[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for enhancement [Re: Question about /etc/fstab in Squeeze]



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:

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.

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.

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.

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).


Reply to: