Kernel für embedded System

[eierfeile]

Guten Tag zusammen!

Ich habe mal ein paar Grundlegende Fragen zu einem Linux-System auf Embedded-Geräten:

Ich habe hier ein Atom-PC mit einem Flash-Festspeicher der als Embedded System mit Grafischer Oberfläche und einer Flash-Animation arbeiten soll. Auf diesem Gerät benötige ich ein
1. Sicherer Betrieb (Ausfallsicher/Betriebssicher, nicht unbedingt Zugriffssicher)
2. Schnelle Bootzeit
3. Performanter Betrieb

Als ersten Schritt habe ich ein minimales Debian installiert und zur sicherheit die Root-Partition als RO gemountet. Die Verzeichnisse /var/tmp und /tmp habe ich als tmpfs gemountet. Das Verzeichnis /var/log ist als Verzeichnis auf die (schreibbare) /home - Partition gelinkt. Das funktioniert auch soweit ganz gut.

Gibt es hierzu von euch irgendwelche Punkte, die noch verbessert werden könnten?

Als zweiten Punkt wollte ich mir einen Kernel bauen, der nur die Hardware enthält, die ich auch wirklich verwende! Ich habe mir auch hierzu schon einige HowTos durchgelesen...und grade kompiliert er fleißig...
Gib es eine Möglichkeit "mit einem Klick" die eigene Hardware auszulesen und wirklich nur die Sachen in den Kernel zu packen, die ich auch habe? Oder muss ich dass von Hand über die .Config machen?

Sollte man die Teile besser in den Kernel kompilieren oder als Modul? Was ist Sicherer und was bootet schneller?

Über Hinweise und Tipps bin ich dankbar!

Weiter Informationen zum System folgen... muss jetzt leider los!

[jeff84]

Gib es eine Möglichkeit "mit einem Klick" die eigene Hardware auszulesen und wirklich nur die Sachen in den Kernel zu packen, die ich auch habe? Oder muss ich dass von Hand über die .Config machen?

Du könntest den Kernel mit

Code: Alles auswählen

make localmodconfig

oder

Code: Alles auswählen

make localyesconfig

konfigurieren. Damit werden nur die Module die gerade geladen sind als Module oder fest eingebaut. Gibts glaub seit 2.6.32 oder 2.6.33

Sollte man die Teile besser in den Kernel kompilieren oder als Modul? Was ist Sicherer und was bootet schneller?

Wenn der Kernel nur für das Gerät ist, und auch nicht dauernd Dinge verändert (USB an- und abgesteckt) werden, sollte fest eingebaut die schlankere Linie sein... Was Sicherheit angeht, könnte man im Kernel dann auch das nachladen von Modulen verhindern...

[rendegast]

und zur sicherheit die Root-Partition als RO gemountet.

Das solltest Du wieder ändern, bringt höchstens Probleme bei upgrades.
(aus einem anderen Thread)

Gib es eine Möglichkeit "mit einem Klick" die eigene Hardware auszulesen und wirklich nur die Sachen in den Kernel zu packen, die ich auch habe?

Es gibt die Option 'localmodconfig' resp. 'localyesconfig' (scripts/kconfig/streamlineconfig.pl),
scripts/kconfig/Makefile:

Code: Alles auswählen

...
	@echo  '  localmodconfig  - Update current config disabling modules not loaded'
	@echo  '  localyesconfig  - Update current config converting local mods to core'
...

[eierfeile]

Vielen Dank schon mal für die Infos!

Das mit dem localmodconfig und localsysconfig werde ich mir mal ansehen!

Zum Readonly: Da das nur eine Flash-Disk ist, wollte ich die Schützen. Am besten so, dass man das System ruhig direkt ausschalten kann.
Für Updates oder auch gerade in der Entwicklungsphase mach ich dann immer ein "mount -o remount,rw...." Hat bisher ganz gut geklappt...
vorher gabs hin und wieder Probleme, da das System nicht vernünftig heruntergefahren ist und so das File-System immer wieder gescheckt wurde....

