Zugschlusbeobachtungen (Entries tagged as grml)

grml als eigenes Rescuesystem

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 30 Aug 2009 15:21:00 +0200

Diesen Artikel habe ich schon im Mai 2009 geblogged. Allerdings hat sich grml seitdem so dramatisch weiterentwickelt, dass ich ihn aktualisiert und mit neuem Datum versehen habe.

Update: Das hier beschriebene Verfahren funktioniert seit grml 2011.12 nicht mehr. Der Way to Go is nun grml-rescueboot.

In Mietserver-Recovery mit veraltetem Rescuesystem habe ich beschrieben, wie man grml aus dem komprimierten Image von einer Festplatte booten kann, was zum Beispiel für Rescue-Zwecke an einem Server ohne direkt zugängliche Konsole sehr praktisch sein kann. Zu dieser Zeit (der Artikel stammt aus dem März 2007) war das noch eine größere Operation mit “CD-Image loopback mounten, die einzelnen Dateien rauskopieren und an die richtige Stelle im Dateisystem werfen”, mit neueren grml-Versionen ist es aber noch viel einfacher geworden.

Neueres grml (die hier beschriebenen Verfahren sind mit dem daily grml-small_sid vom 17. August 2009 getestet) erspart einem einen Teil des Lottos, denn mit Hilfe der isofrom-Option kann sich grml beim booten selbst die benötigten Daten direkt aus einem .iso-File ziehen. Das könnte einem die Artistik mit dem Loopback-Mount zur Installationszeit ersparen, wenn man nicht Kernel und initrd bräuchte, bevor grml in der Lage ist, direkt auf das .iso zuzugreifen. grub 0.9 bracht kernel und initrd noch direkt im Boot-Dateisystem, und so muss man sich seine Dateisystemstruktur doch selbst aus dem .iso zusammenkratzen.

Damit reicht dann aber auch ein

title grml-small
root (hd0,0)
kernel /grml/linux26 quiet vga=791 lang=de boot=live noeject noprompt keyboard=de findiso=/grml/grml.iso
toram=grml-small-daily-sid.squashfs
initrd /grml/initrd.gz

und das grml bootet aus diesen drei Dateien. Das macht natürlich das Updaten verhältnismäßig einfach.

grub2 kann direkt ein .iso-File loopback mounten und auch kernel und initrd direkt aus dem .iso laden. Somit reicht es, im Updatefall einfach ein neues .iso an die passende Stelle im Dateisystem zu werfen, und fertig ist man. Die dafür notwendige grub2-Konfiguration ist diese hier:

menuentry “grml” {
loopback loop (hd0,1)/grml/grml.iso
linux (loop)/boot/grmlsmalldailysid/linux26 quiet vga=791 lang=de boot=live noeject noprompt keyboard=de
findiso=/grml/grml.iso toram=grml-small-daily-sid.squashfs
initrd (loop)/boot/grmlsmalldailysid/initrd.gz
}

Dank der bekanntermaßen tollen Dokumentation für grub2 (eine Erklärung, wie die neue grub.cfg aussieht, habe ich in keiner der automatisch installierten Packages für grub2 gefunden, und grub2-doc gibt es nicht) hätte ich das allerdings ohne Mikas Hilfe nicht rausbekommen. Doch dazu noch ein anderer Artikel in diesem Blog.

Die Pfade innerhalb des .iso variieren mit dem Image-Flavor (z.B. Released, oder daily image, basierend auf sid, testing, stable, grml, grml-medium, grml-small), hier muss man noch ein wenig aufpassen. Und der Loopback-Mount funktioniert nur, wenn dem grub2 die Mondphase gerade passt (siehe auch Debian Bug #543924).

Mit der Bootoption ssh=password kann man dem System beim Booten sagen, dass es einen ssh-Server starten soll und das Passwort für den User grml auf das angegebene Passwort setzen soll. Wenn ein DHCP-Server im Netz vorhanden ist und korrekte Informationen ausgibt, kann das System somit direkt ohne Konsolenzugang übers Netz erreicht werden.

Etwas komplexer wird es, wenn das System nicht per DHCP ans Netz gebracht werden kann. Aber auch hierfür hat grml (nicht nur ein einziges) Bordmittel bei sich. So kann man z.B. mit der Bootoption scripts ein innerhalb des .iso liegendes Script beim booten ausführen. Grml kann auch nach einem Dateisystem mit dem Label GRMLCFG suchen und sich das Script aus dessen Root Directory holen. Das passt allerdings nicht so schön in ein Setup, in dem das grml nur das Rescuesystem ist.

Die grml daily images ab dem 17. August sind auch in der Lage, die Koordinaten zu dem Startscript von der Kommandozeile zu beeinflussen. Die Bootoptionen myconfig=/dev/sda1 scripts=boot/grml/network.sh veranlassen grml zum Beispiel, nach dem Start das Script /boot/grml/network.sh von dem Dateisystem auf /dev/sda1 zu starten. Wenn man dort ein Script nach der Machart von

#!/bin/sh
ip link set dev eth0 up
ip addr add dev eth0 192.168.8.240/24 brd +
ip route add default via 192.168.8.254
echo “nameserver 192.168.8.254” > /etc/resolv.conf
echo “grml:1234” | chpasswd
/etc/init.d/ssh start

hinterlegt, kommt das System mit den hier eingestellten Netzwerkparametern hoch, setzt ein Passwort für den User grml und startet den sshd. Dann muss man noch verhindern, dass einem der DHCP-Client dazwischenfunkt (Bootoption dhcp) und man kann das System komplett ohne Mitarbeit der RZ-Infrastruktur zu Rettungsmaßnahmen ans Netz bringen.

Insgesamt arbeite ich also inzwischen mit dem Grub-Eintrag

title grml-small
root (hd0,0)
kernel /boot/grml/linux26 quiet vga=791 lang=de boot=live noeject noprompt keyboard=de
findiso=/boot/grml/grml-small_sid_20090817.iso toram=grml-small-daily-sid.squashfs nodhcp myconfig=/dev/sda1
scripts=boot/grml/network.sh
initrd /boot/grml/initrd.gz

Ein Hoch auf grml, die tägliche Arbeit wird jeden Tag etwas einfacher.

Und hier noch ein Script für grub2, das beim Aufruf von update-grub automatisch für jedes gefundene grml-Image einen korrekten Booteintrag erzeugt:

#!/bin/sh
set -e

. /usr/lib/grub/update-grub_lib
list=$(for i in /boot/grml/grml*.iso ; do
        if grub_file_is_not_garbage “$i” ; then echo -n “$i ” ; fi
      done)

while [ “x$list” != “x” ] ; do
  grml=$(version_find_latest $list)
  echo “Found grml image: $grml” >&2
  basename=“$(basename $grml .iso)”
  dirname=“$(dirname $grml)”
  rel_dirname=“$(make_system_path_relative_to_its_root $dirname)”
  kernel=“$(isoinfo -f -J -i $grml | grep ‘linux26$’)”
  initrd=“$(isoinfo -f -J -i $grml | grep ‘initrd\.gz$’)”
  squashfs=“$(basename $(isoinfo -f -J -i $grml | grep ‘\.squashfs$’))”

  cat << EOF
menuentry “$basename” {
  loopback loop $rel_dirname/${basename}.iso
  linux (loop)$kernel quiet vga=791 lang=de boot=live noeject noprompt keyboard=
  initrd (loop)$initrd
  }
EOF

  list=$(echo $list | tr ' ' ‘\n’ | grep -vx $grml | tr ‘\n’ ' ‘)
done

The Admin Zen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 14 Apr 2008 11:54:00 +0200

http://adminzen.org/. Danke Mika.

Mietserver-Recovery mit veraltetem Rescuesystem

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 24 Mar 2008 23:07:00 +0100

Den First Dedicated Power Server S Limited Edition benutze ich seit ziemlich genau einem Jahr als Entwicklungssystem. Da die Kiste ausschließlich verschlüsselt mit der Außenwelt spricht, sind die Schwächen im Netzwerksetup des Hosters für meine Anwendung irrelevant. Als nicht irrelevant zeigten sich vor einigen Wochen die Macken im Rescuesystem, als ein Umstieg auf neue Hardware anstand.

Mein Server hat im Herbst letzten Jahres angefangen, SMART-Fehlermeldungen zu werfen, und Anfang Februar wurde es mir dann zu bunt, so dass ich ein Ticket beim Hoster aufgemacht habe. Der Hoster findet bei einer oberflächlichen Prüfung des Systems, die mit einem knappen halben Tag Downtime verbunden war, keine Fehler und tauscht mir kulanterweise das PATA-Kabel. Leider hilft das nicht, die SMART- und CRC-Fehler im Syslog tauchen schnell wieder auf.

Als nächstes versucht der Hoster, die Schuld auf mein System zu schieben (“Fehlerhaftes Dateisystem oder Bugs im verwendeten Kernel”) und möchte, dass ich den Server neu aufsetze. Ich versuche das erstmal zu vermeiden und versuche das Problem mit dem Rescue-System zu reproduzieren. Das erweist sich aber als leichter gesagt als getan, denn das Rescuesystem ist - ich berichtete - so alt, dass ich damit meine Filesysteme nicht eingehängt bekomme. Und durch irgendwelche dd-Übungen ist das System nicht zum Werfen von CRC-Fehlern zu bringen.

Also rsynce ich die Daten zähneknirschend auf einen anderen Server (um mir das Restore vom Wohnungs-Backup über mein dünnes ADSL zu ersparen), mache eine Neuinstallation auf das Uralt-Standardimage des Anbieters, update auf aktuelles Debian etch mit security-Updates und beginne meine Daten draufzukopieren. Keine fünf Minuten später beginnen wieder die CRC-Fehler.

Nun ist der Hoster auch überzeugt und bietet mir den Tausch gegen eine komplett neue Maschine an, die dann auch eine neue IP bekommt. Das stört mich nicht, da ich das System ja nur inten verwende, also stimme ich zu. Leider ist es nicht möglich, Zugang auf beide Maschinen gleichzeitig zu bekommen; zuerst wird die alte abgeschaltet und dann für die neue Zugangsdaten generiert. Am Abend desselben Tages kommen die Zugangsdaten für die neue Kiste; ab dem ersten Kontakt bis hier sind sechs Tage vergangen.

Die Zugangsdaten für den neuen Server teilen mir mit, dass ich mich in das Rescuessystem mit grml@ip-adresse einloggen soll. Das funktioniert allerdings nicht, und das auf Port 22 sichtbare Banner mit dem String “Debian woody” lässt vermuten, dass ich es hier auch nicht mit einem grml zu tun habe, sondern mit dem “alten” Rescuesystem. Nach einer Stunde sind dann auch die Zugangsdaten in das System konfiguriert und ich kann mich endlich - als root - anmelden.

Wie schon im Servertest erwähnt, ist das Rescesystem von First Dedicated uralt. Es basiert irgendwo auf Debian woody, hat weder LVM-Support im Kernel noch die Userspace-Tools installiert und läuft noch mit Linux 2.4. Damit direkt mein LVM- und Linux-2.6-basierendes System wieder draufzuklatschen ist illusorisch. Also anders.

Ich entschliesse mich, wie schon bei einem anderen Hoster neulich durchgespielt, ein grml-small in die swap-Partition zu installieren. Aber dann kommt mir die Idee, dass das gar nicht not tut: Ich habe doch ein nicht im LVM liegendes ext2-Filesystem, nämlich das System, das im Produktivbetrieb als root eingehängt ist. Spricht eigentlich nichts dagegen, das grml dort abzulegen - dann steht es schneller zur Verfügung, wenn im Notfall das Root-Filesystem noch da ist. Wenn es nicht mehr da ist, kann man dann immer noch den Stunt mit dem swap-Filesystem machen.

Also wird schwupps die Platte partitioniert, das root-Filesystem auf hda1 angelegt und dessen Inhalt aus dem Backup zurückgeschoben. Nach /boot/grml kommt der Inhalt einer grml-small-CD. grml-medium hatte ich zu dem Zeitpunkt noch nicht ausprobiert; der Trick hätte aber nach den einschlägigen Erfahrungen aus der Erstellung meines Universal-Boot-Sticks auch mit grml-medium funktioniert.

Die für grml-small gültige Boot-Eintragung lautet:

title           grml
root            (hd0,0)
kernel          /boot/grml/linux26 toram grml_dir=/boot/grml/GRML/ grml_name=GRML toram ramdisk_size=100000
init=/etc/init lang=us BOOT_IMAGE=grml ssh=M9flN0A1
initrd          /boot/grml/minirt26.gz

und ich schätze, dass die für grml-medium irgendetwas rund um

title           grml-medium
root            (hd0,0)
kernel          /boot/grml/boot/grmlmedium/linux26 live-media-path=/grml-medium/live/ toram=grml-medium.squashfs lang=us
boot=live noeject noprompt keyboard=de
initrd          /boot/grml/boot/grmlmedium/initrd.gz

heißen müsste. Das hab nich aber nicht ausprobiert.

Nun nur noch grub auf der Platte installieren. Unter Debian liegt das grub-Binary in /usr und steht somit im vorliegenden Zustand des Systems nicht zur Verfügung; das Rescuesystem hat kein grub. Also schwupps die binäre grub-Package aus Debian stable gezogen, mit dpkg-deb ausgepackt und... festgestellt, dass die Libraries des Rescuesystems zu alt sind um das dynamisch gelinkte grub-Binary auszuführen. Ich spare mir den Bugreport “please build a new package with statically linked grub”, weil grub in Debian nicht mehr wirklich gepflegt wird - die Maintainer sind der Meinung, dass man die Arbeit besser in grub 2 stecken sollte, und ich bin der Meinung, dass bis zur rudimentären Benutzbarkeit von grub 2 noch ein wenig Wasser den Neckar wird herunter fliessen müssen.

Statt dessen wird /boot/grub in /boot/grub-backup umbenannt, ein historisches grub aus woody ausgepackt, die stages nach /boot/grub geschoben, menu.lst kopiert und auf der grub-shell installiert. Da der Server keine serielle Konsole hat, muss mit dem default-Keyword gearbeitet werden (die Einträge zählen ab Null, #451709), und schwupps läuft das grml.

Der Rest ist schnell erzählt: LVM bauen, Filesysteme anlegen, Daten zurück-rsyncen, chroot ins frisch restorete System, IP-Adresse anpassen, /boot/grub nach /boot/woody-grub umbenennen, /boot/grub-backup zurückschieben, “aktuellen” grub neu installieren, booten und Produktivbetrieb aufnehmen. Das grml bleibt da für zukünftige Aktionen liegen, mit dem aktuellen Grub lässt es sich ja auch nach Anpassung des Default-Wertes in der menu.lst kurzfristig booten.

Universal boot stick for Debian, grml and the Debian installer

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 19 Mar 2008 23:27:00 +0100

For various reasons, I have the kernel and the initrd that my notebook needs to boot Linux on an USB stick. I recently added the Debian Installer and grml to the stick to allow additional uses of the stick.

Usually, USB sticks are formated with FAT32 and when they’re used to boot Linux, Syslinux or some derivative is used.

I do it differently on my boot stick, most prominently because I’d like to have Unixoid privileges on the stick, and because I’d like to continue using grub. So, my stick is formatted as ext3, and feels like an additional hard disk.

Booting from an USB stick is sometimes tricky. I have made the best experiences with formatting the USB stick as an USB ZIP, which basically means having 64 heads, 32 sectors and a single partition in the fourth primary partition slot. This can be done using mkdiskimage and is documented on Debian in /usr/share/doc/syslinux/usbkey.doc. Partitioning and generation of the file system is as straightforward as is installing grub using the standard, documented methods for hard disks.

I tried using grub 2, but have found it not sufficiently well-documented and stable to be used in this kind of critical environment. I am therefore still using grub-legacy despite the fact that the grub maintainers have ceased fixing grub-legacy bugs some months ago, refering to the pending release of grub 2.

I use unison to keep /boot on the stick in sync with /boot of the Linux system, which is on a crypted filesystem on the hard disk and thus unuseable until the system has booted. The hard disk /boot thus serves only as installation target and sync source so that the stick does not need to be plugged in during upgrades. update-grub is configured so that running it creates a menu.lst which can be used from the stick. This concludes booting the production system from the stick.

For the other systems, I have decided not to put them in the “default” boot menu from menu.lst, but instead include foo.lst files to the root of the stick, and when I need them, shell out from the grub menu to a command line by pressing “c” and then pulling in the new grub config file with the “configfile /foo.lst” command.

grml is my favorite rescue system. I use it all the time once a system starts acting up. One of its biggest advantages is its extremely flexible bootup process. That made it predestined to be the rescue system on my USB boot stick. grml is currently making a transition to a new build environment, which has had the side effect that the boot process has changed in some details. grml-small, the 60 MB variant that I had been using before, has been discontinued and replaced by grml-medium, a 170 MB variant which does definetely not fit any more on a business card CD, but 128 MB USB sticks have become relatively seldom.

For both grml flavours, all one needs to do is mount the .iso file loopback, copy the file’s contents to a subdirectory of the boot stick, and to drop this menu file to the stick:


title           grml-small
root            (hd0,3)
kernel          /grml-small/boot/isolinux/linux26 toram grml_dir=/grml-small/GRML/ grml_name=GRML ramdisk_size=100000
init=/etc/init lang=us BOOT_IMAGE=grml
initrd          /grml-small/boot/isolinux/minirt26.gz

title           grml-medium
root            (hd0,3)
kernel          /grml-medium/boot/grmlmedium/linux26 live-media-path=/grml-medium/live/ toram=grml-medium.squashfs
lang=us boot=live noeject noprompt keyboard=de
initrd          /grml-medium/boot/grmlmedium/initrd.gz

Since grml-medium works reasonably well, I do not expect to need grml-small very often any more.

The Debian Installer guys have published an initrd which can browse nearly arbitrary media for an debian-installer .iso file, mount it and install from that image. I have made use of that feature to allow Debian to be installed from my boot stick. /d-i holds a current debian-testing-i386-netinst.iso, and vmlinux and initrd.gz from http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386/current/images/hd-media/. With that, this d-i.lst:


title debian installer
root (hd0,3)
kernel /d-i/vmlinuz
initrd /d-i/initrd.gz

does the trick and boots up the Installer, ready to start.

I guess that it would be easily possible to include these grub config stanzas to the default menu.lst, including grml and the Installer into the main grub menu, but I deliberately decided not to have these options directly in the menu for the time being.

It is always amazing how flexible today’s systems have become when it comes to boot Linux. For both rescue and installation, this is needed, and the respective authors have done a remarkable job.

using grml to prepare LVM surgery

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 29 Mar 2007 00:00:52 +0200

One of my dedicated servers was in bad need of major LVM surgery today. Since the rescue system delivered with the server by the housing provider suffers from lack of LVM support, I needed to pull a creative stunt with grub and grml to accomplish this.

The dedicated server rented from strato is the Box I tested in a different article. Installing the LVM-based Debian system via the LVM-less rescue system involved first installing without LVM in the partition which was originally supposed to be swap, booting the just installed system and using this temporary system to finally bootstrap the target.

I had originally planned to go this way again in case rescue should become necessary. Today, I checked first whether the provider supplied rescue system had improved in the mean time (which it hadn’t), and I didn’t feel like installing a new temporary system. Instead, I decided to go through a different route, using grml.

grml is extremely versatile regarding boot. All you need is to get the grml kernel to boot and point it towards the grml initrd, and the initrd automatically searches the available drives for the compressed file system image, mounts it and continues the boot process. This was the point where I hooked myself into grml. I put an ext3fs on the swap partition and copied the contents of a grml CD to that partition. After thinking a while about how to get ISOLINUX to boot this grml, I remembered that the disk already has grub installed, and decided to use grub to boot grml.

This was possible because the provider offers a serial console for the machine. If no serial console had been available, things would have been a lot harder since there would be no feedback and one would have to talk to grub via offline editing of menu.lst. Thanks to the serial console, things were a lot faster.

Booting grml via grub is actually easy. After finding out which partition grml is on (find /linux26) and setting this partition as root, all you need is “kernel /linux26 ramdisk_size=100000 init=/etc/init lang=us BOOT_IMAGE=grml console=ttyS0,57600n8”, “initrd /minirt26.gz” and finally “boot”.

The “57600” given on the kernel command line was actually the hardest part: Strato operates the serial console at unusual 57600 bps, and grml’s serial console feature starts mgetty with hard-coded 9600 bps. The rather frustrating symptom was that you can watch grml booting, with “Finished execution of main grml startup” as the last sign of life. Knowing that there is a login prompt waiting for you at the wrong baud rate.

After talking to Mika from the grml team for some minutes, we decided to take two “roads” to solve the issue. Mika hacked grml’s startup process to parse the baud rate to be used for mgetty from the kernel command line. Since I couldn’t wait for Mika’s fix, I used a grml.sh script to put a fixed mgetty.config over the file contained in grml. After fixing some stupid mistakes on my part, I finally received my grml login prompt and could start with the LVM surgery.

Grml is a perfect tool for such tasks since it is extremely flexible and not selective in which medium and partition types it can boot from. It has saved me a lot of grief today and has helped me in solving a difficult problem.

Oh, btw, pvmove --alloc anywhere can move a logical volume inside a pysical volume without the need of a temporary physical volume, and it is thus possible to “manually” defragment a physical volume in order to allow more clean resizing of logical values. While it is debateable whether this does really make sense, it satisfies my sense of order to have an LVM setup unfragmented.

Adieu, Knoppix

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 11 Jul 2005 13:23:18 +0200

Vor einigen Wochen habe ich (<d68fl1$mm0$1@news1.tnib.de>) nach einer Debian-basierten Live-CD-Distribution gesucht. Inzwischen habe ich eine gefunden:grml-small.

Nachdem ich einige, darunter

mehr oder weniger oberflächlich betrachtet und verworfen hatte, bin ich schliesslich von Mika auf grml hingewiesen worden. Es entstand eine sehr fruchtbare Diskussion, in die ich meine Erfahrungen mit meinem lokalen Knoppix-Light-Projekt einfliessen lassen konnte.

Das Ergebnis ist grml-small 0.1, zu dem ich außer meinen Wünschen nur noch meinen Namen beisteuern konnte. Den Rest hat Mika sehr zufriedenstellend erledigt. So hat man das gerne: Oben die Wunschliste einkippen, unten das Ergebnis rausbekommen. Fein.

Was noch zu erledigen ist, findet sich hier, das offizielle Release-Announcement dort und die Liste der installierten Software dort.

Sehr interessant ist auch das Feature, grml-small von einem USB-Stick zu booten. Da kann man dann nämlich auch gleich eine IP-Konfiguration mitliefern, womit das Rescue-System für entfernt stehende Systeme perfekt ist. Systeme, die nicht von USB booten können, bekommen (hoffentlich) in einer zukünftigen Version etwas Magie, um kundentauglich eine IP-Konfiguration von Irgendwo[tm] zu lesen.