Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
>> Every time you have to reboot, it means your OS has somewhat failed you. > i don't think that at all. remember that each person can > have different preferences, requirements and expectations. That's why I wrote "have to". Of course, if you choose to reboot it, it's not you OS's fault. > system to begin with but i hate the idea that it is doing > nothing at all useful just sitting there if i'm not going > to be using it any time soon. IIUC in your case you could just as well suspend/hibernate instead of shutting down and that would solve the "just sitting there" problem without having to reboot: the reboot is your choice and you're indeed perfectly entitled to that preference. Stefan
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Wed 05 Feb 2020 at 22:54:33 (-0500), Michael Stone wrote: > On Wed, Feb 05, 2020 at 07:33:38PM -0600, David Wright wrote: > > On Wed 05 Feb 2020 at 15:59:27 (-0500), Michael Stone wrote: > > > On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote: > > > > On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote: > > > > > On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote: > > > > > > While I'm sure this can be managed by explicitly setting UUIDs, I've > > > > > > found it much more pleasant to manage explicit names (I personally > > > > > > prefer LVM names over filesystem labels, but filesystem labels work > > > > > > well > > > > > > for those filesystems I don't put under LVM). Not only I can > > > > > > pronounce > > > > > > them and they carry meaning, but they tend to be much more visible > > > > > > (and > > > > > > hence easier to manipulate). > > > > > > > > > > I dislike using names becaues it's *much* more common to find name > > > > > collisions than UUID collisions. (E.g., a bunch of disks with > > > > > filesystems all labeled with easy to remember names like "root" or > > > > > "home".) Reboot with a couple of those in your system on a > > > > > label-oriented configuration and you may have a very bad day. > > > > > > > > Rather a strawman argument there. There's no reason not to choose > > > > sensible LABELs, unlike the examples you've given there, which fail > > > > for at least two reasons: they're unlikely to be unique and they're > > > > too overloaded with meaning. > > > > > > What does "sensible" mean in this context? On a static system all of > > > this is a complete waste of time because nothing changes. If you start > > > upgrading disks, using external drives, moving things around, etc., it > > > may very well be that the same "sensible" label applies to a > > > filesystem found on more than one disk. > > > > To make that argument, you have to put scare quotes round sensible > > because common sense would lead you to use different LABELs for > > partitions that you intend to distinguish by LABEL. To do otherwise > > would be like suggesting that two teams who play in red should do > > so without a change of shirt for one team. > > You seem to just be stuck in this mindset where you think that it's > somehow weird or unusual to name a root filesystem "root" instead of > "kumquat" or some other meaningless string. I opined that it's unwise to LABEL a filesystem "root" if you're using LABELs as the determining name. It's not weird, and I have no idea whether it's usual or not. The reason I called it unwise is that it's limiting. For example, if I make it a habit to call the root filesystem on this laptop "root", what should I LABEL the other root filesystem as? Is it sensible to have two fstab files like: LABEL=root / ext4 errors=remount-ro 0 1 LABEL=previous /media/previous ext4 errors=remount-ro 0 1 and LABEL=previous / ext4 errors=remount-ro 0 1 LABEL=root /media/previous ext4 errors=remount-ro 0 1 That's what I mean about excessive overloading of meanings. > I don't really have a > response to that except to note that in my experience your naming > conventions are an outlier and that it's a waste of time making > assertions about what people should use as names instead of simply > acknowledging what people actually use as names. I have very little knowledge of what people are using as names, if anything, unless they post them here. That doesn't prevent my having an opinion, nor anybody else. How I spend my time is up to me. I thought I had limited my assertions to pointing out that your arguments appeared to be directed against things *not* stated, like "labels prevent problems". > > > Can problems be avoided > > > through careful attention to detail? > > > > I'd call the LABEL problem's solution blindingly obvious. Ironically, > > one has to be more careful with *certain* operations when using UUIDs > > because one is less likely to spot a duplication. I'm thinking of, > > say, copying partitions. > > Again, asserting that using labels in a fashion that avoids potential > collisions is "blindlingly obvious" implies that the problems I've > seen people have with label-based schemes must mean that they're too > ignorant to do the "obviously" correct thing. That seems presumptuous > at least. Pointing out a pitfall to someone doesn't mean that you're calling them ignorant, particularly in a forum like this where you don't have any idea who "they" are. > OTOH, following best practices when copying raw partitions (including > changing the UUID) seems to be something to be glossed over > (presumably because only changing the label in that exact case is > "obvious"?) No, I'm not trying to gloss over it. What I would say is that if you have a partition LABELled sex and you clone it, and then you find yourself typing # mount LABEL=sex /media/myclone you're more likely to notice the
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
Stefan Monnier wrote: >>> PS: The only problem with LVM names is that Linux doesn't let you >>> rename a volume group while it's active (at least last time I tried), >>> which makes it painful to rename the volume group in which lives your >>> root partition. >> How painful is it to dd a live cd, boot from it and rename? > > Very. It's called "downtime". > Every time you have to reboot, it means your OS has somewhat failed you. i don't think that at all. remember that each person can have different preferences, requirements and expectations. i reboot my computer once or twice a day depending upon what i'm doing. it takes only a few seconds. at the end of the day i turn it off since i don't like wasting electricity. it is a fairly low power consuming system to begin with but i hate the idea that it is doing nothing at all useful just sitting there if i'm not going to be using it any time soon. since it does shut down and start up quickly enough it isn't an issue. songbird
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Wed, Feb 05, 2020 at 07:33:38PM -0600, David Wright wrote: On Wed 05 Feb 2020 at 15:59:27 (-0500), Michael Stone wrote: On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote: > On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote: > > On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote: > > > While I'm sure this can be managed by explicitly setting UUIDs, I've > > > found it much more pleasant to manage explicit names (I personally > > > prefer LVM names over filesystem labels, but filesystem labels work well > > > for those filesystems I don't put under LVM). Not only I can pronounce > > > them and they carry meaning, but they tend to be much more visible (and > > > hence easier to manipulate). > > > > I dislike using names becaues it's *much* more common to find name > > collisions than UUID collisions. (E.g., a bunch of disks with > > filesystems all labeled with easy to remember names like "root" or > > "home".) Reboot with a couple of those in your system on a > > label-oriented configuration and you may have a very bad day. > > Rather a strawman argument there. There's no reason not to choose > sensible LABELs, unlike the examples you've given there, which fail > for at least two reasons: they're unlikely to be unique and they're > too overloaded with meaning. What does "sensible" mean in this context? On a static system all of this is a complete waste of time because nothing changes. If you start upgrading disks, using external drives, moving things around, etc., it may very well be that the same "sensible" label applies to a filesystem found on more than one disk. To make that argument, you have to put scare quotes round sensible because common sense would lead you to use different LABELs for partitions that you intend to distinguish by LABEL. To do otherwise would be like suggesting that two teams who play in red should do so without a change of shirt for one team. You seem to just be stuck in this mindset where you think that it's somehow weird or unusual to name a root filesystem "root" instead of "kumquat" or some other meaningless string. I don't really have a response to that except to note that in my experience your naming conventions are an outlier and that it's a waste of time making assertions about what people should use as names instead of simply acknowledging what people actually use as names. Can problems be avoided through careful attention to detail? I'd call the LABEL problem's solution blindingly obvious. Ironically, one has to be more careful with *certain* operations when using UUIDs because one is less likely to spot a duplication. I'm thinking of, say, copying partitions. Again, asserting that using labels in a fashion that avoids potential collisions is "blindlingly obvious" implies that the problems I've seen people have with label-based schemes must mean that they're too ignorant to do the "obviously" correct thing. That seems presumptuous at least. OTOH, following best practices when copying raw partitions (including changing the UUID) seems to be something to be glossed over (presumably because only changing the label in that exact case is "obvious"?) Stefan and I were posting why we like names. The uniqueness of UUIDs is a given. (Ironically, it's in the name.) Perhaps (although the fact that they won't be unique if you copy the raw filesystem is a recurring theme) but the argument at the top of the thread seems to be that they somehow change unexpectedly and can't be relied upon--which would seem to be an even more serious problem (if it existed). And it's a different argument from the one you appeared to make, Yes, I argued against the proposition that actually started the thread, which seemed to be that UUIDs are somehow unreliable--in particular, as compared to labels. For some reason talking about why that isn't actually the case makes you start talking about straw men, as though you either didn't read or couldn't remember posts from a couple of days ago. which was that you dislike using names because other people (presumably) misuse them. And you've explained that anybody who uses them other than in the (extremely idiosyncratic) manner you prescribe is just doing them wrong and its their own fault if there are problems because they must be dumb. I'm glad we've managed to so succinctly summarize each other's position. If I were to summarize my own position it would simply be that I encourage people to be aware of potential issues that arise when labels collide, and that UUIDs are a (not unreliable) alternative that may work better in some circumstances. OK, perhaps you run a helpdesk. The closest I come to that is this mailing list. Just because you personally use a feature in a particular way doesn't mean everyone else does. Sometimes a standard install of an OS can default to labeling schemes that cause conflicts if you put the drive from one machine into another
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Wed 05 Feb 2020 at 16:47:13 (-0500), Greg Wooledge wrote: > On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote: > > I don't suppose either of us will meet a UUID collision in our > > lifetimes, and it's obviously a sensible scheme to use where there > > are large numbers of commoditised objects to name. > > Usually a UUID collision is a result of a subtle mistake, like cloning > a disk and then trying to mount a file system by UUID while the clone > is still attached. At least, that's the first scenario I can think of. There are versions of UUIDs that aren't quite what they seem; IOW there are predictable ones. There are means of placing strings into positions where UUIDs are expected, eg tune2fs -U. There's a vanishingly small probability that a human will spot a deliberately altered UUID. My assumption in writing the above was that we are honest brokers, generating UUIDs in a random manner. In the absence of a RNG of any quality whatsoever, I think the cryptographic vulnerability of the system will exceed the likelihood of UUID collisions occurring. I have no information to back that up :) https://lists.debian.org/debian-user/2020/02/msg5.html Cheers, David.
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Wed 05 Feb 2020 at 15:59:27 (-0500), Michael Stone wrote: > On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote: > > On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote: > > > On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote: > > > > While I'm sure this can be managed by explicitly setting UUIDs, I've > > > > found it much more pleasant to manage explicit names (I personally > > > > prefer LVM names over filesystem labels, but filesystem labels work well > > > > for those filesystems I don't put under LVM). Not only I can pronounce > > > > them and they carry meaning, but they tend to be much more visible (and > > > > hence easier to manipulate). > > > > > > I dislike using names becaues it's *much* more common to find name > > > collisions than UUID collisions. (E.g., a bunch of disks with > > > filesystems all labeled with easy to remember names like "root" or > > > "home".) Reboot with a couple of those in your system on a > > > label-oriented configuration and you may have a very bad day. > > > > Rather a strawman argument there. There's no reason not to choose > > sensible LABELs, unlike the examples you've given there, which fail > > for at least two reasons: they're unlikely to be unique and they're > > too overloaded with meaning. > > What does "sensible" mean in this context? On a static system all of > this is a complete waste of time because nothing changes. If you start > upgrading disks, using external drives, moving things around, etc., it > may very well be that the same "sensible" label applies to a > filesystem found on more than one disk. To make that argument, you have to put scare quotes round sensible because common sense would lead you to use different LABELs for partitions that you intend to distinguish by LABEL. To do otherwise would be like suggesting that two teams who play in red should do so without a change of shirt for one team. > Can problems be avoided > through careful attention to detail? I'd call the LABEL problem's solution blindingly obvious. Ironically, one has to be more careful with *certain* operations when using UUIDs because one is less likely to spot a duplication. I'm thinking of, say, copying partitions. > Sure--but the same is true of > many other systems. I submit that labels are not inherently "better", > but merely a matter of preference. I haven't said one is better than the other, but have just pointed out why I like LABELs, which you said you dislike. > If you like them, great! Have fun! > If giving every thumbdrive its own label and mountpoint makes you > happy, go for it. I generally expect thumbdrives to be consumables, > mount them at generic points, and call it a day. YMMV. And I supported you there, but you snipped it; I wrote of UUIDs: "it's obviously a sensible scheme to use where there are large numbers of commoditised objects to name." > And FWIW, those aren't "strawman arguments", those are based on things > I've found in the real world. Stefan and I were posting why we like names. The uniqueness of UUIDs is a given. (Ironically, it's in the name.) And it's a different argument from the one you appeared to make, which was that you dislike using names because other people (presumably) misuse them. OK, perhaps you run a helpdesk. > Just because you personally use a > feature in a particular way doesn't mean everyone else does. Sometimes > a standard install of an OS can default to labeling schemes that cause > conflicts if you put the drive from one machine into another > machine--so this really isn't something I'm making up out of thin air > that never happens in real life. IIRC you're describing Debian in the early days, when partitions were configured only by their kernel names, rather like some people prefer their network interfaces to be named. > > > LVM is > > > more resistant to that as long as you keep the vg names unique. (Call > > > everything vg0 and you're back to having a bad day.) > > > > It seems that saying "keep the vg names unique" is not very different > > from saying to keep filesystem LABELs unique. > > It's pretty much exactly the same. If you have multiple logical > entities addressed by the same name, you might not get the entity you > expected to get. This isn't always obvious to someone starting out who > reads something like "labels prevent problems" and hasn't yet run into > cases where that isn't true and thus hasn't adopted strategies to > avoid those problems. That's another strawman argument: I haven't suggested that, you bring it up, then knock it down: isn't that the definition of a strawman argument? LABELs are a tool, as are UUIDs. I like both. UUIDs are great for creating a nonce name; so good, we wonder how we got by without them. But LABELs have some advantages (like brevity, memorability, meaning) which persuades some people to use them without abusing them. Where I might part company with Stefan is in adopting names with too much meaning,
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Tue, 04 Feb 2020 22:19:25 -0500 Stefan Monnier wrote: > > How painful is it to dd a live cd, boot from it and rename? > > Very. It's called "downtime". > Every time you have to reboot, it means your OS has somewhat failed > you. > > > Stefan > You are absolutely right!
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
> Usually a UUID collision is a result of a subtle mistake, like cloning > a disk and then trying to mount a file system by UUID while the clone > is still attached. At least, that's the first scenario I can think of. I wouldn't call it a "subtle mistake". Instead it's what *always* happens when I make a clone: I always mount it right afterwards to perform some checks and/or tweaks, and I never have any reason to unmount the original before doing that. Of course, that doesn't bother me: the clone's LV has a different name, so whether the UUID is the same or not doesn't affect it. Stefan
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote: > I don't suppose either of us will meet a UUID collision in our > lifetimes, and it's obviously a sensible scheme to use where there > are large numbers of commoditised objects to name. Usually a UUID collision is a result of a subtle mistake, like cloning a disk and then trying to mount a file system by UUID while the clone is still attached. At least, that's the first scenario I can think of.
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote: On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote: On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote: > While I'm sure this can be managed by explicitly setting UUIDs, I've > found it much more pleasant to manage explicit names (I personally > prefer LVM names over filesystem labels, but filesystem labels work well > for those filesystems I don't put under LVM). Not only I can pronounce > them and they carry meaning, but they tend to be much more visible (and > hence easier to manipulate). I dislike using names becaues it's *much* more common to find name collisions than UUID collisions. (E.g., a bunch of disks with filesystems all labeled with easy to remember names like "root" or "home".) Reboot with a couple of those in your system on a label-oriented configuration and you may have a very bad day. Rather a strawman argument there. There's no reason not to choose sensible LABELs, unlike the examples you've given there, which fail for at least two reasons: they're unlikely to be unique and they're too overloaded with meaning. What does "sensible" mean in this context? On a static system all of this is a complete waste of time because nothing changes. If you start upgrading disks, using external drives, moving things around, etc., it may very well be that the same "sensible" label applies to a filesystem found on more than one disk. Can problems be avoided through careful attention to detail? Sure--but the same is true of many other systems. I submit that labels are not inherently "better", but merely a matter of preference. If you like them, great! Have fun! If giving every thumbdrive its own label and mountpoint makes you happy, go for it. I generally expect thumbdrives to be consumables, mount them at generic points, and call it a day. YMMV. And FWIW, those aren't "strawman arguments", those are based on things I've found in the real world. Just because you personally use a feature in a particular way doesn't mean everyone else does. Sometimes a standard install of an OS can default to labeling schemes that cause conflicts if you put the drive from one machine into another machine--so this really isn't something I'm making up out of thin air that never happens in real life. LVM is more resistant to that as long as you keep the vg names unique. (Call everything vg0 and you're back to having a bad day.) It seems that saying "keep the vg names unique" is not very different from saying to keep filesystem LABELs unique. It's pretty much exactly the same. If you have multiple logical entities addressed by the same name, you might not get the entity you expected to get. This isn't always obvious to someone starting out who reads something like "labels prevent problems" and hasn't yet run into cases where that isn't true and thus hasn't adopted strategies to avoid those problems.
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote: > On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote: > > > > Me too, so I usually label the permanent stuff at least. UUID's can and > > > > will change for no detectable reason. > > > For those reading along or finding this in search results: no, filesystem > > > UUIDs don't change for no detectable reason. Don't implement anything > > > based > > > on this theory. > > > > What he meant is that filesystem UUIDs are (re)created automatically > > based on a heuristic of what it means for a filesystem to be "the same". > > You understand that he didn't actually say that, right? This seems > like your own personal bugaboo instead. Yes, what he wrote is elaborated in postings like https://lists.debian.org/debian-user/2018/01/msg00787.html https://lists.debian.org/debian-user/2018/01/msg00791.html > > While I'm sure this can be managed by explicitly setting UUIDs, I've > > found it much more pleasant to manage explicit names (I personally > > prefer LVM names over filesystem labels, but filesystem labels work well > > for those filesystems I don't put under LVM). Not only I can pronounce > > them and they carry meaning, but they tend to be much more visible (and > > hence easier to manipulate). > > I dislike using names becaues it's *much* more common to find name > collisions than UUID collisions. (E.g., a bunch of disks with > filesystems all labeled with easy to remember names like "root" or > "home".) Reboot with a couple of those in your system on a > label-oriented configuration and you may have a very bad day. Rather a strawman argument there. There's no reason not to choose sensible LABELs, unlike the examples you've given there, which fail for at least two reasons: they're unlikely to be unique and they're too overloaded with meaning. I don't suppose either of us will meet a UUID collision in our lifetimes, and it's obviously a sensible scheme to use where there are large numbers of commoditised objects to name. Look at cars. For practical purposes, a VIN is a (U)UID: great for computers, but totally impractical for human use, hence licence plates, whose numbers are chosen to be unique only within a juridiction. My jurisdiction is Home, so every host gets a short memorable name, and each disk, stick and card does too. Their filesystem LABELs relate to those names. All are marked with those names, and I couldn't manage that with UUIDs. None of the names carry any functional meaning, because functions necessarily change. Other people will choose LABELs in different ways, but the fact that some people will choose unwisely does not condemn the method. > LVM is > more resistant to that as long as you keep the vg names unique. (Call > everything vg0 and you're back to having a bad day.) It seems that saying "keep the vg names unique" is not very different from saying to keep filesystem LABELs unique. > On Tue, Feb 04, 2020 at 10:19:25PM -0500, Stefan Monnier wrote: > > > > PS: The only problem with LVM names is that Linux doesn't let you > > > > rename a volume group while it's active (at least last time I tried), > > > > which makes it painful to rename the volume group in which lives your > > > > root partition. > > > How painful is it to dd a live cd, boot from it and rename? > > > > Very. It's called "downtime". > > Every time you have to reboot, it means your OS has somewhat failed you. > > I'm trying to think of a reason to rename the root partition that > doesn't involve downtime and coming up empty. I don't know what the implications of LVM are because I've not used them. Consequently I don't know why Stefan wrote 'The root partition is always called "root"', or whether "called" even refers here to a filesystem LABEL or something else. Some of the posts seem to conflate the terms partition, VG, LV and LVM. Cheers, David.
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
>>What he meant is that filesystem UUIDs are (re)created automatically >>based on a heuristic of what it means for a filesystem to be "the same". > You understand that he didn't actually say that, right? This seems like your > own personal bugaboo instead. Definitely. > I dislike using names becaues it's *much* more common to find name > collisions than UUID collisions. (E.g., a bunch of disks with > filesystems all labeled with easy to remember names like "root" or "home".) Yes, that happens frequently with filesystem labels, which is why I much prefer LVM names. > LVM is more resistant to that as long as you keep the vg names unique. Indeed, my VG names are always unique and descriptive. > I'm trying to think of a reason to rename the root partition that doesn't > involve downtime and coming up empty. The root partition is always called "root", which is why I was talking about renaming the VGs rather the LVs. Yes, it usually involves downtime for some other related reason, but every time I've had to change a VG's name it would have been *much* more convenient to do it while the system is up (e.g. would have shortened the downtime and the administration time noticeably). Renaming the root VG is really the only case where I find LVM names to be a point of friction. Stefan
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote: Me too, so I usually label the permanent stuff at least. UUID's can and will change for no detectable reason. For those reading along or finding this in search results: no, filesystem UUIDs don't change for no detectable reason. Don't implement anything based on this theory. What he meant is that filesystem UUIDs are (re)created automatically based on a heuristic of what it means for a filesystem to be "the same". You understand that he didn't actually say that, right? This seems like your own personal bugaboo instead. While I'm sure this can be managed by explicitly setting UUIDs, I've found it much more pleasant to manage explicit names (I personally prefer LVM names over filesystem labels, but filesystem labels work well for those filesystems I don't put under LVM). Not only I can pronounce them and they carry meaning, but they tend to be much more visible (and hence easier to manipulate). I dislike using names becaues it's *much* more common to find name collisions than UUID collisions. (E.g., a bunch of disks with filesystems all labeled with easy to remember names like "root" or "home".) Reboot with a couple of those in your system on a label-oriented configuration and you may have a very bad day. LVM is more resistant to that as long as you keep the vg names unique. (Call everything vg0 and you're back to having a bad day.) On Tue, Feb 04, 2020 at 10:19:25PM -0500, Stefan Monnier wrote: PS: The only problem with LVM names is that Linux doesn't let you rename a volume group while it's active (at least last time I tried), which makes it painful to rename the volume group in which lives your root partition. How painful is it to dd a live cd, boot from it and rename? Very. It's called "downtime". Every time you have to reboot, it means your OS has somewhat failed you. I'm trying to think of a reason to rename the root partition that doesn't involve downtime and coming up empty.
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
>>> Me too, so I usually label the permanent stuff at least. UUID's can and >>> will change for no detectable reason. >> For those reading along or finding this in search results: no, filesystem >> UUIDs don't change for no detectable reason. Don't implement anything based >> on this theory. > > What he meant is that filesystem UUIDs are (re)created automatically Your "analysis" appears to be more like what you want to mean than what Gene was meaning. > based on a heuristic of what it means for a filesystem to be "the same". > This heuristic can be wrong in both directions: sometimes you delete and >create a new filesystem which is supposed to "be" the same filesystem as This seems like an eminently detectable reason for a UUID change to me. -- "J'ai pour me guérir du jugement des autres toute la distance qui me sépare de moi." Antonin Artaud
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
>> PS: The only problem with LVM names is that Linux doesn't let you >> rename a volume group while it's active (at least last time I tried), >> which makes it painful to rename the volume group in which lives your >> root partition. > How painful is it to dd a live cd, boot from it and rename? Very. It's called "downtime". Every time you have to reboot, it means your OS has somewhat failed you. Stefan
Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
> PS: The only problem with LVM names is that Linux doesn't let you > rename a volume group while it's active (at least last time I tried), > which makes it painful to rename the volume group in which lives your > root partition. > How painful is it to dd a live cd, boot from it and rename? 3 minutes of pain, if that is what you want to call it?
Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
>> Me too, so I usually label the permanent stuff at least. UUID's can and >> will change for no detectable reason. > For those reading along or finding this in search results: no, filesystem > UUIDs don't change for no detectable reason. Don't implement anything based > on this theory. What he meant is that filesystem UUIDs are (re)created automatically based on a heuristic of what it means for a filesystem to be "the same". This heuristic can be wrong in both directions: sometimes you delete and create a new filesystem which is supposed to "be" the same filesystem as before (but gets a new UUID), and other times you copy a filesystem so as to get "another one" (but it keeps its UUID). While I'm sure this can be managed by explicitly setting UUIDs, I've found it much more pleasant to manage explicit names (I personally prefer LVM names over filesystem labels, but filesystem labels work well for those filesystems I don't put under LVM). Not only I can pronounce them and they carry meaning, but they tend to be much more visible (and hence easier to manipulate). Stefan PS: The only problem with LVM names is that Linux doesn't let you rename a volume group while it's active (at least last time I tried), which makes it painful to rename the volume group in which lives your root partition.
