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

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

Open
reynhout opened this Issue Jan 18, 2017 · 95 comments

Comments

Projects
None yet
@reynhout
Member

reynhout commented Jan 18, 2017

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

    • ?? 8530.93.0 (firmware Google_Setzer.7287.154.xx)
      • reports of both success and failure
    • OK 8743.85.0
      • report of success: @nulloa in comments below
    • NG 55.0.2883.105
  • 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)

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

This comment has been minimized.

Show comment
Hide comment
@pswiifanwmi

pswiifanwmi Jan 18, 2017

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!

pswiifanwmi commented Jan 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gbing19

gbing19 Jan 19, 2017

This issue in crouton sounds like it might be the same issue.

dnschneid/crouton#2926

Probably to do with xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) #2926

gbing19 commented Jan 19, 2017

This issue in crouton sounds like it might be the same issue.

dnschneid/crouton#2926

Probably to do with xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) #2926

@diosky

This comment has been minimized.

Show comment
Hide comment
@diosky

diosky Jan 19, 2017

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 commented Jan 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Jan 19, 2017

Member

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

Member

reynhout commented Jan 19, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@diosky

diosky Jan 19, 2017

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

diosky commented Jan 19, 2017

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

@higherstateofawkwardness

This comment has been minimized.

Show comment
Hide comment
@higherstateofawkwardness

higherstateofawkwardness Jan 29, 2017

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 commented Jan 29, 2017

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

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Jan 29, 2017

Member

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

Member

reynhout commented Jan 29, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kfmush

kfmush Jan 31, 2017

@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 commented Jan 31, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Jan 31, 2017

Member

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

Member

reynhout commented Jan 31, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@kfmush

kfmush Jan 31, 2017

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

kfmush commented Jan 31, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@higherstateofawkwardness

higherstateofawkwardness Jan 31, 2017

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

higherstateofawkwardness commented Jan 31, 2017

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

@reynhout reynhout changed the title from Xorg fails to start when dual-booting with certain versions of ChromeOS to Xorg fails to start with newest version of ChromeOS firmware Feb 2, 2017

@kfmush

This comment has been minimized.

Show comment
Hide comment
@kfmush

kfmush Feb 2, 2017

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 Feb 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kfmush

kfmush Feb 2, 2017

Update to 55.0.2883.105 revived the problem.

kfmush commented Feb 2, 2017

Update to 55.0.2883.105 revived the problem.

@ampheul

This comment has been minimized.

Show comment
Hide comment
@ampheul

ampheul Feb 5, 2017

@kfmush 55.0.2883.105 of what?

ampheul commented Feb 5, 2017

@kfmush 55.0.2883.105 of what?

@kfmush

This comment has been minimized.

Show comment
Hide comment
@kfmush

kfmush Feb 5, 2017

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.

kfmush commented Feb 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Feb 20, 2017

Member

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

  • Setting .leave_firmware_alone works to prevent updates, but only until the next OS update. An OS update clears that setting and creates .force_firmware_update in its place
  • Modifying chromeos-firmwareupdate on 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.

Member

reynhout commented Feb 20, 2017

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

  • Setting .leave_firmware_alone works to prevent updates, but only until the next OS update. An OS update clears that setting and creates .force_firmware_update in its place
  • Modifying chromeos-firmwareupdate on 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.

@divx118

This comment has been minimized.

Show comment
Hide comment
@divx118

divx118 Feb 20, 2017

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 commented Feb 20, 2017

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

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Feb 20, 2017

Member

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

Member

reynhout commented Feb 20, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@divx118

divx118 Feb 20, 2017

@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 dnschneid/crouton#2923 (comment) but I don't think it is related to the issue here.

divx118 commented Feb 20, 2017

@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 dnschneid/crouton#2923 (comment) but I don't think it is related to the issue here.

@reynhout reynhout removed this from the 2.1 milestone Feb 23, 2017

@reynhout reynhout changed the title from Xorg fails to start with newest version of ChromeOS firmware to Looping black screen at boot (TERRA, SETZER, BANON, ...) -- Xorg fails to start with new ChromeOS firmware May 15, 2017

@pswiifanwmi

This comment has been minimized.

Show comment
Hide comment
@pswiifanwmi

pswiifanwmi May 17, 2017

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?

pswiifanwmi commented May 17, 2017

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?

@kdizzay

This comment has been minimized.

Show comment
Hide comment
@kdizzay

kdizzay May 17, 2017

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?

kdizzay commented May 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrisjohgorman

chrisjohgorman Jun 11, 2017

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 commented Jun 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Jun 11, 2017

Member

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

Member

reynhout commented Jun 11, 2017

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

@ajj

This comment has been minimized.

Show comment
Hide comment
@ajj

ajj Nov 8, 2017

Working on SETZER with 8743.85.0 installed via recovery and RW_LEGACY + GBBR set.

Firmware reported as Google_Setzer.7287.268.0

ajj commented Nov 8, 2017

Working on SETZER with 8743.85.0 installed via recovery and RW_LEGACY + GBBR set.

Firmware reported as Google_Setzer.7287.268.0

@jgonsior

This comment has been minimized.

Show comment
Hide comment
@jgonsior

jgonsior Nov 10, 2017

I restored the Firmware 8530.93.0 on my Terra machine. It says, that my firmware is now the following:
read-only: Google_Terra.7287.154.45 active: Google_Terra.7287.154.28

But still when I install GalliumOS I see ERROR: Unable to locate IOAPIC for GSI 182 after installing, and even shortly while booting from the live USB stick. Did I missed any step after restoring ChromeOS? Do I need to boot into it first and do then something there too?

jgonsior commented Nov 10, 2017

I restored the Firmware 8530.93.0 on my Terra machine. It says, that my firmware is now the following:
read-only: Google_Terra.7287.154.45 active: Google_Terra.7287.154.28

But still when I install GalliumOS I see ERROR: Unable to locate IOAPIC for GSI 182 after installing, and even shortly while booting from the live USB stick. Did I missed any step after restoring ChromeOS? Do I need to boot into it first and do then something there too?

@MrChromebox

This comment has been minimized.

Show comment
Hide comment
@MrChromebox

MrChromebox Nov 10, 2017

restored the Firmware 8530.93.0 on my Terra machine

that's the ChromeOS build, not firmware, as noted in the OP above; Google_Terra.7287.154.28 is the firmware build

But still when I install GalliumOS I see ERROR: Unable to locate IOAPIC for GSI 182

that's a spurious error and can be ignored. If GalliumOS boots after install, then you're good to go

MrChromebox commented Nov 10, 2017

restored the Firmware 8530.93.0 on my Terra machine

that's the ChromeOS build, not firmware, as noted in the OP above; Google_Terra.7287.154.28 is the firmware build

But still when I install GalliumOS I see ERROR: Unable to locate IOAPIC for GSI 182

that's a spurious error and can be ignored. If GalliumOS boots after install, then you're good to go

@jgonsior

This comment has been minimized.

Show comment
Hide comment
@jgonsior

jgonsior Nov 10, 2017

Hm, it doesn't really boots, first I see shortly the spurious error, then for a while the boot animation, and then I end up with the following:

ERROR: Unable to locate IOAPIC for GSI 182

BusyBox v1.22.1 Ubuntu 1:1.22.0-15ubuntu1) Built-in shell (ash)
Enter 'help' for a list of built in commands.

(initramfs) 

But maybe this error has then nothing to do anymore with this issue here?

jgonsior commented Nov 10, 2017

Hm, it doesn't really boots, first I see shortly the spurious error, then for a while the boot animation, and then I end up with the following:

ERROR: Unable to locate IOAPIC for GSI 182

BusyBox v1.22.1 Ubuntu 1:1.22.0-15ubuntu1) Built-in shell (ash)
Enter 'help' for a list of built in commands.

(initramfs) 

But maybe this error has then nothing to do anymore with this issue here?

@MrChromebox

This comment has been minimized.

