pbear wrote: Sun Aug 13, 2023 11:05 pm
andy wrote: Sun Aug 13, 2023 3:27 pm
I would like to start to promote MX-Linux, instead of Linux Mint, to family and friends.
Come now, Ubuntu's boot repair utility is so unreliable that all guru helpers I've seen say to use it only for generating a report in difficult cases.
Hi
@pbear,
first warm thanks for your willingness to help and to provide information.
FWIW, fiddling around, MX's boot repair tool seems to work fine with encryption, but not something I've actually used as I don't like inscrutable black boxes. Are you interested in learning how to do this yourself? Meaning, command line, sometimes even chroot. If so, I probably can help. Disclaimer, though, that while I've tested repairing boot with encryption, I don't use btrfs.
Yes, I am interested, though, I primarily opened this topic to help testing and making MX-Boot repair better.
I have made a guide for myself in March 22, as I needed to repair my MX21.
I will post it here, maybe it will help someone.
But I suppose it is not complete for usage with BTRFS+subvolumes. Maybe some config files edit/ kernel parameters?
Code: Select all
System - repair BOOT
Repair boot on system with encrypted boot and root partitons
https://www.bleepingcomputer.com/forums/t/740193/how-to-repair-or-re-install-grub-using-the-chroot-command/
https://www.reddit.com/r/debian/comments/sb736l/how_to_installreinstall_grubefi_for_debian_1011/
https://forum.mxlinux.org/viewtopic.php?t=68831
Boot into recovery environment (e.g. USB Live)
(same Debian base as installation)
Open encrypted containers needed for boot
sudo cryptsetup luksOpen /dev/nvme0n1p8 boot_crypt -v
sudo cryptsetup luksOpen /dev/nvme0n1p6 rootMX -v
Setup chroot environment and do chroot
sudo mount /dev/mapper/rootMX /mnt/
sudo mount /dev/mapper/boot_crypt /mnt/boot
sudo mkdir -p /mnt/boot/efi/
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
sudo mount --bind /dev /mnt/dev
sudo mount --bind /dev/pts /mnt/dev/pts
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run
sudo chroot /mnt
Prompt changes to:
root@mx1:/#
Issue boot reinstall command.
Attention! Some guides promt to use these switches for grub-install:
--removable --no-uefi-secure-boot
Use only these as stated below:
grub-install --efi-directory=/boot/efi/ --bootloader-id=mx --target=x86_64-efi
update-grub
Exit chrooted environment,
dismount everything mounted earlier, in reversed order.
exit
sudo umount /mnt/run
sudo umount /mnt/sys
sudo umount /mnt/proc
sudo umount /mnt/dev/pts
sudo umount /mnt/dev
sudo umount /mnt/boot/efi/
sudo umount /mnt/boot
sudo umount /mnt
Reboot.
Then, thinking laterally, another suggestion. To my mind, a rEFInd USB drive is more useful than the various emergency boot tools. Importantly, in Linux, not dependent on the EFI partition(s), as it can boot directly from kernel images. Do you have a small flash drive you could use to give this a try? Or do you perchance use Ventoy? If so, there's a trick for using that as a rEFInd USB drive.
Yes, I even installed my MX-Libretto with Ventoy.
Sounds interesting, I'll investigate.
I suppose Boot Rescue Menus -> GRUB-EFI bootloader on the bootmenu of the Live media can do the same, because I have to point it to /boot partition, not EFI, to be able to boot my crippled MX-23.
Further, I will mention there's no need to delete EFI partitions. If you temporarily remove the boot/esp flags, the installer won't recognize them as EFI partitions. Will say, though, that while Ubuntu's installer (also used by Mint) always has had a bug as regards which EFI partition it uses, I can't recall having ever having run into that problem with MX's installer.
Thank for the info, it didn't come to my mind. Certainly more clever than delete
Last but not least, you don't need a separate EFI partition for each system. That's MBR thinking. A single EFI partition can host any number of boot loaders, limited only by available space. Bear in mind, you can only use one Linux boot loader at a time. From which Grub can boot any number of installed operating systems, using either os-prober or custom configfile entries. Or you could switch to rEFInd as your regular boot manager.
I allways had only one EFI partition, the more thing is only due to adding disks and retaining OSes on the old disk for a while.
If MX developers want me to test MX-Boot repair, I will gladly participate and I am willing to do new reinstalls of Windows and MX to simulate real life source of damage to MX/GRUB.
I want MX-Boot repair to be better.
If not now, I will move on, and solve the situation by myself.
(and maybe then I will reach you for help,
@pbear. Thank you again.)