UUIDs of existing swap partitions are changed
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
busybox (Ubuntu) |
Fix Released
|
High
|
Colin Watson | ||
Hardy |
Invalid
|
Undecided
|
Unassigned | ||
Intrepid |
Won't Fix
|
Undecided
|
Unassigned | ||
Jaunty |
Fix Released
|
High
|
Colin Watson | ||
partman-basicfilesystems (Ubuntu) |
Fix Released
|
High
|
Colin Watson | ||
Hardy |
Fix Released
|
High
|
Colin Watson | ||
Intrepid |
Won't Fix
|
Undecided
|
Unassigned | ||
Jaunty |
Fix Released
|
High
|
Colin Watson |
Bug Description
I installed Ubuntu Intrepid on a machine, and then made a second installation (the second time using a Hardy Live CD, I was not able to use Intrepid the second time due to bug 333584 https:/
The second installation involved repartitioning, and when I returned to my first installation, the UUID of the swap partition had been changed, which meant that swap was no longer available, and hibernate no longer worked.
The original UUID was:
441b1300-
The new UUID is:
441b13b7-
The striking similarities between these number make me think something funny is going on, which is why I bothered to post them. Assuming the hexadecimal digits correspond to a simple array of bytes, it looks like you can generate the second UUID by this algorithm:
1) create a buffer containing the first UUID
2) set pointer1 and pointer2 to position 0
3) if byte at pointer1 == 0, increment pointer1, and go to step 3
4) copy byte at pointer1 to pointer2
5) increment pointer1 and pointer2
6) go to step 3.
The other UUID on my first installation system, i.e. for the root partition, was not changed, but it did not contain a '00' in it either, so by the above process you would not expect it to change. (Also the root partition didn't change its starting cylinder, only the end cylinder, whereas the swap partition probably had to be created from scratch).
As mentioned above, this happened in Hardy, not Intrepid, and it looks like it could well be a libparted bug or something like that.
This was fixed in partman-
http://
I've backported this change to hardy-proposed:
http://
TEST CASE: Perform an installation on a blank disk, then set the UUID of the swap partition to one containing at least one zero byte; the UUID provided by the reporter of this bug will do fine. You can do that like this, assuming that the swap partition is /dev/sda5:
sudo swapoff /dev/sda5
sudo mkswap -U 441b1300-
Having done this, reboot and do another installation overwriting the previous one's root filesystem and just using the existing swap partition; you'll need to use the manual partitioner to do this properly. After rebooting, run 'sudo vol_id -u /dev/sda5' and confirm that the UUID shown is exactly that which you set previously.
REGRESSION POTENTIAL: It might be worth making sure that installations with a fresh swap partition (i.e. no UUID to preserve) keep on working.
Changed in partman-basicfilesystems (Ubuntu Hardy): | |
status: | Triaged → In Progress |
description: | updated |
summary: |
- UUID of existing swap partitions are changed + UUIDs of existing swap partitions are changed |
Great catch, thanks. It looks as if the old UUID doesn't survive being saved in a shell variable in partman- basicfilesystem s; we'll have to put it in a file instead (which in retrospect is more sensible anyway).