Dienstag, 24. Oktober 2006, 22:32 Uhr

Wenn es update-initramfs zu eng wird …

… könnte man beim nächsten Reboot des Debian GNU/Linux-Servers eine böse Überraschung erleben. Wie ich heute Nachmittag:

Es war wieder mal an der Zeit, ein

apt-get upgrade

durchzuführen. Folgende Fehlermeldung beunruhigte mich keinesfalls, was sich als fahrlässig herausstellte:

Setting up initramfs-tools (0.83) ...
update-initramfs: Generating /boot/initrd.img-2.6.17-2-686
W: mdadm: unchecked configuration file: /etc/mdadm/mdadm.conf
W: mdadm: please read /usr/share/doc/mdadm/README.upgrading-2.5.3.gz .
I: mdadm: auto-generated temporary mdadm.conf configuration file.
I: mdadm: will start all available MD arrays from the initial ramdisk.
I: mdadm: use `dpkg-reconfigure --priority=low mdadm` to change this.

gzip: stdout: No space left on device
dpkg: error processing initramfs-tools (--configure):
 subprocess post-installation script returned error exit status 1

(Im Grunde bestand kein Anlass, den Server zu rebooten – aber irgendwie liess mich die Fehlermeldung dann doch nicht locker).

Prompt kam die Kiste nicht mehr hoch. Der Grund:

VFS: Cannot open root device "888" or unknown-block(8,8)
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on unknown-block(8,8)

(die Fehlermeldung habe ich aus dem Netz kopiert, bei mir stand etwas sehr ähnliches …)

Zum Glück hatte ich noch meinen alten 2.4er-Kernel rumliegen, der anstandslos bootete. Ein Blick auf die Partitionen offenbarte das Übel:

ALPHA:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6             958M  879M   30M  97% /
udev                   10M  116K  9.9M   2% /dev
devshm                507M  4.0K  507M   1% /dev/shm
/dev/sda1              16M  0  0  100% /boot
/dev/sda7              92M  4.1M   83M   5% /tmp
/dev/sda9             942M  493M  402M  56% /home
/dev/sdb1             4.2G  3.1G  938M  77% /var
/dev/md0              459G  247G  189G  57% /multimedia

Kein Wunder, dass update-initramfs abkrachte. Zurück blieb ein halbfertiges Ramdisk-Image. Glücklicherweise war die vorangehende Version auch unter /boot zu finden – soweit ich mich erinnern kann mit einem .dpkg-bak am Ende. Schwuppdiwupp, das verkrüppelte Image gelöscht, das alte unbenannt und schon kam die Kiste auch wieder mit dem 2.6er Kernel hoch.

Dennoch war mir nicht wohl dabei – alles schien reibungslos zu funktionieren, doch aus einem bestimmten Grund musste ja das Image neu erstellt werden. Ich entschied mich deshalb, das Image erneut zu generieren, stellte aber vorher sicher, dass im /boot-Verzeichnis dieses Mal genügend Platz vorhanden war. Dann ging’s los:

ALPHA:/boot# dpkg-reconfigure linux-image-2.6.17-2-686
Running depmod.
Finding valid ramdisk creators.
Using mkinitramfs-kpkg to build the ramdisk.
W: mdadm: unchecked configuration file: /etc/mdadm/mdadm.conf
W: mdadm: please read /usr/share/doc/mdadm/README.upgrading-2.5.3.gz .
I: mdadm: auto-generated temporary mdadm.conf configuration file.
I: mdadm: will start all available MD arrays from the initial ramdisk.
I: mdadm: use `dpkg-reconfigure --priority=low mdadm` to change this.
Not updating initrd symbolic links since we are being updated/reinstalled 
(2.6.17-9 was configured last, according to dpkg)

Ob es gefruchtet hat? Ich hoffe es. Beim nächsten Test-Reboot klappte alles wie am Schnürchen. Falls ich einmal Zeit habe, nehme ich mich auch noch der mdadm-Fehlermeldungen an (RAID10).

Guet Nacht!

Nachtrag

Vielleicht hat Kollege Liechti wirklich recht: Heute „klepfe“ man bei einer Linux-Installation alles auf eine Partition, rät er … Ich überleg’s mir mal.

Labels: Linux

Kommentar erfassen