[Eisfair_dev] [e1] eiskernel 4.1.2 (Status 'unstable') verfügbar - 4.9er Kernel für eisfair-1

[Helmut Backhaus]

Hallo zusammen!

Am 25.11.19 um 22:50 schrieb Thomas Bork:
> Hi @all,
> 
> ab 23:45 Uhr ist eine Version 4.1.2 von eiskernel mit dem Status
> 'unstable' für eisfair-1 verfügbar.
> 
> Das ist das erste eiskernel-Paket für eisfair mit einem 4.9.y-Kernel.
> Vorab gab es mehrere interne Versionen für das Test-Team, in denen wir
> versucht haben, alle möglicherweise auftretenden Probleme beim Umstieg
> zu erkennen und zu beseitigen. Trotzdem vorab diese Warnung:
> 
> 1.
> Installiert das Update nur auf Systemen, für die Ihr eine Sicherung
> parat habt!

Hatte ich nicht, aber neu aufsetzen wäre auch kein Beinbruch.
Das sind Testsysteme ...

> 
> Der Status ist 'unstable'. Es ist trotzdem toll, wenn Ihr (nach einer
> Sicherung des Alt-Systems natürlich) testet :-)

Habe ich gemacht, das eine ist ein System unter XEN mit einem virt
kernel, das andere ein Hardware PC mit smp kernel.

> 
> 2.
> Vergewissert Euch, dass von Euch verwendete externe Module für diesen
> Kernel noch existieren. Im Vergleich zu älteren Kerneln und bedingt
> durch den Wechsel der Kernel-Linie sind einige externe Module für
> AVM-Hardware weggefallen, was aber aufgrund abnehmender Relevanz von
> ISDN wahrscheinlich keine Rolle mehr für Euch spielen wird.
> 
> Die grösste Hürde für den Umstieg war die Vorbereitung auf den
> gewünschten Wegfall der alten IDE-Treiber mit dem Namens-Schema
> /dev/hdX. Dazu waren einige Änderungen nötig:
> 
> udev musste beigebracht werden, Einträge unter /dev/disk/by-id und
> /dev/disk/by-uuid für alte IDE-Treiber zu schreiben, damit der
> Bootmanager lilo die Devices findet, auch wenn sie nicht mehr /dev/hdX
> heissen. Die lilo.conf musste beim Kernel-Update umgeschrieben werden,
> damit sie statt mit Device-Namen mit by-id und by-uuid arbeitet. Die
> /etc/inittab musste umgeschrieben werden, damit nötige Partitionen
> anhand der UUID und nicht des alten Namens /dev/hdX gefunden werden. Die
> initramfs, aus der das System startet, musste umgearbeitet werden, damit
> sie mittels udev die nötigen Treiber als Ersatz für den ehemals fest
> eingebauten IDE-Treiber findet. Die Kernel-Pakete mussten umgearbeitet
> werden, damit sie von und zu /dev/disk/by-id und /dev/disk/by-uuid
> konvertieren könnten usw.

Das hat alles Problemlos geklappt, auch habe ich nicht feststellen
können das irgend etwas nicht funktioniert.

> 
> Inzwischen hoffen wir, dass der Umstieg schmerzfrei gelingt. Sollten
> bestimmte Gegebenheiten auf Euren Systemen nicht existieren, haben wir
> versucht das abzufangen, z.B. mit Tests im Kernel-Update. Hat jemand
> Änderungen des base-Updates an der inittab rückgängig gemacht und
> mountet dort /dev/hdX-Devices statt UUIDs mit der Option auto, dann wird
> das Kernel-Update sich nicht installieren lassen.
> Existiert kein by-id oder by-uuid-Eintrag, wird das Kernel-Update sich
> nicht installieren lassen...
> 
> Weitere mögliche Probleme und Lösungen (z.B. eine zu kleine
> /boot-Partition für den erhöhten Platzbedarf von Kernel und initramfs)
> hat Marcus unter
> 
> https://web.nettworks.org/wiki/display/e/Anmerkungen+zum+Wechsel+vom+3.16er+zum+4.9er+Kernel
> 
> 
> zusammen getragen. Schaut bei Problemen bitte zuerst dort hinein!
> 

