postmarketOS als Dualboot

S

svenh

Member
Original poster
6 Januar 2023
26
Ich verwende postmarketOS auf einem Pocophone F1 und würde gern bald den Wechsel zum Shift6mq wagen. Zugleich würde ich gern mein altes Android-Handy stilllegen; schwatzt mir zu viel mit Google ...
Daher meine Frage: Kann man das Shift6mq schon als Dualboot betreiben, also postmarketOS plus ein weiteres Betriebssystem?
 
Danke für den Link. Das habe ich beim Suchen übersehen, sorry.

Dann schließe ich eine Frage an: Gibt es eine Anleitung, wie man Dualboot auf dem Shift6mq einrichtet?
 

SHIFT SHIFT6mq (shift-axolotl) - postmarketOS Wiki

wiki.postmarketos.org wiki.postmarketos.org

Everything is in here.
On one partition the Android, on the other (installed as a system) Postmarketos. Remember the developer settings in the bootloader to switch Slots by need. Furthermore, almost every Android update must be installed from within the recovery. But before that you have to switch to the Postmarketos slot, otherwise it will be overwritten with Android. An OTA from the system may no longer be work without crashing the PMOs-Partition.

I can't say how it behaves with a shared user data partition. It gives me a headache. I think they are redirected to an external SD card for PostmarketOS.
But amartinz can probably provide information when he has finished his vacation 😉.

Think I'll try that out when I get a chance. Actually seems solid.

greetz

Hier steht alles drin.
Auf einer Partition das Android, auf der anderen (als System installiert) Postmarketos. Denke an die Entwicklereinstellungen im Bootloader zum wechseln. Weiterhin muss dann quasi jedes Android-Update aus dem Recovery installiert werden. Vorher muss aber auf den Postmarketos-Slot gewechselt werden, da dieser sonst mit Android überschrieben wird. Ein OTA aus dem System darf nicht mehr gemacht werden.

Wie es sich mit einer gemeinsamen Userdata-Partition verhält kann ich nicht sagen. Die macht mir Kopfzerbrechen. Denke die lenkt man für PostmarketOS auf eine externe SD-Karte um.
Da kann aber wahrscheinlich @amartinz Auskunft geben wenn er seinen Urlaub beendet hat 😉.

Denke bei Gelegenheit probiere ich das auch Mal aus. Wirkt eigentlich solide.

Greetz
 
Zuletzt bearbeitet:
  • Like
Reaktionen: amartinz, danielp und svenh
Das wäre mein nächster Link gewesen. Noch was bei der "Recherche" übersehen. 😊

Edit: Die Anleitung enthält ja zwei Möglichkeiten. Vermutlich ist die komplette Installation in userdata sicherer als in die Super Partition (ist sowieso noch WIP) auch wenn es kein richtiges Dualboot erlaubt.

Aber der Experte kann da sicher mehr drüber sagen.
 
Zuletzt bearbeitet:
Die Installation nach userdata verhindert ein Betreiben von zwei Betriebssystemen.
(kein Android, pmOS hat 100+ GB zur Verfügung)

Wenn pmOS mit dem zweiten Installationsweg (also Installation in die super Partition) eingerichtet wird, nutzt Android die userdata partition und pmOS die restliche Größe innerhalb der super Partition.
(Dual Boot mit Android möglich, pmOS hat weniger Speicher zur Verfügung)

Ein Teilen von der userdata Partition ist nicht möglich wegen der File Based Encryption von Android.

Es ist möglich die logischen Partitionen innerhalb der super Partition zu resizen, damit pmOS mehr Platz zur Verfügung steht.

Edit: Oder/Und wie @@Lhotze geschrieben hat, eine externe SD-Karte einlegen und manuell via LVM oder einfach als extra Mountpoint für Speichernutzung einbinden.
 
  • Like
Reaktionen: svenh, @Lhotze und danielp
Jetzt habe ich mal ne Frage:

