kernel 4.9.261 stable

[Daniel Vogel]

Hallo zusammen,

es steht nun die Kernel-Version 4.9.261 (linux-kernel 3.0.6/eiskernel
6.0.5) als stable-Version zum Download auf pack-eis zur Verfügung.

Den Kernel aus der Logterm-Kernel-Linie 4.9 gibt es, wie gewohnt, für
eisfair-1 in den Varianten SMP, PAE und VIRT. Für eisfair-64 gibt es
lediglich die Variante VIRT.

Das Release der Pakete als stable-Version erfolgt auf der Basis der
Erfahrungen mit der Testversion 3.0.5. Die Pakete entsprechen denen der
Testversion bis auf die erforderlichen Anpassungen in der Paket-Info-Datei.

Versionshistorie:

linux-kernel 4.9.261 stable (3.0.6)
-----------------------------------
* Änderung des Status auf stable

linux-kernel 4.9.261 testing (3.0.5)
-----------------------------------
* Update auf Version 4.9.261:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v4.9.261
* Update wireguard auf Version 1.0.20210219
* Umstellung der Generierung der initrd auf dracut
* Umstellung auf relative Links in /boot und /usr/src

linux-kernel 4.9.255 stable (3.0.4)
-----------------------------------
* Änderung des Status auf stable

linux-kernel 4.9.255 testing (3.0.3)
-----------------------------------
* Update auf Version 4.9.255:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v4.9.255
* Update wireguard auf Version 1.0.20210124
* Hinweis auf einen erforderlichen Reboot am Ende der Installation
* Korrektur des Source-Pakets in Bezug auf den Umgang mit dem
Ausführungsverzeichnis des switch_config Skripts.
* Aufnahme der EDAC-Module in das Kernel-Release

linux-kernel 4.9.248 stable (3.0.1)
-----------------------------------
* Der Standardwert für use_dac der Realtek Netzwerktreiber r8168 und
r8101 wurde von 1 auf 0 geändert.
* Bei der Erstellung der initrd werden nun auch Systeme mit Raid 6 und
Raid 10 akzeptiert.

linux-kernel 4.9.248 testing (3.0.0)
------------------------------------
* Update auf Version 4.9.248:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=v4.9.248
* Patch: realtek-r8101-1.035.03
* Patch: realtek-r8168-8.048.03
* Patch: wireguard-linux-compat-1.0.20201112
* Aufteilung des Kernel-Pakets in eine Reihe separater Pakete
* Verwaltung der Kernel in Form versionierter Pakete
* Auslagerung der Erstellung der initrd
* Auslagerung der Erstellung der Bootloader-Konfiguration
* Änderung der Installation des Source-Pakets (kein Download mehr
erforderlich).

Viel Erfolg bei der Installation.

X-Post & F'Up2 spline.eisfair

[Gerd Walter]

Hallo,

Hallo zusammen,es steht nun die Kernel-Version 4.9.261 (linux-kernel 3.0.6/eiskernel 6.0.5) als stable-Version zum Download auf pack-eis zur Verfügung.Den Kernel aus der Logterm-Kernel-Linie 4.9 gibt es, wie gewohnt, für eisfair-1 in den Varianten SMP, PAE und VIRT. Für eisfair-64 gibt es lediglich die Variante VIRT.

Auf einen vollvirtualisierten Eis64 lief der Reboot schief.
Es kommen nur mehrere 99 auf der vnc Console.

[Rolf Bensch]

Post by Gerd Walter
Hallo,

Hallo zusammen,es steht nun die Kernel-Version 4.9.261 (linux-kernel 3.0.6/eiskernel 6.0.5) als stable-Version zum Download auf pack-eis zur Verfügung.Den Kernel aus der Logterm-Kernel-Linie 4.9 gibt es, wie gewohnt, für eisfair-1 in den Varianten SMP, PAE und VIRT. Für eisfair-64 gibt es lediglich die Variante VIRT.

Auf einen vollvirtualisierten Eis64 lief der Reboot schief.
Es kommen nur mehrere 99 auf der vnc Console.

Das kann ich NICHT bestätigen. Hier lief der Reboot mit virt-Kernel problemlos durch.

Grüße Rolf

[Marcus Röckrath]

Hallo Gerd,

Post by Gerd Walter
Auf einen vollvirtualisierten Eis64 lief der Reboot schief.
Es kommen nur mehrere 99 auf der vnc Console.

Ich nehme an, dass nichtmal das lilo-Bootmenü kommt, richtig?

L 99 99 99 99 ... weist auf defekten MBR hin.

Kannst du bitte genauere Infos zu dem System geben?

[Gerd Walter]

Hallo Marcus,

