Sie sind hier : Homepage →  > Linux (12) Technik des NAS-540→  > Hintergrund von Embedded Linux

Diese Seiten sind unsere internen Protokolle aus dem Labor.

Aufgrund der fortlaufenden Protokollierung der Ergänzungen sowie der Verbesserungen ist die Reihenfolge / Chronologie der Seiten aus dem Ruder gelaufen - leicht durcheinander geraten.

.

Mein bisheriges (älteres) Wissen von Embedded Systemen :

Die Hauptplatine eines "embedded" Systems von Zyxel - ein NAS-Server

Jan. 2022 - (Text wird noch korrigiert) Bei der Recherche, warum das Betriebssystem Linux in den Zyxel NAS Boxen (Servern) so sonderbare Wege geht, um Erweiterungen resident oder permanent im System zu speichern, bin ich in den Suchmaschinen über mehrere Foren-Artikel gestolpert.

Die Erklärung :
Wenn man ein ganz normales Windows von WIN 95 bis WIN 10 (oder sogar WIN 11) installiert, werden bei der Installation auf der unabdingbaren !! Festplatte Nummer 1 (der Disk-0 mit dem MBR=Boot-Record) jede Menge an System-Verzeichnissen angelegt - wichtig, alle auf der Festplatte.

Gleiches gilt auch für die ganz normale Installation von Linux-Servern (bei uns opensuse) auch auf der obligatorischen (ersten) Festplatte, ohne die auch hier (wie bei Windows) die Installation abbricht.
.

Es gibt sogenannte "Live"-Systeme von DVD oder USB-Stick

Bei diesen Systemen wird eine uns durchaus bekannte Verzeichnisstruktur virtuell im Hauptspeicher (sofern er groß genug ist) angelegt (also nicht auf der echten Festplatte sondern auf einer virtuellen RAM-Disk) und in diese virtuellen Verzeichnisse wird das alles aus einer großen Container-Datei entpackt und installiert.

Damit läßt sich ein scheinbar ganz normales Windows- oder Linux- Umfeld betreiben samt Browser, aber nicht updaten oder gar mit weiteren Programmen ergänzen. Wird der PC am Ende wieder runter gefahren, ist (aus dem Hauptspeicher) alles wieder weg. Diese Live- oder Rescue-Systeme starten auch ohne die sonst obligatorische Festplatte oder sonstige Massenspeicher.
.

Die "Embedded Systeme" für Spezialanwendungen

Bislang bin ich bei Windows nur bei den beiden Grass Valley Video-Disc-Recordern auf "Windows XP Embedded" gestoßen. Ähnliches gilt aber auch für Linux basierende Geräte.

Diese speziellen Geräte benötigen nur ein Bruchteil der fast unendlichen Möglichkeiten eines normalen Windows- oder Linux- Betriebssystems. Der Enwickler konfiguriert "sein" Betriebssystem mit direktem Blick auf die nackten Funktion des Zielgerätes - zum Beispiel einer Registrierkasse in einem Kaufhaus oder Supermarkt.

Diese Kasse soll nichts weiter "können" als die Kassenfunktionen. Gleiches gilt für die genannten Video-Recorder und teilweise auch für die NAS Server. Ich brauche auf einem NAS-Server zum Beispiel keinen Firefox Browser oder einen PDF Reader.

Ist die ausgewählte bzw. zusammengestellte (oft minimale) Konfiguration fertig, wird alles Notwendige davon an Modulen in eine ausführbare Datei (bei Windows eine große ".bin" Datei gepackt und bei Linunx ist es die Firmware, die auch noch die sogenannte "busybox" oder "toybox") mit reingepackt bekommt.

Diese gepackte Datei wird beim Start solch eines Gerätes in den Hauptspeicher und/oder auf die Festplatte extrahiert. Die "busybox" ist die minimalsierte Sammlung von wirklich nur absolut notwendigen Unix-Tools in einer einzigen ausführbaren Datei und nicht mehr.
.

Das ist dann das Boot-Image (auch Firmware genannt)

Dieses "Image" wird jedesmal beim Start des Gerätes neu entpackt und installiert und somit sind natürlich alle früheren eventuellen Änderungen nicht mehr da.

Das mit ssolch einem Boot-Image machen sowohl das ganz normale Standard-Windows als auch ein Standard-Linux zwecks Beschleunigung beim Hochfahren der Geräte. Jedoch wird dieses Boot-Image beim Herunterfahren des Betriebssystems jedesmal mit der aktuellen Konfiguration neu erzeugt. Auch werden die ergänzten Programme in den Verzeichnissen auf der Festplatte dauerhaft abgelegt und sind so auf Dauer verfügbar.

Bei den Embedded Systemen muß deshalb mit einem Trick gearbeitet werden, um neue zusätzlich installierte Funktionen und Programme "persistent" zu erhalten.
.

Wie geht das bei Linux mit dem "embedded" Linux ?

Ein NAS, ein Netzwerk-Server, muß immer (mindestens) eine Festplatte haben, sonst macht ein NAS ja überhaupt keinen Sinn. Eine völlig leere Festplatte bekommt bei der Initialisierung, also wenn die erste Partition (oder bei Zyxel das erste "Volumen") angelegt wird, eine sogenannte Volumen-ID, eine künstlich generierte "Hexa-Nummer" - eine zumindest für den Server eindeutige einmalige Ident-Nummer.

Diese "Volume-ID" wird von dem embedded Betriessystem von nun an ins ganz normale allgemein bekannte (virtuelle) Verzeichnis-System eingelinkt (gemounted). Die VOL_IDs stehen auf der Festplatte (im MBR ?) und ändern sich nicht mehr. Bei der Abfrage von "Disk-0" bekommt das embedded System die ID mitgeteilt und der Admininstrator kann damit auf dieser Platte ein paralelles aber reales "Verzeichnis-Konstrukt" aufbauen.

Dieses oder diese Verzeichnisse werden beim Start in das virtuelle Verzeichnis- System eingeklinkt und dort werden die zusätzlichen Software-Module und Programme gespeichert.
.

Dazu eine Info bezüglich der "busybox"

Die "originalen" Linux-Befehlszeilen Kommandos sind in der Summe ganz schön groß. Viele der Optionen werden seltenst gebraucht. Beschränkt man sich auf gängige und oft benutze Funktioen und Optionen, passen eine ganze Menge dieser Befehle komprimiert in einen Container. Diese Kommandos kommen dann aus der "busybox". Hier eine Auflistung der in unserem NAS-540 Server enthaltenen Befehle bzw. Funktionen:
.
Currently defined functions:

acpid, addgroup, adduser, adjtimex, arp, ash, awk, basename, beep, bzip2, cat, catv, chat, chgrp, chmod, chown, chroot, chrt, chvt, cksum, clear, cmp, cp, crond, crontab, cryptpw, cttyhack, cut, date, dd, deallocvt,  delgroup, deluser, depmod, devmem, df, diff, dirname, dmesg, dnsdomainname, du, echo, ed, egrep, eject, env, expand, expr, false, fgrep, find, flock, free, freeramdisk, fsync, getopt, getty, grep, gunzip, gzip, halt,  hdparm, head, hexdump, hostname, hwclock, id, ifconfig, ifplugd, init, insmod, install, ionice, ipcrm, ipcs,  kill, killall, less, linuxrc, ln, logger, login, losetup, ls, lsmod, lspci, lsusb, lzop, lzopcat, man, md5sum,  mdev, microcom, mkdir, mknod, mkpasswd, mkswap, mktemp, modinfo, modprobe, more, mountpoint, mv, netstat, nice, nslookup, openvt, passwd, pgrep, pidof, ping, ping6, pivot_root, poweroff, printenv, printf, ps, pwd, raidautorun, rdev, readahead, readlink, reboot, reset, resize, rev, rm, rmdir, rmmod, route, rtcwake, script, scriptreplay, sed, seq, setfont, setlogcons, setsid, sh, sha256sum, sha512sum, showkey, sleep, sort, split,  start-stop-daemon, strings, su, swapoff, swapon, sync, tac, tail, tar, tee, telnet, telnetd, test, time,  timeout, top, touch, tr, traceroute, traceroute6, true, tty, ttysize, udhcpc, udpsvd, uname, unexpand, uniq, unlzop, unxz, unzip, uptime, usleep, vi, volname, wall, watchdog, wc, wget, which, who, whoami, xargs, xz,  xzcat, yes, zcat, zcip

.

.

Startseite -- © 2001/2022 - Copyright by Dipl.-Ing. Gert Redlich / Germany - D-65191 Wiesbaden - Telefon-Nummer - Impressum