| 2012-05-08 09:36:34 |
André Pirard |
bug |
|
|
added bug |
| 2012-05-08 09:37:25 |
André Pirard |
summary |
use UUID=0 |
use UUID=0 for "this partition" |
|
| 2012-05-08 09:41:00 |
André Pirard |
description |
Any version, any release and probably any distribution.
What happens.
When GParted makes a backup of a partition, two partitions with the same UUID exist, which is contrary to principle.
This produces a lot of confusion if both are visible, such as one being mounted but the other one is locked.
If the backup UUID is changed, you get (for example) an unbootable backup system because fstab mounts the wrong UUID.
What should happen.
If UUID=0 meant "the UUID of the partition in which this reference is located" there would be no need to change the fstab.
If GParted made a backup with a different UUID (by default, optionally same or user specified UUID such as similar to previous one), there would no longer be any UUID concern.
What should result.
One more easy step towards a system as or more easy to use as ... other ones. |
Any version, any release and probably any distribution.
What happens.
When GParted makes a backup of a partition, two partitions with the same UUID exist, which is contrary to principle.
This produces a lot of confusion if both are visible, such as one being mounted but the other one is locked.
If the backup UUID is changed, you get (for example) an unbootable backup system because fstab mounts the wrong UUID.
What should happen.
If UUID=0 meant "the UUID of the partition in which this reference is located" there would be no need to change the fstab (mounting UUID=0).
If GParted made a backup with a different UUID (by default, optionally same or user specified UUID such as similar to previous one), there would no longer be any UUID concern.
What should result.
One more easy step towards a system as or more easy to use as ... other ones. |
|
| 2012-05-08 09:43:36 |
Fabio Marconi |
affects |
ubuntu |
gparted (Ubuntu) |
|
| 2012-05-08 11:17:31 |
André Pirard |
summary |
use UUID=0 for "this partition" |
use UUID=0 for "this partition", e.g. in fstab |
|
| 2012-05-08 15:08:43 |
Phillip Susi |
marked as duplicate |
|
737387 |
|
| 2012-05-08 15:32:11 |
André Pirard |
removed duplicate marker |
737387 |
|
|
| 2012-05-08 15:41:19 |
André Pirard |
description |
Any version, any release and probably any distribution.
What happens.
When GParted makes a backup of a partition, two partitions with the same UUID exist, which is contrary to principle.
This produces a lot of confusion if both are visible, such as one being mounted but the other one is locked.
If the backup UUID is changed, you get (for example) an unbootable backup system because fstab mounts the wrong UUID.
What should happen.
If UUID=0 meant "the UUID of the partition in which this reference is located" there would be no need to change the fstab (mounting UUID=0).
If GParted made a backup with a different UUID (by default, optionally same or user specified UUID such as similar to previous one), there would no longer be any UUID concern.
What should result.
One more easy step towards a system as or more easy to use as ... other ones. |
Any version, any release and probably any distribution.
Update:
Please please please read the title of this report and see that this report is not (only) related to Gparted but to UUID=0 being an alias of the UUID of the partition in which that reference appears.
The Gparted side of the story turns out to be bug #737387.
--- EOE ---
What happens.
When GParted makes a backup of a partition, two partitions with the same UUID exist, which is contrary to principle.
This produces a lot of confusion if both are visible, such as one being mounted but the other one is locked.
If the backup UUID is changed, you get (for example) an unbootable backup system because fstab mounts the wrong UUID.
What should happen.
If UUID=0 meant "the UUID of the partition in which this reference is located" there would be no need to change the fstab (mounting UUID=0).
If GParted made a backup with a different UUID (by default, optionally same or user specified UUID such as similar to previous one), there would no longer be any UUID concern.
What should result.
One more easy step towards a system as or more easy to use as ... other ones. |
|
| 2012-05-08 15:43:28 |
André Pirard |
affects |
gparted (Ubuntu) |
ubuntu |
|
| 2012-05-08 16:09:18 |
Phillip Susi |
ubuntu: status |
New |
Invalid |
|
| 2012-05-11 09:51:17 |
André Pirard |
ubuntu: status |
Invalid |
New |
|
| 2012-05-11 09:53:28 |
André Pirard |
description |
Any version, any release and probably any distribution.
Update:
Please please please read the title of this report and see that this report is not (only) related to Gparted but to UUID=0 being an alias of the UUID of the partition in which that reference appears.
The Gparted side of the story turns out to be bug #737387.
--- EOE ---
What happens.
When GParted makes a backup of a partition, two partitions with the same UUID exist, which is contrary to principle.
This produces a lot of confusion if both are visible, such as one being mounted but the other one is locked.
If the backup UUID is changed, you get (for example) an unbootable backup system because fstab mounts the wrong UUID.
What should happen.
If UUID=0 meant "the UUID of the partition in which this reference is located" there would be no need to change the fstab (mounting UUID=0).
If GParted made a backup with a different UUID (by default, optionally same or user specified UUID such as similar to previous one), there would no longer be any UUID concern.
What should result.
One more easy step towards a system as or more easy to use as ... other ones. |
Any version, any release and probably any distribution.
Update:
Please please please read the title of this report and see that this report is not (only) related to Gparted but to UUID=0 being an alias of the UUID of the partition in which that reference appears.
The Gparted side of the story turns out to be bug #737387.
Completely restated, finally.
--- EOE ---
When the UUID of a partition is changed, e.g. during backup, UUID=... references to it become invalid. Remembering that, finding and editing these references is not easy to do for the novice, let alone geek. But in most cases those references (mostly in fstab) are to the UUID of the partition they're in.
Hence, if coding UUID=0 meant "the partition we're in", "this partition", "myself" ... by convention, there would rarely be any need to change any UUID references in a boot partition. Copying such a partition with UUID rename would keep the partition bootable instead of dead. Moreover, any references made by a boot partition to other partitions are usually meant to remain unchanged when the boot partition is "renamed".
Note: UUID=1 could also mean "any swap partition" or "the sole swap partition" on this disk.
In consequence, with UUID=0/1 and if Gparted changing the UUID by default (which it does not (1)) when copying a boot partition, making a safety backup of one's system disk would be a seamless process instead of a pile of warnings and surprises.
(1) By default, Gparted creates partitions with the same UUID and, among other system's anomalies, traps itself into believing that one partition is locked when another one should be locked instead. |
|
| 2012-05-11 09:57:47 |
André Pirard |
description |
Any version, any release and probably any distribution.
Update:
Please please please read the title of this report and see that this report is not (only) related to Gparted but to UUID=0 being an alias of the UUID of the partition in which that reference appears.
The Gparted side of the story turns out to be bug #737387.
Completely restated, finally.
--- EOE ---
When the UUID of a partition is changed, e.g. during backup, UUID=... references to it become invalid. Remembering that, finding and editing these references is not easy to do for the novice, let alone geek. But in most cases those references (mostly in fstab) are to the UUID of the partition they're in.
Hence, if coding UUID=0 meant "the partition we're in", "this partition", "myself" ... by convention, there would rarely be any need to change any UUID references in a boot partition. Copying such a partition with UUID rename would keep the partition bootable instead of dead. Moreover, any references made by a boot partition to other partitions are usually meant to remain unchanged when the boot partition is "renamed".
Note: UUID=1 could also mean "any swap partition" or "the sole swap partition" on this disk.
In consequence, with UUID=0/1 and if Gparted changing the UUID by default (which it does not (1)) when copying a boot partition, making a safety backup of one's system disk would be a seamless process instead of a pile of warnings and surprises.
(1) By default, Gparted creates partitions with the same UUID and, among other system's anomalies, traps itself into believing that one partition is locked when another one should be locked instead. |
Any version, any release and probably any distribution.
Update:
Please please please read the title of this report and see that this report is not (only) related to Gparted but to UUID=0 being an alias of the UUID of the partition in which that reference appears.
The Gparted side of the story turns out to be bug #737387.
Completely restated, finally.
--- EOE ---
When the UUID of a partition is changed, e.g. during backup, UUID=... references to it become invalid. Remembering that, finding and editing these references is not easy to do for the novice, let alone geek. But in most cases those references (mostly in fstab) are to the UUID of the partition they're in.
Hence, if coding UUID=0 meant "the booting partition", "the partition we're in", "this partition", "myself" ... by convention, there would rarely be any need to change any UUID references in a boot partition. Copying such a partition with UUID rename would keep the partition bootable instead of dead. Moreover, any references made by a boot partition to other partitions are usually meant to remain unchanged when the boot partition is "renamed".
Note: UUID=1 could also mean "any swap partition" or "the sole swap partition" on this disk.
In consequence, with UUID=0/1 and if Gparted changing the UUID by default (which it does not (1)) when copying a boot partition, making a safety backup of one's system disk would be a seamless process instead of a pile of warnings and surprises.
(1) By default, Gparted creates partitions with the same UUID and, among other system's anomalies, traps itself into believing that one partition is locked when another one should be locked instead. |
|
| 2012-05-11 10:04:59 |
André Pirard |
summary |
use UUID=0 for "this partition", e.g. in fstab |
use UUID=0 for "boot partition", e.g. in fstab |
|
| 2012-05-11 15:11:26 |
Phillip Susi |
ubuntu: status |
New |
Invalid |
|