Auf welchen Verzeichnissen im System benötige ich denn unbedingt schreibrechte und welche Verzeichnisse können ruhig als tmpfs laufen?
Ist meine Wahl bis jetzt richtig?

tmpfs /tmp
tmpfs /var/tmp
Softlink auf /home-Partition bei /var/log, später, wenn alles läuft ggf. auch tmpfs... und/oder logging ausschalten
Softlink auf /home-Partition bei /etc/networ/(irgendein Unterverzeichnis, wo mir der Name grad nicht einfällt)

[rendegast]

Noch diese in /etc/default/rcS:

Code: Alles auswählen

RAMRUN=yes
RAMLOCK=yes

Um noch schneller zu booten

Code: Alles auswählen

CONCURRENCY=startpar

in Verbindung mit insserv
(mittlerweile Standard in squeeze, bei lenny vielleicht noch einige Startskripte dafür anpassen)

[debianoli]

Als ersten Schritt habe ich ein minimales Debian installiert und zur sicherheit die Root-Partition als RO gemountet. Die Verzeichnisse /var/tmp und /tmp habe ich als tmpfs gemountet. Das Verzeichnis /var/log ist als Verzeichnis auf die (schreibbare) /home - Partition gelinkt. Das funktioniert auch soweit ganz gut.

Ich steh gerade vor einem ähnlichen Problem, weil ich mir einen Medienplayer bauen will (T-online 100s).
Was hast du denn alles für das minimale Debian installiert? Gibt es da ein aktuelles Howto nach dem du vorgegangen bist? Das ist bei Lenny doch die Experte-Option im Installationsmenü, oder? (Ich habe schon länger kein neues Debian aufgesetzt, deshalb die Fragen)

[cosmac]

hi,

Zum Readonly: Da das nur eine Flash-Disk ist, wollte ich die Schützen. Am besten so, dass man das System ruhig direkt ausschalten kann.
Für Updates oder auch gerade in der Entwicklungsphase mach ich dann immer ein "mount -o remount,rw...."

mach' ich genauso. Und wenn ich es mal vergesse, sagt mir aptitude das schon

vorher gabs hin und wieder Probleme, da das System nicht vernünftig heruntergefahren ist und so das File-System immer wieder gescheckt wurde....

wobei das noch das kleinere Übel ist. CF-Karten können irreparabel beschädigt werden, wenn der Strom ausfällt während geschrieben wird.

Auf welchen Verzeichnissen im System benötige ich denn unbedingt schreibrechte und welche Verzeichnisse können ruhig als tmpfs laufen?

das kann man so nicht sagen, die Frage muss lauten: welche Daten müssen einen Stromausfall überleben? Solange es nur um "beschreibbar" geht, ist ein tmpfs genau richtig und kann bei Bedarf für jedes Verzeichnis und jede Datei verwendet werden. Und wenn die Priorität "Zuverlässigkeit mit nur einer CF-Karte" ist, muss man darauf verzichten, Daten über einen Stromausfall zu retten. Außer natürlich, man schickt sie per Netzwerk auf einen Server, das würde sich besonders für die Logfiles anbieten.

Einen nützlichen Link hätte ich noch: /etc/mtab -> /proc/mounts. Und dann noch einen Problemfall: wenn /etc/init.d/urandom beim Runterfahren nicht schreiben kann, wird /dev/urandom bei jeden Neustart mit dem gleichen Wert initialisiert. Wenn dann nicht wenigstens die Uhrzeit mit benutzt wird, werden die Zufallszahlen vorhersagbar.

Softlink auf /home-Partition bei /var/log, später, wenn alles läuft ggf. auch tmpfs... und/oder logging ausschalten

ausschalten würde ich das Logging nicht, ein tmpfs ist doch besser als garnichts. Es sollte allerdings ein eigenes tmpfs nur für /var/log sein und mit "size=50m" oder so gemountet werden, damit das RAM nicht vollgemüllt werden kann.

Softlink auf /home-Partition bei /etc/networ/(irgendein Unterverzeichnis, wo mir der Name grad nicht einfällt)

