I’ve recently switched to OpenSUSE Tumbleweed and I’m trying to edit fstab so that my drives will automatically mount where I want them to every start up. I’ve read a lot about this and the UUID seems to be the best way to be sure that the drive locations don’t change (vs using dev/sda1, etc).
However, all of my drives seem to have two UUIDs: the main UUID and (for the most part) a much longer PARTUUID (partition UUID from what I can tell). Now, do I use the former or the latter? I’m confused. I seems like the PART UUID would make more sense since it’s the partition that needs to be mounted. It’s also odd, even on drives that have only a single partition, it still shows a shorter UUID and a longer PARTUUID.
Any info would be extremely helpful. I’ve not been able to find much info in my web searches on whether I want the UUID or PARTUUID and I know fstab isn’t something you want to screw up. Thanks so much in advance!
I normally use UUID, partly because there is builtin support. I can use
UUID=uuidstring
instead of the longer
/dev/disk/by-uuid/uuidstring
I’m not sure whether a similar shorthand method is available for PARTUUID.
In most case, the UUID and PARTUUID seem to be of similar length. The main exception is for FAT file systems, where the UUID is quite short.
The UUID is part of the file system. The PARTUUID is part of the partition table. With a older MBR/DOS partitioned drive, the PARTUUID is somewhat faked and less reliable.
If using encryption, then there is no PARTUUID for the file system, because the file system is not a partition (unless you are using a disk with hardware crypto built-in). And there is also a separate UUID for the LUKS header.
If you use a randomly encrypted swap partition, the UUID is likely to change with every boot as the random key changes. But the PARTUUID will still work in that case.
If you clone a file system to move to a different disk, then the cloning can include the UUID (depending on the software used), but it cannot include the PARTUUID.
In general, it is your choice. Use what works best for you. And note that some people prefer to use LABEL.
PARTUUID is of the partition in GPT partitioning (it is in the GPT partition table and there isn’t such a thing in MBR partitioning, no place in the MBR table and MBR partitioning is probably inveneted before UUIDs existed)…
UUID is of the file system, regardless on what type of partition (or even on no partition at all).
When you “clone” a file system to another partition, the UUID will be cloned with it, because it is inside the file system.
When you clone to another GPT partition, both will have the same UUIDs, but different PARTUUIDs.
UUID is the one already used by default on openSUSE installations for some time, on MBR and GPT partitioned disks.
But of course there is also case for usng LABEL.
And there might even be arguments to use a mix, depending on your needs.
Thanks so much to everyone for all of these thoughtful replies. I obviously don’t know about other systems than my own but I’m including some of the data from the list output from the terminal, just so you can see what I’ve been seeing:
At least you can see the output directly now, and the different UUIDs that I’ve been working with.
I’ve been giving this a lot of thought and since there now appears to be file UUIDs, disk UUIDs, and partition UUIDs, I’m thinking that the best option for me may be to use the label option, instead. I’m in the process of renaming to more meaningful labels anyway and I know that the partition that I’ve labeled will be what’s mounted (and not worrying about whether the disk itself but not the correct partition is what gets mounted). It also will likely be easier for me to remember/identify the partitions this way and may just offer more clarity all round. Thanks so much for all of your help with all of this. I’d not have gotten to this point without all of your help and knowledge.
One last caveat. Of course labels like “/” should be replaced, especially if you have more than one OS installed at any given time, but even “efi” and “swap” are not so good for mounting since you appear to have at least two efi and two swap partitions on your system.
Please be aware that some systems at installation re-format the swap partition they are going to use and that will change the UUID, possibly preventing another system from using that swap if its fstab uses “UUID=xxx”.
Please take care again. LABELs do NOT belong to a partition. They belong to a file system.
They are set using file system dependent tools (but of coures YaST Partioner and other high level GUI partitioners hide this) and are insode the file system.
Thus a specific file system type may or may not support this (most do).
When you “clone” a file system, the LABEL will be cloned with it and after that you will have two file systems with the same LABEL (like I explained for the UUID above).
BTW, what is your problem with what openSUSE uses by default?
I have several hundred filesystems, mostly Linux native, spread across more than two dozen computers. All Linux native here have been mounted (and Grub booted) using LABEL= for more than a decade. UUIDs are for optimal for young people with eidetic memory, and computers. LABEL OTOH is human friendly. Humans get to pick strings of flexible length that work the way their brains work.
[QUOTE=hcvv;2943253
BTW, what is your problem with what openSUSE uses by default?[/QUOTE]
Well, it’s simple. It didn’t work for me. I really, really, really wanted to just use what OpenSUSE did by default (run/media/user/drive).
However, in order for that to work, I had to be able to add two users/groups into the group that was setup with permission to rwx all the files in the drives. I know people don’t like me to say drives on here because Linux sees them all the same but nevertheless, I had to add my media server software’s user to the group with permissions.
I did that till I turned blue. But no matter what I did (whether adding the groups to the existing approved group) or creating a new group then changing ownership/permissions to that new group, nothing worked. The permissions changes wouldn’t “stick”. It was like because OpenSUSE had mounted those partitions there automagically, I couldn’t make any changes (whether I did it as my own user, or as root - everything failed).
So, I went round in circles trying to get this fixed but nothing worked. I read about another user in OpenSUSE who had a similar issue and after manually editing fstab so that all the partitions mounted automatically each time, everything worked with permissions. So, I tried it myself and had the same outcome. Once I had setup fstab, I could then makes the permissions changes and it worked this time.
Maybe there was something I overlooked somewhere that got fixed with this process but I can’t see what it is. And hearing that someone else had the same issue where the auto mount location just didn’t work for being able to change or add permissions, I figure maybe it’s a weird glitch somewhere. Anyway, at least this piece or working now. One less thing. I was about to go out of my mind on this prior.
Well, it’s simple. It didn’t work for me. I really, really, really wanted to just use what OpenSUSE did by default (run/media/user/drive).
However, in order for that to work, I had to be able to add two users/groups into the group that was setup with permission to rwx all the files in the drives. I know people don’t like me to say drives on here because Linux sees them all the same but nevertheless, I had to add my media server software’s user to the group with permissions.
I did that till I turned blue. But no matter what I did (whether adding the groups to the existing approved group) or creating a new group then changing ownership/permissions to that new group, nothing worked. The permissions changes wouldn’t “stick”. It was like because OpenSUSE had mounted those partitions there automagically, I couldn’t make any changes (whether I did it as my own user, or as root - everything failed).
So, I went round in circles trying to get this fixed but nothing worked. I read about another user in OpenSUSE who had a similar issue and after manually editing fstab so that all the partitions mounted automatically each time, everything worked with permissions. So, I tried it myself and had the same outcome. Once I had setup fstab, I could then makes the permissions changes and it worked this time.
Maybe there was something I overlooked somewhere that got fixed with this process but I can’t see what it is. And hearing that someone else had the same issue where the auto mount location just didn’t work for being able to change or add permissions, I figure maybe it’s a weird glitch somewhere. Anyway, at least this piece or working now. One less thing. I was about to go out of my mind on this prior.
Thanks for the encouragement. Maybe I’m just not at young as I used to be but Labels seem to work more how my brain does now. Make it’s easier to figure out where everything is and what it is. I’d never be able to figure it out with UUIDs only. I’d go crazy.
Sorry, but your story is confusing to me on several points. The result us that I loose what the sequence of what happened.
The use of /run/media for creating mount points is only done when a mass-storage device is connected to the system while some user is using the desktop. The system will se the spontanious emerging of the device and signal the desktop. The desktop then warns the user with a pop-up asking him what to do. The user can then e.g. say het wants to use his file mnager on it. Then the file system (in most cases there is only one partition and one file system) will then be mounted on a mont point that has to be created for the occasion. That is done in /run/media, first a directory for the user is made with the user’s name (remember, Linux is a multi-user system, thus such a solution must be able to accomodate several users), then a directory to be used as mount point is created in /run/media/<user>/ where the name depends. The mount is done, when this is a non-Linux file system, the options to make the user the owner is used. The file manager is started and the user sees the conetents of he device.
But this is only for mass-storage devices connected during a desktop session!
And no use should be made of /run/media by others!
File systems that are to be part of the system and are thus mounted during boot (and unmounted at shutdown) are to be defined in /etc/fstab.
You will thus find there a file system for / (else there would be nothing at all) and with a Btrfs file system a bunch of sub-volumes.
You will find there often /home.
And possibly will find there other file systems that are needed for all sorts of caeses. In your case, I understand you want to run some music serber, thus you may want to have the music on a seperate file system. And those should be always there. And those thus should be in /etc/fstab.
And openSUSE uses in /etc/fstab by default UUID=. For your added file systems, you could do likewise, or e.g. use LABEL= (or any others of the several possibilities, inccluding direct the device files /dev/sdNX).
Also saying things like “adding group to groups” sounds like …
Better explain in detail, calling names, might help others to understand what you are doing.
Thanks so much in advance!