after a month i have decided to give it a try again and install an older image for waydroid
however, now i can not download, or unzip the image
my system is out of space
when i do that:
rm -rf /var/lib/waydroid /home/.waydroid ~/waydroid ~/.share/waydroid ~/.local/share/applications/aydroid ~/.local/share/waydroid
i end up with 700 mb of space in system data, which is hardly sufficient to download and unzip the image
any ideas what i could clean up ?
I have only 550M space in my / so I’ve not been able to test this. Deleting stuff in .local and co. won’t really help. I wonder if the files it can be symlinked from /home/.system ? But I assume you were trying to use the
waydroid init
method? @piggz , symlinking won’t work will it?
The root filesystem on the GS290/Volla is way too small.
Yes, a problem since many years. @Jolla : Please do something that is easier to do than resizing root partition this way:
Until now, I wasn’t couraged enough to follow this howto, because I fear to brick the phone.
Also I don’t know if this howto is also working on the Volla, it’s written for the Sony.
maybe i should be more precise :
i flashed it, installed chum and then immediately waydroid so maybe that s why the installation worked in first place ?
cause now i can t download nor unzip
even though that i did remove the waydroid files before …
regarding spaceproblem:
i have solved it like that:
BUT that does not solve the issue that i would like to use an older image, not the latest and older one.
i did download it manually, but i can not tell waydroit to use it in init.
from waydroid channel i got that information
sudo rm -rf /usr/share/waydroid-extra/images
sudo ln -s /home/defaultuser/image $_
sudo waydroid init -f
creation of symlink using ln i had to do in /usr/share/waydroid-extra folder …
steps:
download wanted images (vendor and system)
unzip that
copy that into /home/defaultuser/images folder
create the symlink in waydroid-extra : devel-su ln -s /home/defaultuser/images
run waydroid init -f
btw: reset waydroid:
Reset Waydroid:
stop the waydroid-container.service # systemctl stop waydroid-container.service
cleanup sudo rm -rf /var/lib/waydroid /home/.waydroid ~/waydroid ~/.share/waydroid ~/.local/share/applications/*aydroid* ~/.local/share/waydroid
btw: i was told that one can also modify the images_path in /var/lib/waydroid/waydroid.cfg (and yes there is an entry)
and finally:
while it seems i was able to run the images that i did download, waydroid init was super quick.
runner still hangs in waiting for android ui
mental note: adb reboot-bootloader
works to send phone with antroid/vollaos to booloader mode
when fucking buttons do not work
success !!
4.3.0.15 sfos + images from 14052022
did update now to 4.4.58 with zypper and waydroid is still running
new final flow - reflashing a sfos gs290
Old Volla - GS290 / SFOS 4.4.0.72…
A few days ago, Chum reported 2 available updates for Waydroid, I installed them and now Waydroid starts and runs faster and smoother!
Many thanks to all devs!!!
Bug report - Old Volla - GS290 / SFOS 4.4.0.72…
Stock camera, Advanced camera and Fotokopierer still not working. All 3 apps crash and minimize to grid view of open apps after taking a shot.
Strange. My GS290 is running fine. I wonder if this has anything to do with the adaptation packages that both @pawel.spoon and I were missing?
I have to add (forgot to mention in previous post), that in Waydroid, the Android stock Camera and also Open Camera app is working fine.
The SF apps mentioned above also can access the cam and I can see the image on the screen. But they can’t save the image but crash as written above.
The Android cam apps are able to save the photos to Android memory.
For me it looks like all the 3 SF camera apps don’t have appropriate write access to the drive in the same way, so it is maybe not something that relies to the apps and the supporter can fix but more likely a bug in 64 bit SFOS?
The three Xperia 10’s in my family with their 32 bit SFOS are not affected by this bug, but only my 64 bit Volla.
Is there an option to install the missing packages manually via CLI and then test if the cameras bug is gone?
No, SailfishOS 4.4.0 (or in general: some A.B.C release versions) is a “stop release”. Hence one may call any point release A.B.C.x of such a “stop release” a “stop release”, but that easily confuses people into thinking that a specific point release version is relevant.
Thus you should be able to upgrade from any 4.3.0.x release to any 4.4.0.y release, i.e., from any point release of a “stop release” to any point release of next “stop release”, in general (i.e., that is how Jolla wants it to be). Release specific or device-port specific bugs may render this statement untrue.
BTW, upgrading SailfishOS in smaller steps than from a(ny) point release of the last “stop release” to the current point release or from any release to a(ny) point release of the next “stop release” sounds like voodoo to me. Again: I lack experience with community ports and release specific or device-port specific bugs may render this statement untrue.
They did: Buy an Xperia 10 II or III, flash SailfishOS and the root volume size will be 4000 MBytes. That is how they addressed this issue. Its up to the device porters to utilise the scheme Jolla developed for this, which I comprehensively described in some other Volla specific thread (“topic”) here at FSO.
Until now, I wasn’t couraged enough to follow this howto, because I fear to brick the phone.
Did you meant to address specifically the section 3.3 Increasing the “root” LVM volume size?
Well, at the beginning of section 3.3 I explicitly described how things should look, before one starts altering the LVM volumes: If they do look as described, I see no reason why this section should not be applicable.
But you cannot “brick your phone” (which means that one cannot reflash it any longer) by altering these SailfishOS specific LVM volumes: The partitioning scheme and the content of any other partition (e.g., the boot partition(s)) are not touched by following this section 3.3.
Also I don’t know if this howto is also working on the Volla, it’s written for the Sony.
Neither do I, because I do not own any of the Volla models.
Though IMO, solely the section 1.1 First steps contains mostly points, which are specifically for Sony Xperias.
If you carefully read my “Guide: Installing SailfishX on Xperias”, all sections should be applicable to any SailfishOS device, with the exception of section 1.1.
I happen to own only Xperias, hence I developed this guide on, with and for them, thus I do not claim anything else.
Feedback from users, positive and negative (e.g., criticism) is always welcome, for this guide preferably by opening a new “issue” at Gitlab.
P.S.: I still wonder why @piggz did not increase the root volume size to 4000 MBytes for his more recent ports of SailfisOS, like Jolla did for the Xperia 10 II and III. I already provided this suggestion accompanied with the technical details in some other Volla specific thread (“topic”) here at FSO.
I do see that it might turn out to be troublesome or impossible to increase the root volume size in an fully automated manner when upgrading SailfishOS etc. But to create a larger root volume when creating a new installation image for a new device appears to be quite easy: Just utilise what Jolla implemented.
Neither did I (going into details here), because I do not run any community port of SailfishOS. One porter reported years ago, that one of his users was successfully upgrading SailfishOS with sailfshos-upgrade. As stated at many places (e.g., in its README) sailfshos-upgrade is just a frontend for ssu re A.B.C.D && version --dup; if that works, one should rather use sailfshos-upgrade (because the generally recommended GUI updater cannot be used on SailfishOS ports; I always wondered why: Is it proprietary software, does it need a Jolla account to run, or is something else the reason?).
OTOH, some porters emphasise using the “zypper dance” for upgrading their port of SailfishOS. I do not know the technical details, because I do not own a device running a SailfishOS port. But I would be happy to be informed about any special requirements device ports have and will consider to take them into account in sailfishos-upgrade.
Edit: I just saw that @Seven.of.nine and @pawel.spoon both used ssu re A.B.C.D && version --dup, not the “zypper dance” ssu re A.B.C.D && zypper ref && zypper dup.
Due the usual absence of positive feedback from users, I cannot tell.
You are welcome to change that!
Side note
7o9 has already provided an unusual exception from this for another piece of software, but I general I assume that of users who experience a bug in Free Software (“FLOSS”) about every 100th reports it and of users who are fond of a specific Free Software (“FLOSS”) about every 1000th denotes this to the author(s), sometimes even spiced with some helpful information, e.g., which features are most important, what works well, what does not work well, UI design goodies and flaws etc.
A “Yes” to both aspects addressed:
these were the packages that got removed when I updated from .64 to the non-existant yggdrasil .68 …
patterns-sailfish-device-adaptation-yggdrasil
patterns-sailfish-device-configuration-yggdrasil
Try installing them.
@poetaster thanks very much, please help me: what is the command to install these two packages? Is it ‘pkcon install packetname’? Or shall I better use zypper to install? Is there any difference in the result between them?
I’m now on 4.4.0.72, with …68 and …64 the cam did work fine. Bug occured when I updated to …72, and it affects all 3 cam apps - stock cam, advanced cam and Fotokopierer - in the same way: app crashes in the moment where the shot should be saved to memory, or - in case of Fotokopierer - should be further processed.
Camera under Waydroid works fine. Only native SFOS apps are affected.
I did so, using ‘zypper install packagename’. The first (patterns-sailfish-device-adaptation-yggdrasil) reported ‘is installed’, and the second (patterns-sailfish-device-configuration-yggdrasil) was installed by zypper. Then I rebooted the phone and tried if something changes.
Result is: nothing changes. All 3 apps still crash (minimize) after taking a shot.
Is there any other option that has a chance to succeed?
Hmmm. It could be that there is something else missing.
There I had somehow also been missiing busybox-symlinks-procps so try:
zypper install patterns-sailfish-device-configuration-common busybox-symlinks-procps
I tried and got this:
andrea@andrea-Voom-Laptop-Max:~$ ssh volla
Last login: Wed Dec 28 10:55:29 2022
,---
| Sailfish OS 4.4.0.72 (Vanha Rauma)
'---
[defaultuser@VollaPhone ~]$ devel-su
Password:
[root@VollaPhone defaultuser]# zypper install patterns-sailfish-device-configuration-common busybox-symlinks-procps
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...
Problem: das zu installierende busybox-symlinks-procps-1.33.1+git3-1.7.14.jolla.aarch64 steht im Konflikt mit 'procps-ng', das vom installierten procps-ng-3.3.16+git2-1.6.2.jolla.aarch64 bereitgestellt wird
Lösung 1: Deinstallation von procps-ng-3.3.16+git2-1.6.2.jolla.aarch64
Lösung 2: busybox-symlinks-procps-1.33.1+git3-1.7.14.jolla.aarch64 nicht installieren
Wählen Sie aus den obigen Lösungen mittels Nummer oder brechen Sie (a)b [1/2/a/d/?] (a):
so I aborted because I don’t know what to do. How can I solve this?
Try this alone first.
For reference, I had made a log of what happened when I made the mistake of updating .64 to .68: https://poetaster.de/sfos/64-72.txt
What one can see is the following removals:
The following 5 packages are going to be REMOVED:
droid-config-yggdrasil-policy-settings
ofono-ril-binder-plugin
ofono-ril-plugin
patterns-sailfish-device-adaptation-yggdrasil
patterns-sailfish-device-configuration-yggdrasil
check those, too.