LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Debian
User Name
Password
Debian This forum is for the discussion of Debian Linux.

Notices


Reply
  Search this Thread
Old 12-18-2020, 03:42 PM   #1
scpeckham
LQ Newbie
 
Registered: Dec 2005
Distribution: Mint Cinnamon
Posts: 15

Rep: Reputation: 0
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!
 
Old 12-18-2020, 09:51 PM   #2
mrmazda
LQ Guru
 
Registered: Aug 2016
Location: SE USA
Distribution: openSUSE 24/7; Debian, Knoppix, Mageia, Fedora, others
Posts: 5,788
Blog Entries: 1

Rep: Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065
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.
 
Old 12-18-2020, 10:17 PM   #3
frankbell
LQ Guru
 
Registered: Jan 2006
Location: Virginia, USA
Distribution: Slackware, Ubuntu MATE, Mageia, and whatever VMs I happen to be playing with
Posts: 19,272
Blog Entries: 28

Rep: Reputation: 6124Reputation: 6124Reputation: 6124Reputation: 6124Reputation: 6124Reputation: 6124Reputation: 6124Reputation: 6124Reputation: 6124Reputation: 6124Reputation: 6124
You may also find the blkid command helpful. See man blkid for more.
 
Old 12-18-2020, 10:27 PM   #4
syg00
LQ Veteran
 
Registered: Aug 2003
Location: Australia
Distribution: Lots ...
Posts: 21,103

Rep: Reputation: 4117Reputation: 4117Reputation: 4117Reputation: 4117Reputation: 4117Reputation: 4117Reputation: 4117Reputation: 4117Reputation: 4117Reputation: 4117Reputation: 4117
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.
 
Old 12-22-2020, 12:04 PM   #5
scpeckham
LQ Newbie
 
Registered: Dec 2005
Distribution: Mint Cinnamon
Posts: 15

Original Poster
Rep: Reputation: 0
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.
 
Old 12-22-2020, 12:14 PM   #6
mrmazda
LQ Guru
 
Registered: Aug 2016
Location: SE USA
Distribution: openSUSE 24/7; Debian, Knoppix, Mageia, Fedora, others
Posts: 5,788
Blog Entries: 1

Rep: Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065
How about uploading bootinfoscript output so those with more familiarity with it can possibly see what is wrong?
 
Old 12-22-2020, 12:20 PM   #7
yancek
LQ Guru
 
Registered: Apr 2008
Distribution: Slackware, Ubuntu, PCLinux,
Posts: 10,444

Rep: Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474
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.
 
Old 12-25-2020, 11:57 AM   #8
scpeckham
LQ Newbie
 
Registered: Dec 2005
Distribution: Mint Cinnamon
Posts: 15

Original Poster
Rep: Reputation: 0
Hi,

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.

Thanks,
Steven Peckham.
Attached Files
File Type: txt bisbuster.txt (224.5 KB, 71 views)
 
Old 12-26-2020, 08:08 AM   #9
yancek
LQ Guru
 
Registered: Apr 2008
Distribution: Slackware, Ubuntu, PCLinux,
Posts: 10,444

Rep: Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474Reputation: 2474
The Mint partitions you indicate do not boot (sdf9 and sdf10) show their UUIDs as in lines 225 and 211 of the bootinfoscript output:

Quote:
/dev/sdf9 08245a6c-3189-4ba2-b1d5-be4fb4390398 ext4
/dev/sdf10 2c425dd3-aeb1-4703-a74f-6a30dba85ae1 ext4
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?
 
Old 12-27-2020, 02:02 AM   #10
mrmazda
LQ Guru
 
Registered: Aug 2016
Location: SE USA
Distribution: openSUSE 24/7; Debian, Knoppix, Mageia, Fedora, others
Posts: 5,788
Blog Entries: 1

Rep: Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065
Quote:
Originally Posted by scpeckham View Post
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).
 
Old 12-31-2020, 11:58 AM   #11
scpeckham
LQ Newbie
 
Registered: Dec 2005
Distribution: Mint Cinnamon
Posts: 15

Original Poster
Rep: Reputation: 0
Hi,

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

the results of blkid command were:
/dev/sda4: TYPE="ufs"
/dev/sdf1: UUID="31255f12-6059-497f-86e4-4b3dcbdfc92d" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdf2: UUID="c7ff744d-cf78-427f-8505-e8a292a541e9" TYPE="swap"
/dev/sdf3: LABEL="home" UUID="99a4332b-1957-429b-8a44-1cb1a4ab8de2" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdf5: UUID="9b9544ba-fa8a-4d56-8301-c66e0fd535dd" TYPE="ext3"
/dev/sdf6: UUID="9d3cb056-3e6a-4263-8f85-77118990f90f" TYPE="ext4"
/dev/sdf7: UUID="013bced4-ef27-4467-9949-8972374cfd8a" TYPE="reiserfs"
/dev/sdf8: LABEL="jessyDEB8" UUID="419cdbd5-10c5-4640-ba5e-594bdcfd66e9" TYPE="ext3"
/dev/sdf9: UUID="08245a6c-3189-4ba2-b1d5-be4fb4390398" TYPE="ext4"
/dev/sdf10: UUID="2c425dd3-aeb1-4703-a74f-6a30dba85ae1" TYPE="ext4"
/dev/sdf11: LABEL="acer" UUID="28d7760c-62f3-4071-9d5f-b0a7a0a849dd" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdf12: LABEL="BUSTER" UUID="aea773dd-1b7e-45f4-a767-a48db68cf949" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdf13: UUID="43539dc6-db9a-4c05-bda5-6286ec3c59d8" TYPE="ext3"
/dev/sdf14: UUID="ce6ea7ec-ade6-4f03-a488-a9e115e3d052" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdf15: UUID="78f51392-778f-4d9b-8590-5c82447c93ca" TYPE="ext4"
/dev/sdf16: UUID="164735b5-615e-4530-ae74-a4cf2b7b0746" TYPE="ext4"
/dev/sdf17: LABEL="space" UUID="f673c420-a012-434a-9e33-60586d65a485" TYPE="ext4"

