Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update pop-recovery.md #1083

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Update pop-recovery.md #1083

wants to merge 4 commits into from

Conversation

VenRoot
Copy link

@VenRoot VenRoot commented Nov 11, 2022

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 jacobgkau requested review from a team November 15, 2022 21:03
@jacobgkau jacobgkau self-assigned this Nov 15, 2022
@jacobgkau
Copy link
Member

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
Copy link
Author

VenRoot commented Dec 1, 2022

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
Copy link
Member

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.

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
@ahoneybun
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants