Re: Request for enhancement [Re: Question about /etc/fstab in Squeeze]
On 20101221_040215, Tom H wrote:
> On Mon, Dec 20, 2010 at 8:10 PM, Paul E Condon
> <pecondon@mesanetworks.net> wrote:
> > On 20101220_173710, Stephen Powell wrote:
> >> On Sun, 19 Dec 2010 11:44:35 -0500 (EST), Rick Thomas wrote:
> >>>
> >>> The Debian Installer insists on reformatting any swap partitions it
> >>> finds, even though that partition, specified by UUID, is probably in
> >>> use in the /etc/fstab for some other instantiation of Linux -- thus
> >>> breaking the other Linux, leaving it without a usable swap partition.
> >>>
> >>> Would it be possible to either:
> >>>
> >>> 1) have the option (default) of *not* reformatting a swap partition
> >>> or
> >>> 2) if reformatting is necessary or desired, have the option (default)
> >>> of preserving the UUID.
> >>> or
> >>> 3) using "LABEL=" instead of "UUID=" in fstab for swap partitions, if
> >>> it turns out to be easier to preserve a LABEL than a UUID.
> >
> > I think the facilities exist for an interested and concerned user to
> > write labels on all h(is|er) partitions, create a small database of
> > UUID-Label pairs for all partitions and a script that rewrites the
> > UUIDs to their prior values and rewrites /etc/fstab to use the old
> > UUIDs after they have been restored.
> >
> > My contribution to thinking about this is that UUID is crazy overkill
> > as to uniqueness of tags on partitions. Much better would be an
> > automatic writing of locally unique labels on any partitions that are
> > unlabeled. (The ones that are already labeled, are already locally
> > unique.) The locally unique labels might be the current kernal device
> > assignment, e.g. sda1, sdb5, etc. i.e. very short and very
> > mnemonic. For swap, there seems not to be a label field, but the
> > database could include however many UUIDs as there are swap
> > partitions, and the rewrite script could match UUID with partition
> > based on the size of the partition. (Does it really matter is two swap
> > partition of the same size get their UUIDs swapped during an install
> > of another OS?).
>
> I see three problems with your proposal - other than complexity:
The real complexity is in the disconnect between the internals of the
Linux kernel and the rest of the real world, IMHO. It is a complexity
which we are struggling to learn to live with.
>
> 1. If you're multibooting, swap's shared between all the installs so,
> unless there's an option to prevent mkswap from running at install
> time, and since you're mounting swap through its UUID, using labels
> for the other partitions isn't going to help. By the way, an install
> isn't broken if swap's UUID is changed. It's just that swap's not
> mounted at boot and you have to mount it post-boot - and fix the UUID
> issue either by editing fstab in the old install(s) or running "mkswap
> -U ..." in the new install and editing its fstab.
If one is NOT multibooting, it hardly matters to the user how various
partitions are identified within the internal workings of the OSs (plural).
The UUID of the swap partitions IS mentioned in the /etc/fstab of the
OS that one is booting. If that UUID in the /etc/fstab is no longer
valid, the boot of that OS is, I believe, bollixed. I think there was
a time when swap partitions were not mentioned in /etc/fstab. If they
must be mentioned now, then the several different /etc/fstab(s) of the
several different OSs must be kept consistent with the current value
of UUID on the actual partition. I think something along the lines of
my proposal could be made to work at that. I might be mistaken. I think
you might be mistaken about the nature of the problem that I am trying
to address.
>
> 2. Using kernel device names as labels' fine, until you add a disk to
> your box and the kernel device names change. You can then end up with
> sdd1 being labeled sdb1. To add a twist, imagine someone who's in that
> situation, posts to a mailing list, and confuses everyone by referring
> to sdb1 both as the device and the label.
The intent is to have block devices labeled in such a way that the
user can keep track of block devices and how their UUIDs change over
time. With this information available, the user can script a re-write
of /etc/fstab to conform to the most recent rewriting of UUIDs on
disk. It is intended to allow the user a cryptic (hidden) alternative
to the naming convention that is being promoted by some. Properly
done, the advocates of UUID need never know. But it is not a full
design and implementation, and it might be tricky to do.
>
> 3. If you use labels to mount partitions, label them with kernel
> device names, and move a disk to another box as an extra disk, you'll
> end up with multiple partitions with the same labels - and boot
> confusion. If you've ever used Fedora/RHEL/CentOS with their default
> root label, you'll know how much fun that is.
The proposal is to use labels as surrogate keys in a database of historical
values of UUIDs. So that the user can keep the different OS instances in
sync with the UUIDs currently in use on the actual partitions. Actually
I have not used Fedora/RHEL/CentOS. If you say it's bad, that's likely so.
I left the RedHat world about the time of Y2K and never looked back.
>
> 4. If you really want persistent device names, you can use
> "/dev/disk/by-id" like grub2 in its device.map (based on some
> multi-boot problems that I've helped out on online, I think that
> OpenSuse does this).
For myself, I have decided to simply give up on multiboot until the
developers have figured out a way to make it work again. Maybe it does
work, and all the complaints are the result of user gross
misunderstanding. But I don't hear murmurings of progress that
encourage me to try again, soon.
Others are complaining and I thought of this idea of developing a
cryptic database in which terse mnemonic tags are used as surrogate
key values in the database and the 'data' in the database is the UUID
previously in use. Actually, I thought of the idea some time ago when
I realized that UUID was useless to me in keeping track of how I
organize my hard drives.
IMHO, the entries in "/dev/disk/by-id" are not terse and not mnemonic
in the sense of conveying information about intended use. Mnemonic
keys seem to be the way that the human mind retrieves data.
Thanks for your comments. I think this issue could benefit from more
discussion.
--
Paul E Condon
pecondon@mesanetworks.net
Reply to: