On Saturday 13 November 2021 15:44:35 Andy Smith wrote: > On Sat, Nov 13, 2021 at 01:14:56PM -0500, Gene Heskett wrote: > > I wouldn't argue near as loud if it hadn't already been proven to me > > that what you call filesystem UUID's are volatile. > > What I and everyone else call filesystem UUIDs do not change unless > you force them to change, because they only exist inside the > filesystem. It seems far more likely that you are confused, in the > same way you have been confused throughout this whole thread. If > you've got something outside of your control scribbling in your > filesystems then that is a very serious bug. > > I think you are and have been confused between different things that > have UUIDs. Filesystems, MD arrays, GPT partitions and lots of other > things all can have UUIDs. > > In this thread you have repeatedly shown that you don't understand > the difference between those UUIDs and have tried to use them in > your fstab, so it seems far more likely that any prior issue you > have had with filesystem UUIDs is going to be down to similar > confusions and not some serious bug. > > > It happened when I moved a drive from sda to sdd several years > > ago. > > Barring some strange bug that only you have ever seen, it is not > possible, so I believe you are mistaken. This is going to be > another one of those things where you swear software behaved in > incredibly improbable ways, you are asked to reproduce it and can't. > I will gladly eat humble pie if you can reproduce this one and show > us. I will be excited for the bug report we can make together, > because that would be a real doozy. > > Like that time you said that having an IPv6 address configured > prevented you from compiling some software, a claim you kept > repeating in multiple unrelated threads any time IPv6 was mentioned, > until you were asked to reproduce the issue and couldn't. > > We all make mistakes from time to time but filling the archives with > bold assertions like "filesystem UUIDs are volatile" I think would > come under the category of an extraordinary claim that would require > extraordinary proof. > > > Getting ready to switch to the next version of debian because I > > always install to a new drive, which I installed wheezy on, then > > put the old drive back in on a different sata port to get my data > > copied to the new drive. No boot but single. It took me 3 days to > > build an fstab that mounted everything by Labels. When I finally > > had a working system again, I ran blkid again, and with the same > > drives except the boot drive re-arranged, every UUID blkid > > reported was different from what it was in the now commented out > > lines in fstab. > > "blkid" also reports things called PARTUUIDs, so I think this is > explained by it doing that, and you being confused. Nothing you have > described could cause a filesystem UUID to change. > > > The downside of now using mkfs to install a label, I didn't use it > > then but something else, but mkfs also wipes the drive, so in this > > case I hadn't moved anything to it, so I lost nothing reformating to > > install the label. The utility, if it wasn't journal-something or > > other I don't recall, but it could label a partition that already > > had content, without losing that data. > > You have not once in this thread asked how to label an existing > filesystem without re-creating it. Although you don't even need to > ask us, because: > > https://lmgtfy.app/?q=how+do+I+label+an+ext4+filesystem > > So instead of doing a trivial search, or even asking, you just > assume that it can't be done and have a nice old rant. Weird flex, > but OK. > > The above is for ext* filesystems; other filesystems have their own > tools for changing the label. A similar search will find them, too. > > People have been putting and changing labels on filesystem in Linux > for decades. It's well understood and well documented. If you look. > First you complain that fs UUIDs are volatile, now you complain that > fs labelling is hard without even doing the most basic research. At > least these topics have been adequately covered, so unwary searchers > are unlikely to stumble upon this thread in future and be led down a > very long garden path by the bizarre claims within. > > > Its simply too big a risk to do UUID mounts with something that > > important. > > For you, maybe, but I guarantee this is down to some confusion on > your part. Confusion is still a valid reason to shy away from > something, especially when there is an alternate approach (mount by > label) that works much better for you, but blaming it on > mysteriously changing UUIDs and/or the mdadm man pages is not > helping. > > Andy Wordwrap off. So which of these various UUID's is actually valid in an fstab?
root@coyote:etc$ blkid /dev/sda1: LABEL="stretchboot" UUID="06aa3215-a6a6-4fbb-86ca-186c47e1334c" TYPE="ext4" PARTUUID="6603f591-01" /dev/sda2: UUID="8b675a91-5aa5-401b-bf50-d8afc3e8115a" TYPE="swap" PARTUUID="6603f591-02" /dev/sda3: LABEL="stretchvar" UUID="ee491e5c-7394-434f-b50a-f4354f6c9869" TYPE="ext4" PARTUUID="6603f591-03" /dev/sda5: UUID="0e698024-1cf3-4dbc-812d-10552c01caab" TYPE="ext4" PARTUUID="6603f591-05" /dev/sdb1: LABEL="adumps" UUID="4982ee4c-58c4-4d2b-b9d5-69344c3cb090" TYPE="ext4" PARTUUID="3bb7fc74-01" /dev/sdc1: LABEL="amandatapes-2T" UUID="3b6848c1-7b09-43be-a7aa-ae63d82f5f26" TYPE="ext4" PARTUUID="5997197d-01" /dev/sde1: UUID="3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb" UUID_SUB="9cd6d3b5-6d13-8d46-a7e6-6f9847846d24" LABEL="coyote:0" TYPE="linux_raid_member" /dev/sde2: UUID="ddb6ffa2-e068-b701-f316-cc5f83938a13" UUID_SUB="64609477-3041-8169-feab-73809dd337c6" LABEL="coyote:1" TYPE="linux_raid_member" /dev/sdg1: UUID="3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb" UUID_SUB="38030389-42bc-f933-3945-8b22db9de87e" LABEL="coyote:0" TYPE="linux_raid_member" /dev/sdg2: UUID="ddb6ffa2-e068-b701-f316-cc5f83938a13" UUID_SUB="dfd980a3-a155-4f50-f82d-02cbbe289891" LABEL="coyote:1" TYPE="linux_raid_member" /dev/sdh1: UUID="3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb" UUID_SUB="ef0ffd69-5ce4-9629-ccd4-81b1f6431571" LABEL="coyote:0" TYPE="linux_raid_member" /dev/sdh2: UUID="ddb6ffa2-e068-b701-f316-cc5f83938a13" UUID_SUB="b4d25ae6-fc68-1ce5-a08b-92df22c9030b" LABEL="coyote:1" TYPE="linux_raid_member" /dev/sdf1: UUID="3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb" UUID_SUB="baca3a30-e9a5-f5e1-57e1-c197252c3500" LABEL="coyote:0" TYPE="linux_raid_member" /dev/sdf2: UUID="ddb6ffa2-e068-b701-f316-cc5f83938a13" UUID_SUB="ff02585f-cafc-2d7a-3780-6cba4b48b0cb" LABEL="coyote:1" TYPE="linux_raid_member" /dev/md1: LABEL="snapshot" UUID="733718b2-e7f8-4b00-a390-264e5c73c453" TYPE="ext4" /dev/md0: LABEL="home2" UUID="708320b3-10af-4c15-b5b1-a9ff7be06d99" TYPE="ext4" there are UUID's, PARTUUID's and UUID_SUB's in the above blkid output. Thanks Andy. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>
