0

I have a dual boot system with Pop OS 20.04 and Windows 11 on the same 500GB SSD. I installed GRUB to make this work instead of using systemd bootloader, and everything worked smoothly for over a year, until I updated packages on Pop a few days ago.

Suddenly, rebooting gave me a black screen with the GRUB CLI. I was able to follow instructions given here to manually boot, but I had to do this every single time. To fix this, I got an Ubuntu 20.04 live USB and ran boot-repair from it, with the recommended settings. This appeared to run smoothly and said it reinstalled GRUB. Even after this, rebooting led me to the same CLI. I can confirm that boot-repair did something because I now had to manually boot with the efi directory under (hd2,gpt7) whereas it was earlier in (hd2,gpt8).

Here are the logs generated by boot-repair. It also showed this -

enter image description here

Which as far as I can tell, seems unrelated to my problems. The UEFI boot order seems to be right and has "pop" at the top. The other options lead to either just Pop or just Windows booting.

booega
  • 1
  • Post the link to the Summary Report that Boot-Repair runs in question above. – oldfred Nov 24 '22 at 22:25
  • @oldfred I have hyperlinked it in the question already, but here is the link again https://paste.ubuntu.com/p/y8CpxRyxtj/ – booega Nov 25 '22 at 07:37
  • A link that doesn't need login - https://pastebin.com/8h3Kg2C3 – booega Nov 25 '22 at 09:26
  • Boot-Repair says nvme0n1p8 is full You must resolve that first. Also Boot-Repair is installing grub, but you are booting with systemD boot. Do you want that change? Boot-Repair's most common fixes are related to grub, not sure if it knows SystemD boot?You also are showing two ESPs? – oldfred Nov 25 '22 at 16:00
  • @oldfred Should I clear nvme0n1p8 and run it again? I don't think I am booting with systemd, because its not top in my boot order - if it was selected then it would directly boot Pop everytime, I never configured dual boot with systemd. It opens GRUB CLI instead when I boot instead. If the two ESPs are on nvme0n1p8 and nvme0n1p7, I believe boot-repair is responsible for the latter, as it reinstalled it there. Pretty sure I had only one on p8 before. – booega Nov 25 '22 at 20:59
  • Your p2 & p7 are both ESP. Boot-Repair cannot create partitions. Either you with gparted or installer. And only way installer would create another ESP is if Windows or UEFI have locked ESP. Some systems can do that & Windows fast startup or bitlocker may also lock up ESP. Your p8 is your / (root) and it is the one that is full. You have one pop entry in p2 and others in p7. I might delete p7 and reinstall pop's boot loader unless you really want to convert to grub. I do not know systemD boot and do not think Boot-Repair can fix it. https://support.system76.com/articles/bootloader/ – oldfred Nov 25 '22 at 22:19

0 Answers0