du meinst wahrscheinlich /etc/network/run/ifstate. Muss das wirklich dauerhaft gespeichert werden? Nach einem Neustart ist der Netzwerk-Zustand doch erstmal undefiniert, wen interessiert da der Zustand vom letzten Mal? Also: Link nach /dev/shm (da hatte Debian das früher mal untergebracht).

Übrigens, solange die /home-Partition beschreibbar ist, brauchst du auch / nicht ro zu mounten. Schließlich ist für die Anwendung /home genauso wichtig wie /. Bei CF-Karten kann es sogar passieren, dass Teile von beiden Partitionen in einem physikalischen Block untergebracht sind. Ein Fehler würde also auch die ro-Partition beschädigen. Je größer und neuer die Karte ist, umso größer sind die physikalischen Blöcke und umso wahrscheinlicher wird das.

Wenn's um kurze Boot-Zeiten geht, würde ich einen Kernel ohne initrd, aber mit devtmpfs verwenden. Damit muss udev keine Devices mehr anlegen, das spart merklich Zeit. Noch mehr spart man, indem man unnötige init-Scripts mit "insserv -r $script" entfernt. Z.B. braucht man hwclock.sh und hwclockfirst.sh nicht, wenn die Uhrzeit aus dem Netz kommt. checkfs.sh und checkroot.sh sollten eigentlich unnötig sein und mountoverflowtmp scheint mir völlig überflüssig zu sein. Hier werden nur noch ca. 5 der Original-Scripte aufgerufen, dazu kommen ein paar Befehle in einem eigenen Script. Damit dauert es vom Bootloader-Prompt bis zum Fenster der Anwendung 8 Sekunden auf einem N270; und da müsste noch Luft drin sein.

Was hast du denn alles für das minimale Debian installiert? Gibt es da ein aktuelles Howto nach dem du vorgegangen bist? Das ist bei Lenny doch die Experte-Option im Installationsmenü, oder?

Ich installiere zwar immer mit expert-Option, aber das ist für ein minimales Debian nicht entscheidend. Wenn du 1GB Platz hast, kannst du ganz normal, nur ohne "Desktop", installieren. Dazu X11, einen Window-Manager und deine Anwendungen und gut ist. Deutlich weniger Platz, also unter 500MB, wird mit Debian sehr mühsam.

[eierfeile]

Ich steh gerade vor einem ähnlichen Problem, weil ich mir einen Medienplayer bauen will (T-online 100s).
Was hast du denn alles für das minimale Debian installiert? Gibt es da ein aktuelles Howto nach dem du vorgegangen bist? Das ist bei Lenny doch die Experte-Option im Installationsmenü, oder? (Ich habe schon länger kein neues Debian aufgesetzt, deshalb die Fragen)

Ich hab das ungefähr so gemacht, wie cosmac bereits beschrieben hat. Ich bin jetzt nur auf das Problem gestoßen, dass ich den X-Server nicht vernünftig starten kann, da die .Xauthority nicht angelegt werden kann.
Wenn ich startx direkt im Startskript ausführen lasse, wird der X-Server ja ohne User gestartet und die .Xauthority liegt direkt unter / und dort ist ein Schreibschutz. Kann ich irgendwie festlegen, wo die .Xauthority hingelegt werden soll und dann so ein schreibbares Verzeichnis auswähle?

Und wo ich grad dabei bin: Ich wollte das System bzw / mal wieder auf rw setzen und hab das in der /etc/fstab geändert. Aber es funktioniert nicht mehr. Nach jedem Boot ist das System immer wieder Read-Only. Woran kann das liegen?

[cosmac]

Ich bin jetzt nur auf das Problem gestoßen, dass ich den X-Server nicht vernünftig starten kann, da die .Xauthority nicht angelegt werden kann.
Wenn ich startx direkt im Startskript ausführen lasse, wird der X-Server ja ohne User gestartet

dann starte ihn eben mit User Zum Beispiel so (man achte auf die '-' und Blanks)

Code: Alles auswählen

su - eierfeile -c xinit &

