Installer doesn't show up on some Chromebooks: "Error setting up gfxboot"

[[Po]lentino]

I downloaded Ubuntu Wily 15.10, then copied into an USB drive in order to use that to install Ubuntu on my Chromebook Pixel 2.
After selecting the drive to boot from, I only get a terminal that shows up the following lines:

graphics initialization failed
Error setting up gfxboot
boot:

Same happens with any *buntu ISO image ( I tried KDE and XFCE as well).
At this point, I tried to download the Debian8 ISO image and I noticed that the installer doesn't recognize the video size, too but then asks for the user to manually select a suitable video format from a list of options. From that point on, I was able to install Debian on the chromebook.

[[Po]lentino (polentino911)]

Update: I tried Mint, and the installer just worked flawlessly: it picked the correct video size, then launched the live session, and from there I could install Mint easily .
Please let me know if you need more infos about the system (lspci output or whatever else you need).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Waz (paviluf)]

I have this problem on my HP Chromebook 14 (FALCO).
I use Gallium OS (based on Xubuntu) for now.

[Waz (paviluf)]

On previous Ubuntu versions there was a workaround. You had to type "help" (after boot:) then hit "enter".
That doesn't work anymore.

Gallium OS which is based on Xubuntu 15.04 works and don't need a workaround. Maybe it's a good place to start.
It will be great if it can be fixed for Ubuntu 16.04 !

[Waz (paviluf)]

Thanks to MattDevo I managed to fix the problem by installing his legacy firmware :

https://github.com/MattDevo/scripts

He said that there is maybe a bug in Ubuntu because the previous firmware I used from John Lewis doesn't re-run the video BIOS when switching to SeaBIOS. He'd guess it has to do with the way JL's SeaBIOS reuses the existing framebuffer vs re-initializing using the VGA BIOS.

[Mathieu Trudel-Lapierre (cyphermox)]

Reassigning to gfxboot-theme-ubuntu, where the problem might be (either that or it's something in syslinux).

It would help if someone from Gallium could point out what they did to work around this in gfxboot, if anything, or if they're using some newer syslinux, for instance.

[Waz (paviluf)]

Thank you Mathieu for looking at this problem.
I'm on irc with the Gallium OS guys and they say that they are using grub, not syslinux.
You can talk to them directly here if you want :
https://kiwiirc.com/client/irc.freenode.net#galliumos

[kk (kk1987)]

I have this problem on a Acer CB5-571-C4G4.

Unlike on the HP Chromebook as Waz mentioned in #5, MattDevo's SeaBIOS isn't making a difference on this Acer.

[Waz (paviluf)]

Maybe that can help, recently I flashed the full ROM from John Lewis and the problem is not present too for my Falco.

[Timo Jyrinki (timo-jyrinki)]

Fedora 23 boots fine, as does Ubuntu when created with unetbootin (which is otherwise somewhat unrecommendable tool for Ubuntu USB).

I'm available with my Braswell based Chromebook if anyone wants to debug this.

I needed to use Ubuntu 14.04.4 LTS created from 14.04 installation since unetbootin is not maintained at the moment and creating 16.04 USB from 16.04 Ubuntu did not work.

[Nicholas Skaggs (nskaggs)]

Timo, this only affects newer releases. 14.04 works with the workaround mentioned. The issue is indeed the resolution and 3:2 scaling I'd guess. There's no graceful fallback either and you have to workaround it or patch even after installed.

[Timo Jyrinki (timo-jyrinki)]

There is no 3:2 resolution on normal chromebooks, just normal resolutions. It's more due to the video BIOS missing / being strange when using the SeaBIOS payload beneath chromebook's Coreboot from what I can understand, and gfxboot not coping with it.

I believe 16.04 would work just as well if unetbootin would work for 16.04 images, ie removing gfxboot completely and replacing it with other first menu showing code.

[Waz (paviluf)]

Ubuntu seem to have a problem when the SeaBIOS payload doesn't re-run the video BIOS. Some SeaBIOS payload, like the John Lewis one, reuses the existing framebuffer vs re-initializing using the VGA BIOS.

https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/1530530/comments/5

[Nicholas Skaggs (nskaggs)]

@Timo, ahh! Hence the fascination with unetbootin. Makes sense now.

[Snwint-g (snwint-g)]

See https://github.com/openSUSE/gfxboot/issues/7.

It doesn't start on Chromebooks as it doesn't find/can't set a video mode.

[Snwint-g (snwint-g)]

Created attachment 677455
test iso 1: show available video modes

Please use this ('dd' to a usb stick) to show the available video modes.

[Timo Jyrinki (timo-jyrinki)]

Created attachment 677518
result from test iso 1

It just hangs in there.

With kvm /dev/sdb on another machine I can see it correctly gives resolution list.

[Snwint-g (snwint-g)]

Does it react to 'ESC'? Like showing the text boot menu?

[Timo Jyrinki (timo-jyrinki)]

Right, yes it does react to Esc, I can get the boot: menu with the harddisk/linux/upgrade etc options. So it's not hanged.

[Snwint-g (snwint-g)]

Ok, then everything is fine, actually. I'll put together a new test iso today or tomorrow.

[Snwint-g (snwint-g)]

Created attachment 677583
test iso 2: show active vbe mode and try to use it

Please test this one. Ideally it shows the current mode and then lets you continue.

Anything can happen, but I'd like at least to know the mode number.

[Timo Jyrinki (timo-jyrinki)]

Created attachment 677602
result from test iso 2

No graphics still. (but under kvm I got the graphical menu instead of text one)

[Snwint-g (snwint-g)]

Created attachment 677608
test iso 3: also list available modes

Please test this one. It should list all available modes on the first text screen. Otherwise nothing has changed.

Please post a screenshot of the mode list (provided there is anything).

[Timo Jyrinki (timo-jyrinki)]

Created attachment 677609
result from test iso 3

We've some modes. The native resolution of Acer Chromebook R11 (Braswell 14nm CPU) is 1366x768.

[Snwint-g (snwint-g)]

Created attachment 677616
test iso 4: just set mode 0x140

Ok, then let's just hardcode this mode number an see what happens.

[Timo Jyrinki (timo-jyrinki)]

With test iso 4, blank black screen after the "Press a key to continue..." prompt after the modes are displayed as in the previous image attachement. Keypresses don't seem have a visual effect.

(On kvm /dev/sdb, 320x200 graphical output)

[Snwint-g (snwint-g)]

Created attachment 677696
test iso 5: use framebuffer for drawing

Please try this one. With some luck it might work.

[Timo Jyrinki (timo-jyrinki)]

With test iso 5 still just blank black screen after seeing the text "Initializing gfx code...".

[Snwint-g (snwint-g)]

Created attachment 677773
test iso 6: try very hard to show something

Ok, if this one also doesn't show anything I'm out of ideas for the moment.

[Timo Jyrinki (timo-jyrinki)]

Created attachment 677776
result from test iso 6

We have image! Sorry for bad colors, they are normal red/green/blue for all the blocks.

The text is ip 26d: 2010b0a9.4 (ie the '1' is what's barely visible under green color in the photo)

[Snwint-g (snwint-g)]

And if you press 'ESC' there, what happens?

[Timo Jyrinki (timo-jyrinki)]

Nothing seems to happen when I press Esc, the screen stasys as is.

[Snwint-g (snwint-g)]

Ok, what you see there is the debug window. You can single-step through the code
with 'Enter', 'ESC' leaves the debug mode. The dots were just sprayed all over
the graphics framebuffer.

If you go two steps further with 'Enter' (provided it works), what number appears
in the data window (upper left)? (The ip in the bottom left should show '27a'.)

[Snwint-g (snwint-g)]

I'm on vacation next week and won't respond during that time.

[Timo Jyrinki (timo-jyrinki)]

The number that arrives at the bottom row of data is: 0: 201114ad. c

Below in the bottom box there is also:
err 0
ip 27a: 45.7

Let's continue after next week then probably.

[Snwint-g (snwint-g)]

Created attachment 680084
test iso 7: try to draw something

I've prepared a new test image. It shows at startup on a text screen the internal memory layout. Please attach the numbers (or screenshot).

Then, it will draw a bit. On the first debug screen, you should see the dots all over the screen as before + some lines crossing the screen + a small rectangle in the middle.

When you press ESC there, you reach another debug point and the text 'Test' should be printed at the top of the screen.

Do any of these things show up?

[Timo Jyrinki (timo-jyrinki)]

Created attachment 680175
result from test iso 7

The memory layout is shown, but only the image shown in the attachment (below memory layout) is what's gotten after that. Waiting or pressing Esc does not change anything. That is, only the diagonal lines background that was also shown with test iso 6 (aside from top left corner that had other info), with nothing else.

Note that while the background is drawn immediately, any characters outputted are v-e-r-y slow to output, so any timing assumptions may be wrong. As mentioned at https://johnlewis.ie/alls-well-that-braswell/ - if one would have a full screen of text output, it might take a full minute to draw. Think of a 300bps modem line. With short and few lines like with test iso 6, it only took maybe 10-20s or so though.

[Snwint-g (snwint-g)]

I'm currently out of ideas and it will be tricky to make progress without such a device at my desk. :-(

Issues I've seen:

- the video bios knows only one video mode with an unusual resolution; the standard gfxboot script doesn't expect this (and doesn't provide a theme in this resolution), but that can be trivially adjusted

- it seems that the graphics card can only be accessed via framebuffer; but gfxboot uses the old method via 64k windows mapped at 0xa0000 for drawing; I've added a patch that changes this (see link below) - and which works at least on some test machines

- it still doesn't work here; the patch seems to be ok because you can (a) draw directly by using the framebuffer pointer and do memory writes (the dots you see with the test isos) and (b) the debug window is visible (it's drawn using standard internal routines)

