-
Notifications
You must be signed in to change notification settings - Fork 85
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
galp5 - 2021-09-20 FW build - boot entries disappearing. #246
Comments
Does it happen reliably? Verify the SMMSTORE is being cleared:
If you can, after every boot (need it before and after boot entries disappear), dump the CMOS to see what values changed:
|
Just wanted to +1. I experience the same phenomenon on both FW versions. The only OS which has stayed reliably is Ubuntu 20.04. I don't have the expertise to debug but I'll try the steps provided by @crawfxrd |
Sorry, I just don't have that much time to troubleshoot this issue, but today I had some time to look into this. Very first line gave me an error: Sure enough, there is nothing inside the coreboot directory. I did a new git clone https://github.com/system76/firmware-open/ |
Did you run the |
No, but I'll give it a try now. I just reinstalled Windows and Pop!_OS 21.04. I may not be using my eGPU anymore (cable is bad, not very stable, more trouble than it's worth), but what I've noticed is that soemtimes when I have a device in the USB port on the left side (USB-A or the USB-C), the laptop doesn't respond to the ESC key to go into the boot menu. I noticed this when I was reinstalling the OSes. Also, when this happens, the boot entries get cleared. Even after a clean install of both OSes, Windows Boot Manager is now gone. I'm not sure why this is happening, and it's frustrating. I want to reiterate: I'm not a developer or coder. My knowledge goes as far as Windows batch files, and barely just learning bash script (just to automate some things). I'm not all that familiar with git. If you need me to do something, please give me a step-by-step. I will eventually learn as I go along, but I wanted to set expectations. |
After running I ran the next line I get command not found. |
It looks like those two last lines should be |
I'm actually trying this: I removed the NVME drive and flashed this firmware via a USB drive. I then updated to the current available firmware (2021-07-20). I'm going to reinstall the OSes again and see if this fixes the issue. Would using Ventoy be an issue? I don't think it should, but figured I'd ask anyways. Update: it didn't work. After installing PopOS, then, Windows 11 (Win11 install.wim in Win 10 ISO to avoid restrictions), boot entries are gone. I'm getting really frustrated with this. :( |
I'll give this a try when I can gather the energy to try again. |
You said to run it before and after if I can. I'm assuming only running the last two lines before and after, right? Because after "make", the toil is already compiled so no need to recompile again for the after? make -C coreboot/util/nvramtool Before boot entries disappear (ex: after running bootrec /fixmbr and whatever the Linux version of the fix bootloader command for system-d?) And then after? |
That support article is for a very specific issue and should not be used here.
That should be correct, although running the |
I don't remember how to recreate the Linux boot loader, but I did add the Windows one at least. Here I confirm it shows up in efibootmgr, then I ran the two commands. After this, I'm going to reboot and run the commands again after confirming the boot entry is gone. zeddie@zedlin-galp5:~/temp/firmware-open$ efibootmgr zeddie@zedlin-galp5:~/temp/firmware-open$ sudo coreboot/util/nvramtool/nvramtool -a zeddie@zedlin-galp5:~/temp/firmware-open$ sudo coreboot/util/nvramtool/nvramtool -x |
After a reboot, Windows Boot Manager is gone. zeddie@zedlin-galp5:~$ efibootmgr zeddie@zedlin-galp5:~/temp/firmware-open$ sudo coreboot/util/nvramtool/nvramtool -a zeddie@zedlin-galp5:~/temp/firmware-open$ sudo coreboot/util/nvramtool/nvramtool -x |
Oh, and there were no outputs for: Sorry it took a while. Busy life. I'm having less time to play and troubleshoot, so now I just need a laptop that works. Been using my work-issued laptop since I couldn't reliably get this to dual-boot. So what do I do now? |
I can create a firmware update image that dumps the CMOS NVRAM to the cbmem console. Then if you check the cbmem console, you will see hex dump of the actual values, and not what coreboot rewrites.
Optionally, I could change the default behavior to not clear the SMMSTORE. You would have to be careful about the SMMSTORE used space, as this could trigger #145 again. Unfortunately there's no convenient way to check this right now, but I can update one of the tools to report the used space, along with if it detects the region is corrupted. Build: 2021-10-23_dfc8d23 [1] Instructions for using this are here: #145 (comment) |
I flashed the firmware you gave me and ran the command. Here you go: ` coreboot-2021-10-23_dfc8d23 Sat Oct 23 21:06:11 UTC 2021 bootblock starting (log level: 7)... coreboot-2021-10-23_dfc8d23 Sat Oct 23 21:06:11 UTC 2021 romstage starting (log level: 0)... coreboot-2021-10-23_dfc8d23 Sat Oct 23 21:06:11 UTC 2021 postcar starting (log level: 0)... coreboot-2021-10-23_dfc8d23 Sat Oct 23 21:06:11 UTC 2021 ramstage starting (log level: 0)...
MTRR check POST: 0x93 |
So help me understand. Before the issue was the SMMSTORE was not clearing boot entries, so it gets full and it can't be rewritten? And now the CMOS is clearing the SMMSTORE every time it boots? I think we need a better solution. |
Did you have the issue on this boot? You will need to reproduce the issue and boot to Linux. The full cbmem console log isn't needed, just the hex dump at
Yes. SMMSTOREv1 is append-only, so at a certain point it would just run out of space and fail to do any operations involving EFI variables.
Not every time. As a workaround to the previous issue, we added an option that would allow users to reset the CMOS battery in order to erase SMMSTORE. The problem is we don't know what else writes to CMOS, or where: Earlier it was Windows writing the
We have it: SMMSTOREv2. It supports read-modify-write and fault tolerate writes. It will allow us to remove the CMOS hack, and these issues should almost never happen again. (The caveat is that if the firmware volume does somehow become corrupted, it will erase it to get back to a known good state.) I have #260 to track remaining work needed for the next firmware update. |
I just was able to reproduce this again. Freshly installed Arch, shutdown multiple times over the course of a few hours. Every time it booted into grub fine, except this latest instance when it dropped into grub shell. I dumped the CMOS right after I booted into Arch for the first time:
This is the dump after booting from grub shell:
Oddly, it looks identical to me. If my experience is unrelated let me know. |
Yes I did have the issue on this boot.
That's good news. Do you know how long before it is released into the standard firmware update feed? Or is this something we need to compile and flash manually? |
Then the fact that the cbmem dump matches the nvramtool dump, and the lack of the "CMOS reset" log, implies it's not the The only other, seemingly very unlikely, cause I can think of is firmware-smmstore. But for that to happen it would have to:
The tasks in the tracking issues need to be completed, and then any issues that come up in testing, so it may be some time before its released. |
I just want to say that I have the same issue with galp5. Also some reports on youtube with the same issue: https://www.youtube.com/watch?v=e47Tq90fHqc I install debian 11 on a new disk (UEFI). After the first successful boot to the installed OS, on the next reboot the boot entries are missing. If I boot from recovery USB, and "reinstall grub", I can boot again, but only once. On the second reboot, boot entries are missing. It is not happening for the original drive and original OS(popos) Please let me know if you need more info |
That's my video! :) |
Just flashed a build from #260 Actually it is slightly different. I can see the boot options in "One Time Boot", but it wont allow me to boot, the message I
|
How did you flash it? |
with |
How do I disable SecureBoot? |
SMMSTORE is not copied when using intel-spi or a CH341A programmer, so boot entries will always be lost if flashing via firmware-update doesn't migrate data to the new format yet, so it will actually always get erased right now. |
You didn't have to configure anything for that to happen? Right now, I expect it to boot into Setup Mode with Secure Boot disabled. |
I didn't configure anything. I just cloned the repo, checkout |
Secure Boot is not configurable from the firmware yet. You will have to build and flash with |
I have a GALP5 (iGPU) and on both the 2021-07-20 and 2021-09-20 firmware, the boot entries seem to disappear when I perform a cold boot. I have Pop!_OS 21.04 and Windows 10/11 installed and I perform dual-boot. I also use an Akitio Node TB3 eGPU with an RTX 3070 Ti and USB mouse. It may be related.
The text was updated successfully, but these errors were encountered: