Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #222293 > unrolled thread

gnome-disk-utility User Session Defaults issue

Back to article view | Back to linux.debian.user

Contents

  gnome-disk-utility User Session Defaults issue Default User <hunguponcontent@gmail.com> - 2020-05-08 02:50 +0200
    Re: gnome-disk-utility User Session Defaults issue David Wright <deblis@lionunicorn.co.uk> - 2020-05-08 04:50 +0200
      Re: gnome-disk-utility User Session Defaults issue Default User <hunguponcontent@gmail.com> - 2020-05-08 16:10 +0200
        Re: gnome-disk-utility User Session Defaults issue Cindy Sue Causey <butterflybytes@gmail.com> - 2020-05-08 18:20 +0200
        Re: gnome-disk-utility User Session Defaults issue Tixy <tixy@yxit.co.uk> - 2020-05-08 18:40 +0200
          Re: gnome-disk-utility User Session Defaults issue Default User <hunguponcontent@gmail.com> - 2020-05-08 22:50 +0200
            Re: gnome-disk-utility User Session Defaults issue David Wright <deblis@lionunicorn.co.uk> - 2020-05-09 01:20 +0200
              Re: gnome-disk-utility User Session Defaults issue Default User <hunguponcontent@gmail.com> - 2020-05-09 04:40 +0200
                Re: gnome-disk-utility User Session Defaults issue Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-09 07:20 +0200
                Re: gnome-disk-utility User Session Defaults issue David Wright <deblis@lionunicorn.co.uk> - 2020-05-10 17:30 +0200
                  Re: gnome-disk-utility User Session Defaults issue Default User <hunguponcontent@gmail.com> - 2020-05-11 21:30 +0200
                    Re: gnome-disk-utility User Session Defaults issue David Wright <deblis@lionunicorn.co.uk> - 2020-05-11 23:10 +0200

#222293 — gnome-disk-utility User Session Defaults issue

Hi.

I am using Debian Unstable (64-bit), Cinnamon desktop environment.
-----------------------------------------------------------------------
lsblk output:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 111.8G  0 disk
├─sda1   8:1    0    28G  0 part /
├─sda2   8:2    0     1K  0 part
├─sda5   8:5    0   7.9G  0 part [SWAP]
└─sda6   8:6    0    76G  0 part /home
sr0     11:0    1  1024M  0 rom

---------------------------------------------------------------------
blkid output:

/dev/sda1: LABEL="/" UUID="1af49d67-02c1-4601-b020-ca70e78e6da8"
BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cff3c8f8-01"
/dev/sda5: UUID="93082123-a386-41ce-8067-fafbf5892691" TYPE="swap"
PARTUUID="cff3c8f8-05"
/dev/sda6: LABEL="/home" UUID="561e0ea6-46ef-41bd-9a51-f840352d918c"
BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cff3c8f8-06"

----------------------------------------------------------------------
/etc/fstab contents:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system>                            <mount point> <type>
<options>          <dump> <pass>
#
# / was on /dev/sda1 during installation
UUID=1af49d67-02c1-4601-b020-ca70e78e6da8  /              ext4
errors=remount-ro  0      1
#
# /home was on /dev/sda6 during installation
UUID=561e0ea6-46ef-41bd-9a51-f840352d918c  /home          ext4
defaults           0      2
#
# swap was on /dev/sda5 during installation
UUID=93082123-a386-41ce-8067-fafbf5892691  none           swap
sw                 0      0
#
/dev/sr0                                   /media/cdrom0  udf,iso9660
user,noauto        0      0

------------------------------------------------------------------------

I have gnome-disk-utility (a.k.a. the "Disks" program) installed.

In "Disks", for each partition (/, swap, or home), on the primary
(only) ssd, if the partition is highlighted and the "gears" icon is
clicked, a menu pops up with one of the choices being "Edit Mount
Options".  When "Edit Mount Options is clicked, a window titled "Mount
Options" appears.

Near the top of the mount options window is a slide switch labeled
"User Session Defaults".  If you rest the mouse pointer on the slide
switch, a popup text box says "Switch off User Session Defaults to
manage mount point and mount options for the device.  The options
correspond to an entry in the /etc/fstab file."

Until recently, for all partitions on the main ssd, the slide switch
was "on" by default, with the slide background colored blue, and all
of the text in the fields for the options in the window were "greyed
out".

But now, for all partitions on the main ssd, the slide switch is "off"
by default, the slide background is colored grey, and the text in the
options fields is black, not grey, and is editable.

Now if I slide the switches to "on", and click "OK" to save the
changes (requires authentication by user sudo password), the computer
will not reboot after shutdown.  Using a rescue disk to inspect
/etc/fstab on the main ssd reveals that changing the User Session
Defaults switches for each partition has caused the corresponding
entries to be deleted from /etc/fstab.

Replacing /etc/fstab with a backed up good copy allows the computer to
boot as normal.

BUT, restoring the backed up /etc/fstab causes the "Disks" slider
switches to change back to "off" by themselves! No matter what I try,
I can not get /etc/fstab and the User Session Defaults switches to not
change each other.  Very strange . . .

Note 1: all of this behavior affects only the partitions on the main
ssd.  It does not affect the "Disks" Edit Mount Options windows for
the dvd drive or any external usb drives that are plugged in. For any
drive other than the main ssd, the User Session Defaults switches
default to "on", as expected.

Note 2: in the Edit Mount Options window for each partition on the
main ssd, the 'Identify As" field lists a UUID entry (ie,
UUID="93082123-a386-41ce-8067-fafbf5892691 for the swap partition).
But
for any partition or drive other than on the main ssd, the 'Identify
As" field lists either a device name entry (ie, /dev/sr0 for the dvd
drive), or a /dev/disk/by-id entry (ie,
usb-HP_v125w_8EIYHFB131ZYW5I4-0:0-part1, when an external usb device
is plugged in.)

