2014-11-18 16:42 GMT+01:00 Phillip Susi <ps...@ubuntu.com>: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/18/2014 1:16 AM, Chris Murphy wrote: > > If fstab specifies rootfs as UUID, and there are two volumes with > > the same UUID, it’s now ambiguous which one at boot time is the > > intended rootfs. It’s no different than the days of /dev/sdXY where > > X would change designations between boots = ambiguity and why we > > went to UUID. > > He already said he has NOT rebooted, so there is no way that the > snapshot has actually been mounted, even if it were UUID confusion. >
That's right. Anyway, I've built a system to reproduce the bug. You can download the image and run it with KVM or other virtualization technology. Instructions are straightforward – if you start the VM, you'll know what to do, and you'll see what I was talking about. http://undead.megabrutal.com/kvm-reproduce-1391429.img.xz Download size: 113 MB; Unpacked image size: 2 GB. > > So we kinda need a way to distinguish derivative volumes. Maybe > > XFS and ext4 could easily change the volume UUID, but my vague > > recollection is this is difficult on Btrfs? So that led me to the > > idea of a way to create an on-the-fly (but consistent) “virtual > > volume UUID” maybe based on a hash of both the LVM LV and fs > > volume UUID. > > When using LVM, you should be referring to the volume by the LVM name > rather than UUID. LVM names are stable, and don't have the duplicate > uuid problem. > I use LVM names to identify volumes. I initially suspected it's an UUID confusion, because I thought grub-probe looks for the volume by UUID. But now I think the problem is nothing to do with UUIDs. Probably I should have looked deeper into the problem before I hypothesized. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
