On Tue, Aug 6, 2019 at 7:39 PM Ian Zimmerman <i...@very.loosely.org> wrote: > > On 2019-08-06 12:28, Rich Freeman wrote: > > > > Arguing against this trivial (and IMHO, elegant) solution is tilting > > > at windmills. Specially if it is for ideological reasons instead of > > > technical ones. > > > Some of the solutions I've seen tossed out in this thread are more > > complex than just building your own initramfs from scratch. > > > > An initramfs is just a userspace bootloader that runs on top of linux. > > Nobody has any problem with conventional bootloaders, and if you want > > to do anything with one of those you have to muck around in low-level > > C or assembly. > > There is a difference, and that difference is the reason I dislike > initramfs, not one of the other possible reasons you hypothesize. The > difference is that real Unix processes (not just kernel threads and not > just PID 1) survive from the initramfs stage into the "real Unix" > stage. It's like being able to trace matter back before the Big Bang.
They only persist if you allow them to. Most implementations I've seen don't leave anything behind. Typically an initramfs will unlink everything inside, kill any stray processes (if it even forks anything in the first place), and then will exec the new init from the previous init. That starts up init as PID 1 with nothing else running, and no trace of the initramfs remaining. But, sure, you can stick a fork bomb in an initramfs and have it create 10GB of junk in the ramfs as well so that you boot up a crippled system if you really want to. Unless something has changed the kernel is actually built with an empty initramfs built-in by default which loads no matter what. So, the framework of an initramfs is always there, and the only thing that changes is whether it does anything. -- Rich