Show comment
Hide comment
@MrChromebox

MrChromebox Nov 10, 2017

@jgonsior no, that's a slightly different variation on the same issue -- downgrading ChromeOS/the stock firmware should have fixed the issue though. Can you confirm the ChromeOS platform/build you're currently running?

MrChromebox commented Nov 10, 2017

@jgonsior no, that's a slightly different variation on the same issue -- downgrading ChromeOS/the stock firmware should have fixed the issue though. Can you confirm the ChromeOS platform/build you're currently running?

@jgonsior

This comment has been minimized.

Show comment
Hide comment
@jgonsior

jgonsior Nov 10, 2017

Version: 53.0.2785.144 (64-bit)
Platform 8539.93.0 (Official Build) stable-channel terra
Firmware Google_Terra.7287.154.28

jgonsior commented Nov 10, 2017

Version: 53.0.2785.144 (64-bit)
Platform 8539.93.0 (Official Build) stable-channel terra
Firmware Google_Terra.7287.154.28

@MrChromebox

This comment has been minimized.

Show comment
Hide comment
@MrChromebox

MrChromebox Nov 10, 2017

that should be a working config - perhaps try to go back to the 8172.62.0 build?

MrChromebox commented Nov 10, 2017

that should be a working config - perhaps try to go back to the 8172.62.0 build?

@jgonsior

This comment has been minimized.

Show comment
Hide comment
@jgonsior

jgonsior Nov 10, 2017

I can't restore to that one - while trying to restore to this build I get (after the build verification is positive and it recovers for quite a while): An unexpected error has occured. Please refer to this URL for troubleshooting tips: https://www.google.com/chromeos/recovery

jgonsior commented Nov 10, 2017

I can't restore to that one - while trying to restore to this build I get (after the build verification is positive and it recovers for quite a while): An unexpected error has occured. Please refer to this URL for troubleshooting tips: https://www.google.com/chromeos/recovery

@MrChromebox

This comment has been minimized.

Show comment
Hide comment
@MrChromebox

MrChromebox Nov 10, 2017

tried using more than one USB device? ChromeOS recovery can be weird like that

MrChromebox commented Nov 10, 2017

tried using more than one USB device? ChromeOS recovery can be weird like that

@jgonsior

This comment has been minimized.

Show comment
Hide comment
@jgonsior

jgonsior Nov 11, 2017

I tried it with another USB stick, tried the 8350.68.0, the 8530.81.0, the 8172.60.0 build too - the same error happens as with the 8172.62.0 build. I was able to install the 8743.87.0 build, the active firmware was after that 7287.154.56. So basically every build older than 7287.154.28 results in the "Unexpected error" and can't be restored.

jgonsior commented Nov 11, 2017

I tried it with another USB stick, tried the 8350.68.0, the 8530.81.0, the 8172.60.0 build too - the same error happens as with the 8172.62.0 build. I was able to install the 8743.87.0 build, the active firmware was after that 7287.154.56. So basically every build older than 7287.154.28 results in the "Unexpected error" and can't be restored.

@jgonsior

This comment has been minimized.

Show comment
Hide comment
@jgonsior

jgonsior Nov 11, 2017

I finally got it working - with the 7287.154.28 build. Previously I always enabled the "full-disk encryption" option during the installation - now I just enabled the home folder encryption. So the error has apparently something to do with #363. Thanks for the help @MattDevo!

jgonsior commented Nov 11, 2017

I finally got it working - with the 7287.154.28 build. Previously I always enabled the "full-disk encryption" option during the installation - now I just enabled the home folder encryption. So the error has apparently something to do with #363. Thanks for the help @MattDevo!

@aaronfranke

This comment has been minimized.

Show comment
Hide comment
@aaronfranke

aaronfranke Dec 1, 2017

This occurs for me on HP Chromebook 11 G5 SETZER. I updated to the latest ChromeOS after enabling developer mode, then updated the firmware to MrChromebox, then installed GalliumOS with chrx and I get a flashing command line. Please let me know if there's a solution to this!

