search

GalliumOS / galliumos-distro

Docs, issues, and artwork sources for GalliumOS
https://galliumos.org/
GNU General Public License v2.0
347 stars 11 forks source link

Looping black screen at boot (TERRA, SETZER, BANON, ...) -- Xorg fails to start with new ChromeOS firmware #320

Open reynhout opened 7 years ago

reynhout commented 7 years ago

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:

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:

pswiifanwmi commented 7 years ago

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!

gbing19 commented 7 years ago

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

diosky commented 7 years ago

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

reynhout commented 7 years ago

@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.

diosky commented 7 years ago

Yeah, I just figured out how to update the kernal to 4.9. Works great now.

higherstateofawkwardness commented 7 years ago

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!

reynhout commented 7 years ago

@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.

kfmush commented 7 years ago

@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!

reynhout commented 7 years ago

@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.

kfmush commented 7 years ago

@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.

higherstateofawkwardness commented 7 years ago

@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?").

kfmush commented 7 years ago

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.

kfmush commented 7 years ago

Update to 55.0.2883.105 revived the problem.

amphitheres commented 7 years ago

@kfmush 55.0.2883.105 of what?

kfmush commented 7 years ago

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.

reynhout commented 7 years ago

Automated prevention of ChromeOS firmware updates does not appear to be possible:

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.

divx118 commented 7 years ago

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.

reynhout commented 7 years ago

@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.

divx118 commented 7 years ago

@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.

pswiifanwmi commented 7 years ago

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?

kbpersonal commented 7 years ago

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?

chrisjohgorman commented 7 years ago

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

reynhout commented 7 years ago

@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.

chrisjohgorman commented 7 years ago

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 notifications@github.com 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:

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 .

reynhout commented 7 years ago

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 .).

chrisjohgorman commented 7 years ago

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 notifications@github.com 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 .

reynhout commented 7 years ago

@chrisjohgorman OK, thanks for the info. I will update the top post accordingly.

reynhout commented 7 years ago

@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!

chrisjohgorman commented 7 years ago

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 notifications@github.com 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 .

reynhout commented 7 years ago

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. :)

Aeny202 commented 7 years ago

I've done the recovery via usb with all those images on my SETZER system and have found the firmware version stays the same on the developer mode screen (TAB), however when looking up the version number in Chrome they changed properly (and to the right version). All versions seemed to work okay up until the latest one (9334.72.0). That one produced a black screen instead of booting Gallium OS properly from USB.

I have a .force_firmware_update file set in root automagically by the recovery installer by the way. I'm currently on vacation but am willing to do further testing on SETZER. Let me know if there's some specific data that you need.

chrisjohgorman commented 7 years ago

Thank you for the information. I will try to revert to an old recovery image next week. I can't do it sooner as I too am away from home. Your testing gives me hope that I too will be able to get Gallium OS working on my BANON. Thanks.

On Mon, Jun 12, 2017 at 4:21 AM, Aeny202 notifications@github.com wrote:

I've done the recovery via usb with all those images on my SETZER system and have found the firmware version stays the same on the developer mode screen (TAB), however when looking up the version number in Chrome they changed properly (and to the right version). All versions seemed to work okay up until the latest one (9334.72.0). That one produced a black screen instead of booting Gallium OS properly from USB.

I have a .force_firmware_update file set in root automagically by the recovery installer by the way. I'm currently on vacation but am willing to do further testing on SETZER. Let me know if there's some specific data that you need.

— 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-307721587, or mute the thread https://github.com/notifications/unsubscribe-auth/Ab_r86Z2OIp3Kqt6-E_ZW6m499IRcVAqks5sDPT7gaJpZM4LnYNA .

chrisjohgorman commented 7 years ago

I believe you have already updated the main post with this information, but I wanted to confirm your results. 8530.81.0 works. To restate what fails about 8530.93.0, the zip file is reported to be corrupt when I tried to unzip it, otherwise it may have worked as well. Thanks for all your help in getting my machine running Linux.

On Mon, Jun 12, 2017 at 8:34 AM, Chris Gorman chrisjohgorman@gmail.com wrote:

Thank you for the information. I will try to revert to an old recovery image next week. I can't do it sooner as I too am away from home. Your testing gives me hope that I too will be able to get Gallium OS working on my BANON. Thanks.

On Mon, Jun 12, 2017 at 4:21 AM, Aeny202 notifications@github.com wrote:

I've done the recovery via usb with all those images on my SETZER system and have found the firmware version stays the same on the developer mode screen (TAB), however when looking up the version number in Chrome they changed properly (and to the right version). All versions seemed to work okay up until the latest one (9334.72.0). That one produced a black screen instead of booting Gallium OS properly from USB.

I have a .force_firmware_update file set in root automagically by the recovery installer by the way. I'm currently on vacation but am willing to do further testing on SETZER. Let me know if there's some specific data that you need.

— 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-307721587, or mute the thread https://github.com/notifications/unsubscribe-auth/Ab_r86Z2OIp3Kqt6-E_ZW6m499IRcVAqks5sDPT7gaJpZM4LnYNA .

reynhout commented 7 years ago

@chrisjohgorman Good to hear, and thanks for the update.

If you are able, please let us know what ChromeOS firmware version was installed by the 8530.81.0 image.