- my suspicion atm is that _reading_ from the framebuffer causes problems: it's done implicitly internally at a number of places and can't be avoided (design decision from the old times where free memory was scarce); also, maybe strange mtrr settings are an issue

I've put the current state into the chrome_fb branch (there's some translation update that slipped into it which can be ignored). When you build the 'test_fb' theme, you basically get test iso 7.

https://github.com/openSUSE/gfxboot/tree/chrome_fb

[Timo Jyrinki (timo-jyrinki)]

Thank you for the investigation! It seems valuable information nevertheless.

In case budget for extra hardware is found, for example this particular Chromebook is the 4GB/32GB model at https://www.amazon.de/Acer-Chromebook-CB5-132T-C732-Convertible-Quad-Core/dp/B01618Z3R4/278-3649416-4927750

I bought it for experimentation myself, since it has some interesting features like Coreboot (like all Chromebooks), touch screen, 14nm CPU with modern GPU features (Broadwell like) and 4GB RAM which is useful amount.

[Timo Jyrinki (timo-jyrinki)]

Notably I've now bypassed the gfxboot by installing Ubuntu on another computer to yet another USB stick (that is, two USB sticks attached to the computer) and using this install target USB as the boot device on my Chromebook.

gfxboot is only used when starting Ubuntu installation media in legacy mode, so a ready install does work.

[Timo Jyrinki (timo-jyrinki)]

Wow, with ubuntu-16.10-beta2 I do again get the "boot:" prompt and this time the 'live' works on my Chromebook! So, no need for trick in #40.

[Timo Jyrinki (timo-jyrinki)]

Just one for confirmation that while 16.04 USB loops in the text mode boot menu after graphics initialization failed (when trying to type "live"), 16.10 works and boots fine with the same live typing.

[Gintaras (gintaras4u)]

Another confirmation: Y Y 16.10 finally works on Toshiba Chromebook 2 (2015). Bugs were partially overridden using external DVD drive through USB 2.0 instead of flash or SD card drive. "help" after boot was helpful too. It took couple days to figure to use DVD drive ;)

[Daniel van Vugt (vanvugt)]

Confirmed with Ubuntu 16.10, this bug still occurs, but typing "help" as a workaround will get you booting just fine.

[[Po]lentino (polentino911)]

It's been almost one year and still, no fix for that.. Even though even the new Mint18 works.. great..
And I'm talking about the *Pixel 2*, in case somebody didn't read my description at the beginning.

[Robert Sloboda (robertusa)]

Based on favorable feedback and problems with Ubuntu on Chromebooks, I Will be trying Linux Mint and GalliumOS, since there is no declared fix/time-frame or debugging process for Ubuntu. Perhaps this is the fork in the road, where I commit all hardware to a migration plan away from Ubuntu?

Compatibility matrix is sparse for Ubuntu, and I don't see the effort to improve it to address high volume platforms like Acer Chromebooks, and Samsung Chromebooks.

I'm happy to contribute to Ubuntu-Chromebook testing, but someone has to coordinate the Chromebook-Ubuntu release and Chromebook fixes.