aaronfranke commented Dec 1, 2017

This occurs for me on HP Chromebook 11 G5 SETZER. I updated to the latest ChromeOS after enabling developer mode, then updated the firmware to MrChromebox, then installed GalliumOS with chrx and I get a flashing command line. Please let me know if there's a solution to this!

@MrChromebox

This comment has been minimized.

Show comment
Hide comment
@MrChromebox

MrChromebox Dec 1, 2017

@aaronfranke as per the top post, you need to downgrade to a working ChromeOS version, then install RW_LEGACY, then install chrx

MrChromebox commented Dec 1, 2017

@aaronfranke as per the top post, you need to downgrade to a working ChromeOS version, then install RW_LEGACY, then install chrx

@aaronfranke

This comment has been minimized.

Show comment
Hide comment
@aaronfranke

aaronfranke Dec 1, 2017

Does the Powerwash option do this? Will I have to redo the developer mode and firmware updates?

aaronfranke commented Dec 1, 2017

Does the Powerwash option do this? Will I have to redo the developer mode and firmware updates?

@MrChromebox

This comment has been minimized.

Show comment
Hide comment
@MrChromebox

MrChromebox Dec 1, 2017

@aaronfranke no, powerwash just formats the userdata partition, it doesn't touch the OS or firmware. You need to boot into Recovery Mode, use the ChromeOS recovery image linked in the top post, allow it to roll things back (just a normal recovery), then redo the firmware and chrx (because using a Recovery image does wipe the OS and restore the stock RW_LEGACY firmware)

MrChromebox commented Dec 1, 2017

@aaronfranke no, powerwash just formats the userdata partition, it doesn't touch the OS or firmware. You need to boot into Recovery Mode, use the ChromeOS recovery image linked in the top post, allow it to roll things back (just a normal recovery), then redo the firmware and chrx (because using a Recovery image does wipe the OS and restore the stock RW_LEGACY firmware)

@reynhout

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Feb 12, 2018

Member

This issue no longer appears on TERRA on current ChromeOS firmware.

  • Recovery image: 10032.86.0
  • Chrome version: 63.0.3239.140
  • Firmware version: Google_Terra.7287.154.102

So it looks like Google has fixed the bug!

Current firmware for SETZER and BANON might also fix the issue, but I'm not aware of anyone who has tested (and we don't have the hardware).

Member

reynhout commented Feb 12, 2018

This issue no longer appears on TERRA on current ChromeOS firmware.

  • Recovery image: 10032.86.0
  • Chrome version: 63.0.3239.140
  • Firmware version: Google_Terra.7287.154.102

So it looks like Google has fixed the bug!

Current firmware for SETZER and BANON might also fix the issue, but I'm not aware of anyone who has tested (and we don't have the hardware).

@maxromanovsky

This comment has been minimized.

Show comment
Hide comment
@maxromanovsky

maxromanovsky Apr 1, 2018

Updated to the latest stable version of chromeos, and can't boot galliumos stable, the same as on previous recent versions.
Tried to re-install it, starting with mrchromebox RW_LEGACY & chrx.
I have TERRA ASUS C300S & chromeos 65.0.3325.184

maxromanovsky commented Apr 1, 2018

Updated to the latest stable version of chromeos, and can't boot galliumos stable, the same as on previous recent versions.
Tried to re-install it, starting with mrchromebox RW_LEGACY & chrx.
I have TERRA ASUS C300S & chromeos 65.0.3325.184

@reynhout

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Apr 1, 2018

Member

@maxromanovsky Thanks for the info, this appears to still be a problem on the C300 and C301 TERRAs, although it tests fine on the C202 TERRAs.

They all use the same ChromeOS firmware, not not necessarily the same code branches in the firmware -- and at least some of the video hardware is different too.

This also remains an issue on SETZER, I think. Have not heard updates from any BANONs yet.

Member

reynhout commented Apr 1, 2018

@maxromanovsky Thanks for the info, this appears to still be a problem on the C300 and C301 TERRAs, although it tests fine on the C202 TERRAs.

