[SOLVED] ALERT! UUID does not exist for ext4 partitions after Buster installed
DebianThis forum is for the discussion of Debian Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
ALERT! UUID does not exist for ext4 partitions after Buster installed
After I installed the latest Debian (Buster-10) (onto an ext3 partition), grub shows the old systems as well, Buster boots ok (buster has some issues, but boots) and the other ext3 filesystems still work fine. Two of my older Mint systems (both on ext4 partitions ... Petra and Nadia ) fail with
ALERT! /dev/disk/by-uuid/... does not exist
which puts you to a (initramfs) prompt
If I issue a "ls -l /dev/disk/by-uuid" at that time
I do see the uuid that it is complaining about, so it does , in fact, exist.
The newer Mint installs work, as do my various other Linux installs.
I've tried doing an upgrade for grub, and rebuilding the grub.cfg, which did not alter the result. I also checked the fstab for any invalid uuids in the failing Mints, but found none.
If someone knows how to fix this (or even something else that I can check), it would be great. Failing that how to regress to the grub I was running if it can not be fixed (The one with Jessie-8 worked fine). I do want to continue to run Buster if possible (so I would rather not just restore).
Thanks!
If you upload to pastebin.com or paste.debian.net or equivalent, output from bootinfoscript, someone here can probably suggest a fix. Based on the output, you might even be able to determine a fix on your own.
Yeah, sounds weird - I'd expect issues with with a shared swap getting reformatted by later installs (been there, done that) but not untouched system partitions.
More info as requested is always better.
Thanks for the suggestions.
blkid provided a nice output, but no new information.
I could not run bootinfoscript from the busybox, so I installed gawk on Buster and ran it there. It appears that the places that you suggested are for code development rather than bugs/issues though, so I've done no more than look at the output.
I disabled (commented out) the swap in /etc/fstab of Petra, but that did not seem to alter the issue.
Do you see this same error when booting both Petra and Nadia and is the UUID the same when booting either? That would probably mean a swap changed. If the UUID is different when booting Petra and Nadia, make a note of the UUID and boot the system with the default bootloader (Grub on Debian?) and compare the uuids to the uuids in the grub.cfg file for the menuentries for Petra and Nadia.
Would have been useful to members here if you had posted the bootinfoscript output.
The UUIDs in the error message match the UUID that is being booted.
I attached the boot info script output in case someone is willing to look at it (sorry, still learning how to use the site).
I did get an ext4 system to boot. It was a debian wheezy on sdf6, that had a sda# in the etc/fstab. I changed it to a UUID format and it booted fine. The older mint systems are still down. Apparently the new systems name the disk differently as the partitions of the drive are named sdf# now, although I only have two drives (and one , unix , is disabled in the bios unless I am using it). The two failing partitions are sdf9 - Nadia and sdf10 - Petra. The other ext4 partitions (not mentioned here, but in the file) are data only at this time. Worst come to worst, I can live without Nadia and Petra, but if you can see what is wrong, it would make me feel better about using ext4 filesystems for booting from.
Are those the UUIDs you see when trying to boot either?
At the very beginning of the bootinfoscript it tells us that Grub is installed in the MBR of that drive and looks for /boot/grub on sdf12 which is your new Debian install so we need to scroll down to the beginning of the grub.cfg file for sdf12 on line 3837. The entries for Petra beginning on line 4093 and Nadia beginning on line 4614 have those same UUIDs so those entries appear correct and should boot.
sdf10 has the correct UUID for swap in fstab while sdf9 does not, see lines 3630 and 3499 so I'm not really sure why neither boots. I would suggest that once you get this resolved, you learn how to clean up old kernels and if you are going to be using these outdated and unsupported systems, you not connect to the internet as they are insecure. I've never seen one of these reports with nearly 5,000 lines?
The older mint systems are still down. Apparently the new systems name the disk differently as the partitions of the drive are named sdf# now, although I only have two drives (and one , unix , is disabled in the bios unless I am using it). The two failing partitions are sdf9 - Nadia and sdf10 - Petra.
Does every bootable distro report the boot drive is using /dev/sdf rather than /dev/sda?
Have you done something in BIOS setup to give the usually unused drive priority over the problem drive? Have you done any housekeeping inside the PC lately? Could the SATA cables been swapped between the two HDDs? Could front panel USB port cables or a multi-type media reader's USB cable(s) have been moved to a different motherboard connector?
Multi-type, USB connected media readers are often the reason why 4 extra drive letters shift another drive to a different letter than before. This changes device enumeration that assigns the USB devices before one or more "internal" ATA or NVME drives. Getting the boot drive back to /dev/sda from /dev/sdf for all installed distros might be all the repair required to restore Nadia and Petra to bootable.
If nothing else works, I'd try chrooting into Nadia or Petra to rebuild the default initrd (after backing up the current one).
Yes, I have a Unix drive (40G) and a Linux drive (1T). The Unix drive is normally disabled in the BIOS unless I am using it, as I want to boot grub. The drives have no particular priority in the bios, so I suppose it is due to the ports that they are actually connected to. I have not recently updated the computer except to install new os (it came as a w7 machine with the 40G drive and 512M ram, I started using it for Linux in the days of Debian Sarge, so no, I have not moved cables).
I tried rebuilding the initrd on both, but it did not change anything. What follows is the detail (of petra), in case I did something wrong (I have never done that before).
su - root
Password:
root@it:~# mount /dev/sdf10 /mnt
root@it:~# mount --bind /dev /mnt/dev
root@it:~# mount --bind /proc /mnt/proc
root@it:~# mount --bind /sys /mnt/sys
root@it:~# chroot /mnt
it / # ls /boot/*initrd*
/boot/initrd.img-3.11.0-12-generic
it / # cd /boot
it boot # mv /boot/initrd.img-3.11.0-12-generic /boot/old-initrd.img-3.11.0-12-generic-old
it boot # update-initramfs -c -k 3.11.0-12-generic
update-initramfs: Generating /boot/initrd.img-3.11.0-12-generic
Warning: No support for locale: en_US.utf8
it boot # update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.11.0-12-generic
Found initrd image: /boot/initrd.img-3.11.0-12-generic
Found memtest86+ image: /boot/memtest86+.bin
No volume groups found
Found Debian GNU/Linux (6.0) on /dev/sdf1
Found Debian GNU/Linux (6.0) on /dev/sdf11
Found Debian GNU/Linux (10.7) on /dev/sdf12
Found Linux Mint 18 Sarah (18) on /dev/sdf5
Found Debian GNU/Linux (7.11) on /dev/sdf6
Found Debian GNU/Linux (wheezy/sid) on /dev/sdf7
Found Debian GNU/Linux (8.6) on /dev/sdf8
Found Linux Mint 14 Nadia (14) on /dev/sdf9
done
it boot # exit
exit
root@it:~# umount /mnt/dev
root@it:~# umount /mnt/proc
root@it:~# umount /mnt/sys
root@it:~# umount /mnt
root@it:~# shutdown -r now
The result was identical, it booted to the busybox with the same error.
From the busybox the contents of the /proc/cmdline had the uuid in the error:
BOOT_IMAGE=/boot/vmlinuz-3.11.0-12-generic root=UUID=2c425dd3-aeb1-4703-a74f-6a30dba85ae1 ro quiet splash
Shut down and move the cable from your Maxtor to the #1 SATA port, and the cable from the WD to the #0 SATA port.
Disconnect the USB multi-card reader from the USB bus.
Boot something that allows you to see whether the WD is no longer /dev/sdf. If it turns up as /dev/sda,
Shutdown, reconnect the multi-card reader, boot to find out if it remains the same. If it changes,
Shutdown, move the multi-card reader to some other USB port, boot to find out what if anything changed.
If necessary, move the multi-card reader to yet another port.
Report back your findings.
If this is an older PC without SATA ports, then shuffle whatever is necessary to make the WD the primary master, and the Maxtor either the primary slave, or the secondary master.
If the USB multi-card reader is plugged into the motherboard, lsusb looks like:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 058f:9360 Alcor Micro Corp. 8-in-1 Media Card Reader
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Otherwise it looks like:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
This was true if the boots were working or failing.
When I started the test, the maxtor was on the first IDE port, the DVD on the third IDE port (second controller master), WD on the #0 sata. I did not do any drive switching due to the cable difference (can not switch).
If the USB Media Card reader is disconnected, the drive letter went from sdf to sdb, and I was able to boot Petra (of course, no usb at that point). Since I kind of need usb, that was the only test that I ran with it that way.
If I disabled the first IDE Controller, it drops the drive letter by one (sdf => sde, or sdb => sda), which did not affect the success or failure of the boots.
If I disable both IDE Controllers, the drive becomes sda, and boots (of course, I can not use the dvd , or maxtor drives, but I can use usb).
Petra works fine as sda/sdb, and fails as sde/sdf.
Nadia booted (sda/sdb) , but did not like the motherboard video. I took out the video card when I installed Buster, as Buster would not use it well enough to put a screen up. The motherboard video reports as a nvidia 6100, the adapter card sticker says v6202el-63 (6200el 32bit nvidia gpu with 64mb).
I forgot about motherboards with both PATA and SATA ports having such letter shuffling trouble being one instigator of UUIDs as defaults for Grub and fstab replacing device names.
Many motherboards, maybe most, have a means in BIOS setup to determine whether PATA or SATA has priority. You should be good if you find yours, and set the priority to SATA over PATA, meaning WD should then be sda, Maxtor sdb (or possibly sdf), and USB sdc-sdf, regardless what you boot into. If this makes the Maxtor unbootable because it's no longer sda, then, if you can, reconfigure it to boot as sdb, or when you wish to use it, restore PATA to priority, then change it back when each time comes to return to the WD as boot device.
Thanks for all your help.
Nothing shy of disabling the CDROM IDE Controller helps at all (Disabling the CDROM IDE Controller moves the USB to the end in Buster, no idea why). The order in the bios is/was SATA, IDE, USB and it worked that way with older Debians, but with Buster it uses the opposite order. I don't know why. Likely they don't test Debian on 15 year old computers. In any case, it is not worth any more effort. I am going to mark this solved, even though it is not fully solvable, it is mostly resolved. I no longer think the issue is related to the file type (thanks to you ). That was just coincidence. Hopefully I will upgrade to a new computer in the next few years. The Video card not working actually worries me more, as I am unsure what would be safe video card to actually use in the long term.
In any case, thanks for all of your suggestions and efforts attempting to solve this for me.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.