Too bad, Chromebooks and dual-boot ChromeOS/Linux are a perfect combo for Education, R&D, software development, and the consumer space :(

I guess we'll have to go with the Linux distro that's putting in the most effort for Chromebook compatibility :(

[Robert Sloboda (robertusa)]

I have this problem also on the latest 16.04.1 ISO, trying to install on a Samsung Chromebook 3, xe500c13-k02us. Long standing issue?

[Timo Jyrinki (timo-jyrinki)]

As mentioned, works in Ubuntu 16.10 and newer. The message is still there but can be bypassed.

Note that Mint is Ubuntu with small tweaks, so Mint 18 (built on Ubuntu 16.04) working probably means their live image creation uses something else than gfxboot for the first run menu. Fixing gfxboot would be the best option, since changing to something else could break other computers too. Ability to skip gfxboot would be nice though.

Before 16.10 I successfully did 16.04 installation by installing on another computer, and then transferring that installation to my Chromebook. Gfxboot is only used for Legacy boot's live session graphical menu, not for booting installed Ubuntu or for the UEFI live boot. So if any Chromebook gets non-Legacy boot working, also live image should boot without the error/warning message.

These are the options currently. Feel free to co-operate a final full fix to development Ubuntu or backporting the workaround possibility to 16.04.

[Siro-3 (siro-3)]

gfxboot doesn't support 24bpp or 32bpp.

The only mode that is supported by coreboot's native graphics initialization is 32bpp.

As the graphics initialization is done by coreboot, the pixel format can't be changed in (Sea)VGABIOS.

I'm working on supporting multiple resolutions, but the main problem persists. There will be only one advertised pixel format ever.

[Snwint-g (snwint-g)]

gfxboot supports 32bit but not 24bit.

[Siro-3 (siro-3)]

You are right.
I got confused looking at the code:
pixel_bits db 0 ; pixel size (8 or 16)
color_bits db 0 ; color bits (8, 15 or 16)

This should be fixed.

SeaVGABios advertises 24bpp as the panel does support 24bpp, even though the VBE format should be 32bpp. I'll send a fix to SeaBIOS.

[Siro-3 (siro-3)]

I found another issue:
I tested KDE Neon Live DVD. It does not boot because the code checks additional window attributes:

  mov dx,[es:edi+2] ; win A/B attributes
  and dx,707h
  cmp dl,7
  jz set_mode_50 ; win A is rw

It depends on VBE_WINDOW_ATTRIBUTE_RELOCATABLE.
The comment indicates that it needs only VBE_WINDOW_ATTRIBUTE_READABLE and VBE_WINDOW_ATTRIBUTE_WRITEABLE.

Is the attribute VBE_WINDOW_ATTRIBUTE_RELOCATABLE required ?

It shows a splash screen and boots if I just advertise VBE_WINDOW_ATTRIBUTE_RELOCATABLE without checking what's it's good for.

[Snwint-g (snwint-g)]

> SeaVGABios advertises 24bpp as the panel does support 24bpp, even though the
> VBE format should be 32bpp. I'll send a fix to SeaBIOS.

Uhm, is there a way to detect this situation? Like, add at least the color mask
bits up to 32?

> Is the attribute VBE_WINDOW_ATTRIBUTE_RELOCATABLE required ?

Good point. It isn't.

[Siro-3 (siro-3)]

(In reply to Steffen Winterfeldt from comment #29)
> > SeaVGABios advertises 24bpp as the panel does support 24bpp, even though the
> > VBE format should be 32bpp. I'll send a fix to SeaBIOS.
>
> Uhm, is there a way to detect this situation? Like, add at least the color
> mask
> bits up to 32?
Yes that should be working, but all VBE clients expect the bpp to match the accumulated color bit mask.

I've sent a fix to SeaBIOS.

>
> > Is the attribute VBE_WINDOW_ATTRIBUTE_RELOCATABLE required ?
>
> Good point. It isn't.
Looking at the code is seems that relocation is required as the "window" has a maximum pagesize of 64K, but I'm not familar with those addressing modes.

In VBE2.0 there's a linear framebuffer that does not need relocations at all and it's the only mode supported by coreboot's SeaVGABios implementation.

Would it be possible to add VBE2 and linear framebuffer support to gfxboot ?

[Snwint-g (snwint-g)]

> Looking at the code is seems that relocation is required

You're right; after reading up the vbe specs again, 'relocation' means
mapping different regions into the window. So yes, it's required and the
code is correct.

> Would it be possible to add VBE2 and linear framebuffer support to gfxboot?

Yes, I've done this in the branch mentioned in comment 23. The patch basically
simulates the 64k window thing by moving 64k segment selectors across the framebuffer.

[Siro-3 (siro-3)]

My patches made it into SeaBios git.
Following points are fixed:
* Advertise 32bpp instead of 24bpp
* Advertise additional VBE modes

I tried your examples but I'm not sure what they want to show, and pressing ESC doesn't work. It looks like it crashes.

Is there anything I can help at ?

[Snwint-g (snwint-g)]

I don't see any reason why the code in the chrome_fb branch shouldn't work. It does, for example, work in qemu as running './gfxtest -t test_fb' shows.

From Timo's reports it seems it gets the framebuffer address right: the code in
themes/test_fb/test_fb.bc that draws directly by writing bytes into the fb and creates the diagonal pixel pattern seemed to work. But then it gets wrong.

I don't have an idea so far, why.

[Siro-3 (siro-3)]

Fixed by https://github.com/openSUSE/gfxboot/pull/25

Tested on real hardware.

[Snwint-g (snwint-g)]

Thanks a lot!

Then, AIUI, the only thing left is to recognize the video mode as 32bit even though it's advertised as 24bit, right? Can we do that by adding up the
rgb+reserved bits and use this if the sum is > than bits_per_pixel?

[Siro-3 (siro-3)]

If you mind adding a workaround for broken VGABIOS, yes that's the solution.

Please note that the bpp is correctly advertised in SeaBios git.
With the next stable release this issue will be fixed, too.

[Snwint-g (snwint-g)]

Patrick, if you could try out

https://github.com/openSUSE/gfxboot/pull/26

this would be great. There should be everything in place now.

[Snwint-g (snwint-g)]

I think it's all in Tumbleweed meanwhile, closing.

[Timo Jyrinki (timo-jyrinki)]

gfxboot upstream 4.5.22 (https://github.com/openSUSE/gfxboot/releases/tag/4.5.22) and newer would now have this fixed.

[Siro-3 (siro-3)]

My framebuffer fixes are part SeaBIOS 1.11.0 stable.

[Waz (paviluf)]

If I understand correctly, with 18.04 and SeaBIOS 1.11.0 the installer should work ?

[dan (byrd)]

Hello All!!
        I would like to start off by saying thank you for all your hard work in trying to figure this issue out thanks again to all.

       so here i was with my new Acer CB5-571 with chrome OS on it and i just couldn't handle it any more i'm in the process of learning Linux and found that i could install it on my Chromebook, after a few hurdles i was able to finely get to the bios screen aka sea bios now i got this error from the USB drive and could not get past it. after reading the forum i came accost a post that said something along thew lines of "live" at that point it was like (LIGHT BULB) so i just simply typed live at the BOOT: command prompt and just like that it took off and i'm now installing kubuntu 17.10.1....

       I'm sure it may be way more complicated for some but i thought it would be good for me to post this to the forum as i normally don't in fact this is my very first post ever.. again i appreciate all of you in all the hard work every one has provided to this issue and i hope my findings help

[Waz (paviluf)]

The problem is still present on Ubuntu 18.04 daily iso ! The "help" workaround still work.
Since it seem fixed can the fix be integrated in Ubuntu 18.04 please. Thanks !

[KhoPhi (khophi)]

Problem still exists on December 2018. Ubuntu, Ubuntu, Ubuntu, hmmm 🤦🏾‍♂️

[Daniel van Vugt (vanvugt)]

Yes, looks like the bug was fixed upstream last year. But also Ubuntu's version of gfxboot is years out of date:

https://launchpad.net/ubuntu/+source/gfxboot
https://github.com/openSUSE/gfxboot/releases

[Daniel van Vugt (vanvugt)]

Specifically, this bug is fixed in gfxboot version 4.5.22, but Ubuntu ships version 4.5.2

[Joseph (noob1000)]

I just type help then press enter 2 times

[Daniel van Vugt (vanvugt)]

gfxboot (4.5.73-2) unstable; urgency=medium

[Daniel van Vugt (vanvugt)]

^^^
That fix is in Ubuntu 21.04 only right now.