Re: gnome-disk-utility User Session Defaults issue
On Mon 11 May 2020 at 15:26:11 (-0400), Default User wrote:
> On Sun, May 10, 2020 at 11:20 AM David Wright <deblis@lionunicorn.co.uk> wrote:
>
> > 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.)
>
> IIRC, I may have done the install in "expert mode". During the
> partitioning phase, you can review and change the parameters for each
> partition (including the "label") before committing the partitioning
> to disk.
That's right, and it's what I do. However, I only use the top part
of each menu, and none of:
Resize the partition
Erase data on this partition
Delete the partition
but only:
Done setting up the partition
in the panel at the bottom. (I presume create partition never
shows up as there's no free space.)
> After doing a full-system imaging, using Clonezilla, I did change my
> labels like this:
> /dev/sda1 as ROOTPART
> /dev/sda2 as [not labeled]
> /dev/sda5 as SWAPPART
> /dev/sda6 as HOMEPART
>
> I used:
> # e2label for partitions 1 and 6,
> # swaplabel for 5.
> That was as easy as it gets, no problems there. Thanks.
>
> Unfortunately, that made no difference to my situation.
No, I didn't think it would. That's not where your problem lies.
> Then, since I had a full system image. I deleted the entire /dev/disk
> directory structure, and rebooted.
> Upon reboot, something in the system automatically rebuilt the entire
> /dev/disk directory structure, exactly as it had just been, except
> that there are now only the new /dev/disk/by-label zero-byte files
> corresponding to the new partition labels I had just put in. And the
> mysterious files /dev/disk/by-label'\x2f' and
> /dev/disk/by-label'\x2fhome' are gone.
They're actually links, not zero-byte files. Thus /dev/disk/by-label/'\x2f'
will have become /dev/disk/by-label/ROOTPART and should have a length
of 10 bytes, pointing as it does to ../../sda1 which is the actual
device file.
> (But did not solve my situation).
No, it just looks more conventional.
> > 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".
>
> Regarding disk naming, there is only one computer, no LAN. There is
> only one internal drive (ssd), and only one or two usb devices
> (external hard drives or thumb drives ever "attached" at any one time.
> so device naming shouldn't really be a problem, and I normally just
> let the system automatically name and manage all the devices by
> itself, and it seems to just use UUID numbers.
>
> I *could* simply change the labels to:
> /dev/sda1 as ROOT_PARTITION_1
> /dev/sda2 as [not labeled]
> /dev/sda5 as SWAP_PARTITION_1
> /dev/sda6 as HOME_PARTITION_1
In the situation you've outlined, I wouldn't bother. (I don't
know the limits on LABEL length.)
> > (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.)
>
> I have always use the traditional BIOS setup. I have never used GPT.
> Maybe in the future, but I am reluctant to try to switch my system to
> GPT now, with everything else going on. And since I run Unstable, it
> will (hopefully) be a while before I have to do a new install.
It's rather a committment when you only have one of everything.
> > Google can. Typing gnome mailing lists yields
> > https://mail.gnome.org/mailman/listinfo
> > as the first hit.
>
> Thanks, I saw that. I intend to root through that and see if any of
> the lists might apply to my situation.
>
> Bottom line:
> At this point, my computer boots and "seems" to work okay. Many
> (most?) people might say, "It works, so what's the problem?"
> I do get the point. It's just that, maybe I am autistic, but it does
> bother me when something just doesn't work the way it is SUPPOSED to.
Nobody has yet piped up with what "normality" is. I've no idea whether
what you observed originally is what's expected of systems where a
choice has never been made, and once you've made that choice, it
always shows the choice you last made. How any of the DEs do these
things? Perhaps sometime you'll happen upon some documentation that
actually explains things, and doesn't expect you to just poke around
until it "looks right".
Cheers,
David.
Reply to: