Stretch Kernel update Problem

[dirk11]

Hallo!

wollte heute mein Stretch ganz normal updaten, klappt nicht. Bekomme den Kernel nicht upgedatet. Fehlermeldung lautet:

Code: Alles auswählen

/usr/bin/grub-mkrelpath: Fehler: Kanonischer Pfad von »2:/boot« konnte nicht ermittelt werden.

Und nun?

[rendegast]

Etwas ungewöhnliches in /etc/default/grub[.d/] ?

"2:/boot" ?

Code: Alles auswählen

mount

blkid  |  sort -V

?

[dirk11]

Sind zwei gpt-partitionierte 3TB-Platten, /boot ist ein md-device.

Code: Alles auswählen

~# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1720772k,nr_inodes=430193,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=353252k,mode=755)
/dev/mapper/md5_crypt on / type xfs (rw,relatime,attr2,inode64,noquota)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
pstore on /sys/fs/pstore type pstore (rw,relatime)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=706500k)
/dev/md4 on /boot type xfs (rw,relatime,attr2,inode64,noquota)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,size=12k,mode=755)
/dev/mapper/md5_crypt on /var/spool/hylafax/etc type xfs (rw,relatime,attr2,inode64,noquota)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)

Code: Alles auswählen

~# blkid  |  sort -V
/dev/mapper/md3_crypt: UUID="c72159ee-aaaa-bbbb-cccc-409f6bdd58b6" TYPE="swap"
/dev/mapper/md5_crypt: LABEL="debian64" UUID="f98f4859-1111-2222-3333-a78421656e97" TYPE="xfs"
/dev/md2: LABEL="reserved" UUID="ebd5cbbd-4444-5555-6666-b52d4110c0ca" TYPE="xfs"
/dev/md3: UUID="04d742af-3f5c-4688-7777-b7b6981024b6" TYPE="crypto_LUKS"
/dev/md4: LABEL="boot" UUID="bcacc1e7-8888-9999-5555-9b83a2440ec3" TYPE="xfs"
/dev/md5: UUID="d22f9e63-2a86-5555-6666-1734481b1b9d" TYPE="crypto_LUKS"
/dev/sda1: PARTLABEL="bios-grub" PARTUUID="060e82e1-aaaa-bbbb-nnnn-dd23833dc73f"
/dev/sda2: UUID="38ededc6-2209-0000-abab-161baeeb9b8d" UUID_SUB="bd9716fc-dcdc-8e8e-bf5c-536a25e77b2e" LABEL="server:2" TYPE="linux_raid_member" PARTLABEL="reserved" PARTUUID="72c64ac9-aaaa-bbbb-eeee-0b0ef8101d6e"
/dev/sda3: UUID="f0bdc579-6767-a8a8-3434-54419e07c83e" UUID_SUB="4c5c1879-3934-3443-b22b-2c2d6de05ecb" LABEL="server:3" TYPE="linux_raid_member" PARTLABEL="swap" PARTUUID="cb234631-fcfc-2222-4242-92104eebb7d1"
/dev/sda4: UUID="5d951aa1-5142-4236-4242-576b5f136afc" UUID_SUB="430a5c7d-f3e5-4265-4217-9c5aa72d7ab1" LABEL="server:4" TYPE="linux_raid_member" PARTLABEL="boot" PARTUUID="24cab28e-2222-3232-4141-d29c360d3b10"
/dev/sda5: UUID="562484bf-9696-dddd-398e-4adcbe6275e8" UUID_SUB="70071a87-11be-4f4f-5656-8e54b4334d21" LABEL="server:5" TYPE="linux_raid_member" PARTLABEL="debian64" PARTUUID="52c62a18-ecaa-acac-be0f-52d0c8516853"
/dev/sdb1: PARTLABEL="bios-grub" PARTUUID="9a1d9722-cccc-4444-a8e9-ac01dd5c52e2"
/dev/sdb2: UUID="38ededc6-2222-0202-adaa-161baeeb9b8d" UUID_SUB="648bd236-7232-2323-1212-bc1d2b2b4fc4" LABEL="server:2" TYPE="linux_raid_member" PARTLABEL="reserved" PARTUUID="2c39eb9c-abcd-4890-1010-b8829f4cb5d3"
/dev/sdb3: UUID="f0bdc579-68c4-adda-caac-54419e07c83e" UUID_SUB="4624baba-c11c-abab-36e7-8638d7d04383" LABEL="server:3" TYPE="linux_raid_member" PARTLABEL="swap" PARTUUID="42322c13-9999-3333-2434-ef771ca8cd68"
/dev/sdb4: UUID="5d951aa1-5151-5146-cccc-576b5f136afc" UUID_SUB="622fbee7-6363-a1a1-baba-83a106acda50" LABEL="server:4" TYPE="linux_raid_member" PARTLABEL="boot" PARTUUID="dfe1daac-bb80-daad-3a4b-6bf547cc8eb9"
/dev/sdb5: UUID="562484bf-ddff-34fd-efad-4adcbe6275e8" UUID_SUB="3f2d878e-2020-c2e4-9f71-b49f0daeb723" LABEL="server:5" TYPE="linux_raid_member" PARTLABEL="debian64" PARTUUID="2afe3e00-1212-3434-ad85-3c5194b0624a"
/dev/sdc1: UUID="3017-A001" TYPE="vfat" PARTUUID="147a91b8-01"

[dirk11]

"2:/boot" ?

Das hat mich übrigens auch irritiert, das kam, nachdem ich den vorherigen Kernel zusätzlich installieren wollte. Wenn ich das nicht mache, sondern nur den aktuellen updaten lassen will, steht dort 1:/boot.

/etc/default/grub ist auch seit Jahren unverändert:

Code: Alles auswählen

GRUB_DEFAULT=0
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet ipv6.disable=1 acpi_enforce_resources=lax"
GRUB_GFXMODE=1024x768
GRUB_GFXPAYLOAD_LINUX=1024x768
GRUB_DISABLE_RECOVERY="true"
GRUB_DISABLE_SUBMENU="y"
SUPPORTED_INITS=""

[Taomon]

Irgendwas erhellendes bei

Code: Alles auswählen

grub-probe -vvv -t fs /boot/grub/

Taomon

[dirk11]

Ich würd's ja gerne auf debianforum pastebin hochladen, dort bekomme ich aber die Fehlermeldung

Code: Alles auswählen

[phpBB Debug] PHP Warning: in file [ROOT]/ext/phpbbde/pastebin/controller/main.php on line 279: include_once(./includes/functions_upload.php): failed to open stream: No such file or directory
[phpBB Debug] PHP Warning: in file [ROOT]/ext/phpbbde/pastebin/controller/main.php on line 279: include_once(): Failed opening './includes/functions_upload.php' for inclusion (include_path='.:/usr/share/php:/usr/share/pear')

Scheint also kaputt zu sein.

Sei's drum. Die gesamte Ausgabe kann man hier nachlesen. Ich sehe da wenig für mich Erhellendes.

[dirk11]

Krasser Mist!

Das Problem ging "irgendwie" von einem noch vorhandenen alten Kernel 4.9.0-bpo5 aus. Das war der, dessen vmlinuz angeblich nicht in /boot, sondern in 1:/boot gefunden wurde. Nachdem ich den entfernt habe, funktioniert auch update-grub wieder ohne Fehlermeldung!

EDIT:
Fehler gefunden!

War selbst-induziert. Hikaru hat ja hier davor gewarnt, daß Software, die mit grep arbeitet, über die vorangestellte Zeilennummer stolpern würde. Ich habe dieses Script erstellt und wie hier von Meillo beschrieben das Script dann nach /usr/local/bin verfrachtet. Und darüber bin ich nun gestolpert. Tja, Script gelöscht, farbige grep-Ausgabe kann ich mir klemmen, aber zumindest funktioniert dier Rest jetzt wieder.

Und wieder dazugelernt.