Update pop-recovery.md

[VenRoot]

For newer versions, /sys/firmware/efi/efivars also needs to be binded before chrooting into the partition, or else update-initramfs or efibootmgr won't recognise your system as an EFI-system, causing anything boot related to fail, including update-initramfs

[jacobgkau]

update-initramfs or efibootmgr won't recognise your system as an EFI-system, causing anything boot related to fail

I don't think "causing anything boot related to fail" is accurate. Without this mount, I do see an error message from kernelstub that says Failed to retrieve NVRAM data. Are you running in a chroot?, which we are. It doesn't look like update-initramfs or efibootmgr themselves care, based on the output. This error does not prevent the system from booting. However, the error can be avoided by adding the mount you're suggesting, and it's probably a good idea in general to do that.

This will cause an error when running the for i in loop on non-EFI systems since the efivars directory will not exist. I think we should have a note about that so people running on non-EFI systems don't think something's wrong when they get that error message. (Alternatives would be either listing two commands, one for EFI and one for non-EFI, or including a check if the directory exists before mounting in the command. The latter would not be ideal since some users have to type these commands out manually.) We should also make this update in the Repair the Bootloader article (bootloader.md), only in the EFI sections.

[VenRoot]

Thanks for your message. The reason I created this PR is because as a somewhat experienced Linux user, I had to fix my PopOS install and it wasn't easy for me to get the solution.

so people running on non-EFI systems don't think something's wrong when they get that error message

Didn't think of that since the doc already tells to mount /boot/efi, so I didn't worry about it. Just tested it and trying to mount the missing efivars doesn't break the loop, it just warns that it doesn't exist, so it should be "fine" for non-efi users.

We should also make this update in the Repair the Bootloader article (bootloader.md), only in the EFI sections

Done, just pushed my commit.

Alternatives would be either listing two commands, one for EFI and one for non-EFI

Would be a good point if you bring up the point that some pop-users don't have an EFI-system. If users get confused about the "efivars doesn't exist" warning, they also will get confused by the warning, that /mnt/boot/efi doesn't exist or even potentially mounting the wrong partiton (sda1 would be /boot, /recovery or even / on non-efi systems).

I don't know how much it is appreciated to do bigger changes to the docs from a "someone" like me, since everyone has their own taste in grammar and phrasing, but I could try

Best regards

[jacobgkau]

Just tested it and trying to mount the missing efivars doesn't break the loop, it just warns that it doesn't exist, so it should be "fine"

This is the same behavior that kernelstub has without this PR: it shows an error message, but the rest of the operation still works. However, you have a good point about /boot/efi already being in the list. I'll test to confirm if non-EFI systems already had an error message, and if they did, then the new one's not an issue.

[ahoneybun]

@jacobgkau do you results of that testing? Is this PR still needed?

[jacobgkau]

Testing again, it looks like this was already fixed by 11db9e3 for the Recovery article by switching from -B to -R, which bind mounts recursively.

It would be simpler to just apply that update to the Bootloader article as well.

[jacobgkau]

Superseded by #1204 & #1248. Thank you for bringing this up.