ubports / ubuntu-touch

Ubuntu Touch's issue inbox is now migrated to GitLab.
https://gitlab.com/ubports/ubuntu-touch
1.28k stars 110 forks source link

TB-X605L OTA on devel channel leads to soft brick #2063

Open H-Sachse opened 1 year ago

H-Sachse commented 1 year ago

Steps to reproduce

Install OTA update.

Expected behavior

Device boots normally after install

Actual behavior

Device reboots to "updating", then reboots but is stuck in Lenovo logo Power cycling doesn't help. Only solution seems to be to reinstall with UT installer. The download size of the image seems to be wrong too at only 16.5MB

Logfiles and additional information

Let me know which logs are of interest.

fredldotme commented 1 year ago

The file that was downloaded was a delta, and the update probably caused breakage due to improper use of overlays in device tarballs. In case you used apt: that might also break your system on regular OTA updates because it just isn't possible to maintain OS stability and usability of unconfined, typical apt. For that we use Libertine.

H-Sachse commented 1 year ago

Didn't use apt. I used the UT update tool from settings. Also never had issues with apt on Debian so don't bash apt.

fredldotme commented 1 year ago

I'm not "bashing apt", I'm jotting down obvious deficiencies in mixing an OTA with read-write OS partition.

luksus42 commented 1 year ago

I can confirm the issues that the device does not boot anymore after updating or even rebooting. I still have no solution for that. The X605 seems to be very picky about changes on the systempartition. For example, if you mount the system writeable (to hack something) and forget to mount it readonly before rebooting, in most cases it causes the same issue.

I don't remember, if I already tried to investigate last boot-logs, when this happens. But I think that would be the way to go, to maybe find the root-cause.

H-Sachse commented 1 year ago

The X605 seems to be very picky about changes on the system partition. For example, if you mount the system writable (to hack something) and forget to mount it read-only before rebooting, in most cases it causes the same issue.

This could be due to the reboot not safely un-mounting before the reboot, assuming the system partition is mounted read-only anyway, which is a bad assumption. Next time I'll have this issue (probably tomorrow) I'll try to pull the log.

H-Sachse commented 1 year ago

here's the updater log after a fresh "devel" install via the installer

System Image Upgrader for Ubuntu Touch
Preparing command file
Starting image upgrader
Loading keyring: archive-master.tar.xz
Processing command file
Formatting: system
system partition: /dev/block/bootdevice/by-name/system
umount: /system_root: No such file or directory
mke2fs 1.43.3 (04-Sep-2016)
Discarding device blocks: done                            
Creating filesystem with 786432 4k blocks and 196608 inodes
Filesystem UUID: 3be4daac-e33d-46b9-81c0-eb92a68e886a
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/mmcblk0p24: Invalid argument
umount: /cache/system: Invalid argument
umount: /system_root: No such file or directory
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: 11/196608 files (0.0% non-contiguous), 29884/786432 blocks
Unknown command: 
Keyring doesn't exist: device-signing
Applying update: ubports-c4589c46b5e54055669d562e58bec3d15fefcdc245bdc4bc601c401be281d226.tar.xz
mv: bad 'data/*': No such file or directory
Keyring doesn't exist: device-signing
Applying update: device-ba2e97e14b719912c442272dcdee43062f2450148c1fe084045a3c41350e1737.tar.xz
mv: bad 'data/*': No such file or directory
Keyring doesn't exist: device-signing
Applying update: boot-af76d0859990c76f83eb380ab9fb96bd500444ae062bdc64d290172635ce7df5.tar.xz
mv: bad 'data/*': No such file or directory
Flashing boot at /dev/block/bootdevice/by-name/boot
Invalid sparse file format at header magic
Failed to read sparse file
4+1 records in
4+1 records out
33914880 bytes (32 M) copied, 0.596998 s, 54 M/s
Keyring doesn't exist: device-signing
Applying update: keyring-28992f008be20d562ea06745f563d3abe00b08da1b16e5b92e448e2d4ba21e9f.tar.xz
mv: bad 'data/*': No such file or directory
Keyring doesn't exist: device-signing
Applying update: version-277.tar.xz
mv: bad 'data/*': No such file or directory
Done upgrading...
tune2fs 1.43.3 (04-Sep-2016)
Setting reserved blocks percentage to 5% (308473 blocks)

all the mv: bad 'data/*': No such file or directory make me think something's amiss

H-Sachse commented 1 year ago

I tried several more OTAs and one actually worked without issue. Usually I have to at least run through the first part of the installer (flashing via fastboot) and afterward it will boot normally. sometimes only a full reflash with the installer helps.

What I noticed is that the updater doesn't show any progressbar, but when I go into recovery after a failed update and select graphics test from advanced, I first get an "error" icon and then it claims to do an update, including a progress bar. This also seems to take longer than the "normal" update process. Sometimes this makes the tablet boot OK afterwards, but usually it doesn't. Then only the mentioned partial or full re-flash helps.