`--removable` in `grub-install` fails on some hardware

[Torxed]

The full thread can be found here: https://discord.com/channels/726808923662712894/726809631342592081/937766587044364321
But here are some exerpts:

• Log: https://0x0.st/oHEp.log

We'll need to detect the need for --removable or retry if it fails, here's the relevant code:

archinstall/archinstall/lib/installer.py

Line 770 in 1515fb9

if not (handle := SysCommand(f'/usr/bin/arch-chroot {self.target} grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB --removable')).exit_code == 0:

[timmypidashev]

I feel a good idea would be to enable the --debug flag just so people can get an idea of what went wrong with grub in the future, but its also just nice to see it compile. Makes me calm at least. This is just my opinion, won't fix the bug aforementioned above.
Problem with --debug is we would have to flush it to stream, might just add to the complexity of the command overall.

[Torxed]

We can in a pretty simplistic way add peak_output=True to any command we run, which will render it to stdout. We can do that for the grub commands.

I’m in the process of refactoring SysCommand so that the forking doesn’t break. Currently we’re getting quite lucky that it doesn’t run commands twice and stuff. So no one will know, but that needs to be addressed before people know :)

[timmypidashev]

Awesome, I look forward to that.

[Torxed]

I've added peak_output to the grub-install commands, which should give a more detailed although "spammy" output of what's going on. I've also added --debug to show in greater detail where it might fail.

This will for sure help us debug issues down the road, but at some point we'll have to remove this or pipe it somewhere.

This will fix the above mentioned issue, but not other grub issues.
But it will help to diagnose :)