Upgrading from 3.0.2.8 to 3.0.3.10 on an Aigo tablet fails about sfos-upgrade

[dalasre]

Hi,

it was indeed the first time for the Aigo, I only used your tool on the XA2 before. Not sure whether I can help, as things might have changed between 3.0.2.8 and 3.0.3.10, which is my current version (I used the version --dup-way). If I need to downgrade to help analyzing: can I set ssu re 3.0.2.8 and use version --dup?

Anyway, on 3.0.3.10 the outputs are:

mount | fgrep sysfs

none on /sys type sysfs (rw,relatime)
none on /opt/alien/sys type sysfs (rw,relatime)

ls -l /sys/class/power_supply

total 0
lrwxrwxrwx 1 root root 0 Jun 9 13:48 dollar_cove_battery -> ../../devices/platform/80860F41:04/i2c-5/5-0034/dollar_cove_battery/power_supply/dollar_cove_battery
lrwxrwxrwx 1 root root 0 Jun 9 13:48 dollar_cove_charger -> ../../devices/platform/80860F41:04/i2c-5/5-0034/dollar_cove_charger/power_supply/dollar_cove_charger

ls -l /sys/class/power_supply/battery

ls: cannot access /sys/class/power_supply/battery: No such file or directory

cat /sys/class/power_supply/battery/uevent

cat: /sys/class/power_supply/battery/uevent: No such file or directory

Not sure if I understand correctly what information you need, but as you can see above there is no

/sys/class/power_supply/battery

but there is a

/sys/class/power_supply/dollar_cove_battery

and there is a

uevent

inside.

cat /sys/class/power_supply/dollar_cove_battery/uevent outputs

POWER_SUPPLY_NAME=dollar_cove_battery
POWER_SUPPLY_STATUS=Charging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_VOLTAGE_NOW=4241000
POWER_SUPPLY_VOLTAGE_OCV=4226000
POWER_SUPPLY_CURRENT_NOW=128000
POWER_SUPPLY_CURRENT_AVG=128000
POWER_SUPPLY_CAPACITY=94
POWER_SUPPLY_TEMP=350
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CHARGE_FULL=4418960
POWER_SUPPLY_CHARGE_NOW=4153968
POWER_SUPPLY_CHARGE_FULL_DESIGN=4450000
POWER_SUPPLY_MODEL_NAME=INTN0001

ls -la gives

total 0
drwxr-xr-x 3 root root 0 Jun 9 13:47 .
drwxr-xr-x 3 root root 0 Jun 9 13:47 ..
-r--r--r-- 1 root root 4096 Jun 9 13:48 capacity
-r--r--r-- 1 root root 4096 Jun 9 23:19 charge_full
-r--r--r-- 1 root root 4096 Jun 9 23:19 charge_full_design
-r--r--r-- 1 root root 4096 Jun 9 13:48 charge_now
-r--r--r-- 1 root root 4096 Jun 9 23:19 current_avg
-r--r--r-- 1 root root 4096 Jun 9 13:48 current_now
lrwxrwxrwx 1 root root 0 Jun 9 23:19 device -> ../../../dollar_cove_battery
-r--r--r-- 1 root root 4096 Jun 9 13:48 health
-r--r--r-- 1 root root 4096 Jun 9 23:19 model_name
drwxr-xr-x 2 root root 0 Jun 9 23:19 power
-r--r--r-- 1 root root 4096 Jun 9 13:48 present
-r--r--r-- 1 root root 4096 Jun 9 13:48 status
lrwxrwxrwx 1 root root 0 Jun 9 13:48 subsystem -> ../../../../../../../../class/power_supply
-r--r--r-- 1 root root 4096 Jun 9 13:48 technology
-r--r--r-- 1 root root 4096 Jun 9 13:48 temp
-r--r--r-- 1 root root 4096 Jun 9 13:48 type
-rw-r--r-- 1 root root 4096 Jun 9 22:37 uevent
-r--r--r-- 1 root root 4096 Jun 9 13:48 voltage_now
-r--r--r-- 1 root root 4096 Jun 9 23:19 voltage_ocv

Does this help?

[Olf0]

a. Do not downgrade! While that may work under specific circumstances, any downgrade which affects more than the last version field ("point release") may result in an unusable SailfishOS installation (and downgrading over a stop release will almost certainly do that).
For details, see: https://together.jolla.com/question/50986/howto-how-to-revert-to-an-earlier-sailfish-os-version/?answer=51003#post-id-51003

b. Thanks, this is all the information I need to employ a proper solution.

[dalasre]

Well, as the information is sufficient, I won't try downgrading ;)

[Olf0]

A draft of a solution has been implemented in PR #27.

[Olf0]

This is resolved in the v3.1 (currently "pre-") release.

Can you please issue these commands on your Aigo tablet:

cd /tmp
curl -LO https://github.com/Olf0/sfos-upgrade/releases/download/3.1-1/sfos-upgrade-3.1-1.noarch.rpm
devel-su
pkcon install-local sfos-upgrade-3.1-1.noarch.rpm
sfos-upgrade "$(version | rev | cut -s -f 2 -d ' ' | rev)"

See, if sfos-upgrade performs the battery checks (even if a check proper fails, this is fine, as long as sfos-upgrade now successfully manages to extract the battery information) and answer with "n", when ultimately asked, if you want to perform the upgrade.
Side note: Actually this would perform a "same-grade", as the command above instructs sfos-upgrade to "upgrade" to the installed version; hence it does do no harm, if you accidentally answer with "y" (but all Patchmanager Patches are unapplied then; still you should not interrupt sfos-upgrade, if that happens).

[Olf0]

@dalasre et al, if you still see issues extracting the battery information with sfos-upgrade 3.1 or later, please post here.
Note that v3.1-3 was published on OpenRepos today, so you can update to it per GUI.

[Olf0]

"Re-fixed" this issue in sfos-upgrade 0.3.5.