MMI 3G größere Festplatte einbauen
Bevor das Thema "MMI 3G nachrüsten" zu unübersichtlich wird, mache ich lieber mal ein neues Thema auf ...
So, ich habe gestern mal auf verschiedenen Wegen versucht die Jukebox größer zu machen.
Zuerst habe ich den kompletten Dump von meiner originalen Festplatte auf die 320er gespielt. (byteweise unter Linux mit dd)
Die 320er Festplatte hat dann einwandfrei im 3G funktioniert.
Leider ist die 10GB Partition, in der ich auch die importierten Files (hexedit) gefunden habe, die 2. Partition und es folgen noch die 3., extended, 5. und 6. Partition.
Hier mal ein fdisk-Dump von der originalen Platte / der originalen Partitionstabelle:
Disk /dev/sdc: 40 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 * 1 3003 24121566 4d QNX4.x
/dev/sdc2 3004 4380 11052720 4e QNX4.x 2nd part
/dev/sdc3 4381 4486 843412 4f QNX4.x 3rd part
/dev/sdc4 4487 4864 3028252 5 Extended
/dev/sdc5 4487 4813 2618595 bb Boot Wizard Hid
Warning: Partition 5 does not end on cylinder boundary.
/dev/sdc6 4814 4820 48195 bb Boot Wizard Hid
Warning: Partition 6 does not end on cylinder boundary.
/dev/sdc7 4821 4864 345397 bb Boot Wizard Hid
Warning: Partition 7 does not end on cylinder boundary.
Da man die 2. Partition (in diesem Fall /dev/sdc2) nicht vergrössern kann, da direkt im Anschluss weitere Partitionen folgen, habe ich 2-7 gelöscht, die 2. größer gemacht (z.B. 256GB) und dann die übrigen dahinter so angelegt, wie sie von der Größe her waren.
Die originalen Partitionen habe ich vorher einzeln mit dd gedumpt und dann auf die jeweiligen Partitionen zurückgespielt.
Das 3G bootet einwandfrei, leider ist die Jukebox in der Quellenauswahl ausgegraut 
Ok, nächster Versuch war mit "diinit -h /dev/sdc2" ein neues, leeres QNX4-Filesystem auf /dev/sdc2 zu erzeugen.
Mounten konnte ich dieses frische Filesystem einwandfrei mit dem Linux QNX4 (readonly) Treiber - ganz im Gegensatz zu der originalen 2. Partition. Diese hat sich bisher hartnäckig gegen ein Mounten gewehrt.
Leider kein anderes Bild am 3G Eine kleinere (nur 20GB) 2. Partition habe ich in beiden Konstellationen auch ausprobiert. (hätte ja sein können, dass 256GB einfach zu viel für das arme, kleine 3G ist 
Hat aber leider auch keinen Unterschied gemacht.
Spasseshalber habe ich auch mal ein EXT2 Filesystem drauf gepackt. QNX kann eigentlich auch mit einem Linux EXT2 FS umgehen. Leider auch kein Erfolg.
Im Moment bin ich der Meinung, dass das originale QNX4 Filesystem abgewandelt wurde und wahrscheinlich auch noch eine bestimmte Datei im Filesystem dem 3G sagt, dass es eine gültige, funktionierende Jukebox-Partition/Filesystem zur Verfügung hat.
Ich befürchte daher, dass man sich wirklich die Mühe machen muss das Filesystem genauer zu verstehen, um die nötigen Anpassungen vorzunehmen.
Insbesondere müssten man mal schauen, ob bestimmte Verzeichniss-/File-Einträge für die Jukebox nötig sind.
So viel erst einmal dazu ... vielleicht findet sich hier ja noch jemand, der irgendetwas rausfindet ...
Kai
Beste Antwort im Thema
Achso ... Feedback ist natürlich auch durchaus erwünscht! (positives wie negatives)
Also bitte nach dem Test bitte einmal kurz ein paar Zeilen schreiben, das wäre wirklich super 
Ähnliche Themen
176 Antworten
Ich ziehe mir jetzt erst einmal ein QNX Neutrino und versuche das in einer virtuellen Maschine zum laufen zu bringen.
Es könnte sehr gut sein, dass es sich um ein QNX6 (Power Fail Safe) Filesystem handelt. (von dem, was ich heute gelesen habe, würde das von der Struktur her eher hinkommen)
Leider gibt es für dieses FS noch keine alternativen Treiber (z.B. für Linux). Mal sehen, ob man unter QNX selbst drauf zugreifen kann ...
Ich drücke die Daumen!!
Zitat:
Original geschrieben von kbankett
Im Moment bin ich der Meinung, dass das originale QNX4 Filesystem abgewandelt wurde und wahrscheinlich auch noch eine bestimmte Datei im Filesystem dem 3G sagt, dass es eine gültige, funktionierende Jukebox-Partition/Filesystem zur Verfügung hat.
Entweder das, oder die MMI Software enthält Code der die Größe der Partition prüft und bei falschen Werten den Betrieb verweigert.
Moin,
Zitat:
Disk /dev/sdc: 40 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 * 1 3003 24121566 4d QNX4.x
/dev/sdc2 3004 4380 11052720 4e QNX4.x 2nd part
/dev/sdc3 4381 4486 843412 4f QNX4.x 3rd part
/dev/sdc4 4487 4864 3028252 5 Extended
/dev/sdc5 4487 4813 2618595 bb Boot Wizard Hid
Warning: Partition 5 does not end on cylinder boundary.
/dev/sdc6 4814 4820 48195 bb Boot Wizard Hid
Warning: Partition 6 does not end on cylinder boundary.
/dev/sdc7 4821 4864 345397 bb Boot Wizard Hid
Warning: Partition 7 does not end on cylinder boundary.
Partition 1 enthält also die importierten Daten, oder? Wenn die o.g. Partitionierung die der Originalplatte ist, kann ich mir nicht vorstellen, dass Du das Layout einfach beliebig verändern kannst. Der Aufbau muss sicherlich so sein?!?
Was ich auch nicht ganz verstehe: Wieso möchtest Du sdc2 vergrößern, liegen die eigentlichen Daten nicht auf sdc1? Welche Daten befinden sich denn auf den übrigen Partitionen?
Spannendes Thema! :-)
Gruß
Krümel
PS: Wenn Du die Bootpartition erweitern willst, hast Du wahrscheinlich eh schlechte Karten!
Auf der HDD sind die Daten für die Navi und Jukebox vorhanden.
Ich hatte mal bei einem 3G die HDDs quer getauscht mit unterschiedlichen Nav-DB Ständen. Das eine hatte was von 5.0.5 drauf und die andere die 5.5.5.
Die Nav. DB wurde bei Unit 1 immer nur als 5.0.5 erkannt, obwohl die andre vorhanden war. Ich denke mal, dass auch noch viel in Flashspeicher drin steht.
Dieser ist leider nicht auf der HDD vorhanden. Meine Befürchtung ist, dass eben auch die Infos der Jukebox auf einem Flashspeicher liegen und sie nur 10GB verwalten kann. Also müsste man diesen neu programmieren - sage ich mal so als Volllaie , welcher ich auf diesem Gebiet wirklich bin.
Ja, was ich bisher so gelesen habe, scheint die Navi Datenbank mit dem internen Flash-Speicher verknüpft zu sein.
So wie es aussieht liegen die eigentlichen Datenfiles dann aber auf der ersten Partition, welche ca. 24GB gross ist. (stimmt natürlich nicht ganz, da 24GB = 1024 * 24KB, daher sind 24121566 Bytes natürlich 23556 KB = 23 GB - nur, fall sich jemand wundert ...)
Booten tut das 5F auch nicht von der Festplatte, sondern vom internen Flash Speicher. Wenn man die Platte komplett herausnimmt, dann funktioniert noch alles, bis auf Navi (hängt in der Initialisierung) und Medienplayer (erkennt keine Medien mehr - auch kein DVD-Laufwerk und keine SD-Karte).
Auf der 2. Partition liegt die Jukebox und ich kann mir wirklich nicht vorstellen, dass eine Funktion implementiert wurde, die die größe mit einem Wert im "Betriebssystem" vergleicht. Wenn das natürlich so sein sollte, dann müsste man eine originale Firmware patchen und den Wert dort ändern.
Ich glaube aber nicht wirklich dran ...
Ich habe nun erst einmal die 320GB Festplatte eingebaut und gleichzeitig einen Versuch gemacht. Die Partitionstabelle habe ich wie folgt verändert:
Disk /dev/sdd: 320 GB, 320070320640 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdd1 * 1 3003 24121566 4d QNX4.x
/dev/sdd2 3004 4380 11052720 4e QNX4.x 2nd part
/dev/sdd3 5757 5862 843412 4f QNX4.x 3rd part
/dev/sdd4 5863 6240 3028252 5 Extended
/dev/sdd5 5863 6189 2618595 bb Boot Wizard Hid
Warning: Partition 5 does not end on cylinder boundary.
/dev/sdd6 6190 6196 48195 bb Boot Wizard Hid
Warning: Partition 6 does not end on cylinder boundary.
/dev/sdd7 6197 6240 345397 bb Boot Wizard Hid
Warning: Partition 7 does not end on cylinder boundary.
Was auffällt, ist, dass ich die 2. Partition (/dev/sdd2) genauso gross wie original gemacht habe. (selbe Anzahl an Cylindern)
Die danach folgenden Partitionen habe ich um noch einmal die Größe der 2. Partition nach hinten geschoben, also eine Lücke gelassen.
Ziel dieses Versuches war zu testen, ob sich das Betriebssystem an der Partitionstabelle orientiert. Wenn es das nicht tun würde, dann sollte mit dieser Partitionstabelle irgendetwas nicht mehr funktionieren, weil es die Daten in den weiter nach hinten geschobenen Partitionen nicht mehr an der erwarteten Stelle finden würde.
Wie erwartet funtkioniert aber alles einwandfrei, was für mich heisst, dass es sich beim Auffinden der Daten nach der Partitionstabelle richtet.
Das ist schon mal sehr gut
Zentraler Ansatzpunkt ist jetzt definitiv das Filesystem in der 2. Partition. Wenn man weiss wie dieses funktioniert, dann kommt man 1. an die Filenamen / die Verzeichnisstruktur und 2. kann man dieses dann auch innerhalb einer Partition vergrößern.
Einfach die Partition vergrößern funktioniert nicht. Das Filesystem erwartet, basierend auf der Größe der Partition (deren Daten werden zuerst ausgelesen), an bestimmten Stellen bestimmte Dateisysteminformationen.
Beispiel: Bei einem größeren Filesystem wird eine größere Allocation-Tabelle (Belegungsinformationstabelle) verwendet. Wenn man die Partition größer macht, die Belegungstabelle aber nicht anpasst, dann läuft das Filesystem in einen Fehler.
hast du schon versucht, die 24GB NAV Partition ein zweites mal statt der Jukebox Partition (sdc2) zu kopieren. Nun müssten in der Jukebox die NAV Daten ersichtlich sein (zumindest die Folder) und 24GB gross sein.
Nein, habe ich noch nicht versucht.
Die Frage ist: Was möchtest du damit erreichen? Möchtest du die Navi-Dateien sehen/sichtbar machen oder den Mehrspeicherplatz durch nachfolgendes Löschen der Dateien nutzbar machen?
ich denke an den Mehrplatz, da ja eine Vergrösserung scheinbar nicht geht.
Hm, interessantes Thema - als ITler finde ich so etwas auch spannend ;-)
Es kann aber durchaus sein, das die Flash-Firmware eine kompatible Firmware für die Platte voraussetzt (wird bei manchen Speichersystemen aus Sicherheitsgründen gemacht). Dann hätte man mit einer Austauschplatte immer das nachsehen...
Ich setzt mich da auch mal ran wenn mein Dicker kommt :-) Das dauert aber noch bis Februar. Hast du eine Platte für extreme Temperaturbereiche? Eine normale HDD da reinzusetzen würde sowieso nicht lange heben...
LG,
Nico
Hallo,
@Eloya: Festplatte tauschen funktioniert ja schon, auch gegen eine größere. Nur kann eben der zusätzliche Platz nicht nutzbar gemacht werden.
@kbankett: Hast Du mal geschaut ob ein Dir bekanntes File mehrfach auf der Platte vorkommt? Das würde dann nämlich tatsächlich für das QNX6.x Filesystem mit seiner Failsafe-Funktion sprechen. Wenn ich es richtig verstanden habe werden Dateien, z.B. für einen Schreibzugriff, mehrfach auf der Platte gespeichert. Erst wenn die Schreiboperation abgeschlossen und verifiziert wurde, wird in einer mehr oder weniger atomaren Aktion in der File-Table umgeschaltet...
Viele Grüße,
Klayman
Das hatte ich mir auch durchgelesen, was man über QNX6 findet. Nein, so wie es scheint kommen die Informationen nicht mehrfach vor. (ich habe aber auch noch nicht wirklich intesiv gesucht)
Derzeit habe ich eine stinknormale 2.5" Samsung 320GB Platte eingebaut. Diese ist für den Betrieb bei 0-70°C spezifiziert. (wenn ich es richtig in Erinnerung habe)
Die Platte wird aber bestimmt auch mehr überleben. Und wenn sie stirbt - wat solls schon ... für 50-60 EUR bekommt man eine neue
An einem Auto ist das, bei dem Preis, fast noch das günstigste Teil 
Natürlich, wenn ich die Jukebox vergrössert bekomme, dann kommt eine SSD rein - warum aber schon vorher das Geld investieren, wenn man sich noch nicht sicher ist, dass es am Ende auch was wird.
Unter der Woche komme ich leider absolut nicht dazu daran weiter zu arbeiten. Heute war ich aber dann natürlich schon wieder fleissig.
Ich habe das QNX Neutrino erfolgreich in einer VM auf dem Notebook hier laufen. Die Parititonen kann ich unter QNX auch einwandfrei sehen.
Leider meint auch ONX (so out of the box), dass das FS fehlerhaft ist. Sowohl, wenn ich es als QNX4 versuche anzusprechen, als auch als QNX6. (sowohl fs-check, als auch mount)
So wie es ausschaut ist also wohl doch etwas an dem grundlegenden Datenformat verändert worden.
Der nächste logische Schritt wäre nun, eine Datei, die via 3G auf die Jukebox aufgespielt wurde, mal auf der Datenpartition wieder zu finden (die wirklichen Daten, nicht der Filename im Directory-Eintrag) und sich dann anzuschauen, wie diese dann über der Festplatte / in der Partition verteilt ist.
Also, wenn ich auf einfache Weise ein Filesystem "scrambeln" wollte, dann würde ich einfach einen Algorithmus in die Blockverwaltungsschicht einklinken, der die Berechnung der Blöcke einfach von linear auf etwas Anderes abändern würde.
So einer Verteilung könnte man auf dem Weg der Verfolgung der Datenfragmente über die Parition vielleicht auf die Schliche kommen.
Beispiel (rein zur Veranschaulichung konstruiert):
Nehmen wir an, dass normalerweise
Block 1 das Hauptverzeichnis enthält
Block 2 die 1. Datei
Block 3 die 2. Datei
Wenn man nun auf Blockebene durcheinanderwürfelt (natürlich nach einem reversiblen Schema), dann erhält man z.B. folgendes Ergebnis:
Block 1 die 2. Datei
Block 2 die 1. Datei
Block 3 das Hauptverzeichnis
(ich denke mal, dass das in diesem Beispiel verwendete Schema sehr einfach zu durchschauen ist - oder? )
Ansonsten sollte man, nachdem man die Dateifragmente lokalisiert hat, sich mal anschauen, wie die Verkettungen der einzelnen Fragmente im FS gelöst sind. Ein guter Startpunkt für so etwas ist natürlich immer der Eintrag in einer Inode (im Directory-Block), der sich ja einfach über den Filenamen finden lässt.
Dort sollte sich ein Verweis auf den 1. Datenblock der eigentlichen Datei finden.
Wenn die eigentlichen Nutzdaten verschlüsselt sein sollten (die Inodes sind definitiv nicht verschlüsselt, da sich die Filenamen im Klartext finden lassen), dann findet man das im nächsten Schritt (Suche nach den Fragmenten) auch sofort raus, da man dann noch nicht einmal den Anfang der Daten aus der Datei in der Partition finden wird. Wenn man die eigentlichen Daten also nicht finden kann, dann ist das erst einmal Ende der Fahnenstange. (dann wird das alles sehr viel komplizierter ...)
Demnächst in diesem Kino "Findet Kai die Datenfragmente - oder nicht?" 
Kai
Wegen Temperaturen und erschütterungen brauchst dir keine Sorgen machen.
Ich habe in 36 Mess Rechnern seit 10 Jahren erst 1 Festplatte wechseln es sind auch nur normale 2,5" Platten
Glaube mir wenn die Jedes Jahr für 3 Monate an den Polarkreis müssen, ist es kein leichtes leben. Jeden morgen
von -30 Grad auf lauschige 24 Grad Plus im Fahrerhaus. Und ständiege Vollbremsungen und anfahrversuche das rüttelt
ganz schön.
Also mach dir deswegen keinen Kopf
Gruß Messknecht
Zitat:
Original geschrieben von messknecht01
Wegen Temperaturen und erschütterungen brauchst dir keine Sorgen machen.
Ich habe in 36 Mess Rechnern seit 10 Jahren erst 1 Festplatte wechseln es sind auch nur normale 2,5" Platten
Glaube mir wenn die Jedes Jahr für 3 Monate an den Polarkreis müssen, ist es kein leichtes leben. Jeden morgen
von -30 Grad auf lauschige 24 Grad Plus im Fahrerhaus. Und ständiege Vollbremsungen und anfahrversuche das rüttelt
ganz schön.
Also mach dir deswegen keinen Kopf
Gruß Messknecht
Na, herzlichen Glückwunsch ;-)
Da habe ich andere Erfahrungen gemacht, sogar mit Disks im Ruhezustand. Aber andererseits - bei den Preisen, die für die Platten heutzutage aufgerufen werden ist es auch egal, wenn sie kürzer halten :-)
Bin mal auf mein Auto gespannt - das wäre auch ein Projekt, was ich gerne machen würde.
@kbankett: Hast du die Möglichkeit, von einer originalen Platte ein Image zu ziehen und das Image dann erst mal 1:1 auf eine größere zu bringen? Stehen dann alle Funktionen zur Verfügung? Wenn das zieht, dann fällt die Firmware schon mal aus *g*.
LG,
Nico