Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

Caribou22 · 05-09-2023 12:20:38

Bonjour

Sur un Thinkpad L590 sous Debian 11 amd64, il m'était impossible de booter sur le dernier noyau Linux 5.10.179-5. En revanche le 5.10.179-4 fonctionnait.

Avec le dernier noyau, le démarrage bloquait immédiatement sur le message "loading initial ramdisk". J'ai tenté dans les options de grub d'activer nomodeset, de retirer splash, sans succès.

Je me suis dit (à tort peut-être ^^) que de toutes façons, il était temps de migrer vers la stable en espérant que ça résolve le problème. Mais j'ai toujours le même problème, aux versions de noyau près : désormais, ça bloque avec le dernier noyau (6.1.38-4) mais ça fonctionne avec le 5.10.179-5 !

Je n'ai pas trouvé d'où pouvait venir le problème. J'ai tenté de ré-installer grub, aussi sans succès.

Si vous avez des pistes, je suis preneur

Un grand merci d'avance !

captnfab · 05-09-2023 12:22:56

Plop,

Est-ce que l'initrd se génère sans problème ? Il n'y a pas de problème d'espace disque ?

Pour régénérer les initrd:

update-initramfs -u

Caribou22 · 05-09-2023 12:26:25

Merci

Apparemment oui :

update-initramfs -u

update-initramfs: Generating /boot/initrd.img-6.1.0-11-amd64

I: The initramfs will attempt to resume from /dev/nvme0n1p5

I: (UUID=f2df45b4-d492-47e9-aea2-9f7cf584c03e)

I: Set the RESUME variable to override this.

Précision, je suis donc booté sur le noyau 5.10 lorsque je lance cette commande.

Croutons · 05-09-2023 14:05:46

hello
ça donne quoi

blkid

Caribou22 · 05-09-2023 14:46:53

Croutons a écrit :

hello
ça donne quoi
blkid

Hello
Ceci :

/dev/nvme0n1p1: LABEL_FATBOOT="SYSTEM" LABEL="SYSTEM" UUID="9692-B7D1" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="76b201ef-d533-46ec-a29d-22dddf4879af"

/dev/nvme0n1p3: LABEL="Windows" BLOCK_SIZE="512" UUID="9E04950A0494E695" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="54586b14-3f28-41bf-b8a5-f6ccaa10cade"

/dev/nvme0n1p4: LABEL="WinRE_DRV" BLOCK_SIZE="512" UUID="82FA9531FA952309" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="0f747981-6e87-4f8f-af89-a93b045cbc3d"

/dev/nvme0n1p5: UUID="f2df45b4-d492-47e9-aea2-9f7cf584c03e" TYPE="swap" PARTUUID="e79f8408-9cf2-4333-b3ab-d3c2e11ebcc7"

/dev/nvme0n1p6: UUID="8efd2dcc-aad5-44b8-86e5-f7ecc9919ef5" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="2b73f2a3-417a-4b4a-b497-6d1680ee8025"

/dev/nvme0n1p2: PARTLABEL="Microsoft reserved partition" PARTUUID="d9c541d8-4c40-428f-b33f-2fcb5acdd4f5"

raleur · 05-09-2023 16:12:46

Il faudrait déterminer à quel stade le blocage se produit exactement : pendant le chargement de l'initramfs par GRUB ou après.
Pour tester le chargement de l'initramfs, au menu de GRUB appuyer sur "e" pour éditer l'entrée de menu, insérer # au début de la ligne commençant par "initrd" et appuyer sur F10 pour démarrer.
Si le noyau démarre et finit avec un kernel panic parce qu'il ne trouve pas la racine (normal), alors c'est le chargement de l'initramfs par GRUB qui coince.
Sinon, démarre en mode dépannage pour voir ce que ça dit.

Caribou22 · 05-09-2023 17:40:09

Yes, j'ai bien un kernel panic en commentant la ligne initrd !

Problème de chargement d'initramfs par GRUB donc.
En mode dépannage ça bloque à la même étape qu'en mode normal.

Dernière modification par Caribou22 (05-09-2023 18:29:14)

Caribou22 · 05-09-2023 18:29:43

J'ai trouvé cette discussion depuis, dont le problème semble similaire : https://www.debian-fr.org/t/loading-ini … lent/87832

Il y est question de régénérer l'initramfs, ce que j'ai fait :

