search

pop-os / beta

Pop!_OS Beta
359 stars 19 forks source link

Beta install removes rEFInd entries #222

Open CaseyNordcliff opened 3 years ago

CaseyNordcliff commented 3 years ago

Pretty much what the title says. After upgrading to the beta, the rEFInd entries for which UEFI partition I want to boot into are no longer there. The partitions themselves seem fine, and no data has been lost or corrupted, I just have to manually go through and choose is all. This might not end up being a bug, moreso just a byproduct of an OS install, but I just figured Id let it be known.

bobzhu418 commented 3 years ago

I don't think it removes the entry. It just places Pop!_OS 21.10 ahead of rEFInd Boot Manager in the boot list.

ArjenR commented 3 years ago

I too am observing this. It is actually the wrong refind my systems boots from. It looks as if the upgrade changed things in efivars. It configured the one in the 2nd partition whereas it should use the one in the 5th.

juanejot commented 3 years ago

I've found similarly (though not using rEFInd but rather the later semi-derivative OpenCore Legacy Patcher which installs OpenCore as a base (version 0.7.3 for current versions of the OC Legacy Patcher) that I experience a similar though not identical behavior (because the OpenCanopy GUI boot interface is different from that of rEFInd, and while much of the underlying bootloader is similar, they are not identical):

The GitHub pages for those two projects are https://github.com/dortania/OpenCore-Legacy-Patcher and https://github.com/acidanthera/OpenCorePkg . I don't suggest them as an alternative to rEFInd (which I have also used), but only for running (versions of) macOS on x86 systems for which they weren't originally intended. If you have rEFInd otherwise running well on your hardware, keep at it. I simply include this info in case System76 folks need to get in touch with dortania and/or acidanthera. I post here not to steal thunder, but simply due to the likely underlying similarity of the issue with a non-systemd-boot bootloader running before it. If it would be best to make my issue with OpenCore (Legacy Patcher) a separate one from this one already started with rEFInd, please let me know & I'm happy to remove it from this issue & start a new one.

Before describing the behavior, I should say I'm seeing it on an older Mac laptop running OpenCore Legacy Patcher versions 0.2.5 and 0.3.0, with macOS & Pop!_OS occupying separate partitions on the same laptop-limited drive, and I'm NOT seeing it on a much newer rig running OpenCore 0.7.4 and OSes on separate drives. Also of note (see below) is that the newer computer does not currently have OpenLinuxBoot.efi or ext4_x64.efi either installed or enabled at the moment; it's "just that good" at picking up that Linux is there (on a separate drive) to boot, and I have yet to install/configure software until/unless OC requires it. By contrast, the older laptop with OC LP does by install default, have LinuxOpenBoot.efi installed & properly referenced in config.plist to run, but not ext4_x64.efi. Yet… see workaround, below.

Once any update of the kernel for Pop!_OS 21.10 beta is completed on the laptop, with update-initramfs having done its job and (possibly new behavior; never noticed in 21.04) some combination of kernelstub & efibootmgr doing their business, apparently now by default), upon reboot I have a new boot selection that is selected by default, for "EFI." Booting to this selection never gets to a GUI, but the text at the bottom of the screenful of boot text says that it's reached a kernel panic. True to an original issue I've had with both Pop!_OS 21.04 final and 21.10 beta (only on the older machine), selecting the "Pop!_OS" boot selection always boots to the previous, not current, kernel. So how to get to the current kernel?

Workaround: For me, since OpenLinuxBoot.efi was already installed, I installed (from https://github.com/acidanthera/OcBinaryData) ext4_x64.efi and properly referenced it to run within config.plist, and that brought up a new "Pop!_OS 21.10" boot selection. Resetting NVRAM allowed me to get rid of the "EFI" selection that always kernel panicked when selected, and the system has worked well with "Pop!_OS 21.10" (current kernel) and "Pop!_OS" (previous kernel, same 21.10 OS) ever since. Booting/running of macOS has luckily (🤜🪵) worked through all of this as well as it can; which is to say hotly, loudly, and slowly (hence my interest in Pop!_OS!).