Hey, bitte registriere dich, um alle Funktionen nutzen zu können!

Mach's gut, CyanogenMod. Hallo LineageOS. ♥ Unsere Community freut sich auf die neue Ära.

Wie soll ich meine Frage im LineageOS Forum posten?


Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
[LineageOS] Wileyfox Swift - ADB Sideload Fehler 7
#1
Hallo,

ich bin dabei, ein Wileyfox Swift von Android 7.1.2 auf LOS 16 zu bringen.

Nur zur Info, wenn man nicht von CM, sondern vom Android migriert, muss man sich an diese Anleitung halten:
https://www.usp-forum.de/threads/erfahru...os.138591/


Bootloader entsperren ging unproblematisch.

Nach der Installation des Recovery TWRP 3.1.1.0 (die aktuelle) bootete ein altes Recovery.
???
Inzwischen bootet das TWRP, beim ADB sideload erhalte ich aber den Fehler 7.

Im Fenster steht oben in rot:
"/system "konnte nicht eingehängt werden (no such device).

Gehe ich ins Menu "Einhängen", ist die Box von "System-Partition schreibgeschützt einhängen" nicht angeixt.

Im fastboot-Modus habe ich "about the phone" gewählt.

LK-Version: crackling-13-ge86e772
OEM unlocked: true
Security fuse: false

Wenn ich nun entsprechend der Anleitung zu" Löschen -> Erweitertes Löschen" gehe und Cache und System wähle und Löschen bestätige, erhalte ich die Meldungen:

"/system "konnte nicht eingehängt werden (no such device)
E:Unable to wipe "/system" - unknown file system "squasfs"
/System kann nicht gelöscht werden

Hm - ich habe bisher zwei Swifts zu LOS gebracht, das hatte ich bisher nicht.
Keine Ahnung, welchen Blödsinn ich gemacht haben könnte.

Also müsste die /system-Partition in ein anderes Format formatiert werden?


Gruß,
Wolfgang
Antworten
#2
Der Fehler 7 weist auf ein veraltetes oder fehlerhaftes TWRP hin, welches das installierte System nicht erkennt.

Bei TWRP wäre 3.3.1.0 aktuell : https://eu.dl.twrp.me/crackling/

Tippfehler?

Wenn Tippfehler: einfach mal eine ältere Version von TWRp flashen und dann die neuste drüber.

Gruß
Antworten
#3
Zitat: " ... Hier am besten sofort alles an Partitionen erst formatieren, ..."

Auf Geräten mit wenig Flashspeicher nutzt Android gerne mal squashfs auf der SystemPartition. Das mag CM und LOS und TWRP gar nicht! Du musst die Systempartition also nicht löschen sondern mit ext3/4 formatieren.
Eventuell das gleiche auch mit der Datenpartition?
Am besten mal ins TWRP booten. Dann ins Terminal gehen und dort mit "mount" die Partitionen anzeigen lassen. Das ganze dann als Foto hier Posten.

G900F mit LOS16
Antworten
#4
Hallo, miteinander,

@ reset: Wie beschrieben, ist es TWRP 3.1.1.0

@ : Anbei drei Bilder.

"Mount" ist die Ausgabe an besagtem Handy.

Ich bin in TWRP über "Löschen - > Erweitertes Löschen", Checkbox System, "Dateisystem reparieren oder ändern" gegangen.
Hier die beiden Ausgaben, wf_a ist das vom Handy, um das es geht.
Wf_w ist vom erfolgreich umgestellten Handy.

Ich habe mal hierhin geschaut:

https://www.droidwiki.org/wiki/Partitionen

Code:
# adb shell cat /proc/emmc
cat: can't open '/proc/emmc': No such file or directory
# adb shell cat /proc/mtd
cat: can't open '/proc/mtd': No such file or directory
# adb shell cat /proc/partitions
major minor  #blocks  name

179        0   15267840 mmcblk0
179        1        512 mmcblk0p1
179        2        512 mmcblk0p2
179        3       1024 mmcblk0p3
179        4       1024 mmcblk0p4
179        5        512 mmcblk0p5
179        6        512 mmcblk0p6
179        7        512 mmcblk0p7
179        8        512 mmcblk0p8
179        9        512 mmcblk0p9
179       10        512 mmcblk0p10
179       11          4 mmcblk0p11
179       12       1536 mmcblk0p12
179       13       1536 mmcblk0p13
179       14       1024 mmcblk0p14
179       15          1 mmcblk0p15
179       16          8 mmcblk0p16
179       17      10240 mmcblk0p17
179       18        512 mmcblk0p18
179       19      65536 mmcblk0p19
179       20         32 mmcblk0p20
179       21      65536 mmcblk0p21
179       22       1536 mmcblk0p22
179       23         16 mmcblk0p23
179       24      32768 mmcblk0p24
179       25    1572864 mmcblk0p25
179       26      32768 mmcblk0p26
179       27      65536 mmcblk0p27
179       28      32768 mmcblk0p28
179       29     153600 mmcblk0p29
179       30        512 mmcblk0p30
179       31   12983791 mmcblk0p31
179       32       4096 mmcblk0rpmb
#


Angehängte Dateien Thumbnail(s)
           
Antworten
#5
So,
das Verbinden per adb mit dem funktionierendem Handy ging erst nach einem Reboot des Rechners.   :-(

Code:
# adb shell cat /proc/partitions
major minor  #blocks  name

179        0   15267840 mmcblk0
179        1        512 mmcblk0p1
179        2        512 mmcblk0p2
179        3       1024 mmcblk0p3
179        4       1024 mmcblk0p4
179        5        512 mmcblk0p5
179        6        512 mmcblk0p6
179        7        512 mmcblk0p7
179        8        512 mmcblk0p8
179        9        512 mmcblk0p9
179       10        512 mmcblk0p10
179       11          4 mmcblk0p11
179       12       1536 mmcblk0p12
179       13       1536 mmcblk0p13
179       14       1024 mmcblk0p14
179       15          1 mmcblk0p15
179       16          8 mmcblk0p16
179       17      10240 mmcblk0p17
179       18        512 mmcblk0p18
179       19      65536 mmcblk0p19
179       20         32 mmcblk0p20
179       21      65536 mmcblk0p21
179       22       1536 mmcblk0p22
179       23         16 mmcblk0p23
179       24      32768 mmcblk0p24
179       25    1572864 mmcblk0p25
179       26      32768 mmcblk0p26
179       27      65536 mmcblk0p27
179       28      32768 mmcblk0p28
179       29     153600 mmcblk0p29
179       30        512 mmcblk0p30
179       31   12983791 mmcblk0p31
179       32       4096 mmcblk0rpmb
179       64   62521344 mmcblk1
179       65   62520320 mmcblk1p1
#
Antworten
#6
So,
Habe beim funktionierendem Handy adb shell mount eingegeben:

Code:
# adb shell mount
rootfs on / type rootfs (rw,seclabel)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=953988k,nr_inodes=238497,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,seclabel,relatime,size=953988k,nr_inodes=238497)
pstore on /sys/fs/pstore type pstore (rw,seclabel,relatime)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
/dev/block/mmcblk0p31 on /data type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/mmcblk0p31 on /sdcard type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/mmcblk0p29 on /cache type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/mmcblk1p1 on /sdcard1 type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
#

So,
hier die Ausgabe auf dem Problem-Swift:

Code:
# adb shell mount
rootfs on / type rootfs (rw,seclabel)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,size=953988k,nr_inodes=238497,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,seclabel,relatime,size=953988k,nr_inodes=238497)
pstore on /sys/fs/pstore type pstore (rw,seclabel,relatime)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
adb on /dev/usb-ffs/adb type functionfs (rw,relatime)
/dev/block/mmcblk0p29 on /cache type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/mmcblk0p31 on /data type ext4 (rw,seclabel,relatime,data=ordered)
/dev/block/mmcblk0p31 on /sdcard type ext4 (rw,seclabel,relatime,data=ordered)
#
Antworten
#7
OK. Jetzt musst Du herauskriegen welche Partition die Systempartition ist.
Auf dem funktionierenden Gerät im LOS im Terminal also sowas wie

ls -al /dev/block/platform/msm_sdcc.1/by-name

Da müsste dann so etwas herauskommen

lrwxrwxrwx root root 2014-01-20 11:29 aboot -> /dev/block/mmcblk0p6 lrwxrwxrwx root root 2014-01-20 11:29 apnhlos -> /dev/block/mmcblk0p1 lrwxrwxrwx root root 2014-01-20 11:29 backup -> /dev/block/mmcblk0p17 lrwxrwxrwx root root 2014-01-20 11:29 boot -> /dev/block/mmcblk0p14 lrwxrwxrwx root root 2014-01-20 11:29 hidden -> /dev/block/mmcblk0p25 lrwxrwxrwx root root 2014-01-20 11:29 modem -> /dev/block/mmcblk0p2 lrwxrwxrwx root root 2014-01-20 11:29 persdata -> /dev/block/mmcblk0p22 lrwxrwxrwx root root 2014-01-20 11:29 persist -> /dev/block/mmcblk0p21 lrwxrwxrwx root root 2014-01-20 11:29 recovery -> /dev/block/mmcblk0p15 lrwxrwxrwx root root 2014-01-20 11:29 system -> /dev/block/mmcblk0p23


Und das dann hier posten.

G900F mit LOS16
Antworten
#8
Leider nein:
ls: /dev/.... : No such file or directory

Ich habe dann hier geschaut:
[/url][url=https://android.stackexchange.com/questions/5232/how-can-i-view-the-android-internal-partition-table]https://android.stackexchange.com/questions/5232/how-can-i-view-the-android-internal-partition-table


parted gibt es nicht.

Was geht ist busybox fdisk  - aber nicht mit dem Devicenamen:

busybox fdisk -l /dev/block/sda:
fdisk: can't open /dev/block/sda: No such file or directory.

Erfolgreich war ls -la /dev/block/bootdevice/by-name.
Ich würde sagen, Partionsnummer 25 ist die richtige.

Ich reiche zur Sicherheit ein paar Bilder nach.
WF_Bootdevice_[1-4] sind vom funktionierendem Swift, WF_A_Bootdevice vom problematischen.

Ich glaube inzwischen zu wissen, welchen Blödsinn ich gemacht hatte:
Ich vermute, dass ich beim Flashen des Recoverys vergessen habe, das Ziel zu benennen.
Es gab eine Meldung, dass das Ziel kein Recovery wäre.
Vermutlich hatte ich "fastboot flash $TWRP.img" eingegeben.   :-(

Wie sagte vor ein paar Jahren einer unserer ITs?
"Der Weg vom SuperUser zum SuperLooser ist manchmal ein kurzer."


Angehängte Dateien Thumbnail(s)
                   
Antworten
#9
Ja. Aber die 0p25 auf dem nicht funktionierenden ist aber viel zu klein (128MB) für eine Systempartition?
Gucke mal auf dem funktionierenden Gerät wie groß die dort ist (wieder ins Terminal, dann z.B. "df").

Wenn die Partition auf dem funktionierenden Gerät tatsächlich größer ist, wirst Du vermutlich erst das originale CM installieren müssen.


G900F mit LOS16
Antworten
#10
df bringt glaube ich, keine Erkenntnisse, Bilder vom funktionierendem Swift unten.

Partition 31 scheint /data zu sein.
Ich habe über "Löschen -> Erweitertes Löschen" die Größen von /system und /data anzeigen lassen.
/system ist also 1511 MB groß und /data 12352 MB.

Das funktionierende Swift:

adb shell cat /proc/partitions
major minor  #blocks  name
...
 179       25    1572864 mmcblk0p25
...
 179       31   12983791 mmcblk0p31
...

Bei dem defekten Swift sieht es genauso aus:

# adb shell cat /proc/partitions
major minor  #blocks  name
...
 179       25    1572864 mmcblk0p25
...
 179       31   12983791 mmcblk0p31
...

Hmm ...blocks sind das nicht Blöcke zu 1024 Byte?


Angehängte Dateien Thumbnail(s)
           
Antworten



Möglicherweise verwandte Themen...
Thema Verfasser Antworten Ansichten Letzter Beitrag
  Wileyfox Swift jetzt offizielles LOS 17.1 verfügbar uwe75 0 980 04.06.2020, 08:05
Letzter Beitrag: uwe75
  (Gelöst) Bootloop Problem mit LineageOS14 auf Wileyfox Swift NonKon 10 5.560 27.10.2019, 14:19
Letzter Beitrag: Ronnsn
  Wileyfox Swift mit CM 12.1.1 - Installation wie von Android 7.x wowi63 0 1.024 27.07.2019, 17:40
Letzter Beitrag: wowi63
  Wileyfox Swift - Tastatur unter LOS 16.x stürtzt regelmäßig ab? uwe75 1 1.049 24.07.2019, 08:39
Letzter Beitrag: wowi63
  [LineageOS] Xiaomi Mi6 & TWRP: ZIP-Fehler nachtpult 1 1.058 22.07.2019, 09:14
Letzter Beitrag: nachtpult

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste