On Fri 08 May 2020 at 22:34:30 (-0400), Default User wrote: > On 2020-05-08, David Wright (deb...@lionunicorn.co.uk) wrote: > > > But I'm surprised: which partitioner did you use, and which installer? > > David, I Originally installed Debian as Stable using the Debian 9 > netinst installer, a day or two before the initial Debian 10 release. > What timing. I used the partitioner built into the Debian installer. > I have not changed the partitioning since. After installation, I > immediately upgraded to Unstable and have been running Unstable since > then.
Thanks. I hadn't realised the d-i would do that by default. (I've never used it to actually partition a disk, but only to allow the partitioner to rewrite the LABELs and UUIDs when creating the filesystems etc during installation.) > > So it would be sensible to change them to something sane. I never > > stray beyond ASCII alphanumerics, though windows uses _ as well. > > Well, if I must change the labels to "something sane", how about: > /dev/sda1 as ROOTPART > /dev/sda2 as [not labeled] > /dev/sda5 as SWAPPART > /dev/sda6 as HOMEPART > > > # e2label for partitions 1 and 6, > > # swaplabel for 5. > > I am not conversant with either e2label or swaplabel. I will have to > check those out tomorrow. > > Anyway, are labels even needed anymore? These days everyone and > everything wants to use UUID numbers for partitions, to the seeming > exclusion of all else. Well, UUIDs are very useful for the installer because it doesn't have to worry about collisions when it makes up names on the fly. And for the person with one computer/drive, or with hundreds, that probably suffices, and LABELs may not be useful, certainly not needed. What may be of more concern to the latter group is the identity of the disks themselves, and the /dev/disk/by-id is usually of help here because it should correspond with what's printed on the disk. (But beware of external caddies, where the number printed on the container may refer to the caddy rather than the disk inside.) But LABELs give you the opportunity to logically label the filesystems with names that are human-friendly. All my disks are labelled physically (marker pen on the case top, label on the edge that's still visible when the drive is in situ) with a short name, and all the filesystem LABELs consist of the name and the partition number (which is stable, of course). This is because I have a small number of disks (my N has never exceeded the alphabet), and these disks have been swapped¹ between multiple computers (which themselves are more of a commodity to me). Your new naming scheme avoids the problem of character set, but doesn't scale above N=1, so it wouldn't work for me. For example, all my system disks contain two Debian root filesystems, typically one generation apart. And "PART" isn't useful, like calling a dog "fido animal". (BTW bear in mind that LABELs are labelling the filesystems. With GPT disks, you also get the opportunity to name the partitions themselves, which can be useful.) > > You might end up having to post to Gnome lists, so having them changed > > may save embarrassment. > > Could you please suggest an appropriate Gnome "mailing list"? Google can. Typing gnome mailing lists yields https://mail.gnome.org/mailman/listinfo as the first hit. But remember, I don't use any DE, so they're of no more than passing interest to me. > I wrote (today): > > > Maybe I am getting ahead of myself, but I wonder - what would happen if I > > just either deleted the entire /dev/disk directory, or at least some > > part(s) of it. > > > > After all, it just seems to be full of various zero-byte files. Would the > > /dev/disk directory just rebuild itself upon reboot, hopefully with > > "correct" files? > > > > No, I wouldn't do that. I'm not sure which files you think are > > > incorrect, but these files should be left to be kept up-to-date > > > by the OS, below the level of Gnome. > > : ( No need to be sad. I just don't think these links are relevant to your problem, and you don't want to lay waste your system by confusing some process deep within the OS that happens to use them. ¹ For example, faye was bought as an upgrade for a desktop PC (Pentium II), then moved to a second drive in a tower (Pentium III), then into a loaned (redundant) Dell Optiplex, and when the PSU died in March, I found a twin to replace it. Faye's two root filesystems have flipped back and forth between sarge, etch, lenny, squeeze, wheezy, jessie, stretch and buster over the years. Cheers, David.