They all use the same ChromeOS firmware, not not necessarily the same code branches in the firmware -- and at least some of the video hardware is different too.

This also remains an issue on SETZER, I think. Have not heard updates from any BANONs yet.

@reynhout

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Apr 1, 2018

Member

@maxromanovsky If single-booting is an option for you, the UEFI full ROM firmware from MrChromebox does not have this issue, of course.

Member

reynhout commented Apr 1, 2018

@maxromanovsky If single-booting is an option for you, the UEFI full ROM firmware from MrChromebox does not have this issue, of course.

@maxromanovsky

This comment has been minimized.

Show comment
Hide comment
@maxromanovsky

maxromanovsky Apr 1, 2018

@reynhout I'd cross my fingers & wait for double boot option :)

maxromanovsky commented Apr 1, 2018

@reynhout I'd cross my fingers & wait for double boot option :)

@ampheul

This comment has been minimized.

Show comment
Hide comment
@ampheul

ampheul Jun 8, 2018

I have Terra C202Sa and the problem persists unfortunately.

ampheul commented Jun 8, 2018

I have Terra C202Sa and the problem persists unfortunately.

@reynhout

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Jun 8, 2018

Member

@ampheul which ChromeOS firmware versions do you have installed?

Member

reynhout commented Jun 8, 2018

@ampheul which ChromeOS firmware versions do you have installed?

@ampheul

This comment has been minimized.

Show comment
Hide comment
@ampheul

ampheul commented Jun 8, 2018

@reynhout 10452.99.0

@reynhout

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Jun 8, 2018

Member

@ampheul Which is that, active or RO? What is the other?

Member

reynhout commented Jun 8, 2018

@ampheul Which is that, active or RO? What is the other?

@ampheul

This comment has been minimized.

Show comment
Hide comment
@ampheul

ampheul Jun 8, 2018

@reynhout From chrome://system, firmware version is Google_Terra.7287.154.102 and the release build is the number above.

ampheul commented Jun 8, 2018

@reynhout From chrome://system, firmware version is Google_Terra.7287.154.102 and the release build is the number above.

@reynhout

This comment has been minimized.

Show comment
Hide comment
@reynhout

reynhout Jun 8, 2018

Member

@ampheul Press Ctrl+I (or Tab) at the white "OS verification is OFF" screen to check the firmware version numbers. There are two to consider, labelled "active" and "read-only".

Active will probably be Google_Terra.7287.154.102 as you saw in the browser. RO is less critical, but gives an idea of rollback options.

Your best approach might be to roll back to the previous known-good version listed in the issue description above. I have successfully tested 7287.154.102 on C202/TERRA, but there must be another variable involved.

Member

reynhout commented Jun 8, 2018

@ampheul Press Ctrl+I (or Tab) at the white "OS verification is OFF" screen to check the firmware version numbers. There are two to consider, labelled "active" and "read-only".

Active will probably be Google_Terra.7287.154.102 as you saw in the browser. RO is less critical, but gives an idea of rollback options.

Your best approach might be to roll back to the previous known-good version listed in the issue description above. I have successfully tested 7287.154.102 on C202/TERRA, but there must be another variable involved.

@ampheul

This comment has been minimized.

Show comment
Hide comment
@ampheul

ampheul Jun 9, 2018

@reynhout RO is 7287.154.4, Active is 7287.154.102

ampheul commented Jun 9, 2018

@reynhout RO is 7287.154.4, Active is 7287.154.102

@egalyon3

This comment has been minimized.

Show comment
Hide comment
@egalyon3

egalyon3 Aug 30, 2018

Hey, I'm also experiencing this issue on the TERRA C300S where after installing galliumos, the screen flashes the same black terminal screen. Has there been any updates on this?

Active: TERRA 7287.154.4

egalyon3 commented Aug 30, 2018

Hey, I'm also experiencing this issue on the TERRA C300S where after installing galliumos, the screen flashes the same black terminal screen. Has there been any updates on this?

Active: TERRA 7287.154.4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment