search

Halium / projectmanagement

143 stars 32 forks source link

[device-port] [marmite] Wileyfox Swift 2 #178

Open ivdok opened 4 years ago

ivdok commented 4 years ago

Tree: halium-7.1

Progress as of 16:24 13/01/20 GMT+3: https://t.me/halium/112510 https://t.me/halium/112511

ivdok commented 4 years ago

Currently, the progress is stalled by /vendor tree conflict. When I omit line 5 of pull/#195 at halium-devices, mka bootimage && mka hybris-boot succeeds, but systemimage fails because of lacking /system/bin/wcnss_service, and I've got a feeling there'll be more of these even if I drop one directly from vendor tree, bypassing CVS. When I add them by uncommenting said line 5, I get tree conflict described above. What else do I do, and where can I get a pointer what to look for? My post at Telegram/halium was completely ignored, and I don't know where else to ask, apart from UBports forum, but I've got a feeling I'll be booted once again, so I want to know at least where I can actually ask for support.

Considered merging missing blobs directly into tree and call it a day, but that's not possible for legal reasons.

jbruechert commented 4 years ago

Maybe running git diff in the vendor tree can help, since the halium-devices script tries to do some automatic modifications that make porting easier in most cases (Removing all apks and jars that are not used by halium). If the list of vendor blobs in the device tree (proprietary-files.txt) doesn't match the contents of the vendor tree, things will fail. Sometimes the diff allows to detect those cases.

ivdok commented 4 years ago

Maybe running git diff in the vendor tree can help, since the halium-devices script tries to do some automatic modifications that make porting easier in most cases (Removing all apks and jars that are not used by halium). If the list of vendor blobs in the device tree (proprietary-files.txt) doesn't match the contents of the vendor tree, things will fail. Sometimes the diff allows to detect those cases.

By bad, turns out I've mistyped device instead of vendor. mka mkbootimg and hybris-boot succeeds, and systemimage fails for a different reason. aidl_language_l.cpp:1435:47: error: comparison of integers of different signs: 'int' and 'yy_size_t' (aka 'unsigned long') [-Werror,-Wsign-compare] If that's important, I'm building inside Ubuntu 16.04 LXC container for Proxmox VE 6.1.

ivdok commented 4 years ago

Exporting LC_ALL=C and USE_HOST_LEX=yes doesn't produce any noticeable improvements. Rebuilding just repeats this error. Found this and that mention at Telegram/halium, but it doesn't seem like any (public?) solution has been reached.

ivdok commented 4 years ago

Also, this:

arch/arm64/configs/lineageos_marmite_defconfig:54:warning: symbol value '!' invalid for AUDIT
arch/arm64/configs/lineageos_marmite_defconfig:987:warning: symbol value '!' invalid for BT_HCIUART_H4
arch/arm64/configs/lineageos_marmite_defconfig:1045:warning: symbol value '!' invalid for FW_LOADER_USER_HELPER
arch/arm64/configs/lineageos_marmite_defconfig:3955:warning: symbol value '!' invalid for BTRFS_FS
arch/arm64/configs/lineageos_marmite_defconfig:4032:warning: symbol value '!' invalid for F2FS_FS
arch/arm64/configs/lineageos_marmite_defconfig:4035:warning: symbol value '!' invalid for NFS_FS
arch/arm64/configs/lineageos_marmite_defconfig:4518:warning: symbol value '!' invalid for NFS_ACL_SUPPORT
arch/arm64/configs/lineageos_marmite_defconfig:4519:warning: symbol value '!' invalid for NFS_V4
arch/arm64/configs/lineageos_marmite_defconfig:4520:warning: symbol value '!' invalid for NFS_V4_1
arch/arm64/configs/lineageos_marmite_defconfig:4521:warning: symbol value '!' invalid for NFS_USE_KERNEL_DNS
arch/arm64/configs/lineageos_marmite_defconfig:4522:warning: symbol value '!' invalid for NFS_V3
arch/arm64/configs/lineageos_marmite_defconfig:4523:warning: symbol value '!' invalid for NFS_V3_ACL
arch/arm64/configs/lineageos_marmite_defconfig:4524:warning: symbol value '!' invalid for NFS_COMMON
arch/arm64/configs/lineageos_marmite_defconfig:4525:warning: symbol value '!' invalid for SUNRPC
arch/arm64/configs/lineageos_marmite_defconfig:4526:warning: symbol value '!' invalid for SUNRPC_GSS
arch/arm64/configs/lineageos_marmite_defconfig:4534:warning: symbol value '<4.3' invalid for SECURITY_YAMA_STACKED
arch/arm64/configs/lineageos_marmite_defconfig:4535:warning: symbol value '!' invalid for LOCKD
arch/arm64/configs/lineageos_marmite_defconfig:4536:warning: symbol value '!' invalid for LOCKD_V4

But mer_verify_kernel_config didn't panic at my Kconfig. I know that it's not supposed to know everything about my kernel fork, but will these warnings result in a working boot image? IIRC, '!' is used to tell make to build these as separate modules, and I thought about dropping them from my release (why the hell would any phone need NFS kernel-side server? Also, F2FS was crashing build process, so I thought about putting it off for later)

ivdok commented 4 years ago

Upgrading container OS to bionic did not affect the error. However, replacing all exclamation signs in defconfig did the trick. Here's the issue log for future reference.

ivdok commented 4 years ago

Boot successfully flashed, but halium-install breaks on system partition creation:

[ivdok@LENOVO-20255 marmite-halium]$ halium-install/halium-install -p ut ubports-touch.rootfs-xenial-armhf.tar.gz system.img 
[sudo] password for ivdok: 
Debug: Chosen rootfs is ubports-touch.rootfs-xenial-armhf.tar.gz
Debug: Chosen android image is system.img
Debug: Chosen release is ut

I: Writing rootfs into mountable image
I: Writing android image into mountable image
I: Running post installation tasks
enabling Mir ... [done]
enabling SSH ... [done]
Please enter a new password for the user 'phablet':
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
I: Shrinking images
e2fsck 1.45.5 (07-Jan-2020)
resize2fs 1.45.5 (07-Jan-2020)
Resizing the filesystem on .halium-install-imgs.zaxHi/system.img to 122665 (4k) blocks.
Begin pass 2 (max = 32220)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 28)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on .halium-install-imgs.zaxHi/system.img is now 122665 (4k) blocks long.

I: Unmounting images
I: Pushing rootfs and android image to /data via ADB
adb: error: failed to copy '.halium-install-imgs.zaxHi/rootfs.img' to '/data/rootfs.img': remote write failed: No space left on device
.halium-install-imgs.zaxHi/rootfs.img: 0 files pushed. 20.4 MB/s (40627360 bytes in 1.903s)
adb: error: failed to copy '.halium-install-imgs.zaxHi/system.img' to '/data/system.img': remote write failed: No space left on device
.halium-install-imgs.zaxHi/system.img: 0 files pushed. 13.1 MB/s (40692888 bytes in 2.969s)
Error: Couldn't copy the files to the device, is it connected?
I: Cleaning up
umount: .halium-install-rootfs.Vvhar: not mounted.

Guess that's due to system.img only taking 465,5 MiB instead of 3Gb+ on actual device? Even after running repartitioning script for Project Treble support for my device (currently running highly volatile Android 9), which increased /vendor at the cost of /system, I still have 3.4G left. And even then, it only applies to Oreo and newer, lineage 14.1 tree has no idea about /system shrink, and system.img this low shouldn't even exist.

jbruechert commented 4 years ago

Halium is installed to /data for debugging. Can you check you actually have enough space there? If you used encryption previously, you will also have to reformat /data as ext4 preferably using TWRP.

ivdok commented 4 years ago

Halium is installed to /data for debugging. Can you check you actually have enough space there? If you used encryption previously, you will also have to reformat /data as ext4 preferably using TWRP.

Sorry, my mistake, I thought it was assembling image locally. Now it completed normally(-ish?):

I: Shrinking images
e2fsck 1.45.5 (07-Jan-2020)
resize2fs 1.45.5 (07-Jan-2020)
Resizing the filesystem on .halium-install-imgs.sp4Y2/system.img to 122665 (4k) blocks.
Begin pass 2 (max = 32220)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 28)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on .halium-install-imgs.sp4Y2/system.img is now 122665 (4k) blocks long.

I: Unmounting images
I: Pushing rootfs and android image to /data via ADB
.halium-install-imgs.sp4Y2/rootfs.img: 1 file pushed. 22.4 MB/s (3221225472 bytes in 136.952s)
.halium-install-imgs.sp4Y2/system.img: 1 file pushed. 22.1 MB/s (502435840 bytes in 21.650s)
I: Cleaning up
umount: .halium-install-rootfs.hOwE7: not mounted.

But RNDIS interface doesn't appear in NetworkManager. Instead, I see QDL/EDL device, which usually indicates soft brick. Did I forget to flash something apart from boot/system? Will try to wipe device from TWRP beforehand.

ivdok commented 4 years ago

halium-boot. Of course. How stupid of me.

jbruechert commented 4 years ago

Sorry, my mistake, I thought it was assembling image locally. Now it completed normally(-ish?):

For debugging, halium places an ext4 image on /data, so you can easily back it up, swap it out easily etc. The partition on which the image is located still needs to be mountable by the initramfs (hybris / halium-boot)

ivdok commented 4 years ago

It's something, at last. Kernel boots, but I don't think sshd is listening to 10.15.19.82 @ port 22.

[ivdok@LENOVO-20255 marmite-halium]$ ip a
[DATA EXPUNGED]
7: enp0s16f0u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether da:5b:44:11:7c:0d brd ff:ff:ff:ff:ff:ff
    inet 10.15.19.100/24 brd 10.15.19.255 scope global noprefixroute enp0s16f0u1
       valid_lft forever preferred_lft forever
[ivdok@LENOVO-20255 marmite-halium]$ ip r
default via 10.0.0.1 dev wlp3s0 proto dhcp metric 600 
default via 10.15.19.1 dev enp0s16f0u1 proto static metric 20100 
10.15.19.0/24 dev enp0s16f0u1 proto kernel scope link src 10.15.19.100 metric 100 
[ivdok@LENOVO-20255 marmite-halium]$ ping 10.15.19.82
PING 10.15.19.82 (10.15.19.82) 56(84) bytes of data.
From 10.15.19.100 icmp_seq=1 Destination Host Unreachable
From 10.15.19.100 icmp_seq=2 Destination Host Unreachable
From 10.15.19.100 icmp_seq=3 Destination Host Unreachable
^C
--- 10.15.19.82 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3049ms
pipe 4
[ivdok@LENOVO-20255 marmite-halium]$ ssh phablet@10.15.19.82
ssh: connect to host 10.15.19.82 port 22: No route to host
[ivdok@LENOVO-20255 marmite-halium]$ traceroute 10.15.19.82
traceroute to 10.15.19.82 (10.15.19.82), 30 hops max, 60 byte packets
 1  LENOVO-20255 (10.15.19.100)  3043.714 ms !H  3043.621 ms !H  3043.601 ms !H

When using DHCP, I get 192.168.2.90/24 ipaddr, and after nmap -sS -p 22 192.168.2.0/24, I get report that it's listening in 192.168.2.15:22, but ssh phablet@192.168.2.15 is refused. -vvvv is useless at this point, it's the daemon that rejects connections.

ivdok commented 4 years ago

Hmm, this gets interesting... Telnet is listening on 192.168.2.15, but it looks like it's just bare ramdisk w/busybox. And judging by empty /etc/fstab I screwed up yet again.

jbruechert commented 4 years ago

Did you already check diagnosis.log (for hybris-boot) / dmesg (for halium-boot)?

ivdok commented 4 years ago

At first boot dmesg wasn't present on $PATH, which confused me. On second try, I've got this log, but it's FUBAR.

ivdok commented 4 years ago

> # CONFIG_QUOTA is not set >[ 6.218108] EXT4-fs (mmcblk0p34): Filesystem with quota feature cannot be mounted RDWR without CONFIG_QUOTA

Time to rebuild the kernel yet again.

jbruechert commented 4 years ago

This is your log filtered through | grep initrd. It should be clearer to understand now.

[    2.564503] Freeing initrd memory: 4008K (ffffffc003600000 - ffffffc0039ea000)
[    6.143967] initrd: checking filesystem integrity for the userdata partition
[    6.177757] initrd: checking filesystem for userdata took (including e2fsck) 0 seconds
[    6.189758] initrd: mounting /dev/mmcblk0p34
[    6.224939] initrd: boot mode: halium
[    6.225203] initrd: Halium rootfs is  
[    6.225926] initrd: mounting system rootfs at /halium-system
[    6.227273] initrd: WARNING: Android system image not found.
[    6.227452] initrd: mounting   (user mode)
[    6.229128] initrd: mounting android system image (/tmpmnt/android-rootfs.img) ro, in /android-unknown (unknown mode)
[    6.229338] initrd: mounting android system image from system rootfs
[    6.233067] initrd: WARNING: Failed to mount Android system.img.
[    6.233867] initrd: Normal boot
[    6.246131] initrd: WARNING: Didn't find a device name. Is the Android system image mounted correctly?
[    6.246323] initrd: device is unknown
[    6.246494] initrd: This rootfs does not have any writable-paths defined
[    6.246753] initrd: checking fstab /root/var/lib/lxc/android/rootfs/fstab* for additional mount points
[    6.253135] initrd: moving Android system to /android/system
[    6.837761] ########################## usb_info: Halium initrd Debug telnet on port 23 on rndis0 192.168.2.15 - also running udhcpd
ivdok commented 4 years ago

It should be clearer to understand now.

Actually... I don't get it. fstab.qcom is present in halium/device/wileyfox/marmite/rootdir/root, so by all means it should be populated. If I knew how to mount/extract boot-halium or system.img, I'd at least patch fstab if it's not present, but simg2img refuses to recognize them, and binwalk recognizes LZMA dicts and android bootimg format, but it's too much effort for no gain to actually split it and merge back. So, what else is needed to populate fstab for halium-boot and systemimage?

ivdok commented 4 years ago 
[    6.088861] EXT4-fs (mmcblk0p34): warning: maximal mount count reached, running e2fsck is recommended
[    6.097901] EXT4-fs warning (device mmcblk0p34): ext4_enable_quotas:5282: Failed to enable quota tracking (type=0, err=-3). Please run e2fsck to fix.
[    6.098313] EXT4-fs (mmcblk0p34): mount failed

Strange, looks like /data is recognized as corrupted by new kernel (but not by recovery), and e2fsck in my recovery is too old. Pulled static binary from Ubuntu's repo, ran with -vf options, no errors. Booting back - same issue. What if I just disable this feature entirely? Found prior reports of this bug, but they quickly fade in chat logs without any solution found.

Gotta return to it tomorrow, if ever, shit's infuriating.

ivdok commented 4 years ago

At least now it mounts, but stuck in the inject loop.

ivdok commented 4 years ago

And no, there's pleny o' space on device:

/ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p34        9471476   3673152   5781940  39% /root/userdata
/dev/loop0             3030800   1551032   1306100  54% /root
/dev/loop1              425068    418736         0 100% /root/android/system
tmpfs                   942520      4080    938440   0% /root/var/lib/lxc/android/rootfs
none                         4         0         4   0% /root/android
/dev/mmcblk0p34        9471476   3673152   5781940  39% /root/android/data
tmpfs                   188508       264    188244   0% /root/run
tmpfs                   942520         4    942516   0% /root/etc/fstab
/dev/disk/by-partlabel/cache                        253920      9088    239592   4% /root/android/cache
/dev/disk/by-partlabel/persist                         28144       332     27160   1% /root/android/persist
/dev/mmcblk0p34        9471476   3673152   5781940  39% /root/var/lib/ureadahead
ivdok commented 4 years ago

[ 7.343705] No init found. Try passing init= bootarg. I guess that's my progress-blocker for now.

ivdok commented 4 years ago

Got this bit that needs attention:

[    7.236828] initrd: mounting /dev/disk/by-partlabel/config as /root/android//frp
[    7.240353] mount: mounting /dev/disk/by-partlabel/config on /root/android//frp failed: No such device
[    7.246764] initrd: checking mount label boot
[    7.247628] initrd: mounting /dev/disk/by-partlabel/boot as /root/android//boot
[    7.251222] mount: mounting /dev/disk/by-partlabel/boot on /root/android//boot failed: No such device
[    7.257500] initrd: checking mount label recovery
[    7.258384] initrd: mounting /dev/disk/by-partlabel/recovery as /root/android//recovery
[    7.261968] mount: mounting /dev/disk/by-partlabel/recovery on /root/android//recovery failed: No such device
[    7.268202] initrd: checking mount label misc
[    7.269056] initrd: mounting /dev/disk/by-partlabel/misc as /root/android//misc
[    7.272772] mount: mounting /dev/disk/by-partlabel/misc on /root/android//misc failed: No such device
[    7.279090] initrd: checking mount label zram0
[    7.280442] initrd: mounting /dev/zram0 as /root/android/none
[    7.284009] mount: mounting /dev/zram0 on /root/android/none failed: No such device

That's strange. fdisk doesn't recognize them as valid:

/ # fdisk -l /dev/disk/by-partlabel/config

Disk /dev/disk/by-partlabel/config: 0 MB, 32768 bytes
4 heads, 16 sectors/track, 1 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Disk /dev/disk/by-partlabel/config doesn't contain a valid partition table
/ # fdisk -l /dev/disk/by-partlabel/boot

Disk /dev/disk/by-partlabel/boot: 67 MB, 67108864 bytes
4 heads, 16 sectors/track, 2048 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Disk /dev/disk/by-partlabel/boot doesn't contain a valid partition table
/ # fdisk -l /dev/disk/by-partlabel/recovery

Disk /dev/disk/by-partlabel/recovery: 67 MB, 67108864 bytes
4 heads, 16 sectors/track, 2048 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Disk /dev/disk/by-partlabel/recovery doesn't contain a valid partition table
/ # fdisk -l /dev/disk/by-partlabel/misc 

Disk /dev/disk/by-partlabel/misc: 1 MB, 1048576 bytes
4 heads, 16 sectors/track, 32 cylinders
Units = cylinders of 64 * 512 = 32768 bytes

Disk /dev/disk/by-partlabel/misc doesn't contain a valid partition table

Obviosly it can't and shouldn't mount misc and config, these are private vendor partitions with no distinguishable FS, but recovery and boot are 100% legit, TWRP and halium-boot respectively.

ivdok commented 4 years ago

Sorry, I can't do this. Keeping track all across disjointed chat logs while also strictly asking specific things only in specific chats, keeping open 3 different halium-related wikis and dozens even remotely related pastebin snippets and google queries just in case something will work is too stressful for a weekend project.

doniks commented 4 years ago

Sorry to hear @ivdok Since there is a manifest, it builds and it boots, I'll reopen the porting issue. Even if you are frustrated by the outcome, it can still be helpful if someone else with the device comes around and wants to push this further. Thanks for the effort!

ivdok commented 4 years ago

Sorry to hear @ivdok Since there is a manifest, it builds and it boots, I'll reopen the porting issue. Even if you are frustrated by the outcome, it can still be helpful if someone else with the device comes around and wants to push this further. Thanks for the effort!

It doesn't boot, only useless cryptic debug initramfs.

doniks commented 4 years ago

Ah, ok. Then maybe missread, I thought you had telnet and even 10.15.19.100. Well, either way, even if we're just documenting what didn't work, this can be helpful for other porters. So, let's keep it open