On Friday 16 September 2011 10:19:07 Daniel Baumann wrote:
> On 09/15/2011 05:44 PM, Yair K. wrote:
> > extlinux-update currently extracts root system by looking at /etc/fstab .
>
> ftr: it only takes it from fstab if it's not already set otherwise.
I don't think users are expected to create /etc/default/extlinux themselves
before running extlinux-update.
>
> > Problem is that / mounting can use LABEL= or UUID= arguments which are
> > unsupported by the vanilla kernel.
>
> debians kernel do support it and users should not have label or uuid in
> fstab if they cannot be used in the rest of the system, that not just
> includes mount but also initramfs.
But it can be used in what fstab is supposed to do: arguments for mounting.
When writing arguments to fstab, one doesn't necessarily expect them to show
up elsewhere, like as arguments to the kernel...
>
> > There are also more complicated cases of
> > mismatches**. This can result in an system where the default config does
> > not boot.
>
> right, but that's not fixable/detectable, we cannot symantically know
> what the users system is supposed to consist of (see below).
>
True, which is a reason to suggest the users check
/etc/default/extlinux to see if root is set right...
> > At the very least, the install should warn against the LABEL/UUID cases.
>
> i don't think so. debian uses uuid by default, that would give the user
> a warning *by default*. rather, those people that leave the debian patch
> should know what they are doing.
Right. Shows how long this Debian install is active... :-)
>
> > It may also be possible to avoid this using a different extraction method:
> i'm always interested in improving things, of course, however...
>
> > e.g. look at /proc/mounts instead (since it indicates what the kernel
> > sees
> >
> > past the userland mapping of LABEL or UUID), ignore FS=rootfs entry if
> > there, extract the first word mounting to '/', and 'readlink -f' it to
> > get the result (since it can be e.g. /dev/root symlink). One should
> > examine how this method would interact with initrds.
>
> this is not improving, as it will completely fail to work when you want
> to run extlinux-update from a chrooted system (that one e.g. has booted
> with a live system for rescue purposes) as there the *mounted* rootfs is
> not the rootfs of the target system. oiow, requireing the target system
> to be running in order to configure the bootloader is a noop as it
> introduces a chicken-egg problem once you have to rescue a system, that
> is not what the bootloaders do in debian.
>
Hmm.. I'd think that anyone doing recovery should understand to set the root.
But if that's a use-case then yea, /etc/fstab is the only method I can think
of.
> Regards,
> Daniel
Ok, I see the current behaviour is deliberate and you have good reasons for
it, but I'd still recommend suggesting the user check /etc/default/extlinux
given the unfortunately non-zero chance to get the root wrong. You could also
close this report... Thanks for responding quickly.
Yours,
Yair K.
