Ne démarre pas (dépose sur busybox) après la mise à niveau du noyau (avec des disques chiffrés)
J'ai deux systèmes - un 14.04.03 LTS et un 16.04 LTS, qui ne démarrent pas après les dernières mises à jour du noyau. Toute aide serait appréciée - je ne suis pas un expert, mais il me semble que le nouveau noyau ne voit tout simplement pas les systèmes de fichiers cryptés au démarrage.
Pour les deux systèmes, j'ai utilisé le programme d'installation pour chiffrer le lecteur de démarrage. Plus tard, j'ai ajouté un deuxième disque, chiffré à l'aide de LUKS, monté automatiquement au démarrage à l'aide d'un fichier de clés. Je (à peu près - a été fait après que le système a été installé et démarré) ai suivi les instructions ici:
Voici quelques détails supplémentaires sur les systèmes:
Pour le système 16.04 LTS:
Le matériel est un SSD mSATA sur /dev/sdb, sur lequel Ubuntu a été installé à l’aide de la configuration automatique de la partition (/ et de la permutation). Un lecteur Sata de 500 Go sur /dev/sda est utilisé pour /data - une fois le système en marche et opérationnel, la partition luks a été créée et configurée pour un montage automatique au démarrage avec un fichier de clés.
$ uname -a
Linux <hostname> 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 X86_64 GNU/Linux
$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/sdb2 during installation
UUID=5039XXXX-XXXX-XXXX-XXXX-d2b4XXXXXXXX /boot ext2 defaults 0 2
# /boot/efi was on /dev/sdb1 during installation
UUID=1DXX-XX4D /boot/efi vfat umask=0077 0 1
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
# encrypted disk /data (unlocked with keyfile
/dev/mapper/data_crypt /data ext4 errors=remount-ro 0 1
$ cat /etc/crypttab
sdb3_crypt UUID=0bg9rz-XXXX-XXXX-XXXX-XXXX-XXXX-XXqvBH none luks
data_crypt UUID=453cXXXX-XXXX-XXXX-XXXX-6926XXXXXXXX /root/<keyfile> luks
Lorsque 4.4.0-21 est sélectionné dans grub, une invite de mot de passe à déverrouiller sdb3_crypt apparaît immédiatement. Le système se bloque alors à l'invite de démarrage d'ubuntu. Appuyer sur delete affiche le message d'erreur suivant. Après quelques minutes, le système démarre réellement et data_crypt est monté sur /data comme prévu.
[ 2.091698] [drm:intel_set_pch_fifo_underrun_reporting [i915]] ERROR uncleared pch fifo underrun on pch transcoder a
[ 2.091735] [drm:intel_pch_fifo_underrun_irq_handler [i915]] ERROR PCH transcoder A FIFO underrun
lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
cannot process volume group ubuntu-vg
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
Reading all physical volumes. This may take a while...
Found volume group "ubuntu-vg" using metadata type lvm2
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
WARNING: failed to connect to lvmetad. Falling back to internal scanning.
2 logical volume(s) in volume group "ubuntu-vg" now active
/dev/mapper/ubuntu--vg-root: clean 488960/6750209 files, 11825728/26996736 blocks
[ ***] A start job is running for dev-disk-by\x2duuid-0bg9rZ\X2deNSE\x2d1E8u\x2XXXXX\x2XXXXX\x2XXXX\x2dZpqvBH.device (xxS / 1min 30s)
Dans le menu Grub, sélectionnez 4.4.0-22 ou 4.4.0-24, puis appuyez sur Supprimer pour afficher les informations suivantes (transcrites):
[ 2.091698] [drm:intel_set_pch_fifo_underrun_reporting [i915]] ERROR uncleared pch fifo underrun on pch transcoder a
[ 2.091735] [drm:intel_pch_fifo_underrun_irq_handler [i915]] ERROR PCH transcoder A FIFO underrun
lvmetad is not active yet, using direct activation during sysinit
Volume group "ubuntu-vg" not found
cannot process volume group ubuntu-vg
/run/lvm/lvmetad.socket: connect failed: no such file or directory:
WARNING: failed to connect to lvmetad. Falling back to internal scanning.
Reading all physical volumes. This may take a while.
Les 3 dernières lignes se répètent peut-être une trentaine de fois et, au bout de quelques minutes, passent à un shell busybox. Exécuter manuellement cryptsetup luksOpen /dev/sdb3 sdb3_crypt (et entrer la phrase secrète) est correct, mais je ne peux pas le monter (probablement parce que c'est dans initramfs et que je ne sais pas ce que je fais là).
La suppression de lignes relatives à data_crypt de /etc/fstab et /etc/crypttab ne fait aucune différence, je ne pense donc pas que cela soit lié au montage automatique de ce disque posant problème.
J'ai aussi essayé de recréer les initramfs pour ces noyaux, ce qui n'a fait aucune différence.
Je rencontre également un problème similaire sur un système 14.04.03 LTS, comme décrit ci-dessous, mais je ne peux pas fournir de détails exacts (c’est le système à partir duquel je publie ce message).
Pour le système 14.04.03 LTS:
Le matériel est un SSD NVMe pour / et un swap, et un disque SATA de 1 To pour /data. Encore une fois, Ubuntu a été installé sur le disque SSD, puis le disque SATA a été connecté, configuré en tant que partition chiffrée à l'aide de luks, puis ajouté au montage automatique au démarrage avec un fichier de clés.
les paquets pour le noyau xenial ont été installés:
linux-generic-lts-xeniallinux-headers-generic-lts-xeniallinux-image-generic-lts-xenial
Sortie de commande:
Linux hostname 4.2.0-36-generic #42~14.04.1-Ubuntu SMP Fri May 13 17:27:22 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/ubuntu--vg-root / ext4 errors=remount-ro 0 1
# /boot was on /dev/nvme0n1p2 during installation
UUID=0657XXXX-XXXX-XXXX-XXXX-1be3XXXXXXXX /boot ext2 defaults 0 2
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=AEXX-XX66 /boot/efi vfat defaults 0 1
/dev/mapper/ubuntu--vg-swap_1 none swap sw 0 0
# encrypted disk /data (unlocked with keyfile
/dev/mapper/data_crypt /data ext4 errors=remount-ro 0 1
$ cat /etc/crypttab
nvme0n1p3_crypt UUID=61235695-XXXX-XXXX-XXXX-962cXXXXXXXX none luks,discard
data_crypt UUID=2e92XXXX-XX57-XXXX-XXXX-af9fXXXXXXXX /root/<keyfile> luks
L'un des noyaux de la série 4.4 ne parvient pas à démarrer. Le noyau de la série 4.2 démarre bien.
J'ai eu un problème similaire sauf que mon /etc/crypttab était complètement absent. Récemment, j'avais mis à niveau mon disque dur mécanique sur un SSD. Sur tous les deux j'ai tout sauf /boot chiffré, et le processus de démarrage fonctionnait parfaitement. De plus, j'ai vérifié une sauvegarde de quelques semaines auparavant et crypttab était présent à ce moment-là.
J'ai suivi la réponse à ce post pour résoudre mon problème.
réinstaller sur des partitions chiffrées existantes
Notez le commentaire concernant trois des montures. Ceux-ci sont faux et devraient être:
# mount --bind /dev /mnt/ubuntu/dev
# mount --bind /sys /mnt/ubuntu/sys
# mount -t proc none /mnt/ubuntu/proc
Notez également que l'UUID dans crypttab doit être pour le conteneur qui contient le volume LUKS (dans mon cas, /dev/sda5), pas pour le volume LUKS après son déchiffrement. (Il dit ça, mais ça m'a manqué la première fois, alors j'ai pensé le signaler.)
Note finale, je dois dire que ce mauvais comportement de la part du programme de mise à jour - rendre l'ordinateur non amorçable - est le genre de problème qui empêche Linux de toucher un public plus large parmi les utilisateurs de bureau classiques.
Ok, compris.
L'UUID de sdb3_crypt (où/et le swap sont situés) n'était pas correct dans/etc/crypttab. J'ai vérifié cela en comparant les UUID répertoriés dans/etc/crypttab avec ceux répertoriés dans/dev/disk/by-uuid /. Je ne sais pas du tout comment cela s'est mal passé, mais j'ai dû prendre le doigt quelque part en chemin.
J'ai corrigé/etc/crypttab avec le bon UUID de/dev/sdb3, puis mis à jour initramfs ($ update-initramfs -c -k 4.4.0-24-generic). Redémarrez et maintenant cela fonctionne bien.