… 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.
