Day 10: hybris-boot
So, late in Day 9 I tried these hacks:
Commenting out the typedef from
hadk/prebuilts/clang/host/linux-x86/clang-r383902b1/lib64/clang/11.0.2/include/stdint.h // comment out uintptr_t
and then next:
change my host’s /usr/include/stdint.h to also use the __UINTPTR_TYPE__.
The latter change seems to make the build continue, and I will assume nothing is very broken because it ended up using headers from the host, although I may regret this later:)
Build completed after 22 more minutes. If you add to the initial 15 mins since restarting build from outside ubu-chroot it would be under an hour (if make clean actually cleaned everything). That’s way shorter than the entire Lineage build which was ~5 hours.
Let’s see what got build as imgs:
ls hadk/out/target/product/sake/*.img
boot.img dtb.img dtbo.img hybris-boot.img hybris-recovery.img ramdisk.img ramdisk-recovery.img```
Hmm… no vendor_boot here either. Compare that to lineage
boot.img dtbo.img product.img ramdisk.img system_ext.img vbmeta.img vendor_boot.img
dtb.img odm.img qmcs.img ramdisk-recovery.img system.img vbmeta_system.img vendor.img
Missing vendor_boot is not the only difference. System is missing (which is expected for HADK), vbmeta and vendor too and another thing called qmcs. This may mean that the HADK may whitelist only a couple of targets and maybe the vendor_boot can still be built.
But let’s look inside the boot images:
The boot.img is similarily sized as the Lineage one, 96M.
hybris-boot.img however, and hybris-recovery, both have ‘only’ 46M.
The difference is that the hybris- ones pack a minimal filesystem for init, instead of a recovery as on my asus/Lineage boot. What I don’t like in that init script (which is readable, shell) is that I see a define DATA_PARTITION=/dev/block-dm11. Later in that script it is used to mount $DATA_PARTITION /data.
This is a failure of my mount point fixups. I do remember that I didn’t figure out the block-dm partitions, because I assume they are from the super-partition. But /data to be there is a bit surprising. Let’s double-check through adb on the (still running, original ASUS firmware) phone. (Btw, did I mention it uptimed almost 8 days, on cellular, waiting for me to resume my flashing;).
First, inspecting on device mount command, /data/ is /dev/block/dm-10, not 11. Actually there are many mount points with from that dm-10, all type f2fs, and with block device major:253, minor:N (where N=10 for dm-10). Unfortunately, I don’t have access to /proc/devices to see what 253 is, but is probably related to the dynamic partitions we talked about before.
Also, with ls -l /dev/block/platform/*/*/by-name/ from HADK, I do get userdata -> /dev/block/sda23.
Maybe I should flash lineage one more time to get adb root acces - I remember last time I had problems with not being able to boot twrp, which in turn would not allow me to flash the lineage zip…
Let’s take a look at the super.img with the tools from parse-android-dynparts
Building them as per their instruction, then simg2img super.img super-raw.ing and running parse-android-dynparts super-raw.img gives:
dynpart-system_a,,,ro,0 7010296 linear /mnt/datas/sake/debugging/asus/super-raw.img 2048;
dynpart-system_ext_a,,,ro,0 470248 linear /mnt/datas/sake/debugging/asus/super-raw.img 7012352;
dynpart-product_a,,,ro,0 2604744 linear /mnt/datas/sake/debugging/asus/super-raw.img 7483392;
dynpart-vendor_a,,,ro,0 2521232 linear /mnt/datas/sake/debugging/asus/super-raw.img 10088448;
dynpart-odm_a,,,ro,0 2176 linear /mnt/datas/sake/debugging/asus/super-raw.img 12611584
Which clearly means that /data is NOT one of those partitions. It may be that ASUS is using another dynamic partition like inside dm-10, but apart from dm-10 only these appear in mount output through adb (and they correspond to the above 5 partitions).
/dev/block/dm-5 on / type ext4 (ro,seclabel,relatime,discard)
/dev/block/dm-6 on /system_ext type ext4 (ro,seclabel,relatime,discard)
/dev/block/dm-7 on /product type ext4 (ro,seclabel,relatime,discard)
/dev/block/dm-8 on /vendor type ext4 (ro,seclabel,relatime,discard)
/dev/block/dm-9 on /odm type ext4 (ro,seclabel,relatime,discard)
Maybe dm-0 through dm-4 are the same 5 above partitions, but on the other slot.
But clearly dm-10 is nowhere to be seen.
Need to flash Lineage back to get more info.
Let’s restart to bootloader. I cannot adb shell there, no device (only fastboot access).
Then select recovery mode. I cannot adb shell here either, device unauthorised.
Let’s go to fastbootD mode. Nope, no device.
Let’s try to boot twrp. sudo fastboot boot twrp.img results in ‘Unrecognized command boot’. So I need plain bootloader for this.
sudo fastboot boot twrp.img this time works. I don’t know what happened one week before…
In twrp, /data shows as dm-5 
So is /sdcard.
This time, from /proc/devices (I have adb root access here) I can see that major 253 is device-mapper
Unfortunately, I don’t have dmctl to actually see where dm-5 points (this is just a guess, the command existed in ASUS rom but I was not root)
There’s a device /dev/device-mapper that can’t be ‘cat’ to stdout
There is a blockdev command though.
Let’s try to mount sda23 to see how it looks like.
mount -t ext4 /dev/block/sda23 /userdata → Device or resource busy. Same with f2fs
lsof /dev/block/sda23 → nothing. lsof /dev/block/by-name/userdata neither.
There’s got to be a way to find out what’s on that partition.
# xxd -l 512 /dev/block/sda23
gibberish
00000000: fa1e c4f1 d7df 5986 38e4 cb81 6e51 90e7 ......Y.8...nQ..
00000010: abff 69aa 2d01 4b7a 7053 ad91 d362 0afb ..i.-.KzpS...b..
00000020: b4e5 fcd2 6ea9 dd65 9413 caad a4ea fbc3 ....n..e........
00000030: 7417 6b87 98f3 93a4 d2f3 fac6 72b3 693b t.k.........r.i;
00000040: 456c ccf4 d4ec fb5e e462 2a58 b86d d4d7 El.....^.b*X.m..
00000050: c798 fc57 11b9 ff34 0a46 808d 4ead 565a ...W...4.F..N.VZ
00000060: 3d0c f297 3b62 91f3 654c 710a 1ae9 6783 =...;b..eLq...g.
00000070: 13e5 f93d 8518 6398 791a 8694 649d 79ca ...=..c.y...d.y.
00000080: 4c77 bdef 3ef6 a484 ff39 0eaf 0f24 dd9d Lw..>....9...$..
00000090: bd91 0832 f9d9 aaa1 3dfe b5eb cabc 2cb9 ...2....=.....,.
000000a0: bf71 fa57 b901 ef82 dd7d b5c5 cf3e dd24 .q.W.....}...>.$
000000b0: a7fb 9d8d 7b3e 1324 4cf5 fc48 f6ff eabd ....{>.$L..H....
000000c0: f0b9 46f8 d709 d9e2 657c 4df8 8603 5749 ..F.....e|M...WI
000000d0: 7961 8362 a145 81b0 b55d e3cd ca66 e404 ya.b.E...]...f..
000000e0: 3e98 fb34 0fe3 96d0 7996 d9ee 902c 0022 >..4....y....,."
000000f0: d6e4 9433 be16 7b00 967f 0431 d7bd be8e ...3..{....1....
00000100: 5962 f9a5 6225 f781 5d75 85fa cc32 ef9d Yb..b%..]u...2..
00000110: afe2 cbec c2f5 129c 3043 4adf 27a2 4d21 ........0CJ.'.M!
00000120: bef0 c841 4d7d bea7 dcff fced 4f4a 4a2a ...AM}......OJJ*
00000130: 35e3 a89f ac9c a39e 1fb8 adb9 0fab 4f1e 5.............O.
00000140: 626b 9fab 84a0 9f4f f5ac e492 36e5 1494 bk.....O....6...
00000150: 84cb 66a4 c0f2 8808 6186 983c db98 df7e ..f.....a..<...~
00000160: 0c5f c638 74a4 8079 3d2d 9d52 98bd 92bd ._.8t..y=-.R....
00000170: bef4 0b96 dfa3 1d89 c4d1 d184 971a a5e2 ................
00000180: 7acb ca90 4cd5 4de9 c386 b21d e9b5 6b2f z...L.M.......k/
00000190: 6c78 052c 6cc1 1b0c ea4c eab0 3c57 72dd lx.,l....L..v.....|u..KZ.
000001f0: 3c48 ff14 5b03 a98b 75a8 2f14 b2a2 d197 <H..[...u./.....
Meh. Let’s flash Lineage though, since we got twrp.
Using twrp to wipe data → run mount again.
/dev/block/sda23 on /data type f2fs
Ta-da. This should go into our fixup mountpoints.
Being more confident that sda23 is the right partition, I am re-doing my fixups with the whole info from ls -l /dev/block/platform/*/*/by-name/ and starting a new hybris-hal boot img build.
I log into adb root onto Lineage in the meantime.
/data is again mounted on dm-5
dmctl is now available and am now root:
# dmctl list devices
Available Device Mapper Devices:
system_ext_b : 253:3
userdata : 253:5
odm_b : 253:0
system_b : 253:2
vendor_b : 253:4
product_b : 253:1
As you can see, 5 is userdata. However I don’t get how the mapping is done to sda23:
# dmctl info userdata
device : userdata
active : true
access : rw
activeTable : true
inactiveTable : false
bufferFull : false
# dmctl getpath userdata
/dev/block/dm-5
# dmctl table userdata
Targets in the device-mapper table for userdata:
0-476106392: default-key, aes-xts-plain64 - 0 259:7 0 4 allow_discards sector_size:4096 iv_large_sectors wrappedkey_v0
# dmctl status userdata
Targets in the device-mapper table for userdata:
0-476106392: default-key
Anyways, hybris-boot now correctly uses sda23, after another 23mins build:)
Let’s flash just this on the boot partition and see if we get telnet.
If somehow we don’t I’m going to flash ASUS’s vendor_boot because it has a GZipped ramdisk too, unlike Lineage’s…
sudo fastboot flash boot hadk/hybris-boot.img in fastbootd mode. Reboot. Stuck at ASUS logo.
Vol-Dn and power, Enter bootloader, recovery mode - Stuck at ASUS logo. :facepalm: of course, recovery was on boot ramdisk before!
Let’s flash vendor_boot from ASUS in bootloader mode.
sudo fastboot flash vendor_boot asus/vendor_boot.img
Hmm… no telnet either. Let’s get back to Lineage.
sudo fastboot flash boot lineage/boot.img
sudo fastboot flash vendor_boot lineage/vendor_boot.img
Ok, It boots/works.
So, what now? We don’t have the vendor_boot generated by the HADK way either (I could look up the hybris patches / hybris-hal target to see why).
Or I could try again with wiping the userdata partition from lineage recovery.
Or I should just use the next day to ask on #sailfishos-porters for help with telnet.
. Maybe it’s something I can strace in the original ROM later, not a dead end. 
.
