MX-Boot repair & encrypted root

[andy]

Hi @pbear,
I have set up rEFInd on Ventoy.
Interestingly, it cannot restore boot functionality on my crippled MX-23 setup.
It seems MX-Boot repair (when recent version finally unlocked LUKS), did something to break things even more.
rEFInd did boot from the boot partition, beyond the point I unlock my root partition on LUKS, but then I got on console this:

Code: Select all

Scanning for BTRFS filesystems
done.
No root device specified. Boot arguments must include a root= parameter.
...
(initramfs) _

If I would somehow edit kernel boot parameters correctly, maybe it would boot.
MX-Boot repair must somehow destroy this information from /boot partition, because before its repair operation I was able to boot from the /boot partition, with the help of the Live menu, as I described above.

Anyway, when I got silence from developers (understandably, I see they have enough work, forums are busy) I have decided to reinstall it again, with the "correct" order: first Win, then MX.
(and discovered yet another bug in installer, which I reported.)
right now there is second reinstall running.
edit: it is done, booting correctly.
edit2: owww, I have got many "read-only filesystem" errors on console, GUI does not start.
(but this belongs to another thread, as this was subsequent reinstall on existing LUKS container, 2nd attempt)

I will investigate, how to pass kernel boot parameters in rEFInd.

I am very interested in encryption of /boot, and enabling secureboot.
I had it once on MX21, albeit without secureboot. (and was able to successfully repair its boot, like you see in my mini-tutorial above)

[andy]

Hi @Adrian,
may I ask, if:
1. is this supposed to work - repair the actual running system - thus without chroot-ing?
(should be simpler, because no chroot is needed)
2. is MX-Boot repair adapted to all variants of install - LUKS+BTRS+root on @ subvolume?

Or was my attempt to use it in these cases futile?

[pbear]

... but then I got on console this:

Hmm, testing (encrypted ext4 rather than btrfs), I get the same outcome. Would have sworn this worked previously. It's possible I did test and it's a new bug, but more likely my recollection is faulty. Frankly, if an encrypted system can't be booted from a rEFInd emergency drive, that to me would be another argument against system encryption (which I don't use and don't generally recommend). My encrypted test system boots fine from Grub, so this almost has to be a rEFInd problem. And, no, MX Boot Repair didn't trash your /boot partition. Grub scripts don't do that. I'd even go so far as to say they can't.

[andy]

...
And, no, MX Boot Repair didn't trash your /boot partition. Grub scripts don't do that. I'd even go so far as to say they can't.

But: Until I do repair, I was able to boot it, and immediately after, not.
How is that possible, if repair did not change anything?

edit: Encryption of root and even boot partions has its reason. Simplicity is not the priority, if you consider safety.

[pbear]

That's not how troubleshooting works. Before anything is considered a bug, it has to be replicated. For this sort of thing, a VM will do. Meanwhile, I've spent a couple hundred hours understanding Grub, precisely so I wouldn't have to rely on inscrutable black box apps. Moreover, encryption is notoriously unstable because it's so complicated. And, well, to be blunt, user error is a thing also.

[fehlix]

1. is this supposed to work - repair the actual running system - thus without chroot-ing?
(should be simpler, because no chroot is needed)

Don't think, that any MX tools are build or tested to be run within a chroot.
Even if you use Chroot-Rescue-Scann tool, which does provides some comfort to go int chroot,
this tools are meant to repair the system but not from running GUI tools.
Some tools may work in chroot, other may create bad side effects or even worse a disaster.

2. is MX-Boot repair adapted to all variants of install - LUKS+BTRS+root on @ subvolume?

You better show details what you mean with all variants.
The normal way as offered by the MX installer
with /@-root and /@home subvolumes have been tested.
And if something does not work you would need to give details,
in a reproducible way in order to identify the issue to be reproducible.

[andy]

That's not how troubleshooting works. Before anything is considered a bug, it has to be replicated. For this sort of thing, a VM will do. Meanwhile, I've spent a couple hundred hours understanding Grub, precisely so I wouldn't have to rely on inscrutable black box apps. Moreover, encryption is notoriously unstable because it's so complicated. And, well, to be blunt, user error is a thing also.

I agree on all you said. If developers are willing to take this matter, I will gladly assist. Until then, I think most reasonable for me is to give up on this particular matter.
Better to invest my time finding a way how to encrypt boot, on MX23 and BTRFS, if possible.

BTW, isn't it funny, how many years have passed and still no support for using Argon2 family PBKDFs in GRUB? On more passes, it should be much more robust against bruteforcing than PBKDF2.
Nowdays, PBKDF2 can be very weak for lower iteration counts and/or not very long passwords.
Argon2 is supported in KeePassXC, for example, so there do exist libraries, which offer this functionality. (I am not an expert, and I know not every library is suitable for using in GRUB, but it is certainly doable.)

It seems to me GRUB developement in this regard it is delibarately omitted.
It would be nice to have a setup resistible even against the evil maid attack, albeit not my threat model.
(I mean not against state-of-the-art variants of this attack. But not every potential adversary or hacker is a three letter agency)
EDIT: But... it certainly is not in the interest of these agencies to let average Joe use such encryption, which will cause unneeded troubles to them.

So if accessible with reasonable effort, why not to have benefit of it?

1. is this supposed to work - repair the actual running system - thus without chroot-ing?
(should be simpler, because no chroot is needed)

Don't think, that any MX tools are build or tested to be run within a chroot.
Even if you use Chroot-Rescue-Scann tool, which does provides some comfort to go int chroot,
this tools are meant to repair the system but not from running GUI tools.
Some tools may work in chroot, other may create bad side effects or even worse a disaster.

2. is MX-Boot repair adapted to all variants of install - LUKS+BTRS+root on @ subvolume?

You better show details what you mean with all variants.
The normal way as offered by the MX installer
with /@-root and /@home subvolumes have been tested.
And if something does not work you would need to give details,
in a reproducible way in order to identify the issue to be reproducible.

1. Edit: strikeout Yes, I have a feeling it is always supposed to be fired from the another system, I just wanted to be sure.
As previous versions of the tool were never able to unlock LUKS (for me), I started to think I am using it incorrectly, so trying every possibility, hence trying to run even from the system-being-repaired.

2. I have meant all setup combinations you allow in your installer.

Thank you for your answers. Ok, so if I will have plenty of spare time, I will try to replicate in a VM.

Just one thing comes to my mind: Since MX-Boot repair is a GUI tool, I suppose it is not intended for GRUB gurus, but for less experienced users, to help them potentially repair some errors, would you consider a good idea, to allow user to view the flow of internal probe commands and their output, used for gathering info, for internal logic to do actual repair, and, to allow dry run, which will list exact commands with their arguments, issued to repair?
Maybe hidden behind a checkbox named "Expert mode: show probe results", and "dry run only - show suggested repair."

It will be source of inspiration for some intermediate users, what can be done to diagnose problems, and maybe to send reports to experienced experts.
What do you think?

[andy]

1. is this supposed to work - repair the actual running system - thus without chroot-ing?
(should be simpler, because no chroot is needed)

Don't think, that any MX tools are build or tested to be run within a chroot.
Even if you use Chroot-Rescue-Scann tool, which does provides some comfort to go int chroot,
this tools are meant to repair the system but not from running GUI tools.
Some tools may work in chroot, other may create bad side effects or even worse a disaster.
...

Hi @fehlix, there is some misunderstanding here.
I reread your answer today morning, and realized, that yesterday I did not get what you said.
I see now, you did not get, what I was asking.

1. is this supposed to work - repair the actual running system - thus without chroot-ing?

I did not name "chroot-ing" in this context as an user made step, but as a mean what can your SW do, when doing repair.
I understand, that if repair SW is doing chroot internally, it cannot be run from chrooted environnment.
I can reformulate it:
1. is this supposed to work - repair the actual running system - by not running this tool from the another, live system, but from the very same (emergency booted) system which I want to repair?
(this is exactly what I have tried)

[andy]

Hi @fehlix,
sorry to bother you, please just give me clear yes/no, on this:

1. is this supposed to work - repair the actual running system - by not running this tool from the another, live system, but from the very same (emergency booted with the help of external tools) system which I want to repair?

or, by another words, is this tool designed to use in such circumstances?

[fehlix]

Hi @fehlix,
sorry to bother you, please just give me clear yes/no, on this:

1. is this supposed to work - repair the actual running system - by not running this tool from the another, live system, but from the very same (emergency booted with the help of external tools) system which I want to repair?

or, by another words, is this tool designed to use in such circumstances?

I guess the original design of mx-bootrepair was to regenerate GRUB boot loader and GRUB config (grub.cfg)
on a non booting system by gathering the mount situation based on fstab.
The tool may have some weakness in detection what subvolum "/" root is on within a running luks-btrfs system where "/" is mounted onto a subvolume, hence you may not see the option to select the current "/" when running mx-bootrepair from the same luks-btrfs running system.
So for emergency situations, you may try to run grub-install and update-grub from the terminal,
and double check grub detectes the correct subvolum to use as rootflags with the generated grub.cfg.