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