How to use volume label in filepaths instead of sd*?

[dhuum]

Does anyone know a way to force puppy to use the volume label, instead of the sd* designation, in filepaths? The inconsistency with which those designations are allocated is a big nuisance.

I want filepaths to look something like this:

/mnt/VOLNAME/files/thatfile.txt

instead of this:

/mnt/sdc2/files/thatfile.txt

And I really need this to apply in all circumstances.

Alternatively, does anyone know how to force puppy and/or bios to allocate the sd* things logically? (I realise that expecting a computer to act logically is wildly optimistic.)

[Jafadmin]

Easy Peasy

Just keep in mind that this negates the 'portable' nature of your puppy install.

'fstab' is the tool to use for attached storage:

Code: Select all

# /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>

# Mount 4T data drive in the root filesystem at /Data
UUID=ad018dd1-d0dc-40a3-924b-46a6e04fbc7e /Data           ext4    defaults        0       2

# Mount disk label 'MyData' at /root/MyData
LABEL=MyData    /root/MyData   ext3    defaults        0       2

For hot-pluggable storage you would use 'udev'. If you could be more specific about storage types and portability requirements, it would help us to answer.

[williams2]

Code: Select all

## mount the file system labelled "Lexar"
# mount-FULL -L Lexar /mnt/tmp/
#
## show that it is mounted
# mount-FULL -l | grep Lexar
/dev/sdb1 on /mnt/tmp type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro) [Lexar]
#
## list all syslinux* files
# ll /mnt/tmp/syslinux*
-rwxr-xr-x 1   72 Aug 29  2014 /mnt/tmp/syslinux2.cfg
-rwxr-xr-x 1 3.3K Nov 13  2020 /mnt/tmp/syslinux.cfg
# 
# umount-FULL /mnt/tmp/
#

Using UUID works only on 1 particular device.
Using LABEL works on any machine with that device.

[williams2]

Do you mean that drive icons are displayed on the desktop,
and if you click an icon labelled, say, sda4,
then it mounts /dev/sda4 on /mnt/sda4/

and do you mean you would like the drive icons to be labelled with the Volume Name Labels
and you would like it if, when you click an icon named, say, "Lexar",
then it would mount the file system labelled "Lexar" on /mnt/Lexar/ ?

Labels can be listed something like:

Code: Select all

# blkid | awk '{print $2}' | grep LABEL | grep -v PARTLABEL
LABEL="WINRE"
LABEL="RECOVERY"
LABEL="Lexar"
#

a mount point in /mnt/ could be created something like: mkdir "/mnt/$LABEL"

The file system could be mounted something like: mount-FULL -L "$LABEL" "/mnt/$LABEL"

To rewrite the code that creates clickable icons would require more effort.
Or a gui to mount file systems by LABEL could be written, it would also require some effort to do.

You could write a script like this maybe named "mount-label" or maybe named "ml":

Code: Select all

#!/bin/sh
mkdir -p "/mnt/$1"
mount-FULL -L "$1" "/mnt/$1"
rox "/mnt/$1"

Then to mount a file system labelled "Lexar", you could simply type ml Lexar

[JASpup]

If this engineering achieves the goal of consistent drive/partition assignment, before addressing the volume name, it is pretty important.

I am unable to customize my system if next boot sda & sdb will be switched.

[Jafadmin]

@JASpup 'fstab" is the "standard" way Unix/Linux mounts drives. In your case I would recommend using the UUID method indicated instead of the "label" method. UUID's are far less likely to be duplicated than labels.

LABEL=<label> or UUID=<uuid> may be given instead of a
device name. This is the recommended method, as device
names are often a coincidence of hardware detection order,
and can change when other disks are added or removed. For
example, `LABEL=Boot' or `UUID=3e6be9de-8139-11d1-9106‐
-a43f08d823a6'.

[dhuum]

Thanks for replies, folks.

My approach to computing is more a matter of low cunning than high tech, so I understand very little about all these things. Nevertheless, I tinkered with fstab and found that this kind of line in fstab:

LABEL=VOLNAME /mnt/VOLNAME vfat defaults 0 2

and this kind of thing in a script:

mkdir /mnt/VOLNAME
mount -L VOLNAME

produces the effect I was looking for -- BUT, as Jafadmin mentioned, it stops the operating system working on any other computer.

This seems far beyond bizarre. Can anyone explain why using the word 'label' in fstab would make an operating system installed on a flash drive refuse to work on all computers except one?

Although I don't make use of portability very often, I still regard it as essential. Is there really no way to get puppy to use the volume label in filepaths without losing portability?

Or is there really no way to get the sd* business to work consistently, so that an external boot device (attached before any other external storage is attached) is always sdb, and the back-up device attached next is always sdc? (I don't even know if this is strictly a Linux question or a bios question.)

Running a script after boot to change (e.g.) 'sdb' to 'sdc' in various places is, I admit, not a huge amount of trouble, once you've written the script. But should it really be necessary?

[Jafadmin]

Let's put the "low cunning" to the side for purposes of this discussion. The topic is technical.

1) sda, sdb, sdc, etc, are device descriptors. They are automatically assigned by the Linux kernel. Puppy natively uses the device descriptors to create file system mountpoints of the same name in /mnt. If you are interested in mounting filesystems by your own criteria, you must learn how to do so.

2) Mounting by "label" is less common and less reliable in OS's. Why? Labels are NOT unique. It's too easy to wind up with conflicting labels and corrupt filesystems. The recommended method is mounting by UUID, as these are generated by a RNG and are assured to not conflict unless the user forces them to (cloning comes to mind).

3) So now we come to the large issue. Are you talking about permanently attached storage, or "hotswap" & plug n play media? The rule of thumb is that permanently attached (i.e.: internal HDD) storage for the OS should be managed by 'fstab'. Plug n play & hotswap storage should be managed by 'udev' (the linux PnP daemon).

I think I can see a potential reason for wanting to mount by label, though. If you go to amazon and buy bulk USB flash drives (say a dozen or so), they all look the same in appearance, and are hard to physically label on the outside. Being able to plug them in and identify them by their filesystem label could help keep them organized.

In conclusion:
So think of it like your vehicle registration. The DMV will issue your vehicle randomly assigned license plates. If you want vanity plates you have come up with a unique name, apply to the DMV, wait for them to check for conflicting names, pay an extra fee, then mount them on your vehicle.

p.s. .. One last thought; Folks often confuse the devices and the device configurations as being the same thing. They are not. A disk is a device. What's on the disk (Partition Table) is it's configuration. Some parts of the OS deal with the devices, others deal with the configuration and contents of those devices.