Bringing FP3 to the Ubports Installer
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.
fredldotme last edited by
@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?
could someone tell me, if that
ubuntu-updater.loglooks 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
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.
But data is mountable. If I do
mount -athen 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 execute
mkfs.ext4 /dev/block/bootdevice/by-name/system_bmanually 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
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.
Today I used installer in order to migrate from /e/ OS to UbPorts and would like to refer (I do not want to flood category with duplicate topics).
I had to migrate back from /e/ OS Android 11, which was easy thanks to link for old FPOS in installer. /e/ OS version Q (1.4) did not work for me and phone got only to boot loop.
I used AppImage installer from device card on ubports.com on Gentoo stable:
- Installer did not notice I do not have android-tools installed and just hanged on "waiting for device"
- Even with stock FPOS the installer (appimage) did not recognize connected phone. I had to reboot it manually to bootloader.
- After manually selecting device there are several channels marked as android9 (
stable, rc and devel). Nothing terrible but it is a bit confusing, because device card on website refers to
- Rest of installation worked as expected. Last step (sending feedback) failed due to some random error after clicking send button.
@luksus I don't think I enabled adb while in developer settings. So this part was probably my mistake