Bringing FP3 to the Ubports Installer
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 last edited by
Not any prog skill here, but FP3 in the installer would be great, so hope you'll have help to solve this.
@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.
@fredldotme Did he maybe forget "mark boot as successful" patch?
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...
@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.
@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 last edited by
He said "my system-updater-script", not "system-image-upgrader", or i missed something?
But somehow I got an outdated version, there were some lines missing.
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?
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.