You can check by pressing Tab at the white "OS verification is OFF" screen. It'll be something like Google_Banon.xxxx.xxx.x. There will be two versions, read-only and active, corresponding to the factory version and your installed version. Both are useful to know, but active is the most important one for this issue.

Thanks again!

chrisjohgorman commented 7 years ago

Sure thing. Both read-only and active are 7287.253.0 .

On Fri, Jun 16, 2017 at 11:04 AM, reynhout notifications@github.com wrote:

@chrisjohgorman https://github.com/chrisjohgorman Good to hear, and thanks for the update.

If you are able, please let us know what ChromeOS firmware version was installed by the 8530.81.0 image.

You can check by pressing Tab at the white "OS verification is OFF" screen. It'll be something like Google_Banon.xxxx.xxx.x. There will be two versions, read-only and active, corresponding to the factory version and your installed version. Both are useful to know, but active is the most important one for this issue.

Thanks again!

— 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-309050814, or mute the thread https://github.com/notifications/unsubscribe-auth/Ab_r80Sj_16mt9eff1F7AIwIBBCsim1iks5sEpmagaJpZM4LnYNA .

reynhout commented 7 years ago

@chrisjohgorman Merci. Updated main post with that info. Thanks again. :)

chrisjohgorman commented 7 years ago

@reynhout Merci to you. Thanks for all your help getting this machine running gallium.

On Fri, Jun 16, 2017 at 11:52 AM, reynhout notifications@github.com wrote:

@chrisjohgorman https://github.com/chrisjohgorman Merci. Updated main post with that info. Thanks again. :)

— 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-309063246, or mute the thread https://github.com/notifications/unsubscribe-auth/Ab_r88Zn-yYPpGRI6F3uIvRL8Nf1_PwJks5sEqTZgaJpZM4LnYNA .

enko commented 7 years ago

Any update on this?

chrisjohgorman commented 7 years ago

I'm not too sure what information you need updated. My machine is working loading GalliumOS now. I had to downgrade my firmware to 7287.253.0 in order to see the Linux install.

On Sun, Jul 23, 2017 at 8:17 AM, Tim notifications@github.com wrote:

Any update on this?

— 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-317249085, or mute the thread https://github.com/notifications/unsubscribe-auth/Ab_r81A5461uTGGvhGZI8bFghHN5RxfYks5sQznggaJpZM4LnYNA .

kbpersonal commented 7 years ago

I am unable to load any of the images listed here on a Google_Relm.7287.313.0 laptop - I downloaded the .zip files, extracted the .bin files and then copied them over to a USB using both Mac and Windows methods listed here (used the sudo cp method on Mac and Win32DiskImager on Windows) : https://wiki.galliumos.org/Installing/Creating_Bootable_USB

but no matter what when the USB is inserted ChromeOS says that the image on the disk is not a valid ChromeOS image. Not sure if this is an issue with how I created the USB or with Relm but I am simply unable to load the lower version of ChromeOS on here before proceeding with the GalliumOS install.

reynhout commented 7 years ago

@kdizzay Those images won't work on RELM. They're for TERRA, SETZER, or BANON, respectively, and are model-specific.

I'm not 100% sure that RELM is affected by the ChromeOS firmware issues described here -- but it's entirely possible. Try these RELM images to see if you can find one that works:

Those are in ascending chronological/version order of course, so the first is the least-likely to be affected and the last is the most.

enko commented 7 years ago

Ok, so here is my result:

First I tried 8530.93.0, but that did not work at all, as the recovery did not work. After that I tried 8743.85.0 and it worked flawless and gallium install via chrx was perfect and now my wife is happy 👍 .

kbpersonal commented 7 years ago

Thanks guys, I'll give it a shot. And I am definitely facing this issue on my Chromebook running Google_Relm.7287.313.0: https://www.amazon.com/gp/product/B01N0Z4KD5/ref=oh_aui_detailpage_o09_s00?ie=UTF8&psc=1 fyi for anyone who is interested/considering on buying this.

reynhout commented 7 years ago

@enko Which model Chromebook did the 8743.85.0 work on for you?

Can you check your working ChromeOS firmware versions for us? Press Tab at the white screen, look for "active" and "read-only" version numbers.

Thanks!

jdbowma commented 7 years ago

I tried to recover to an older version of Chrome OS (currently using the Terra version that is causing issues) and every time, I am met with "an unexpected error has occurred" I've tried different flash drives, doing things on different systems, but nothing changes it.

pswiifanwmi commented 7 years ago

@untoldj Did you try a different image? The oldest doesn't always work. At least not with mine anyway. And did the latest version of @MattDevo RWLegacy change anything regarding the main issue? I'm scared to test it.

jdbowma commented 7 years ago

I've tried both versions and both seemed to have the same issue.

reynhout commented 7 years ago

@untoldj Which firmware versions do you have after the Recovery? The TERRA image definitely works for me, but it might not be successfully installing the firmware for you.

jdbowma commented 7 years ago

@reynhout Before RW Legacy: read only: Google_Terra.7287.154.4 Active: Google_terra.7287.154.80 After, it's still the same. I guess the RWLegacy isn't working for me?

MrChromebox commented 7 years ago

@untoldj the RW_LEGACY firmware has nothing to do with the main firmware, it's completely separate, and updating it will not be reflected in any firmware version listing (outside of SeaBIOS itself). You need to verify the ChromeOS version in Settings/About ChromeOS and ensure it matches one of the working ones listed above.