Zugschlusbeobachtungen (Entries tagged as usb)

Produkt-Idee fuer die Installation von Betriebsstemen

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 07 Oct 2008 22:02:23 +0200

Wie oft habe ich mir schon einen USB-Stick gewünscht, auf den man eine .IMG-Datei mit 1.44 MB Größe oder eine .ISO-Datei ablegen kann und der sich dann, ggf. nach entsprechender Konfiguration, nicht als generische USB-Storage, sondern als USB-Floppy oder USB-CD-ROM zeigt.

Auf dieser Weise könnte man störrischer Software, z.B. den Desktop-Betriebssystemen des Marktführers oder BIOS-Update-Tools des großen Serverherstellers mit zwei Buchstaben mit zeitgemäßer, platzsparender Hardware ein Schnippchen schlagen und wäre nicht mehr genötigt, prähistorische Laufwerke in heutige PCs einzubauen und - noch schlimmer - die dazu notwendigen, lächerlich kleinen und unzuverlässigen Medien weiterhin am Lager zu halten.

Laden per USB? Fehlanzeige.

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 03 Aug 2008 22:01:00 +0200

Sandras Morotola RAZR macht es richtig: Es hat gar keinen eigenen Anschluß fürs Ladegerät mehr. Statt dessen hat das Ladegerät einen Mini-USB-Stecker und wird in denselben Anschluß eingesteckt, mit dem man auch die Datenverbindung zum PC herstellen kann. Und wie man es eigentlich auch erwartet, wird der Akku auch geladen, wenn eine Datenverbindung gesteckt ist.

Nicht so bei Nokia. Das E90 hat wie das RAZR einen Mini-USB-Port und ein mitgeliefertes USB-Kabel, das taugt aber nicht zum Laden: Man hat diese Funktion wohl schlichtweg weggelassen, denn das E90 verhält sich akkuseitig bei eingestecktem und verbundenem USB-Kabel genauso, als wäre es nicht verbunden.

Dagegen hat die Elektrobucht USB-Ladekabel für Nokia-Telefone wachsen lassen. Also gleich für wenig Geld eins bestellt. Funktioniert aber nicht. Und zwar in keiner der Kombinationen zwischen Notebook, “richtigem” PC, beiden 6310 und dem E90. Entweder ist das Kabel kaputt oder es ist ein Placebo. Mist.

Aber immerhin gibt es ein Ladegerät, das sowohl für das E90 als auch das zum Geburtstag vom Ehepaar A. aus M. bei N. an der W. geschenkte Bluetooth-Headset bedienen kann.

Klimaanlage, Alarmanlage, Löschanlage und USV an USB

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 03 Jul 2008 11:09:14 +0200

Viele Geräte der “Haustechnik” bzw. “Infrastruktur” (das können Klima, Lösch-, Alarmanlagen oder USVs sein) melden Fehlerzustände mit einem potenzialfreien Alarmkontakt. Das klingt ziemlich hochtrabend, ist aber in aller Regel nur ein simples Relais mit einem Schließerkontakt, das im Normalfall angezogen ist. Sprich, wenn irgendwas passiert, fällt das Relais ab und der Kontakt geht auf. Bei dieser Schaltung werden auch Defekte im Relais selbst oder Schäden an der Verkabelung erkannt; das ganze versagt also zur richtigen Seite.

Ich habe in den letzten Monaten einige Zeit damit verbracht, ein Stück Hardware zu finden, was mir ermöglicht, den Zustand eines potenzialfreien Alarmkontaktes in einen PC einzulesen und den Alarm mit Netzwerkmitteln (z.B. Nagios) weiterzumelden.

Die zwei Rechner, an die ich das ankoppeln möchte, sind ein 1U-Server und ein Notebook. Beide Geräte haben gemeinsam, dass sie keinen Gameport haben und auch PCI-Slots eher knapp sind (der Server hat zwar einen, der sollte aber für andere Anwendungen frei bleiben). Bleibt die serielle Schnittstelle (die wohl in der nächsten Gerätegeneration auch aussterben wird) und USB. Also USB.

Als Ergebnis einer Diskussion im Usenet gab es die Empfehlung für das universelle 8-Kanal-USB-Interface aus dem Webshop von ABACOM, was knapp fünfzig Euro kostet.

Das Ding hat zehn Schraubklemmen (GND, Vcc, Port 1 bis Port8), wobei jeder Port als digitaler Ausgang, als digitaler Eingang, analoger Eingang und Temperatureingang (die dazu passenden Fühler kosten extra) verwendet werden kann. Die Digitalausgänge sind mit 25 mA pro Kanal belastbar, ob das für ein Relais reicht weiß ich nicht. Ich habe zu lange keine ernsthafte Elektronik mehr betrieben.

Besondere Treiber sind nicht nötig, das Ding wird beim Einstecken sofort erkannt und als serielle Schnittstelle erreichbar:

Jul  3 09:29:47 scyw00225 kernel: usb 4-4.1: new full speed USB device using ehci_hcd and address 20
Jul  3 09:29:47 scyw00225 kernel: usb 4-4.1: configuration #1 chosen from 1 choice
Jul  3 09:29:47 scyw00225 kernel: usb 4-4.1: New USB device found, idVendor=0403, idProduct=6001
Jul  3 09:29:47 scyw00225 kernel: usb 4-4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jul  3 09:29:47 scyw00225 kernel: usb 4-4.1: Product: DLP-IO8
Jul  3 09:29:47 scyw00225 kernel: usb 4-4.1: Manufacturer: DLP Design
Jul  3 09:29:47 scyw00225 kernel: usb 4-4.1: SerialNumber: 12345678
Jul  3 09:29:47 scyw00225 kernel: usbcore: registered new interface driver usbserial
Jul  3 09:29:47 scyw00225 kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
Jul  3 09:29:47 scyw00225 kernel: usbcore: registered new interface driver usbserial_generic
Jul  3 09:29:47 scyw00225 kernel: drivers/usb/serial/usb-serial.c: USB Serial Driver core
Jul  3 09:29:47 scyw00225 kernel: drivers/usb/serial/usb-serial.c: USB Serial support registered for FTDI USB Serial
Device
Jul  3 09:29:47 scyw00225 kernel: ftdi_sio 4-4.1:1.0: FTDI USB Serial Device converter detected
Jul  3 09:29:47 scyw00225 kernel: drivers/usb/serial/ftdi_sio.c: Detected FT232RL
Jul  3 09:29:47 scyw00225 kernel: usb 4-4.1: FTDI USB Serial Device converter now attached to ttyUSB0
Jul  3 09:29:47 scyw00225 kernel: usbcore: registered new interface driver ftdi_sio
Jul  3 09:29:47 scyw00225 kernel: drivers/usb/serial/ftdi_sio.c: v1.4.3:USB FTDI Serial Converters Driver

Dann connected man mit 115k8n1 auf die neu erkannte serielle Schnittstelle und kann dort Einbuchstabenkommandos hinschicken. Dabei wird durch das Kommando auch gleich der Port ausgewählt. Hier zum Beispiel die Kommandos für Port 1:

1	Digitalausgang HIGH
Q	Digitalausgang LOW
A	Digitaleingang abfragen
Z	Analogeingang abfragen
9	Temperatur abfragen

Das einzige was ich probiert habe ist der Digitaleingang. Der wird, wenn er in der Luft hängt, zuverlässig als LOW erkannt, wobei ich natürlich nicht weiß, wie sich das verhält wenn da erstmal zwanzig Meter Anschlussleitung dran hängen und irgendwas da hinein streut. Vielleicht nimmt man dafür am besten einen Pull-Down-Widerstand.

Wenn man dem Gerät auf der seriellen Schnittstelle das “A” schickt, kommt sofort “0” oder (wenn man den Eingang mit Vcc verbindet) “1” zurück. So soll es sein.

Für den Anschluß eines Temperaturfühlers braucht’s noch einen 4k7-Pullup-Widerstand.

Von Kompatibilitätslisten und USB-Sticks

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 11 Jun 2008 11:00:00 +0200

Ich habe mich endlich auf einen USB-Stick-Typ geeinigt, den ich in Zukunft bevorzugt verwenden möchte: Den SanDisk Cruzer Micro. Zwar nicht besonders klein, aber auch nicht besonders groß, mit halbwegs günstigem Preis, und zurückziehbarem USB-Verbinder. Das bedeutet, dass keine Kappe verloren gehen kann und das Ding auch robust genug ist für das Schlüsselbund. Die dazugehörige “U3-Software”, die einem Windows ganz unkompliziert das Kaffeekochen beibringen soll, ignoriere ich völlig und benutze die Sticks halt als wären es ganz normale USB-Sticks.

Als USB-ZIP-Disk formatiert booten alle Rechner ganz prima von den Sticks. So gehört es sich ja auch. Nur gewisse hp-Server zicken.

