Yes, using the real well known UUID of the booting partition to replace UUID=0
is quite possible during the boot process (egg laying time if you like). I am
not, of course, speaking of determining which hen^H^H^H UUID to boot, which is
a cock^H^H^H^H pre-boot instead of boot matter.
Please note that I'm always working towards making Ubuntu usable for the
non-geek.
It proved necessary to restate the description and I did.
Thank you.
** Changed in: ubuntu
Status: Invalid => New
** Description changed:
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.
+ The Gparted side of the story turns out to be bug #737387.
+
+ Completely restated, finally.
--- EOE ---
- What happens.
+ 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.
- 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.
+ 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.
** Description changed:
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".
+ 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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/996443
Title:
use UUID=0 for "boot partition", e.g. in fstab
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/996443/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
