2.1.1/Jämsänjoki EA - Page 16 - maemo.org

Schturman | # 151 | 2017-10-04, 13:33 | Report

Originally Posted by n950 View Post

Hi,

Here is my problem when i try to install the new update on my Jolla C.

How to resolve that?

EDIT: SMS BOMB in settings app need to be uninstalled before install new update.
Now it works

Hmmm, don't know why you decided that related to Bomb sms, I updated both my Jolla (1/C) with this app installed... For me it also not worked from first time, but from attempt 2 or 3 update installed without any problem...

The Following 4 Users Say Thank You to Schturman For This Useful Post:
Amboss, Feathers McGraw, hardy_magnus, juiceme

DrYak | # 152 | 2017-10-04, 15:25 | Report

Originally Posted by Mikkosssss View Post

So my Jolla 1 went to bootloop after trying to update.
How can I try again in recovery mode?
{...}
If anyone got any ideas how to fix my Jolla I will try. If not I have do bit backups and do factory reset.

For the recovery mode, the procedure would be something along the lines of :
- mount the root (subvolume "@") on /mnt/
- mount the home (subvolume "@home") on /mnt/home/
- bind-mount the few software defined directory (like /proc /sys /dev) into /mnt/home
- mount the few other blocks

chroot into /mnt/
and try restarting the update and/or checking with zypper/pkgcon if there aren't other problems (packages conflicts).

For reference, mounts currently effective on my 2.1.1-running Jolla 1 :

Code:

/dev/mmcblk0p28 on / type btrfs (rw,noatime,ssd,noacl,space_cache,autodefrag)
devtmpfs on /dev type devtmpfs (rw,relatime,size=412956k,nr_inodes=103239,mode=755)
none on /proc type proc (rw,relatime)
none on /sys type sysfs (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_prio,net_cls)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/debug type cgroup (rw,nosuid,nodev,noexec,relatime,debug)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /tmp type tmpfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
mtp on /dev/mtp type functionfs (rw,relatime)
/dev/mmcblk0p9 on /var/systemlog type ext4 (rw,nosuid,nodev,relatime,data=ordered)
/dev/mmcblk0p28 on /home type btrfs (rw,noatime,ssd,noacl,space_cache,autodefrag)
/dev/mmcblk0p25 on /persist type ext4 (ro,nosuid,nodev,relatime,data=ordered)
/dev/mmcblk0p18 on /firmware type vfat (ro,relatime,uid=1000,gid=1000,fmask=0337,dmask=0227,codepage=cp437,iocharset=iso8859-1,shortname=lower,errors=remount-ro)
/dev/mmcblk0p19 on /drm type ext4 (rw,nosuid,nodev,relatime,data=ordered)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
statefs on /run/state type fuse.statefs (rw,nosuid,nodev,relatime,user_id=0,group_id=998,default_permissions,allow_other)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /run/user/100000 type tmpfs (rw,nosuid,nodev,relatime,size=82872k,mode=700,uid=100000,gid=100000)
/dev/mmcblk0p28 on /opt/alien/usr type btrfs (rw,noatime,ssd,noacl,space_cache,autodefrag)
statefs on /run/user/100000/state type fuse.statefs (rw,nosuid,nodev,relatime,user_id=100000,group_id=100000,default_permissions,allow_other)

Otherwise, yeah, if that doesn't work, I suspect you'll be needing to backup / factory reset / upgrade / restore

The Following 3 Users Say Thank You to DrYak For This Useful Post:
Amboss, juiceme, lal

olf | # 153 | 2017-10-04, 15:56 | Report

Originally Posted by jukk View Post

2.1.1 was never officially released. If you have early access or if you update from command line, you can update to 2.1.1 (unless it was completely withdrawn?) and now also to 2.1.2.3. My tablet is on 2.1.1 because I updated from command line (it is nagging about updating(!) to 2.1.0, though).

Just to debunk some myths:

SFOS 2.1.1.26 was available as an official OS update for a few days. I am not an Early Access subscriber and received it this way on my two sbj1.
And it is not "completely pulled", as that would cause havoc for those having SFOS 2.1.1 installed, when installing additional packages from Jolla's repos.
So it sounds to me that something went slightly wrong with your CLI update to 2.1.1 (device "is nagging about updating(!) to 2.1.0").

WRT Jolla's advice to uninstall Call Recorder before any SFOS upgrade:
IMO it does not have to be uninstalled (as it is not replacing SFOS RPMs), but one has to ensure that its service is not running when upgrading, otherwise your device will likely be screwed. So this is a dangerous route (forgetting to will probably lead you to a Factory Reset), thus it is well understandable that Jolla simply advises to uninstall it before upgrading.

Last edited by olf; 2017-10-04 at 17:54.

The Following 5 Users Say Thank You to olf For This Useful Post:
Amboss, Feathers McGraw, juiceme, lal, Watchmaker

Mikkosssss | # 154 | 2017-10-04, 17:50 | Report

