[e64] eiskernel 3.45.0 (Status 'testing') verfügbar - 3.16er Kernel für eisfair-64

[Thomas Bork]

Hi @all,

ab 14:45 Uhr ist eine Version 3.45.0 von eiskernel mit dem Status
'testing' für eisfair-64 verfügbar.

Intern wird hierfür der Kernel 3.16.70 aus der Longterm-Kernel-Serie
3.16 verwendet.

Siehe dazu:

https://www.kernel.org/category/releases.html

Der Kernel enthält die PTI-Patches. Diese sind bei uns aktiv, da die
Implementation bei 64-Bit-Kerneln greift (im Gegensatz zu den
32-Bit-Kerneln von eisfair-1).

https://de.wikipedia.org/wiki/Kernel_page-table_isolation

Dieser Kernel wird nur als VIRT-Variante angeboten. Aufgrund der
Eigenschaften des 64-bit-Kernels sind verschiedene Varianten (SMP, PAE
und VIRT) nicht mehr notwendig.

Dieses Kernel-Paket lässt sich auf allen Systemen mit normaler Hardware
und laufendem Kernel 3.16.xx-eisfair-64-VIRT installieren.

Beim Update von einem älteren Kernel als 3.16.70-eisfair-64-VIRT aus
wird *bei genügend Platz in /boot* ein lilo-Start-Eintrag für diesen
Kernel erzeugt, wenn noch kein Backup unter /boot existiert, um
problemlos diesen alten stabilen Kernel booten zu können. Beim Update
von 3.16.70-eisfair-64-VIRT aus werden alle alten Kernel samt der
Fallbacks gelöscht, wenn dieser Kernel den stabilen Status erreicht.

Zu den angegebenen eiskernel-Namen (z.B. 3.16.70-eisfair-64-VIRT) und
den darin enthaltenen Versionen siehe [1].

Denkt daran, eventuell bei Euch installierte kernel-abhängige Treiber
(z.B. die AVM- und Dahdi-Module) für diesen Kernel vorher zu
installieren, da der Name sich geändert hat!


Änderungen zum stabilen eiskernel 3.44.0:
=========================================
- Name auf 3.16.70-eisfair-64 geändert (war 3.16.69-eisfair-64).
- Alle Patches bis zu 3.16.70 integriert (war 3.16.69).
- microcode-20190514a.tar.gz -> microcode-20190618.tar.gz.
- Benötigt udev 2.8.1.
- Wenn es sich nicht um ein md-Device handelt, wird das boot-Device
in /etc/lilo.conf zu /dev/disk/by-id/ konvertiert. Eine Ausnahme
wird nur unter Xen gemacht, bei dem manchmal /dev/disk/by-id/ nicht
existiert.
- Wenn es sich nicht um ein md-Device handelt, wird das root-Device
in /etc/lilo.conf zu /dev/disk/by-uuid/ konvertiert.

Diese Konvertierung ist die Vorbereitung für einen kommenden Kernel, der
nicht mehr die alten, fest eingebauten IDE-Treiber verwendet, sondern
die neuen, libata-basierenden modularisierten IDE-Treiber.

Bitte postet bei Schwierigkeiten unbedingt die Ausgabe von

cat /var/log/log.kernel-update

nach dem Kernel-Update.

- CONFIG_HW_RANDOM nicht mehr modular, sondern fest eingebaut:
+CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_TIMERIOMEM=m
-CONFIG_HW_RANDOM_INTEL=m
-CONFIG_HW_RANDOM_AMD=m
-CONFIG_HW_RANDOM_VIA=m
-CONFIG_HW_RANDOM_VIRTIO=m
+CONFIG_HW_RANDOM_INTEL=y
+CONFIG_HW_RANDOM_AMD=y
+CONFIG_HW_RANDOM_VIA=y
+CONFIG_HW_RANDOM_VIRTIO=y


Dieses Paket bei https://pack-eis.de:
=====================================
VIRT: https://www.pack-eis.de/index.php?p=31983


Gleichzeitig wird wie gewohnt auch das Paket eiskernel-dev mit den
Quellen passend zu diesem Kernel freigegeben.


Änderungen zum vorherigen stabilen eiskernel-dev 3.44.0:
========================================================
- Basiert auf 3.16.70 (war 3.16.69).
- Setzt installierten eiskernel 3.45.0 voraus.
- Lädt 3.16.70 herunter (war 3.16.69).
- Benötigt gcc 2.8.5.


Dieses Paket bei https://pack-eis.de:
=====================================
https://www.pack-eis.de/index.php?p=31984


