Philippe,
when did you do the upgrade?
As far as I understand from Scott's comment #4:
>Migration script fixed to abort on discovering a duplicate UUID
this should not happen anymore. So if I understood it correctly, you
should not get a warning, but the migration script would detect that
there
I ran into the same problem and I have to say it cost me a major
headache.
So, right, it is entirely my fault since I had an old copy of my root partition
somewhere else...
... but since there is a change in behavior between Dapper & Edgy, it would be
nice to issue a warning when we have 2 parti
> If it's caused by you making a duplicate of a disk (with dd), and
leaving both disks in the system, then that's entirely your own fault :)
Err... that sounds somehow familiar... I guess I'll have to fill a bug
against myself ;).
Many thanks for your help.
--
Duplicate UUIDs after Edgy update
It depends what's caused your clash.
If they are NTFS filesystems, then that's a bug in the NTFS filesystem
... not sure what Microsoft's bug tracker is for that. It appears that
it only tries to avoid duplicate IDs in the same install, and doesn't
use the UUID standard for it -- we need to inves
May thanks for the explanation, now I'm starting to get it.
Is there any particular package then to blame (and to file a bug
against) for the UUID clashes?
--
Duplicate UUIDs after Edgy update
https://launchpad.net/bugs/64909
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lis
We don't generate UUIDs at all! That's a common misconception.
We just use the UUIDs already present in the filesystem, in cases where
you have a clash, there's no way you can mount-by-UUID for that device,
so yes, you have to fall back to /dev/hd*
(You could use LABEL=... but the chances are th
> Just edit /etc/fstab - the original device names are in the comment
above the UUID
I had done this from the start (see the original post), otherwise I
could have not booted up. Not only I had to edit /etc/fstab but also
/boot/grub/menu.lst, otherwise the wrong kernel would be loaded.
So from wh
Just edit /etc/fstab - the original device names are in the comment
above the UUID
--
Duplicate UUIDs after Edgy update
https://launchpad.net/bugs/64909
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Now that the fix has been released, the update process should not create
duplicate UUIDs, but how can people already affected by this bug get rid
of the duplicate UUIDs?
Is there a way to generate new UUIDs for each affected partition or
should we remove all UUIDs from menu.lst and fstab and use e
Migration script fixed to abort on discovering a duplicate UUID
** Changed in: udev (Ubuntu)
Status: Confirmed => Fix Released
--
Duplicate UUIDs after Edgy update
https://launchpad.net/bugs/64909
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/
The update script should probably ignore UUIDs for which their are
multiple resolutions
** Bug 63384 has been marked a duplicate of this bug
** Changed in: udev (Ubuntu)
Importance: Undecided => High
Assignee: (unassigned) => Scott James Remnant
Status: Unconfirmed => Confirmed
I just wanted to notice that I also had to remove the UUIDS from
/boot/grub/menu.lst, otherwise the wrong partition is mounted as root.
I attached my menu.lst as reference.
The only bootable entry is the first one (title Ubuntu, kernel
2.6.17-10-generic), the next two, which I left unmodified wit
** Changed in: update-manager (Ubuntu)
Sourcepackagename: update-manager => udev
--
Duplicate UUIDs after Edgy update
https://launchpad.net/bugs/64909
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Assigning this bug to a package.
Please note, this is just my best guess at the package this bug should
be assigned to, if it is incorrect, please feel free to correct, and if
I am consistently assigning bugs incorrectly, please contact me through
my launchpad page. I am just a member of BugSquad
14 matches
Mail list logo
