Media not bootable in BIOS - x86_64 - ODROID H2

OK, those of you that have been waiting, rip away!

I've been trying to get the ODROID H2 here to boot OpenWrt quite unsuccessfully. It runs Debian 10 quite well from an SSD in a USB3 enclosure, or direct connected. When I flash the current snapshot, either ext4 or squashfs (sha256 sum confirmed), to a SSD and either put in the same enclosure or attach it directly, the BIOS doesn't recognize it as bootable.

I can mount both partition 1 ("boot") and partition 2 (root) on a Debian 10 system, at least for the ext4 file system.

Any ideas what to try next?

jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sha256sum openwrt-x86-64-combined-ext4.img.gz 
eed3f3cc3add9bf4ae9364953c5a34a6a033a43a056f5772edeed9dc14955e6f  openwrt-x86-64-combined-ext4.img.gz
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ zcat openwrt-x86-64-combined-ext4.img.gz | sudo dd of=/dev/sdd bs=1M
[sudo] password for jeff: 
0+4622 records in
0+4622 records out
151519232 bytes (152 MB, 144 MiB) copied, 1.19399 s, 127 MB/s
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sudo mount /dev/sdd1 /mnt
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ ls /mnt
boot  lost+found
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sudo umount /mnt
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sudo mount /dev/sdd2 /mnt
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ ls /mnt
bin  dev  etc  lib  lib64  lost+found  mnt  overlay  proc  rom  root  sbin  sys  tmp  usr  var  www
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sudo umount /mnt
jeff@deb-devel:~/devel/openwrt-x86_64/_tmp$ sync

AMI BIOS, 2.19.1268 gets entered, no boot-device options are shown in the menu. Never gets to the kernel.

1 Like

Maybe UEFI (not supported by OpenWrt without patches[0] yet) versus legacy CSM (BIOS)?

Edit: Looks that way.

Edit 2:
[0] I did successfully test a previous state of that pull request on different hardware in UEFI mode a while ago.


Well, that at least those patches have the drive recognized as bootable.

No VGA console shows from there, nor do the Ethernet ports seem to come alive.

Thanks for the pointers -- guess I'll have to format my own drive and install rEFInd or something.

I'd probably first test setting CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y in target/linux/x86/64/config-*

Given that you have Debian running on that device, it might also help to check if maybe UEFI is running in 32 bit mode, in which case you might need CONFIG_EFI_MIXED=y (and more work on the grub side).

1 Like

No idea if this sill applies for UEFI, but - I have an Odroid XU4 running Debian as well, and I had to remember to toggle the boot flag on the /boot partition. Maybe something similar here?

That shouldn't be an issue (famous last words), for UEFI all what matters is GPT partitioning with a FAT32 partition labelled as EF00 (EFI System Partition); although really weird UEFI implementations might look at the protective MBR…

(and yes, having to set a bootflag was/ is one of the most braindead traits of some BIOS implementations)

/sbin/fdisk --type dos <openwrt_image> would allow setting a boot flag on the protective MBR for the GPT partition (it's needed for some systems with a (broken) legacy BIOS to accept GPT for booting, it shouldn't matter for UEFI).

I did double check and the "official" snapshot image (unpatched source, downloaded from OpenWrt) does appear to set the partition to bootable

(parted) print                                                            
Model: Inateck  (scsi)
Disk /dev/sdd: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      262kB   17.0MB  16.8MB  primary  ext2         boot
 2      17.3MB  152MB   134MB   primary  ext2

Partition 1 contains


UEFI by default only has drivers to read from FAT32 filesystems. OpenWrt makes 2 ext2/4 partitions. It won't work.

Apart from that, UEFI can't boot the kernel unless you are also compiling in efi stub in the kernel (so it becomes a EFI executable and can be loaded and executed, or you are using a EFI bootloader that does the booting (i.e. GRUB UEFI).
So again it won't work even if it could read the boot partition, as OpenWrt is not using GRUB EFI.

Since the firmware on that board does not have the CSM feature/module, you can't just boot it in legacy/BIOS mode.

Since apparently no core dev is giving a shit about UEFI support
(the PR has been sitting there for ages, and it's the last one of a list, the first appeared in LEDE days),
you either compile your firmware using that, or just use Debian (or VyOS, a network-oriented Debian dderivative) and be done with it.

1 Like

Yes, it will be running FreeBSD, but I thought I'd benchmark it under OpenWrt with all the interest in "cheap" solutions for gigabit lines.

The PR seems to get some things right, but I'm still tempted to go with a from-scratch solution with an EFI-enabled kernel and a root file system, at least until I can get it to boot once.

GNU Parted 3.2
Using /dev/sdd
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Error: The backup GPT table is corrupt, but the primary appears OK, so that will be used.
OK/Cancel? OK                                                             
Warning: Not all of the space available to /dev/sdd appears to be used, you can fix the GPT to use all of the space (an extra 234145649 blocks) or continue with
the current setting? 
Fix/Ignore? i                                                             
Model: Inateck  (scsi)
Disk /dev/sdd: 120GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                  Flags
128     17.4kB  262kB   245kB                                      bios_grub
 1      262kB   17.0MB  16.8MB  fat16        EFI System Partition  boot, esp
 2      17.3MB  152MB   134MB   ext2                               msftdata

That error is expected and explained in the commit.

Since the image building process has to be generic they can't create the backup GPT table.

GPT has two partition tables, one at the start and one at the end of the drive. They just can't know the size of your drive when they generate the image, so they just add some padding at the end, but no partition table.
Similar for the "not all of the space available appears to be used" error. They can't know what is the size of the drive you will have so they just set a high enough capacity.

The system works fine with just one table and you can fix that error by just opening that in fdisk (a GPT-aware one) or gdisk, and then write to disk.

1 Like

@markbirss As noted on the other thread that link was posted to, and now edited on that wiki page, the referenced branch in jow's repo doesn't exist. The two commits that differ between that repo and master and seem related to UEFI date back to early 2017 and were never accepted by OpenWrt.

Edit: Able to get boot with as linked by slh and bobafetthotmail. With no console it's hard to figure out quite what is going on, but when I narrow things down, I'll try to clarify just what made the change. For now, rebasing the branch from the PR (not from the wiki page) onto one of your choice seems a reasonable approach.

Edit: On the ODRIOD H2 in the default OpenWrt config, the "LAN" port (eth0) is the one above the USB2 ports, the "WAN" port (eth1) is the one above the USB3 ports.

1 Like

Thank you @jeff for making it clear what the current status is regarding UEFI Openwrt support.

I would also like to see better UEFI support since many newer X86 devices lack CSM legacy boot support. Eg my Intel NUC with J4005 cpu


by no console you mean it does not print anything on a screen you connect to the device?
Or you mean its serial/TTL/whatever connection?

Both, unfortunately. I see the AMI splash when it boots, then just an underline when I'd normally expect to see the kernel boot sequence. On the serial, I haven't yet been successful with in getting a kernel console (though can run ttyS0 and ttyS1 from userspace). The grub config looked as though it should enable the serial.

Since it's booting now, I'm running the tests to answer a question on one of the gigabit-router threads, then may go back to figuring out what's going on with the video and serial consoles.

I dont own a Odroid H2 but I can see from the EFI Bios update page

Serial console redirection has been disabled in the latest update ?

Not sure if you have seen this

BIOS Release

GLK-SF 1.07

  • Project Version: GLK-SF 1.07

  • Build Date and Time: 08/09/2019 10:25:45


GLK-SF 1.06

  • Project Version: GLK-SF 1.06

  • Build Date and Time: 08/01/2019 11:32:11


This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.