< Blog

Important update 2018-07-27: This issue is likely related to the “Boot Booster” feature using the same partition type code as EFI System Partitions (0xEF), resulting in the BIOS corrupting ESPs even if said feature is off. This extends the bug’s scope to any hybrid BIOS+UEFI bootloader installed to an EFI partition, not just SYSLINUX, but I no longer have any Eee PC units to test that. The original post is saved below for posterity.

I ran into a weird issue with my own embedded Debian-based Linux system image on an old ASUS Eee PC netbook: the system could boot from the USB installation drive, however, it could not boot from the hard drive once the image was installed. Booting from the hard drive resulted in a blinking cursor (displayed on the second line of text), and no response to Ctrl+Alt+Del. Both drives have identical contents, as the installation drive essentially clones itself to the hard drive.

There appears to be a bug in the BIOS firmware for these devices, which corrupts the first sectors of a SATA hard drive upon attempting to boot from it. Said bug seems to only affect the SYSLINUX bootloader on a FAT/FAT32 filesystem, when not using the boot menu to select a boot device. I’ve reproduced this issue on models 1005HA and 1201T, although I have reason to believe most (if not all) models with the boot screen pictured below are affected.

Image from ADM Blog (the screen on those things is so reflective I couldn't take a picture myself)

The only documented instance of this issue so far comes from the CloudReady Chromium OS distribution (official documentation, forum post), which specifically warns Eee PC users to always boot from USB drives through the boot menu. CloudReady uses SYSLINUX for both the installer and the installed system, although according to them, only the USB installer is affected.

A workaround is to use EXTLINUX instead of SYSLINUX. EXTLINUX operates on Linux filesystems intead of FAT/FAT32. From my own testing, replacing SYSLINUX on a FAT32 partition with EXTLINUX on an ext4 partition (disabling the 64bit filesystem option as required) fixed the corruption on my model 1201T unit. I no longer have the 1005HA, where I had used another workaround which escapes me.

Last update: Sep 19, 2023