Bringing FP3 to the Ubports Installer

fredldotme

@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.

Luksus

@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?

Luksus

Hi again,
could someone tell me, if that ubuntu-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:/ #

flohack

@luksus not sure whats up with data... Are you sure its mounted correctly in recovery?

Luksus

@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 do mount -a then data gets mounted correctly.

flohack

@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

Luksus

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_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 to 7 and slot-unbootable:b to No
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?

flohack

@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

Luksus

@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.

Luksus

@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?

Janez

@luksus I don't think I enabled adb while in developer settings. So this part was probably my mistake