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.
Haha! First, "This wouldn't have happened if you were running Windows!" post. Although in thinking about it, I have had updates in the past that stopped Windows from booting too, so damn. Maybe, "This wouldn't have happened if you were running OS/X!". Crap it happened there too...
That's it! Back to Windows 10!
Is it the kernel? Or some userspace boot process? udev sounds like the init system has a problem.
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?
My mouse started moving across the screen ON ITS OWN!
I unplugged my network cable and I am now writing this post on a yellow legal pad with a pencil!
LOL @ vword: audited
Let's not drastically overreact here!
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."
That's it! Back to Windows 10!
You don't get it, it's KB3035583 that has been merged with 4.6.1 and 4.7 beta to force-upgrade to Windows 10
And unsurprisingly: it crashes.
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.
udev is the userspace daemon responsible for adding/removing device files to /dev/ since people didn't want the kernel doing that on it's own (devfs apparently had bugs nobody wanted to fix).
From the error message, it appears that udev is unable to connect to the kernel to get the messages about what devices are available so it can create those device files, and it's probably been a decade since anyone knew how to mknod their devices correctly since we've all grown soft thanks to Friend Computer doing that work for us. Since udev did not create the device file and the user does not know what the device file should be to create it themselves, mount cannot mount the device file, and the computer cannot boot.
It's unlikely that this has anything to do with nfsroot.
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!
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
If udev is a userspace daemon, does systemd run before it and start it? Is systemd responsible for setting up the communication between udev and the kernel?
Running 4.6.1 and 4.7-rc1 on Fedora 23, and no problems.. Maybe a Ubuntu-specific issue?
systemd would probably be responsible for running it, but I am pretty sure udev communicates directly with the kernel, not through systemd.
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 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.
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).
only a few linux versions are "supported"
no linux "versions" are supported by anyone, ever
linux distributions are supported
when one version is set to be EOL, people are warned to upgrade to one of the supported version, usually the latest
makes NO SENSE at all. Please review how RHEL etc actually function if you can manage to get your head out of your ass
Ubuntu in general has been unstable as shit. Wife needed to create a slideshow movie from a bunch of pictures, using programs like openshot, imagination, kdenlive, etc -- those programs crash constantly (openshot being far worse than anything I've ever seen -- always segfaulting). Wife struggled through the crashes with imagination, and eventually got a movie made, then struggled with the bugs in kdenlive to get an audio track added and generate a DVD VOB.
Struggle to find more software (ended up with devede) to convert the VOB to an ISO image that is capable of being burned to DVD. Of course kdenlive only generates files that are useless by themselves (you need programs like devede to create an ISO or burn a DVD).
Then, found that we couldn't burn to DVDs, always making a coaster at 85% into the process - wasted half a day, and a bunch of blank DVDs trying to convince myself that the ISO was corrupted (and re-rendering the movie). Finally I give up and boot up Windows to try my copy of cdrtools (from 2009), and it burned the DVDs like a champ (same hardware / dual-boot / same ISO image).
I mean, W.T.F.
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.
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.
You didn't have to say anything. Microsoft already told us.
Open architecture
And yet when you compare kernel to kernel, Linux has had several orders of magnitude more bugs than the NT kernel. Usually most bugs in Windows are outside of the kernel. I guess that's what happens when you have a huge blob with everything and the kitchen sink design as the Linux kernel does. Looks like Linux people have a lot to learn about modularity from Microsoft engineers.
Sounds like a systemd failure to me...
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.
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.
Oh believe you me, I was thinking that the entire time I was dealing with this mess (rushing to create and burn these movies for my wife's project).
cat /var/log/syslog | grep foo | less
You are overly piping; can do grep foo /var/log/syslog | less.
Sometimes this is true...
This is unpossible! You're lying! Everything Open Sores is perfect and this wouldn't evar happen! Loonis Toreballs and all things related to him are always perfect!
The 4.4 kernel has been declared as an official "Long Term Support" release, so any significant faults and all known security fixes (such as those in 4.6.1) will be backported to it throughout its support life until it becomes EOL.
4.4.11 or thereabouts is the latest in the ongoing series of 4.4 updates.
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...
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.
Is systemd now a part of the Linux kernel, just because almost all major distros of Linux use it?
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!"
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.
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...
Looks like udevd (inside initramfs) throwing a hissy fit because it can't talk to the kernel.
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).
What we need to figure out is a way to blame Windows 10 forced updates on systemd. Then we will truly have reached satori.
canonically when calling someone out for this it is 'useless use of cat'
Welcome to linux, where software to deal with photos, video editing, and cd/dvd burning is subpar and a big joke since the 90's.
Systemd
or in this case, catless use of less
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):
1. You can turn off journald and use rsyslog or syslog-ng instead.
You actually really can't. What you CAN do is have journald forward its messages to syslog-ng, but it isn't dropping in one for the other, rather duplicating and hoping journald is doing what it should. You can do things like telling journald not to store things, or have a small log size, which will often actually work now....
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.
So I could spend $1000 as a test? You're a loon.
That's it! Back to Windows 10!
But but, cryptolocker
It's all because of systemd that the new Linux won't boot !
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.
While systemd presented a lot of nasty surprises and real ugly design decisions it seems to be a missing kernel module this time.
Nobody uses unix sockets anymore, right?
Putting the module in initramfs or compiling the module back into the kernel reenables the missing protocol. It's poettering in style, but that's all.
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.
Adults spend thousands of dollars just to figure out what they want to buy?
No wonder every adult I know has a ton of debt.
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!
If it's going to be a thin client, why bother with Ubuntu? You can use Ubuntu for the server, but the clients can use a lighter, easier to work with OS, such as TinyCore.
An X11 thin client would need just a bit of config, VNC would need adding a VNC client, all NFS bootable, as well as a few other network protocols.
1. Ubuntu, Redhat, Fedora are the Microsoft wannabe's of Linux. The only 3 to avoid really.
2. Anybody using the latest kernels knows how to revert to prior config if they are affected.
Mandrake Cooker used to be fun. You got the latest patches immediately.
Don't freak out because the summary says ...
All users of the 4.6 kernel series must upgrade," says Greg Kroah-Hartman.
It's absolutely not like Windows where they use every dickmove to force unwanted updates on you. This story sucks dick as worded tbh.
With Windows, eg. Windows 10, they sneak updates in... change telling you what's included and what is not... which happens to be Global Mother Fucking Spyware. Then they shill the Internet with bullshit until the populace gets tired of hearing about it etc... Big debate style advertising... only ever ending with "muh games so I have to put up with the spyware."
So you have spyware with fucking games now. Then they sneak backports into previous versions 7/8/8.1 that not only spy if you don't update but even nag you to update. It takes hours to read how to block their bullshit... now do a headcount. Lifetimes die reading their shit. Then NOW... last couple weeks... they have you closing a box but it goes ahead and updates over your 9 year old kid's Windows 7 when they click close instead of not updating. Now today same time as this story they removed the red box it just updates.
https://news.slashdot.org/story/16/06/02/2140230/microsoft-removes-the-x-from-windows-10-update-leaving-no-way-out
They read this shit and so do the spies. Notice how they aren't sued any more or threatened to be split into two corporations?
Dig a big big big fucking tomb.
this is news why?
Why because they were true?
Anything a vendor ships that breaks is THEIR fault. If Ubuntu chooses to ship systemd and it breaks something that is Ubuntus AND systemds fault. Both share the blame. Period.
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.
Does systemd not run first and then everything runs thru systemd?
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)...
Oooooo Mr. smarty mcsmartie pants guy over here. The resident slashdot know it all. Who seems to truly believe he's a rockstar. Yet he can't grok that this simple program called systemd has problems. Instead, places the blame elsewhere. But never provides anything useful, just copy pasta and blatant lies. Aka a troll. But I'll shoot you down anyway, because I'm bored.
Not everybody is as smug as you. And people who are usually smug aren't very confident because they are hiding behind their smugness. They also bend the truth and lie a lot.
You didn't say I was wrong, because you know I am right, your smugness won't let you admit it. Do you live in San Francisco by any chance?
So if you think I am wrong, you are basically saying that it is the users fault 100% of the time when a distro or kernel updatw breaks something. Because that is what you are suggesting. If that's the case then how come Microsoft doesn't get that same respect. I'll tell you why, because of zealots. If Windows updated its kernel and it borked some computers boot up process, you would shit in your pants. Calling for heads at Microsoft to be impaled out front of Redmond on stakes. How do I know this? Because it's happen before. Look no further than this Windows 10 problem. It's forced on users just like systemd was. Yet when it happens to a Linux distro (most likely due to systemd because the other init systems keep working fine) it is 100% the users fault. He did something wrong. Or it's 100% the kernels fault because Linus. Or it's 100% the hardware fault. Or it's 100% the codes fault. If it's broke fork it and fix it yourself you luserZ. That's the attitude. I understand it's free software and WE choose to use it. But please stop treating people like they are the problems. If your software crashes computers and causes countless issues and you fail to address those problems, that is YOUR fault as a coder. Stop blaming the users. Sometimes they deserve the blame. Most of the time they don't.
Never once did you accept that maybe systemd is causing more problems than it's fixing. Or even is causing this problem. You keep dismissing it. Because it seems that with every distro that uses the Linux kernel and systemd, something breaks. I'm not saying systemd is at fault 100% of the time, but lately it feels like at least 50% of issues with Linux stem from systemd. (Citation needed). I know Linux is the kernel and systemd interfaces with it. But lately they don't seem to be playing well together or ever played well together. And that's an issue for many people, Including myself. Lately it feels like the kernel has to follow systemd rules in order to work. Systemd is BECOMING the kernel. If systemd is causing an issue with the kernel, the systemd devs believe it's the kernels fault and they need to abide by their rules. That's a huge problem. Another case of being smug.
And out of all those broken Debian systems, who should be blamed? Someone has to take responsibility. If I upgrade my computer the standard way and all the hardware is "supported"' and I did everything in the manual down to the T, that's not the users fault if it gets borked.
That's why Linux gets no respect. They don't take responsibity for their actions. That's why we have shit like systemd. No one told them it was shit and wasn't needed. Everyone gave pottering a pat on the back and a cushy job at red hat. If Adobe hired pottering and he created a systemd for Adobes creative suite, he'd be fired. Instead you guys gave him more control. Now systemd runs everything. It has its grips in every piece of Linux code damn near. And you allowed it to happen.
I know what you are going to say, don't like it switch distros. That's the fucking problem. Instead of fixing a serious issue, you side step it and work around it. How can I have choice when everything is being written to work with systemd and not without it. You aren't addressing the problem. You are treating the symptoms and not the causes. It's worst than the medical industry for Christ sakes. Th
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.
https://www.phoronix.com/forums/forum/phoronix/general-discussion/874145-you-may-want-to-think-twice-about-trying-linux-4-7-git-right-now?p=874152#post874152
This works for me, just a small fix.
Yet another Linux boot issue causing problems, once again proving open source is amateur hour.
Wow. Just wow.
Your comment makes me believe that you either have no understanding about the complexity of a piece of software like the linux kernel and/or have no understanding wrt the open source process.
If the former, and assuming you can read code, then you can correct your ignorance by heading over to kernel.org
If the latter, then may I point out the word "open". You are seeing the kernel (at kernel.org) BEFORE it has gone thru QA. (In a closed s/w shop you would never have the option of seeing/using this kernel.) If you only want blessed kernels then take them from your distro. Even then you can choose how risk adverse you are thru your choice of distro (IMO e.g. RHEL/CentOS if very risk adverse, Ubuntu for middle ground, Arch for risky, but new)
If you were trolling, then well played sir. You got me this time.
https://askubuntu.com/questions/781849/ubuntu-fails-to-initramfs/781869#781869?newreg=fa0ba2ae2cfd46c0a57658a4adbf2840