Duo 1 boots to Android with `fastboot set_active other; fastboot continue` but can't boot to recovery

[SilverEzhik]

Hey there, so I got a Surface Duo 1 (128GB, AT&T) that was bricked by its previous owner. It would get to the bootloader and boot to TWRP but not anything else. According to them, they messed it up while flashing a ROM. From what I've seen, they hosed it by flashing the system.img from an unpacked stock Microsoft recovery image to super - the super on the device started with that image byte-for-byte. I do have a backup of this if need be.

I managed to cook my own super with this incantation:

lpmake \
 --super-name super \
    --device super:15032385536 \
    --metadata-size 65536 \
    --metadata-slots 2 \
    --group slot_a:7516192768 \
    --group slot_b:7516192768 \
\
    --partition=odm_a:readonly:1253376:slot_a \
    --partition=odm_b:readonly:1253376:slot_b \
    --image=odm_a=odm.simg --image=odm_b=odm.simg \
\
    --partition=product_a:readonly:4036599808:slot_a \
    --partition=product_b:readonly:4036599808:slot_b \
    --image=product_a=product.simg --image=product_b=product.simg \
\
    --partition=system_a:readonly:1212825600:slot_a \
    --partition=system_b:readonly:1212825600:slot_b \
    --image=system_a=system.simg --image=system_b=system.simg \
\
    --partition=system_ext_a:readonly:545341440:slot_a \
    --partition=system_ext_b:readonly:545341440:slot_b \
    --image=system_ext_a=system_ext.simg --image=system_ext_b=system_ext.simg \
\
    --partition=vendor_a:readonly:723410944:slot_a \
    --partition=vendor_b:readonly:723410944:slot_b \
    --image=vendor_a=vendor.simg --image=vendor_b=vendor.simg \
\
    --sparse \
    --output _super.simg 

(I was getting errors like "Invalid sparse file format at header magic" when running lpmake, converting the input images to sparse ones with img2simg helped.)

Then I flashed this in the bootloader (fastboot flash super) and wiped userdata with fastboot -w, and now this went from being a full on brick to at least letting me do a tethered boot - I can get to Android after running:

fastboot set_active other
fastboot set_active other
fastboot continue

However, I'm still unable to get to recovery or fastbootd, and every reboot throws me back to the bootloader, with fastboot reporting that both slots are unbootable and the current slot is set to b.

Output of fastboot getvar all

(bootloader) parallel-download-flash:yes
(bootloader) battery-level:95
(bootloader) hw-revision:20002
(bootloader) unlocked:yes
(bootloader) off-mode-charge:0
(bootloader) charger-screen-enabled:0
(bootloader) battery-soc-ok:yes
(bootloader) battery-voltage:4321
(bootloader) version-baseband:
(bootloader) version-bootloader:2022.815.527
(bootloader) erase-block-size: 0x1000
(bootloader) logical-block-size: 0x1000
(bootloader) variant:SDM UFS
(bootloader) partition-type:vbmeta_system_b:raw
(bootloader) partition-size:vbmeta_system_b: 0x3E5000
(bootloader) partition-type:vbmeta_system_a:raw
(bootloader) partition-size:vbmeta_system_a: 0x10000
(bootloader) partition-type:super:raw
(bootloader) partition-size:super: 0x380000000
(bootloader) partition-type:fsc:raw
(bootloader) partition-size:fsc: 0x1DB000
(bootloader) partition-type:fsg:raw
(bootloader) partition-size:fsg: 0x200000
(bootloader) partition-type:modemst2:raw
(bootloader) partition-size:modemst2: 0x200000
(bootloader) partition-type:modemst1:raw
(bootloader) partition-size:modemst1: 0x200000
(bootloader) partition-type:ALIGN_TO_128K_2:raw
(bootloader) partition-size:ALIGN_TO_128K_2: 0x1A000
(bootloader) partition-type:secdata:raw
(bootloader) partition-size:secdata: 0x8000
(bootloader) partition-type:logfs:raw
(bootloader) partition-size:logfs: 0x100000
(bootloader) partition-type:uefivarstore:raw
(bootloader) partition-size:uefivarstore: 0x80000
(bootloader) partition-type:apdp:raw
(bootloader) partition-size:apdp: 0x20000
(bootloader) partition-type:devinfo:raw
(bootloader) partition-size:devinfo: 0x1000
(bootloader) partition-type:sftpfw_b:raw
(bootloader) partition-size:sftpfw_b: 0x2000000
(bootloader) partition-type:uefisecapp_b:raw
(bootloader) partition-size:uefisecapp_b: 0x40000
(bootloader) partition-type:dtbo_b:raw
(bootloader) partition-size:dtbo_b: 0x1000000
(bootloader) partition-type:vbmeta_b:raw
(bootloader) partition-size:vbmeta_b: 0x10000
(bootloader) partition-type:qupfw_b:raw
(bootloader) partition-size:qupfw_b: 0x20000
(bootloader) partition-type:devcfg_b:raw
(bootloader) partition-size:devcfg_b: 0x10000
(bootloader) partition-type:cmnlib64_b:raw
(bootloader) partition-size:cmnlib64_b: 0xC0000
(bootloader) partition-type:cmnlib_b:raw
(bootloader) partition-size:cmnlib_b: 0x80000
(bootloader) partition-type:boot_b:raw
(bootloader) partition-size:boot_b: 0x6000000
(bootloader) partition-type:keymaster_b:raw
(bootloader) partition-size:keymaster_b: 0x80000
(bootloader) partition-type:dsp_b:raw
(bootloader) partition-size:dsp_b: 0x4000000
(bootloader) partition-type:abl_b:raw
(bootloader) partition-size:abl_b: 0x100000
(bootloader) partition-type:bluetooth_b:raw
(bootloader) partition-size:bluetooth_b: 0x100000
(bootloader) partition-type:modem_b:raw
(bootloader) partition-size:modem_b: 0xB400000
(bootloader) partition-type:hyp_b:raw
(bootloader) partition-size:hyp_b: 0x800000
(bootloader) partition-type:tz_b:raw
(bootloader) partition-size:tz_b: 0x600000
(bootloader) partition-type:aop_b:raw
(bootloader) partition-size:aop_b: 0x80000
(bootloader) partition-type:sftpfw_a:raw
(bootloader) partition-size:sftpfw_a: 0x2000000
(bootloader) partition-type:uefisecapp_a:raw
(bootloader) partition-size:uefisecapp_a: 0x40000
(bootloader) partition-type:dtbo_a:raw
(bootloader) partition-size:dtbo_a: 0x1000000
(bootloader) partition-type:vbmeta_a:raw
(bootloader) partition-size:vbmeta_a: 0x10000
(bootloader) partition-type:qupfw_a:raw
(bootloader) partition-size:qupfw_a: 0x20000
(bootloader) partition-type:devcfg_a:raw
(bootloader) partition-size:devcfg_a: 0x10000
(bootloader) partition-type:cmnlib64_a:raw
(bootloader) partition-size:cmnlib64_a: 0xC0000
(bootloader) partition-type:cmnlib_a:raw
(bootloader) partition-size:cmnlib_a: 0x80000
(bootloader) partition-type:boot_a:raw
(bootloader) partition-size:boot_a: 0x6000000
(bootloader) partition-type:keymaster_a:raw
(bootloader) partition-size:keymaster_a: 0x80000
(bootloader) partition-type:dsp_a:raw
(bootloader) partition-size:dsp_a: 0x4000000
(bootloader) partition-type:abl_a:raw
(bootloader) partition-size:abl_a: 0x100000
(bootloader) partition-type:bluetooth_a:raw
(bootloader) partition-size:bluetooth_a: 0x100000
(bootloader) partition-type:modem_a:raw
(bootloader) partition-size:modem_a: 0xB400000
(bootloader) partition-type:hyp_a:raw
(bootloader) partition-size:hyp_a: 0x800000
(bootloader) partition-type:tz_a:raw
(bootloader) partition-size:tz_a: 0x600000
(bootloader) partition-type:aop_a:raw
(bootloader) partition-size:aop_a: 0x80000
(bootloader) partition-type:sfpd:raw
(bootloader) partition-size:sfpd: 0x1800000
(bootloader) partition-type:ddr:raw
(bootloader) partition-size:ddr: 0x100000
(bootloader) partition-type:ALIGN_TO_128K_1:raw
(bootloader) partition-size:ALIGN_TO_128K_1: 0x1A000
(bootloader) partition-type:xbl_config_b:raw
(bootloader) partition-size:xbl_config_b: 0x3F5000
(bootloader) partition-type:xbl_b:raw
(bootloader) partition-size:xbl_b: 0x1000000
(bootloader) partition-type:xbl_config_a:raw
(bootloader) partition-size:xbl_config_a: 0x20000
(bootloader) partition-type:xbl_a:raw
(bootloader) partition-size:xbl_a: 0x1000000
(bootloader) partition-type:userdata:ext4
(bootloader) partition-size:userdata: 0x1A00273000
(bootloader) partition-type:misc:raw
(bootloader) partition-size:misc: 0x100000
(bootloader) partition-type:frp:raw
(bootloader) partition-size:frp: 0x80000
(bootloader) partition-type:metadata:raw
(bootloader) partition-size:metadata: 0x1000000
(bootloader) partition-type:persist:raw
(bootloader) partition-size:persist: 0x2000000
(bootloader) partition-type:ssd:raw
(bootloader) partition-size:ssd: 0x2000
(bootloader) has-slot:modem:yes
(bootloader) has-slot:system:no
(bootloader) current-slot:b
(bootloader) has-slot:boot:yes
(bootloader) slot-retry-count:b:7
(bootloader) slot-unbootable:b:yes
(bootloader) slot-successful:b:yes
(bootloader) slot-retry-count:a:7
(bootloader) slot-unbootable:a:yes
(bootloader) slot-successful:a:yes
(bootloader) slot-count:2
(bootloader) secure:yes
(bootloader) serialno:NNNNNNNNNNNN
(bootloader) product:surfaceduo
(bootloader) snapshot-update-status:none
(bootloader) is-userspace:no
(bootloader) max-download-size:367521792
(bootloader) kernel:uefi

[SilverEzhik]

I FIXED IT!

Okay, so. I was stuck on slot b, with both it and a marked unbootable. None of the changes to this in the bootloader ever persisted. The trick to boot an image did work, but the bootloader itself still was stuck thinking everything is broken and unbootable - so every reboot required fastboot.

However, it is possible to switch slots and mark them as successful within Android itself.

I had to get Magisk installed first:

1. Take the boot image used to create the super image and send it to the Duo
2. Download Magisk and install it on the Duo
3. Patch the boot image from 1 using Magisk
4. Pull the patched image back to the computer
5. Boot the patched image with the usual set_active trick then fastboot boot magisk_boot.img

(I also flashed the boot image, but don't know if this is really necessary):

1. Reboot the Duo into TWRP (directly flashing the image did not work for me)
2. Push the patched image using adb push
3. Flash the image to both slots using dd if=/sdcard/magisk_boot.img of=/dev/block/platform/soc/1d84000.ufshc/by-name/boot_a and then boot_b

After booting into rooted Android, install the bootctl Magisk module: https://github.com/roihershberg/bootctl-binary

Reboot again with the set_active and magisk_boot.img trick.

Once booted, get an adb shell then ran su. Approve the prompt on the Duo.

Then in the root prompt, run:

bootctl get-current-slot

This gives you the current slot as a number - either 0 or 1. It was 1 for me.

Then run

bootctl mark-boot-successful
bootctl set-active-boot-slot 0

I used slot 0 as my current slot was 1 - might make sense to switch it otherwise.

Then do adb reboot.

For me, it then finally booted into recovery, but gave me a message saying that Android could not start, offering to wipe data. I picked "try again". After this, it actually booted untethered!

[gus33000]

Yeah the issue you see is that the entire fourth LUN on the UFS is read only til reinitialized by the Linux kernel part of the android boot image, this creates some friction between the state recorded in TrustZone, and the one on disk as they can not match; and the XBL portion will always fail to update the disk state.

Most if not all of the boot issues on this device are really just due to this.

There are other methods to fix this but yours seems by far to be the simplest I have seen yet, Thank you for sharing it :)

I know this could come far fetched, but would you be up to write some kind of markdown as a gist or do a PR for the guides repo maybe to have some sort of document to help recreate super partitions from scratch or, fix what you just did fix with above instructions? you seem well versed (more than me at least) with the state of android tooling so far, that could be awesome as a resource for sure.

No obligation though just asking =)

[SilverEzhik]

Oh I definitely want to clean this up - I'm actually curious if this can be simplified by doing bootctl in TWRP - and if we can bundle both parted and bootctl in the TWRP image. If we could, then we could additionally bundle a bunch of scripts to automate all the tedious parts of it.

Top priority was getting this out in public - there's a massive lack of info on these things so hopefully this rough write-up can help unbrick a Duo or two.

[rladudgnsnl]

Hi @SilverEzhik,

I recently dealt with a very similar situation on my Surface Duo 1
devices and successfully reached full Android boot (not just tethered)
on my 128GB unit. Your setup looks remarkably close to mine.

The key addition that unlocked full boot was patching vbmeta with
AVB flags=3 (HASHTREE_DISABLED | VERIFICATION_DISABLED) and writing
it via TWRP dd (since fastboot flash vbmeta is blocked by Critical
lock).

Recovery method (verified on my 128GB):

1. Rebuild super with lpmake (same as you did)

2. Patch vbmeta_a/b with flags=3:

   import struct
   d = bytearray(open('vbmeta_original.img','rb').read())
   struct.pack_into('>I', d, 0x78, 3)
   open('vbmeta_patched.img','wb').write(d)

3. Same patch for vbmeta_system_a/b.

4. Boot into TWRP (fastboot boot surfaceduo1-twrp.img), push patched
   files, then:
   dd if=/data/vbmeta_patched.img of=/dev/block/.../by-name/vbmeta_a
   dd if=/data/vbmeta_patched.img of=/dev/block/.../by-name/vbmeta_b
   dd if=/data/vbmeta_system_patched.img of=/dev/block/.../vbmeta_system_a
   dd if=/data/vbmeta_system_patched.img of=/dev/block/.../vbmeta_system_b

5. fastboot erase misc + fastboot --set-active=a + fastboot continue

After OOBE, I was able to install Magisk permanently + flash Android 16
GSI via fastbootd. The 128GB is now fully self-booting.

⚠️ CRITICAL WARNING: Once flags=3 patched vbmeta gets you to OOBE,
NEVER revert to original vbmeta. The reassembled super_both.img's
hash no longer matches the original vbmeta, so restoring it breaks
even the continue path — and TWRP boot becomes impossible too
(AVB verification). This exactly happened on my 256GB, which is now
completely stuck in Load Error.

Full writeup with all the failure modes I documented:

• XDA: https://xdaforums.com/t/guide-surface-duo-1-super-partition-corruption-recovery-woa-issue-84-practical-solution-firehose-loader-request.4786160/
• Archfx Discussion: [Help] Surface Duo 1 256GB stuck in Load Error after failed recovery attempt — detailed diagnosis + firehose loader request Archfx/duo-de#262

Hope this helps! If you try it and run into the "reboot wall" I
described (fastboot reboot still bootloops, but continue works), I
documented that state extensively — let me know.

— GreemGreem