Hi,

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.

Any idea??
Thanks

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.

Thanks for your replies.

here are the answers I am able to provide

@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

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.

1 members found this post helpful.

@ houbahop69
Below is the UUID shown in your /etc/fstab
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

1 members found this post helpful.

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

the prompt (initramfs) appears but is not active

Have I to reinstall????????
Thanks

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.

This is a bug in the kernel, there are many folks having issues with this:
ACPI / processor: Fix the return value of acpi_processor_ids_walk()
Now, Linux checks the duplicate processor ids at boot time based on the ACPI namespace. But, In fact, it doesn't work
Subject: linux-image-4.18.0-3-amd64: errors "Failed to get unique processor _UID"

1 members found this post helpful.

Hi,

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 ????

Thanks

What have you got there at the moment? There should be a grub directory with a file in it called grub64.efi or boot64.efi. Is it there?

Yes I think my /boot/efi is OK; except if some special DELL files are required in there.

At last my T5810 is up again with internal boot on this revision :
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
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 :
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

Some fresh news and a request :

Finally I have filled a bug report Debian Bug report : #919498
https://bugs.debian.org/cgi-bin/bugr...i?bug=919498#5

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

Thanks

Hi,

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.

/J

Try this place, I do see "linux-headers-4.18.0-3-common_4.18.20-2_all.deb"

Try adding this to your source.list and do apt update: deb http://ftp.debian.org/debian stretch-backports main

2 members found this post helpful.

Thanks to all for hints, advices, and help.

it seems that the problems where beyond ordinary user control. I have got a stable boot since the kernel image upgrade. I am running now and all boots have been clean and the behavior is normal