[lfs-support] Booting LFS with systemd
bruce.dubbs at gmail.com
Thu Jul 12 10:03:01 PDT 2018
On 06/27/2018 04:42 PM, Paul Rogers wrote:
>>> I removed the need for using initrd, so now init=/bin/bash is working.
>>> Time to move forward and investigate what is causing the ABRT when
>>> starting systemd. Thanks for the pointer, it has grossed my mind before
>>> but somehow I forgot it again.
>> Yeah! Now we're on the right track! :)
>> Looking into it, the reason why initramfs is so tightly linked to systemd
>> is because:
> Correct me if I'm wrong, but I thought the only good reason for an initramfs is so a totally generic kernel could be built with every possible device driver for any unpredictable hardware out there as modules, then with discovery keep only those modules with the running kernel and dump the rest.
That's generally correct, but the initrd is also used for other things
than just drivers. It can be used for mounting a root filesystem that
is encrypted or be needed with LVM or other custom filesystems or for
finding a partition identified with a UUID.
I also use one to update the CPU firmware. We show how to create this
limited initrd at the section 'Early loading of microcode' in
But with LFS, given that 1) we know what hardware we have and that's
unlikely to change much, if at all, 2) those modules need to be
available to the system at all times, and 3) rebuilding the kernel isn't
fearsome for us, I've never seen ANY need for an initramfs and build
what's necessary as a monolithic kernel.
> If that's true, even with systemd, why is there any need to build an initramfs for a known system?
Because systemd is trying to insinuate itself into all critical
functions of Linux, It just makes the boot process more complex than it
needs to be.
More information about the lfs-support