Der Kernel 3.16.70:
===================
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?id=refs/tags/v3.16.70


[1]
Übersicht der 3.16er eiskernel-64-Pakete:
=========================================

eiskernel-Vers.| eiskernel-Name | Patchlevel Vanilla
______________________________________________________
3.45.0 | 3.16.70-eisfair-64 | 3.16.70
3.44.0 | 3.16.69-eisfair-64 | 3.16.69
3.43.0 | 3.16.69-eisfair-64 | 3.16.69
3.42.1 | 3.16.68-eisfair-64 | 3.16.68
3.42.0 | 3.16.68-eisfair-64 | 3.16.68
3.41.0 | 3.16.68-eisfair-64 | 3.16.68
3.40.0 | 3.16.65-eisfair-64 | 3.16.65
3.39.0 | 3.16.65-eisfair-64 | 3.16.65
3.38.1 | 3.16.63-eisfair-64 | 3.16.63
3.38.0 | 3.16.63-eisfair-64 | 3.16.63
3.37.0 | 3.16.63-eisfair-64 | 3.16.63
3.36.0 | 3.16.62-eisfair-64 | 3.16.62
3.35.0 | 3.16.62-eisfair-64 | 3.16.62
3.34.0 | 3.16.60-eisfair-64 | 3.16.60
3.33.0 | 3.16.60-eisfair-64 | 3.16.60
3.32.0 | 3.16.58-eisfair-64 | 3.16.58
3.31.0 | 3.16.58-eisfair-64 | 3.16.58
3.30.1 | 3.16.57-eisfair-64 | 3.16.57
3.30.0 | 3.16.57-eisfair-64 | 3.16.57
3.27.0 | 3.16.56-eisfair-64 | 3.16.56
3.26.0 | 3.16.54-eisfair-64 | 3.16.54
3.25.0 | 3.16.54-eisfair-64 | 3.16.54
3.23.0 | 3.16.53-eisfair-64 | 3.16.53
3.21.0 | 3.16.50-eisfair-64 | 3.16.50


Ich danke allen Mitgliedern des Teams für Tests und Unterstützung und
wünsche allen Anwendern weiterhin viel Spass mit eisfair!


Das Posting geht parallel an spline.eisfair und spline.eisfair.dev.
Produktive Rückmeldungen bitte an spline.eisfair.dev.

[Peter Bäumer]

Glück Auf! Thomas
Installation bei einer XEN domU ohne Auffälligkeiten.

Diese Konvertierung ist die Vorbereitung für einen kommenden Kernel, der nicht mehr die alten, fest eingebauten IDE-Treiber verwendet, sondern die neuen, libata-basierenden modularisierten IDE-Treiber.

Sehe ich das richtig das die Xen domU schon die libata basierenden IDE-Treiber verwendet?
libata 164633 2 ahci,libahci
sd_mod 36150 0
scsi_mod 102042 2 libata,sd_mod



MfG
Peter B.

[Thomas Bork]

Post by Peter Bäumer
Sehe ich das richtig das die Xen domU schon die libata basierenden IDE-Treiber verwendet?
libata                164633  2 ahci,libahci

Nö, der ahci ist kein IDE-Treiber.

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork

Post by Peter Bäumer
Sehe ich das richtig das die Xen domU schon die libata basierenden IDE-Treiber verwendet?
libata                164633  2 ahci,libahci

Nö, der ahci ist kein IDE-Treiber.

IMHO doch; mein e64:

00:12.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB600
Non-Raid-5 SATA (prog-if 01 [AHCI 1.0])
Subsystem: Foxconn International, Inc. SB600 Non-Raid-5 SATA
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64
Interrupt: pin A routed to IRQ 22
Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable)
[size=8]
Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable)
Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable)
[size=8]
Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable)
Region 4: I/O ports at ff00 [size=16]
Region 5: Memory at f0000000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ahci
Kernel modules: ahci

[Thomas Bork]

In der Kernel-Konfiguration ist der ahci bei SATA und nicht bei ATA oder
PATA einsortiert. Dass er auch SATA-Controller im IDE-Modus ansteuern
kann, Àndert daran nichts.

[Peter Bäumer]

Post by Thomas Bork

Post by Peter Bäumer
Sehe ich das richtig das die Xen domU schon die libata basierenden IDE-Treiber verwendet?
libata                164633  2 ahci,libahci

Nö, der ahci ist kein IDE-Treiber.

Ich stelle mir gerade die Frage wie der Bootablauf bei der domU ist.
Die Informationen wo der Kernel liegt und was an Platte verwendet werden soll liegt außerhalb der domU in der dom0 in einer cfg-Datei.
Über LILO bootet die domU nicht und die boot Partition wird nur fürs Kernel update benötigt (mit händischen kopieren des Kernels zur dom0)