Hallo Gerd,Gerd Walter wrote:> Auf einen vollvirtualisierten Eis64 lief der Reboot schief.> Es kommen nur mehrere 99 auf der vnc Console.Ich nehme an, dass nichtmal das lilo-Bootmenü kommt, richtig?L 99 99 99 99 ... weist auf defekten MBR hin.Kannst du bitte genauere Infos zu dem System geben?-- Gruß Marcus[eisfair-Team]

Ja, stimmt es kommt kein Bootmenü.
Es war erst ein paravirtualisierter Eisfair, welchen ich auf hvm
gewechselt habe.
Er läuft unter Bullseye xen 4.14. Das update auf den .255 hatte
letztens geklappt.

[Gerd Walter]

Ach ja, das update zeigte keine Fehler, aber beim Reboot hing er
(war per ssh drauf.).

[Marcus Röckrath]

Hallo Gerd,

Post by Gerd Walter
Ach ja, das update zeigte keine Fehler, aber beim Reboot hing er
(war per ssh drauf.).

Kommst du an die Daten auf der virtuellen Platte ran?

cat /etc/lilo.conf

ls -l /boot

Ist da ein Raid im Spiel? cat /etc/mdadm/mdadm.conf

[Gerd Walter]

Hallo Marcus,

Hallo Gerd,Gerd Walter wrote:> Ach ja, das update zeigte keine Fehler, aber beim Reboot hing er> (war per ssh drauf.).Kommst du an die Daten auf der virtuellen Platte ran?cat /etc/lilo.confls -l /bootIst da ein Raid im Spiel? cat /etc/mdadm/mdadm.conf-- Gruß Marcus[eisfair-Team]

Raid ist nicht im Spiel.

***@core:~# cat /mnt/vm/etc/lilo.conf
#-----------------------------------------------------------------
------------
# /etc/lilo.conf - lilo bootloader configuration
# created: 2021-03-26 23:44:50
#-----------------------------------------------------------------
------------

lba32
boot = /dev/xvda1
read-only
prompt
timeout = 50
vga = normal
menu-scheme = wr:bw:wr:Yr
image = /boot/kernel
#root = /dev/xvda3
root = "UUID=678cf645-2354-4b95-bdd2-1c474dd65fa1"
label = eis
initrd = /boot/initrd.gz
append = "raid=noautodetect console=hvc0 ipv6.disable=1"
image = /boot/kernel-4.9.261-eisfair-64-VIRT
#root = /dev/xvda3
root = "UUID=678cf645-2354-4b95-bdd2-1c474dd65fa1"
label = 4.9.261-VIRT
initrd = /boot/initrd-4.9.261-eisfair-64-VIRT.gz
append = "raid=noautodetect console=hvc0 ipv6.disable=1"
image = /boot/kernel-4.9.255-eisfair-64-VIRT
#root = /dev/xvda3
root = "UUID=678cf645-2354-4b95-bdd2-1c474dd65fa1"
label = 4.9.255-VIRT
initrd = /boot/initrd-4.9.255-eisfair-64-VIRT.gz
append = "raid=noautodetect console=hvc0 ipv6.disable=1"
***@core:~# ls -l /mnt/vm/boot/
insgesamt 29426
lrwxrwxrwx 1 root root 1 3. Mär 2019 boot -> .
-rw-r--r-- 1 root root 512 30. Jul 2016 boot.0300
-rw-r--r-- 1 root root 512 19. Aug 2018 boot.0800
-rw-r--r-- 1 root root 512 23. Jan 2019 boot.CA00
-rw-r--r-- 1 root root 512 26. Mär 23:33 boot.CA01
drwxr-xr-x 2 root root 1024 23. Jan 22:55 grub
-rw------- 1 root root 8729859 6. Mär 15:41 initrd-4.9.255-eisfa
ir-64-VIRT.gz
-rw------- 1 root root 10908413 26. Mär 23:44 initrd-4.9.261-eisfa
ir-64-VIRT.gz
lrwxrwxrwx 1 root root 33 26. Mär 23:44 initrd.gz ->
initrd-4.9.261-eisfair-64-VIRT.gz
lrwxrwxrwx 1 root root 30 26. Mär 23:44 kernel ->
kernel-4.9.261-eisfair-64-VIRT
-rw-r--r-- 1 root root 5005808 15. Feb 22:12 kernel-4.9.255-eisfa
ir-64-VIRT
-rw-r--r-- 1 root root 5009904 20. Mär 11:21 kernel-4.9.261-eisfa
ir-64-VIRT
drwx------ 2 root root 1024 19. Aug 2018 lost+found
-rw------- 1 root root 467456 26. Mär 23:44 map
***@core:~#

[Thomas Bork]

Post by Gerd Walter
lba32
boot = /dev/xvda1
read-only
prompt
timeout = 50
vga = normal
menu-scheme = wr:bw:wr:Yr
image = /boot/kernel
#root = /dev/xvda3
root = "UUID=678cf645-2354-4b95-bdd2-1c474dd65fa1"

