Ubuntu 20.04 kernel upgrade -> encrypted Volume group cannot be found + crypttab empty

Я сегодня обновил, потом перезагрузил. В результате группа томов не может быть найдена, и она выпадает из BusyBox.

Я попытался:

• «vgchange -ay» из busybox -> ничего не сделал.

• Загрузка со старого ядра -> тот же результат.

• Затем я начал с живого CD.

Я нашел эту веб-страницу: Восстановление из незагружаемого корневого раздела LVM с шифрованием Ubuntu , но мой / etc / crypttab

Здесь вы видите, как структурирована файловая система:

Два твердотельных накопителя sda и sdb создают на контроллере 3ware массив raid 1 sdc. Затем на жестких дисках 2x 8 ТБ запускается программный бой 1 (который распознается BIOS, но к нему нельзя получить доступ (если я не знал, как) с live CD, даже если крипта на SSD открыта.

Итак, я думаю ... обо всем по порядку ... что мне нужно исправить группу томов, которая будет найдена во время загрузки.

Если я сначала разблокирую crypt & run sudo vgchange -ay на живом компакт-диске это выглядит многообещающе:

2 logical volume(s) in volume group "hal9999-vg" now active

Однако после перезагрузки все еще не удается найти группу томов.

Я читал, что эта проблема возникает в отношении LVM и initramfs, но я не хочу случайно возиться с моими файловыми системами, чтобы избежать больших проблем.

Тем временем я попытался этот ответ . Он залил мою crypttab, но update-initramfs -u -k all не удалось:

update-initramfs: Generating /boot/initrd.img-5.4.0-40-generic
cryptsetup: WARNING: target 'luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262' not
    found in /etc/crypttab
W: /sbin/fsck.crypto_LUKS doesn't exist, can't install to initramfs

После всего этого текущий статус:

Вывод lsblk -fs :

NAME                 FSTYPE            LABEL       UUID                                   MOUNTPOINT
loop0                squashfs                                                             /rofs
sda                  linux_raid_member hal9999:0   853e3329-6076-8398-e0d8-19149c7d0d64
sdb                  linux_raid_member hal9999:0   853e3329-6076-8398-e0d8-19149c7d0d64
sdc1                 vfat                          94B1-AF12
└─sdc
sdc2                 ext4                          bbb39977-bf4a-4d8b-b524-7c29a85471d0   /mnt/boot
└─sdc
sdd1                 vfat              XUBUNTU 18_ 849C-7AF8                              /cdrom
└─sdd
hal9999--vg-root     ext4                          17c06541-b952-41a2-b28d-b37e49771625   /mnt
└─luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262
                     LVM2_member                   JK4UPj-KdoV-yFe5-XBZW-cHFP-JCbV-JsLjPq
  └─sdc3             crypto_LUKS                   524c1ad6-fabe-4f32-9bb0-c8db1286b262
    └─sdc
hal9999--vg-swap_1   swap                          cd5a6a21-dea3-46a9-a524-e43de19c0587
└─luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262
                     LVM2_member                   JK4UPj-KdoV-yFe5-XBZW-cHFP-JCbV-JsLjPq
  └─sdc3             crypto_LUKS                   524c1ad6-fabe-4f32-9bb0-c8db1286b262
    └─sdc

/ etc / crypttab :

sdc3_crypt UUID=524c1ad6-fabe-4f32-9bb0-c8db1286b262 none luks,discard

data /dev/md0 /root/drive_key luks

/ etc / cryptsetup-initramfs / conf-hook :

#
# Configuration file for the cryptroot initramfs hook.
#

#
# KEYFILE_PATTERN: ...
#
# The value of this variable is interpreted as a shell pattern.
# Matching key files from the crypttab(5) are included in the initramfs
# image.  The associated devices can then be unlocked without manual
# intervention.  (For instance if /etc/crypttab lists two key files
# /etc/keys/{root,swap}.key, you can set KEYFILE_PATTERN="/etc/keys/*.key"
# to add them to the initrd.)
#
# If KEYFILE_PATTERN if null or unset (default) then no key file is
# copied to the initramfs image.
#
# Note that the glob(7) is not expanded for crypttab(5) entries with a
# 'keyscript=' option.  In that case, the field is not treated as a file
# name but given as argument to the keyscript.
#
# WARNING: If the initramfs image is to include private key material,
# you'll want to create it with a restrictive umask in order to keep
# non-privileged users at bay.  For instance, set UMASK=0077 in
# /etc/initramfs-tools/initramfs.conf
#

#KEYFILE_PATTERN=
CRYPTSETUP=Y

/ etc / fstab :

# /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>
UUID=524c1ad6-fabe-4f32-9bb0-c8db1286b262 /               ext4    errors=remount-ro 0       1
#/dev/mapper/hal9999--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sdc2 during installation
UUID=bbb39977-bf4a-4d8b-b524-7c29a85471d0 /boot           ext4    defaults        0       2
# /boot/efi was on /dev/sdc1 during installation
UUID=94B1-AF12  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/hal9999--vg-swap_1 none            swap    sw              0       0
#/dev/md0 /mnt/md0 ext4 defaults,nofail,discard 0 0
/dev/mapper/data /mnt/data ext4 defaults 0 2

Это похоже на диагноз " результаты update-initramfs -c -k all :

update-initramfs: Generating /boot/initrd.img-5.3.0-59-generic
cryptsetup: ERROR: Couldn't resolve device
    UUID=luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262
update-initramfs: Generating /boot/initrd.img-5.4.0-39-generic
cryptsetup: ERROR: Couldn't resolve device
    UUID=luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262
update-initramfs: Generating /boot/initrd.img-5.4.0-40-generic
cryptsetup: ERROR: Couldn't resolve device
    UUID=luks-524c1ad6-fabe-4f32-9bb0-c8db1286b262