Linux Kernel 4.6.1 Released; Some Users Report Boot Issue 161
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).
Could systemd be responsible for the boot issues? (Score:4, Interesting)
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 [slashdot.org].
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.
Re:Could systemd be responsible for the boot issue (Score:4, Interesting)
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.
Re: (Score:2)
Re:Could systemd be responsible for the boot issue (Score:4, Insightful)
Re: (Score:2)
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
Re:Could systemd be responsible for the boot issue (Score:5, Insightful)
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.
Re: (Score:1)
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
Re:Could systemd be responsible for the boot issue (Score:5, Informative)
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.
Re: (Score:3, Funny)
cat /var/log/syslog | grep foo | less
You are overly piping; can do grep foo /var/log/syslog | less.
Re: (Score:3, Funny)
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.
Re:Could systemd be responsible for the boot issue (Score:4, Insightful)
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.
Re: (Score:3)
Re: (Score:1)
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.
'
Re: (Score:2)
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 [digitalocean.com]
Re:Could systemd be responsible for the boot issue (Score:5, Informative)
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!"
Re: (Score:2)
Re: (Score:2)
I'm surprised you managed to install an OS with a reading comprehension that poor.
Re: (Score:2)
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
Re: (Score:1, Offtopic)
I love Linux, and for a developer it is great -- but the quality of the end-user software in Ubuntu is abysmal. It seems like Ubuntu wants to pull in the new shiny with no regard to quality. BTW, using Ubuntu 14.04 LTS.
I'm REALLY not trolling here; but there are about 3 different out-of-the-box ways that your Wife's project could have been accomplished on OS X.
And to you, I say as a Developer, there's plenty of "Developer" Goodness available in OS X. In some ways, even more than in Linux.
Re: (Score:2)
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..
Re: (Score:2)
So I could spend $1000 as a test? You're a loon.
Re: (Score:2)
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.
Re: (Score:2)
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)...
Re: (Score:1)
Re: (Score:3)
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.
Re: (Score:2)
No, but it requires pretty heroic effort to avoid it, so talking about them at the same time can be useful, depending on context.
Re: (Score:2)
You really think RedHat would let that happen? I get not liking systemD, but there's no need for conspiracies.
Re: (Score:2)
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?
Re: (Score:2)
> 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.
Re: (Score:3)
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)
Re: (Score:1)
A now no longer works
Then how are the affected systems dropping to busybox? The kernel has to be OK for that to work. So in this case, it appears that 'B' is in fact broken.
*Things like the dev, udev and other system services need to be started by the init system. These services are very tightly coupled to the kernel and it's not unheard of for a kernel update to break one or two of them. That's why *NIXes are modular. Made up of a bunch of stand-alone utilities. So if one thing breaks, the failure isn't likely to propagate. B
Re: (Score:2)
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 i
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: Kernel, or userspace boot stuff? (Score:3)
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.
Origin of "must upgrade" joke? (Score:3)
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?
Re: (Score:2)
at least it's such a silly imperial phrase, it must be a joke ... surely?
Re: (Score:3)
Re: (Score:2)
Such coyness is unseemly. Besides, GKH is immune to blame already by virtue of the NO WARRANTY clause of the GPL.
Re: (Score:2)
Unseemly? No. Just good process. Greg is not worried about legal liability, he's worried about what happens to you if you don't update the kernel. And he's not interested in feeding the script kiddies. People who want to know what the security problems are should read the kernel lists and diffs.
Re:Origin of "must upgrade" joke? (Score:5, Insightful)
This is just a empty way to say that this build may or not fix security problems.
In the past, several people complained that linux announces did not warn about fixed security problems,but failing to understand that many fixes are made even without notice that the bug was a security problem in the first place. So some people would only update the kernel when they saw any warning about a security fix and ignored the other ones... and then complained that the previous release notes were broken when it was found that some of the already fixed bug were really security holes and how easy it would be for the developers to add a note to the commit/release notes that everyone should/MUST upgrade the kernel.
As there is no "security team" in linux and the linux code rapid development, no one is really in charge of analyzing each patch security implication. Greg, tired of the complains decided to say that in every release there are bug fixed (except very simple bugs, documentation, etc), so if later it is found that any of those patches where fixing a security problem, they could just say that they were warned to upgrade. Also, some bug fixes are more important than others, so "should" is used for minor problems, but if there is any known bigger problem (security,corruption, stability), Greg usually uses the "must" word
Finally, only a few linux versions are "supported", so when one version is set to be EOL, people are warned to upgrade to one of the supported version, usually the latest
Re: (Score:2)
Re: (Score:2)
> Everyone who configures their own kernel
No no, he asked who in their *right* mind, your statement precludes that! :P
Re: (Score:2)
you see, the brand new AMD graphic card, still unreleased is already supported in the kernel and mesa.
All depends of the company behind the hardware. Old hardware is community work, new hardware is owner company responsibility, complain to then if not supported. That being said, not supported hardware in linux is usually a rare sight.
Re: (Score:1)
I've been doing it off and on for years, simply for the bugfixes most often. Distro kernels tend to lag quite a ways behind, and often pack stuff that I have no need for.
Re: (Score:3)
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?
I assumed it was because his first language is German.
Re: (Score:2)
This release contains security fixes. At least this one [openwall.com] stood out, but more of the changelog sounds like it might fix exploitable issues.
systemd or not? (Score:2)
lets get that out of the way, early ;)
anyone know if systemd, our favorite component of late, has anything to do with this?
Re: (Score:1)
Re: (Score:1)
It's dying in udevd which has been hijacked by systemd.
Re: (Score:2)
It's dying in udevd which has been hijacked by systemd.
Due to a crap call by a kernel which worked in the previous release. Try again.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
At this time, I am very seriously considering throwing out udev and all the instability and auto-mess it brings with it and going back to statically created device nodes. While a bit more work initially, that does not fall over foaming at the mouth if something is not quite as it expects.
Re: (Score:2)
Well, since udevd no longer works without systemd... yes, it is systemd.
Kernel works, update kernel, kernel no works. MUST BE SYSTEMD!!!!
And this is why no one takes you guys seriously.
So (Score:2)
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
Re: (Score:2)
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!
Ubuntu by default saves the last three or so kernels that you've gone through, so that if the new release is unbootable, you can still use an older one. It's selectable from GRUB.
LILO is now maintained by Slackware, so you'll have to ask a slacker what they do in that case. Probably the same thing, I would guess.
Re: (Score:2)
Re: (Score:2)
> I think if I had known about the legal quagmire that is the IT industry at this point I would have studied law rather than computer science...
If anyone knew what Oracle was going to do, they just would have never used anything that they touch. If they buy something you care about, transition off IMMEDIATELY. Not doing so is a minimum six figure error for a company, and possibly 2-3 more orders of magnitude. Vastly too risky to touch, total poison.
Re: (Score:2)
Re: (Score:2)
--I think you mean, you can hold the Left SHIFT key in during boot... ;-)
Re: (Score:2)
Boot issue on Dell XPS 9350 (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You get what you pay for (Score:1)
Sometimes this is true...
Re: (Score:2)
Indeed. Something the Windows-world does not know: There you only get what you deserve.
Re: (Score:2)
Windows 10 is free, and look at all the shit with it. Don't know what your point is.
Re: (Score:2)
Well, not really. The upgrade is free. But you have a point.
a solution to boot failure that worked for me (Score:3, Informative)
Ubuntu Dev bug worth a headline? (Score:1)
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!
Re:really? IPv7 already in the kernel? (Score:5, Funny)
Re: (Score:2)
That's it! Back to Windows 10!
But but, cryptolocker.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
> 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.
Re: (Score:2)
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 o
Re: (Score:2)
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.