On Thursday, September 15, 2011 04:27:35 PM Rich Freeman wrote: > On Thu, Sep 15, 2011 at 4:03 PM, Joost Roeleveld <jo...@antarean.org> wrote: > > On Thursday, September 15, 2011 09:27:06 AM Zac Medico wrote: > > > It should be similar to how sys-apps/v86d is used for uvesafb > > > support. > > > It installs /usr/share/v86d/initramfs and when you configure your > > > kernel, you set CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" > > > in > > > order to have in included in your kernel image. > > > > Will this be set somewhere globally to the initramfs automatically? > > And doesn't this mean that a new kernel will need to be build just to > > satisfy > > this? > > > > I'm trying to think of how best to avoid users who are not aware to get > > caught > > with non-booting systems. > > > > Wouldn't automatic inclusion into grub.conf be a better approach? Not > > sure if > > grub.conf can handle a "global" setting for initramfs. > > Well, the only way to set a kernel config parameter is to rebuild the > kernel. There might be some way to extract the built-in initramfs (every > kernel has one) and replace it with the new one without rebuilding it, but I > doubt most users would prefer that we mount /boot and start modifying their > kernel images.
I wasn't actually talking about changing kernels, but was wondering if grub.conf has some option for a "global" initramfs. I couldn't find anything in the manpage. > Changes to grub.conf will only be properly merged if /boot is mounted, if > grub is installed (don't laugh - I checked and since my system was migrated > so many times I don't actually have the package installed any longer), and > the user actually merges the changes in. Fiddling with grub.conf isn't > exactly risk-free either. I know, which is why I was asking for a "default" option for the initrd/module part. > I think something like this is best handled via news. And perhaps also an announcement on gentoo-user. I think a lot of users are subscribed to there. > Note also that depending on your definition of "broken" the separate /usr > situation is already broken. It will probably steadily become more broken > over time, so when it stops booting altogether for any particular user might > happen anytime from a year ago to never. In what way is it broken? I've only seen comments about where some udev-rules seem to expect /usr to be present when run and udev not properly handling these cases. (I know this is the very short version) If an installation works and none of the udev-rules depend on /usr (or /var, ....) then a seperate /usr should not be considered "broken". My desktop is up-to-date and none of my udev-rules even have a "RUN+=" part. Only my server has these for Xen-devices and these aren't run until "xendomains" starts and this is quite late in the boot-sequence. All my machines have /usr on LVM. -- Joost
