UUIDs on drives

[Marcin ‘Qrczak’ Kowalczyk]

2008/8/14 Brian McKee <brian.mckee at gmail.com>:

>> Except when resizing the swap with gparted, where /dev/sda5 does not
>> change but UUID does.
>
> I can come up with a half dozen other ways where UUID doesn't change
> but drive letter does.  What's your point?

That it would be nice to find a way to avoid the case of the default
UUID-based setup, where resizing the swap causes it to be silently
unused, and makes hibernate not working, while leaving no clue to the
user that he should change the UUID in one file known to all Unix
admins (/etc/fstab) and one obscure file that almost nobody knows
about (/etc/initramfs-tools/conf.d/resume).

> How often is swap the last partition on your drive and
> you have room to expand it so that your example is valid?

Have you used gparted? It does not have to be the last partition. A
week ago I decided to move /home contents to a separate partition, so
I booted from CD, shrank / at /dev/sda1, moved swap at /dev/sda5 down
shrinking it a little bit while I were at it, and created /home at
/dev/sda6. I have not realized for a few days that it changed UUID and
is now unused. Swap would get a new UUID again if I now decided to
make it larger while shrinking the next partition, or the converse, or
to move some space between swap and the previous partition. I assume
that the swap would keep the same UUID if I just moved it without
changing its size.

Perhaps gparted could be improved by being able to resize the swap
without changing its UUID. It copied swap contents to the new
location, very slowly (slower than ext3 contents apparently) — this
can definitely be improved if it later does simply mkswap. I don't
know if it does mkswap after copying, I just guess from the fact that
the UUID changes. Why does it copy swap contents at all? Perhaps it
should just mkswap and then write back the old UUID.

-- 
Marcin Kowalczyk
qrczak at knm.org.pl
http://qrnik.knm.org.pl/~qrczak/