So wird ganz normal /home/eierfeile benutzt und X11 und die Anwendungen laufen dann auch nicht mehr als root (weil, ganz ohne User geht ja nicht). Leider reicht das nicht, weil /home ja auch read-only ist und außerdem brauchen auch einige Anwendungen ein beschreibbares Verzeichnis. Deswegen kopiere ich das home-Verzeichnis nach /tmp und setze einen Link. Das originale home-Verzeichnis muss einmalig umbenannt werden (hier: eierfeile-persistent), damit das effektiv benutzte den normalen Namen haben kann:

Code: Alles auswählen

cp -a /home/eierfeile-persistent /tmp/eierfeile
ln -sf /tmp/eierfeile /home/eierfeile
su - eierfeile -c xinit &

Ich verwende "xinit" statt "startx", weil startx irgendwie nicht richtig funktioniert hat. Außerdem möchte man auf so einem Rechner ja genau kontrollieren, was gestartet wird. Mit xinit wird genau nur das gestartet, was in /tmp/eierfeile/.xinit drin steht. Einzelheiten sind in der Manual Page von xinit gut erklärt.

Und wo ich grad dabei bin: Ich wollte das System bzw / mal wieder auf rw setzen und hab das in der /etc/fstab geändert. Aber es funktioniert nicht mehr. Nach jedem Boot ist das System immer wieder Read-Only. Woran kann das liegen?

Tippfehler? falsche Zeile? "rw" und "ro" angegeben? Oder ein kaputtes Dateisystem, das wird aber geloggt, schau mal mit dmesg nach (oder in /var/log/syslog).

[eierfeile]

Danke für die vielen Tipps:
Zum X-Server:
Bei mir ist es so:
-Wenn ich startx in einem init-Script aufrufe, versucht er immer //.Xauthority zu verwenden (warum auch immer // in der Ausgabe steht, weiß ich nicht). Aber das /-Filesystem war ReadOnly.
- Wenn ich startx als root aufrufe war es /root/.Xauthority, bei Ausführung als User war es entsprechend /home/user/.Xauthority (Die Verzeichnisse waren entsprechend mit Schreibrechten versehen und es hat funktioniert)
- Komischerweise wurde aber auch bei "sudo -u root startx" im init-Skript immer noch das File unter //.Xauthority versucht anzulegen, was ja nicht funktioniert hat - alle anderen Einstellungen wurden aber seltsamerweise von root übernommen. (Das hatte ich schon heute morgen versucht.)
- Deine Tips mit xinit und "sudo - user -c xinit" werde ich - wenn ich es schaffe - morgen noch mal testen... wenn nicht, hab ich erstmal 3 Wochen Urlaub
- Kann man eigentlich auf .Xauthority komplett verzichten? gdm konnte ich komischerweise auch starten, trotz RO -System.... und somit konnte .Xauthority auch nicht angelegt werden.

Aber...ich habe es ja doch zum laufen bekommen: Ich hab den Fehler für das Read-Only trotz Änderung in fstab gefunden. Ich hatte in /etc/rcS.d die skripte für "checkfs" und co deaktiviert....und "mountall" wurde nur ausgeführt, wenn das checkfs ausgeführt wurde! Naja....jetzt hab ich wieder schreibrechte und ich kann den X-Server auch aus einem Init-Skript starten.

Wenn deine Tips helfen...werde ich sehr wahrscheinlich wieder auf RO gehen....

So...besten Dank nochmal und gleich viel Erfolg beim Fußballgucken

[debianoli]

@all
Danke für die Tipps, werde ich bald mal ausprobieren.

[eierfeile]

Ich hab noch mal ne kurze Frage:
Ich hatte irgendwo gelesen, dass es ein Befehl gibt, mit dem man den Kernel optimal an das eigene System anpassen kann.... ich finds nur nicht mehr wieder....

Kennt ihr sowas?

[jeff84]

Code: Alles auswählen

make localyesconfig

oder

Code: Alles auswählen

make localmodconfig

Einmal alles was zum Aufruf als Modul geladen ist, wird fest einkompiliert und beim zweiten als Modul gebaut. Allerdings aufpassen, dass man Sachen nicht vergisst, die uU später erst geladen werden, zum Beispiel irgendwelche USB-Module...