Partitionen und komplettes ShiftOS ab Bootloader wiederherstellen

Könnte technisch mit Fastboot und Fastbootd möglich sein, wenn du keine kritischen Partitionen gelöscht hast und es schaffst die Partitionen wieder an die richtige Stelle zu löten.

Problem:
Ich "lösche" eine Partition (bspw. weil ich mit LineageOS experimentieren). Die Partition ist leer, aber immernoch vorhanden.
Fastboot weiß also, wo die neuzuflashende Partition hingehört.

Du beschreibst, dass du alle Partitionen gelöscht hast als du mit PM experimentiert hast. Könnte mit fastbootd möglich sein diese wieder in position zu rücken und zu Reformatieren. Dafür müsstest du (von meinem Verständnis her) aber mindestens ein fastbootd-fähiges Recovery draufbügeln müssen.

Also Hand aufs Herz:

Du hast bisher auf denen Anfragen keine Antworten erhalten, weil dein Usercase bisher wohl noch nicht aufgetreten oder noch nicht gelöst wurde.

Also schick dein Gerät ein. Shift flashed dir (für ich glaube 23€+ Porto) mittels EDL die Firmware wieder drauf und fini.

Greetz

Edit: Falls du der Meinung bist, dass da manuell noch was deinerseits zu retten wäre hab ich dir mal (für die Einordnung, was du wo brauchst) ne Partitionstabelle (Terminal aus dem laufenden System und einmal noch mit BusyBox) vom 6mq angehängt, die ich mal vor grauer Vorzeit im Jahr 2021 gezogen habe. Vielleicht kannst du da was puzzelnderweise mit Anfangen 😉
 

Anhänge

Zuletzt bearbeitet:
Vielen Dank für die ausführlichen Tipps. Mit den Dateien bin ich derzeit noch ein bisschen überfordert.

Einschicken für eine professionelle Korrektur meines Systems wäre mir am liebsten. Da es mir aber aus logistischen Gründen derzeit nicht möglich ist, habe ich es noch ein bisschen weiter versucht.

Was ich bisher geschafft habe:

e/OS Recovery vom PC aus per Fastboot gestartet; Ich verwende dieses Recovery, weil es ADB bereitstellt (im Gegensatz zum originalen).

Dann habe ich statische Binaries von busybox sowie sgdisk gefunden (https://xdaforums.com/t/exe-static-...stdisk-photorec.3709380/page-31#post-89413183) und per "adb push" auf das Gerät geladen.

Irgendwas scheine ich dann mit sgdisk noch falsch zu machen. Ich kann zwar Partitionen anlegen und diese per MKFS formatieren, aber das System bleibt in einem "eigenartigen" Zustand:

Zuerst sehe ich in `cat /proc/partitions` ein paar neue Partitionen, aber sobald ich sie den Kernel neu einlesen lasse (`blockdev --rereadpt /dev/block/mmcblk0`) sind sie wieder weg.

Auf gut Glück habe ich trotzdem nochmal die Shift-Wiederherstellung aus dem Bootloader heraus versucht (`fastboot_flash.sh`), aber das Ergebnis bleibt das gleiche (Writing 'super' FAILED (remote: 'Partition not found'))
 
Super ist eine dynamische Partition. Sie hat (beim 6mq) eine Größe von etwa 12 GB und beinhaltet logische Partitionen (wie system, vendor, product). Diese können im regulären Bootloader-Modus nicht direkt geflasht werden, da sie keinen festen physischen Speicherplatz besitzen, sondern innerhalb der Super-Partition variabel verwaltet werden.
Aufgrund der Dateigröße und der notwendigen Kommunikation mit dem Logical Partition Manager lässt sich die Super-Partition (oder deren Inhalt) meist nicht über das klassische Bootloader-Interface (Fastboot) flashen.
Hierfür ist der fastbootd-Modus erforderlich. Dieser ist Teil des Recovery-Systems (oder eines fastbootd-fähigen Kernels). Nur in diesem Modus können die logischen Strukturen innerhalb von "Super" erkannt und beschrieben werden.
Du musst also in den fastbootd-Modus booten (oft über das Recovery erreichbar). Nur von dort aus kannst du ein Super-Image oder die darin enthaltenen logischen Partitionen installieren.

Greetz
 
Das hat meine KI (auch?) gesagt, aber auch wenn ich im e/OS recovery auf "Enter Fastboot" drücke erscheint die BCB-Fehlermeldung (E:Failed to clear BCB message: failed to open /dev/block ibootdevice/by-name/misc: No such file or directory) und das Gerät hängt sich auf.

Hast du die Möglichkeit, mir die Ausgabe von `sgdisk --print /dev/block/mmcblk0` zu senden? - bzw sind deine Grundpartitionen (boot_a/recovery_a/misc/super/userdata) in Originalzustand?
 
(E:Failed to clear BCB message: failed to open /dev/block ibootdevice/by-name/misc: No such file or directory) und das Gerät hängt sich auf.
Mein Case beschreibt das Vorgehen, wenn nicht die gesamte Systempartitur zerschossen ist. Was du mit deinem Gerät getan hast, kann ich nur mutmaßen und nicht nachvollziehen.
Ich weiß nicht, ob ich es dir schon mal vorgeschlagen habe: Einschicken wäre ne super Möglichkeit 😇.

Andererseits kannst du aktuell auch nicht mehr viel kaputt machen.
Du kannst mal überlegen ob du hiermit weiterkommst und Fastboot umgehst. Oder mal ein anderes Recovery, Stock oder LineageOS ausprobierst. In deinem Fall muss man jetzt anfangen über den Tellerrand zu schauen und Alternativen in Erwägung ziehen wenn du das alleine versuchen willst.

Was Emergency Download (das von mir verlinkte) angeht fehlt mir (und ich denke so ziemlich den meisten 6mq-Besitzern hier im Forum) aber die 6mq-Praxiserfahrung. Hab das vor Jahren mal mit nem Nokia 5 geschafft.

Hast du die Möglichkeit, mir die Ausgabe von `sgdisk --print /dev/block/mmcblk0` zu senden?
Nope, mein 6mq ist letztes Jahr mit nem Mainboarddefekt abgerauscht.

Das hat meine KI (auch?) gesagt
Juhu, mein Wissensstand ist auf einer Wellenlänge mit einer KI (oder die mit mir 🤔).

Greetz
 
  • Like
Reaktionen: check6
Nach einigen weiteren Stunden habe ich zumindest wieder ein funktionierendes fastbootD und Recovery.

Das Flashen per fastboot_flash.sh läuft durch (auch "super" wird nun geschrieben) und - mit meiner improvisierten Partitionstabelle - komme ich auch bei ShiftOS zumindest bis zur "smartphones can be timekillers" Warnung - und der Kreis wird Schritt-für-Schritt fertig blau umrandet. Dabei bleibt's dann allerdings auch.

Sicher ist die Partitionstabelle noch immer nicht ganz korrekt:

Code:
# ./sgdisk --print /dev/block/sda
Disk /dev/block/sda: 29765632 sectors, 113.5 GiB
Sector size (logical/physical): 4096/4096 bytes
Disk identifier (GUID): 5D2B2BA2-744C-06B7-565B-DEACCE4B0255
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 5
First usable sector is 6, last usable sector is 29765626
Partitions will be aligned on 256-sector boundaries
Total free space is 4090 sectors (16.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            4096           36863   128.0 MiB   8300  boot_a
   2           36864           69631   128.0 MiB   8300  boot_b
   3           69632           94207   96.0 MiB    8300  recovery_a
   4           94208          126975   128.0 MiB   8300  recovery_b
   5          126976          129023   8.0 MiB     8300  misc
   6          129024          129279   1024.0 KiB  8300  storsec_a
   7          129280          129535   1024.0 KiB  8300  storsec_b
   8          129536          131583   8.0 MiB     8300  dtbo_a
   9          131584          133631   8.0 MiB     8300  dtbo_b
  10          133632          133887   1024.0 KiB  8300  vbmeta_a
  11          133888          134143   1024.0 KiB  8300  vbmeta_b
  12          134144          134399   1024.0 KiB  8300  vbmeta_system_a
  13          134400          134655   1024.0 KiB  8300  vbmeta_vendor_a
  14          134656         6688255   25.0 GiB    8300  super
  15         6688256         6704639   64.0 MiB    8300  metadata
  16         6704640        29765626   88.0 GiB    8300  userdata

Ich frage mich ob "metadata" sowie manche andere nicht eigentich in "super" sein sollten.

Generell weiß ich nicht, welche Partitionen benötigt werden und ob sie an der richtigen Stelle und der richtigen Reihenfolge sind.
Vielleicht kann mir ein motivierter Nutzer die Partitionsangaben eines unveränderten Shift6mq zukommen lassen?

Der Ablauf dazu wäre (mit Telefon verbunden und im Bootloader-Modus):


Code:
        cd /tmp

        # eOS RECOVERY STARTEN
        # Download via https://images.ecloud.global/community/axolotl/
        wget https://images.ecloud.global/community/axolotl/IMG-e-3.3-a15-20251213556761-community-axolotl.zip
        # Entpacken
        7z x IMG-e-3.3-a15-20251213556761-community-axolotl.zip
        # Starten
        fastboot boot ./recovery.img

        # PER ADB VERBINDEN
        # Download via https://xdaforums.com/t/exe-static-linux-binaries-for-arm-android-cryptsetup-encfs-f2fs-tools-testdisk-photorec.3709380/page-31 :
        wget -O sgdisk64.zip https://xdaforums.com/attachments/sgdisk64-zip.6082730/
        # Entpacken
        7z x sgdisk64.zip
        # Zu Telefon laden
        adb push sgdisk64 /tmp/
        # Verbinden
        adb shell

        # PARTITIONEN AUSGEBEN LASSEN
        chmod +x /tmp/sgdisk64
        /tmp/sgdisk64 --print /dev/block/sda

=> Diese Ausgabe wäre interessant zu haben.



Was ist mit dem Shift Recovery? Andere können einen anderen Funktionsumfang haben.

Das von Shift scheint kein ADB zu bieten und ohne ADB könnte ich kein sgdisk bzw mkfs ausführen - daher das von e/OS (basierend auf TWRP?).

Einschicken wäre ne super Möglichkeit 😇.

Ist leider nicht so einfach möglich - anderer Kontinent.
 
Von deinen zerschossenen Partitionen verstehe "nur Bahnhof", frage mich aber die ganze Zeit beim mitlesen, warum das nicht mit dem UB-ports oder Iodé-Installer klappen sollte. Immerhin wir dein 6mq ja per USB vom PC erkannt.
 
warum das nicht mit dem UB-ports oder Iodé-Installer klappen sollte

Generell scheint es so zu sein, dass alle Installer die Partitionstabelle in Ruhe lassen und immer einfach die vorhandenen Tabellen nutzen - also nur die bereits vorhandenen Partitionen mit den Inhalten aus ihren respektiven Images überschreiben.

Siehe dazu beispielsweise die UBports-Definitionsdatei für axolotl:


Solange die Tabelle falsch ist, wird jeder Installer scheitern.

Soweit zumindest mein Verständnis bisher.

Daher meine Annahme, dass das Einzige was fehlt eine korrekte (Werk-)Partitionstabelle ist - abzurufen von einem beliebigen Shift6mq über die oben genannten Umwege - aber natürlich mit ~30 Minuten Zeitaufwand verbunden.