From: Tom H on 13 Mar 2010 10:00 >> I believe a UUID is generated when the partition is "formatted", either >> with >> mkfs or mkswap. > I confirm - just tried shrinking and growing back an extfs. UUID is left > untouched (as expected); that Mint article is BS or just obsolete. I have never come across the problem described by the Mint link. The closest is having swap's UUID change when installing a 2nd/3rd distrib on the same HD. Someone said earlier "I can't imagine any case where an filesystem UUID change "by the face", I think this is not possible if you didn't execute any filesystem command to do it." and cannot but +1 the comment because the UUID is held in a partition's superblock. -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/6d4219cc1003130653j51248695h184ee5aa14cf01b(a)mail.gmail.com
From: Paul E Condon on 13 Mar 2010 11:10 On 20100313_095320, Tom H wrote: > >> I believe a UUID is generated when the partition is "formatted", either > >> with > >> mkfs or mkswap. > > > I confirm - just tried shrinking and growing back an extfs. UUID is left > > untouched (as expected); that Mint article is BS or just obsolete. > > I have never come across the problem described by the Mint link. I have seen a UUID change in a way that disrupts my work: When I install a 2nd/3rd distrib on a HD, I have made it a practice to set up fstab so the existing distrib are mounted automatically. Repeated use leads to all functioning distrib to be crosslinked. But when a distrib must be reinstalled because something drasticly wrong happened, or whatever, access to that replacement distrib in all the older distrib is broken because the UUID of the partition is changed. This is not a killer objection for me. But it is a use case expample that belies some broad claims about UUIDs. If there were a place on every partition where a UUID of the partition could be recorded, and if the partitioning software could be trained to preserve that record whenever the partition is simply wiped in preparation for a reinstall, then ... maybe this use case would behave more to my liking. But I am aware that there are a lot of individual requirements for partition identifiers, so I hesitate to advocate this proposal in this most simple form. As I say, I understand enough about the scheme that I think I can live with it in its current form. Also. There seems not to be a standard algorithm for computing UUID bit strings. Different developer/users of UUID ideas seem to be free to choose what algorithm and what input data they use to get their UUIDs. So, the actual behavior of UUID technology in Debian may change over time. Future versions of Debian may silently change to address old problems (and to introduce new problems). > > The closest is having swap's UUID change when installing a 2nd/3rd > distrib on the same HD. > > Someone said earlier > > "I can't imagine any case where an filesystem UUID change "by the > face", I think this is not possible if you didn't execute any > filesystem command to do it." > > and cannot but +1 the comment because the UUID is held in a > partition's superblock. > My original post has generated a lot of very interesting discussion. UUIDs are no longer so mysterious. I think that there is more work to be done, but I have no good ideas to pursue and I have reached my attention span limit. I don't want to post with a subject line "Solved", but it is true that I want to stop discussing this. Thanks to all. -- Paul E Condon pecondon(a)mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100313160128.GB2170(a)big.lan.gnu
From: Tom H on 13 Mar 2010 11:20 > When I install a 2nd/3rd distrib on a HD, I have made it a practice > to set up fstab so the existing distrib are mounted automatically. > Repeated use leads to all functioning distrib to be crosslinked. > But when a distrib must be reinstalled because something drasticly > wrong happened, or whatever, access to that replacement distrib in > all the older distrib is broken because the UUID of the partition > is changed. You could make a note of the UUID before the re-install then re-apply it to the partition with tune2fs -U <uuid> /dev/sdaX -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/6d4219cc1003130813w71928edchaf1c308015fd9928(a)mail.gmail.com
From: Paul E Condon on 13 Mar 2010 13:40 On 20100313_111314, Tom H wrote: > > When I install a 2nd/3rd distrib on a HD, I have made it a practice > > to set up fstab so the existing distrib are mounted automatically. > > Repeated use leads to all functioning distrib to be crosslinked. > > But when a distrib must be reinstalled because something drasticly > > wrong happened, or whatever, access to that replacement distrib in > > all the older distrib is broken because the UUID of the partition > > is changed. > > You could make a note of the UUID before the re-install then re-apply > it to the partition with > tune2fs -U <uuid> /dev/sdaX I keep learning stuff. I think this, which is verifiably true, contradicts some other things that I remember (and had thought were verifiably true). Thanks for this knowledge which is definitely new to me. It will take me sometime to integrate it into my belief system, but thanks. -- Paul E Condon pecondon(a)mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100313183152.GC2170(a)big.lan.gnu
From: Camaleón on 13 Mar 2010 14:20 On Sat, 13 Mar 2010 00:53:35 -0800, Freeman wrote: > On Fri, Mar 12, 2010 at 08:16:48PM +0000, Camaleón wrote: (...) >> Well, that said I like Lenny still uses the old scheme "/dev/sdx". At >> least if it changes, I still understand it better than the new udev >> naming :-) >> >> > I've been changing to labels with squeeze. The up side: it is a hard > designation and can be made unique. > > The collisions part is unclear to me. If one plugs into USB a drive from > another machine, won't that just be listed in /dev by sdx, at which > point it can have its fstab edited? USB devices usually auto-fall under /media and do not need to be added in /etc/fstab, unless you want to use them as permanent mount points. But if the USB hard drive already has a label, and that label shares its name with another mounted device, it will generate a "collision". Nothing serious, I guess that when you plugged the USB drive it would have told you something like "mount point '/media/mylabel' already exists" and aborts. I mean, the success of mounting a device "by label" will depend on whether the user knows before hand if the device: a) Already has a label defined b) What is that label to prevent collisions with other devices So, in order to avoid that, distribution installers defaults to either UUID and/or ID for use it in /etc/fstab which tends to be a more secure approach. > I typo-ed the label for my root partition on my last fstab update but it > mounted anyway as rootfs in mtab. So I put rootfs in fstab and it has > been working. :-/ Strange behaviour, indeed. Maybe you could had find more information about that under /var/log/dmesg :-? Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/pan.2010.03.13.19.19.12(a)gmail.com
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: pen drive without format and can not find it Next: Incredibly useful Firefox addon: Hyperwords |