You are not logged in.
I'm trying to make a bootable backup of my system to a second internal SSD, hoping to automate the process once I understand all the necessary steps. The backup itself seems to be working as expected, but I'm having trouble booting from the drive. I'd like to be sure I have all the steps correct and am not overlooking something obvious.
Environment
Thinkpad T420, second SSD in ultrabay slot, on /dev/sdb
Kernel 5.12.15-arch1-1
Both SSDs set up with LVM over LUKS
With backup drive LUKS crypt open:
lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1 vfat FAT32 1501-C1FE 89.4M 55% /boot
└─sda2 crypto_LUKS 2 6c70f63d-dce3-4a70-baed-3f7cc7de2622
└─cryptlvm LVM2_member LVM2 001 lKotpA-wU5L-EfjU-Y04Q-RC5l-acyc-1d5xdr
├─vg-swap swap 1 20fca702-a7b2-4fe8-9ac6-199b1996f1c3 [SWAP]
├─vg-var ext4 1.0 c1661357-fc16-49fe-a9b9-714f3441ae95 3.6G 49% /var
├─vg-root ext4 1.0 8d1a3c0a-c8c4-44ba-ab81-8d6fd1486524 14.7G 48% /
└─vg-home ext4 1.0 34d012d7-94ca-4d86-a0e7-c48d6be40dc9 42G 18% /home
sdb
├─sdb1 vfat FAT32 B5EB-749E
└─sdb2 crypto_LUKS 2 35ea2452-c61e-4001-b920-62bd0ddac3af
└─cryptbak LVM2_member LVM2 001 4e1JLX-ImHR-2cMI-sObr-kJZY-5cdH-1TGwIN
├─vgbak-swap swap 1 713d83fd-47c0-41ae-ac46-35d2bed435a9
├─vgbak-var ext4 1.0 89150ad3-adbc-4cf4-a316-e0e5dff779dd
├─vgbak-root ext4 1.0 408efc99-c802-4d6c-a41c-a02ad9e482f9
└─vgbak-home ext4 1.0 6f52473d-cb2d-4f40-8e49-c8dec7346197Steps Taken
# cryptsetup open /dev/sdb cryptbak
# mkdir -p /mnt/backup
# mount /dev/mapper/vgbak-root /mnt/backup
# mkdir -p /mnt/backup/boot
# mount /dev/disk-by-uuid/B5EB-749E /mnt/backup/boot
# mkdir -p /mnt/backup/home
# mount /dev/mapper/vgbak-home /mnt/backup/home
# mkdir -p /mnt/backup/var
# mount /dev/mapper/vgbak-var /mnt/backup/var
# rsync -aAXH --info=progress2 --delete \
--exclude '/dev/*' \
--exclude '/proc/*' \
--exclude '/sys/*' \
--exclude '/tmp/*' \
--exclude '/run/*' \
--exclude '/mnt/*' \
--exclude '/media/*' \
--exclude 'lost+found/' \
/ /mnt/backup
# sed -i "s/1501-C1FE/B5EB-749E/g" /mnt/backup/etc/fstab
# sed -i "s/8d1a3c0a-c8c4-44ba-ab81-8d6fd1486524/408efc99-c802-4d6c-a41c-a02ad9e482f9/g" /mnt/backup/etc/fstab
# sed -i "s/c1661357-fc16-49fe-a9b9-714f3441ae95/89150ad3-adbc-4cf4-a316-e0e5dff779dd/g" /mnt/backup/etc/fstab
# sed -i "s/34d012d7-94ca-4d86-a0e7-c48d6be40dc9/6f52473d-cb2d-4f40-8e49-c8dec7346197/g" /mnt/backup/etc/fstab
# sed -i "s/20fca702-a7b2-4fe8-9ac6-199b1996f1c3/713d83fd-47c0-41ae-ac46-35d2bed435a9/g" /mnt/backup/etc/fstab
# arch-chroot /mnt/backup /bin/sh -c 'mkinitcpio -P && cat /boot/intel-ucode.img /boot/initramfs-linux.img > /boot/initramfs-linux-ucode.img && chmod +x /boot/initramfs-linux-ucode.img'
# umount -R /mnt/backup && rm -r /mnt/backup
# vgchange -q -a n vgbak && cryptsetup close cryptbak
# efibootmgr \
--create \
--disk /dev/sdb \
--part 1 \
--label "arch-backup" \
--loader \vmlinuz-linux \
--unicode 'cryptdevice=UUID=35ea2452-c61e-4001-b920-62bd0ddac3af:cryptbak root=/dev/vgbak/root resume=/dev/vgbak/swap rw initrd=\initramfs-linux-ucode.img' \
--verbose
# rebootAt this point the system boots to a black screen following the normal Lenovo bios splash screen and will not boot beyond this point unless I boot into bios and delete the "arch-backup" entry from the boot list.
I've seen this before as a result of issues with an EFI boot entry (my EFI implementation doesn't support multiple initrd's, which is why I'm applying microcode by concatenating images above), so I suspect that that may be what's going on here as well. However, this efibootmgr command is nearly identical to the one that I've used to create the working boot entry that I use every day with this system. The only differences are the actual cryptdevice UUID and LUKS container name and the use of '--disk' and '--part'.
If this had worked, I would expect to be able to set the backup entry below my usual one in the efibootmgr order, then reboot, hold f12, choose the "arch-backup" entry from the boot menu, and boot a clone of the system from the secondary SSD.
Is it possible that this EFI implementation doesn't support booting from a secondary internal drive? I can't imagine that this would be the case as I have been able to boot from removable media with no problems in the past, but stranger things have happened, I guess. Beyond that, anything else I should look at? I'm aware of potential issues with rsyncing from a live system, but I don't expect that this would cause the backup to be completely unbootable, especially as the symptoms are consistent with what I've seen in the past as a result of EFI boot issues.
And one more question: is chrooting into the backup and regenerating the initial ramdisk even necessary given that the backup will be booted on the same hardware?
Last edited by catniptwinz (2021-07-19 22:54:57)
Offline
After considerable trial and error, I've narrowed this down to an issue with the kernel command line in my EFI boot entry. I'm able to boot the backup as expected if I omit the "resume" parameter and create the entry with:
# efibootmgr \
--create \
--disk /dev/sdb \
--label "arch-backup" \
--loader \vmlinuz-linux \
--unicode 'cryptdevice=UUID=35ea2452-c61e-4001-b920-62bd0ddac3af:cryptbak root=/dev/vgbak/root rw initrd=\initramfs-linux-ucode.img' \
--verboseI'd really love to know why this is the case given that my original boot entry passes "resume" with no problems and the swap volume on my backup drive appears to be okay otherwise.
Offline