I did first: pkcon install zypper (because it was not installed before),
then I did zypper ref and zypper dup, but there was nothing new (because it was fresh installed 
),
then I did pkcon refresh (downloaded something),
then version --dup (downloaded a lot!)
then sfos-upgrade (did not work, gave some error message)
Then I rebooted the device by CLI “reboot”. Then it worked again as described.
Oh!
That would be extremely interesting to someone from Jolla who might notice this topic.
So you did not add the adaptation-common repository manually?
Please post output of
ssu lr
and
pkcon search gstreamer1.0-droid
[root@Xperia10 nemo]# ssu lr
Enabled repositories (global):
Enabled repositories (user):
Disabled repositories (global, might be overridden by user config):
Disabled repositories (user):
[1] This is wrong. “adaptation-common” must be in the section of global repositories. Nobody should add this system repository manually! Manually added repositories always go to the section of user repositories.
[root@Xperia10 nemo]# pkcon search gstreamer1.0-droid
Suche nach Details
Starten
Software-Liste wird aktualisiert
Fertig
Abfragen
Installiert gstreamer1.0-droid-0.20210820.0-1.2.1.jolla.armv7hl (installed) GStreamer droid plug-in contains elements using the Android HAL
Verfügbar gstreamer1.0-droid-tools-0.20210820.0-1.2.1.jolla.armv7hl (adaptation-common) Tools for gst-droid
[root@Xperia10 nemo]#
» So you did not add the adaptation-common repository manually?
No! What is this? Should I do this?
Then I do not understand it!
Are you sure you did not execute the code deusexbeer gave?
Because this adaptation-common repo is added in the user section!
I did execute pkcon install zypper.
Can someone who’s run into this problem test rebuilding just the ssu cache instead of adding the missing repo manually? There’s a bug in ssu that we didn’t think affected public releases, but this is sounding very similar.
Remove any Jolla repos (from the section of user added repos) you might have added manually with:
ssu rr <repo name>
then do:
devel-su
rm -r /var/cache/ssu/
ssu ur
After this, you should see the missing repo (e.g. adaptation-common) in the system repos when you run ssu lr. Please let me know if this gives you the correct repository listing, and if so then i’d recommend doing that rather than adding the repos manually, as this might break the next upgrade if that repo can’t be updated to the new version.
Okay, thanks for the feedback.
Seems to have worked!
But ssu update -f gives
[root@Sailfish nemo]# ssu up -f Device is not registered, can't update credentials [root@Sailfish nemo]# ssu r Username:
So I just removed ssu cache and ssu ur, so I suggest to use:
devel-su; ssu rr adaptation-common; rm -r /var/cache/ssu/; ssu ur
Thanks, I’ll remove that line. I wondered what it did…
Then please also add that line?
[strike] ssu rr adaptation-common; [/strike]
As that name was what was proposed and no one should have modified it?
What is now the complete list i shall execute ?
Easy answer: it depends.
If you have added the repo manually, please check aforehand with ssu lr and if that <adaptation-common> (or whatever name you used) is within the “Enabled repositories (user section)”, then:
devel-su; ssu rr adaptation-common; rm -r /var/cache/ssu/; ssu ur
But if you have not added the repo manually, just:
devel-su; rm -r /var/cache/ssu/; ssu ur
–edit
just checked once more and as the ssu rr only affects user added repositories, it is safe to just use
devel-su; ssu rr adaptation-common; rm -r /var/cache/ssu/; ssu urWorked for me.
adaptation-common is in “Enabled repositories (global)”.
Thanks. In my case I had this “store” repo in the enabled user repositories. Wheresoever that came from:
- store ... https://store-repository.jolla.com/h4113/armv7hl/?version=4.3.0.12
I saw exactly the same behaviour (“store” repo) on another XA2 device. So this was not a special case.
Same on my XA2 with 4.3 No torch, no camera app working. I removed the advanced camera app but this did not help.
Does the solution work for you?
It may be safe, but didn’t work (with devel-su) on my XA2+ with Suomenlinna.
adaptation-common is in the “Enabled repositories (global)”
I updated coming from 3+ and it’s unbelievable that Jolla still hasn’t fixed this after a month.
If I do
ssu rr <repo name>
I get
WARNING: ssu.ini does not seem to be writable. Setting values might not work.
Are you sure we shouldn’t do:
devel-su
ssu rr <repo name> ?
Enfin, I just did just that but the ‘funny’ thing is that if I do
devel-su
ssu rr adaptation-common
ssu lr
adaptation-common is still in the
Enabled repositories (global):
- adaptation-common ... https://releases.jolla.com/releases/4.3.0.12/jolla-hw/adaptation-common/armv7hl/
- adaptation-0 ... https://store-repository.jolla.com/features/4.3.0.12/appsupport/armv7hl/
In other words, I don’t seem to be able to even remove that repository, hence I can’t re-install it either.
By the way, there is another non-jolla repository in Enabled repositories (global): and that’s
- mentaljam-obs ... https://repo.merproject.org/obs/home:/mentaljam/4.3.0.12_armv7hl/
But even with devel-su I can not remove when I do
devel-su
ssu rr mentaljam-obs
as it, too, stubbornly reappears in `ssu lr’ listing.
Possibly related…possibly not, but, I lost the option for Flash on when shooting video, this was on my Jolla1’s camera which occurred after updating the OS several releases back. A reset of the dconf camera path fixed the problem.
dconf reset -f /apps/jolla-camera/
Out of curiosity, I did a dump from dconf on my Xperia 10 ii, I wonder if it may reveal problems for other users by comparing a dconf dump from their device.
dconf dump /apps/jolla-camera/ > xperia10iidconfdump.txt
The above line of code, writes a text file containing the dconf dump of camera settings, name it what you like as long as it ends in .txt, then you can read it or send it elsewhere for further scrutiny.
backCameraLabels=['1.0', '2.0', '0.6']
captureMode='video'
deviceId='1'
exposureCompensation=1
landscapeCaptureButtonLocation=5
portraitCaptureButtonLocation=3
previousBackFacingDeviceId='1'
previousStoragePathStatus=0
qrFilterEnabled=true
saveLocationInfo=false
whiteBalance=0
[back/image]
aspectRatio=1
flash=1
[back/video]
aspectRatio=1
flash=2
viewfinderGrid='none'
[front/image]
aspectRatio=0
[primary/image]
captureMode=1
exposureMode=1
exposureModeValues=[1, 2, 3, 6, 23]
flash=2
iso=3200
meteringMode=1
meteringModeValues=[1, 2, 3]
timer=0
viewfinderGrid='none'
viewfinderGridValues=['none', 'thirds', 'ambience']
[primary/video]
captureMode=2
exposureMode=1
exposureModeValues=[1, 3, 6]
flash=2
iso=0
meteringMode=1
meteringModeValues=[1, 2, 3]
timer=0
viewfinderGrid='none'
viewfinderGridValues=['none', 'thirds', 'ambience']
[secondary/image]
captureMode=1
exposureMode=1
exposureModeValues=[1, 2, 3, 6, 23]
flash=2
iso=0
meteringMode=1
meteringModeValues=[1, 2, 3]
timer=0
viewfinderGrid='none'
viewfinderGridValues=['none', 'thirds', 'ambience']
[secondary/video]
captureMode=2
exposureMode=1
exposureModeValues=[1, 3, 6]
flash=2
iso=0
meteringMode=1
meteringModeValues=[1, 2, 3]
timer=0
viewfinderGrid='none'
viewfinderGridValues=['none', 'thirds', 'ambience']
end of dump.txt
Just, where it belongs!
So nothing to worry/do.
That is another story and (looking-for-next-fanboy-bash-or-censoring:) another real mismanagement of how updates are spit out to ‘normal users’. With a mistake that camera, torch, videos (and more?) were not working you (the ‘normal user’) was left alone for over two weeks (@deusexbeer many thanks for bringing up the workaround!, @abranson, thanks for correction). And even then you need cli experiences and root rights to correct.
Not to speek about that a ‘fix’ would only come maybe with the next release in 3-6 months!