Re: [gentoo-user] systemd and initramfs

[thegeezer]

On 08/21/2013 02:13 AM, Canek Peláez Valdés wrote:
> On Tue, Aug 20, 2013 at 7:32 PM, Walter Dnes <waltdnes@××××××××.org> wrote:
>> On Tue, Aug 20, 2013 at 01:54:26AM -0500, Canek Peláez Valdés wrote
>>> No, the kernel has a mini filesystem (doesn't matter which directory
>>> structure has inside), and it executes the init script (or binary
>>> program) in the root of the initramfs. This init program/script is the
>>> responsible for mounting the real root and other partitions, and
>>> handling control over to systemd (or OpenRC, or whatever).
>>>
>>> Dracut is able to create an initramfs (with the systemd Dracut module)
>>> that executes systemd inside the initramfs, which mounts /usr,
>>> switches to the real root, and gives control to the "real" systemd
>>> instance. At shutdown, the reverse happens: the "real" systemd
>>> surrenders control to the initramfs systemd, it umounts everything,
>>> and finish the shutdow process.
>>   A possibly stupid question from a non-user of initramfs...  why not
>> simply treat the initramfs as "the real system"?  This would avoid the
>> hand-off to a second fs at start-up, and the reverse process at
>> shutdown.
you need as much memory as your / partition if you want to do this.  it
is a good way of making a livecd if you know you are guaranteed the
memory, as once booted it no longer requires the cd (faster reads).  
this boot time ramfs is released once unmounted so even if you have a
100MB initrd you get this memory back after boot normally.
not sure how unionFS works these days, previously i was using AUFS2 as
union didn't provide enough good features for me. but the premise is to
mount ramfs as readonly and then mount real_root as writable over the
top.  again you stil have memory issues doing this; while memory is
cheap not all boards (intel atom) support huge amounts of memory.

> If I understand correctly, because it's a ramfs, as its name implies
> (it lives on your RAM). You don't want it to hold all your system,
> only the necessary parts to mount the filesystems necessary to boot.
>
>>  There would be no need to worry about keeping files synced in
>> 2 different locations, because there would only be one location.
> The worry about falling out of sync, although justified, I think it's
> a little overreacted; even for things like LVM2 and NFS, how many
> times changes the metadata or format used by different versions?
> Normal filesystems present no problems: almost all of them are
> future-proof.
It happened to me just last week with LVM, and it wasn't a metadata
issue, it was a user space program/ service loaded service running issue.
> update LVM2
> kernel remains the same
> reboot
> initramfs finds all PVS and activates VG
> main system init
> /etc/init.d/lvm2 start
> error can't read from USB PVS
> login to system with missing PVS
> /etc/init.d/lvm2 restart
> all PVS listed
> reboot several times to verify it wasn't just a stuck service, exactly
the same
> now ok but restarting a boot service manually required (!)
I updated the initramfs and rebooted and all problems went away

> And (as Allan suggested) you can (easily and automagically) regenerate
> the initramfs everytime sometimes inside it changes.
>
>>  If
>> necessary, one could use UnionFS http://en.wikipedia.org/wiki/Unionfs to
>> make the hard drive and userspace stuff all look like part of the
>> initramfs.
> No unionfs has been accepted in the mainline kernel, although several
> have been proposed. It's a hard problem, and nothing has satisfied the
> kernel devs until now.
>
> The initramfs has several advantages: it's supported directly by the
> kernel, it works the same from embedded systems to big iron servers,
> and it just works.
>
> I just installed two systems (a server and a desktop) to systemd
> directly, and Dracut just worked. And I like that now my kernels have
> *EVERYTHING* as a module (that can be compiled as module). Even the
> filesystems!
>
> Regards.