One of the most recent sparky-aptus-upgrade wipes out old boot-loader and prompts you to install new boot-loader . It suggests the options vda,vda2 (/boot ext4),vda3 ("/" btrfs) , neither one of options suggested is correct due to /boot/efi is mounted on /dev/vda1. The workaround is to reject install new boot-loader and wait until sparky-aptus-upgrade would exit warning you that boot-loader is missing. Then initiate ssh session to instance of Sparky Linux and issue
$ sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=sparky --recheck && \
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable && \
sudo update-grub
root@devs-SVX8664:~# lsblk -o NAME,FSTYPE,MOUNTPOINT,PARTTYPE | grep -i c12a7328
├─vda1 vfat /boot/efi c12a7328-f81f-11d2-ba4b-00a0c93ec93b
├─vda2 ext4 /boot c12a7328-f81f-11d2-ba4b-00a0c93ec93b
root@devs-SVX8664:~# find / -name grubx64.efi -print
/boot/efi/EFI/sparky/grubx64.efi
/boot/efi/EFI/debian/grubx64.efi
/boot/efi/EFI/boot/grubx64.efi
/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi
$ sudo reboot
This step is important for successful executing of disaster recovery procedure on Sparky Linux 2026 06 instance with "/" on BTRFS . All commands below are supposed to run in Sparky Live Instance environment against Sparky instance been crashed on vda device (VENV simulation)
***************************************************** Phase 1 (in general, standard step utilizing low level btrfs CLI)
*****************************************************
mount -o subvol=@ /dev/vda3 /mnt/system-root
# 6. Mount dedicated boot partition
mount /dev/vda2 /mnt/system-root/boot
# 7. Wipe and re-create the corrupted FAT32 EFI partition
mkfs.vfat -F32 /dev/vda1
# 8. Mount the freshly formatted EFI partition
mount /dev/vda1 /mnt/system-root/boot/efi
# 9. Bind-mount required virtual filesystems
for i in /dev /dev/pts /proc /sys /run; do mount -B $i /mnt/system-root$i; done
# 10. AUTOMATIC FSTAB REPAIR: Fixed regex for FAT32 UUID matching
NEW_UUID=$(blkid -s UUID -o value /dev/vda1)
sed -i -E "s/UUID=\S+(.*\/boot\/efi)/UUID=$NEW_UUID\1/" /mnt/system-root/etc/fstab
# 11. Enter the restored operating system jail and restore both EFI targets
chroot /mnt/system-root /bin/bash -c "
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=sparky --recheck && \
grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable && \
update-grub
"
# 12. Clean up and restart
cd /
umount -R /mnt/system-root
umount -R /mnt/btrfs-top
poweroff
UPDATE as of 07/03/26
How CachyOS Execute the Restore via CLI (ssh remote connection)
If you are connected via SSH to the read-only instance, btrfs-assistant provides a minimal CLI wrapper explicitly built for execution when a GUI environment is unavailable.
First list the available snapshots. Run the following command to check your index numbers:
$ sudo btrfs-assistant --list
Second restore your target snapshot to roll back the root system to your desired state (e.g. snapshot with <ID>), invoke the restore command using its target index: $ sudo btrfs-assistant --restore <ID>
When you trigger the restore, btrfs-assistant uses its built-in logic to handle the layout flawlessly: It safely detaches or mirrors the nested subvolumes (.snapshots, var/lib/portables,var/lib/machines) out of the active path. It backs up your current broken @ layout into a secondary subvolume (often named root_broken either root_backup). It creates a fresh, fully writable clone of selected snapshot directly under subvolume ID 5 named @.It seamlessly migrates your nested .snapshots infrastructure back under the newly restored @ layout
END UPDATE
No comments:
Post a Comment