Acer R11 recent problem using Boot Menu and Boot Manager entries -- black screens when clicked

[vtgit]

MrChromebox-4.11.2 03/17/2020 Acer Chromebook R11 / C738T (Cyan)

I have an Acer R11 which I have used successfully in the past w/Mr Chromebox. It has full install bios (no ChromeOS) and Xubuntu locally installed, which does start and run properly.

The problem is that it's the default OS and I can no longer change that. When at initial startup, if I hit ESC to get the boot menu, I have the usual three choices, Default, Boot Menu, and Boot Manager.

If I try either Boot Manager or Boot menu, the screen goes black, so it's impossible to choose anything other than the default boot.

This occurs whether there is a bootable USB drive or not in place. I used to be able to choose a USB boot or a shell boot, but can't now because of the blank screens. There is no ability to choose anything (except the default/Xubuntu installation).

Is there a way I can re-download MrChromebox firmware...... or correct this new behavior? (the Xubuntu installation is not needed btw -- was just a test install, but now the only thing I can do with this computer.)

Thanks for your help!

[MrChromebox]

Please run the Firmware Utility Script as per my site, update to the latest firmware, clear the NVRAM (using the script option), and reboot. That will resolve the issue

[vtgit]

Thank you greatly! Unfortunately in the meantime I tried a few other thumbdrives to see if any worked better, and finally found one that did give Boot Manager choices. I noticed many duplicate entries there, oddly. I was successful that one time in booting to a USB linux OS, BUT, on trying again, I could only boot into the UEFI Interactive Shell as default. Boot Menu and Boot Manager don't work (blank screens).

I did try using the firmware script in the UEFI Interactive Shell (v2.2) but get the error:

'cd;' isn't recognized as an internal or external command" --- the semicolon is the problem.

[MrChromebox]

Not sure why you are trying to run my script from the EFI shell, you need to do it from Linux with a network connection.

[vtgit]

Well becaause I can't get into Linux at this point on the chromebook, only boot to the EFI shell because it always defaults to that. Boot Menu and Boot Manager when clicked on present blank (black) screens.

[vtgit]

In other words, I tried it out of desperation.

[MrChromebox]

either you boot Linux somehow (internal eMMC, USB) and flash using my script, or you have to flash using a USB programmer like a ch341a per my unbricking guide: https://wiki.mrchromebox.tech/Unbricking

[vtgit]

Thank you for that. I've been reading about EFI Shell commands tonight to see if there's a way to go from the shell to a boot of one of the mapped devices -- which do have Linux on them.

Or if there's a way of changing the default boot from EFI Shell to one of the mapped devices.

I can't use the initial boot screen to do this through the Boot Menu or Boot Manager options, due to the blank screen problem with them. But if I can do it somehow through the CLI that would allow booting a linux instance and updating the firmware through the script.

[vtgit]

I've got Linux up! Running the firmware update script option 1 -- downloading coreboot-edk-cyan-mrchromebox_20240223.rom Error: firmware download checksum fail; download corrupted, cannot flash

I've tried it twice and same result. Could you check the checksum is okay for that file?

[vtgit]

(typo copying the above -- should read edk2, not edk)

-- downloading coreboot-edk2-cyan-mrchromebox_20240223.rom

tried several times with same checksum error. I suspect the checksum might be off?

[MrChromebox]

the file and checksum are correct on the server. You can check /tmp where the script downloads those files. The ROM should be 8.4MB with a sha1 hash of 4c4d7c0671b6c087b3bb87e07d851e427938060a

[vtgit]

Thanks again, mrchromebox. The sha1 hashes match up in tmp. See attached screenshot of the provided sha1, the calculated sha1, and the file size properties of the rom file. It is 8388608 bytes -- not sure if that matches your 8.4 mb figure unless it was an approximation.

[MrChromebox]

I have no idea why the script would tell you it's failing then, it's literally just calling sha1sum -c coreboot_edk2-cyan-mrchromebox_20240223.rom.sha1

[vtgit]

Consistently fails. Screenshot below. Is there a way to bypass the script's check and do the rom update?

[vtgit]

hyphen underscore naming problem with that last post of yours as "coreboot_edk2" vs coreboot-edk2 which is the actual name of the downloaded file ion /tmp.

[MrChromebox]

huh? the typo was yours, I just copied it in my reply

[vtgit]

sorry, I see

[MrChromebox]

Is there a way to bypass the script's check and do the rom update?

you can edit firmware-util.sh to not delete/re-downoad the other files, then comment out the checksum verification in firmware.sh, not that I recommend that generally but not sure what else to suggest in this case. you could also just remove the part of the command that's suppressing the output of sha1sum to see exactly why it's failing

[vtgit]

thanks kindly, mrchromebox, that gives me a direction to go in -- I do trust the local sha1 sums, and the computer is a semi-brick anyway, as-is.

[MrChromebox]

if you can run the script, the clear NVRAM option should fix your issue, but updating from the old/buggy firmware is paramount

[vtgit]

I'm trying to do the changes suggested. The linux I'm running for this (the only one that booted out of hundreds of tries with this faulty computer) is a live USB thumbdrive version of EasyOS Kirkstone64. This is a Barry Kauler flavor similar in a lot of respects to Puppy Linuxes, and runs as root. I'm wondering if this OS may be causing the failure of the SHA1 comparison. It does implement a fair number of security features including containers. I am not running the mr chromebox script in a container, however.

When I run the initial MrChromebox command to start the process, it downloads firmware-util.sh into the /root directory and then executes, putting the rom image and SHA1 check files into /tmp, plus three scripts, plus some other files.

I've noticed that none of the scripts in /tmp then have execute permissions. I don't know if that's normal, or if that affects the continuation. I notice that the firmware.sh script is the one with the SHA1 test in it:

verify checksum on downloaded file

if ! sha1sum -c "${coreboot_file}.sha1" --quiet > /dev/null 2>&1; then 
    exit_red "Firmware download checksum fail; download corrupted, cannot flash."; return 1
fi 

It looks like firmware-util.sh first deletes any prior instances of the files in /tmp and then downloads fresh versions, so if the SHA1 checking stanza is modified or commented out, it won't persist, unless code is changed in /root/firmware-util.sh, and it also isn't downloaded fresh.

I also noticed it also does not have executable permissions set. So to run a modified version, I would have to set it executable, manually, is that correct?

[MrChromebox]

I've noticed that none of the scripts in /tmp then have execute permissions. I don't know if that's normal,

it is, they aren't executed

It looks like firmware-util.sh first deletes any prior instances of the files in /tmp and then downloads fresh versions, so if the SHA1 checking stanza is modified or commented out, it won't persist, unless code is changed in /root/firmware-util.sh, and it also isn't downloaded fresh.

correct.

I also noticed it also does not have executable permissions set. So to run a modified version, I would have to set it executable, manually, is that correct?

no, just run sudo bash firmware-util.sh after editing it and firmware.sh

[vtgit]

Thank you greatly, mr chromebox, with your suggestions I was able to successfully update the rom firmware. Booting seems normal, with both Boot Menu and Boot Manager opening to usable choices instead of blank pages. I am able to boot from all USB thumbdrives I've tried, now.

I was not however able to clear the NVRAM as you asked. That errors out. I wonder if it's really necessary to do that, at this point?

Here's the error message (abbreviated) (also despite the dire warnings at the end of the message, nothing was written so I'm not stuck at waiting to reboot, etc):

Clearing the NVRAM will remove all EFI variables
and reset the boot order to the default.

Would you like to continue? [y/N] y

Clearing NVRAM...

flashrom 1.4.0-devel on Linux 5.15.148 (x86_64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns).
Cannot stat /run/lock.
Trying fallback directory: /tmp
coreboot table found at 0x7cd11000.
Found chipset "Intel Braswell".
Enabling flash write... Warning: Setting BIOS Control at 0x0 from 0x0b to 0x09 failed.
New value is 0x0b.
SPI Configuration is locked down.
FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-only.
FREG1: BIOS region (0x00200000-0x007fffff) is read-write.
FREG2: Management Engine region (0x00001000-0x001fffff) is locked.
Not all flash regions are freely accessible by flashrom. This is most likely
due to an active ME. Please see https://flashrom.org/ME for details.
At least some flash regions are read protected. You have to use a flash
layout and include only accessible regions. For write operations, you'll
additionally need the --noverify-all switch. See manpage for more details.
OK.
Found Winbond flash chip "W25Q64.W" (8192 kB, SPI) mapped at physical address 0x00000000ff800000.
Transaction error!
read_flash: failed to read (0x100000..0x100007).
Transaction error!
read_flash: failed to read (0x080000..0x080007).
Transaction error!
read_flash: failed to read (0x180000..0x180007).

(snip)

read_flash: failed to read (0x1f4000..0x1f4007).
Transaction error!
read_flash: failed to read (0x1fc000..0x1fc007).
Using region: "SMMSTORE".
disable_power_management: Failed to open /run/lock/power_override/flashrom.lock for writing: No such file or directory
Reading old flash chip contents... Transaction error!
read_flash: failed to read (00000000..0x7fffff).
FAILED.
Your flash chip is in an unknown state.
Get help on IRC (see https://www.flashrom.org/Contact) or mail
flashrom@flashrom.org with the subject "FAILED: <your board name>"!-------------------------------------------------------------------------------
DO NOT REBOOT OR POWEROFF!
FAILED

Failed to erase SMMSTORE firmware region; NVRAM not cleared.
``

`

[MrChromebox]

that's fine, it was cleared as part of the firmware update

[vtgit]

Great! Thank you for all your help. And the firmware to use these Chromebooks, too.