[gentoo-amd64] Re: Please get me straight about sysvinit vs. systemd, udev vs eudev vs mdev, virtuals and other things...

[Duncan]

Canek Peláez Valdés posted on Mon, 03 Mar 2014 11:58:18 -0600 as
excerpted:

> If you use dracut to generate your initramfs, you can get a full-fledged
> systemd inside it, so you can use the systemd in the initramfs to start
> the systemd in the real filesystem. I use it like that. Total size of
> the "bloated" initramfs? 11 megabytes. 10,660,755 bytes if you want to
> be precise. It's even reasonable for an embedded system; and I have a
> lot of stuff there, it can be trimmed to be really small, still keeping
> systemd inside.

FWIW, 9 MiB (8091136 bytes) uncompressed cpio here, dracut generated 
including btrfs but with some of the normal dracut modules omitted.  
*NOT* host-only mode as I experienced some bugs with host-only 
(apparently now fixed but I had already done my manual module setup 
so...).

I'm only running an initramfs at all because some kernels ago when I 
originally setup my (dual-device raid1 mode) btrfs rootfs, the kernel 
command-line parser couldn't properly parse rootflags=device= , 
apparently due to splitting at the wrong equal-sign, so the only way I 
could mount rootfs direct from the kernel commandline was in degraded 
mode. =:^(  I'm not sure if that has been fixed or not, but I have the 
initramfs setup and working now, so it's not so pressing to find out.  
Anyway, I expect that someday I'll be able to omit that and go back to a 
direct (initr*less) kernel commandline root=/rootflags= boot.

> Lets be clear: udev is *fully* merged into systemd. The share *code*.
> They are the *same project*. But udev can run without systemd, and that
> is not going to change. If anyone says otherwise, they are spreading
> FUD.

Like some of the other broken promises, including keeping it separate 
tarballs, because (break-reason straight from the horse's mouth) they 
don't care about source-based distros.

>> However, with the introduction of kdbus and other changes, I'm
>> wondering if they'll decide they might as well shoehorn systemd onto
>> the initramfs as well, and will then subsume the full udev binary as
>> well...
>
> Systemd is already "shoehorned" into my initramfs, and it works great,
> thank you very much. I don't understand what you mean by "subsume the
> full udev binary as well".

I suspect that after kdbus gets into wide use, they'll decide that they 
no longer need a separate udev at all, and despite promises to the 
contrary, it'll be so integrated into systemd (possibly even as a single 
binary, thus the subsumed wording) that only forks such as eudev will 
allow use of the one without the other.

Yes it'll break the promise, but they've already demonstrated they're 
willing to do that.

>> (This said as an openrc user at least for the time being... even
>> apparently one of the only people actually running the live-git
>> openrc-9999, or at least all the bugs filed on it seem to be mine.
>> I've suspected for some time that I'll eventually switch to systemd,
>> but was at least originally hoping to avoid it until it quits actively
>> blackholing nearly everything it comes across and had some reasonable
>> time to stabilize without gobbling something else up.  But when that'll
>> be... who knows?  And I'm getting an itch to try it one of these days,
>> or at least seriously read up on it with a view to _consider_ trying
>> it,
>> tho if I do it'll likely still be against my better judgment, since I
>> don't see it really stabilizing any time soon and I had originally
>> planned to wait for that.  So I guess I sort of fall in the middle in
>> this debate.)
>
> If you run OpenRC live, I think you'll be fine running systemd, even
> 209/210, which introduced so many changes I've been waiting to upgrade
> my systems.

Interesting note there:  At the last upgrade I had a dracut -rX bump and 
the udev-210 bump, but dracut had a blocker on udev-210.  I'd have 
already updated if I wasn't running an initr*, but based on the blocker 
introduction changelog wording, current dracut can't see some of the 
moved udev files (didn't pay attention to exactly what, just decided to 
mask 210 for now and get on with life, as 208 seems to be working fine 
for me ATM) and thus doesn't include them, thus the blocker until dracut 
gets updated to look in the new locations as well.

> Come to the dark side. We have cookies.

I'd normally need a block of several days in a row off in ordered to do 
the necessary research (I intend to read most of the systemd for sysadmins 
guide, plus whatever gentoo-specific stuff is available, I won't upgrade 
until I understand at least the underlying theory in enough depth to be 
sufficiently comfortable dealing with a recovery from boot-failure 
situation, tho I recognize the real comfort only comes with practice).

Since I'm doing overtime most weeks ATM, that's not likely short-term.  I 
could do some of the research ahead of time, but I have to be in the 
right mood and not too tired to grok what I'm reading.  I'm not a 20-year-
old college student any more, and I can't so easily properly integrate 
entirely new knowledge on two hours sleep as I used to, back then. =:^(

But based on previous experience once I get in this sort of impatient "I 
wonder..." mood about an anticipated switch, I usually find myself 
actually trying it within a few months, so chances are I'll either be 
switched over, or alternatively have some solid experience and concrete 
answers as to why either it or me aren't ready for that, quite likely 
before year's end, and very possibly within 1H2014.  No hurry, but that's 
what previous experience suggests for timing once I start thinking about 
it like this, none-the-less.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman