Bringing FP3 to the Ubports Installer
-
@fredldotme
He said "my system-updater-script", not "system-image-upgrader", or i missed something? -
@keneda @fredldotme : sorry for the confusion.
I was indeed talking of the "system-image-upgrader" script.But somehow I got an outdated version, there were some lines missing.
See: https://gitlab.com/ubports/community-ports/android9/fairphone-3/fairphone-fp3/-/commit/d0ff22967525dc3f434d156dcc315e88eac9a810#8127353120ea022e70e597a4db201595406c862e -
So I just switched from dev to rc channel (in system settigs) and let the phone reboot and install, but it is still the same issue, also with the fix of system-image-upgrader.
-
@luksus possibly need to set the bootctl flag from within the recovery too? It would need a few components not shipped by default in the recovery though.
-
@fredldotme what I don't understand, what is different here from a diff-update (OTA) which is working.
And also the strange fact, that flashing the stock system-image and after it my ubports system image fixes the issue. I mean both images are overriding the system partition, but only flashig the ubports system image again isnot enough.What is so special about the stock image?
-
Hi again,
could someone tell me, if thatubuntu-updater.log
looks as expected?root@FP3:/ # cat /cache/ubuntu_updater.log Loading keyring: archive-master.tar.xz A/B slot system detected! Slot suffix is _b Formating: system system partition: /dev/block/bootdevice/by-name/system_b umount: /system_root: Invalid argument mke2fs 1.43.3 (04-Sep-2016) Discarding device blocks: done Creating filesystem with 786432 4k blocks and 196608 inodes Filesystem UUID: c69adf87-fcbb-4cfd-9694-e76bed943e8d Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912 Allocating group tables: done Writing inode tables: done Creating journal (16384 blocks): done Writing superblocks and filesystem accounting information: done Loading keyring: image-master.tar.xz Loading keyring: image-signing.tar.xz umount: /dev/block/mmcblk0p31: Invalid argument umount: /cache/system: Invalid argument umount: /system_root: Invalid argument e2fsck 1.43.3 (04-Sep-2016) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/block/bootdevice/by-name/system_b: 11/196608 files (0.0% non-contiguous), 29884/786432 blocks Applying update: ubports-345e286684f401e201b71f66e70d2745ac0e54e131a4e9e575d8490fea83e687.tar.xz mv: bad 'data/*': No such file or directory Applying update: device-577af01d6b138075ac0a105109e228004712d5a7f9daaae3322a1feb61213036.tar.xz mv: bad 'data/*': No such file or directory Applying update: boot-c11b3194655f04c18c04bbe40983921c29ede3e72766ebf611c781d352229fef.tar.xz mv: bad 'data/*': No such file or directory Flashing boot at /dev/block/bootdevice/by-name/boot_b Applying update: keyring-4c4e7ef380ebcfa2c31084efa199138e93bfed8fc58aa3eb06bdf75a78af9b57.tar.xz mv: bad 'data/*': No such file or directory Applying update: version-162.tar.xz mv: bad 'data/*': No such file or directory root@FP3:/ #
-
@luksus not sure whats up with data... Are you sure its mounted correctly in recovery?
-
@flohack userdata does not seem to be mounted correctly as it does not show any content, when I do
ls data
.But I am not sure, if that is really the issue, because I got the same lines with an incremental update, which is working fine.
The only difference, as far as I can see, is the previously formatting of the system partition on a full update.
And perhaps that is leading again to the bootctl flag, which you already mentioned and which must be set.Edit:
But data is mountable. If I domount -a
then data gets mounted correctly. -
@luksus Ok I think the upgrader mounts data partition to be sure, but we would need to check still why this error appears, it feels wrong
-
So it turns out, that the issue is caused by the formatting of the system partition.
If I executemkfs.ext4 /dev/block/bootdevice/by-name/system_b
manually from within recovery, the next boot fails.Which sets this values (slot b):
(bootloader) slot-count:2 (bootloader) slot-retry-count:b:0 (bootloader) slot-success:b:No (bootloader) slot-active:b:No (bootloader) slot-unbootable:b:Yes (bootloader) slot-retry-count:a:6 (bootloader) slot-success:a:No (bootloader) slot-active:a:Yes (bootloader) slot-unbootable:a:No
It is not needed to have a slot-success, to get a successful boot, for example I could boot slot a successfully afterwards, though it had no slot-success previously.
Setting slot b active again, resets the
slot-retry-count:b
to7
andslot-unbootable:b
toNo
Therefor I don't think, that marking the slot as boot-successful will make a difference.So perhaps formatting with mkfs.ext4 breaks some kind of partition table or something similar?
-
@luksus You need to enter a job into Ubuntu Touch to mark the boot as successful, did you do that?
Otherwise every 2 or 3 boots the slot will change -
@flohack not actively, but slot a (where I always keep a working ubports) for example gets a slot-success after I booted UT on it. So somehow it seems to be set.
I am using the device daily for some month now and did not have unwanted slot-switches. -
@janez said in Bringing FP3 to the Ubports Installer:
Even with stock FPOS the installer (appimage) did not recognize connected phone. I had to reboot it manually to bootloader.
Did you activate adb debugging in developer settings before?
-
@luksus I don't think I enabled adb while in developer settings. So this part was probably my mistake
-