Therefore I wonder if this has something to do with entries in
/dev/disks/*, but that is just speculation. And since I know nothing
about /dev/disks/* and how it works, I am somewhat reluctant to do
surgery there without knowing what I am doing.

-----------------------------------------------------------------

Here are the /dev/disk/* entries, with no external devices attached:

/dev/disk/by-id:
total 0
drwxr-xr-x 2 root root 280 May  7 20:22 ./
drwxr-xr-x 7 root root 140 May  7 15:06 ../
lrwxrwxrwx 1 root root   9 May  7 15:06
ata-HL-DT-ST_DVD+_-RW_GU90N_KZSZ73G1632 -> ../../sr0
lrwxrwxrwx 1 root root   9 May  7 15:06
ata-KINGSTON_SV300S37A120G_50026B77490A7CE8 -> ../../sda
lrwxrwxrwx 1 root root  10 May  7 15:06
ata-KINGSTON_SV300S37A120G_50026B77490A7CE8-part1 -> ../../sda1
lrwxrwxrwx 1 root root  10 May  7 15:06
ata-KINGSTON_SV300S37A120G_50026B77490A7CE8-part2 -> ../../sda2
lrwxrwxrwx 1 root root  10 May  7 15:06
ata-KINGSTON_SV300S37A120G_50026B77490A7CE8-part5 -> ../../sda5
lrwxrwxrwx 1 root root  10 May  7 15:06
ata-KINGSTON_SV300S37A120G_50026B77490A7CE8-part6 -> ../../sda6
lrwxrwxrwx 1 root root   9 May  7 15:06 wwn-0x5001480000000000 -> ../../sr0
lrwxrwxrwx 1 root root   9 May  7 15:06 wwn-0x50026b77490a7ce8 -> ../../sda
lrwxrwxrwx 1 root root  10 May  7 15:06 wwn-0x50026b77490a7ce8-part1
-> ../../sda1
lrwxrwxrwx 1 root root  10 May  7 15:06 wwn-0x50026b77490a7ce8-part2
-> ../../sda2
lrwxrwxrwx 1 root root  10 May  7 15:06 wwn-0x50026b77490a7ce8-part5
-> ../../sda5
lrwxrwxrwx 1 root root  10 May  7 15:06 wwn-0x50026b77490a7ce8-part6
-> ../../sda6

/dev/disk/by-label:
total 0
drwxr-xr-x 2 root root  80 May  7 20:22  ./
drwxr-xr-x 7 root root 140 May  7 15:06  ../
lrwxrwxrwx 1 root root  10 May  7 15:06 '\x2f' -> ../../sda1
lrwxrwxrwx 1 root root  10 May  7 15:06 '\x2fhome' -> ../../sda6

/dev/disk/by-partuuid:
total 0
drwxr-xr-x 2 root root 120 May  7 20:22 ./
drwxr-xr-x 7 root root 140 May  7 15:06 ../
lrwxrwxrwx 1 root root  10 May  7 15:06 cff3c8f8-01 -> ../../sda1
lrwxrwxrwx 1 root root  10 May  7 15:06 cff3c8f8-02 -> ../../sda2
lrwxrwxrwx 1 root root  10 May  7 15:06 cff3c8f8-05 -> ../../sda5
lrwxrwxrwx 1 root root  10 May  7 15:06 cff3c8f8-06 -> ../../sda6

/dev/disk/by-path:
total 0
drwxr-xr-x 2 root root 160 May  7 20:22 ./
drwxr-xr-x 7 root root 140 May  7 15:06 ../
lrwxrwxrwx 1 root root   9 May  7 15:06 pci-0000:00:1f.2-ata-1 -> ../../sda
lrwxrwxrwx 1 root root  10 May  7 15:06 pci-0000:00:1f.2-ata-1-part1
-> ../../sda1
lrwxrwxrwx 1 root root  10 May  7 15:06 pci-0000:00:1f.2-ata-1-part2
-> ../../sda2
lrwxrwxrwx 1 root root  10 May  7 15:06 pci-0000:00:1f.2-ata-1-part5
-> ../../sda5
lrwxrwxrwx 1 root root  10 May  7 15:06 pci-0000:00:1f.2-ata-1-part6
-> ../../sda6
lrwxrwxrwx 1 root root   9 May  7 15:06 pci-0000:00:1f.2-ata-2 -> ../../sr0

/dev/disk/by-uuid:
total 0
drwxr-xr-x 2 root root 100 May  7 20:22 ./
drwxr-xr-x 7 root root 140 May  7 15:06 ../
lrwxrwxrwx 1 root root  10 May  7 15:06
1af49d67-02c1-4601-b020-ca70e78e6da8 -> ../../sda1
lrwxrwxrwx 1 root root  10 May  7 15:06
561e0ea6-46ef-41bd-9a51-f840352d918c -> ../../sda6
lrwxrwxrwx 1 root root  10 May  7 15:06
93082123-a386-41ce-8067-fafbf5892691 -> ../../sda5

-----------------------------------------------------------------

So, I would just like for the old behavior to return:

1)  The computer boots, without issue.

3)  User Session Defaults will show in the "Disks" program as turned
"on" (and stay that way)!

3)  A good /etc/fstab that doesn't change by itself when User Session
Defaults is turned on or off!

Thanks in advance for any help on this!

[toc] | [next] | [standalone]

#222294

Not using a DE, I might not be much help, sorry.
But you aroused my curiosity…

On Thu 07 May 2020 at 20:46:32 (-0400), Default User wrote:

> blkid output:
> 
> /dev/sda1: LABEL="/" UUID="1af49d67-02c1-4601-b020-ca70e78e6da8"
> BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cff3c8f8-01"
> /dev/sda5: UUID="93082123-a386-41ce-8067-fafbf5892691" TYPE="swap"
> PARTUUID="cff3c8f8-05"
> /dev/sda6: LABEL="/home" UUID="561e0ea6-46ef-41bd-9a51-f840352d918c"
> BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="cff3c8f8-06"

I thought for a minute that you'd (mis)typed that in, but then
realised from /dev/disk that those LABELs are real. Did you
choose them, or were they chosen for you?

> # /etc/fstab: static file system information.
[…]
> UUID=1af49d67-02c1-4601-b020-ca70e78e6da8  /              ext4
> errors=remount-ro  0      1
> #
> UUID=561e0ea6-46ef-41bd-9a51-f840352d918c  /home          ext4
> defaults           0      2
> #
> UUID=93082123-a386-41ce-8067-fafbf5892691  none           swap
> sw                 0      0
> #
> /dev/sr0                                   /media/cdrom0  udf,iso9660
> user,noauto        0      0

[…]

> Note 2: in the Edit Mount Options window for each partition on the
> main ssd, the 'Identify As" field lists a UUID entry (ie,
> UUID="93082123-a386-41ce-8067-fafbf5892691 for the swap partition).
> But
> for any partition or drive other than on the main ssd, the 'Identify
> As" field lists either a device name entry (ie, /dev/sr0 for the dvd
> drive), or a /dev/disk/by-id entry (ie,
> usb-HP_v125w_8EIYHFB131ZYW5I4-0:0-part1, when an external usb device
> is plugged in.)
> 
> Therefore I wonder if this has something to do with entries in
> /dev/disks/*, but that is just speculation. And since I know nothing
> about /dev/disks/* and how it works, I am somewhat reluctant to do
> surgery there without knowing what I am doing.

Well, that seems logical enough. The 'Identify As" field corresponds
with the name of the filesystem in your /etc/fstab file, just so long
as the "UUID=" is part of the field's value, which you say it is.

Using the /dev/disk/by-id entry instead for an external device may be
designed to avoid the sort of problem shown by your sda2, which has
no UUID. (I would have thought that …/by-path is the least likely to
be absent or non-unique.)

> /dev/disk/by-uuid:
> total 0
> drwxr-xr-x 2 root root 100 May  7 20:22 ./
> drwxr-xr-x 7 root root 140 May  7 15:06 ../
> lrwxrwxrwx 1 root root  10 May  7 15:06
> 1af49d67-02c1-4601-b020-ca70e78e6da8 -> ../../sda1
> lrwxrwxrwx 1 root root  10 May  7 15:06
> 561e0ea6-46ef-41bd-9a51-f840352d918c -> ../../sda6
> lrwxrwxrwx 1 root root  10 May  7 15:06
> 93082123-a386-41ce-8067-fafbf5892691 -> ../../sda5

[…]

> 3)  A good /etc/fstab that doesn't change by itself when User Session
> Defaults is turned on or off!

As an emergency measure, you could   chattr +i /etc/fstab   to prevent
anything changing it, while you investigate. You might even get some
error messages occasionally, when some program tries to change it.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#222295

[Multipart message — attachments visible in raw view] — view raw

Hi David.

Yes, I made the labels for the  partitions during the original installation:

/dev/sda1 = /  (primary partition)
/dev/sda2 =     (extended partition)
/dev/sda5 = swap (logical partition)
/dev/sda6 = /home (logical partition)

So /dev/sda2 has no label, as it is just an extended partition, which
"holds" logical partitions:
/dev/sda5
/dev/sda6

[toc] | [prev] | [next] | [standalone]

#222299

On 5/8/20, Default User <hunguponcontent@gmail.com> wrote:
> Yes, I made the labels for the  partitions during the original
> installation:
>
> /dev/sda1 = /  (primary partition)
> /dev/sda2 =     (extended partition)
> /dev/sda5 = swap (logical partition)
> /dev/sda6 = /home (logical partition)
>
> So /dev/sda2 has no label, as it is just an extended partition, which
> "holds" logical partitions:
> /dev/sda5
> /dev/sda6


Just thinking out loud because I've never seen labels like that.
Interesting that they can be named that way.

My question is: Is that the only hard drive with partitions named like
that? Just ruling out that maybe there's some kind of conflict if two
hard drives have the same layout..

Based on the line deletions reference in your other email, it sounds
like the program is not so subtly saying, "You can only have it one
way here. Either you do this thing you're doing through me, OR you can
have it the other way that you like in your fstab."

Maybe it's seeing some kind of obscure, deeply buried clash with the
longstanding Linux file system hierarchy?

That comes from renaming my own, each with a very different yet easily
remembered system. That way when I e.g. "mount LABEL=apthoard-disk1
/var/cache/apt/archives", my system's not quibbling with itself over
WHICH "apthoard-disk1" label I'm asking for if it were to find two (or
3... or 4.... or...) instead of only one labeled as such..

Sounds like SOME kind of "bug" because it momentarily makes the system
unusable. Maybe something in the documentation, maybe a new change,
references it?

It seems odd that it deletes and doesn't SOMEHOW replace something in
fstab that is how we boot our systems. If it's going to DELETE
something because it sees a conflict a user does not, it needs to
likewise intelligently guarantee that a system has something else in
place to follow through on the very next reboot....

Cindy :)
-- 
Cindy-Sue Causey
Talking Rock, Pickens County, Georgia, USA

* runs with.. a dire need for a lightning rod in the backyard. Long
term lightning induced Internet disconnects are gettin' real-l-l-l
old... *

[toc] | [prev] | [next] | [standalone]

#222301

On Fri, 2020-05-08 at 09:59 -0400, Default User wrote:
> Hi David.
> 
> Yes, I made the labels for the  partitions during the original
> installation:
> 
> /dev/sda1 = /  (primary partition)
> /dev/sda2 =     (extended partition)
> /dev/sda5 = swap (logical partition)
> /dev/sda6 = /home (logical partition)
> 
> So /dev/sda2 has no label, as it is just an extended partition, which
> "holds" logical partitions:
> /dev/sda5
> /dev/sda6

It strikes me that using '/' in a label might cause problems. E.g.
something (kernel? udev?) makes disks appear under /dev/disk/by-label/
where each entry is the label name. If that label contains a '/' then
it can't appear there, or if it does, it will have a mangled name to
remove the '/'.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#222303

[Multipart message — attachments visible in raw view] — view raw

On Fri, May 8, 2020, 12:34 Tixy <tixy@yxit.co.uk> wrote:

> On Fri, 2020-05-08 at 09:59 -0400, Default User wrote:
> > Hi David.
> >
> > Yes, I made the labels for the  partitions during the original
> > installation:
> >
> > /dev/sda1 = /  (primary partition)
> > /dev/sda2 =     (extended partition)
> > /dev/sda5 = swap (logical partition)
> > /dev/sda6 = /home (logical partition)
> >
> > So /dev/sda2 has no label, as it is just an extended partition, which
> > "holds" logical partitions:
> > /dev/sda5
> > /dev/sda6
>
> It strikes me that using '/' in a label might cause problems. E.g.
> something (kernel? udev?) makes disks appear under /dev/disk/by-label/
> where each entry is the label name. If that label contains a '/' then
> it can't appear there, or if it does, it will have a mangled name to
> remove the '/'.
>
> --
> Tixy
>



Question to all:

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?

[toc] | [prev] | [next] | [standalone]

#222305

On Fri 08 May 2020 at 16:48:52 (-0400), Default User wrote:
> On Fri, May 8, 2020, 12:34 Tixy <tixy@yxit.co.uk> wrote:
> > On Fri, 2020-05-08 at 09:59 -0400, Default User wrote:
> > >
> > > Yes, I made the labels for the  partitions during the original
> > > installation:
> > >
> > > /dev/sda1 = /  (primary partition)
> > > /dev/sda2 =     (extended partition)
> > > /dev/sda5 = swap (logical partition)
> > > /dev/sda6 = /home (logical partition)
> > >
> > > So /dev/sda2 has no label, as it is just an extended partition, which
> > > "holds" logical partitions:
> > > /dev/sda5
> > > /dev/sda6

Silly me—it's a couple of decades since I had disks formatted with
extended partitions; one forgets.

But I'm surprised: which partitioner did you use, and which installer?

> > It strikes me that using '/' in a label might cause problems. E.g.
> > something (kernel? udev?) makes disks appear under /dev/disk/by-label/
> > where each entry is the label name. If that label contains a '/' then
> > it can't appear there, or if it does, it will have a mangled name to
> > remove the '/'.

Well, it is mangled, appearing as \x2f. I'm not aware that it's not
allowed, and the system ought not to get tripped up by it.
But if you try to use it, I can imagine that there might be software
that limits how you have to quote it—hex as here, or in quotes, or what?

So it would be sensible to change them to something sane. I never
stray beyond ASCII alphanumerics, though windows uses _ as well.

You might end up having to post to Gnome lists, so having them changed
may save embarrassment.

# e2label for partitions 1 and 6,
# swaplabel for 5.

> Question to all:
> 
> 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.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#222306

On 2020-05-08, Cindy Sue Causey (butterflybytes@gmail.com) wrote:

> My question is: Is that the only hard drive with partitions named like
> that? Just ruling out that maybe there's some kind of conflict if two
> hard drives have the same layout..

Cindy, there is only one drive in the computer, /dev/sda. Any other
drives would be removable usb external drives or usb thumb drives.
And no other drive I have would have the same layout.

> It seems odd that it deletes and doesn't SOMEHOW replace something in
> fstab that is how we boot our systems. If it's going to DELETE
> something because it sees a conflict a user does not, it needs to
> likewise intelligently guarantee that a system has something else in
> place to follow through on the very next reboot....

I agree!

--------------------------------------

On 2020-05-08, Tixy (tixy@yxit.co.uk) wrote:

> It strikes me that using '/' in a label might cause problems. E.g.
> something (kernel? udev?) makes disks appear under /dev/disk/by-label/
> where each entry is the label name. If that label contains a '/' then
> it can't appear there, or if it does, it will have a mangled name to
> remove the '/'.

Tixy, just a note: for many years, when installing Debian, using the
Debian installer, I have been setting:
/ as label for /dev/sda1
swap as label for the /dev/sda5
/home as label for /dev/sda6

In the past, I have instead used three primary partitions:
/ as label for /dev/sda1
swap as label for the /dev/sda2
/home as label for /dev/sda3

Either way has always worked fine, and did work fine on my current
setup until two days ago.

-------------------------------------

On 2020-05-08, David Wright (deblis@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.

> 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.

> 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"?

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.

: (

[toc] | [prev] | [next] | [standalone]

#222308

[Multipart message — attachments visible in raw view] — view raw

On Vi, 08 mai 20, 22:34:30, Default User wrote:
> 
> 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.

UUID is the preferred method for automating such stuff[1], because they 
are (for all practical purposes) unique, so it ensures there won't be 
conflicts even when swapping drives between systems.

Labels are more convenient for humans, provided that some care is taken 
to avoid conflicts as needed.

[1] Whatever automounter is used by LXDE it will mount removable storage 
under /media/<username>/<label> if the partition has one. This is much
friendlier than using UUID.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#222345

On Fri 08 May 2020 at 22:34:30 (-0400), Default User wrote:
> On 2020-05-08, David Wright (deblis@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.

[toc] | [prev] | [next] | [standalone]

#222386

On Sat, May 09, 2020, at 22:34:30, Andrei POPESCU
<andreimpopescu@gmail.com> wrote:

> UUID is the preferred method for automating such stuff[1], because they
> are (for all practical purposes) unique, so it ensures there won't be
> conflicts even when swapping drives between systems.
>
> Labels are more convenient for humans, provided that some care is taken
> to avoid conflicts as needed.

Understood.

> [1] Whatever automounter is used by LXDE it will mount removable storage
> under /media/<username>/<label> if the partition has one. This is much
> friendlier than using UUID.

I am using the Cinnamon DE on Unstable. On my system there is no
/media/<username>/<label>.
There are (currently) only:
/media/default/disk
/media/default/sdc
Both are zero-byte directories.


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.

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.

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.

(But did not solve my situation).

> 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

> (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.

> 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.

I am reminded of the situation where a son proudly tells someone that
his father is so good, that he managed to put together the son's new
bicycle with "three parts left over!"

: )

Thank you for indulging me . . .

[toc] | [prev] | [next] | [standalone]

#222389

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web