[GELÖST] /boot-Partition mit Bootflag zu klein für Kernel-Upgrade

[BrotherJ]

Hallo,

ich habe jetzt ein ernsthaftes Problem:
Ich habe einen Rootserver mit Proxmox im Internet am Laufen. Darauf laufen als
VMs ein Mailserver, ein Webserver plus zwei DNS-Server.

Der Host selbst ist mit Debian Stretch installiert. Jetzt benötige ich wegen
einem Bug in Promox ein Upgrade. Und das ist jetzt nicht machbar:

Code: Alles auswählen

"....
Installing new version of config file /etc/vzdump.conf ...
Setting up proxmox-ve (5.4-2) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Processing triggers for initramfs-tools (0.130) ...
update-initramfs: Generating /boot/initrd.img-4.15.18-20-pve

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-4.15.18-20-pve with 1.
dpkg: error processing package initramfs-tools (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for pve-ha-manager (2.0-9) ...
Processing triggers for systemd (232-25+deb9u12) ...
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)"

Code: Alles auswählen

# df -h
Filesystem                       Size  Used Avail Use% Mounted on
udev                              32G     0   32G   0% /dev
tmpfs                            6.3G  658M  5.7G  11% /run
/dev/sda3                        366G  2.9G  345G   1% /
tmpfs                             32G   19M   32G   1% /dev/shm
tmpfs                            5.0M     0  5.0M   0% /run/lock
tmpfs                             32G     0   32G   0% /sys/fs/cgroup
/dev/sda4                         14G  3.0G   11G  23% /usr/local/backups
/dev/mapper/vg00-backup         1008G  547G  421G  57% /home/systembackup
/dev/sda1                        225M  189M   20M  91% /boot
/dev/mapper/vg00-ffm             492G  309G  163G  66% /home/ffm
/dev/mapper/vg00-var--partition   40G  5.0G   33G  14% /var
zp_100                           3.4T  128K  3.4T   1% /zp_100
tmpfs                            6.3G     0  6.3G   0% /run/user/1000
/dev/fuse                         30M   16K   30M   1% /etc/pve

Ich hatte /boot auf /dev/sda1 zu klein gestaltet.

Ich hatte exakt das gleiche Problem diesen Freitag bei einem PC schon einmal.
Nur hier konnte ich am PC direkt im Debian-Installer /dev/sda1 und swap
löschen, um dann /dev/sda1 auf Kosten von swap zu vergrößern. Alles Andere
blieb unberührt.

Wie kann mein Problem hier remote lösen? Ich denke daran, ein /boot-
Verzeichnis auf /dev/sda3 mit gleichem Inhalt anzulegen und /dev/sda1 aus der
fstab rauszunehmen. Nur hat /dev/sda1 ja auch das Boot-Flag gesetzt. Kann ich
das im laufenden Betrieb auf /dev/sda3 legen, so dass ich problemlos neu in
den neuen Kernel booten kann?

Beste Grüße

BrotherJ

[mludwig]

Was liegt denn sonst noch in /boot ? Vielleicht reicht es ja einen oder mehrere alte unbenutzte Kernel zu deinstallieren ...

[BrotherJ]

Leider liegt da nur der Aktuelle und der eben Installierte:

Code: Alles auswählen

 # ll /boot/
