A/B System Updates style partitioning support

[GigabyteProductions]

Google Pixel XL uses A/B System Updates (or "Seamless Updates"), where there are multiple system, vendor, boot, among other partitions, using a _a or _b suffix on the name. The purpose of these is that a running OS would install an update by flashing the non-active slot, before trying to boot into it, and users would always have a bootable slot in the event that an update fails.

Due to the naming of partitions on systems with A/B System Updates, the hard coded names will not work.

$ adb -d shell 'cat /proc/cmdline' | tr '[:space:]' '\n' | grep '^androidboot.slot_suffix='
androidboot.slot_suffix=_b

$ adb -d shell 'ls -l /dev/block/bootdevice/by-name'
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
lrwxrwxrwx    1 root     root            16 Jan  3  1970 aboot_a -> /dev/block/sda17
lrwxrwxrwx    1 root     root            16 Jan  3  1970 aboot_b -> /dev/block/sda18
lrwxrwxrwx    1 root     root            16 Jan  3  1970 apdp_a -> /dev/block/sda29
lrwxrwxrwx    1 root     root            16 Jan  3  1970 apdp_b -> /dev/block/sda30
lrwxrwxrwx    1 root     root            15 Jan  3  1970 board_info -> /dev/block/sdf1
lrwxrwxrwx    1 root     root            16 Jan  3  1970 boot_a -> /dev/block/sda19
lrwxrwxrwx    1 root     root            16 Jan  3  1970 boot_b -> /dev/block/sda20
lrwxrwxrwx    1 root     root            15 Jan  3  1970 bootlocker_a -> /dev/block/sda1
lrwxrwxrwx    1 root     root            15 Jan  3  1970 bootlocker_b -> /dev/block/sda2
lrwxrwxrwx    1 root     root            16 Jan  3  1970 cdt -> /dev/block/sdd12
lrwxrwxrwx    1 root     root            16 Jan  3  1970 cmnlib32_a -> /dev/block/sda13
lrwxrwxrwx    1 root     root            16 Jan  3  1970 cmnlib32_b -> /dev/block/sda14
lrwxrwxrwx    1 root     root            16 Jan  3  1970 cmnlib64_a -> /dev/block/sda15
lrwxrwxrwx    1 root     root            16 Jan  3  1970 cmnlib64_b -> /dev/block/sda16
lrwxrwxrwx    1 root     root            16 Jan  3  1970 ddr -> /dev/block/sdd11
lrwxrwxrwx    1 root     root            16 Jan  3  1970 devcfg_a -> /dev/block/sda23
lrwxrwxrwx    1 root     root            16 Jan  3  1970 devcfg_b -> /dev/block/sda24
lrwxrwxrwx    1 root     root            15 Jan  3  1970 devinfo -> /dev/block/sdf4
lrwxrwxrwx    1 root     root            15 Jan  3  1970 devinfobak -> /dev/block/sdd5
lrwxrwxrwx    1 root     root            15 Jan  3  1970 dip -> /dev/block/sdd7
lrwxrwxrwx    1 root     root            15 Jan  3  1970 dpo -> /dev/block/sdd6
lrwxrwxrwx    1 root     root            15 Jan  3  1970 frp -> /dev/block/sde1
lrwxrwxrwx    1 root     root            15 Jan  3  1970 fsc -> /dev/block/sdd8
lrwxrwxrwx    1 root     root            15 Jan  3  1970 fsg -> /dev/block/sdf3
lrwxrwxrwx    1 root     root            16 Jan  3  1970 hosd_a -> /dev/block/sda21
lrwxrwxrwx    1 root     root            16 Jan  3  1970 hosd_b -> /dev/block/sda22
lrwxrwxrwx    1 root     root            16 Jan  3  1970 hyp_a -> /dev/block/sda11
lrwxrwxrwx    1 root     root            16 Jan  3  1970 hyp_b -> /dev/block/sda12
lrwxrwxrwx    1 root     root            15 Jan  3  1970 keymaster_a -> /dev/block/sda3
lrwxrwxrwx    1 root     root            15 Jan  3  1970 keymaster_b -> /dev/block/sda4
lrwxrwxrwx    1 root     root            15 Jan  3  1970 metadata -> /dev/block/sde5
lrwxrwxrwx    1 root     root            15 Jan  3  1970 mfg -> /dev/block/sdf2
lrwxrwxrwx    1 root     root            15 Jan  3  1970 misc -> /dev/block/sdd1
lrwxrwxrwx    1 root     root            16 Jan  3  1970 modem_a -> /dev/block/sda25
lrwxrwxrwx    1 root     root            16 Jan  3  1970 modem_b -> /dev/block/sda26
lrwxrwxrwx    1 root     root            15 Jan  3  1970 modemst1 -> /dev/block/sdd9
lrwxrwxrwx    1 root     root            16 Jan  3  1970 modemst2 -> /dev/block/sdd10
lrwxrwxrwx    1 root     root            16 Jan  3  1970 msadp_a -> /dev/block/sda27
lrwxrwxrwx    1 root     root            16 Jan  3  1970 msadp_b -> /dev/block/sda28
lrwxrwxrwx    1 root     root            15 Jan  3  1970 persist -> /dev/block/sdd3
lrwxrwxrwx    1 root     root            15 Jan  3  1970 pg1fs -> /dev/block/sde3
lrwxrwxrwx    1 root     root            15 Jan  3  1970 pg2fs -> /dev/block/sde4
lrwxrwxrwx    1 root     root            15 Jan  3  1970 pmic_a -> /dev/block/sda9
lrwxrwxrwx    1 root     root            16 Jan  3  1970 pmic_b -> /dev/block/sda10
lrwxrwxrwx    1 root     root            15 Jan  3  1970 ramdump -> /dev/block/sde2
lrwxrwxrwx    1 root     root            16 Jan  3  1970 reserve0 -> /dev/block/sda36
lrwxrwxrwx    1 root     root            16 Jan  3  1970 reserve3 -> /dev/block/sdd13
lrwxrwxrwx    1 root     root            15 Jan  3  1970 reserve4 -> /dev/block/sde6
lrwxrwxrwx    1 root     root            15 Jan  3  1970 reserve5 -> /dev/block/sdf5
lrwxrwxrwx    1 root     root            15 Jan  3  1970 rpm_a -> /dev/block/sda7
lrwxrwxrwx    1 root     root            15 Jan  3  1970 rpm_b -> /dev/block/sda8
lrwxrwxrwx    1 root     root            15 Jan  3  1970 sec -> /dev/block/sdd4
lrwxrwxrwx    1 root     root            15 Jan  3  1970 ssd -> /dev/block/sdd2
lrwxrwxrwx    1 root     root            16 Jan  3  1970 system_a -> /dev/block/sda33
lrwxrwxrwx    1 root     root            16 Jan  3  1970 system_b -> /dev/block/sda34
lrwxrwxrwx    1 root     root            15 Jan  3  1970 tz_a -> /dev/block/sda5
lrwxrwxrwx    1 root     root            15 Jan  3  1970 tz_b -> /dev/block/sda6
lrwxrwxrwx    1 root     root            16 Jan  3  1970 userdata -> /dev/block/sda35
lrwxrwxrwx    1 root     root            16 Jan  3  1970 vendor_a -> /dev/block/sda31
lrwxrwxrwx    1 root     root            16 Jan  3  1970 vendor_b -> /dev/block/sda32
lrwxrwxrwx    1 root     root            15 Jan  3  1970 xbl_a -> /dev/block/sdb1
lrwxrwxrwx    1 root     root            15 Jan  3  1970 xbl_b -> /dev/block/sdc1

[dlenski]

How would you suggest handling this case? Is there a way to tell which one is currently active, between _a and _b? Also, where is the recovery partition?

[GigabyteProductions]

I'm not sure if this is the intended way to detect it, but it is pretty simple. Fastboot seems to add a kernel cmdline documenting the slot that is booted. I documented that above the ls -l:

$ adb -d shell 'cat /proc/cmdline' | tr '[:space:]' '\n' | grep '^androidboot.slot_suffix='
androidboot.slot_suffix=_b

[nomeata]

@GigabyteProductions Are you using tetherback with your Pixel device? Is it working?

[GigabyteProductions]

@nomeata I have not used tetherback in a long time (disk space issue). Unmodified tetherback actually does not work on my device. With some modifications regarding source block devices, and adb scripting to help setup TWRP, I made it work.

I'll find all of my material if you are interested. However, I will have to do some additional testing to see if TWRP can even restore backups made by tetherback. You may want to consider making a full image of your device (dd in TWRP, for example) if you have the storage to do so, due to complexities with the ext4 FBE implementation (I've had bad luck manually restoring from the tars due to this).

[nomeata]

Thanks. I am currently experimenting with TWRP’s own support for backups over adb: https://twrp.me/faq/openrecoveryscript.html

[GigabyteProductions]

Let me know if you have success with that, because I have not.

[nomeata]

Stuck at https://github.com/TeamWin/Team-Win-Recovery-Project/issues/877#issuecomment-289128732 right now. But I made a backup on the device in TWRP, and copied it to my laptop. First step taken :-)