Die Umstellung von /dev/[Gerätedateiname] zu UUID bei der fstab und lilo.conf helfen die Festplatten eindeutig zu Identifizieren, so das keine Bezeichnungen der Platten vertauscht werden.

Wäre für mich interessant zu wissen ob die angaben aus der cfg Datei ausreichend das da kein Verdreher vor kommen kann?

Würde gerne die alt Bezeichnungen behalten, macht mir das Klonen einer Fertigen domU einfacher :)

MfG
Peter B.

Post by Thomas Bork
kernel = "/etc/xen/eiskernel/nx-03-03/kernel"
ramdisk = "/etc/xen/eiskernel/nx-03-03/initrd.gz"
root = "/dev/xvda3"
boot = "c"
extra = "console=hvc0 xencons=tty1 net.ifnames=0 ro quiet"
memory = 1024
name = "nx-03-03"
vif = [ 'mac=02:00:31:00:02:23, bridge=xenbr0, model=e1000' ]
disk = [ 'phy:/dev/vg1/nx-03-03_root,xvda3,w' ,
'phy:/dev/vg1/nx-03-03_swap,xvda2,w' ,
'phy:/dev/vg1/nx-03-03_boot,xvda1,w'
]

[Thomas Bork]

Kann ich nicht beantworten. Ich habe keine Ahnung von Xen und bin froh,
dass es im Moment so funktioniert. Damit wirst du dann wohl
experimentieren mÃŒssen.

Um zu verhindern, dass es nach Umstellung des kommenden Kernels beim
Booten zu Problemen kommt, muss ich aber unkonvertierte Devices als
Fehler betrachten und die Installation abbrechen. Ausnahme ist wie schon
geschrieben Xen ohne by-id und das Boot-Device...

[Gerd Walter]

Hallo Peter,

Post by Peter Bäumer
Ich stelle mir gerade die Frage wie der Bootablauf bei der domU ist.
Die Informationen wo der Kernel liegt und was an Platte verwendet werden
soll liegt außerhalb der domU in der dom0 in einer cfg-Datei.
Über LILO bootet die domU nicht und die boot Partition wird nur fürs
Kernel update benötigt (mit händischen kopieren des Kernels zur dom0)
Die Umstellung von /dev/[Gerätedateiname] zu UUID bei der fstab und
lilo.conf helfen die Festplatten eindeutig zu Identifizieren, so das
keine Bezeichnungen der Platten vertauscht werden.
Wäre für mich interessant zu wissen ob die angaben aus der cfg Datei
ausreichend das da kein Verdreher vor kommen kann?
Würde gerne die alt Bezeichnungen behalten, macht mir das Klonen einer
Fertigen domU einfacher :)

Wenn die Festplatten einfach Klonst, werden doch die UUIDs nicht verändert.

[Marcus Roeckrath]

Hallo Gerd,

Post by Gerd Walter
Wenn die Festplatten einfach Klonst, werden doch die UUIDs nicht verändert.

Sicher, aber dass was bei boot= in der lilo.conf steht, wird sich ändern.

z. B.

boot = /dev/disk/by-id/ata-ST3160215A_9RABEDAP

Das dürfte den Boot einer geklonten Platte nicht berühren. Ob das dann durch
ein anschließendes Kernelupdate korrigiert wird, habe ich noch nicht
getestet.

[Gerd Walter]

Hallo Marcus,

Post by Marcus Roeckrath
Hallo Gerd,

Post by Gerd Walter
Wenn die Festplatten einfach Klonst, werden doch die UUIDs nicht verändert.

Sicher, aber dass was bei boot= in der lilo.conf steht, wird sich ändern.
z. B.
boot = /dev/disk/by-id/ata-ST3160215A_9RABEDAP
Das dürfte den Boot einer geklonten Platte nicht berühren. Ob das dann durch
ein anschließendes Kernelupdate korrigiert wird, habe ich noch nicht
getestet.

Es gibt bei mir unter XEN und sicher auch bei Peter kein by-id.


eis # cat /etc/lilo.conf
lba32
disk = /dev/xvda
bios = 0x80
boot = /dev/xvda
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"

[Marcus Roeckrath]

Hallo Gerd,

Post by Gerd Walter

Post by Marcus Roeckrath

Post by Gerd Walter
Wenn die Festplatten einfach Klonst, werden doch die UUIDs nicht verändert.

