galliumos-distro
galliumos-distro copied to clipboard
GalliumOS
Looping black screen at boot (TERRA, SETZER, BANON, ...) -- Xorg fails to start with new ChromeOS firmware
Initially reported on TERRA; additional models will likely be affected as ChromeOS firmware updates are rolled out.
Preliminary discussion at https://www.reddit.com/r/GalliumOS/comments/5juby5/asus_202a_braswell_blinkingflashing_screen_after/
ChromeOS platform versions and their status:
-
TERRA
- OK 8172.62.0 (firmware Google_Terra.7287.154.28)
-
OK 8530.93.0 (firmware Google_Terra.7287.154.28)
- last known-working version prior to Google bugfix
- NG 8743.87.0
-
NG 8872.76.0 (firmware Google_Terra.7287.154.56)
- Chrome version 55.0.2883.105
-
OK (C202 ONLY!) 10032.86.0 (firmware Google_Terra.7287.154.102)
- Still NG on C300 and C301
- Chrome version: 63.0.3239.140
-
SETZER
-
BANON
-
OK 8530.81.0 (firmware Google_Banon.7287.253.0)
- newest known-working version
- NG 8530.93.0 (image from Google fails to unzip!)
- NG 8743.85.0 (firmware Google_Banon.7287.313.0)
-
OK 8530.81.0 (firmware Google_Banon.7287.253.0)
Speculation is that new ChromeOS firmware is putting the video hardware into an initialization state which Linux/Xorg does not properly reset.
To check your ChromeOS version, press Tab or Ctrl+I at the white dev mode ("OS verification is OFF") screen. There are two versions, "read-only" and "active". Active is the most important, but both are helpful to know.
Current workaround is to Recover to working version of ChromeOS and not allow ChromeOS to update.
To Recover to an older version of ChromeOS, download and unzip the working version (linked above for known-problematic models). Then write the .bin file to a USB drive just like it was an .iso file, using the tools available on your platform (general info on the wiki: https://wiki.galliumos.org/Installing/Creating_Bootable_USB). You can also use the ChromeOS Recovery Tool inside the Chrome browser on some platforms.
Note that Recovering ChromeOS will return your machine to factory state, and erase all local data. You'll need to reinstall GalliumOS, starting with enabling dev mode, and flashing firmware.
Update 20180211 - 20180401:
- Current firmware on C202 TERRAs no longer exhibits this issue
- C300 TERRAs, C301 TERRAs, and SETZER are reported still affected
- BANON has no updated reports yet
Hey, I've been on the subreddits as "Yumsterboy" and yeah, that version does not work for me. I end up with the same issue. I've tried following the directions specifically, and I've even got the same model ID as you. I'm remaking the recovery media, but so far, nothing has worked yet.
Edit: The flashing message is as follows
ERROR: Unable to locate IOAPIC for GSI 182
tpm_tis 00:07: can't request region for resource [mem 0xfed40000-0xfed44fff]
proc_thermal 000:00:0b.0: No auxiliary DTSs enabled
kvm: disabled by bios
kvm: disabled by bios
and then the login
This is a video of the log file it gave me.
https://goo.gl/photos/ynDQqBjdHVs5jVXVA EDIT 2: It works now with the 8530 build!
This issue in crouton sounds like it might be the same issue.
https://github.com/dnschneid/crouton/issues/2926
Probably to do with xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) #2926
Wanted to add my finding that the latest version I have been able to get to work so far is 8050.93.0. Tried the recovery version right after that and yet again got the blinking screen. Still no sound though
@diosky thanks for the update. I'll note the top comment accordingly.
Re: sound, you need to either install the nightly image, run chrx with -r nightly, or post-install run sudo galliumos-repodist --enable testing and then update packages.
I recently bought an HP G5 11 (Braswell/Setzer)and have been following all of the issues here with interest. I'm a relative noob as far as digging into the guts of Linux but might be able to help with testing etc (first github post..). After being unable to install GalliumOS on the latest firmware I thought I would check out Crouton - looks like the latest firmware updates have also broken Crouton - see issue 2917 on the Crouton github entry.
Someone with a bit more experience than me might be able to transfer the xorg config fix that they have over there into the GalliumOS distro here. I'll try having more of a poke around with Crouton Xorg config file and post the settings here if I have any success (suggestions for settings to try are welcome).
Keep up the excellent work!
@higherstateofawkwardness I've tried each of the suggested Xorg config changes posted to the Crouton issue tracker (as of about a week ago, at least). None of them worked at all.
The only workaround that I've had any success with is rolling back to the 8530.93.0 version of ChromeOS. That works 100% of the time, but it's not a great solution for dual-booting, as ChromeOS will want to update itself. There is a way to specifically block firmware updates, but I haven't tested it yet.
@reynhout What methods are there to block updates?
"initctl stop update-engine" has to be run every login.
The better option I've found is to block updates with a G Suite account, which is a premium business account ($5/mo for access and $50/yr for 60 chrome devices).
Thanks for the hard work!
@kfmush The firmware updater script checks a file at /root/.leave_firmware_alone to see if it should ..well.. leave the firmware alone.
Creating that file requires remounting the root partition read-write, but otherwise should be straightforward. I haven't tested it though.
Of course, once the filesystem is remounted RW, it would be simple to bypass or modify the firmware update script (/usr/sbin/chromeos-firmwareupdate) entirely.
The full process could (and should) be scripted.
Alternately, we could make a custom ChromeOS recovery image reverts the firmware to the newest known-good version, and then that bypasses the firmware update step. That would be more convenient for the already-affected, but we'd also want a standalone script for the not-yet-affected.
Any of these workarounds would be temporary -- resolving the Xorg issue is the goal. Not much progress on it yet though. Wayland is reported to succeed.
@reynhout Thanks for the response! I look forward to your progress with that script and the main Xorg issue.
For now, I've had success using G Suite to block auto-updates (gsuite.google.com). They offer a 90 day trial and a 60 day trial specifically to add chrome devices. They ask for credit card info for when the trial ends, but one can just cancel out of it. I figure that's enough time for a quick fix until a better temporary or real solution comes about.
There is a significant barrier, though. One needs to own a domain and verify ownership (or pay $8/month for one). Fortunately, I already had a domain I could use, but obviously not everyone does. It looks like there is a limit of 10 Chrome devices per G Suite account.
@reynhout thanks; for various reasons I am currently restricted to wifi internet only and the Broadcom wifi drivers that I have for my laptop don't currently work for booting Linux from a liveusb. However, I have had success downgrading to 8743.85.0 within the "rollback" command within the crosh terminal.
This seems the simplest way to downgrade and has fixed crouton; I'll try and install galliumOS and post back to advise if it is working for Setzer on this firmware rev (I see at the top that it is listed as "OK?").
I just wanted to update. Like diosky, I have updated Gallium's Linux kernel to 4.9 and can now update Chrome OS to the latest version with no discernable problems booting GalliumOS.
Version number of Chrome OS. (Platform version 8872.76.0)
I was mistaken about updating the Linux kernel to 4.9 fixing my problem. Chrome OS was just slow to update it seems.
Automated prevention of ChromeOS firmware updates does not appear to be possible:
- Setting
.leave_firmware_aloneworks to prevent updates, but only until the next OS update. An OS update clears that setting and creates.force_firmware_updatein its place - Modifying
chromeos-firmwareupdateon the ChromeOS Recovery Image cannot work. That code is executed after the filesystem integrity check, which fails and aborts Recovery
Active manual prevention is possible, but requires diligence: reset the .leave_firmware_alone vs .force_firmware_update config manually after every ChromeOS update. This is easy to overlook or forget. (Easier: just don't use ChromeOS!)
Repair via full Recovery continues to work, at a cost: full ChromeOS Recovery will downgrade firmware, but the process also damages the GalliumOS partition.
Repair via rollback from the crosh shell can work: ChromeOS keeps two versions of itself in the A and B boot partitions. If both are updated to too-new versions, rollback won't help.
Repair via reversion to read-only firmware (needs testing!) should be possible, if your RO firmware is adequately old
Repair via explicit flashing of known-good firmware (needs testing!) might also be possible. Would require some scripting and infrastructure to set up
The proper solution remains to get Xorg working with the updated firmware. No discoveries or progress on that front yet.
I wonder if this will be a problem on more chromebooks. I am currently on Google_Lars.7820.127.0 with chromeos 58.0.3007.0 (Official Build) dev (64-bit) I don't have this problem yet, also never hope to get. However before it hits me could someone give some more info thanks. Maybe I overlooked it, but I have not found a descend dmesg log or xorg log which could prevail what is going on.
@divx118 it's definitely possible that this problem will spread to additional models as new ChromeOS firmware is released.
Even on affected systems, there is nothing useful in the log files.
@reynhout Ah ok, so no errors or anything. There was some mention that crouton black screen was related, however I doubt that. On crouton drinkcat created a temporary workaround https://github.com/dnschneid/crouton/issues/2923#issuecomment-280220433 but I don't think it is related to the issue here.
Is there any status on the issue? Still borked? Is there anything we can do to help? I haven't started ChromeOS in months, also i got an email from GH about a comment from @CoolStar saying that he had a working Full UEFI firmware dated March 31. Was that removed? Considering nuking Gallium for a clean 2.1 install. Does Chrx do 2.1 by default?
Google_Relm.7287.313.0 is borked on an Acer Chromebook 11 N7 (C731 series) Braswell notebook as well.
In my case, after the GalliumOS logo is rotating, it just drops me to shell with galliumos login as it repeatedly blinks.
I've also tried to flash the Terra recovery image from the above and have used windisk32 imager, plain dd on a Macbook and also just tried to copy the .bin file into the USB but the laptop refuses to boot off of it with the message 'Insert image invalid' . I've redownloaded, tried different USB sticks, but to no avail. Is there any other recommended way of getting the .bin onto a USB and successfully boot off of it?
I'm trying to resolve this on a banon machine. The original post links to a google recovery disk version 8530.93.0 .This link works but the resulting zip file is corrupt. Is there a way to browse google's recovery disks online so I can try an earlier one? Does someone have a link to a banon disk that is not broken?
The link is 8530.93.0
@chrisjohgorman I don't have a BANON to test, but I can't imagine why the zip file would be bad. Google uses the same URL to make recovery images.
My process is, e.g.:
curl -O https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_8530.93.0_banon_recovery_stable-channel_mp.bin.zip
unzip chromeos_8530.93.0_banon_recovery_stable-channel_mp.bin.zip
sudo cp chromeos_8530.93.0_banon_recovery_stable-channel_mp.bin /dev/sdb
Which works every time on Linux or macOS. Check the target of the cp of course.
Here are some other versions to try:
8743.85.0 is a reasonable possibility. I would not expect anything after that to work.
Thanks. I'm trying the download on the chromebook. I don't know why, but the download of 8530.93.0 fails on my systems due to a corrupt zip file. Thanks for the links to the other versions, I will try them out when I get home next week.
On Sun, Jun 11, 2017 at 10:55 AM, reynhout [email protected] wrote:
@chrisjohgorman https://github.com/chrisjohgorman I don't have a BANON to test, but I can't imagine why the zip file would be bad. Google uses the same URL to make recovery images.
My process is, e.g.:
curl -O https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_8530.93.0_banon_recovery_stable-channel_mp.bin.zip unzip chromeos_8530.93.0_banon_recovery_stable-channel_mp.bin.zip sudo cp chromeos_8530.93.0_banon_recovery_stable-channel_mp.bin /dev/sdb
Which works every time on Linux or macOS. Check the target of the cp of course.
Here are some other versions to try:
- 8350.68.0 https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_8350.68.0_banon_recovery_stable-channel_mp.bin.zip
- 8530.81.0 https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_8530.81.0_banon_recovery_stable-channel_mp.bin.zip
- 8530.93.0 https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_8530.93.0_banon_recovery_stable-channel_mp.bin.zip
- 8743.85.0 https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_8743.85.0_banon_recovery_stable-channel_mp.bin.zip
- 9000.91.0 https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_9000.91.0_banon_recovery_stable-channel_mp.bin.zip
- 9202.64.0 https://dl.google.com/dl/edgedl/chromeos/recovery/chromeos_9202.64.0_banon_recovery_stable-channel_mp.bin.zip
8743.85.0 is a reasonable possibility. I would not expect anything after that to work.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/320#issuecomment-307633965, or mute the thread https://github.com/notifications/unsubscribe-auth/Ab_r80OssJqmvogdyiQO2SPNQK3dLwJiks5sC__ygaJpZM4LnYNA .
The download fails? Or the unzip fails after downloading?
The commands I posted above will work on ChromeOS too, I think (assuming unzip is available as an executable, which I believe it is). Make sure you have adequate disk space though. You'll need at least 3GB available in your working directory (df -h .).
The unzip fails after downloading. It is not available as an executable on my system, but the files app will perform an unzip. It works with 8530.81.0 but not with 8530.93.0.
On Sun, Jun 11, 2017 at 11:38 AM, reynhout [email protected] wrote:
The download fails? Or the unzip fails after downloading?
The commands I posted above will work on ChromeOS too, I think (assuming unzip is available as an executable, which I believe it is). Make sure you have adequate disk space though. You'll need at least 3GB available in your working directory (df -h .).
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/320#issuecomment-307637276, or mute the thread https://github.com/notifications/unsubscribe-auth/Ab_r89B3rO6l7AXFhx-z38eamosNkB8gks5sDAnrgaJpZM4LnYNA .
@chrisjohgorman OK, thanks for the info. I will update the top post accordingly.
@chrisjohgorman Can you check the Firmware version on your system, post-install? Press Tab or Ctrl+I at the white dev mode ("OS verification is OFF") screen. There are two versions, "read-only" and "active". Active is the most important, but both are helpful to know. Thanks!
Here are the firmware versions.
read-only firmware id: Google_Banon.7287.253.0 active firmware id: Google_Banon.7287.313.0
As i understand it I will need to downgrade the firmware somehow so that the active firmware id is 7287.253.0 at the latest. I'm not too sure how to do this, but am hoping using the recovery image 8530.81 will update the firmware appropriately. Keeping my fingers crossed.
Thanks for all the help.
Chris
On Sun, Jun 11, 2017 at 12:45 PM, reynhout [email protected] wrote:
@chrisjohgorman https://github.com/chrisjohgorman Can you check the Firmware version on your system, post-install? Press Tab or Ctrl+I at the white dev mode ("OS verification is OFF") screen. There are two versions, "read-only" and "active". Active is the most important, but both are helpful to know. Thanks!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GalliumOS/galliumos-distro/issues/320#issuecomment-307641262, or mute the thread https://github.com/notifications/unsubscribe-auth/Ab_r8-BzizjfVf14CYuCIVj_EHB2LCgCks5sDBmZgaJpZM4LnYNA .
Oh, I misunderstood -- I thought you meant that 8530.81.0 fixed the problem, but it's just a valid zip file so far. OK, please let us know how things go, and what firmware version you end up with after installing it. Good luck...fingers crossed. :)