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.
During last update/upgrade of my buster package linux-image-4.19.0-1-amd64 has been installed and since the desktop cannot boot with this kernel. I have tried recovery mode with no success. The computer still boots and works perfectly with the previous kernel 4.4.18.
last message is :
Alert! cannot find UUID=********* (with the correct disk UID)
previous message says
gave up /scripts/local-block after many instances trying /scripts/local-block.
My Laptop boots with 4.4.19, the problem seems to hit this computer only.
the keyword here seems to be "testing".
i'm sure many debian testing users will tell you that
a) you have to expect occasional glitches like that
b) you should be able to provide more information, or even file a bug report.
This message comes from a script in the initramfs. Does it drop you to a prompt? If so, you could explore further. For example, is there a /etc/fstab file and does the problematic uuid occur in it? Is the correct root filesystem specified anywhere? The more information you can track down, the easier to fix the problem.
@ondoho /a I am working with debian testing distribs for some time and I have experienced "glitches" as you mentionned but it is the first time I suffer one that interrupts the booting process, freezes everything and appears only on one machine; that's why I dared asking the question.
@ondoho /b I cannot make any copy paste, so I have to copy by hand everything or reboot and look for information but I do not know which ones could be usefull.
@hazel The computer is freezed, the keyboard is inactive, my only solution has been on/off deadstart.
I have an etc/fstab that seems correct (the UUID given during the faulty event is the one quoted for /) thie configuration works as it is for kernel 4.4.18
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda1 during installation
UUID=b47a29e3-878e-4e0a-ac36-59cc0994c88f / ext4 errors=remount-ro 0 1
# /data was on /dev/sdb1 during installation
UUID=5b32e90a-3833-415d-8dc1-f425a8ed3ae3 /data ext4 defaults 0 2
# /home was on /dev/sda4 during installation
UUID=585c923e-7e95-4555-8aa2-f1c354efe311 /home ext4 defaults 0 2
# /opt was on /dev/sda3 during installation
UUID=a24cef5d-e101-4922-a6d8-4e3d7097a588 /opt ext4 defaults 0 2
# swap was on /dev/sda2 during installation
UUID=a1d44d7b-d2c7-4181-8107-bfa21dce1945 none swap sw 0 0
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
I can't understand what you request by "Is the correct root filesystem specified anywhere?"
fdisk says that the boot is present on first partition :
Disque /dev/sda*: 477 GiB, 512110190592*octets, 1000215216*secteurs
Modèle de disque*: INTEL SSDSC2KF51
Unités*: secteur de 1 × 512 = 512*octets
Taille de secteur (logique / physique)*: 512*octets / 512*octets
taille d'E/S (minimale / optimale)*: 512*octets / 512*octets
Type d'étiquette de disque*: dos
Identifiant de disque*: 0x873e57b7
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 * 2048 48828415 48826368 23,3G 83 Linux
/dev/sda2 48828416 80078847 31250432 14,9G 82 partition d'échange Linux / Solaris
/dev/sda3 80078848 128907263 48828416 23,3G 83 Linux
/dev/sda4 128907264 1000214527 871307264 415,5G 83 Linux
Disque /dev/sdb*: 1,8 TiB, 2000398934016*octets, 3907029168*secteurs
Modèle de disque*: ST2000DM001-1ER1
Unités*: secteur de 1 × 512 = 512*octets
Taille de secteur (logique / physique)*: 512*octets / 4096*octets
taille d'E/S (minimale / optimale)*: 4096*octets / 4096*octets
Type d'étiquette de disque*: dos
Identifiant de disque*: 0x527efacd
Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sdb1 2048 3907028991 3907026944 1,8T 83 Linux
Menu entries in grub seem identical between 4.4.18 and 4.4.19
menuentry 'Debian GNU/Linux, avec Linux 4.19.0-1-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.19.0-1-amd64-advanced-b47a29e3-878e-4e0a-ac36-59cc0994c88f' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 b47a29e3-878e-4e0a-ac36-59cc0994c88f
else
search --no-floppy --fs-uuid --set=root b47a29e3-878e-4e0a-ac36-59cc0994c88f
fi
echo 'Chargement de Linux 4.19.0-1-amd64…'
linux /boot/vmlinuz-4.19.0-1-amd64 root=UUID=b47a29e3-878e-4e0a-ac36-59cc0994c88f ro quiet
echo 'Chargement du disque mémoire initial…'
initrd /boot/initrd.img-4.19.0-1-amd64
}
}
menuentry 'Debian GNU/Linux, avec Linux 4.18.0-3-amd64' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.18.0-3-amd64-advanced-b47a29e3-878e-4e0a-ac36-59cc0994c88f' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 b47a29e3-878e-4e0a-ac36-59cc0994c88f
else
search --no-floppy --fs-uuid --set=root b47a29e3-878e-4e0a-ac36-59cc0994c88f
fi
echo 'Chargement de Linux 4.18.0-3-amd64…'
linux /boot/vmlinuz-4.18.0-3-amd64 root=UUID=b47a29e3-878e-4e0a-ac36-59cc0994c88f ro quiet
echo 'Chargement du disque mémoire initial…'
initrd /boot/initrd.img-4.18.0-3-amd64
Is that usefull? What can I do more to help.
Thanks again
@hazel The computer is freezed, the keyboard is inactive, my only solution has been on/off deadstart.
I have an etc/fstab that seems correct (the UUID given during the faulty event is the one quoted for /) thie configuration works as it is for kernel 4.4.18
I can't understand what you request by "Is the correct root filesystem specified anywhere?"
fdisk says that the boot is present on first partition :
What I meant is that in some distros, the init scripts use an internal variable to represent the real root device. If this variable is wrongly set, then the partition won't be found, regardless of what your /etc/inittab file shows. I ran into a problem like this in Debian, when a new installation of Slackware caused the swap partition to be renamed. Editing the new uuid into /etc/fstab had no effect. I had to update the initramfs to get the new name recognised by the startup scripts. But that doesn't seem to be your problem, since you say the uuid being looked for is the correct one.
If you haven't got a working terminal, then my previous advice won't help you. But you could try booting the old kernel and running update-initramfs (or whatever that command is called on your system) for the new one to see if the error will be corrected.
@ houbahop69
Below is the UUID shown in your /etc/fstab
Code:
# swap was on /dev/sda2 during installation
UUID=a1d44d7b-d2c7-4181107-bfa21dce1945 none swap sw 0 0
You say you can boot the system with 4.18.0.3 kernel, boot with this kernel and check file: /etc/initramfs-tools/conf.d/resume to see if there is a UUID present that does not match any UUID in /etc/fstab. If this is the case, try editing it to this: RESUME=none, then run command as root or sudo: update-initramfs -u -k all, try booting with kernel 4.19.0.1
Thanks for your time.
UID in /etc/initramfs-tools/conf.d/resume is exactly the value of swap UID in /etc/fstab
I did a update-initramfs -u -k all
and ....
no more boot with 4.18 and no boot with 4.19
I have a bunch of messages saying
acpi LNXCPU:bf: Failed to get unique processor _UID (0xff)
then
Gave up waiting for suspend/resume device
Gave up waiting for root file system device
common problems
- Boot args
- Check rootdelay
- Missing modules
ALERT! UUID=***(THE CORRECT UID HERE)**** does not exist
acpi LNXCPU:bf: Failed to get unique processor _UID (0xff)
ALERT! UUID=***(THE CORRECT UID HERE)**** does not exist
Have I to reinstall????????
You can try, if you have data you want to keep you can boot Ubuntu or Linux Mint live to get your data first. The good part about Ubuntu or Mint is you can right click on a folder and open it as root, this comes in handy.
The item in red quoted above tells the story, when I upgraded to kernel 4.18.0.3 I started getting ACPI related errors and booting the computer would hang for half a minute when these errors appeared. I reinstalled around Christmas at the same time the 4.19.0.1 kernel was part of Debian testing, the error messages still appear but my computer doesn't hang for more than a second and continues booting, so a reinstall certainly did help me.
I did two full reinstalls one legacy that did not boot at all then a EFI one that brought me back to the original situation.
If I boot with a live and chroot to the resident system things work perfectly but the internal boot is still impossible.
I think that the CPU detection comes from another problem but I cannot see where is the origin of my bug. now the system is clean, (formatted the / and the swap) and the /boot/efi has been created during the install.
Do I need to put some extra files in the /boot/efi ????
I tested 3 reboots by manually selecting 4.18, it seems stable but 4.19 still does not boot with the same "giving up" message. I reached this situation by formatting the "/", "swap" and "/opt" partitions, create a new structure with EFI and "/" partions only then install fresh system with
Quote:
firmware-buster-DI-alpha4-amd64-DVD-1.iso
From this point my guess is that 4.19.0 is buggy at least for my DELL-T5810 (with Xeon procs).
I have finally succeeded in finding poor guys in the same situation than me by searching the web with the terms :
Quote:
boot failed "Gave up waiting for suspend/resume device"
It seems that competent people are informed and dealing with the problem. Or at least had dealt with it in 2017, meaning that this is a revival of an old bug... https://bugs.debian.org/cgi-bin/bugr...?bug=860543#22.
I got my access to my machine late in the evening yesterday and I lacked energy to check the proposed tricks. Even if I am pretty sure of my interpretation, I have not enough skills to make a correct formal bug report and I am sure that somebody will do that better than me very soon. Kernel 4.20 is out and longterm is now 4.19.14, that may correct the bug, I'll test it as soon as it arrives in buster and react if things are still bad. If anyone close to debian dev team wants me to do more please let me know.
Thanks for the help and support
Last edited by houbahop69; 01-12-2019 at 11:14 AM.
I checked Sid 4.19 kernel that fails with the same errors
I have problems induced after the full reinstall : it is impossible to recover Virtualbox because linux-headers-4.18 are missing in buster. Does anybody knows how I can retrieve the linux-headers-4.18.0-3-amd64 package that has been removed from the official repositories
I had a similar problem about a week ago that my computer didn't recognize the LUKS encrypted hard drive with debian testing using the new kernel linux-image-4.19.0-1-amd64, but it worked with version 4.18 and all the UUIDs seemed fine. However, today after running apt upgrade it regenerated the /boot/initrd.img... image and now my computer finds the hard drive using the new kernel 4.19. I'm not sure which package triggered the rebuild of the initrd file, but maybe your initial problem is solved with the newest upgrade.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.