Stephanie Daugherty <sdaughe...@gmail.com> wrote: >> But what's the point of having modules "at the end of [the kernel] image"? >> You can just compile-in them. > > Simple, It's to be able to turn a packaged, distribution supplied kernel into > one that will successfully boot on obscure hardware - to be able to inject > the modules needed for drive controllers, filesystems, and other boot-time > dependencies into the image. Which would be not only faster, but also less > error prone, and easier to do than a full kernel compile and all the obscure, > potentially breaking choices that go with it.
I vaguely recall from my days with SCO OpenServer that it did something similar. It didn't compile the kernel, but it did relink it when you made changes - presumably just meging the stock kernel with your drivers and with config options (such as disk cache size) configured.. What you propose sounds like something similar. Roger Leigh <rle...@codelibre.net> wrote: > The *real* goal here is something rather simpler: having both / and /usr > mounted in the initramfs. The primary reason for this is that there are > genuine problems with stuff on / needed in early boot having library > dependencies located in /usr. Libraries were moved to / on a case-by-case > basis, but it's really just the tip of the iceberg. E.g. PAM modules needing > openssl, datafiles from /usr/share, etc. It becomes a nightmare to > coordinate and manage, particularly when you also have to consider > third-party stuff out of your control. Simply ensuring that /usr is > available in the initramfs solves all these problems. ... Thanks for that explanation > See https://wiki.debian.org/ReleaseGoals/MountUsrInInitramfs > Looks like they crippled the /usr mount for the non-systemd case for no good > reason though. Well it would be easy to put it down to malice, but rationally it's more likely incompetence. Given how many people seem to have gone into "systemd or on your own" mode, it's likely that they have probably not considered the combination (or just don't care if it's broken for non-systemd users). _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
