Michael Mol posted on Wed, 18 Jul 2012 15:18:35 -0400 as excerpted: > On Wed, Jul 18, 2012 at 3:05 PM, Rich Freeman <[email protected]> wrote: >> On Wed, Jul 18, 2012 at 2:53 PM, Michael Mol <[email protected]> wrote: >>> AFAIK, neither genkernel nor dracut were expected to get tied to the >>> Gentoo update process. Has that changed? >> >> We don't even update kernels as part of the regular update process, let >> alone initramfs systems. >> >> In general you update them together. >> >> The only issue I could see is if problems arise if you have a different >> version of udev in your initramfs than on your system. I don't know if >> that actually causes problems. For the most part after the system is >> booted the initramfs is done its job. > > The most widely touted benefit I've heard for initramfs is its > capability to ease system recovery in case, e.g. a critical filesystem > refuses to mount. With recovery roles come recovery tools, which quickly > extends network-aware tools and a security attack surface. > > Hence why I tend to feel that if an initramfs is going to become the > go-to solution for bootstrapping userland, it's important to consider > the difficulties of keeping the packed tools up-to-date; it's not just a > bootstrap tool, it's also the first recovery option a sysadmin faces.
As others have stated, that might be /a/ widely touted benefit, but the reason for initr* being there in the first place, is to solve the otherwise chicken/egg issue of having the tools/modules necessary to mount a filesystem, /on/ that filesystem, since now they're on the initr* as well, and that is maintained with the kernel. But meanwhile, recovery /is/ /a/ widely touted benefit, which really presents its own problem, in the form of a choice: a) automatically update the initr* and get the security benefits but risk breaking the recovery tools when they break with an update to the main system, OR: b) don't automatically update the initr* in ordered to keep a known/ tested-working first recovery mechanism, but at the cost of potentially unfixed security-vulns in the initr* that were already fixed on the main system. Of course (b) is the usual case on an initr* (unless it's one-size-fits- all automatically updated by the distro), due to static linking. So security is already taking second priority to a known-working recovery mechanism, and updating the initr* on a user-configured/managed distro like gentoo pretty much must remain in that user-admin domain. There's simply no way around it, without going the one-size-fits-all-distro- configured route, which by accepted definition isn't palatable to gentooers, or they'd be using something else. So IMO, updating the initr* is and must remain user-admin domain, not something gentoo really can worry about, other than to the extent of making those updates as easy and stupid-mistake-proof as can reasonably be done while still placing the responsibility of actually configuring and maintaining the initr* with the user-admin. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
