Bringing FP3 to the Ubports Installer

[Luksus]

I created a ubports-installer configuration file for the FP3, which can be tested locally.
However, it is not working yet. It breaks the device slot (A/B), which is currently active and where the installer is doing its magic.
As a result, the phone immediately falls back to the other slot, when booting the broken slot.

I also encountered the same problem, when I tried to switch from the dev to the RC channel within System-Settings. In this case, the updater is downloading a full system image.
So I believe, that the main-issue is not the installer-config but the fact, that a full system image gets installed by the recovery.

So I am not shure how to proceed from here... OTA updates in general work, as long as they are "diff-updates".

Perhaps someone has some suggestions, what is happening here.

[Keneda]

Not any prog skill here, but FP3 in the installer would be great, so hope you'll have help to solve this.

[fredldotme]

@luksus How many tries does the bootloader give you until it falls back to the other slot? I have successfully enabled booting on an A/B device so I'm surprised it's not working.

[flohack]

@fredldotme Did he maybe forget "mark boot as successful" patch?

[Luksus]

@fredldotme
It reboots immediately (lets say half of a second since turning on) and already switched the slot, so that the second boot is working (on the other slot).

@Flohack : Not sure wich patch you are referring to... But yesterday evening I encountered, that my system-updater-script indeed was missing some A/B script lines.

I made a new build, but it was the same behavior as before. But maybe this was caused by a not up to date device tarball...

[flohack]

@luksus See this commit, last files: https://github.com/Flohack74/android_device_google_wahoo/commit/b69b770da153b368a976d5666feff2ed1dca882c

You basically need a job in the Android container that signals the bootloader: Ok this boot was successful.

[fredldotme]

@luksus What do you mean "your" system-image-upgrader, any reason not to use our regular recovery with it's upstream system-image-upgrader?

[Keneda]

@fredldotme
He said "my system-updater-script", not "system-image-upgrader", or i missed something?

[Luksus]

@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

[Luksus]

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]

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