Slashdot Mirror
Linux Kernel 4.6.1 Released; Some Users Report Boot Issue
Marius Nestor, reporting for Softpedia (condensed): Linux kernel 4.6.1 is already here, only two weeks after the official launch of the Linux 4.6 kernel series. For those not in the loop, Linux 4.6 branch is the latest and most advanced kernel branch available right now for GNU/Linux operating systems, but it looks like its adoption is a little slow at the moment. "I'm announcing the release of the 4.6.1 kernel. All users of the 4.6 kernel series must upgrade," says Greg Kroah-Hartman. "The updated 4.6.y git tree can be browsed at the normal kernel.org git web browser."
Some users are apparently facing boot failure issue on the latest version. An anonymous tipster tells Slashdot: Several folks on the web have reported a regression in the latest Linux kernels, starting with 4.6.1 and including the 4.7 beta that prevents booting and drops to busybox, at least the one supplied by the Ubuntu PPA. The boot sequence ends with "address family not supported by protocol: error getting socket" and then, "error initializing udev control socket" (screenshot here).
Some users are apparently facing boot failure issue on the latest version. An anonymous tipster tells Slashdot: Several folks on the web have reported a regression in the latest Linux kernels, starting with 4.6.1 and including the 4.7 beta that prevents booting and drops to busybox, at least the one supplied by the Ubuntu PPA. The boot sequence ends with "address family not supported by protocol: error getting socket" and then, "error initializing udev control socket" (screenshot here).
It was just a few days ago that I saw an article here Slashdot about how systemd changes are breaking software like screen and tmux.
Could systemd also be responsible for these booting problems described in the summary?
I know I experienced problems booting my Debian computers after upgrading to systemd. I've seen a lot of bug reports from other people describing similar problems involving systemd, too.
That's it! Back to Windows 10!
I know Greg's been using that "must upgrade" line for a while. For example in 2013 he did "The Linux Kernel 3.12.1 is now available for the users and all the users of 3.12 kernel series must upgrade". Does anybody know if that's a reference to some pop culture or something?
That's it! Back to Windows 10!
But but, cryptolocker.
lets get that out of the way, early ;)
anyone know if systemd, our favorite component of late, has anything to do with this?
--
"It is now safe to switch off your computer."
Looks to me like a problem with rSCSI or nfs or something is horking the boot process when it tries to mount root.
I'm not surprised. I had to struggle like crazy to get nfsroot working on Ubuntu 14 (diving deep into support forums to find the one completely undocumented option required to make it work). I would have given up except that Ubuntu has (had?) a trial thing that did nfsroot so I knew there had to be a way to make it work.
It's kind of dumb just how hard it is to make an old style thinclient these days. In the old days you would add the nfsroot option in DHCP and a tftp link for the kernel. Super easy. Now you need to jump through several hoops to even get to the point where you need a completely magical kernel commandline option to make it work. Even when you do systemd gets really upset with you because it really really wants to check UUIDs on everything and that doesn't make sense on a thin client. While it's possible to hack out the UUID checks, they get added back in with every minor kernel update (so every couple of days on Ubuntu) and require hacking several files to properly disable. Even then you get a 30 second wait because some message wasn't sent through the message queue (debugging mass message queues sucks) during boot and you have to rely on the fallback to finish booting.
I read the internet for the articles.
Yet another Linux boot issue causing problems, once again proving open source is amateur hour.
Yes. Fortunately something like that would never happen when, say, being forced to upgrade to Windows 10.
Systemd in Ubuntu has been unstable as shit I know that.
Perhaps you could back that up with some kind of facts? I've been on systemd since the very first release (15.04), and I've had zero problems with it so far.
Just to make it clear, I'm not a systemd defender or apologist or anything. My opinion towards it is totally neutral (except journald, which I happen to like). I'm just really tired at the amount of uninformed and insane trolling ("systemd has NSA backdoors!" "there's no stderr!" "it has taken over the whole ecosystem and there's no alternatives!") in comments.
Yet another Linux boot issue causing problems, once again proving open source is amateur hour.
Right, because Windows or OS X have never ever had booting problems in their release history?
I'll have you know that I've experienced TONS of Windows booting problems. And that's in the stable release (Win7 Pro) that my employer paid for! This isn't even a fair comparison, because only developers and extreme tinkerers compile their own Linux kernel (on the same day as the release, no less). The stable kernel that's packaged in the Debian, RHEL, etc. releases is infinitely more stable than NT.
if your system is hosed, what do you do?
Screenshot at Ubuntu is great proof, seen this stuff before, but does it help?
Do you have a FS backup to go back before the upgrade and how long did it take you to do the FS backup + restore the IM backups you took?
Honesty !
Maybe you can to into Grub cl and do it, but if your system is under LiLo because your HW can't take grub - go RIP with disk and try it from there - figure out the cl...
Good luck with it hope it does not take you 1/2 night or day to get it worked out.
Yukk!
Is it the kernel? Or some userspace boot process? udev sounds like the init system has a problem.
I have programs A and B
I update A
A now no longer works
so it must be B's fault
(replace A and B with "Linux" and $INIT)
I have a Dell Inspiron 13, and the kernel boots fine. But, I got my wife an XPS 13 9350 a few weeks ago and tried 4.6. I get the exact same behavior as shown in the screenshot linked in the summary. This is interesting, because 4.6's release notes specifically mentioned new features for the 9350.
sig: sauer
I have seen the message "Address family not supported by protocol" when a program has IPv6 support but the kernel does not.
The real "Libtards" are the Libertarians!
Well, I got a panicky phone call once from a fried whose Windows system updated and it booted just fine. Then it rebooted. And rebooted. And rebooted....
Statistically speaking that evens out, wouldn't you say?
Sound: probably a PulseAudio bug. Try reporting it and see what happens.
Things failing to start: you're not being specific enough for me to comment on whatever problems you're having or whose fault it is. Your lack of error messages is contingent upon a lot of things (are you start services via an init script? shell command? by clicking the button in Unity/whatever your DE is?). But I will say that the only part of systemd that I'll actively defend is journalctl because of how easy it is to use (see here for a nice primer).
Well, I haven't been digging around in that part of the system much lately, but as I understand it, systemd has pretty well taken over the udev process (like so many other things). So there's a fairly high probability that systemd is at least part of the problem.
Even if systemd itself isn't driving udev abnormally, there's still the question to be answered of whether systemd is aiding or hindering the diagnostic and repair processes.
And those are VERY significant to me. One reason I liked Linux better than OS/2 was because despite working in a major IBM shop, when I had problems with OS/2, neither IBM nor third parties provided much in the way of problem resolution (Thomas Watson probably spun out in his grave long ago). Linux, on the other hand, had fairly detailed logs and diagnostics despite not having any Fortune Corporations backing it at the time.
I'll just make a few points about journald, since that's important to you (and as I already said, I actually like it a lot): /var/log/syslog | grep foo | less).
1. You can turn off journald and use rsyslog or syslog-ng instead.
2. journald starts at the same time as the previous two daemons started in the init process, so the same amount of info is at your hands when you're debugging boot problems.
3. You can use journalctl with all your favorite tools that you're accustomed to (i.e. journalctl | grep foo is the same as cat
If you're a hardened unix admin with decades of experience, you're probably just as fast or faster than anybody using journald is to find whatever you're looking for in the logs. I'm not knocking your experience in any way, and if you think journalctl sucks, I'm sure you have a perfectly valid reason (except for "it's different therefore I hate it"). That being said, for somebody that's been in unix for less than a decade, I really think journalctl is much easier to use. For example, if I want all the kernel errors from two boots ago, it's just journalctl -p err -b -2 -k. You can get the same thing with grep but it's a lot more work.
cat /var/log/syslog | grep foo | less
You are overly piping; can do grep foo /var/log/syslog | less.
This solution worked for me on ubuntu 16.04 with kernel from http://kernel.ubuntu.com/~kern...: https://www.phoronix.com/forum...
Right, because Windows or OS X have never ever had booting problems in their release history?
Personally, throughout many years of use of Windows, starting with NT4, I've never once had a boot problem with Windows that was due to a version change or an update from Microsoft. Instead, all the boot problems I've experienced seemed to revolve around other various types of data corruption on the machine.
Oh, except for the other day when my new (and first) Windows 10 machine took two hours to boot due to apparently having completely reinstalled Windows 10. I deduced that it was a complete reinstall not only because it took so long but also from the fact that in the last few stages it promised me that "none of your files have been changed."
At least it worked after that. Lord knows what they did to the machine, or why they did it. But I think I'm beginning to know what it feels like to be an attractive new inmate in a maximum-security prison...
Perhaps not the kernel, but it does claim to run the init system, and it *must* interact with the kernel. To suspect systemd in this case may be slightly paranoid, but it's not being unreasonably so.
I think we've pushed this "anyone can grow up to be president" thing too far.
Indeed. Something the Windows-world does not know: There you only get what you deserve.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
So what you're saying is "I have broken applications or configs on my PC and I will blame it all on systemd because ... I just don't like it OKAY!"
You really think RedHat would let that happen? I get not liking systemD, but there's no need for conspiracies.
Well, I haven't been digging around in that part of the system much lately, but as I understand it, systemd has pretty well taken over the udev process (like so many other things). So there's a fairly high probability that systemd is at least part of the problem.
So kernel worked before, something in the kernel changed, now the system doesn't work and it's systemd's fault? Stretch
Even if systemd itself isn't driving udev abnormally, there's still the question to be answered of whether systemd is aiding or hindering the diagnostic and repair processes.
I'm going to go with aiding. The great strength of systemd is the ability to log much earlier in the boot process and capture the entire boot process to a log unlike syslog. So while you're speculating, why speculate in a direction with complete lack of evidence?
And those are VERY significant to me. One reason I liked Linux better than OS/2 was because despite working in a major IBM shop, when I had problems with OS/2, neither IBM nor third parties provided much in the way of problem resolution (Thomas Watson probably spun out in his grave long ago). Linux, on the other hand, had fairly detailed logs and diagnostics despite not having any Fortune Corporations backing it at the time.
Yep, and now there is more logging than there ever was before. Even when you revert your system to using some syslog daemon you get extra detail from the early part of the boot process.
No, but it requires pretty heroic effort to avoid it, so talking about them at the same time can be useful, depending on context.
> Haha! First, "This wouldn't have happened if you were running Windows!" post.
I know you're kidding, but the solution for those who are grabbing the latest kernel and having problems was just to pick another kernel off the list of choices instead, and boot with that. And of course, if you are using a distro without doing that, you don't have these issues.
Just because Linux lets you grab the kernel straight up doesn't mean you have that need. If you have that need, you sure as fuck aren't using Windows, which doesn't have any comparable option. This isn't happening to end users going through a distro.
> And yet when you compare kernel to kernel, Linux has had several orders of magnitude more bugs than the NT kernel.
First, I fucking doubt it.
Second, if you are going to compare a tiny kernel to a big kernel, it is not a useful comparison. Compare instead the set of Windows components, kernel included, that has equivalent features to the Linux kernel.
Looking at the screenshot from the summary shows that the error occurs in the initramfs so this happens long before any init is called by the kernel. That it dropped to busybox in the first place was a big indicator that this happened long before init was called.
Reminds me of all those posts claiming that systemd broke their systems when they upgraded to Debian 8, like there where not tens of thousands of packages that where changed between Debian 7 and 8...
udev has not been taken over by systemd, since the same developers maintained both the systemd and the udev trees they simply merged them to have a more sane development environment. And the problem from TFA is clearly happening long before the kernel even executes any init since it happens inside initramfs, the mere statement from the summary that the shell is dropped to Busybox should tell you that this happens before even the root is mounted (and root is mounted long before the init is called since the init lives in the root).
It breaks in initramfs which kind of is in the kernel. Since the kernel must have a way to mount root before it can begin to even find init (i.e systemd in this case) most distributions use an initramfs that does all that magic before the real userspace (i.e init) is called and they often include busybox so that you can recover from a failure in initramfs if it cannot mount root. The magic comes due to having to be able to mount all kinds of kinky roots (lvm, raid, different filesystems, nfs and so on).
So it appears that for the affected people this kernel version broke something that their initramfs needed. If it hade broke down in userspace then you would get a bash or sh shell and not a busybox.
Sounds like you have no clue considering the info in the provided screen shot in the summary.
Since it breaks in initramfs and each distribution have their own version of that, this does indeed sound like a Ubuntu specific issue.
It breaks in initramfs which kind of is in the kernel. Since the kernel must have a way to mount root before it can begin to even find init
It looks like its past that point already. udev is trying to start (systemd-udevd.service, etc.). initramfs is fine (which is why you see the initramfs prompt when the 'init' process fails). It is the fall through for an init failure.
Have gnu, will travel.
OSX is "available to the masses" in the same way that business class air travel is.
The next time I have $3k lying around to try OSX and decide if I want a really expensive Windows laptop, I guess I can see if it's really improved that much since Leopard..
For example, if I want all the kernel errors from two boots ago, it's just journalctl -p err -b -2 -k. You can get the same thing with grep but it's a lot more work.
Two boots ago systemd did not exist.
It sounds like a configuration problem of the Ubuntu PPA kernel that doesn't match the Ubuntu default dracut or mkinitramfs settings (e.g. kernel configured with unix sockets as a module instead of built-in and the initramfs not configured to include the unix module). As a result, udevd in initramfs can't open a unix socket.
Really, this wasn't hard to deduce from the error messages.
And nithing to do with systemd.
So I could spend $1000 as a test? You're a loon.
No it's not past that point, the problem is clearly that it cannot mount root and mounting root is done inside initramfs and before an init like systemd is set up, there is probably some udev inside initramfs as seen from the screen shot but that is not the systemd-udev.service one since that is started only after root is mounted. No this has something to do with mounting the users drives, perhaps they use some form of lvm or raid that is makes this version of the kernel incompatible with the initramfs from Ubuntu (might also be for more distributions but we do not know yet).
Systemd in Ubuntu has been unstable as shit I know that.
Perhaps you could back that up with some kind of facts? I've been on systemd since the very first release (15.04), and I've had zero problems with it so far.
Just to make it clear, I'm not a systemd defender or apologist or anything. My opinion towards it is totally neutral (except journald, which I happen to like). I'm just really tired at the amount of uninformed and insane trolling ("systemd has NSA backdoors!" "there's no stderr!" "it has taken over the whole ecosystem and there's no alternatives!") in comments.
Is unreliable or unpredictable better?
By the way: "it has taken over the whole ecosystem and there's no alternatives!" can be a problem, because it is a lot harder to fix than the previous shell scripts doing its job. Most of its new features could have been implemented without breaking stuff for servers. Most of the time you are fine if you are running a desktop (unless you experienced the nice black screen of doom (no console nor login manager spawns. yay, for consoles starting on demand) in early 15.10.
'Funny' ideas from systemd camp (mostly resolved by feedback):
- kill -9 to shutdown processes faster (all programs that write data on shutdown loved it)
- restart all ssh connections on ssh restart (fun for remote administration/updates)
- ignore DHCP resolver parameters
shouldn't be hard to google or search the debian bugtracker or the systemd mailinglist for more information
So I could spend $1000 as a test? You're a loon.
I see. Well, I can see the only figure you'd really accept is ZERO; so nevermind. I obviously mistook you for an adult.
Seriously, there's a bug in a development version of Ubuntu so you (1) report it in a headline on Slashdot and (2) mention "Linux Kernel", not "Ubuntu" in that headline.
Report it on launchpad, that should get it fixed.
The clickbaiting needs to stop!
Windows 10 is free, and look at all the shit with it. Don't know what your point is.
I'm surprised you managed to install an OS with a reading comprehension that poor.
Let him live his miserable existence in the Ubuntu and Windows world. You can lead them to water.
Meanwhile us Mac users snicker every time a thread like this pops up.
Yep. I've been snickering since 1984 (and 1983, if you count my time with the Lisa)...
There is no latest version of initramfs since each and every distribution have created those from scratch in order to support the various and special use cases they each need. Some work to unify it between distributions have been done as far as I know but how far that have gone I don't know.
Because there is no Ubuntu version available without systemd that also can run this new version of the kernel? I can guarantee you that if the person from TFA replaced systemd on his machine with sysv then it would still not boot, you know why? Because it freaking breaks before any init is called by the kernel at all. All you comment tells me is that the anti systemd trolls are completely clueless on how Linux works or how these things stick together.
Please tell me where I put the blame on two different things? In fact I don't put the blame on anything, all I point out is that it breaks inside initramfs which is way way before any init system (sysv or systemd) is even called by the kernel. I have also pointed out that since initramfs is usually different between distributions this could very well be a problem only on Ubuntu systems, or they could be a problem for people with specific types of hardware since the main thing with initramfs is to mount the root device regardless of setup and from the provided screen shot we can clearly see that this is what breaks (i.e the mounting of root). How do you even propose that the kernel could load systemd from root before it even can mount root?
No one has ever dismissed that systemd could cause some systems to break, that is only an illusion kept by you anti systemd trolls. It falls naturally that no software project is ever 100% perfect and bug free. But you pretend that systemd where the only change when you upgraded when the reality where that every single piece of software on your machine where changed.
And this is the main problem with all of this because there are not a single distribution out there that only introduced systemd, they all did it with together with tens of thousands of other changes. So each and every borked system have to be examined before blame can be issued to who or what caused it.
And also in the real world outside Slashdot the vast majority users of Debian, Ubuntu, RHEL and so on got their systems upgraded to versions that run systemd and none of them noticed a single issue. That is not the same as no one experienced problems with systemd.
No, first the boot loaded runs (grub, grub2, lilo and so on). Then the kernel is run, and then (if available) initramfs runs. The initramfs is needed on most systems because mounting root (i.e / ) is not always a simple affair, you could run it on some exoteric filesystem, or on some kind of raid device, or some LVM device or even networked via nfs and so on.
And no one want to bloat the kernel with support for all of that shit so instead a small initial filesystem that can be run from memory (hence the name) is often created by the various distributions and put on on the same partition as the kernel (i.e /boot) these are created dynamically whenever you upgrade the kernel on your machine in order to support the configuration that you have.
Once the scripts and applications in the initramfs have been able to mount root (becuse how could the kernel even load for example systemd from the disk before it could mount it!) the kernels work is done and now it calls /sbin/init which could be sysv or systemd or any other init system.
Now according to the screen shot from the summary the systems break before root could be mounted so there is no systemd involved at all since it could not even have been loaded yet. This is also why the boot have been dropped to busybox, since root cannot be mounted there is no way for the kernel to load /bin/bash or even /bin/sh so to still be able to present a shell most versions of initramfs includes busybox (since it's so small and also contains most of the useful utilities).
So yes systemd (or any init for that matter) runs first when we are talking about the userspace world but there happens a lot before we enter userspace.
Well, not really. The upgrade is free. But you have a point.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.