Linux auf dem Fujitsu (-Siemens) Scaleo Home Server =================================================== 2009-05-16 .. 2011-05-29, solyga@xulin.de 1. Hardware-Hürden ------------------ Das Konsolenproblem: - keine Grafikkarte Obwohl lspci (u.a.) "VGA compatible controller: Intel Corporation 82945G/GZ Integrated Graphics Controller (rev 02)" sagt, ist keine VGA/DVI-Schnittstelle herausgeführt; auch nicht auf einem Pfostenstecker o.ä. (soweit ich das beurteilen kann). Allerdings gibt es wohl einen PCIe x1 Steckplatz, der mittels Riser-Platine anzapfbar wäre. In Ermangelung derartiger Hardware habe ich das (noch?) nicht weiter verfolgt. - keine Tastatur Nix PS/2, auch nicht intern (soweit ich das beurteilen kann). Bleibt also nur USB. Habe das aber (in Ermangelung einer USB- Tastatur) nicht ausprobiert, weil es ohne Grafik nicht viel bringt. - keine serielle Schnittstelle (soweit ich das beurteilen kann) UPDATE 2009-05-20: Anscheinend handelt es sich beim Intel SS-4200 NAS Device um dieselbe Hardware. Gemäß http://ss4200.pbworks.com/ gibt es einen Pfostenstecker auf dem Motherboard. Dann wäre sogar das BIOS einstellbar... (probiere ich wegen Lötarbeiten ggf. später) Ein Linux muß daher blind gebootet werden, bis ein sshd erreichbar ist. Das Bootproblem: - kein Floppyanschluß Zwar sind inzwischen die übliche Rescue- und Install-Systeme (Debian hat keine Floppyversion des Installers mehr!) sowieso zu groß; aber auch etherboot per Floppy fällt damit aus. - SATA/PATA/ATAPI-Geräte Das Mainboard treibt 4 SATA-Platten, auf deren erster sich das OS "Windows Home Server" breitmacht (die zweite Platte wurde genullt ausgeliefert). Außerdem hat es einen PATA-Anschluß, auf dem ein 256MB-Flash-Modul (als Master konfiguriert) steckt. Der Beschreibung zum "Server-Recovery" zufolge wird von diesem Modul gebootet, wenn man beim Anschalten die Recovery-Taste (wie bei Routern) zusätzlich drückt. Die Bootreihenfolge ist also offenbar SATA, USB im Normal- und PATA, SATA, USB im Recovery-Modus. Es ist mir nicht gelungen, von einer PATA-Festplatte zu booten, habe aber auch keine weitere Energie reingesteckt. Booten vom PATA-Flash-Modul geht aber. Booten von USB-Stick funktioniert, wenn man alle SATA- und PATA- Geräte abzieht (oder bootunfähig macht vermutlich). Ohne Platten zu booten hilft aber für die Installation wenig. Das einfachste war, das Flash-Modul mit einem Live-System zu versehen; es kann dann später auch bequem als Rescue-System dienen. 2. Rescue-System auf dem Flash-Modul ------------------------------------ Knoppix erschien mir zu groß, weshalb ich grml.org probiert habe. Die Doku ist nicht gerade umwerfend, aber mit etwas Arbeit ausreichend. Ich gehe im folgenden davon aus, daß eine funktionierende USB-Stick- (oder Festplatten-) Version (Live-System) von grml-small vorhanden ist. Wie man das macht, steht hier: http://wiki.grml.org/doku.php?id=usb. Der folgende Absatz beschreibt zunächst dessen Modifikation. Per default startet grml keine Netzwerkdienste und läßt auch kein login zu (Konsolen laufen ohne login), so daß man um eine Konfiguration nicht herumkommt. (Modifikation fiel bei mir erstmal aus, weil das rootfs squashfs ist, und mir dafür tools und Kernel- Support fehlen.) Zum Starten der ssh ändert man syslinux.cfg und übergibt dem Kernel den (zusätzlichen) Bootparameter "services=ssh". Um sich per ssh einloggen zu können, erzeugt man ein mit einem root- Passwort versehenes /etc/shadow, packt das in config.tbz ein (kann man alles in grml selbst machen, z.B. in einer vom Stick gebooteten VM) und stellt dieses Archiv grml zur Verfügung. Weil ich es sowieso brauchte, habe ich es per Netzwerk gemacht. (Aber es ginge vermutlich auch über den Stick selbst, indem man dem FAT-System das Label "GRMLCFG" verpaßt und config.tbz dort ins Rootverzeichnis spielt.) Dann gibt man dem Kernel einen weiteren Parameter mit: "netconfig=http://linux.xulin.de/scaleo/config.tbz". Achtung: Ohne "http://" erfolgt ein ftp-Zugriff! Im Falle GRMLCONFIG braucht man das vermutlich nicht, weil lokale Geräte per default ohnehin gescannt werden. Wenn man im httpd-log den Download sieht, ist das System schon fast vollständig initialisiert. Zugriff per ssh mit Passwort sollte jetzt gehen. (Man kann /etc/ssh/ssh_host_*_key* mit ins config.tbz packen, damit man nicht ständig known_hosts auf dem Client anfassen muß.) Ist der USB-Stick soweit einsatzfähig (getestetermaßen), wird das IDE-Flash-Modul bespielt. Ich habe das in einem extra PC gemacht: Flash-Modul als einzige Festplatte und ein Live-System gebootet, z.B. gleich grml vom USB-Stick. Prinzipiell geht das genauso, wie die Installation auf dem USB-Stick. Nur kann jetzt syslinux.cfg unmodifiziert übernommen werden. 3. Endgültiges System auf der ersten SATA-Platte ------------------------------------------------ Wenn man einen vollwertigen Server auf dem SCALEO haben will, kommt man nicht drumrum, etwas von einer SATA-Platte zu opfern. Denn einerseits erscheint das Flash-Modul überhaupt nicht, wenn man den SCALEO im normalen Modus bootet, und andererseits soll der RAM nicht unnötig für das rootfs verschwendet werden (/var auf dem Flash-Modul entfällt ohne weitere Diskussion). 2009-05-16 -- MARK -- 2009-05-20 -- MARK -- Etwas nervig für mich ist, daß grml sein rootfs per default von /dev/sda1 nimmt, und der SCALEO/grml-kernel trotz boot vom Flash-Modul zuerst die SATA-Platte(n) listet und das IDE-Flash-Modul erst als letztes: root@grml ~ # dmesg| grep "scsi " [ 3.623489] scsi 0:0:0:0: Direct-Access ATA WDC WD10EACS-07D 01.0 PQ: 0 ANSI: 5 [ 3.634595] scsi 1:0:0:0: Direct-Access ATA WDC WD10EACS-07D 01.0 PQ: 0 ANSI: 5 [ 3.991010] scsi 4:0:0:0: Direct-Access ATA TRANSCEND 2.0 PQ: 0 ANSI: 5 Das passiert natürlich nur, wenn man - wie ich zum Testen - grml bereits auf der ersten SATA-Platte installiert hat. Abhilfe schafft Löschen: root@grml ~ # mount -o remount,rw /live/image/ root@grml ~ # rm -rf /live/image/* Nach einem Reboot (Recovery-Modus natürlich) ist alles schön: root@grml ~ # mount | grep live/image /dev/sdc1 on /live/image type vfat (ro,noatime,fmask=0022,dmask=0022,allow_utime=177777,codepage=cp437,iocharset=iso8859-1) Zur Installation von Debian via debootstrap ist zunächst /etc/debootstrap/config anzupassen und die zu verwendende Platte zu partitionieren. Dann kann es losgehen: root@grml ~ # grml-debootstrap Nach geraumer Zeit ist die Installation beendet. Seltsamerweise war eth0 bei mir nicht konfiguriert, also Debian-root mounten, reinwechseln und die eth0-Zeilen in etc/network/interfaces aktivieren. Reboot (jetzt im Normal-Modus), auf sshd warten -- das root-Passwort wurde von grml übernommen, und sshd wird per default gestartet. Wie schon erwähnt taucht das Flash-Modul nicht auf. Rekonfiguration des Rescue-System muß daher aus diesem selbst passieren, oder man steckt das Modul in einen anderen Rechner... Alles weitere kann nun in Debian selbst passieren. Übrigens: Stromverbrauch mit beiden 1-TB-Platten: 41 W. 4. Neues Rescue-System auf dem Flash-Modul ------------------------------------------ 2011-05-06 -- MARK -- Beim Einbau der 2-TB-Platten habe ich mich aus diversen Gründen dazu entschlossen, ein aktuelles grml (2010.12 small) auf das Flash-Modul zu bringen. Mit mkimg.sh wurde das FAT-Image erzeugt, per NFS gemountet und (ohne Partitionierung) auf das Flash-Modul geschrieben. Komischerweise wird bei ifup hostname=localhost gesetzt, was sich auch nicht per "append hostname=grml" verhindern läßt. Einloggen tut man sich als user grml per ssh; root wird man per "su". Das config.tbz entfällt und damit auch die Abhängigkeit von irgendeinem Webserver. Einzig ein DHCP-Server wird benötigt. Stromverbrauch mit zwei (zusätzlichen) 2-TB-Platten: 50W. root@dada:~# fdisk -l Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x4bc13b85 Device Boot Start End Blocks Id System /dev/sda1 1 131 1052226 82 Linux swap / Solaris /dev/sda2 132 2221 16787925 83 Linux /dev/sda3 2222 121601 958919850 83 Linux Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x72cdc2fe Device Boot Start End Blocks Id System /dev/sdb1 1 121601 976760001 83 Linux Disk /dev/sdc: 2000.4 GB, 2000398934016 bytes 255 heads, 63 sectors/track, 243201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xeb623917 Device Boot Start End Blocks Id System /dev/sdc1 1 243201 1953512001 83 Linux Disk /dev/sdd: 2000.4 GB, 2000398934016 bytes 255 heads, 63 sectors/track, 243201 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xcd28b5bb Device Boot Start End Blocks Id System /dev/sdd1 1 243201 1953512001 83 Linux