Sicher, aber dass was bei boot= in der lilo.conf steht, wird sich ändern.
z. B.
boot = /dev/disk/by-id/ata-ST3160215A_9RABEDAP
Das dürfte den Boot einer geklonten Platte nicht berühren. Ob das dann
durch ein anschließendes Kernelupdate korrigiert wird, habe ich noch
nicht getestet.

Es gibt bei mir unter XEN und sicher auch bei Peter kein by-id.

Klar, aber auch für Otto-nicht-viruell-eisfair kommt man schonmal dazu, eine
Platte zu klonen und dann dürfte obiges schon interessant und bedenkenswert
sein.

[Thomas Bork]

Wird die Platte geclont und liegt root darauf, bricht das Kernel-Update
ab, da es das Device Ìber die nun anderen by-id-EintrÀge nicht mehr
ermitteln kann. Dann hilft nur die Änderung in den Device-Namen in der
lilo.conf vor dem Update.

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork
Wird die Platte geclont und liegt root darauf, bricht das Kernel-Update
ab, da es das Device über die nun anderen by-id-Einträge nicht mehr
ermitteln kann. Dann hilft nur die Änderung in den Device-Namen in der
lilo.conf vor dem Update.

Also alles wieder zurück auf Anfang:

lba32
disk = /dev/sda
bios = 0x80
boot = /dev/sda
# boot = /dev/disk/by-id/ata-ST3160215A_9RABEDAP
read-only
prompt
timeout = 50
vga = normal
menu-scheme = Wb:Kw:Wb:Yk
image = /boot/kernel
root = /dev/hda3
# root = "UUID=766b01c2-d5e3-4129-979d-f8e5e2558ae4"

Das würde ich dann mal als Wiki-Artikel zusammenfassen.

[Marcus Roeckrath]

Post by Marcus Roeckrath
Hallo Thomas,

Post by Thomas Bork
Wird die Platte geclont und liegt root darauf, bricht das Kernel-Update
ab, da es das Device über die nun anderen by-id-Einträge nicht mehr
ermitteln kann. Dann hilft nur die Änderung in den Device-Namen in der
lilo.conf vor dem Update.

lba32
disk = /dev/sda
bios = 0x80
boot = /dev/sda
# boot = /dev/disk/by-id/ata-ST3160215A_9RABEDAP
read-only
prompt
timeout = 50
vga = normal
menu-scheme = Wb:Kw:Wb:Yk
image = /boot/kernel
root = /dev/hda3

root = /dev/sda3

Post by Marcus Roeckrath
# root = "UUID=766b01c2-d5e3-4129-979d-f8e5e2558ae4"
Das würde ich dann mal als Wiki-Artikel zusammenfassen.

[Marcus Roeckrath]

Hallo Peter,

Post by Peter Bäumer
Glück Auf! Thomas
Installation bei einer XEN domU ohne Auffälligkeiten.

Post by Thomas Bork
Diese Konvertierung ist die Vorbereitung für einen kommenden Kernel, der
nicht mehr die alten, fest eingebauten IDE-Treiber verwendet, sondern die
neuen, libata-basierenden modularisierten IDE-Treiber.

Sehe ich das richtig das die Xen domU schon die libata basierenden IDE-Treiber verwendet?
libata 164633 2 ahci,libahci
sd_mod 36150 0
scsi_mod 102042 2 libata,sd_mod

Thomas hat das ja verneint, ich sehe das etwas anders.

Was sagt lspci -vv für den SATA-Controller?

[Peter Bäumer]

Post by Marcus Roeckrath
Hallo Peter,

Post by Peter Bäumer
Glück Auf! Thomas
Installation bei einer XEN domU ohne Auffälligkeiten.

Post by Thomas Bork
Diese Konvertierung ist die Vorbereitung für einen kommenden Kernel, der
nicht mehr die alten, fest eingebauten IDE-Treiber verwendet, sondern die
neuen, libata-basierenden modularisierten IDE-Treiber.

Sehe ich das richtig das die Xen domU schon die libata basierenden IDE-Treiber verwendet?
libata 164633 2 ahci,libahci
sd_mod 36150 0
scsi_mod 102042 2 libata,sd_mod

Thomas hat das ja verneint, ich sehe das etwas anders.
Was sagt lspci -vv für den SATA-Controller?

Nix, ist eine Xen VM da gibt es kein pci

Siehe anderes Posting wo ich was zum booten geschrieben habe.

MfG
Peter B.

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork
ab 14:45 Uhr ist eine Version 3.45.0 von eiskernel mit dem Status
'testing' für eisfair-64 verfügbar.

Rennt auf meiner Buildmaschine.