Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#40637 - [linux] 3.17.x Hard reset while booting x86_64 on some Chromebooks

Attached to Project: Arch Linux
Opened by s (scot14) - Sunday, 01 June 2014, 22:35 GMT
Last edited by Doug Newgard (Scimmia) - Saturday, 18 April 2015, 14:35 GMT
Task Type Bug Report
Category Upstream Bugs
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No


When booting x86_64 from the iso, a hard reset occurs before during kernel loading or decompression. This problem is described at:

I've reproduced the problem in the 2014.04.01 and 2014.06.01 iso's with verified md5sum's on a Toshiba Chromebook.

x86_64 boots from the 2013.10.01 iso
i686 boots from all three iso's

Steps to reproduce:
1. Download the dual iso image
2. Verify the md5sum
3. Burn to USB key
4. Boot off USB key on Toshiba Chromebook (in developer mode)
5. Select 'Boot Arch Linux (i686)' -> successful boot
6. Powerdown and repeat step 4
7. Select 'Boot Arch Linux (x86_64)' -> hard reset
8. step4 automatically repeated
9. Select 'Boot Arch Linux (x86_64)' with additional kernel command line option "mem=1536m" -> hard reset

In steps 7 and 9, after the menu selection of x86_64 is made and Enter is pressed, then the following text appears on the screen:

Loading boot/x86_64/vmlinuz... ok
Loading boot/x86_64/archiso.img... ok
[The screen is cleared]
Probing EDD (edd=off to disable)... ok

Then the hard reset occurs (screen goes blank, then the Google Chrome logo appears, followed by the SeaBIOS messages and then the archlinux boot screen again).

Adding "edd=off" to the kernel command line, both with and without the "mem=1536m" option did not change the outcome.

Adding "earlyprintk=vga" to the command line did not result in any additional text before the hard reset.

The obvious workaround for this bug is to install using the old iso, but it is disappearing from mirrors.
This task depends upon

Closed by  Doug Newgard (Scimmia)
Saturday, 18 April 2015, 14:35 GMT
Reason for closing:  Fixed
Comment by s (scot14) - Sunday, 01 June 2014, 22:39 GMT
Forgot to mention that the next line during a normal boot, after probing for EDD, is:

early console in decompress_kernel
Comment by s (scot14) - Monday, 02 June 2014, 16:31 GMT
My mistake, the report of the problem on the Dell Chromebook is at

Another report of the problem on the HP 14 Chromebook is at
Comment by Gerardo Exequiel Pozzi (djgera) - Saturday, 01 November 2014, 23:36 GMT
status with new Linux 3.17.1 included in recent ISO?
Comment by s (scot14) - Sunday, 02 November 2014, 16:52 GMT
archlinux-2014.11.01-dual.iso exhibits identical behavior on a Haswell-based Toshiba Chromebook.

Possibly related to
Comment by Gerardo Exequiel Pozzi (djgera) - Sunday, 02 November 2014, 20:18 GMT
Please report this to upstream. There is nothing to do here. Thanks.
Comment by James Barnett (jbarnett) - Saturday, 31 January 2015, 01:16 GMT
Flashing John Lewis's coreboot image has been reported to resolve this issue. I've done that on my Acer C720 and can boot 2015.01.01 64-bit successfully. Red Hat has a bug report ( on the same issue, and someone else has reported success on flashing his coreboot and resolving it as well.
Comment by s (scot14) - Monday, 09 February 2015, 21:50 GMT
Patch is at

According to (and other threads on the syslinux mailing list) it may be awhile before this patch finds its way into an official release. Will you go ahead and apply it to the Arch installer, or make a test build of the installer that users can test?
Comment by s (scot14) - Saturday, 18 April 2015, 14:13 GMT
The x86_64 kernel boots from both archlinux-2015.03.01-dual.iso and archlinux-2015.04.01-dual.iso, so this is no longer seems to be an issue.

As a side note, the referenced patch has been accepted upstream, although not yet distributed in an official syslinux release.