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
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.
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?
Q: What is the most annoying thing in e-mail?