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.
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.
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 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)
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...
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.
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!"
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.
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.
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).
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.