Re: [gentoo-dev] udev and /usr

[Joost Roeleveld <joost@antarean.org>]

On Thursday, September 15, 2011 04:27:35 PM Rich Freeman wrote:
> On Thu, Sep 15, 2011 at 4:03 PM, Joost Roeleveld <joost@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