[abgeschlossen] Entwurf: IDE Menü

[seife]

Stimmt. Ich glaube ich hatte das in "alten" (pre-newmake) dm500-Images bei mir drin oder so. Da war das nötig (und einfacher, als den Link ins Makefile zu basteln

[dbt]

Weil /var zuerst gemountet werden muss hat sich ein Link auf /etc/fstab von /var/etc/fstab bisher als wackelig erwiesen, ausserdem macht es sich gut wenn eine unveränderbare Variante vorliegt, könnte ja sein, dass ein Dösbaddel die mal ändert und dann ende mit Booten. Man weiß ja nie. Des Menü sorgt übrigens dafür, dass in Abhängigkeit vom Filesystem immer die nutzbare fstab verwendet und erstellt wird. Sollte also jemand bei yadd oder jffs2 auf die Idee kommen, in /var/etc eine fstab zu erstellen, wird sie gekillt. Dementsprechend habe ich das im make auch so berücksichtigt.

[rhabarber1848]

Sollte also jemand bei yadd oder jffs2 auf die Idee kommen, in /var/etc eine fstab zu erstellen, wird sie gekillt

Gute Idee

[micha-bbg]

EDIT: Geht glaube ich nicht, ohne /etc/fstab kann /var in
einem Squashfs-Image nicht gemountet werden...

Wie wäre es in der rcS mit
mount -t proc proc /proc
mount -t tmpfs tmpfs /tmp
mount -t jffs2 /dev/mtdblock/3 /var
statt mount -a? Dann klappt es auch mit dem fstab-Link in /etc. Mache ich schon seit geraumer Zeit so, keine Probleme.

Zum IDE-Menü:

Ich hab ein IDE-Interface von linux@dbox2.net, folgende Probleme (Platte und MMC waren schon formatiert, Org. CVS-Image):

• Im ersten Menü werden die Plattengröße und MMC-Größe falsch angezeigt. (Platte 80GB - Anzeige 257MB, MMC 1GB - Anzeige 1MB)
• Mounten geht auch nicht, wenn ich die Einträge von Hand in die /var/etc/fstab mache (wie ich es vorher hatte) funktioniert alles, logisch.

Falls die Größenangeben unter "hda (Master)" bzw. "MMC" den noch freien Speicherplatz darstellen sollen, dann sind diese Anzeigen korrekt.

Wenn ich es geschafft habe, die Patte leer zu bekommen werde ich mal versuchen in der Box zu Partitionieren / Formatieren. Vielleicht läuft dann ja alles korrekt.

MfG Micha

[dwilx]

Da war doch mal der Hinweis mit dem Busybox-Fdisk, damit wird mmc falsch ausgewertet.
http://forum.tuxbox-cvs.sourceforge.net ... 63#p368963

[rhabarber1848]

Wie wäre es in der rcS mit
mount -t proc proc /proc
mount -t tmpfs tmpfs /tmp
mount -t jffs2 /dev/mtdblock/3 /var
statt mount -a? Dann klappt es auch mit dem fstab-Link in /etc. Mache ich schon seit geraumer Zeit so, keine Probleme.

+1
Dazu muss rcS aber in Abhängigkeit des Dateisystems erstellt
werden, da /dev/mtdblock/3 nur in Squashfs-Images /var ist.
Es gibt bereits m4-Patches für rcS, die hier einfließen könnten.

[micha-bbg]

Da war doch mal der Hinweis mit dem Busybox-Fdisk, damit wird mmc falsch ausgewertet.
http://www.dreambox-fan.de/forum/viewto ... 63#p368963

Du hast Recht, den Hinweis gab es sogar hier vor ein paar Tagen:

Baut bitte, wenn möglich die originale fdisk version ein. Für HDD geht die bb-Version, aber für mmc gehts damit defintiv in die Hose.

Hatte ich auch gelesen, aber falsch verstanden. originale fdisk version hieß für mich: Nichts ändern, das Original so lassen…

Werde ich heute Abend mal testen.

MfG Micha

[micha-bbg]

Dazu muss rcS aber in Abhängigkeit des Dateisystems erstellt
werden, da /dev/mtdblock/3 nur in Squashfs-Images /var ist.
Es gibt bereits m4-Patches für rcS, die hier einfließen könnten.

Das hatte ich nicht bedacht, baue ja nur Squashfs-Images für mich.

MfG Micha

[rhabarber1848]

Das hatte ich nicht bedacht, baue ja nur Squashfs-Images für mich.

Das zu realisieren ist absolut im Bereich des Möglichen.
Wir sollten mal eine To-Do-Liste für die Erstellung
der rcS via m4 erstellen, es gab da auch mal was
in Bezug zur verwendeten Kernel-Version. Es macht
keinen Sinn, in rcS Shell-Befehle in Abhängigkeit
der Kernel-Version auszuführen, dort sollten nur die
Befehle drin sein, die zum Image passen. Neben
der Kernel-Version kann dabei problemlos auch nach
dem jeweiligen Imagetyp unterschieden werden.

EDIT: rcS.m4-Patch:
http://forum.tuxbox-cvs.sourceforge.net ... 14#p368814

[rhabarber1848]

Dazu muss rcS aber in Abhängigkeit des Dateisystems erstellt
werden, da /dev/mtdblock/3 nur in Squashfs-Images /var ist.

Es gibt schon Code dazu in cdk/make/flashable-dirs.mk:

Code: Alles auswählen

if BOXTYPE_IPBOX
VAR_MOUNT_ENTRY=/dev/mtdblock/1
endif
if BOXTYPE_DBOX2
VAR_MOUNT_ENTRY=/dev/mtdblock/3
endif

[micha-bbg]

Wir sollten mal eine To-Do-Liste für die Erstellung der rcS via m4 erstellen, es gab da auch mal was in Bezug zur verwendeten Kernel-Version. Es macht keinen Sinn, in rcS Shell-Befehle in Abhängigkeit der Kernel-Version auszuführen, dort sollten nur die Befehle drin sein, die zum Image passen. Neben der Kernel-Version kann dabei problemlos auch nach dem jeweiligen Imagetyp unterschieden werden.

Gute Idee. Mein Vorschlag entspricht dem was du oben geschrieben hast. Im Prinzip habe ich ja so bei mir, nur dumm wenn im CVS was geändert wird - dann geht die Sucherei los...

MfG Micha

[micha-bbg]

Baut bitte, wenn möglich die originale fdisk version ein. Für HDD geht die bb-Version, aber für mmc gehts damit defintiv in die Hose.

Hatte ich auch gelesen, aber falsch verstanden. originale fdisk version hieß für mich: Nichts ändern, das Original so lassen…
Werde ich heute Abend mal testen.

Originale fdisk habe ich jetzt drin, die MMC-Anzeige ist O.K., die von der HDD immer noch nicht.
Hab recht lange nach einem Fehler gesucht, dabei ist es so einfach: Die Funktionen zum Größe ermitteln in der drive_setup.cpp verwenden alle den Datentyp unsigned long, dessen Wertebereich geht ja nur bis 4294967295, also gut 4GB!
Ein paar Gedanken hab ich mir auch schon gemacht: Am einfachsten ist es natürlich, den Datentyp long long zu verwenden, aber da mehrere Funktionen für alle Werte (size, heads, zylinders, sectors) verwendet werden müssten ja alle Werte und Funktionen auf long long umgestellt werden. Mal sehen, was es noch für Möglichkeiten gibt,

MfG Micha

[micha-bbg]

Zum letzten Mal vor dem Schlafen gehen. Ich hab einen Vorschlag, wie das Anzeigeproblem gelöst werden könnte (wenn es denn auch bei Anderen auftritt)
Der Funktion getFileEntryLong eine Info mitgeben wenn die Diskgröße abgefragt wird und falls es so ist, dann den Rückgabewert durch 1024 teilen. Jetzt muss ich nur noch die Umwandlung in einen String zur Anzeige gesondert ausführen. Hab ich gerade getestet - funktioniert erst einmal.

MfG Micha

[dbt]

Ich hatte fürs Testen nur einige ausgediente 1 und 3 GB Platten, die noch nicht mal Temperatursensoren haben , da werden bei mir korrekte Werte angezeigt. Mehr hatte ich da nicht gebraucht, na gut muss ich mir wohl oder übel irgendwie eine Platte herzaubern, aber ich kann die nicht einfach irgendwo rausbauen, weil die gebraucht werden, aber das geht dann schon irgendwie.
PS: geht die Temperaturanzeige bei Euch?

getFileEntryLong eine Info mitgeben wenn die Diskgröße abgefragt wird und falls es so ist, dann den Rückgabewert durch 1024 teilen. Jetzt muss ich nur noch die Umwandlung in einen String zur Anzeige gesondert ausführen.

Dann gleich eine fertige Funktion die den passenden Wert zurückgibt. Basiert ja sowieso auf getFileEntryString.

Empirischen Beobachtungen zu Folge scheinen die Größen-Ausgaben vom mmc-Treiber schon nicht zu stimmen. Die init-Ausgabe vom mmc2 zeigt genau das, was BB-fdisk für mmc abietet. Die Original-fdisk Version macht dann scheinbar irgendwas ganz anderes (brauchbares) draus Evtl. kann jemand das genauer unter die Lupe nehmen.

Wir sollten mal eine To-Do-Liste für die Erstellung der rcS via m4 erstellen, es gab da auch mal was in Bezug zur verwendeten Kernel-Version. Es macht keinen Sinn, in rcS Shell-Befehle in Abhängigkeit der Kernel-Version auszuführen, dort sollten nur die Befehle drin sein, die zum Image passen. Neben der Kernel-Version kann dabei problemlos auch nach dem jeweiligen Imagetyp unterschieden werden.

Evtl. sollte man sich vorher drauf einigen, wie das mal ausshehen soll. Die Vorgaben sind soweit erstmal gegeben und es gibt bereits diverse Patches. Wäre es dann nicht sinnvoll, so wie ich es anfangs gemacht habe, getrennte Patches zu haben, also einen fürs cdk (make/rcs/fstab usw.) und einen für Neutrino, dann braucht man sich nur um eine Sache zu kümmern.
@rhabarber1848: Hast du zufällig die Zeit dafür?

[seife]

Naja. Man sollte schon 64 bit für File / Diskgrössen benutzen, sonst ist bei 4 TB wieder schluss (und das ist nich mehr soooo abwegig). Also "long long" ist da schon angemessen.

[rhabarber1848]

Wir sollten mal eine To-Do-Liste für die Erstellung der rcS via m4 erstellen

Evtl. sollte man sich vorher drauf einigen, wie das mal aussehen soll.[...]
@rhabarber1848: Hast du zufällig die Zeit dafür?

Ja, ich würde das gerne übernehmen.
Allerdings schaffe ich heute nur die To-Do-Liste in einem neuen
Thread zu erstellen, wo auch die bisherigen Ideen versammelt
sein werden. Ihr könnt Euch dann übers Wochenende darüber
den Kopf zerbrechen, ich komme erst nächste Woche wieder
dazu, mich damit zu beschäftigen.

PS: Die To-Do-Liste

[rhabarber1848]

@dbt: Wie machst Du den umount für die HDD/MMC-Partitionen beim
Herunterfahren der Box? In cdk/root/etc/init.d/halt steht das drin:

Code: Alles auswählen

mount | grep /hdd >/dev/null && umount /hdd

[dbt]

Da hab ich noch garnichts gemacht, eine Liste sollte man aber über mount abrufen können damit man alle mounts erwischt die weg müssen. Es gibt dann sicher mehr als nur /hdd. Das sollte man schon beachten.

Edit:
Andererseits habe ich deswegen noch keine Probleme bemerkt und so wie's aussieht wird das wohl für hdd-Partitionen automatisch erledigt.

Naja. Man sollte schon 64 bit für File / Diskgrössen benutzen, sonst ist bei 4 TB wieder schluss (und das ist nich mehr soooo abwegig). Also "long long" ist da schon angemessen.

Hast recht, TB-Platten könnte es schon geben , Ok, werds dann berücksichtigen und umstellen.

[micha-bbg]

Naja. Man sollte schon 64 bit für File / Diskgrössen benutzen, sonst ist bei 4 TB wieder schluss (und das ist nich mehr soooo abwegig). Also "long long" ist da schon angemessen.

Dann gleich eine fertige Funktion die den passenden Wert zurückgibt. Basiert ja sowieso auf getFileEntryString.

Stimmt schon, war doch nur mal ein Test.

PS: geht die Temperaturanzeige bei Euch?

Gar nicht.

So wie es getHddTemp macht:

Code: Alles auswählen

/ # hddtemp -n -w -q /proc/ide/ide0/hda
ERROR: /proc/ide/ide0/hda: can't determine bus type (or this bus type is unknown)

So geht es:

Code: Alles auswählen

/ # hddtemp -n -w -q /dev/ide/host0/bus0/target0/lun0/disc
44

Empirischen Beobachtungen zu Folge scheinen die Größen-Ausgaben vom mmc-Treiber schon nicht zu stimmen. Die init-Ausgabe vom mmc2 zeigt genau das, was BB-fdisk für mmc abietet. Die Original-fdisk Version macht dann scheinbar irgendwas ganz anderes (brauchbares) draus Evtl. kann jemand das genauer unter die Lupe nehmen.

Ich kann nichts versprechen, bin nicht der absolute "Held" in C, aber wenn ich am Wochenende Zeit habe versuche ich mal dahinter zu kommen.

Zur MMC noch:
Mounten geht immer noch nicht - kann das damit zusammenhängen, das sie als "Modell unbekannt" erkannt bzw. nicht erkannt wird?
Größenangaben sind i.o., wenn ich sie von Hand in die fstab eintrage funktioniert es auch.

MfG Micha

[dbt]

Soo, hab mir ne HD organisiert.
Danke, Temperatur geht jetzt, hatte ein falsches Element angegeben.
Wegen der Speicheranzeige liegts woanders, aber das mach ich grade noch.

Zur MMC noch:
Mounten geht immer noch nicht - kann das damit zusammenhängen, das sie als "Modell unbekannt" erkannt bzw. nicht erkannt wird?
Größenangaben sind i.o., wenn ich sie von Hand in die fstab eintrage funktioniert es auch.

Damit hat das nichts zu tun. Das HDD-Modell lässt sich locker auslesen, aber für MMC hab ich an der Stelle ja keine Daten, und habe das offen gelasssen. Man könnte das sicher irgendwo auslesen, aber ich habe da bisher nichts unternommen. Wenn jemand dafür eine Funktion hat, um den MMC-Typ auszulesen, kann man die sicher einbauen. Das müsste irgendwie mit idProduct was zu tun haben. Ist aber im Moment nicht so wichtig.
Wie gehst du beim Mounten vor? Formatierst du? Was sagt den das Log beim Mounten?
Ich hab grad mal ein MMC komplett mit vfat formatiert und partitioniert, mounten hat ohne Probleme geklappt.

Code: Alles auswählen

...
Command (m for help): The partition table has been altered!

Calling ioctl() to re-read partition table.

 mmc/disc0/disc: p1

 mmc/disc0/disc: p1

Syncing disks.

[drive setup] formating...

Using /lib/modules/2.4.37.2-dbox2/kernel/fs/vfat/vfat.o

[drive setup] load modul vfat...ok

mkfs.vfat 3.0.3 (18 May 2009)

[drive setup] checking filesystem...

[drive setup] mounting...

[drive setup] mount /dev/mmc/disc0/part1...ok

[drive setup] partitions mounted...

[neutrino] no file /var/tuxbox/config/formating.end was found
...

[micha-bbg]

Wie gehst du beim Mounten vor? Formatierst du? Was sagt den das Log beim Mounten?
Ich hab grad mal ein MMC komplett mit vfat formatiert und partitioniert, mounten hat ohne Probleme geklappt.

War von vornherein mit ext2 formatiert, sollte ja aber egal sein. Ich hab mich wohl nicht ganz korrekt ausgedrückt, mounten klappt erst mal schon.

Code: Alles auswählen

[drive setup] mount /dev/mmc/disc0/part1...ok

Es wird aber kein Eintrag in der fstab erstellt wenn noch keiner existiert, auch nicht nicht wenn ich "Übernehmen" drücke. Bzw. wenn ich den fstab Eintrag per Hand erstelle und später irgendwann "Übernehmen" drücke wird der fstab Eintrag wieder gelöscht - auch bei vorhandener und gemounteter MMC.
Hätte ich oben vielleicht gleich schreiben sollen.

MfG Micha

[GetAway]

@dbt

Im Konfigrationsmenü sollte auch bei deaktiviertem Interface, die Auswahl irq6 angeboten werden,
sonst schlägt beim aktivieren des Interfaces "ide-detect" fehl, das muss nicht sein.

Edit: Wird ja doch schon.
Dann würde ich die Bezeichnung ändern in "Aktiv - Standard IRQ" / "Aktiv - IRQ 6" oder so ähnlich.

[dbt]

Im Konfigrationsmenü sollte auch bei deaktiviertem Interface, die Auswahl irq6 angeboten werden

Hätte mich jetzt gewundert wenn das fehlt

Edit: Dann würde ich die Bezeichnung ändern in "Aktiv - Standard IRQ" / "Aktiv - IRQ 6" oder so ähnlich.

Habe deinen Vorschlag übernommen.
ist das so ok:

Code: Alles auswählen

aktiv mit IRQ6
aktiv mit standard IRQ

[dbt]

Es wird aber kein Eintrag in der fstab erstellt wenn noch keiner existiert, auch nicht nicht wenn ich "Übernehmen" drücke. Bzw. wenn ich den fstab Eintrag per Hand erstelle und später irgendwann "Übernehmen" drücke wird der fstab Eintrag wieder gelöscht - auch bei vorhandener und gemounteter MMC.
Hätte ich oben vielleicht gleich schreiben sollen.

MfG Micha

Jap, ein etwas größeres Log wäre auch nicht schlecht. Ich habe das nicht umsonst recht geschwätzig gehalten, aber ok, ich vermute, dass irgendwie das vfat modul nicht richtig geladen wird (hatte ich auch grade ) oder was anderes schief geht. Sollte das passieren, werden keine Einträge in die fstab und init.drives gemacht bzw. nur defaults eingetragen. Das kann ich aber nur im Log halbwegs nachvollziehen.

[micha-bbg]

Jap, ein etwas größeres Log wäre auch nicht schlecht. Ich habe das nicht umsonst recht geschwätzig gehalten, aber ok, ich vermute, dass irgendwie das vfat modul nicht richtig geladen wird (hatte ich auch grade ) oder was anderes schief geht. Sollte das passieren, werden keine Einträge in die fstab und init.drives gemacht bzw. nur defaults eingetragen. Das kann ich aber nur im Log halbwegs nachvollziehen.

init.drives:

Code: Alles auswählen

#!/bin/sh
echo "start /var/etc/init.d/init.drives generated from neutrino drive setup ($Revision$), do not edit!"
insmod ext2
insmod ide-core
insmod dboxide
insmod ide-detect
insmod ide-disk
insmod mmc2
mount -a
swapon -a
hdparm -S0 -W0 -c1 /dev/ide/host0/bus0/target0/lun0/disc

Log:

Code: Alles auswählen

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2009.08.14 22:42:04 =~=~=~=~=~=~=~=~=~=~=~=
[LCDFONT] FTC_Face_Requester (Fix12/Regular)

$Id: drive setup.cpp,v 0.1 2009/06/22 20:21:40 dbt Exp$
[drive setup] found harddiscs: 1
[drive setup] detected hdd model: 1. WDC WD800BEVS-00VAT0

[drive setup] detected hdd model: 2. Modell unbekannt
[drive setup] detected hdd model: 3. Modell unbekannt
[drive setup] found partitions: master->2 slave->0 mmc->1

The number of cylinders for this disk is set to 9729.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
[drive setup] loadFdiskPartTable: /dev/ide/host0/bus0/target1/lun0/disc not alvailable... 

The number of cylinders for this disk is set to 31000.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
<<<<<<<<<sel_device_num_actionkeysel_device_2
[drive setup] getDeviceInfo: mountpoint  not found...
[drive setup] getDeviceInfo: mountpoint  not found...

The number of cylinders for this disk is set to 31000.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended

[drive setup] mount /dev/mmc/disc0/part1...ok
[drive setup] mount /dev/mmc/disc0/part2 partition not activ, nothing to do...ok
[drive setup] mount /dev/mmc/disc0/part3 partition not activ, nothing to do...ok
[drive setup] mount /dev/mmc/disc0/part4 partition not activ, nothing to do...ok

The number of cylinders for this disk is set to 31000.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)

Wie gesagt, mounten funktioniert, nur in die fstab wird nichts geschrieben.