Habe mir über pmbootstrap die letzte aktuelle 22.12er Version von PostmarketOS erstellt. Diese will ich jetzt auf Partition B installieren um das Gerät im Dualboot zu nutzen.
Das Funktioniert auch mit dem Kernel
Code: 
pmbootstrap flasher flash_kernel --partition boot_b
ohne Probleme. Wenn ich aber mit der beschriebenen Anleitung versuche den Befehl
Code: 
pmbootstrap flasher flash_rootfs --partition system_b
auszuführen, bekomme ich im Fastbootd vom Stock-Recovery die Meldung "no such file or directory" und im LineageRecovery Fastbootd die Meldung "Not enough space to resize partition".
Mir leuchtet also ein, dass die System-Partition in der Super-Partition zu klein ist.

Gibt es dafür eine Möglichkeit das irgendwie anzupassen. Hab aus (optischen) und Speicherplatzgründen schon POSH als Interface gewählt.
Das Image wäre bei mir 2,6 GB im Gesamten. Im Abgleich zu den generic images von PMOS scheint das tatsächlich ein bissel zu groß. Das ist nur mit 1.6 GB gelistet.

Das Installationsproblem tritt unabhängig der gewählten Partition a/b auf.
Gibt es eine Möglichkeit, die selbst erstellten oder die generic Images manuell, ohne Nutzung von pmbootstrap zu flashen? Bspw. nur über Fastbootd mit dem Befehl
Code: 
fastboot flash system_b 20230108-1157-postmarketOS-v22.12-phosh-22.1-shift-axolotl.img
nachdem ich bereits das PMOS Bootimage über pmbootstrap installiert und die DTBO-Partition gelöscht habe? Will es jetzt auf Verdacht nicht ausprobieren, da das Gerät mein Daily Driver ist 😅.

Greetz
 
Ich weiß nicht, ob das hilft. Aber für den Fall, dass "pmbootstrap flasher" scheitert, ist bei einigen Devices beschrieben, wie man ein split-Image erzeugt und nur mit fastboot installiert. Für mein OnePlus 6 (s. https://wiki.postmarketos.org/wiki/OnePlus_6_(oneplus-enchilada)) hat z.B. Folgendes funktioniert:
pmbootstrap install --split pmbootstrap export fastboot erase dtbo fastboot flash <PARTITIONSNAME-FUER-ROOT> /tmp/postmarketOS-export/oneplus-enchilada-root.img # man sieht oft userdata für <...>, aber das darf man bei Dualboot mit Android nie nehmen! s.u. Lhotze fastboot flash vendor /tmp/postmarketOS-export/oneplus-enchilada-boot.img fastboot reboot
Anderes Device und anderer Anwendungsfall (kein Dualboot): also Vorsicht :)
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Dafür musst du die super Partition anpassen, wie in den Spoilern bei dem Issue beschrieben.

Zuerst in den fastbootd Modus booten, danach die logischen Partitionen, welche nicht für pmOS benötigt werden, entfernen und die system Partition um den nun freigewordenen Wert resizen.
Als Beispiel für den Slot B:

Code: 
$ fastboot delete-logical-partition product_b
$ fastboot delete-logical-partition system_ext_b
$ fastboot delete-logical-partition vendor_b
$ fastboot resize-logical-partition system_b 6438256640

Nach dem Resizen in den fastbootd Modus neustarten (einfach für den Fall der Fälle) und die super Partition Installationsanleitung befolgen:

Code: 
$ # Flash rootfs to system_b partition
$ pmbootstrap flasher flash_rootfs --partition system_b
$ # Flash kernel to boot
$ pmbootstrap flasher flash_kernel --partition boot_b
$ # Reboot to bootloader, as erasing dtbo is not working in fastbootd
$ fastboot reboot bootloader
$ # Erase dtbo_b partition, as it conflicts with our mainline kernel
$ # Note: this operation takes some time to complete
$ fastboot erase dtbo_b
$ # Reboot into postmarketOS
$ fastboot reboot
 
  • Like
  • Love
Reaktionen: Martin S., spaetz, svenh und eine weitere Person
amartinz schrieb:
Dafür musst du die super Partition anpassen, wie in den Spoilern bei dem Issue beschrieben.
Zum Vergrößern anklicken....
Den hatte ich nicht auf dem Schirm. Vielen Dank dafür.

Kurze Verständnisfrage:

Wenn ich irgendwann dann wieder ein reguläres AndroidOS mit Dual-Partition auf beiden Partitionen betreiben wollen würde, müsste ich die Partitionierung dann wieder rückgängig machen mit
Code: 
fastboot create-logical-partition <logical_parition_slot> <size>`
oder würde das beim flashen einer Android-Zip im gegenüberliegenden Slot selbstständig durchgeführt werden?

Falls nein, woher bekomme ich die Partitonsgrößen der logischen Partitionen her?

Greetz und Danke
 
Zuletzt bearbeitet:
@Lhotze schrieb:
Den hatte ich nicht auf dem Schirm. Vielen Dank dafür.

Kurze Verständnisfrage:

Wenn ich irgendwann dann wieder ein reguläres AndroidOS mit Dual-Partition auf beiden Partitionen betreiben wollen würde, müsste ich die Partitionierung dann wieder rückgängig machen mit
Code: 
fastboot create-logical-partition <logical_parition_slot> <size>`
oder würde das beim flashen einer Android-Zip im gegenüberliegenden Slot selbstständig durchgeführt werden?

Falls nein, woher bekomme ich die Partitonsgrößen der logischen Partitionen her?

Greetz und Danke
Zum Vergrößern anklicken....
Du kannst am laufenden Gerät lpdump aufrufen (für Beispiel Output siehe obiges Issue) und dann die Größen von den Partitionen im Slot A hernehmen, da sie identisch sind.
 
  • Like
Reaktionen: @Lhotze
Kurzer Zwischenstand zum Dualboot Androis / PostmarketOS:
So wie es hier beschrieben ist habe ich mir zweimal mein System in den Abgrund geschossen. Konnte aber zumindest mal die Fehler ausmachen.

Bis zu dem Punkt, an dem die logische Systempartition vergrößert wird startet mein installiertes Android noch. Nach dem Vergrößern startet es nur noch in den Bootloader.
Wird es (nach dem Vergrößern, vor dem Installieren von PostmarketOS) dann über das "gegenüberliegende" Recovery in den Ursprungsslot installiert, läuft es wieder wie vorher mitsamt Nutzerdaten auf der Userdata-Partition.

Nachdem PostmarketOS in die Resized Partition geflashed wurde startet das Android ebenfalls nicht mehr. Hier kann es auch nicht mehr über das gegenüberliegende Recovery installiert werden. Wir kennen den mitgeteilten Fehler bereits: kInstallDeviceOpenError

Hier hilft dann nichts mehr als die Userdata-Partition zu Löschen bevor Android wieder installiert werden kann.

Fun Fact: Bei mir nutzte PostmarketOS doch tatsächlich nach seiner Installation auf der System-Partition den Speicher der Userdata-Partition. So habe ich mir das nicht vorgestellt.

Ein Wipe der Userdata mit nachträglicher Installation von Android in den ursprünglichen Slot machte übrigens, dass PostmarketOS nicht mehr bootete.

Meine Vermutung ist nun, dass entweder die Partition mit dem Befehl
Code: 
fastboot resize-logical-partition system_b 6438256640
zu krass vergrößert wird und eine andere Beschädigt oder meine über PostmarketOS erstellte Image fehlerhaft ist. Das würde aber nicht erklären, warum das Android nach dem Vergrößern der System-Partition nicht mehr läuft, wenn noch nichts in Richtung PostmarketOS installiert wurde.

Um meine Nerven zu schonen Probiere ich hier erst mal nicht mehr rum. Nervt hart jedesmal 1.000 Backups wieder einzuspielen 😅.

Greetz
 
Eigenartig, wir haben das Setup auf Test Geräten genau so laufen wie beschrieben.
Danke für das Feedback, gehört anscheinend nochmal gründlich durchgegangen, bevor es so übernommen wird.

Übrigens kann pmOS auch auf der SD-Karte installiert werden.

Installation - postmarketOS Wiki

