Die HD als Systemkomponente, nicht nur Datenspeicher: /usr

Kreuzuebersetzer, Diskussion über Änderungen im Tuxbox-CDK und Tuxbox-CVS
Barf
Developer
Beiträge: 1475
Registriert: Dienstag 4. Februar 2003, 22:02

Die HD als Systemkomponente, nicht nur Datenspeicher: /usr

Beitrag von Barf »

Wir haben die "dbox-Festplatte" etwa 3 Jahre gehabt, und betrachten sie noch als Datenspeicher. Einige Leute haben es gerade geschafft, von der FP zu booten. Sonst geht die "Trichterei" (wie klemme ich so viel wie möglich in 8MiB Flash rein?) weiter. :cry:

Ich habe anstatt "booten von FP" den klassischen Unix-Ansatz mit sekundärem Filesystem verfolgt. Dabei wird eine Plattenpartition gemounted, komform zu dem File System Hierarchy standard (am mindestens fast). Dies hat subdirectories bin, lib, share, usw, genau so wie root /. Mit Anpassungen am Pfade bekommt man ein system das wie gewohnt von Flash bootet, binaries etc wird nicht nur von /bin gefunden, sondern auch in /usr/bin.

Praktische Vorteile sind u.a.
  • /usr inhalt bleibt: darauf installierte extrakomponente ein Flashen überleben
  • Inkrementelles updaten möglich
  • r/w-Zugriff, bzw kein Ärger um Flashverschleiss
  • Kein Ärger mit reduzierte Libraries mehr: Die ungestrippte sind vorhanden
So hier bin ich vorgegangen: Ausgangspunkt ein jffs2-Image, Disk (100GB, PATA, 2,5"), nfsserver installiert (bequem, nicht erforderlich).

1. Neupartitionierung der Platte: Part1: swap, ID: 82 (wie üblich), Part2 data, ID: 83, ext2 (wie üblich), Part3 (neu), ID 83, 100 Zylinder = 8.2 GiB, ext2.
2. Anpassung der /etc/fstab: Ziele

Code: Alles auswählen

/dev/ide/host0/bus0/target0/lun0/part3 /usr ext2 defaults 1 2
. mkdir /usr.
3. Anpassung von /etc/exports: Zufügen von

Code: Alles auswählen

/usr *(rw,sync,no_subtree_check)
.
4. Bauen eines aktuelles YADDs auf dem Buildrechener. Kopieren des .../cdkroot auf dbox:/usr über nfs (z.B.).
5. In /etc/profile wird PATH in

Code: Alles auswählen

PATH=/usr/sbin:/usr/bin:/sbin:/bin
geändert, und die Zeile

Code: Alles auswählen

LD_LIBRARY_PATH=/usr/lib:/lib
zugefügt.
6. Es wäre vorteilhaft, die "fette" share Verzeichnis zu benutzen, leider gibt es z.Z. keine Möglichkeit z.B. neutrino mitzuteilen wo share sich befindet: Abhilfe: mounte (/etc/fstab)

Code: Alles auswählen

/usr/share      /share          none    bind
7. (optional) Es ist auch eine gute Idee, Platten-var zu benutzen, deswegen (etc/fstab)

Code: Alles auswählen

/usr/var        /var            none    bind
. Dabei ist es natürlich notwendig, das "/usr/var" vernünfig zu befüllen, z.B. durch rüberkoperien von YADD-var.
8. Um lcdmenu von /usr/bin/lcdmenu zu benutzen (um zwischen mehrere GUIs beim Start zu wählen) wird eine kleine Änderung in /etc/init.d/start erforderlich, wird "dem Leser als Übung" überlassen. Dazu Änderungen in /var/tuxbox/conf/lcdmenu.conf (/bin/neutrino in neutrino ersetzen etc), sowie ein gefixte lcdmenu, dass GUIs ohne Direktory in Pfad sucht (schon eingecheckt).

Dann soll es eigentlich funktionieren.

Bemerkungen:

1 . Dies ist eine Art Machbarkeitsstudie, beweist dass es geht, ohne eine Produktivlösung darzustellen. Ich bitte um Verbesserungen. Insbesonderes: Das LD_LIBRARY_PATH ist (aus gutem Grunden) verpöhnt; ich weiss z.Z.nicht wo sich die jetztige Software beschliesst (in unterschied zu "alle Andere" Unixe/Linuxe) /usr/lib zu ignorieren. Kann man es besser machen (seife?)

2. Ich habe versucht, das usr-lose System als Fallback unverändert zu halten. Ins besonderes wird /usr Zeugs nicht von rcS aufgerufen.

3. Weil Machbarkeitsstudie sind alle Sicherheitsaspekte ignoriert worden.

Nächste Frage ist natürlich: Lässt es sich automatisieren bzw im Makeprozess integrieren? Antwort: Z.Z. relativ schlecht. Das bauen von .../cdkroot/lib ist ein Mist, findet teilweise während builden von compiler/libc/binutils statt. Ein configure-Option --enable-usr=<pfadname> (pfadname wäre dann wo die usr-ergebnisse abgelegt wird, idealerweise ein NFS-Mountpunkt, sonst irgendwelche Verzeichniss, dass später rüberkopiert wird) wäre durchaus denkbar und ziemlich leicht, wurde aber z.Z. nur triviale Sachen ausrichten, wie z.B. mountpoints anlegen und fstab erweitern. Denkbar wäre aber maketargets wie z.B.

Code: Alles auswählen

usr-neutrino: $(appsdir)/tuxbox/neutrino/config.status
	$(MAKE) -C $(appsdir)/tuxbox/neutrino all install prefix=@usr_path@
	$(MAKE) neutrino-additional-fonts targetprefix=@usr_path@
Vielleich wäre binäre zusatzpakete möglich, entweder wie yjogols pakete, rpms oder aptget wie Debian?

Jetzt seit ihr dran!
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: Die HD als Systemkomponente, nicht nur Datenspeicher: /usr

Beitrag von seife »

/usr/lib wird vermutlich ignoriert, weil das der Toolchain beim Bauen so gesagt wird (bin mir aber nicht sicher).

Allerdings sehe ich momentan den konkreten Vorteil gegenüber "booten von Festplatte" nicht (und es ist wesentlich komplexer, IMHO).

"booten von Festplatte" hat den Vorteil, dass man immer noch ein funktionierendes "fallback-Image" im FLASH haben kann, mit deinem "Combo"-Ansatz (Teile auf der Platte, andere Teile im FLASH) ist das IMHO wesentlich schwieriger.

Meine Erfahrungen mit der Tripledragon zeigen, dass es sehr komfortabel ist, das alles auf der Platte zu haben (die "Platte" ist in dem Fall eine 4GB CF-Karte), ich bin noch nie auch nur auf die Idee gekommen, den FLASH der TD auch nur anzufassen.

Von wegen Paketen: man kann, wenn man auf die Platte installiert, einfach ein emdebian installieren (den Kernel und neutrino baut man dann selbst), da sind dann deb-Pakete das Format der Wahl.

Auf der TD habe ich auch schon eine PPC-openSUSE installiert, aber das war mehr eine Machbarkeitsstudie.

Am sinnvollsten ist vermutlich, wenn man Pakete haben will, emdebian zu benutzen oder mit openembedded was zu stricken.