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