wiki.postmarketos.org wiki.postmarketos.org

Das müsste ich auch mal testen und ggf Support dafür in den Bootloader miteinbauen, wenn es nicht auf Anhieb klappt.
Wäre dann etwas "sicherer" als mit der super Partition herumzuhandieren.
 
amartinz schrieb:
Danke für das Feedback
Zum Vergrößern anklicken....
Kein Problem. Ich feiere euch und das 6mq ja für die Möglichkeiten. Da ich aber auch weiß, dass die alternativen Betriebssysteme (die ich tatsächlich unbedingt auf Herz und Niere geprüft haben will, weil da auch geile Sache mit drin sind) leider nur in manchen Teilen eine Alternative zum Marktführer Android darstellen (denke im Bereich Usability und bspw. Kamera und Mobile Anwendungen kommt momentan nix dran. Klar kann man sich mit Waydroid helfen, das wirkt aber weder wie Fisch und Fleisch) ist so ein Dualboot ne geile Sache.

Ich weiß auch nicht, wie viel Einfluss du auf den UB-Port-Installer hast und ob es da überhaupt die technischen Möglichkeiten für gibt. Der Installiert das Generic PostmarketOS immer in der Userpartition. Vll kann man das anpassen, dass man zusätzlich einen Slot auswählen kann und das dort als Systemimage installiert wird.
Würde die Installation für jeden ohne ein Linux (wobei die meisten Nutzer von Ubuntu Touch und PostmarketOS wahrscheinlich von dort kommen 😉) oder ohne großes Terminal und Fastbootwissen massiv vereinfachen und würde eine bereits vorhandene Ressource nutzen.

Gut zu Wissen ist übrigens auch, dass (mindestens) die Lineage-Zip eine veränderte Systempartition beim Flashen wiederherstellt. Man muss die Partitionen also beim Weg zurück nicht manuell einpflegen 😅.

Greetz
 
@Lhotze schrieb:
Ich weiß auch nicht, wie viel Einfluss du auf den UB-Port-Installer hast und ob es da überhaupt die technischen Möglichkeiten für gibt. Der Installiert das Generic PostmarketOS immer in der Userpartition. Vll kann man das anpassen, dass man zusätzlich einen Slot auswählen kann und das dort als Systemimage installiert wird.
Würde die Installation für jeden ohne ein Linux (wobei die meisten Nutzer von Ubuntu Touch und PostmarketOS wahrscheinlich von dort kommen 😉) oder ohne großes Terminal und Fastbootwissen massiv vereinfachen und würde eine bereits vorhandene Ressource nutzen.
Zum Vergrößern anklicken....
Das ist auf meiner Liste, aber erst, sobald die Installationsschritte festgelegt sind.
Dualboot ist ja noch eher experiementell, wie du gesehen hast :D

Außerdem wird auch bei postmarketOS noch weiter an Slots und OTA Geschichten gebastelt.
Dauert noch, bis alle Bausteine zusammengesetzt werden können.
 
Hört sich gut an. Aber kein Stress. Denke die wenigsten werden zeitnah auf PmOS umsteigen wollen und ich bleibe erstmal auf Android. Lässt die Nerven heiler, außerdem haben ich (nachdem ich mir mein System abgeschossen und neu aufgesetzt habe) demnächst noch ein LOS 20 zu testen 😉.

Greetz
 
Hallo! Ich bin hier etwas verwirrt:

Die "Installation on super partition" hat funktioniert. Ich kann über Slot A nun pmOS booten und über Slot B ShiftOS-L.

Jetzt möchte ich, dass die pmOS root-Partition die ~100GB Platz bekommt.

Geht das? So dass Dual-Boot erhalten bleibt?
 
  • Like
Reaktionen: jefla
Wow,... Ich hätte halt die Sorge, dass dir das "um die Ohren fliegt" wenn ein OTA-Update von OS-L in den inaktiven Slot installiert wird.
Du wirst jedes Update per Sideload in den richtigen Slot installieren müssen...
Spannend! Berichte bitte weiter, wie es dir damit ergeht👍
 
  • Like
Reaktionen: jefla und NoG....eFan
check6 schrieb:
Hallo! Ich bin hier etwas verwirrt:

Die "Installation on super partition" hat funktioniert. Ich kann über Slot A nun pmOS booten und über Slot B ShiftOS-L.
Zum Vergrößern anklicken....
Ich hatte mal eine ähnliche Konstellation. Das Problem war, wenn ich das system ein wenig eingerichtet hatte, und dann das OS (SLOT) wechseln wollte ging das dann nur mit Full Wipe. Hatte ich den Full Wipe gemacht, und das andere OS (im anderen Slot) gewählt und ein bisschen eingerichtet, und wollte wieder den Slot wechseln (OS) ging das Spiel wieder von vorne los (Full Wipe). Aber villeicht hast du mehr Glück. Viel spass beim probieren.
 
  • Like
Reaktionen: Uli und @Lhotze
check6 schrieb:
Hallo! Ich bin hier etwas verwirrt:

Die "Installation on super partition" hat funktioniert. Ich kann über Slot A nun pmOS booten und über Slot B ShiftOS-L.

Jetzt möchte ich, dass die pmOS root-Partition die ~100GB Platz bekommt.

Geht das? So dass Dual-Boot erhalten bleibt?
Zum Vergrößern anklicken....
Dazu müsstest du repartitionieren.

Die "userdata" partition splitten und resizen und danach bei pmOS zb als /home einbinden.

Denn Android und pmOS können sich die userdata Partition wegen der File Based Encryption nicht teilen.
 
Dass die beiden Systeme die Partition nicht teilen können ist in Ordnung, aber parted (in pmOS) kann wohl nicht mit der userdata-Partition umgehen.

Ich könnte sie zwar ganz löschen, aber wie dann neu erstellen, sodass Android von der Operation nichts merkt?

Die root direkt zu vergrößern geht jedenfalls in diesem Setup nicht (also auch nicht um 1-2 GB)?
 
check6 schrieb:
Dass die beiden Systeme die Partition nicht teilen können ist in Ordnung, aber parted (in pmOS) kann wohl nicht mit der userdata-Partition umgehen.
Zum Vergrößern anklicken....
Ich denke solange du ein Label vergibst, findet Android die userdata Partition automatisch, denn die fstab nutzt Labels dafür.

check6 schrieb:
Die root direkt zu vergrößern geht jedenfalls in diesem Setup nicht (also auch nicht um 1-2 GB)?
Zum Vergrößern anklicken....
In der Super Partition ist Platz vorreserviert, den pmOS aber nicht vollständig nutzt.
Du könntest somit beim Slot, in den du pmOS installiert hast, alle logischen Partitionen bis auf die system Partition, löschen und dann system resizen.

Dazu musst du in den fastbootd Modus booten, z.B.:
  • Im Bootloader starten via Lautstärke Rauf + Power Button
  • fastboot reboot fastboot
Danach kannst du die Größe der jeweiligen Partitionen rausfinden:
  • fastboot getvar all
