Kernel-update schlägt fehl

german

#1

Hallo,

das letzte update hat auf dem UCS Master funktioniert. Auf einem UCS Slave jedoch nicht:

Setting up linux-image-3.10.0-ucs81-amd64 (3.10.11-1.81.201409041448) ...
Running depmod.
vmlinuz(/boot/vmlinuz-3.10.0-ucs81-amd64
) points to /boot/vmlinuz-3.10.0-ucs81-amd64
 (/boot/vmlinuz-3.10.0-ucs81-amd64) -- doing nothing at /var/lib/dpkg/info/linux-image-3.10.0-ucs81-amd64.postinst line 268.
The link /initrd.img is a dangling linkto /boot/initrd.img-3.10.0-ucs81-amd64
Running /usr/sbin/update-grub.
/usr/sbin/grub-mkconfig: 242: cannot create /boot/grub/grub.cfg.new: Directory nonexistent
User postinst hook script [/usr/sbin/update-grub] exited with value 2
dpkg: error processing linux-image-3.10.0-ucs81-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of univention-kernel-image:
 univention-kernel-image depends on linux-image-3.10.0-ucs81-amd64; however:
  Package linux-image-3.10.0-ucs81-amd64 is not configured yet.
dpkg: error processing univention-kernel-image (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-3.10.0-ucs81-amd64
 univention-kernel-image

Bei einem Vergleich von /boot fällt auf, dass auf dem UCS Slave das Boot-Verzeichnis ziemlich leer ist:

root@host:/boot# ls -l
total 5608
-rw-r--r-- 1 root root  146710 Sep  4 23:08 config-3.10.0-ucs81-amd64
-rw-r--r-- 1 root root 2316607 Sep  4 23:08 System.map-3.10.0-ucs81-amd64
-rw-r--r-- 1 root root 3272736 Sep  4 23:04 vmlinuz-3.10.0-ucs81-amd64

Die fstab sieht so aus

root@host:/boot# cat /etc/fstab
UUID=9bc25a6b-e342-4098-9bba-ca0ea41d19ef       /       ext4    acl,errors=remount-ro   0       1
proc            /proc           proc    defaults        0       0
UUID=e744afdb-7ce1-4ebf-97d1-e6b53ab23865  /boot        ext4    defaults,acl    0       0
UUID=def0136f-2760-43ec-8ed4-07486b52b016  none         swap    sw 0    0
/dev/sr0  /cdrom     auto    user,noauto,exec            0       0
/dev/fd0  /floppy     vfat    user,noauto,exec            0       0
/dev/mapper/storagesystem-part1 /mnt    ext4    auto,nouser,exec,rw,sync        0       0

Dann habe ich folgendes probiert:

root@host:/boot# mount -a
mount: /dev/sda2 already mounted or /boot busy

und

root@host:/boot# mount
/dev/mapper/vg_ucs-rootfs on / type ext4 (rw,acl,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
/dev/mapper/storagesystem-part1 on /mnt type ext4 (rw,sync)

Ich bin verwirrt.

root@host:/# umount /dev/sda2
umount: /dev/sda2: not mounted

root@host:/# mount /dev/sda2 /media/
mount: /dev/sda2 already mounted or /media/ busy

root@host:/boot# mkdir /test

root@host:/# mount /dev/sda2 /test
mount: /dev/sda2 already mounted or /test busy

#2

Hallo,

daran daß es ein DC Slave ist, liegt es meines Erachtens nicht, bei mir gab es diesbezüglich keine Probleme mit dem Kernelupdate.

Könnten Sie bitte einmal schauen, was evtl. während des Mountversuches in /var/log/syslog geschrieben wird?

Viele Grüße
Ulf Friedel


#3

Leider wird nichts in /var/log/syslog geschrieben …

Hier noch ein wenig Hintergrund:

Der UCS Slave läuft als Virtualisierungshost mit KVM. Darauf läuft testweise ein UCS Master und einige Windowsmaschinen.

Den UCS Master habe ich zuerst aktualisiert - ohne Probleme. Danach wollte ich den UCS Slave nachziehen und es kam zu den genannten “Erscheinungen” …


#4

Hier noch etwas merkwürdiges:

Im folgenden steht die Anzeige der Festplatte mit parted:

Disk /dev/sda: 146GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system     Name                 Flags
 1      16.8MB  25.2MB  8389kB                  BIOS Boot Partition  bios_grub
 2      25.2MB  562MB   537MB   ext4            /boot
 3      562MB   11.3GB  10.7GB  linux-swap(v1)  SWAP
 4      11.3GB  146GB   135GB                   LVMPV                lvm

Ein “fake”-mount bringt die Boot-Partition wenigstens schonmal in die Liste:

root@host:~# mount -f /dev/sda2 /media/
root@host:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_ucs-rootfs
                      124G   76G   42G  65% /
tmpfs                  24G     0   24G   0% /lib/init/rw
udev                   10M  236K  9.8M   3% /dev
tmpfs                  24G     0   24G   0% /dev/shm
/dev/sda2             124G   76G   42G  65% /media

Nur wundert es mich, dass die Zeile identisch zur root-Partition ist -.-


#5

Der letzte Hinweis, der mir noch auffällt ist die Ausgabe von parted -l

root@host:/boot# parted -l
Model: LSI RAID SAS 6G 0/1 (scsi)
Disk /dev/sda: 146GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system     Name                 Flags
 1      16.8MB  25.2MB  8389kB                  BIOS Boot Partition  bios_grub
 2      25.2MB  562MB   537MB   ext4            /boot
 3      562MB   11.3GB  10.7GB  linux-swap(v1)  SWAP
 4      11.3GB  146GB   135GB                   LVMPV                lvm


Model: LSI RAID SAS 6G 0/1 (scsi)
Disk /dev/sdb: 299GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start  End  Size  File system  Name  Flags


Model: FUJITSU ETERNUS_DXL (scsi)
Disk /dev/sdc: 545MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End    Size   File system  Name     Flags
 1      1049kB  544MB  543MB  ext4         primary


Model: FUJITSU ETERNUS_DXL (scsi)
Disk /dev/sdd: 545MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End    Size   File system  Name     Flags
 1      1049kB  544MB  543MB  ext4         primary


Model: FUJITSU ETERNUS_DXL (scsi)
Disk /dev/sde: 545MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End    Size   File system  Name     Flags
 1      1049kB  544MB  543MB  ext4         primary


Model: FUJITSU ETERNUS_DXL (scsi)
Disk /dev/sdf: 545MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End    Size   File system  Name     Flags
 1      1049kB  544MB  543MB  ext4         primary


Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/storagesystem: 545MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End    Size   File system  Name     Flags
 1      1049kB  544MB  543MB  ext4         primary


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/storagesystem-part1: 543MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End    Size   File system  Flags
 1      0.00B  543MB  543MB  ext4


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/vg_ucs-rootfs: 135GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop

Number  Start  End    Size   File system  Flags
 1      0.00B  135GB  135GB  ext4


Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/36003005700d73ac01b8ddb1c2c066fb4: 299GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start  End  Size  File system  Name  Flags


Error: /dev/mapper/36003005700d73ac01b8ddb1c2c05e4bc-part4: unrecognised disk
label

Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/36003005700d73ac01b8ddb1c2c05e4bc: 146GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system     Name                 Flags
 1      16.8MB  25.2MB  8389kB                  BIOS Boot Partition  bios_grub
 2      25.2MB  562MB   537MB   ext4            /boot
 3      562MB   11.3GB  10.7GB  linux-swap(v1)  SWAP
 4      11.3GB  146GB   135GB                   LVMPV                lvm

und der Fehler:

Error: /dev/mapper/36003005700d73ac01b8ddb1c2c05e4bc-part4: unrecognised disk
label

Ansonsten bin ich wirklich ratlos …


#6

Hallo,

könnten Sie bitte einmal die Ausgabe von [quote]cat /proc/mounts[/quote] posten?

[quote=“WehlingPh”]Error: /dev/mapper/36003005700d73ac01b8ddb1c2c05e4bc-part4: unrecognised disk label[/quote]
Dies bezieht sich, denke ich, auf das LVM und nicht auf die Bootpartition und könnte deshalb evtl. nichts mit dem eigentlichem Problem zu tun haben.

Viele Grüße
Ulf Friedel


#7

Ja na klar, kein Problem:

rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs rw,relatime,size=10240k,nr_inodes=6187942,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/mapper/vg_ucs-rootfs / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
nfsd /proc/fs/nfsd nfsd rw,relatime 0 0

#8

Hallo,

was sagt die Ausgabe von blkid -c /dev/null -o list in Bezug auf /dev/sda2?

Haben Sie die Partition schon per e2fsck überprüft?

Evtl. könnten Sie versuchen das System mit einer Live-CD zu booten und schauen ob sich diese Partition dort mounten lässt oder ob das Problem da auch auftritt.

Viele Grüße
Ulf Friedel


#9
root@hbucsvm01:~# blkid -c /dev/null -o list | head -3
device           fs_type  label     mount point          UUID
---------------------------------------------------------------------------------------------
/dev/sda2        ext4               (in use)             e744afdb-7ce1-4ebf-97d1-e6b53ab23865
root@hbucsvm01:~# e2fsck /dev/sda2
e2fsck 1.41.12 (17-May-2010)
e2fsck: Device or resource busy while trying to open /dev/sda2
Filesystem mounted or opened exclusively by another program?
lsof /boot

gibt auch keine Ausgabe.

Das mit der Live-CD ist auch eine Idee, aber nicht so leicht umsetzbar hier.

Ich hatte mir die Mühe gemacht, den Kernel-Ring-Buffer durchzuschauen, habe aber auch keine Hinweise gefunden …


#10

Hallo,

prüfen Sie bitte einmal, ob Sie mit [code]

lsof -w /dev/sda2

fuser -m /dev/sda2

[/code] herausfinden, mit was /dev/sda2 beschäftigt ist.

Viele Grüße
Ulf Friedel


#11

Beide Kommandos ergeben keine Ausgaben …