War in der alten lilo.conf (lilo.conf.OLD) das root-Device auch in eine
UUID konvertiert? Was passiert, wenn Du die Zeile

root = "UUID=678cf645-2354-4b95-bdd2-1c474dd65fa1"

kommentierst und wieder

root = /dev/xvda3

daraus machst? Samt Ausführung von lilo im chroot usw...

[Marcus Röckrath]

Hallo Thomas,

Post by Thomas Bork

Post by Gerd Walter
#root = /dev/xvda3
root = "UUID=678cf645-2354-4b95-bdd2-1c474dd65fa1"

War in der alten lilo.conf (lilo.conf.OLD) das root-Device auch in eine
UUID konvertiert? Was passiert, wenn Du die Zeile
root = "UUID=678cf645-2354-4b95-bdd2-1c474dd65fa1"
kommentierst und wieder
root = /dev/xvda3
daraus machst? Samt Ausführung von lilo im chroot usw...

Soweit, dass ein falscher root-Eintrag eine Rolle spielen könnte, kommt das
System doch garnicht.

Laut dem Directory-Listing in /boot existiert-rw------- 1 root
root   467456 26. Mär 23:44 map

-rw------- 1 root root   467456 26. Mär 23:44 map

und hat auch eine passende Größe und wurde mit gleichem Zeitstempel wie die
Links geschrieben.

Das müsste der Updatezeitraum gewesen sein.

Diese 99 kenne ich noch von ganz früher aus meinen Linuxanfangsjahren, als
ich schonmal verpennt hatte nach Neukompilieren eines Kernels lilo
aufzurufen.

Das scheint hier aber nicht der Fall zu sein.

[Gerd Walter]

Hallo Thomas,

Am 29.03.2021 um 20:51 schrieb Gerd Walter:> lba32> boot = /dev/xvda1> read-only> prompt> timeout = 50> vga = normal> menu-scheme = wr:bw:wr:Yr> image = /boot/kernel> #root = /dev/xvda3> root = "UUID=678cf645-2354-4b95-bdd2-1c474dd65fa1"War in der alten lilo.conf (lilo.conf.OLD) das root-Device auch in eine UUID konvertiert? Was passiert, wenn Du die Zeile root = "UUID=678cf645-2354-4b95-bdd2-1c474dd65fa1"kommentierst und wieder root = /dev/xvda3daraus machst? Samt Ausführung von lilo im chroot usw...-- der tom

Habe ich gemacht.
lilo lief ohne Fehkermeldung durch.
Fehlerbild bleibt.

Es ist eine Testinstallation, kann ich auch neu aufsetzen.

***@core:~# xl block-attach Domain-0 phy: /dev/
core-hd0/eisfair64-data xvda w
***@core:~# fdisk -l /dev/xvda
Disk /dev/xvda: 20 GiB, 21474836480 bytes, 41943040 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D764173E-874E-47A3-A5E4-C32430BA7682

Device Start End Sectors Size Type
/dev/xvda1 2048 100351 98304 48M Linux filesystem
/dev/xvda2 100352 4294655 4194304 2G Linux swap
/dev/xvda3 4294656 12683263 8388608 4G Linux filesystem
/dev/xvda4 12683264 41922526 29239263 13,9G Linux filesystem
***@core:~# blkid /dev/xvda
/dev/xvda1: UUID="d08460cc-f0fa-4fc3-a171-89ce25116b34"
BLOCK_SIZE="1024" TYPE="ext4" PTTYPE="dos" PARTLABEL="boot"
PARTUUID="2af59496-203c-4478-933f-c9c1d6ea6f45"
/dev/xvda2: UUID="e1fb454c-3910-45ac-8db3-84fdabaddf02"
TYPE="swap" PARTLABEL="swap" PARTUUID="a0c3a0b5-3e4c-4c4f-8d37-21
c267a07fd0"
/dev/xvda3: UUID="678cf645-2354-4b95-bdd2-1c474dd65fa1"
BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="root" PARTUUID="920e372a
-769c-4f56-8b49-c79edcc25808"
/dev/xvda4: UUID="8589ac09-03f2-4fdb-8c15-beaaf3ba619e"
BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="data" PARTUUID="318dbc72
-4348-414c-8700-39fb18706bc1"
***@core:~#

[Gerd Walter]

da fehlt noch

***@core:~# blkid /dev/xvda
/dev/xvda: PTUUID="d764173e-874e-47a3-a5e4-c32430ba7682" PTTYPE="gpt"

[Marcus Röckrath]

Hallo Gerd,

Post by Gerd Walter
Habe ich gemacht.
lilo lief ohne Fehkermeldung durch.
Fehlerbild bleibt.

Kannst du mal lilo -v nehmen, um eventuell mehr Meldungen zu produzieren.