Mein System lief auf einem 1GB USB-Stick und lief eigentlich ziemlich super. Lief. Ja. Das ist der Knackpunkt: Mein USB-Stick ist ziemlich tot.

Das äußert sich darin, dass plötzlich irgendwelche Befehle nicht mehr tun, ich kryptische Errors um den Kopf geworfen bekomme und das System nicht mehr bootet, weil das ext2-fs so stark beschädigt ist, dass es nicht durch den routinemäßigen Check beim boot repariert werden kann, sondern manuell per e2fsck gefixt werden muss (von einem anderen pc aus).

Die Ursache dafür liegt darin, dass die in USB-Sticks und SD-Karten verbauten Flash-Chips zwar praktisch unendlich viele Lesevorgänge, aber nur ca. 10.000 – 100.000 Schreibzyklen pro Sektor verkraften. Das ist normalerweise absolut kein Problem, wenn man einfach nur “Daten” auf diesen Sticks zwischenspeichert. Außerdem versuchen die Hersteller meist, die Schreibvorgänge auf mehrere Sektoren zu verteilen, um ein Überschreiben von immergleichen Sektoren zu vermeiden. Letzteres kann aber natürlich nicht funktionieren, wenn der Stick quasi voll ist.

Wenn man aber ein Betriebssystem auf dem Stick betreibt, können diese Zyklen relativ schnell erreicht sein, vor allem durch Logfiles, Lockfiles und temporäre Daten. Auf diese Weise hat sich wie eingangs schon erwähnt mein (zugegeben ziemlich billiger und schon länger gebrauchter) USB-Stick verabschiedet.

Da viele Teile dermaßen beschädigt waren, dass das Reparieren verdammt aufwändig geworden wäre, habe ich das System von Neuem hochgezogen. Dabei habe ich mir die Frage gestellt: Wie kann ich vermeiden, dass das System wieder meinen Stick screwed? Als erstes kam mir die Idee, einfach das rootfs read-only zu mounten. Das hat aber zur Folge, sämtliche Schreiboperationen im RAM zu cachen. Da die Dockstar nur 128MB RAM hat, schied diese Möglichkeit aus. Als zweites kam mir die Idee, die ich jetzt auch umgesetzt habe:

Flüchtige Daten in einer Ramdisk halten

Das heißt, ich mounte mir einen Teil des spärlich vorhandenen RAMs als Datenträger und mappe ihn als Ersatz für die Verzeichnisse

• /var/log (Logfiles)
• /var/lock (Sperr-Files)
• /var/run (Daemon-PIDs)
• /var/tmp (Temporäre Dateien)
• /tmp (Temporäre Dateien).

Dadurch fange ich fast alle Schreibzugriffe ab, welche im Dauerbetrieb eben anfallen. Änderungen an Configfiles etc. werden aber immernoch sofort auf den Stick geschrieben. Falls das System sich aufhängt, abstürzt oder ähnliche Scherze passieren, ist der “zusätzliche” Datenverlust also gering (nur die neueren Logfiles). Trotzdem: Hier werden einige Dateien nur im RAM vorgehalten. Wenn das System crasht oder die Daten vorm Ausschalten nicht von der Ramdisk auf den Stick gesichert werden, sind sie weg!

Bevor ich mit der Anleitung beginne, sei hier die Seite cat brain.stuff > wordpress als Quelle genannt, da fast alle Informationen von dort stammen. Ich habe es lediglich zu Arch Linux / Plugbox Linux “geportet” und an meine Bedürfnisse angepasst.

Anlegen der Verzeichnisse

mkdir /var/log-bak

mkdir /var/lock-bak

mkdir /var/run-bak

mkdir /var/tmp-bak

mkdir /tmp-bak

mkdir /run-bak

mkdir /mnt/ramdisk

Den Daemon anlegen

Die Datei /etc/rc.d/ramdisk erstellen und folgendes hineinpasten:

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

case “$1″ in
start)
stat_busy “Copying files to ramdisk”

rm -Rf {/var/log-bak,/var/lock-bak,/var/run-bak,/var/tmp-bak,/tmp-bak,/run-bak}

mount –move /var/log /var/log-bak
mount –move /var/lock /var/lock-bak
mount –move /var/run /var/run-bak
mount –move /var/tmp /var/tmp-bak
mount –move /tmp /tmp-bak
mount –move /run /run-bak

mkdir /mnt/ramdisk/var
mkdir /mnt/ramdisk/var/log
mkdir /mnt/ramdisk/var/lock
mkdir /mnt/ramdisk/var/run
mkdir /mnt/ramdisk/var/tmp
mkdir /mnt/ramdisk/tmp
mkdir /mnt/ramdisk/run
mkdir /mnt/ramdisk/run/lock
chmod 1777 /mnt/ramdisk/tmp
chmod 1777 /mnt/ramdisk/var/lock
chmod 1777 /mnt/ramdisk/var/tmp
chmod 1777 /mnt/ramdisk/run

mount –bind /mnt/ramdisk/var/log /var/log
mount –bind /mnt/ramdisk/var/lock /var/lock
mount –bind /mnt/ramdisk/var/run /var/run
mount –bind /mnt/ramdisk/var/tmp /var/tmp
mount –bind /mnt/ramdisk/tmp /tmp
mount –bind /mnt/ramdisk/run /run

cp -a -v /var/log-bak/* /var/log/ >> /var/log/ramdisk_sync.log
cp -a -v /var/lock-bak/* /var/lock/ >> /var/log/ramdisk_sync.log
cp -a -v /var/run-bak/* /var/run/ >> /var/log/ramdisk_sync.log
cp -a -v /var/tmp-bak/* /var/tmp/ >> /var/log/ramdisk_sync.log
cp -a -v /tmp-bak/* /tmp/ >> /var/log/ramdisk_sync.log
cp -a -v /run-bak/* /run/ >> /var/log/ramdisk_sync.log

echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk synced from HD >> /var/log/ramdisk_sync.log
if [ $? -gt 0 ]; then
stat_fail
else
add_daemon ramdisk
stat_done
fi
;;
stop)
stat_busy “Switching off ramdisk, direct hdd write”
rsync -av –delete /var/log/ /var/log-bak/
rsync -av –delete /var/lock/ /var/lock-bak/
rsync -av –delete /var/run/ /var/run-bak/
rsync -av –delete /var/tmp/ /var/tmp-bak/
rsync -av –delete /tmp/ /tmp-bak/
rsync -av –delete /run/ /run-bak/

# Unmount ramdisk bind
umount /mnt/ramdisk/var/log
umount /mnt/ramdisk/var/lock
umount /mnt/ramdisk/var/run
umount /mnt/ramdisk/var/tmp
umount /mnt/ramdisk/tmp
umount /mnt/ramdisk/run

# Unmount move
umount /var/log-bak
umount /var/lock-bak
umount /var/run-bak
umount /var/tmp-bak
umount /tmp-bak
umount /run-bak

# Deleting directories
rm -Rf /mnt/ramdisk/*

echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk synced to HD >> /var/log/ramdisk_sync.log
if [ $? -gt 0 ]; then
stat_fail
else
rm_daemon ramdisk
stat_done
fi
;;
sync)
echo “Syncing log and lock files to harddisk”
rsync -av –delete /var/log/ /var/log-bak/
rsync -av –delete /var/lock/ /var/lock-bak/
rsync -av –delete /var/run/ /var/run-bak/
rsync -av –delete /var/tmp/ /var/tmp-bak/
rsync -av –delete /tmp/ /tmp-bak/
rsync -av –delete /run/ /run-bak/

echo [`date +"%Y-%m-%d %H:%M"`] Ramdisk synced to HD >> /var/log/ramdisk_sync.log
;;

restart)
$0 stop
$0 start
;;

*)
echo “usage: $0 {start|stop|sync}”
esac
exit 0

Die /etc/fstab anpassen

Dort eine Zeile hinzufügen à la

tmpfs                   /mnt/ramdisk    tmpfs   size=64m        0       0

Ich benutze hier bewusst tmpfs und nicht ramfs, da tmpfs bei akutem Ram-Mangel auf swap ausweicht, ramfs dies aber nicht tut. Weiterhin limitiere ich die Größe für die Ramdisk auf 64MB. Die Ramdisk wächst aber dynamisch, belegt also nur Platz, welchen sie auch braucht. Die 64MB sind nur ein grob geschätzter Maximalwert.

/etc/rc.conf anpassen

Hier sollte der Daemon als erster gestartet werden, damit so wenige Applikationen wie möglich den (sehr) kurzen Ausfall der oben genannten Verzeichnisse verkraften müssen. Euer DAEMONS-Array könnte also so aussehen:

DAEMONS=(ramdisk syslog-ng network openntpd netfs crond sshd)

Logrotate anpassen

Ein Punkt, der sich erst nach einiger Benutzung als wichtig herausgestellt hat: Die Logfiles können sehr groß werden und damit den RAM füllen. Um das zu verhindern, sollten die Logs in kurzen Zeitabständen rotiert werden.

Dazu passen wir die /etc/logrotate.conf an. Meine sieht so aus:

daily

rotate 3

size 16M

create

compress

tabooext + .pacorig .pacnew .pacsave

include /etc/logrotate.d

/var/log/wtmp {

weekly

create 0664 root root

rotate 1

}

Abschließende Worte

Soweit, so gut. Beim nächsten Neustart sollte euer System also nun den größten Teil der Schreiboperationen im RAM vorhalten. Ganz eilige können auch einfach den Daemon starten, es sollte auch so funktionieren. Was passiert, wenn ein Prozess genau dann der Meinung ist, ein Logfile schreiben zu müssen, wenn der Daemon gerade Verzeichnisse herumschiebt, kann ich absolut nicht vorhersagen.

Wenn ihr Verbesserungsvorschläge, Tipps, Kritik oder sonstigen Senf zum Zugeben habt, immer her damit.

Hardware:

- Marvell 88F6281 SoC mit 1,2 GHz Sheeva CPU
- 128MB DDR2
- 256MB NAND-Flash
- 3x USB 2.0 Ports
- 1x Mini-USB für Seagate Go Festplatten
- 100/1000 MBit Ethernet

Wer sich nicht mit den durch den Pogoplug-Dienst gegebenen Einstellungen/Einschränkungen zufriedengeben möchte, kann aber auch mit ein paar Tricks ein vollständig funktionstüchtiges PlugBoxLinux(eine auf Arch basierende Distro) an den Start bringen

Bevor es losgeht, möchte ich auf die Gefahr hinweisen, dass man mit manchen dieser Schritte das Gerät bricken, also unnutzbar machen kann. Alles geschieht auf eigene Verantwortung.

——

Aber no risk, no fun, also los gehts:

1. )Seagate Dockstar ans Netzwerk anschließen, aber darauf achten dass sie keinen Zugriff auf das Internet erhält.(Adi64 und ich haben einfach einen kleinen Switch genommen) Noch ist nämlich ein Service aktiv, der Updates installiert. Unter anderem eines, das ssh deaktiviert und das root-Passwort ändert…

2.)Die IP des Gerätes herausfinden.
Bei uns hat es gereicht, die letzten beiden Byte der MAC-Addresse(steht unten drauf) zu kennen.
Angenommen diese beiden Bytes wären AB(=171) und CD(=205), dann ist die IP

169.254.171.205

Wenn das bei euch nicht so sein sollte, kommt ihr nicht darum, die Dockstar per nmap zu suchen:

nmap -sP 169.254.0.0/16

3.)Per ssh einlogggen:

ssh root@169.254.171.205
root@169.254.171.205's password: stxadmin #ist für alle gleich  

4.)Den Pogoplug-Updateservice abschießen und aus dem Startup rausnehmen:

killall hbwd
mount -o remount,rw / #root als writeable remounten
vi /etc/init.d/rcS
#Jetzt die Zeile mit "/etc/init.d/hbmgr.sh start" auskommentieren
mount -o remount,ro /
#Jetzt kann man das Gerät theoretisch gefahrlos ans Netz anschließen

5.)Backup, Backup, Backup. USB-Stick anschließen und danach die Daten sicher verwahren:

cd /tmp
mkdir usb
mount /dev/sda1 /tmp/usb
wget http://plugapps.com/os/pogoplug/uboot/nanddump
chmod +x nanddump
./nanddump -nf usb/mtd0 /dev/mtd0
./nanddump -nf usb/mtd1 /dev/mtd1
./nanddump -nf usb/mtd2 /dev/mtd2
umount /dev/sda1

6.)Das U-Boot, den Bootloader, installieren. Das ist an sich der gefährlichste Teil, weil ein Teil der Flash-Speichers bearbeitet wird. Ein Neustart danach ist nicht notwendig, es gibt ja noch nichts Besseres wo man reinbooten könnte

cd /tmp
wget http://plugapps.com/os/pogoplug/uboot/install_uboot_mtd0.sh
chmod +x install_uboot_mtd0.sh
./install_uboot_mtd0.sh

7.)Einen USB-Stick(1GB sollte drin sein) formatieren, mit einer mindestens 512MB großen ext2-Partition. Das Formatieren muss nicht unbedingt auf dem DockStar erfolgen.

8.)PlugBox Linux herunterladen, auf dem USB-Stick speichern:

#cd auf den USB-Stick
wget http://plugapps.com/os/1.1/Plugbox-Linux-1.1-rootfs.tar.gz

9.)Das heruntergeladene Archiv auf dem USB-Stick extrahieren, danach das Archiv löschen. Dies sollte auf der DockStar erfolgen, sonst drohen Berechtigungsprobleme (Danke an GerhardSchr!)

tar -xzvf Plugbox-Linux-1.1-rootfs.tar.gz # Dauert ein bisschen auf der Plugbox, ~15min
rm Plugbox-Linux-1.1-rootfs.tar.gz

10.)Den USB-Stick einstecken, falls nicht schon geschehen und die Box neustarten. Auf das Beste hoffen ;D

/sbin/reboot

11.)Nach dem Neustart ist die alte IP natürlich nicht mehr gültig. Die Box bezieht sie über DHCP, sofern ein entsprechender Router/Server vorhanden ist. Bewaffnet mit der MAC könnt ihr ja mal im Listing der auf dem Router angemeldeten Geräte nachschauen. Keys und DynDNS werden Vielnutzer von ssh bestimmt kennen und schätzen. Wenn nicht – es ist definitiv einen Versuch wert.

——

Weiterführendes findet ihr hier. Debian-Fans finden hier etwas – hat bei Adi64 und mir leider nicht funktioniert.

Wer Gentoo ausprobieren möchte, wird hier fündig.

Diejenigen, die etwas mit ihrer LED tun möchten, werden hier glücklich.

Beispiel: Mit folgenden 3 Befehlen blinkt die LED bei jeder ssh-Aktion auf der Box orange:

modprobe xt_LED #Treiber laden
iptables -A INPUT -p tcp --dport 22 -j LED --led-trigger-id web --led-delay 100
echo netfilter-web > /sys/class/leds/dockstar\:orange\:misc/trigger

]]> http://adrian.holfter.de/blog/2010/09/archlinux-auf-der-seagate-dockstar/feed/ 33 http://adrian.holfter.de/blog/2010/07/begrusung-in-der-shell/ http://adrian.holfter.de/blog/2010/07/begrusung-in-der-shell/#comments Sun, 18 Jul 2010 13:12:43 +0000 ADI64 http://adrian.holfter.de/blog/?p=273 Das Programm “fortune” gibt (pseudo)zufällige Sprüche zum Besten, die es aus bestimmten Dateien entnimmt.

“cowsay” nimmt einen Text und zeigt ihn in einer Sprechblase mit einer Kuh (oder eben mit Tux) in ASCII-Art-Manier an.

Kombiniert und ans Ende der ~/.bashrc (oder ~/.zshrc oder was ihr eben für eine Shell benutzt) geschrieben gibt es beim Öffnen einer Shell instant Awesomeness!

# Make tux say something
fortune -e sprueche linuxcookie chucknorris archlinux | cowsay -f tux

Zuerst einmal hat man die Wahl zwischen splashy und fbsplash. Ich habe mich für fbsplash entschieden und werde es in diesem Artikel behandeln.

fbsplash findet man im AUR und im Wiki eine sehr gute Einführung dazu. Ich bin den Leitfaden mehrere Male durchgegangen und immer wieder auf die gleiche Problematik gestoßen:

• Beim Hochfahren bekomme ich eine Fehlermeldung: ‘fbsplash was unable to start…theme not found’
• Beim Herunterfahren funktioniert der Splash

Abhilfe lässt sich mit folgender kleinen Änderung an den Kernelargumenten schaffen:

logo.nologo quiet console=tty1 vga=792 splash=silent,fadein,
fadeout,theme:<theme-name>

Den oben rot markierten Framebuffer-Wert gilt es nun mit dem gewünschten (und vom  Theme unterstützten!) Auflösungswert zu ersetzen, damit der Framebuffer auf den Wert gesetzt ist für den das Theme in /etc/conf.d/splash konfiguriert wurde – sonst startet fbsplash einfach nicht und es gibt die bekannte Fehlermeldung. Über diesen gesuchten Wert gibt uns folgender Befehl Aufschluss:

# hwinfo --framebuffer

hwinfo im AUR

In meinem Fall sähe die geänderte Argumentzeile folgendermaßen aus:

logo.nologo quiet console=tty1 vga=0x0324 splash=silent,fadein,
fadeout,theme:archax

Natürlich kann man die 0×0324 auch in 804 konvertieren und hinter vga= schreiben, das ist aber reine Geschmackssache.

Ich vermute, dass die Startschwierigkeiten entweder mit meiner x86_64-Version von Arch zusammenhängen oder mit meiner Hardware:

AMD Phenom II X4 955 BE

4GB OCZ DDR3-1600

ATI Radeon HD 4870 Vapor-X 2GB von Sapphire

Im Wiki ist nämlich auch ein Wikipedia-Artikel mit den Framebuffer-Codes verlinkt, die für 1280×1024 funktionieren sollen – bei mir tun sie es _nicht_: *klick*

Nachdem fbsplash nun bei mir startete, flackerte es kurz nach seinem Start und wurde nach links verschoben – irgenwdie unschön. Die einzige Lösung die ich dafür finden konnte, war folgende Änderung an /etc/mkinitcpio.conf vorzunehmen und damit den Start von fbsplash hinter die Änderung der Bildschirmauflösung durch den Kernel zu legen:

HOOKS=”base udev fbsplash autodetect pata scsi sata filesystems”

ändern zu

HOOKS=”base udev autodetect pata scsi sata filesystems fbsplash“

Es funktioniert, aber man sieht eben mehr von der Konsole und weniger vom Splash.

Für jegliche Lösungsvorschläge bin ich dankbar!

Das Bild friert ein und es ist auch nicht mehr möglich, auf die anderen virtuellen Konsolen zu wechseln. Lokal bleibt einem also nichts anderes über, als das System über SysRQ mit der magischen Kombination “REISUB” halbwegs sicher neuzustarten.

Mit einem zweiten PC kann man sich allerdings auch noch über SSH noch einloggen (so man dies aktiviert hat) und dort manuell X mit einem “kill -9 $pid” abschießen. Daraufhin startet GDM den X-Server neu und man kann sich wieder einloggen. Allerdings sind alle Programme beendet, die im X gestartet wurden, was das Ganze extrem nervig macht: Jeder Druck auf die Enter-Taste könnte fatale Folgen für die offenen Dateien haben.

Weder in /var/log/everything.log noch in /var/log/Xorg.0.log.old lässt sich etwas finden, was auf einen Crash hindeutet.

Das Problem ist schon im ArchLinux Bugtracker vorhanden und es gibt auch einen Workaround dafür: GDM muss als letzter Daemon in der /etc/rc.conf stehen, also als letzter Daemon starten. Seitdem hatte ich keinen Crash mehr. Warum das so ist, ist mir völlig schleierhaft.  Im DAEMONS-Array standen nach gdm nurnoch “httpd mysqld cups”, die an sich ja überhaupt nichts mit dem X-Server und noch weniger mit Gnome zu tun haben. Aus irgendeinem Grund funktioniert dies aber…