Code: 
(bootloader) partition-size:xbl_config_b:0x20000
(bootloader) partition-size:vbmeta_vendor_b:0x10000
(bootloader) partition-size:sda:0x1C63000000
(bootloader) partition-size:sdc:0x400000
(bootloader) partition-size:mdtpsecapp_a:0x400000
(bootloader) partition-size:dsp_b:0x2000000
(bootloader) partition-size:qupfw_a:0x10000
(bootloader) partition-size:ImageFv_b:0x100000
(bootloader) partition-size:modem_b:0x7800000
(bootloader) partition-size:misc:0x100000
(bootloader) partition-size:modem_a:0x7800000
(bootloader) partition-size:vbmeta_b:0x10000
(bootloader) partition-size:cmnlib64_b:0x80000
(bootloader) partition-size:mdtpsecapp_b:0x400000
(bootloader) partition-size:hyp_a:0x80000
(bootloader) partition-size:aop_a:0x80000
(bootloader) partition-size:ImageFv_a:0x100000
(bootloader) partition-size:cmnlib64_a:0x80000
(bootloader) partition-size:hyp_b:0x80000
(bootloader) partition-size:dsp_a:0x2000000
(bootloader) partition-size:dtbo_b:0x800000
(bootloader) partition-size:devcfg_a:0x20000
(bootloader) partition-size:qupfw_b:0x10000
(bootloader) partition-size:recovery_a:0x6000000
(bootloader) partition-size:sdb:0x400000
(bootloader) partition-size:bluetooth_b:0x100000
(bootloader) partition-size:recovery_b:0x6000000
(bootloader) partition-size:keymaster_b:0x80000
(bootloader) partition-size:xbl_config_a:0x20000
(bootloader) partition-size:xbl_a:0x380000
(bootloader) partition-size:keymaster_a:0x80000
(bootloader) partition-size:sde:0x100000000
(bootloader) partition-size:userdata:0x195FD73000
(bootloader) partition-size:devcfg_b:0x20000
(bootloader) partition-size:xbl_b:0x380000
(bootloader) partition-size:cmnlib_b:0x80000
(bootloader) partition-size:abl_a:0x100000
(bootloader) partition-size:storsec_a:0x20000
(bootloader) partition-size:boot_a:0x4000000
(bootloader) partition-size:aop_b:0x80000
(bootloader) partition-size:boot_b:0x4000000
(bootloader) partition-size:dtbo_a:0x800000
(bootloader) partition-size:vbmeta_system_b:0x10000
(bootloader) partition-size:mdtp_a:0x2000000
(bootloader) partition-size:bluetooth_a:0x100000
(bootloader) partition-size:abl_b:0x100000
(bootloader) partition-size:mdtp_b:0x2000000
(bootloader) partition-size:storsec_b:0x20000
(bootloader) partition-size:tz_a:0x200000
(bootloader) partition-size:cmnlib_a:0x80000
(bootloader) partition-size:sdd:0x8000000
(bootloader) partition-size:tz_b:0x200000
(bootloader) partition-size:metadata:0x1000000
(bootloader) partition-size:super:0x300000000
(bootloader) partition-size:vbmeta_a:0x10000
(bootloader) partition-size:vbmeta_system_a:0x10000
(bootloader) partition-size:vbmeta_vendor_a:0x10000
(bootloader) partition-size:product_a:0x91111000
(bootloader) partition-size:product_b:0x9110C000
(bootloader) partition-size:system_a:0x360B2000
(bootloader) partition-size:system_b:0x0
(bootloader) partition-size:system_ext_a:0x152FA000
(bootloader) partition-size:system_ext_b:0x152F2000
(bootloader) partition-size:vendor_a:0x1B842000
(bootloader) partition-size:vendor_b:0x0

Anhand der Information, kannst du die ungenutzten Partitionen löschen und deine super Partition um die freigewordene Größe erweitern mit:
  • fastboot delete-logical-partition NAME
  • fastboot resize-logical-partition NAME SIZE
Code: 
 delete-logical-partition NAME
                            Delete a logical partition with the given name.
 resize-logical-partition NAME SIZE
                            Change the size of the named logical partition.

Beispiel: Ich hab bei meinem derzeitigen Stand Android 13 im Slot A installiert, kann also folgende Partitionen für pmOS löschen:
  • product_b - 0x9110C000
  • system_ext_b - 0x152F2000
  • vendor_b - 0x1B842000
    • Größe von A hernehmen, da A == B
Beim Rechnen bin ich leider nicht so gut, deswegen bitte selbst überprüfen 😅
Denke so geht das am Einfachsten (und sollte stimmen?):
  • product_b
    • echo "ibase=16; 9110C000"|bc
    • Ergebnis: 2433794048
  • system_ext_b
    • echo "ibase=16; 152F2000"|bc
    • Ergebnis: 355409920
  • vendor_b
    • echo "ibase=16; 1B842000"|bc
    • Ergebnis: 461643776
Also wurden dadurch 2433794048 + 355409920 + 461643776 = 3250847744 frei.
Dann nimmst du die Größe von deiner derzeitigen system_b Partition her, addierst 3250847744 und hast die neue Größe für das resize command.
 
