I have a question about the command ls -la dev/disk/by_uuid on my system.
This system has two ssd disks.
One disk is a M.2 ssd connecting to a small slot on the motherboard. I bought it recently and have OpenSuSE Leap 15.3 running on it.
The other is a 2.5" SSD disk that has been in my PC for a few years and which was used for running OpenSuSE Leap 15.3 (and predecessors) too.
At present (among other things) the command ls -la /dev/disk/by_uuid gives the following result:
The first line gives the partition on which my present OpenSuSE Leap 15.3 system resides.
The second line is the partition where OpenSuSE leap 15.3 ran before I bought the M.2 ssd.
Now, for reasons of testing, I used fsarchiver on a system rescue disk to copy an old archive of the OpenSuSE leap 15.3 (as it was a few months ago on sda1) to nvme0n1p5.
I did do nothing more than that and stayed in the shell of the system rescue disk. No reboot or whatsoever.
To my surprise, the command ls -la /dev/disk/by_uuid suddenly showed this:
where 2e9e19fc-c3b0-4ab2-a517-7d786c1a48c7 previously belonged to sda1.
How can it suddenly point to another partition? I thought these large numbers were fixed to disk partitions an would only change after formatting them.
I have a UEFI system and the /boot/efi partition resides on the M2. ssd.
fsarchive also changes the UUID - as it does an partimage type backup with checksums.
It has to restore the UUID or linux will fail to boot.
you can change the UUID of any unmounted partition with tune2fs.
I was not familiar with fsarchive - I assumed it was like a tar type backup. I was wrong.
That indeed is a surprise. I thought the same as you did. Thanks for the advise. I’ll try it out tomorrow.
By the way: what I tried to accomplish was replacing the OpenSuSe on the new SSD with the one on the old SSD. So far I ended up with a grub command line after booting and knew not what to do next.
Alternatively, I might mount the fsa archive as a loop device and then copy the files to the partition. That won’t change its UUID I guess.
Odds are that the drivers for /dev/nvme are not in your backup which is why grub hangs - it is only seeing /dev/sdX devices as nvme was not there when you installed the last kernel on /dev/sda1.
There are fixes that were posted within the last week to fix the missing drivers and then doing a mkinitrd to install them in the linux loader.
Whatever you did and whatever you think, users may always check their UUIDs and change them back to the previous value (if they still know it, of course), e.g. see “btrfstune --help”.
Use blkid and you will see there are two UUIDs associated with most partitions, one for the filesystem on the partition, and one for the partition itself. The kernel mounts filesystems, not partitions, so the UUIDs that matter regarding Grub and fstab are the the filesystem UUIDs, which are those found in /dev/disk/by-uuid/.
I think this is crucial. The first thing that came to my mind when I saw this thread’s post #1 in the morning: this person does not understand the difference between a partition and a file system.
To repeat what is said by @mrmazda (and referred to by @karlmistelberger with respect to Btrfs) and to elaborate a bit.
A partition is only a part of the disk defined by it’s start and it’s end in the partition table. There is nothing in between that start and end that particular tells anything about a partition, all the bytes are used for the contents of the partition. That contents CAN BE a file system (other things then file systems are possible). A file system that is created inside a partition (or inside something different then a partition) CAN have (depends on the file system type) a UUID that is of course stored somewhere inside that file system. It is this UUID that is used to create the /dev/disk/by-uuid entries (by udev).
When one understands this, it should be clear that:
when the file system is copied (byte for byte by e.g. dd if=/dev/sdd3 …) somewhere else, the UUID will stay the same because the UUID is inside the file system and thus copied with it. When the whole disk is copied (e.g. dd if=/dev/sdd …), the same will happen of course because again all bytes inside the file system (in case of the whole disk maybe even more then one file system) will be copied with it.
when something is changed to the organisation of the file system, the file system software may change the UUID with it. This includes the feature that tools of a specific file system type (like Btrfs) may offer to change it on purpose.
And then there came something new: GPT (GUID Partition Table)
Where the old partition table (MS-DOS or MBR) was designed in a time where every byte that could be spared was important, now diskspace used for administration is not so important anymore. That means that there is more space to administer partitions. And a UUID is given to each partition. That is the second UUID shown by lsblk as mentioned in a post above and you find them in /dev/disk/by-partuuid. But of course only when the disk is GPT.
Again when one understand this, it should be clear that:
when a file system is copied (byte for byte e.g. dd if=/dev/sdd3 …) somewhere else, the Partition UUID will not go with it, because it is in the partition table and not inside the data copied;
when the whole disk is copied (e.g. dd if=/dev/sdd …) the partition table is copied with it and all the Partition UUIDs will go with it.
In both cases one should be careful. When UUIDs (from partitions or file systems) are copied, they are no more UU (Universally Unique). Not only world wide but even dangerously close to each other. Having them on the same system can lead to unpredictable results, specially when you try to use them to identify a file system!
Indeed I did not see the difference between the partition and the file system that may be on it. Of course, the information from /dev/disk/by_uuid is from the file system and not from the partition table.