systemd's mkosi-initrd Talked Up As Better Alternative To Current Initrd Handling--Phoronix:
Red Hat engineer and systemd developer Zbigniew Jędrzejewski-Szmek presented on Monday at the Linux Plumbers Conference on a new design for inital RAM disks (initrd) making use of the new systemd mkosi-initrd project.
The mkosi-initrd approach paired with systemd system extensions is a fundamental shift from expecting initrd images to be built locally on user systems to something that can be done by distribution vendors with their build system. This can allow for better QA, embracing various modern security features, and more manageable initrd assets. Zbigniew summed up his LPC 2022 talk as:
Distributions ship signed kernels, but initrds are generally built locally. Each machine gets a "unique" initrd, which means they cannot be signed by the distro, the QA process is hard, and development of features for the initrd duplicates work done elsewhere.
Systemd has gained "system extensions" (sysexts, runtime additions to the root file system), and "credentials" (secure storage of secrets bound to a TPM). Together, those features can be used to provide signed initrds built by the distro, like the kernel. Sysexts and credentials provide a mechanism for local extensibility: kernel-commandline configuration, secrets for authentication during emergency logins, additional functionality to be included in the initrd, e.g. an sshd server, other tweaks and customizations.
Mkosi-initrd is a project to build such initrds directly from distribution rpms (with support for dm-verity, signatures, sysexts). We think that such an approach will be more maintainable than the current approaches using dracut/mkinitcpio/mkinitramfs. (It also assumes we use systemd to the full extent in the initrd.)
See the talk or go look at the PDF slides.
(Score: 1, Interesting) by Anonymous Coward on Friday September 16 2022, @10:21PM
and IBM controls Red Hat
lock it down, charge by the seat.
(Score: 3, Insightful) by JoeMerchant on Friday September 16 2022, @10:31PM (23 children)
Sounds like modernization and improvement, I predict mistrust, resistance, and shrill arguments against.
Resistance is futile, but you are welcome to maintain your fork of the old ways as long as you feel inclined to do so.
🌻🌻 [google.com]
(Score: 5, Informative) by bart9h on Friday September 16 2022, @10:56PM (5 children)
Thanks, we will [devuan.org].
(Score: 2) by RS3 on Saturday September 17 2022, @01:49AM (4 children)
I'm building a new server, for _many_ reasons want to stay away from systemd. I tried devuan and it's great but they're including a bunch of systemd stuff, but not running systemd itself. I understand that more and more software (Nvidia drivers, for example) won't install / run without some systemd stuff. I'm happy to do whatever I have to to block the spread of systemd, and I was disappointed that devuan is accommodating systemd to some extent.
There are many others to try:
https://en.wikipedia.org/wiki/Category:Linux_distributions_without_systemd [wikipedia.org]
https://nosystemd.org/ [nosystemd.org]
https://itsfoss.com/systemd-free-distros/ [itsfoss.com]
https://www.ubuntupit.com/best-systemd-free-linux-distributions/ [ubuntupit.com]
I've been running Alpine on 1 system (not live) for years and it's really good. I have to try a full clean install again and see how it goes. I tried MX and that might be the winner, especially considering the large amount of Debian packages available.
(Score: 2, Informative) by liquibyte on Saturday September 17 2022, @12:51PM (2 children)
They are not accomodating systemd per se, the developers upstream have however. In order for some software to run systemd must be seen. Devuan is a fork of Debian and those that decide things there insisted this software was a must have feature to the great consternation of the rest of us that don't have enough time to roll our own distros. I remember when this fiasco started and jumped ship early over to Gentoo. Alas, those devs started consistently breaking stuff over the years so I had to, once again, find something else. Devuan it is. I'm glad I did even though I didn't anticipate how much I"d need it later. I just built a CNC machine and run it with LinuxCNC which uses Debian as its OS, which by default ships with systemd. Turns out that while Chimaera doesn't have the package linuxcnc-uspace but Daedalus does. So, a repository change later I have a systemd free machine. By the way, I hate the naming conventions that all distros use, it's assinine. Name your program, use a consistent numbering version system that doesn't jump from v14 to v102 overnight and stop with the silly nicknames already.
(Score: 2) by Unixnut on Saturday September 17 2022, @01:35PM (1 child)
Meh, IMO Linux went from a toy OS in the 90s, to approaching a very reliable, useful, successfully Unix like system, to regressing back towards a toy OS in the last 10 or so years, systemd being one of the more egregious examples of what seems to be a general downtrend in the quality of Linux.
FWIW, the only Linux I still use is Devuan, pretty much only on desktops (due to the better support for graphics HW), and moved my servers and processing machines over to FreeBSD.
At work, there are still many Linux servers I handle, but new project designs and deployments for servers are pretty much FreeBSD nowadays in my world.
(Score: 2) by aafcac on Saturday September 17 2022, @05:32PM
As a FreeBSD user, it does kind of sadden me to see what's becoming of Linux. It's not really surprising with so much development spread over so many different projects though.
(Score: 2) by bart9h on Sunday September 18 2022, @02:34PM
I use Devuan on my desktop, but for the server I'm using OpenBSD, and I love it.
It's surprisingly simple to install and maintain, as is very reliable. I feel at home.
(Score: 2, Insightful) by Anonymous Coward on Friday September 16 2022, @11:27PM
What's not to mistrust? It's the Linux "svchost", where's the improvement in an adversarial network? I don't want it to automatically connect
(Score: 4, Insightful) by sjames on Saturday September 17 2022, @01:42AM (13 children)
It's different, but where's the improvement? Honestly it sounds like it makes things a little less recoverable if the root fs doesn't mount for some reason.
Of course, I have yet to see anything systemd does that couldn't be done as well or better by the old init.
(Score: 2) by JoeMerchant on Saturday September 17 2022, @02:49PM (12 children)
Generally speaking, the improvement tends to be in boot speed, and also system control during boot. So, instead of taking 20 seconds to reach your fully functional desktop and watching a bunch of geeky text scroll by and having the screen flicker around in low res, maybe accompanied by primitive sound, the system comes up with better graphics and sound much earlier and reaches that functional desktop ultimately faster. I found it most dramatic back in the early Raspbian days, on the little Pi 2 the boot time to desktop dropped dramatically when you enabled the systemd option. I sort of played the linked video in background while doing other things, the presenter is typical, not exactly riveting of your attention, but... I thought I heard mumbles about making recovery easier / more robust / more predictable / better? But, of course, he's squarely in the systemd is "better" camp, so if you are truly interested you'd have to take what he's saying and evaluate the actual mechanics for yourself to form an opinion from your perspective.
Aside from that, it's more of a "one vision" system than a collection of stuff that seems to work for most people - I'm not touting that as a benefit at all, when you disagree with that one vision you're screwed, but from a fleet support standpoint it's a hell of a lot easier to debug a one vision system than it is to first determine which collection of stuff is running, then hope that you're familiar with what happens when you've got a bag of A, B, C, E, R, and X, when most people run a bag of A, B, D, E, and S. Of course, they need R for this and X for that, and they just don't like D so they got rid of it, but there's this little known side effect on B when D is missing which happens to completely bork X when it runs after R - but if you don't know all of that, and you probably won't because basically everyone is running a unique combination of stuff, then you've got to be a hell of a lot smarter about all those things to figure it out yourself, instead of just looking up a single series of error messages from a single configuration system and finding hundreds, perhaps thousands, of reports from people who have had the same problem - then it's just up to you to select among the top dozen solutions presented for what makes the most sense in this case, and usually whatever you pick it will probably work first try.
I did Slackware in the 90s, and ultimately put it aside - I didn't have enough time to fix what was broken and poorly documented.
I did Gentoo in the 00s, because it was the only route to full 64 bit (and directly addressable RAM of 4GB or more, corresponding to full color 360dpi large canvases) for a while, and then just because it was what I knew. It was o.k., but there are some pretty obvious drawbacks to a system which requires 24+ hours to install from scratch.
I took a detour into the iOS world from '06 to '13, with Gentoo fading in the background, and Kubuntu rising because it was a path of low resistance for my "not on Apple hardware" stuff, and I started using Qt everywhere (and was solidly impressed with how well cross platform Win, iOS, Linux worked with Qt).
Remarkably, Slackware made a reappearance in my professional life, for somewhat irrational reasons, but I worked with it for about a year and developed a mild fondness for Alien BOB. But, predictably, when my clinically insane colleague faded from the scene, so did Slackware - and quickly. Even during the Slack year, Ubuntu and the rightly loathed Unity desktop beat out Kubuntu for my non-product desktop because: it was a 4K screen notebook, and Kubuntu really didn't have a handle on font scaling at the time whereas Unity did.
Since then, professional pressures have kept me in "mainline" Ubuntu for product, and it's such a path of low resistance for my other desktops that I just eat the dogfood everywhere now, and after 10 years it's a pretty comfortable environment. I've even learned to do things the systemd way, and it's not so terrible to live with, but you do have to accept that things happen their way, or not easily at all.
🌻🌻 [google.com]
(Score: 2) by aafcac on Saturday September 17 2022, @03:30PM (2 children)
Isn't that part of why Windows has had that start up screen since Windows 95? It hides a bunch of that stuff so that the OS looks more sophisticated than it really is. I do think that the current start up time is completely acceptable. Before I got my new computer, Windows was taking between 10 and 20 minutes to boot up from scratch because I was rebooting rather than shutting it down whenever I wanted to switch over to FreeBSD. It always amazes me that people think that what MS is doing is at all acceptable. (I only had the install because I had a couple Windows only programs that I couldn't ditch)
(Score: 2) by JoeMerchant on Sunday September 18 2022, @02:39AM (1 child)
Any startup time greater than 1.5 seconds is too slow for my taste. My Atari 800 was faster than that.
15 minutes isn't a boot time, it's a dysfunction.
🌻🌻 [google.com]
(Score: 2) by aafcac on Sunday September 18 2022, @09:18PM
It's dysfunction due to the incompetent way that the boot process is set up. You shouldn't have to wipe the disk and reinstall from scratch because the OS opts to start everything all at once and can't figure out how to prioritize what to start when. And it shouldn't be relying upon cheating by leaving things ready for the next go round, but only if you shutdown rather than reboot. The same computer was able to boot FreeBSD to a usable state in less than a minute.
And yes, it's definitely not acceptable, which is a large part of why I've got the new computer. As far as 1.5 seconds goes, isn't that what hibernate is for? With an SSD, it shouldn't be that much slower than your target.
(Score: 2) by sjames on Saturday September 17 2022, @10:17PM (6 children)
I don't see systemd booting any faster in practice than a well done SysV. It also doesn't seem to have a way to deal with things that should ideally happen but if it can't I'd rather have the rest of the system come up so I can log in and debug it. For example an auxiliary data disk. The ability to quickly hide what may be the only useful debugging information to show a pretty picture doesn't sound like much of a feature.
But as far as initrd goes, the machine really doesn't spend long in that environment anyway unless something has gone horribly wrong. Not to mention a few cases where the only reason systemd was even feasible was that the initrd using a more standard init was able to do the things systemd simply refused to do correctly before letting systemd have at it.
The whole thing smells like change for change's sake likely to introduce system breaking bugs for years to come in what was once a well debugged subsystem. If you really need a one vision fleet, nobody is stopping anyone from rolling up an initrd they like and deploying it everywhere. If you have a big enough fleet to need that, it's not a big deal to do and you quite likely have a vision that differs from the "one true systemd way".
Linux came to be everywhere because it is flexible and versatile, not because it offers a one size fits none "solution". Notably it's a big part of why the WinPhone is dead and Android is everywhere. The world just doesn't need yet another IBM/RedHat solution looking for a problem.
Note, my comments on boot time are based on my personal best (using LinuxBIOS and a DiskOnChip in an old AMD board) of 10 seconds from power on to a command prompt. Systemd didn't even exist then. If it had, I would have needed to do a lot more work to throw it out in order to get that boot time.
(Score: 2) by JoeMerchant on Sunday September 18 2022, @02:46AM (4 children)
>I don't see systemd booting any faster in practice than a well done SysV
That may be the most damning observation of all: in practice most systemd implementations are done better than most SysV implementations, for whatever reasons.
The Pi 2 with its limited resources magnified the difference, but the difference is there on all systems.
>The whole thing smells like change for change's sake likely to introduce system breaking bugs for years to come
I read a good bit of security theater in the presentation, and that will definitely make life harder with questionable benefits.
🌻🌻 [google.com]
(Score: 2) by sjames on Sunday September 18 2022, @03:50PM (3 children)
Probably because most Linux systems are booted infrequently enough that nobody cares that much about boot time (within reason) in most applications.
Kind of like way back in the old days, Tandy's PC clone booted to DOS nearly instantly (by keeping the boot image in ROM). That feature didn't generate much excitement even though DOS needed much more frequent reboots.
(Score: 2) by JoeMerchant on Sunday September 18 2022, @04:50PM (2 children)
>most Linux systems are booted infrequently enough
Depends entirely on application. I boot my TV system once a month and I don't care much about how long that takes, my desktop once or twice daily and that already matters, laptops even more often and I put up with the vagaries of sleep mode to accelerate the restart times there.
Excitement varies by audience a lot. I will note that even after I have had Linux on my desktop for 20+ years, and on the TV for 15, my wife and children still use Windows or iOS or Android for their "daily driver" computer OSs. My wife is ready to make the jump to Ubuntu but her 5 year old Windows laptop just won't die. One son could use Linux instead of iOS for everything he does, but similar situation with the familiar old iMac, and the other actually has an Ubuntu desktop but he spends 90%+ of his time on Android.
🌻🌻 [google.com]
(Score: 2) by sjames on Sunday September 18 2022, @06:43PM (1 child)
(Score: 2) by JoeMerchant on Sunday September 18 2022, @08:56PM
Well, two dozen colleagues at various sites around the country have settled on "vanilla Ubuntu" as the flavor of choice for our products, so I end up with systemd drain bramage at work anyway regardless of what I choose to struggle with at home.
Actually, at home I rarely interact with systemd as anything but a user. It's my work stuff that has me fighting with services, dependencies, X can't run as root, Y has to run as root headaches.
For home I'm presently messing around with Raspberry Pi Pico Ws which are cool for their low power requirements... I have one running on a solar cell in the yard running a 24-7 available webserver that can activate an ultrasonic dog whistle on demand... Unfortunately micropython, while easy to get going, isn't terribly stable when running threads on both cores.... And the C SDK stack is.... Formidable.
By comparison the home Ubuntu and Raspberry Pi OS boxes are pretty much just appliances.
🌻🌻 [google.com]
(Score: 3, Insightful) by maxwell demon on Sunday September 18 2022, @11:25AM
Idon't think so. There's surely a plan behind this. I just doubt the plan is to the benefit of the users.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by maxwell demon on Sunday September 18 2022, @11:03AM (1 child)
Seems the last time you've booted a Linux system is a two-digit number of years ago.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by JoeMerchant on Sunday September 18 2022, @12:03PM
Getting close for SysV. Last time I booted a non systemd desktop would probably have been Raspbian on the early Pis, circa 2016.
When I say resistance is futile, I don't mean the future is all peaches and cream.
🌻🌻 [google.com]
(Score: 5, Funny) by driverless on Saturday September 17 2022, @10:59AM (1 child)
Yup, that's why they've rot13'd the name of the developer to protect him from repercussions.
(Score: 2) by TheGratefulNet on Sunday September 18 2022, @01:36AM
you might even be able to chmod that string and run it, directly. maybe on a DEC alpha or something.
"It is now safe to switch off your computer."
(Score: 2, Interesting) by Anonymous Coward on Friday September 16 2022, @10:34PM (1 child)
It is the unicode version of init, full of vulnerabilities...
BSD looks better every day
(Score: 2) by aafcac on Saturday September 17 2022, @05:35PM
Apart from hardware and commercial software support, FreeBSD in particular has been good for decades. I remember when I first installed it, the main things to worry about were drivers and being unable to use flash and shockwave. Most of the rest of things were pretty solid.
And now with some of the other options that are basically just BSD+GUI as an initial install, it's just that much easier. I just bought a new computer and I didn't even bother to think about whether the drivers were there or not as I haven't had driver issues in years at this point.
That being said, I don't think that sticking with the old for the sake of it is a good idea, but I do think that this business of conglomerating more and more into a single system shouldn't be done without a whole lot more care than's being done. The init system can be a bit complicated at the deep end, but it is flexible and it seems to work out rather well in most cases.
(Score: 5, Insightful) by hendrikboom on Friday September 16 2022, @11:09PM (8 children)
I run Devuan Linux. I have never had to involve myself in making an initrd. The installation procedure just installed the one that came with the distribution.
I see no reason why systemd needs to make this issue so difficult that they have to add another major new mechanism.
-- hendrik
(Score: 5, Insightful) by epitaxial on Friday September 16 2022, @11:43PM (6 children)
We didn't invent this, therefor it is old and bad.
Can't wait until they get tired of all the plaintext files in /etc and make it into a flat binary database instead. Maybe call it the registry...
(Score: 0, Spam) by antifa on Friday September 16 2022, @11:47PM (2 children)
Do we detect a systemd editorial bias on SN these days? Should we all be worried?
(Score: 2) by hendrikboom on Friday September 16 2022, @11:51PM
Know thine enemy.
(Score: 2) by JoeMerchant on Saturday September 17 2022, @02:52PM
Not just these days. The bias has been high and consistent, carrying over from the earliest days of SN and back deep into the history of the green site.
🌻🌻 [google.com]
(Score: 2) by sjames on Saturday September 17 2022, @01:45AM (2 children)
Caldera tried that years ago, but the demographic of Linux users leaned more knowledgable in those days. That was the first time I ever saw a representative try and fail to give away free install disks at a Linux enthusiasts meeting.
(Score: 2) by maxwell demon on Sunday September 18 2022, @11:13AM (1 child)
Caldera? The company that later bought and renamed itself into SCO, before acting as a Microsoft proxy against Linux?
I didn't know that they already tried to subvert Linux that early.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by sjames on Sunday September 18 2022, @03:55PM
The very same Caldera. The distro was a fork of RedHat with a few more bugs.
(Score: 3, Insightful) by JoeMerchant on Saturday September 17 2022, @02:50PM
>so difficult that they have to add another major new mechanism.
Isn't that the whole systemd M.O.? Major new mechanisms incompatible with the things they replace?
It would appear that resistance is futile, at least in mainstream markets.
🌻🌻 [google.com]
(Score: 3, Insightful) by Sjolfr on Saturday September 17 2022, @02:57AM
Systemd is not an improvement all around. Maybe it helps here and there but all it really does is shit in the bed and try to blame others for not liking shit in the bed because, well ... the shit is new. And who doesn't like new stuff? Systemd is not required for a smooth and secure system, that is usable by anything or anyone, and remains opensource.
Slackware EOA
If you like systemd then go ahead and keep it. Just don't try and force everyone in to adopting it. Convince me or leave me alone.
(Score: 3, Informative) by deimtee on Saturday September 17 2022, @08:49AM (1 child)
If it is built locally on command by signed code, surely it is still as secure as the signed code that built it. The only reason you couldn't trust it was if you didn't trust the process that built it.
If you cough while drinking cheap red wine it really cleans out your sinuses.
(Score: 2) by aafcac on Saturday September 17 2022, @03:26PM
Which is always possible for various reasons. This reminds me of that BSD backdoor that was built into the compiler so that anytime the OS was compiled, the backdoor would be included. It's also why that many eyes thing should be taken with a grain of salt as anybody reviewing the OS source code would not spot the compiler adding such instructions.
(Score: 0) by Anonymous Coward on Saturday September 17 2022, @08:13PM
I wonder what this guy's friends call him..."Zed"?