total 182799
-rw-r--r-- 1 root root   216905 Aug  8 10:42 config-4.15.18-20-pve
-rw-r--r-- 1 root root   216555 Aug 24  2018 config-4.15.18-3-pve
-rw-r--r-- 1 root root   186598 Sep  2 09:18 config-4.9.0-11-amd64
-rw-r--r-- 1 root root   186568 Aug 13  2018 config-4.9.0-7-amd64
-rw-r--r-- 1 root root   186589 Oct  8  2018 config-4.9.0-8-amd64
drwxr-xr-x 5 root root     1024 Sep 15 10:20 grub
-rw-r--r-- 1 root root 34535296 Sep 15 10:20 initrd.img-4.15.18-20-pve
-rw-r--r-- 1 root root 33993716 Aug 30  2018 initrd.img-4.15.18-3-pve
-rw-r--r-- 1 root root 25940782 Sep 15 10:20 initrd.img-4.9.0-11-amd64
-rw-r--r-- 1 root root 18409210 Aug 28  2018 initrd.img-4.9.0-7-amd64
-rw-r--r-- 1 root root 25906941 Sep 15 10:20 initrd.img-4.9.0-8-amd64
drwx------ 2 root root    12288 Aug 28  2018 lost+found
drwxr-xr-x 2 root root     1024 Sep 15 10:21 pve
-rw-r--r-- 1 root root  4095094 Aug  8 10:42 System.map-4.15.18-20-pve
-rw-r--r-- 1 root root  4081299 Aug 24  2018 System.map-4.15.18-3-pve
-rw-r--r-- 1 root root  3203428 Sep  2 09:18 System.map-4.9.0-11-amd64
-rw-r--r-- 1 root root  3192069 Aug 13  2018 System.map-4.9.0-7-amd64
-rw-r--r-- 1 root root  3193875 Oct  8  2018 System.map-4.9.0-8-amd64
-rw-r--r-- 1 root root  8468256 Aug  8 10:42 vmlinuz-4.15.18-20-pve
-rw-r--r-- 1 root root  8427376 Aug 24  2018 vmlinuz-4.15.18-3-pve
-rw-r--r-- 1 root root  4249376 Sep  2 09:18 vmlinuz-4.9.0-11-amd64
-rw-r--r-- 1 root root  4232992 Aug 13  2018 vmlinuz-4.9.0-7-amd64
-rw-r--r-- 1 root root  4237088 Oct  8  2018 vmlinuz-4.9.0-8-amd64

Seltsamerweise steht hier ohne reboot:

Code: Alles auswählen

# uname -a
Linux neckar 4.15.18-3-pve #1 SMP PVE 4.15.18-22 (Fri, 24 Aug 2018 11:12:20 +0200) x86_64 GNU/Linux

[BrotherJ]

Sorry,
gestern hatte ich noch folgende Situation

Code: Alles auswählen

pveversion -v
proxmox-ve: 5.2-2 (running kernel: 4.15.18-3-pve)
pve-manager: 5.2-8 (running version: 5.2-8/fdf39912)
pve-kernel-4.15: 5.2-6
pve-kernel-4.15.18-3-pve: 4.15.18-22
corosync: 2.4.2-pve5

[MSfree]

Leider liegt da nur der Aktuelle und der eben Installierte:

Code: Alles auswählen

 # ll /boot/
 ...
-rw-r--r-- 1 root root  8468256 Aug  8 10:42 vmlinuz-4.15.18-20-pve
-rw-r--r-- 1 root root  8427376 Aug 24  2018 vmlinuz-4.15.18-3-pve
-rw-r--r-- 1 root root  4249376 Sep  2 09:18 vmlinuz-4.9.0-11-amd64
-rw-r--r-- 1 root root  4232992 Aug 13  2018 vmlinuz-4.9.0-7-amd64
-rw-r--r-- 1 root root  4237088 Oct  8  2018 vmlinuz-4.9.0-8-amd64

Also, ich zähle da 5 Kernel:

4.9.0-11 ist der aktuelle Stretch-Kernel.

4.9.0-7 und 4.9.0-8 sind alte Stretch-Kernel und können gelöscht werden:

Code: Alles auswählen

apt-get purge linux-image-4.9.0-7-amd64
apt-get purge linux-image-4.9.0-8-amd64

Wohin die beiden 4.15.18 Kernel gehören, weiß ich gerade nicht, eventuell Ubuntu? Jedenfalls ist davon auch nur der mit der höheren Nummer aktuell.

[towo]

Die beiden pve-Kernel gehören zu Proxmox, nix Ubuntu.

[BrotherJ]

Hallo MSfree,

danke für die Unterstützung. Mir ist heute Morgen echt das Herz in die Hosen gerutscht, eben weil das ein Produktivsystem ist. Ich die alten Kernel echt nicht gesehen, sie aber rausgenommen, wie von Dir empfohlen.

Code: Alles auswählen

 df -h /boot/
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       225M  133M   77M  64% /boot

Den 4.9.0-11-amd64er kann ich eigentlich auch rausnehmen, da hier richtig bemerkt Proxmox mit seinem Kernel läuft.

Besten Dank

BrotherJ