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.