Hier hatte ich die größten bedenken, da ich nur 96 MB für die boot
Partition hatte.
Das sieht jetzt so aus:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda3      2.0G 1013M  850M  55% /
tmpfs           249M   80K  249M   1% /run
devtmpfs        239M  4.0K  239M   1% /dev
/dev/xvda1       93M   28M   59M  32% /boot
/dev/xvdb1      4.8G  1.1G  3.5G  24% /data
tmpfs           249M     0  249M   0% /run/shm

Das sieht hier ja sehr gut aus, oder?

ls -l /boot
total 27077
-rw-r--r-- 1 root root     512 May 26  2004 boot.0300
-rw-r--r-- 1 root root     512 Feb 22  2016 boot.CA00
-rw-r--r-- 1 root root    4368 May 26  2004 boot.b
drwxr-xr-x 2 root root    1024 Feb  7  2016 grub
-rw-r--r-- 1 root root 3144167 Nov 26 17:15 initrd-3.16.74-VIRT.gz
-rw-r--r-- 1 root root 8463156 Nov 26 17:15 initrd.gz
-rw-r--r-- 1 root root 4654608 Nov 26 17:15 kernel
-rw-r--r-- 1 root root 4004688 Nov 26 17:15 kernel-3.16.74-VIRT
drwx------ 2 root root   12288 Feb  7  2016 lost+found
-rw------- 1 root root  288768 Nov 26 17:16 map
-rw-r--r-- 1 root root 3144167 Oct  9 22:06 old-initrd.gz
-rw-r--r-- 1 root root 4004688 Oct  9 22:06 old-kernel

Dann habe ich auch noch einen Hardware PC hochgezogen, auch hier die Daten:

Hier hatte ich sogar nur 43 MB:

df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3       4.8G  2.0G  2.7G  43% /
tmpfs           119M  180K  119M   1% /run
devtmpfs        115M     0  115M   0% /dev
/dev/sda1        43M   31M  8.5M  79% /boot
/dev/sda4        32G  5.1G   25G  17% /data
tmpfs           119M     0  119M   0% /run/shm

Mal sehen, wie sich das weiter entwickelt.
Was meint ihr, kann ich das so lassen?

Der Vollständigkeit halber:
ls -l /boot
total 30617
-rw-r--r-- 1 root root     512 May 26  2004 boot.0300
-rw-r--r-- 1 root root     512 Jan 30  2015 boot.1600
-rw-r--r-- 1 root root    4368 May 26  2004 boot.b
-rw-r--r-- 1 root root 3309542 Oct  9 22:19 initrd-3.16.70-SMP.gz
-rw-r--r-- 1 root root 3309593 Nov 28 00:13 initrd-3.16.74-SMP.gz
-rw-r--r-- 1 root root 8364182 Nov 28 00:13 initrd.gz
-rw-r--r-- 1 root root 3563584 Nov 28 00:13 kernel
-rw-r--r-- 1 root root 3044240 Oct  9 22:19 kernel-3.16.70-SMP
-rw-r--r-- 1 root root 3050192 Nov 28 00:13 kernel-3.16.74-SMP
drwx------ 2 root root   12288 Jan 30  2015 lost+found
-rw------- 1 root root  326144 Nov 28 00:14 map
-rw-r--r-- 1 root root 3309593 Oct  9 22:19 old-initrd.gz
-rw-r--r-- 1 root root 3050192 Oct  9 22:19 old-kernel


Es sieht bis jetzt gut aus, Probleme habe ich bis jetzt noch nicht
gefunden. Wie ich euch kenne, wird es wohl auch keine geben.

Herzlichen Dank für eure Arbeit!



-- 
Gruß,
Helmut