Namentlich geht es um ältere Server vom Typ DL140, die zwar von echten Serverfans nicht als “echte Server” bezeichnet werden, aber dennoch den Segen in Form von hp-Logo und -Preisschild tragen. Die Maschinen sind zwar eigentlich als billiges austauschbares Element von Compute-Clustern etc konzipiert, aber aufgrund ihrer Hardwareausstattung als Server für moderne Linuxe prädestiniert. So sind einige dieser Kisten inzwischen in meinem Aufgabenbereich gelandet.

Im Normalfall bootet der DL140 auch prima von einem als USB-ZIP formatierten Stick, wie es die allermeisten Rechner in meinem Umfeld, die neu genug sind, auch tun. Nur von den SanDisk-Sticks wollen sie nicht. Und zwar wird der SanDisk-Stick entweder gar nicht oder doppelt erkannt, und dann wird doch von der Platte gebootet. Leider wird der Ende-des-Selbsttest-Screen nur einen Sekundenbruchteil lang angezeigt, so dass die Diagnose ein wenig schwer ist. Auch ein BIOS-Update (dank memdisk auch in der von hp gewählten Form des Floppy-Images auch ohne Floppy halbwegs schmerzarm) auf die aktuelle Version hilft nicht; das in manchen Foren empfohlene Entfernen der angeblich auf einer für Normalsterbliche unsichtbaren “Partition” abgelegten U3-Software mit einem proprietären Windows-Tool bleibt ebenfalls wirkungslos.

Also muss der eigentlich in den höchsten Tönen gelobte hp-Support, der in den letzten Tagen für mich schon einmal versagt hat, noch einmal ans Werk. Da für Server kein Chat angeboten wird, konservativer per Webformular.

Das Webformular fragt alles mögliche bis zur Schuhgröße des letzten Technikers, unter anderem auch das installierte Betriebssystem. Ich mache den Fehler, antworte wahrheitsgemäß “Debian GNU/Linux 4.0” und erkläre in der ~~EIngabebriefmarke~~ausreichend groß dimensionierten Textarea meine technische Herausforderung.

Die Antwort kommt auf dem Fuße innerhalb von wenigen Stunden: Debian GNU/Linux 4.0 sei nicht supported, und mein USB-Stick steht nicht auf der Kompatibilitätsliste. Man werde deswegen den Fall schließen; und die Webseite, auf die mein Ticket nun verweist, enthält praktischerweise weder eine Mögilchkeit zum Antworten noch eine, mit der das Ticket wieder geöffnet werden kann. Der gestreckte Mittelfinger ist somit endgültig.

Auf der Kompatibilitätsliste stehen natürlich nur USB-Sticks mit hp-Preisschild, und zwar ganze drei Stück aus der Kollektion von 2004. Das halte ich für heute völlig unzureichend.

Ich glaube, ich muss mal darüber bloggen, was Hardwarehersteller, Endkunden und ich unter “Support” verstehen. Ich habe nämlich den Verdacht, dass da drei ganz verschiedene Definitioen herauskommen.

Ich erwarte von “Support”, dass der Hersteller sich die Wehwehchen seiner Kunden wenigstens so lange anhört, bis jemand mit rudimentärem Sachverstand beurteilen kann, ob man es nicht mit einem offensichtlichen Hardware- oder Firmwarefehler zu tun hat, wie es hier der Fall ist. Schließlich ist im konkreten Problem das auf der Festplatte installierte Betriebssystem völlig irrelevant, weil nämlich der Rechner zum Zeitpunkt des Fehlers noch gar nicht gebootet hat. Außerdem erwarte ich, dass der Hersteller wenigstens eine Datenbank bekannter Macken führt, damit er seinem Kunden im Zweifel sagen kann, ob es sich um ein bekanntes Problem handelt oder ob es vielleicht einen Workaround gibt.

Ich erwarte ausdrücklich nicht, dass mir der Herstellersupport aus dem Kopf herbeten kann, wie man udev unter Arch Linux dazu bringt, einen eingesteckten USB-Stick automatisch zu mounten und als Swapdevice einzurichten, aber ich erwarte dass man mir konkrete technische Fragen zur Hardware auch dann beantwortet, wenn ich angegeben habe, dass auf dem System ein Linux installiert ist.

Außerdem finde ich es zum kotzen, dass hp auf der einen Seite große Töne spuckt, dass man Linux ja für soooooo wichtig hält, Debian-Entwickler bezahlt, mit großem Tamtam auf jeder Linux-Messe vertreten ist und dann in der Praxis die Anwender in dieser Form im Regen stehen lässt. “Wir unterstützen Windows, Windows und Windows, und wenn wir Linux sagen meinen wir Redhat”.

Dass es sich bei der Macke des DL140 mit meinen SanDisk-Sticks um einen BIOS-Fehler handeln muss, wird daraus klar, dass der DL140 von identisch partitionierten Sticks anderer Hersteller problemlos startet, und die SanDisk-Sticks von allen mir bekannten anderen Rechnern ebenso problemlos geschluckt werden.

Ach, was ist es so einfach, einen USB-Port so zu spezifizieren, dass nur eigene Devices unterstützt werden, und das dann auch zur Verweigerung von Support zu enforcen. Warum nicht gleich eine proprietäre, schon mechanisch inkompatible Spezialschnittstelle? Das sorgt wenigstens dafür, dass die Anwender auch das, was sonst problemlos funktionieren würde, nicht benutzt, allerdings auch für schlechte Presse, weil so der Nichtsupport gleich auf den ersten Blick offensichtlich ist. Wann geht es los, dass der Support verweigert wird, weil man das unterstützte Betriebssystem bei der Installation vom CD-ROM-Laufwerk eines Fremdherstellers gebootet hat?

Serial Console Server for the Poor I

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 03 Jun 2008 23:41:47 +0200

The serial port is still the way to access network components out of band. It is slow, but reliable, and remarkably well standardized. It does not have technical whiz-bangs that can fail when one needs things to just work. That makes it the natural way to access critical infrastructure and still being sure that this access vector still works when most other things are down.

Every communication link has two sides, so there is a market for devices with a network link and a bigger number of serial ports to connect the actual devices to. Commercial vendors have a broad choice of serial console servers. Most of them, especially the small products with five to ten ports, are quite expensive, so I have been investigating how do build a serial console server with el cheapo hardware.

USB comes to mind here, of course.

Picture of the fully equipped USB hub

The hardware side is actually quite easy: A seven-port USB hub, and seven USB-to-serial adaptors (using the widely-deployed Prolific PL2303) are easily purchased for well below a hundred Euros, and naively connected. In my test setup, connected to the hp compaq nc8000 that my blog readers should know only too well by now, the hub does not even need to have its power supply connected. The notebook can power the hub and the seven adaptors just fine.

When the UMTS card is plugged in, the ttyUSBx device nodes appear in the order of plugging in the devices. When the system is booted, the order is not very predictable, so one needs - again - udev to give predictable device node names.

udevinfo is an important tool to obtain the data set of an USB device which is available to match a device and to act appropriately when it is connected. udevinfo sorts the devices into a tree and shows the relationship of the devices, which device is “behind” which other device from the system’s point of view. udevinfo’s output starts at the leaf of the device tree and shows the information for each node up the tree until its root is reached.

One pitfall is that one can only match against the leaf and _one_ other node more up the tree. So you cannot do matches like “the pl2303-based device connected to port 3 on hub 2-3 will be designated USBserial3”. If you try this, your rule will silently be ignored. This is a major turn-off in udev’s implementation. I didn’t try it on sid, but etch definetely shows this behavior. So one can only match like “the tty on the USB subsystem connected to port 3 on hub 2-3 will be designated USBserial3”, but that’s probably as good as it’ll get.

The cause for my hub having only seven ports clearly shows itself when one looks at the udevinfo outputs of the fully equipped USB hub: The adapters are connected to ports 1, 2, 3, 4.1, 4.2, 4.3 and 4.4. The seven-port hub is actually two four-port hubs in a single case, with the second one connected to the first one’s port 4. This reflects itself, of course, in the udev rules necessary to address the adapters by the hub port they’re plugged in:

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.1”, \
   SYMLINK=“USBserial1”

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.2”, \
   SYMLINK=“USBserial2”

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.3”, \
   SYMLINK=“USBserial3”

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.1”, \
   SYMLINK=“USBserial4”

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.2”, \
   SYMLINK=“USBserial5”

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.3”, \
   SYMLINK=“USBserial6”

SUBSYSTEM==“tty”, SUBSYSTEMS==“usb”, DRIVERS==“usb”, \
   KERNELS==“*-*.4.4”, \
   SYMLINK=“USBserial7”

These rules will only work for a similary structured hub that is directly connected to the notebook. If there are more hubs in between the “final” hub and the host, the address matched against in the KERNELS matches are going to have a different structure. In the test setup, the first two parts of the address needed to be wildcarded since these addresses keep changing when the host is booted or the hub plugged out and in. So I guess that these udev rules are probably going to fail miserably when more hubs and/or USB-to-serial adaptors are connected.

But if one does not do too many changes, things are just fine, and it is possible to put numbers on the USB hub ports and be sure that the USB-to-serial adaptor connected to port 4 is going to be /dev/USBserial4 in the host system. I tried plugging in and out the adaptors in random order, unplugged and plugged the hub itself, booted the host, and the relationship between the port and the device node was stable.

If you have an USB 2.0 hub connected to an USB 2.0 port of the host, you might see error messages like “pl2303_open - failed submitting interrupt urb, error -28” in your log, while the serial ports plagued by this message are not going to work. This is due to an issue in the USB 2.0 code in the kernel (see the thread starting with my message on linux-kernel), Greg KH says that running USB 1.1 devices behind a USB 2.0 hub is a very difficult thing to do. A possible remedy is using an USB 1.1 hub, which is quite hard to obtain these days. But one can also unload the EHCI driver, disabling USB 2.0 completely, or do

echo P >/sys/class/usb_host/usb_hostB/companion

to force port P of the EHCI controller on Bus B to run at low/full speed (so, Alan Stern says in the linux-kernel thread). After a few tries, I found out that my test notebook needs P=1 and B=1 for the correct port. If you have found the correct port, you’ll see your devices disconnect and reconnect below the USB 1.1 root hub in lsusb and the urb error messages should be gone.

In the test environment, I only tested one adapter at a time, but all these tests were successful as well. I guess that many more of these adaptors will eventually need a powered USB hub, but with seven adaptors on a single hub, the power from the USB host is sufficient to live without extra power on the hub. And, I guess, there is some hard limit for the number of USB adapters being used, and some soft limit when managing the ports and adapters is going to get harder. But, I think that a site in need of more than, say, sixteen serial ports on the console server can afford a “real” console server from one of the major vendors, which can be accessed via ethernet, UMTS, ISDN and whatever you can think of.

This concludes the hardware part of my serial console server for the poor. Tomorrow, I’ll blog about the software side needed on the host to allow the serial ports to be accessed from the network while still being reasonably secure. The next article will involve ssh, /etc/passwd shells, /etc/shells, a small perl script, ser2net and telnet. And, shell escape is the cue word for grey hairs sprouting on my head.

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.

Booting from USB stick on older hardware

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 30 Sep 2007 23:23:32 +0200

I spent the better part of the weekend with trying to get an older Athlon XP mainboard to boot grub from an USB stick. Unfortunately, without success.

Since a few months, my notebook boots Windows XP when it is booted naively. Only if the correct USB stick is plugged in on boot, the Debian system that I work with comes up. The USB stick has grub, a kernel and an initrd which is used to boot and unlock the crypto file systems (crypted LVs) on the disk and can be removed once the system has booted.

I wanted to use the same scheme for a “newly built” new desktop from old parts. Unfortunately, this was much harder than I expected.

Since a few years, I use the USB-ZIP format for USB sticks that need to boot. It has shown that this format has the best chance to successfully boot. For more information about this format and about how to build it, see /usr/share/syslinux/README.usbkey on any recent Debian system with syslinux installed.

My grml USB stick that I always have on me is formatted like this, and the “new” desktop boots it just fine. The boot stick for my notebook is an USB-ZIP as well, only that its primary partition is not FAT, but ext3. Unfortunately, the BIOS of the “new” desktop seems to refuse booting grub. Neither my notebook’s stick nor the new stick even come to the “loading stage x” output of grub, let alone to the menu. syslinux works fine, and both sticks boot just fine on my notebook and on a qemu on the “new” desktop.

Since the grub command line has saved me multiple times in the past, I didn’t really like the idea of having to use syslinux, and decided to boot the “new” desktop conventionally from hard disk without the use of an USB boot stick. Until I got this far, the complete saturday and the better part of sunday was wasted. Darn.

This reminds me of a mainboard from 2002 (incidentally from the same vendor), which checked whether the first hard disk had an active primary partition on it before it even tried to execute the MBR code. If no primary partition was found (which was common case with the partitioning scheme that I used back then which only had logical drives - this was before I discovered LVM), the BIOS gave the error message “Not found active primary partition” (sic!) and refused to boot. Stupid programmers trying to outsmart the sysadmins of their products. But at least, the error message was reasonably clear back then.