Post-install, fstab has wrong partition UUIDs

troff · 2017-07-04 12:21:02

Hi all,

sorry; used Linux for quite some time but not done much in the way of submitting bug reports or the like.

Have an Acer Aspire E 15 laptop (E5-523G-90QW). Getting Devuan onto this thing was a massive headache, but Debian, live Devuan, Ubuntu, Xubuntu, LMDE and Mint 18.2 all failed completely; as far as I can tell, because the latest autodetected drivers for the video (AMD Radeon R5 M430) seem to HANG. Any install locks up; sometimes the live runs lock up.

The only partial success I've had is with Devuan, locking it down to Jessie before trying anything else. And that *seemed* to work (except for the r8169 driver failing after a while and the r8168-dkms package seems to be missing the autorun.sh scripts or a working Makefile, but I'll work on that later).

But tonight, I completed the base install, installed a bunch of packages. Powered down, took it home, started it up.

Dropped into emergency maintenance because various partitions/devices didn't resolve to checkfs. Substituted /dev/ entries, could then mount. So I checked the blkids for each partition.

The following is the relevant parts of my fstab; edited for clarity - the first UUID is the one assigned by installation. The second UUID is that detected by blkid /dev/sdaN:

# /boot was on /dev/sda1 during installation
# UUID=ef1fd89d-d78f-4029-9174-b0b49f76ae20 /boot ext4 noatime,nodiratime,relatime,sync 0 2
# UUID=190a271e-9a96-453a-a913-9a3af5ed9fee /boot ext4 noatime,nodiratime,relatime,sync 0 2
/dev/sda1 /boot ext4 noatime,nodiratime,relatime,sync 0 2

# swap was on /dev/sda2 during installation
# UUID=cb2a0ab4-a9d9-4242-bfc4-f218cd33cf27 none swap sw 0 0
# UUID=66c81ce0-f8d2-4c28-9f27-e3af66b1d3a2 none swap sw 0 0
/dev/sda2 none swap sw 0 0

# / was on /dev/sda3 during installation
# UUID=bdee91c0-75f8-4196-a6d7-8f57bbe8e9f7 / ext4 noatime,nodiratime,relatime,errors=remount-ro 0 1
# UUID=d8dc9adb-43d4-41c4-be1e-e0f1334814f7 / ext4 noatime,nodiratime,relatime,errors=remount-ro 0 1
/dev/sda3 / ext4 noatime,nodiratime,relatime,errors=remount-ro 0 1

# /home was on /dev/sda4 during installation
# UUID=a86ffaf6-d466-4560-9587-5fe660bdf07b /home ext4 noatime,nodiratime,relatime 0 2
# UUID=9f8e3a20-c97d-43a4-969c-02c2422fb0ed /home ext4 noatime,nodiratime,relatime 0 2
/dev/sda4 /home ext4 noatime,nodiratime,relatime 0 2

... if anybody could offer any advice as to how this went wrong (and where best to offer bug reports, plus what best to include), it would be *greatly* appreciated.
Many thanks...

fungus · 2017-07-14 23:21:54

I remember specifically in the installation (both times, first failed) I asked that UUIDs are used over labels and dev/sdxx as being more accurate.
The installation came with an fstab that only mounted the device number /dev/sda1 (ie) and partition labels.
I edited the fstab to match uuids. When I got the system where I wanted I logged into a different system, created a new partition and used dd to copy the partition of the installed devuan into the new one. Then as the uuid of the flash drive partition was copied into the hd, I used gparted to check partitions and gave the clone a new uuid and edited the new fstab to match.
Nothing, it will not even find the root of the system (grub found the installed clone and had the correct uuid). I switched between labels and /dev/sdxx no difference.
While playing with that debian module for non-bootable systems I noticed while I tried mount -a that the system is still seeking the UUID of the original installation, so there is some place where this is specified and can be changed, although I don't know where.
Three different linux distributions I had done this before did not have this problem.
But the above post is already 10days old and did not get a response, so I may be waiting and searching for a while.

golinux · 2017-07-15 01:02:57

My foggy memory tells me that dev/sdxx is the least reliable method of naming drives because adding a usb device can change the numbering and if you're not paying attention, you might write to the wrong partition. My current fstab uses uuids but all my external drives are labeled as well as all my other installations. (I've just been too lazy to change over.) The only uuid that has ever changed for me during an install has been the swap partition afaicr. Note that I don't mess with my system once it's up and running till the next release.

fungus · 2017-07-15 08:17:30

I agree with you 100%, I only use UUIDs on fstab
Here the problem is not finding and mounting other partitions, I could live doing it manually, but it is the
root mounting that is absent. The uuid on fstab is correct, the system while it is trying to start gets an
instruction of the uuid of the original installation. It replies uuid not existing, and returns me to intramfs which I don't know how to debug. The root partition never gets reached, so there are no logs there.

There are several reasons why a UUID may need to change in a system, hd replacement, moving the system to another partition, etc. In all other linux distributions I have ever tried all I had to do was edit fstab and update grub. Not on Devuan.

Back to disk labels, the installation was done on sdb1, it was then cloned to sda11, then sda11 received a
new uuid, fstab was edited and grub was updated with sdb1 upnplugged. When sda11 tries to boot it is looking for the uuid of sdb1 not sda11 as the uuid in grub.cfg and fstab indicate.

Where is it at?

fungus · 2017-07-15 09:07:57

SOLVED!!!!!!

I went back for a detailed look at grub, since the error was within the initramfs and the root location could not be located.

menuentry 'Devuan GNU/Linux ascii/ceres (on /dev/sda11)' --class devuan --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-xxxxxx-new--UUID-----xxxxxxxx' {
	savedefault
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos11'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos11 --hint-efi=hd0,msdos11 --hint-baremetal=ahci0,msdos11  xxxxxx-new--UUID-----xxxxxxxx
	else
	  search --no-floppy --fs-uuid --set=root xxxxxx-new--UUID-----xxxxxxxx
	fi
	linux /boot/vmlinuz-4.9.0-3-amd64 root=UUID=xxxxxx----OLD--UUID-----xxxxxxxx ro quiet
	initrd /boot/initrd.img-4.9.0-3-amd64
}

Grub although it finds the right UUID from the partition in the part of the entry where the linux image to boot from is it picks up something from within the initrd.img...... which contains the original UUID of the installation.
It boots now, but it is slow, I guess I would have to reinstall the two kernels to fix this (booting one reinstalling the other

Hurray.... now the fun really begins.

Damn dumb Grub, I thought it only screws up on Arch based distros.

See you-all later!
Cleaning up shop in my new devuan installation

fungus · 2017-07-15 22:53:09

update-initramfs -u -k all

and then

update-grub

and it all gets fixed magically (thanks to @dev1 for the hint

Last edited by fungus (2017-07-15 22:56:44)

The officially official Devuan Forum!

#1 2017-07-04 12:21:02

Post-install, fstab has wrong partition UUIDs

#2 2017-07-14 23:21:54

Re: Post-install, fstab has wrong partition UUIDs

#3 2017-07-15 01:02:57

Re: Post-install, fstab has wrong partition UUIDs

#4 2017-07-15 08:17:30

Re: Post-install, fstab has wrong partition UUIDs

#5 2017-07-15 09:07:57

Re: Post-install, fstab has wrong partition UUIDs

#6 2017-07-15 22:53:09

Re: Post-install, fstab has wrong partition UUIDs

Board footer