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.

  -- Bruce

FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


Reply via email to