Gave up waiting for root device après mise à jour

tarof · Juillet 29, 2016, 1:27pm

Salut,

Je possède un serveur chez moi (accès physique) tournant sous Debian 8 Jessie, possédant plusieurs services (ftp,nfs,seedbox,site web etc…).

Suite à une coupure d’électricité à cause de travaux , j’ai du rallumer mon serveur qui est resté allumé pendant au moins 2 mois
C’est là que j’ai une erreur au démarrage:
gave up waiting for root device.

voici l’erreur en entier.
Gave up waiting on root device. Common problems:

- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/disk/by-uuid/UUID does not exist.
Dropping to a shell!
modprobe: module ehci-orion not found in modules.dep


Busybox v1.21.1 (Debian 1:1:22.0-9+deb8u1) built-in shell (ash)
Enter 'help' for a list of built-in commands. 

/bin/bash: can't access tty; job control turned off
(initramfs) _

Je possède à coté un backup de mon serveur (.dd) mais qui malheureusement date de fin janvier: il y a eu pas mal de modifications depuis.

Néanmoins j’ai sauvegardé l’état actuel avec dd et rsync en branchant le ssd du serveur sur mon pc.

J’ai chrooté dans le ssd du serveur et tenté de réinstaller grub, à qui je pensais d’abord que c’était sa faute (le ssd étant chiffré, et ayant l’erreur avant de pouvoir rentrer la clé de déchiffrement, je ne pensais pas auparavant qu’il pouvait s’agir d’autre chose que grub.

Mais il s’est avéré qu’en remettant la sauvegarde de fin Janvier pour tester, elle démarre normalement tant que je ne fais pas de mises à jour.

Et dans ces mises à jour figure le paquet initramfs-tools.
Je suis à peu près certain que c’est lui qui pose problème.
Je sais à peu près ce qu’il est censé faire, et à quoi sert le initrd.img-3.16.0-4-686-pae dans ma partition de boot. C’est pour ça que je pense qu’il est la source de mon problème vu que c’est la seule chose qui change en dehors de la partition chiffré dont le problème ne peut venir de ce dernier car il apparaît avant que celui-ci ne soit déchiffré.

J’ai bien sur longtemps cherché sur le net pour trouver une solution, mais le fait de réinstaller grub ne change rien (ou alors je m’y prend mal).
Qu’est ce que le paquet initramfs-tools change exactement ? est-ce une bonne piste ?

Merci pour votre aide.

PascalHambourg · Juillet 29, 2016, 1:20pm

Je n’ai pas de Debian sous la main pour vérifier, mais c’est normal que le busybox d’un initramfs de Debian s’identifie comme provenant d’Ubuntu ?

Pour info, GRUB n’a besoin d’une passphrase que si /boot, qui contient le noyau vmlinuz-* et l’initramfs initrd.img-*, est chiffré (ce qui n’est pas supporté en standard par Debian 8).
Qu’est-ce qui est chiffré exactement sur ce disque ? La racine ? /boot aussi ? Un PV LVM (qui contient quoi) ?

tarof · Juillet 29, 2016, 1:24pm

c’est normal que le busybox d’un initramfs de Debian s’identifie comme provenant d’Ubuntu ?

ahem, non pas tout à fait. J’ai copié le message d’erreur depuis un fofo et je l’ai modifié pour qu’il soit comme le mien qui s’affiche, sauf que j’ai oublié de modifier ça.
C’est bien Debian qui s’affiche sur mon message d’erreur.

Qu’est-ce qui est chiffré exactement sur ce disque ?

Ce qui est chiffré est la racine, pas le /boot qui est sur une autre partition. Je l’ai fait au moment de l’installation de Debian.

La passphrase est censé m’être demandé pour déchiffré /dev/mapper/sdc3_crypt, qui contient la racine.

PascalHambourg · Juillet 29, 2016, 2:04pm

Et l’UUID du message d’erreur, à quoi correspond-il dans /etc/fstab ou /etc/crypttab ?

tarof · Juillet 29, 2016, 2:21pm

l’UUID du message d’erreur: a91e7a19-6f8c-421c-bc8b-a1de58ff3946

fstab
/dev/mapper/sdc3_crypt

crypttab
sdc3_crypt UUID=b405a283-fe58-4bbb-a18b-dbb96329a56b none luks

voici le grub.cfg au cas où

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

terminal_input console
terminal_output console
if [ "${recordfail}" = 1 ] ; then
  set timeout=-1
else
  if [ x$feature_timeout_style = xy ] ; then
    set timeout_style=menu
    set timeout=1
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
    set timeout=1
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
	set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-a91e7a19-6f8c-421c-bc8b-a1de58ff3946' {
	load_video
	insmod gzio
	if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
	insmod part_gpt
	insmod ext2
	set root='hd2,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-efi=hd2,gpt1 --hint-baremetal=ahci2,gpt1  4451428c-bafb-488f-b9f9-ed42cf0bc971
	else
	  search --no-floppy --fs-uuid --set=root 4451428c-bafb-488f-b9f9-ed42cf0bc971
	fi
	echo	'Loading Linux 3.16.0-4-686-pae ...'
	linux	/vmlinuz-3.16.0-4-686-pae root=UUID=a91e7a19-6f8c-421c-bc8b-a1de58ff3946 ro  quiet
	echo	'Loading initial ramdisk ...'
	initrd	/initrd.img-3.16.0-4-686-pae
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 'gnulinux-advanced-a91e7a19-6f8c-421c-bc8b-a1de58ff3946' {
	menuentry 'Debian GNU/Linux, with Linux 3.16.0-4-686-pae' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-686-pae-advanced-a91e7a19-6f8c-421c-bc8b-a1de58ff3946' {
		load_video
		insmod gzio
		if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
		insmod part_gpt
		insmod ext2
		set root='hd2,gpt1'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-efi=hd2,gpt1 --hint-baremetal=ahci2,gpt1  4451428c-bafb-488f-b9f9-ed42cf0bc971
		else
		  search --no-floppy --fs-uuid --set=root 4451428c-bafb-488f-b9f9-ed42cf0bc971
		fi
		echo	'Loading Linux 3.16.0-4-686-pae ...'
		linux	/vmlinuz-3.16.0-4-686-pae root=UUID=a91e7a19-6f8c-421c-bc8b-a1de58ff3946 ro  quiet
		echo	'Loading initial ramdisk ...'
		initrd	/initrd.img-3.16.0-4-686-pae
	}
	menuentry 'Debian GNU/Linux, with Linux 3.16.0-4-686-pae (recovery mode)' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.16.0-4-686-pae-recovery-a91e7a19-6f8c-421c-bc8b-a1de58ff3946' {
		load_video
		insmod gzio
		if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
		insmod part_gpt
		insmod ext2
		set root='hd2,gpt1'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt1 --hint-efi=hd2,gpt1 --hint-baremetal=ahci2,gpt1  4451428c-bafb-488f-b9f9-ed42cf0bc971
		else
		  search --no-floppy --fs-uuid --set=root 4451428c-bafb-488f-b9f9-ed42cf0bc971
		fi
		echo	'Loading Linux 3.16.0-4-686-pae ...'
		linux	/vmlinuz-3.16.0-4-686-pae root=UUID=a91e7a19-6f8c-421c-bc8b-a1de58ff3946 ro single 
		echo	'Loading initial ramdisk ...'
		initrd	/initrd.img-3.16.0-4-686-pae
	}
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###

### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/30_uefi-firmware ###
### END /etc/grub.d/30_uefi-firmware ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###

Lorsque je branche le ssd du serveur sur mon pc, voici ce que donne blkid (je n’ai mis que pour sdc, qui est le ssd du serveur)

/dev/sdc1: UUID="4451428c-bafb-488f-b9f9-ed42cf0bc971" TYPE="ext4" PARTUUID="ba1c85aa-25a7-4c30-9db9-4a51b67f8155"
/dev/sdc3: UUID="b405a283-fe58-4bbb-a18b-dbb96329a56b" TYPE="crypto_LUKS" PARTUUID="26bfc923-8f6b-4f3b-9521-a3413f271712"
/dev/mapper/luks-b405a283-fe58-4bbb-a18b-dbb96329a56b: UUID="a91e7a19-6f8c-421c-bc8b-a1de58ff3946" TYPE="ext4"

ça pourrait-être ça non ? avant la mise à jour /dev/mapper/luks-b405a283-fe58-4bbb-a18b-dbb96329a56b était nommé /dev/mapper/sdc3_crypt et avait comme uuid a91e7a19-6f8c-421c-bc8b-a1de58ff3946

forcémment si l’uuid a changé grub ne va pas détecté l’ancien uuid. Faut-il que je change grub.cfg ou crypttab ?

PascalHambourg · Juillet 29, 2016, 2:39pm

Aucun UUID n’a changé. La seule chose sur laquelle j’ai un doute, c’est si l’option root= passée par GRUB dans la ligne de commande du noyau vmlinuz peut être l’UUID du système de fichiers racine ou doit être le nom du volume chiffré.

Le paquet cryptsetup est-il bien installé ? Est-il bien inclus dans l’initramfs généré suite à la mise à jour (vérifier la présence du fichier /etc/crypttab et de la commande cryptsetup dans le fichier /boot/initrd.img-3.16.0-4-686-pae avec la commandelsinitramfs, ou bien depuis le shell de l’initramfs après l’erreur) ?

tarof · Juillet 29, 2016, 2:48pm

Aucun UUID n’a changé

Autant pour moi, c’est le nom qui m’a prêté confusion.

en faisant ls /etc à partir du shell initramfs je n’ai pas le fichier etc/crypttab.

PascalHambourg · Juillet 29, 2016, 3:07pm

C’est gênant (euphémisme). La commande cryptsetup est-elle présente ?

tarof · Juillet 29, 2016, 3:11pm

/bin/sh: cryptsetup: not found
(commande dans le shell de initramfs)

Je me demandais: ça ne suffirait pas de copier/coller le /boot/initrd.img-3.16.0-4-686-pae de l’ancienne version sur la nouvelle ? enfin ça fait un peu barbare ^^

PascalHambourg · Juillet 29, 2016, 3:17pm

Tu pourrais mais ça ne tiendrait que jusqu’à la prochaine regénération de l’initramfs, ce n’est pas viable. Il vaudrait mieux trouver pourquoi cryptsetup n’est pas inclus.

Le paquet cryptsetup est-il encore installé dans le système ?

tarof · Juillet 29, 2016, 3:23pm

(par chroot)

#cryptsetup --version 
#cryptsetup 1.6.6

Il est bien installé sur le système.

PascalHambourg · Juillet 29, 2016, 3:37pm

Cela indique que la la commande est présente, pas le paquet.

La commande cryptsetup fait partie du paquet cryptsetup-bin qui peut être installé sans le paquet cryptsetup. Les scripts qui lisent /etc/crypttab et intègrent ce qu’il faut dans l’initramfs sont dans le paquet cryptsetup dont il faut vérifier la présence. Par exemple :

dpkg -l cryptsetup

tarof · Juillet 29, 2016, 3:58pm

  Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
    | État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
    |/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
    ||/ Nom                            Version              Architecture         Description
    +++-==============================-====================-====================-==================================================================
    ii  cryptsetup                     2:1.6.6-5            i386               disk encryption support - startup scripts

PascalHambourg · Juillet 29, 2016, 4:13pm

Là, je sèche…

tarof · Juillet 29, 2016, 4:42pm

J’ai testé en écrasant le nouveau /boot/initrd.img-3.16.0-4-686-pae par l’ancien de la sauvegarde de fin Janvier et ça marche.
Mais bon comme tu l’as dit ce n’est pas une solution fiable.
En tout cas je vais rester comme ça pour l’instant tant que je n’aurais pas trouvé la solution.
Ce qui tombe bien c’est que mon serveur, comme la plupart des serveurs, n’a pas être souvent redémarré ^^
merci en tout cas pour ton aide et ta réactivité

PascalHambourg · Juillet 29, 2016, 11:07pm

En fait update-initramfs -u n’écrasera pas un initramfs différent de celui qu’il a créé en dernier, considérant alors qu’il a été installé manuellement, à moins de le forcer avec l’option -t. L’ennui est qu’il contient des fichiers potentiellement obsolètes.

Apparemment il y a des conditions pour que cryptsetup soit inclus dans l’initramfs généré. D’après la page de manuel de crypttab, que la racine ou le swap servant à l’hibernation soit dans un volume chiffré en est une. Dans le cas contraire, on peut forcer en ajoutant initramfs à la liste des options du volume considéré dans /etc/crypttab ; luks deviendrait donc luks,initramfs. Il faut aussi que le volume en question soit ouvert lors de la création de l’initramfs, ce dont la justification m’échappe mais qui est forcément le cas pour la racine.

Je t’ai fait vérifier la présence de crypttab dans l’initramfs mais c’était une erreur ; la liste des volumes chiffrés à ouvrir lors de l’exécution de l’initramfs est dans /conf/conf.d/cryptroot.