Originally Posted by DrYak View Post

For the recovery mode, the procedure would be something along the lines of :
- mount the root (subvolume "@") on /mnt/
- mount the home (subvolume "@home") on /mnt/home/
- bind-mount the few software defined directory (like /proc /sys /dev) into /mnt/home
- mount the few other blocks

chroot into /mnt/
and try restarting the update and/or checking with zypper/pkgcon if there aren't other problems (packages conflicts).

I got to that if you look at my another message but I think I failed at setting up internet.
Ping didint work but zypper seems to have some data about package versions? And it shows that many packages wont match the system version if I understand correctly.
If anyone wants to help me I can come to #jollamobile IRC.

The Following 2 Users Say Thank You to Mikkosssss For This Useful Post:
Amboss, juiceme

Mikkosssss | # 155 | 2017-10-04, 18:46 | Report

Originally Posted by olf View Post

IMO it does not have to be uninstalled (as it is not replacing SFOS RPMs), but one has to ensure that its service is not running when upgrading, otherwise your device will likely be screwed. So this is a dangerous route (forgetting to will probably lead you to a Factory Reset), thus it is well understandable that Jolla simply advises to uninstall it before upgrading.

From my systemupdate.log

Code:

....
Oct 03 19:15:55 Sailfish systemd[905]: Stopping User session.
Oct 03 19:15:55 Sailfish systemd[905]: Stopped target User session.
Oct 03 19:15:55 Sailfish systemd[905]: Stopping Call Recorder Daemon...
Oct 03 19:15:55 Sailfish systemd[905]: Stopping Telepathy mission control daemon...
Oct 03 19:15:55 Sailfish systemd[905]: Stopping PulseAudio...
Oct 03 19:15:55 Sailfish systemd[905]: Stopping Non-Graphic Feedback Daemon...
Oct 03 19:15:55 Sailfish systemd[905]: Stopping Ambience daemon...
Oct 03 19:15:55 Sailfish systemd[905]: Stopping Voicecall manager...
Oct 03 19:15:55 Sailfish systemd[905]: Stopping Generic application launch booster...
Oct 03 19:15:55 Sailfish systemd[905]: Stopping Application launch booster for Sailfish Browser...
....

The Following 3 Users Say Thank You to Mikkosssss For This Useful Post:
Amboss, juiceme, olf

MikeHG | # 156 | 2017-10-04, 19:19 | Report

Anecdata: I had call recorder installed (and presumably running) when I did one of the recent updates (maybe 2.1.1 early access?) on a Jolla 1 because I didn't check the release notes, and they'd only recently added it.

No apparent ill effects. Not taking any chances though, and removed it for 2.1.2.

The Following 2 Users Say Thank You to MikeHG For This Useful Post:
Amboss, juiceme

olf | # 157 | 2017-10-04, 20:35 | Report

Originally Posted by Mikkosssss View Post

From my systemupdate.log

Code:

....
Oct 03 19:15:55 Sailfish systemd[905]: Stopping Call Recorder Daemon...
....

Thanks @Mikkosssss for pointing this out. But now I understand even less, what the issue with Call Recorder while upgrading SFOS is.
NB: I also had it still installed while upgrading to 2.1.0.11 and 2.1.1.26 and apparently nothing bad happened, but we all may not look for negative effects at the right places, as AFAIK nobody has provided a comprehensive explanation for the advice to uninstall Call Recorder before upgrading SFOS, yet.

The Following 2 Users Say Thank You to olf For This Useful Post:
Amboss, juiceme

jenix | # 158 | 2017-10-05, 07:29 | Report

Wasn't there an issue with call recorder breaking a previous update? I'd say Jolla couldn't figured out what exactly caused the issue and how to fix this, so they add this advice for all future updates just to be save...

The Following 4 Users Say Thank You to jenix For This Useful Post:
Amboss, Feathers McGraw, juiceme, pichlo

pichlo | # 159 | 2017-10-05, 11:14 | Report

Originally Posted by jenix View Post

Wasn't there an issue with call recorder breaking a previous update?

Not just Call Recorder, any daemon. In my case it was TOHOLED. The workaround was booting with TOHOLED removed and putting it back on only after the UI started.

The Following 5 Users Say Thank You to pichlo For This Useful Post:
Amboss, Feathers McGraw, juiceme, lal, mosen

olf | # 160 | 2017-10-05, 18:22 | Report

Originally Posted by pichlo View Post

Not just Call Recorder, any daemon. [...]

Well we're running in circles now: As @Mikkosssss already pointed out by quoting update.log, all systemd services are stopped before an SFOS upgrade is installed.
So that explanation is too simple; maybe @jenix's guess is closer to the real reason for Jolla's advice (i.e. they also do not fully understand what is going on, but simply want to avoid failing SFOS upgrades).

Last edited by olf; 2017-10-05 at 21:40.

The Following 4 Users Say Thank You to olf For This Useful Post:
Amboss, juiceme, lal, pichlo