update-initramfs -u

update-initramfs: Generating /boot/initrd.img-6.1.0-11-amd64

I: The initramfs will attempt to resume from /dev/nvme0n1p5

I: (UUID=f2df45b4-d492-47e9-aea2-9f7cf584c03e)

I: Set the RESUME variable to override this.

Sans amélioration malheureusement Pour info, /dev/nvme0n1p5 et UUID=f2df45b4-d492-47e9-aea2-9f7cf584c03e désignent tous les deux ma partition swap. Normal ?

Dernière modification par Caribou22 (05-09-2023 18:31:01)

raleur · 05-09-2023 18:52:47

Caribou22 a écrit :

Problème de chargement d'initramfs par GRUB donc.

Pour en être sûr, il faut faire un autre test. Toujours dans l'éditeur d'entrée de menu de GRUB:
- ajouter ces lignes après celle qui commence par "initrd" :

echo "booting now"

sleep 5

et F10 pour démarrer.
Le délai de 5 secondes permet de voir si GRUB affiche le message "booting now" après avoir fini de charger l'initramfs.

Caribou22 a écrit :

Il y est question de régénérer l'initramfs, ce que j'ai fait

Après avoir changé MODULES=most en dep dans initramfs.conf pour réduire la taille de l'initramfs. L'as-tu fait aussi ? Sinon tu avais déjà regénéré l'initramfs en #3 et ça n'avait rien changé.

Caribou22 a écrit :

/dev/nvme0n1p5 et UUID=f2df45b4-d492-47e9-aea2-9f7cf584c03e désignent tous les deux ma partition swap. Normal ?

Oui, le swap est utilisé pour l'hibernation et c'est l'initramfs qui est chargé de la reprise après hibernation (resume).

Caribou22 · 05-09-2023 19:04:09

Merci

GRUB affiche bien "booting now". Je n'ai pas encore remplacé modules=most par dép (je ne savais pas s'il y avait des inconvénients à le faire)

raleur · 05-09-2023 19:16:30