Zuletzt bearbeitet:
Die Freigabe und Nutzung des Speichers der unnötigen logischen Volumes hat geklappt.

system_ext_X gab es bei mir keine, aber die root-Partition hat jetzt insgesamt 4.2G - damit lässt sich arbeiten!

Zum Thema userdata schreibe ich gleich.

Übrigens: Beste Anleitung aller Zeiten! Danke!
 
  • Like
Reaktionen: amartinz
Auch die userdata konnte ich erfolgreich verkleinern. Allerdings war ein Factory Reset notwendig, bevor Android die neue Größe korrekt erkannte. (Vielleicht gibt es auch eine sanftere Methode?)

Per parted resizepart hatte ich die userdata (in meinem Fall sda9) auf 1 GB reduziert und dann eine neue (sda10) erstellt. In pmOS passte alles:

Code: 
$ df -h
Filesystem             Size  Used Avail Use% Mounted on
dev                     10M     0   10M   0% /dev
run                    3.8G  1.8M  3.8G   1% /run
/dev/mapper/root       4.2G  1.5G  2.5G  38% /
/dev/mapper/system_a1  222M  117M   93M  56% /boot
shm                    3.8G   14M  3.7G   1% /dev/shm
/dev/sda10              99G  2.1M   94G   1% /mnt


Im Android-Dateimanager wurde die userdata nach wie vor mit 107G angezeigt. Hier die Ausgabe von df:

Code: 
$ df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/block/dm-6  896M  893M     0 100% /
tmpfs            3.7G  996K  3.7G   1% /dev
tmpfs            3.7G     0  3.7G   0% /mnt
tmpfs            3.7G     0  3.7G   0% /apex
/dev/block/dm-7  524M  523M     0 100% /product
/dev/block/dm-8  540M  539M     0 100% /vendor
/dev/block/dm-9  101G  1.9G   99G   2% /data
/dev/block/loop2 836K  808K   12K  99% /apex/com.android.tzdata@292500001
/dev/block/loop3 5.2M  5.2M     0 100% /apex/com.android.media@292000301
/dev/block/loop4  98M   98M     0 100% /apex/com.android.runtime@1
/dev/block/loop5 232K   36K  192K  16% /apex/com.android.apex.cts.shim@1
/dev/block/loop6 2.2M  2.2M     0 100% /apex/com.android.resolv@292000502
/dev/block/loop7 4.9M  4.9M     0 100% /apex/com.android.conscrypt@291900801
/dev/block/loop8  21M   21M     0 100% /apex/com.android.media.swcodec@292200001
/data/media      101G  1.9G   99G   2% /storage/emulated


Zum Test habe ich versucht das Dateisystem mit Nullen zu füllen, was in Ein-/Ausgabefehler mündete:

Code: 
axolotl:/storage/self/primary/Download $ split -b 1000m < /dev/zero ; sync
split: xaa: I/O error

axolotl:/storage/self/primary/Download $ ls x* | wc -l
17

axolotl:/storage/self/primary/Download $ du -ch ./
16G     ./
16G     total

Obwohl 16G angezeigt wurden, vermute ich, dass vielleicht nicht wirklich so viel (und vor Allem über die Partition hinaus) geschrieben wurde.

Android konnte danach neu starten. Die x*-Dateien waren allerdings verschwunden und der Zugriff auf /storage/emulated defekt:

Code: 
axolotl:/ $ ls /storage/emulated/
ls: /storage/emulated/: Permission denied

Interessant: Über den Dateimanager konnte ich eine apk (die noch von früher dort lag) erfolgreich installieren. Ich habe dann noch mit der Kamera Fotos gemacht. Diese schienen auf und ich konnte sie öffnen. Danach habe ich Android nochmals neu gestartet und kam an der Fehlermeldung "SHIFT Home keeps stopping" nicht mehr vorbei.

Nach einem Versuch das Problem per adb sideload <SHIFT6MQ>.zip zu behandeln war Android dann gar nicht mehr bootfähig und das Telefon schlug mir den besagten Factory Reset vor.

