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).
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
Higuita
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.
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.