Donc GRUB ne plante pas pendant le chargement de l'initramfs. Soit c'est GRUB qui plante au moment de passer la main au noyau (mais pourquoi seulement après avoir chargé l'initramfs en mémoire ?), soit c'est le noyau qui plante en présence de l'initramfs (mais je suis surpris qu'il n'affiche aucun message en mode recovery).

Générer un initramfs compact avec MODULES=dep a deux inconvénients :
- update-initramfs essaie de déterminer les modules nécessaires au démarrage, mais il peut se louper et en oublier un
- l'initramfs ainsi généré ne fonctionnera pas forcément avec une machine différente.

Caribou22 · 05-09-2023 19:23:53

Oui, je confirme ne peux démarrer qu'en recovery (et en normal d'où j'écris ces lignes) avec le noyau précédent. Aucun message en recovery avec le dernier noyau, même en supprimant quiet splash sur la ligne linux de grub.

Dernière modification par Caribou22 (05-09-2023 19:39:01)

raleur · 05-09-2023 19:31:42

Euh, quiet et splash ne devraient pas être présents en recovery.
Et avec l'initramfs compact ?

Caribou22 · 05-09-2023 19:47:07

raleur a écrit :

Euh, quiet et splash ne devraient pas être présents en recovery.
Et avec l'initramfs compact ?

Au temps pour moi, ils ne sont pas présents en recovery. Pas d'amélioration avec l'initramfs compact (en normal et en recovery)

Pourquoi l'initramfs fonctionnerait avec un noyau mais pas avec l'autre ?

Dernière modification par Caribou22 (05-09-2023 19:47:35)

captnfab · 05-09-2023 20:02:03

Est-ce qu'il y a une différence dans ton /etc/default/grub entre les deux variables suivantes ?

GRUB_CMDLINE_LINUX_DEFAULT=

GRUB_CMDLINE_LINUX=

Caribou22 · 05-09-2023 20:04:37

captnfab a écrit :

Est-ce qu'il y a une différence dans ton /etc/default/grub entre les deux variables suivantes ?
GRUB_CMDLINE_LINUX_DEFAULT=
GRUB_CMDLINE_LINUX=

Oui ! Voici mon fichier /etc/default/grub :

# If you change this file, run 'update-grub' afterwards to update

# /boot/grub/grub.cfg.

# For full documentation of the options in this file, see:

#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0

GRUB_TIMEOUT=3

GRUB_DISTRIBUTOR='Debian'

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=f2df45b4-d492-47e9-aea2-9f7cf584c03e psmouse.elantech_smbus=0"

GRUB_CMDLINE_LINUX="acpi_osi=Linux"

GRUB_DISABLE_OS_PROBER="false"

# Uncomment to enable BadRAM filtering, modify to suit your needs

# This works with Linux (no patch required) and with any kernel that obtains

# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)

#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)

#GRUB_TERMINAL=console

# The resolution used on graphical terminal

# note that you can use only modes which your graphic card supports via VBE

# you can see them in real GRUB with the command `vbeinfo'

#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux

#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries

#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start

#GRUB_INIT_TUNE="480 440 1"

captnfab · 05-09-2023 20:09:10

Mhh, my bad, en relisant la doc je vois que GRUB_CMDLINE_LINUX est appliqué pour toutes les versions, et GRUB_CMDLINE_LINUX_DEFAULT pour toutes les versions aussi, sauf en recovery.
Donc ça ne devrait pas changer le comportement entre les deux versions du noyau.

Une autre idée: est-ce que la partition de resume est clean ? est-ce que l'ordi n'aurait pas tenté d'hiberner ? et seul le boot avec la version du noyau correspondant à l'hibernation tenterait de restaurer l'hibernation ?

Caribou22 · 05-09-2023 20:42:15

Ok ! J'ai tenté une hibernation avec le noyau précédent. Mise en hibernation et sortie d'hibernation sans problèmes. J'ai re-tenté de booter avec le dernier noyau ensuite. Pas de changement.

raleur · 06-09-2023 16:03:15

Qu'est-ce que ça donne en ajoutant le paramètre "dis_ucode_ldr" à la ligne de commande du noyau pour désactiver le chargement des microcodes ?

Caribou22 · 06-09-2023 18:13:13

Bonjour

Malheureusement ça ne change rien

Caribou22 · 06-09-2023 20:05:06

Au pire, je ferai une sauvegarde du /home puis une ré-installation, mais c'est toujours frustrant de contourner un problème sans savoir d'où il venait ^^'

captnfab · 09-09-2023 20:41:51

Mhh, je me demande si ça n'est pas https://bugs.debian.org/cgi-bin/bugrepo … ug=1042885
Ou un bug de microcode, vu ça… quel est ton CPU ?
Genre ça: https://github.com/intel/Intel-Linux-Pr … /issues/70

raleur · 10-09-2023 16:46:52

captnfab a écrit :

Mhh, je me demande si ça n'est pas https://bugs.debian.org/cgi-bin/bugrepo … ug=1042885

Je trouve ce rapport de bug très confus, mais je retiens l'idée du bug de (dé)compression de zstd.
Vérifier la valeur de COMPRESS dans /etc/initramfs-tools/initramfs.conf.
Si COMPRESS=zstd, changer à "gzip", reconstruire l'initramfs et redémarrer pour tester.

captnfab a écrit :

Ou un bug de microcode, vu ça

J'ai déjà demandé à Caribou22 de démarrer avec le paramètre "dis_ucode_ldr" pour désactiver le chargement du microcode et ça n'a rien changé.

Debian-facile

#1 05-09-2023 12:20:38

Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#2 05-09-2023 12:22:56

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#3 05-09-2023 12:26:25

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#4 05-09-2023 14:05:46

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#5 05-09-2023 14:46:53

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#6 05-09-2023 16:12:46

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#7 05-09-2023 17:40:09

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#8 05-09-2023 18:29:43

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#9 05-09-2023 18:52:47

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#10 05-09-2023 19:04:09

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#11 05-09-2023 19:16:30

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#12 05-09-2023 19:23:53

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#13 05-09-2023 19:31:42

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#14 05-09-2023 19:47:07

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#15 05-09-2023 20:02:03

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#16 05-09-2023 20:04:37

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#17 05-09-2023 20:09:10

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#18 05-09-2023 20:42:15

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#19 06-09-2023 16:03:15

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#20 06-09-2023 18:13:13

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#21 06-09-2023 20:05:06

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#22 09-09-2023 20:41:51

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

#23 10-09-2023 16:46:52

Re : Impossible de démarrer sur le dernier noyau: "loading initial ramdisk"

Pied de page des forums