Nach dem Factory Reset funktionieren nun jedenfalls beide Systeme wie gewünscht! 🎉
 
Zuletzt bearbeitet:
  • Like
Reaktionen: amartinz
Ich möchte noch das Umschalten per Bootloader aktivieren.

Wenn Slot A aktiv ist, fehlen die Menüpunkte und der entsprechende Befehl schlägt fehl:

Code: 
$ fastboot getvar current-slot && fastboot oem enable-developer-mode
current-slot: a
Finished. Total time: 0.001s
FAILED (remote: 'unknown command')
fastboot: error: Command failed


Wenn Slot B aktiv ist, scheinen die Menüpunkte auf. Der entsprechende Befehl wird gefunden:

Code: 
$ fastboot getvar current-slot && fastboot oem enable-developer-mode
current-slot: b
Finished. Total time: 0.001s
OKAY [  0.000s]
Finished. Total time: 0.000s

Kurz: Ich kann zwar von Android (Slot B) zu pmOS (Slot A) schalten, aber nicht umgekehrt.
 
Boote mal pmOS und mach alle Bootloader Updates via fwupd.

Code: 
# Geräte listen und überprüfen, dass der Bootloader wohl aktualisierbar ist
fwupdmgr get-devices

# Nach Aktualisierungen suchen
fwupdmgr refresh

# Verfügbare Aktualisierungen anzeigen
fwupdmgr get-updates

# Aktualisierungen installieren
fwupdmgr update

Das Aktivieren des Entwicklermodus muss nicht per Bootloader gemacht werden, sondern das wird in der devinfo Partition abgespeichert und geladen.
Wenn es nicht angezeigt wird, ist der Bootloader zu alt, da das Feature erst ab einer gewissen Version von uns eingebaut wurde.
 
Hier die Ausgabe von fwupdmgr:

Code: 
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
WARNING: This package has not been validated, it may not work properly.
shift SHIFT SHIFT6mq
│
└─H2xxxxxxxxxx:
      Device ID:          caXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      Summary:            UFS device
      Current version:    03
      Vendor:             SKhynix (SCSI:SKhynix)
      Serial Number:      SKhynix
      GUIDs:              eXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX ← SCSI\VEN_SKhynix&DEV_H2xxxxxxxxxx
                          1XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX ← SCSI\VEN_SKhynix&DEV_H2xxxxxxxxxx&REV_03
      Device Flags:       • Internal device
                          • Updatable
Code: 
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
WARNING: This package has not been validated, it may not work properly.
Updating lvfs
Downloading…             [***************************************]
Successfully downloaded new metadata: 0 local devices supported
Code: 
WARNING: UEFI capsule updates not available or enabled in firmware setup
See https://github.com/fwupd/fwupd/wiki/PluginFlag:capsules-unsupported for more information.
WARNING: This package has not been validated, it may not work properly.
Devices with no available firmware updates:
 • H2xxxxxxxxxx
No updatable devices

Ist die Warnung bzgl Capsules relevant?
 
Übrigens bietet der Bootloader von Slot A zwei andere Optionen, deren Bedeutung ich nicht kenne:
Boot to FFBM und Boot to QMMI
 
check6 schrieb:
Ist die Warnung bzgl Capsules relevant?
Zum Vergrößern anklicken....
Nein, weil wir kein reines UEFI nutzen.

Mhm, der Bootloader taucht hier nicht auf.
Welche Version hat der Bootloader im Slot A?

Die 2 Boot Optionen wurden schon vor langer Zeit entfernt, sollte also eine richtig alte Version sein.

Du könntest sonst direkt den Bootloader von LVFS downloaden: https://fwupd.org/lvfs/devices/eco.shift.axolotl.abl.firmware (abl_5.0.20221224.cab)
Die Datei entpacken und das Image flashen: fastboot flash abl abl_5.0.20221224.img reboot bootloader

Danach sollte das Menü angezeigt werden und auch fwupdmgr get-devices sollte den Bootloader listen.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben Unten