and cat /proc/modules shows:
dm_mirror 22056 0 - Live 0xffffffffa010a000 (F)
dm_region_hash 20784 1 dm_mirror, Live 0xffffffffa0085000 (F)
dm_log 18411 2 dm_mirror,dm_region_hash, Live 0xffffffffa007f000 (F)
usb_storage 62062 0 - Live 0xffffffffa0221000 (F)
nouveau 943295 1 - Live 0xffffffffa0117000
mxm_wmi 13021 1 nouveau, Live 0xffffffffa00fe000
pata_acpi 13038 0 - Live 0xffffffffa007a000
wmi 19070 2 nouveau,mxm_wmi, Live 0xffffffffa0104000
video 19318 1 nouveau, Live 0xffffffffa00f8000 (F)
i2c_algo_bit 13413 1 nouveau, Live 0xffffffffa00a5000
ttm 83995 1 nouveau, Live 0xffffffffa00e2000
drm_kms_helper 52651 1 nouveau, Live 0xffffffffa00d4000
firewire_ohci 40060 0 - Live 0xffffffffa00c5000
forcedeth 67371 0 - Live 0xffffffffa00ad000
firewire_core 64476 1 firewire_ohci, Live 0xffffffffa0094000
crc_itu_t 12707 1 firewire_core, Live 0xffffffffa008f000 (F)
sata_nv 27716 1 - Live 0xffffffffa006d000
pata_amd 18225 0 - Live 0xffffffffa0063000
ohci_pci 13561 0 - Live 0xffffffffa0012000
drm 296739 3 nouveau,ttm,drm_kms_helper, Live 0xffffffffa0019000
floppy 69370 0 - Live 0xffffffffa0000000 (F)

I use the old partitions to run software that is no longer available, but only physically connect to the internet when running supported releases.

Thanks!
 
Old 12-31-2020, 06:45 PM   #12
mrmazda
LQ Guru
 
Registered: Aug 2016
Location: SE USA
Distribution: openSUSE 24/7; Debian, Knoppix, Mageia, Fedora, others
Posts: 5,788
Blog Entries: 1

Rep: Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065
I suggest you do this:
  1. Provide here output from lsusb.
  2. 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.
  3. Disconnect the USB multi-card reader from the USB bus.
  4. Boot something that allows you to see whether the WD is no longer /dev/sdf. If it turns up as /dev/sda,
  5. Shutdown, reconnect the multi-card reader, boot to find out if it remains the same. If it changes,
  6. Shutdown, move the multi-card reader to some other USB port, boot to find out what if anything changed.
  7. If necessary, move the multi-card reader to yet another port.
  8. 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.
 
1 members found this post helpful.
Old 01-03-2021, 11:36 AM   #13
scpeckham
LQ Newbie
 
Registered: Dec 2005
Distribution: Mint Cinnamon
Posts: 15

Original Poster
Rep: Reputation: 0
Hi,

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).

Thanks.
 
Old 01-03-2021, 05:24 PM   #14
mrmazda
LQ Guru
 
Registered: Aug 2016
Location: SE USA
Distribution: openSUSE 24/7; Debian, Knoppix, Mageia, Fedora, others
Posts: 5,788
Blog Entries: 1

Rep: Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065Reputation: 2065
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.
 
Old 01-08-2021, 03:31 PM   #15
scpeckham
LQ Newbie
 
Registered: Dec 2005
Distribution: Mint Cinnamon
Posts: 15

Original Poster
Rep: Reputation: 0
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] /dev/disk/by-uuid/<uuid here> does not exist and initramfs shell Mitt Green Linux - Kernel 4 08-03-2015 11:56 AM
ALERT! /dev/disk/by-uuid/.... does not exist. Dr. opping to a shell BEaSTFX Linux - Kernel 8 07-09-2012 07:32 PM
Alert ! /dev/disk/by-uuid/75800786-8994 does not exist. Drop to a shell NT64 Linux - Newbie 4 01-08-2012 10:39 AM
ALERT! /dev/disk/by-uuid/.... does not exist. Dr. opping to a shell! Deimon Linux - Kernel 1 01-05-2011 08:15 PM
ALERT! /dev/disk/by-uuid/ #### does not exist ubuntu 1:1.10.2 -1ubuntu7 please help pinged Linux - Laptop and Netbook 25 04-13-2009 06:57 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Debian

All times are GMT -5. The time now is 01:15 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration