root@ubuntu:/home/ubuntu# sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.10
Caution: invalid main GPT header, but valid backup; regenerating main header from backup!
Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: OK
Backup partition table: OK
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: damaged
Found valid MBR and corrupt GPT. Which do you want to use? (Using the GPT MAY permit recovery of GPT data.)
1 - MBR
2 - GPT
3 - Create blank GPT
I’ve tried both options (1 - MBR and 3 - Create blank GPT), but it doesn’t help — the device still cycles between blue and yellow LEDs.
Yes, I’m aware - I’ve already tried 24.10.5 as well, and the result is the same boot loop (blue → yellow → blue). Here’s what I’ve done:
-rw-r--r-- 1 0 0 2.7M Jan 23 07:24 linux-4.9.149+x_opt4perf.tgz
-rw-r--r-- 1 1000 1000 120M Jan 30 09:40 openwrt-24.10.3-apm821xx-sata-wd_mybooklive-ext4-factory.img
-rw-r--r-- 1 1000 1000 9.9M Jan 30 09:22 openwrt-24.10.3-apm821xx-sata-wd_mybooklive-ext4-factory.img.gz
-rw-r--r-- 1 1000 1000 120M Feb 5 11:08 openwrt-24.10.5-apm821xx-sata-wd_mybooklive-ext4-factory.img
-rw-r--r-- 1 1000 1000 15K Feb 5 12:14 openwrt-25.12.0-rc4-apm821xx-sata-wd_mybooklive-apollo3g.dtb
-rw-r--r-- 1 1000 1000 120M Feb 5 12:14 openwrt-25.12.0-rc4-apm821xx-sata-wd_mybooklive-ext4-factory.img
-rw-r--r-- 1 1000 1000 120M Jan 30 10:28 openwrt-apm821xx-sata-wd_mybooklive-ext4-factory.img
drwx------ 6 1000 1000 120 Jan 21 12:00 snap
-rwxr-xr-x 1 1000 1000 1.2K Jan 21 13:44 st.sh
root@ubuntu:/home/ubuntu# dd if=openwrt-24.10.5-apm821xx-sata-wd_mybooklive-ext4-factory.img of=/dev/sda bs=1M
120+0 records in
120+0 records out
125829120 bytes (126 MB, 120 MiB) copied, 0.0331047 s, 3.8 GB/s
root@ubuntu:/home/ubuntu# gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.10
Caution: invalid main GPT header, but valid backup; regenerating main header from backup!
Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: OK
Backup partition table: OK
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: damaged
Found valid MBR and corrupt GPT. Which do you want to use? (Using the GPT MAY permit recovery of GPT data.)
1 - MBR
2 - GPT
3 - Create blank GPT
Your answer: 1
Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Model: EARX-00PASB0
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 322FA5D2-EC2E-4380-BC2C-B0550CEBC47C
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 3906799725 sectors (1.8 TiB)
Number Start (sector) End (sector) Size Code Name
1 8192 24575 8.0 MiB 8300 Linux filesystem
2 32768 245759 104.0 MiB 8300 Linux filesystem
root@ubuntu:/home/ubuntu# sync
After writing the image and inserting the drive into the right bay of the MBL Duo, it still cycles between blue and yellow LEDs - no stable boot. The partition layout matches OpenWrt’s expected structure (sda1 = boot, sda2 = rootfs), so I suspect the issue might be related to U-Boot expecting a different device tree or boot script behavior on Duo hardware.
Oh, that's very interesting, thank you for the pointer. I wrote the majority of the MBL Wiki page, but this one escaped me.
I actually tried this myself years ago, using the same method (fatload/ext2load from uboot), and for some reason it took uboot incredibly long to load, something like 20 or 30 minutes, to load a back-then-not-even-functional OpenWrt from USB. I eventually gave up on it, and there's records of all of that here on the forum, even though I can't find it anymore.
I should give it another shot. And of course if this turns out to be more practical than theoretical I'll very happily stand corrected, it would actually prompt me to put my MBL Duos back into service.
Edit: Turns out I remembered correctly, it takes an usually long time to load the boot image from USB, but my memory exaggerrated how long it takes, it's actually "only" about 3 minutes. The boot process as entered in uboot is not particularly robust (the Wiki instructions assume /dev/sdc for the boot drive, which is only true in one of three variable scenarios), and that's tricky to fully remedy and make universal. But yes, it is more or less workable.
Now while I have the thing set up and connected to serial, let's see about the boot problems of the OP.
To confirm that it's not a problem with OpenWrt, I have set up right in front of me a MBL Duo running 25.12.0-rc4, and I just watched it boot on the serial console off a random hard drive. It takes about 40 seconds to load the boot image, after that OpenWrt takes about 20 seconds to boot. That's not particularly fast, in part because the bootloader scripts are a bit redundant and could be optimized, but yes, it works.
Which leaves three possible reasons for your problems:
You are writing the wrong image. Did you write a factory image? You could try writing one directly from the download repository, not from the irmware selector (I would suggest the "squashfs-factory" variant).
Your hard drive is knackered or somehow incompatible. You could try a different disk.
Your MBL is knackered. I've seen MBLs randomly fail before, unfortunately the hardware is aging.
Complete certainty, especially to see if the MBL is borked, will probably only be possible if you set up a serial console and check where exactly in the boot process it fails.
