Bug#389881: RC-ness of this bug
I took the liberty of trimming the CC list since the details of a
persistent device node script would probably not interest everyone...
On Thu, March 8, 2007 12:21, Colin Watson said:
> On Thu, Mar 08, 2007 at 12:44:05AM +0100, David Härdeman wrote:
>> I've attached a patch which implements persistent device names in
>> partman by checking for devices which are mounted under /target and
>> which have a suitable link in /dev/disk/by-id/*
>
> I've attached the Ubuntu patch for the same issue; it's been deployed
> for some time and I think it's largely a cleaner approach than fixing it
> up post-facto as your patch does.
I considered doing the changes directly rather than as a post fixup, but I
opted not to for a couple of reasons:
You explicitly have to exclude some volumes, with my patch that decision
(i.e. which devices it is sane to have persistent device names for) is
left to udev.
It becomes much easier to switch between different kinds of persistent
device names with the standalone script. With the post-fix script, it
would be simple to support an argument such as "by-id" or "by-uuid" which
changed the type of symlinks that were used (then we could have that in a
priority "low" question so that the propellerheads can change it
themselves, experience so far seems to indicate that some people will
never be happy with the choice of persistent device names whether they are
based on label, uuid, id, path, etc).
At some point the future we're going to have to help users convert their
fstabs to persistent device names to avoid breakage (which I think is the
only argument that supported implementing persistent device names before
the release of Etch, although I think we'll have to live without it). One
such example will be the libata introduction (whether that will be during
the Etch -> Lenny upgrade or at some different point in time). If we have
one such standalone script, and use it both in the installer and in
upgrading older systems, it will receive much more testing.
Using "vol_id" directly rather than reading the symlinks, which would be
required if this is implemented in fstab_hd_entries, also has the
disadvantage that we'd need to duplicate the string conversions that udev
performs on the output from vol_id before it creates the device nodes.
And on a related note, one disadvantage of using "UUID=something" or
"LABEL=something" instead of /dev/disk/by-something/something is that the
former requires every script that will ever parse fstab to add code to
parse and handle "X=Y" (it would break cryptsetup and possibly other
boot-related scripts right now).
"X=Y" also makes it impossible to add new schemes without having to change
all related scripts to support the new values of "X" (we already have
by-path and by-id) while doing so is easy with the symlinks.
Phew, this came out a bit longer than expected :)
> However, I tend to agree with Steve
> that doing that at the last minute is risky; we had a fair few little
> bits and pieces around the distribution to fix up, IIRC.
I agree with Steve as well
--
David Härdeman
Reply to: