[e1] eiskernel 4.1.3 (Status 'testing') verfügbar - 4.9er Kernel für eisfair-1

[Thomas Bork]

Hi @all,

es ist eine Version 4.1.3 von eiskernel mit dem Status 'testing' für
eisfair-1 verfügbar.

Intern wird hierfür der Kernel 4.9.196 aus der Longterm-Kernel-Serie 4.9
verwendet.

Siehe dazu:

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

Obwohl der Kernel die PTI-Patches enthält, werden diese bei uns nicht
aktiv, da die bisherige Implementation nicht bei 32-Bit-Kerneln greift.

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


Dieser Kernel wird in 3 Varianten angeboten (alle 32-Bit):

1. SMP
2. PAE
3. VIRT

Der SMP-Kernel unterstützt Systeme mit einem oder mehreren Prozessoren
und Prozessoren mit einem oder mehreren physikalischen oder virtuellen
Kernen.

Der PAE-Kernel ist der SMP-Kernel plus PAE und Sparse-Memory-Model. Die
CPU muss die Features cmov und pae unterstützen - das wird bei der
Installation überprüft.

Ein emulierter mathematischer Co-Prozessor (CONFIG_MATH_EMULATION) ist
nur noch bei SMP gesetzt (um auch alte 486 ohne Co-Prozessor zu
unterstützen). Ab PAE ist sowieso immer ein solcher Co-Prozessor
vorhanden, PAE und VIRT bringen die Emulation deswegen bei uns nicht mit
- das spart Platz.
Ab PAE ist das NX-Bit gesetzt, PAE und VIRT sind somit sicherer als SMP.
Ab PAE ist ausserdem CONFIG_TRANSPARENT_HUGEPAGE gesetzt.

Wenn man einen Prozessor verwendet, der cmov und pae unterstützt und
wenn man noch dazu mehr als 4GB RAM ansprechen möchte, sollte man also
die PAE-Variante installieren.

Der VIRT-Kernel sollte alle notwendigen Features mitbringen (die die
verwendete Kernel-Version anbietet), um als Gast-Kernel auf
Virtualisierungs-Systemen zu laufen. Er ist der PAE-Kernel, erweitert um
Funktionen für Xen, KVM und Hyper-V.

Diese Kernel-Pakete lassen sich auf allen Systemen mit laufendem Kernel
3.2.xx-eisfair-1, 3.16.xx-eisfair-1 und 4.9.xxx installieren.

Beim Update von einem älteren Kernel als 4.9.196-eisfair-1 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
4.9.196-eisfair-1 aus werden alle alten Kernel samt der Fallbacks
gelöscht, wenn dieser Kernel den stabilen Status erreicht.

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!

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


Änderungen zum stabilen eiskernel 3.48.0:
=========================================
- Name auf 4.9.196-eisfair-1 geändert (war 3.16.74-eisfair-1).
- Alle Patches bis zu 4.9.196 integriert (war 3.16.74).
- Update intel microcode-20190918.tar.gz -> microcode-20191115.tar.gz.
- Update AMD microcode für Processor-Familie 17h.
- /tmp/scsi.list wird nicht mehr verwendet.
- info-Dateien sind jetzt mit sha256sum versehen.

Änderungen zum unstable eiskernel 4.1.2:
========================================
- Status auf 'testing' geändert.
- /var/install/initrd/initramfs_udev.tar.gz/initparttwo:
- Bei Angabe von root-Devices in UUID-Form wird jetzt maximal 10
Sekunden auf das Auftauchen des Links unter /dev/disk/by-uuid/
gewartet. Das behebt Probleme beim Boot von langsamen USB-Sticks.

Dieses Paket bei https://pack-eis.de:
=====================================
PAE : https://www.pack-eis.de/index.php?p=34809
SMP : https://www.pack-eis.de/index.php?p=34810
VIRT: https://www.pack-eis.de/index.php?p=34811


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

Änderungen zum vorherigen stabilen eiskernel-dev 3.48.0:
========================================================
- Basiert auf 4.9.196 (war 3.16.74).
- Setzt installierten eiskernel 4.9.196 voraus.
- Lädt 4.9.196 herunter (war 3.16.74).
- info-Dateien sind jetzt mit sha256sum versehen.

Änderungen zum unstable eiskernel-dev 4.1.2:
============================================
- Status auf 'testing' geändert.
- /tmp/install.sh:
Fehler bei Ermittlung des Status des Paketes behoben.
- Setzt installierten eiskernel 4.1.3 voraus.

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


Der Kernel 4.9.196:
===================
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?id=refs/tags/v4.9.196


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

eiskernel-Vers.| eiskernel-Name | Patchlevel Vanilla
_______________________________________________________
4.1.3 | 4.9.196-eisfair-1 | 4.9.196
4.1.2 | 4.9.196-eisfair-1 | 4.9.196


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.

[Marcus Roeckrath]

Hallo Thomas,

Post by Thomas Bork
es ist eine Version 4.1.3 von eiskernel mit dem Status 'testing' für
eisfair-1 verfügbar.

Update und Reboot auf zwei Maschinen erfolgreich.

[Fabian Törner]

Hi tom,

Post by Thomas Bork
es ist eine Version 4.1.3 von eiskernel mit dem Status 'testing' für
eisfair-1 verfügbar.
Intern wird hierfür der Kernel 4.9.196 aus der Longterm-Kernel-Serie 4.9
verwendet.
https://www.kernel.org/category/releases.html
Obwohl der Kernel die PTI-Patches enthält, werden diese bei uns nicht
aktiv, da die bisherige Implementation nicht bei 32-Bit-Kerneln greift.
https://de.wikipedia.org/wiki/Kernel_page-table_isolation
1. SMP
2. PAE

bei mir ebenfalls ohne Probleme im Einsatz.

Vielen Dank & viele Grüße
Fabian

[Holger Bruenjes]

Hallo Dirk

Könnte der hintere "Unterstrich" bei der Disk-ID der Fehler sein?  Ich
traue mich grad gar nicht den kleinen Server runterzufahren, zumal ich
da keinen Monitor dran habe.
scanner # ls /dev/disk/by-id
ata-TS8GCF133_625736CB2361DF000029
ata-TS8GCF133_625736CB2361DF000029-part1
ata-TS8GCF133_625736CB2361DF000029-part2
scanner # cat /etc/lilo.conf
lba32
#boot = /dev/hda
boot = /dev/disk/by-id/ata-TS8GCF133_625736CB2361DF000029_

ja, mach ihn wech und dann mal mit lilo -t ueberpruefen

Holger

[Dirk Alberti]

Hallo Holger,

Post by Holger Bruenjes
Hallo Dirk

Könnte der hintere "Unterstrich" bei der Disk-ID der Fehler sein?

ja, mach ihn wech und dann mal mit lilo -t ueberpruefen

jawoll:

scanner # lilo -t
Added eis  +  *
Added oldeis
Added 3.16.70-SMP
Added 3.16.74-SMP
The boot sector and the map file have *NOT* been altered.



Und wie nun weiter? Nochmal das Update laufen lassen? Wie kommt der
Unterstrich da hin? Ich wars nicht. ;-)

Post by Holger Bruenjes
Holger

Dirk

[Marcus Roeckrath]

Hallo Dirk,

Post by Dirk Alberti

Post by Holger Bruenjes

Könnte der hintere "Unterstrich" bei der Disk-ID der Fehler sein?

ja, mach ihn wech und dann mal mit lilo -t ueberpruefen

scanner # lilo -t
Added eis  +  *
Added oldeis
Added 3.16.70-SMP
Added 3.16.74-SMP
The boot sector and the map file have *NOT* been altered.
Und wie nun weiter? Nochmal das Update laufen lassen?

IMHO ja.

Post by Dirk Alberti
Wie kommt der Unterstrich da hin? Ich wars nicht. ;-)

Keine Ahnung, aber durch die Kernelupdates IMHO auch nicht.

Das Update auf 4.1.2 scheint ja funktioniert zu haben, wenn du danach den
4er-Kernel booten konntest, sonst hätte der notwendige Aufruf von lilo beim
Kernelupdate alle Füße von sich gestreckt.

Oder unter dem alten 3er-Kernel war der Unterstrich für das Device "normal",
aber nun unter dem 4er-Kernel entfiel dieser?

Halte ich für unwahrscheinlich.

Der jetzige Updateversuch hat jedenfalls noch garnichts an der Datei getan.

Daher eben auch meine Frage nach datumstempel der Datei und dem Zeitpunkt
des ersten Updates auf den 4er-Kernel.

[Dirk Alberti]

Hallo Marcus,

Post by Marcus Roeckrath
Hallo Dirk,

Post by Dirk Alberti
Und wie nun weiter? Nochmal das Update laufen lassen?

IMHO ja.

Ok, das Update lief nun ohne Fehler durch.

Post by Marcus Roeckrath

Post by Dirk Alberti
Wie kommt der Unterstrich da hin? Ich wars nicht. ;-)

Keine Ahnung, aber durch die Kernelupdates IMHO auch nicht.
Das Update auf 4.1.2 scheint ja funktioniert zu haben, wenn du danach den
4er-Kernel booten konntest, sonst hätte der notwendige Aufruf von lilo beim
Kernelupdate alle Füße von sich gestreckt.

Ja eben, das dachte ich halt auch und hatte irgendwas im Update-Skript
im Verdacht. Denn seit dem Upadate auf den 4.1.2 war der Server noch gar
nicht wieder an.

Post by Marcus Roeckrath
Oder unter dem alten 3er-Kernel war der Unterstrich für das Device "normal",
aber nun unter dem 4er-Kernel entfiel dieser?
Halte ich für unwahrscheinlich.
Der jetzige Updateversuch hat jedenfalls noch garnichts an der Datei getan.
Daher eben auch meine Frage nach datumstempel der Datei und dem Zeitpunkt
des ersten Updates auf den 4er-Kernel.

Also, jetzt läuft er auch mit Eiskernel 4.1.3-SMP.

Vielen Dank Euch, und schönes WE.


Grüße, Dirk

[Marcus Roeckrath]

Hallo Dirk,

Post by Dirk Alberti

Post by Marcus Roeckrath

Post by Dirk Alberti
Wie kommt der Unterstrich da hin? Ich wars nicht. ;-)

Keine Ahnung, aber durch die Kernelupdates IMHO auch nicht.
Das Update auf 4.1.2 scheint ja funktioniert zu haben, wenn du danach den
4er-Kernel booten konntest, sonst hätte der notwendige Aufruf von lilo
beim Kernelupdate alle Füße von sich gestreckt.

Ja eben, das dachte ich halt auch und hatte irgendwas im Update-Skript
im Verdacht. Denn seit dem Upadate auf den 4.1.2 war der Server noch gar
nicht wieder an.

Wenn der Unterstrich zum Zeitpunkt schon drin war, muss entweder unter dem
damals laufenden Kernel auch das Device so geheißen haben (komisch) oder
das Kernelupdate hätte sich verweigert.

Post by Dirk Alberti
Also, jetzt läuft er auch mit Eiskernel 4.1.3-SMP.

Gut.

[Marcus Roeckrath]

Hallo Dirk,

Your lilo configuration is broken!

Ist das ein RAID-System?

IMHO kann das nicht sein, denn Thomas konvertiert RAID-Systeme nicht auf
by-id.

stat("/dev/disk/by-id/ata-TS8GCF133_625736CB2361DF000029_")
Repair your lilo configuration, cancelling installation.
-------------------------------------------------
Könnte der hintere "Unterstrich" bei der Disk-ID der Fehler sein?  Ich
traue mich grad gar nicht den kleinen Server runterzufahren, zumal ich
da keinen Monitor dran habe.

IMHO ja.

scanner # ls /dev/disk/by-id
ata-TS8GCF133_625736CB2361DF000029
ata-TS8GCF133_625736CB2361DF000029-part1
ata-TS8GCF133_625736CB2361DF000029-part2

Hast du ein Backup vor dem Update?

War da auch schon der 4er-Kernel installiert?

Wie sieht da /etc/lilo.conf aus?

scanner # cat /etc/lilo.conf
lba32
#boot = /dev/hda
boot = /dev/disk/by-id/ata-TS8GCF133_625736CB2361DF000029_

Der Unterstrich kann hier nicht richtig sein.

Läuft lilo -t durch, wenn du den Unterstrich entfernst?

Mit dem Kernel 4.1.2 bootete das System ganz normal und beim Upgrade vom
3er Kernel gab es auch keine Probleme. Nur eben jetzt mit dem Update zu
4.1.3.

Übrigens wurde das Kernelupdate doch überhaupt nicht durchgeführt, du
müsstest noch auf dem Stand davor sein.

Möglicherweise, ist das auch eine /etc/lilo.conf, die nun beim Kernelupdate
noch nicht angefasst wurde, weil Thomas diesen Check sehr früh macht.

Datumstempel der /etc/lilo.conf?

Zeitpunkt des Updates auf eiskernel 4.1.2?

Eventuell eine unbewußt reingerutschte Änderung an der /etc/lilo.conf, weil
die ja durchaus Änderungen deinerseits hat.

[Dirk Alberti]

Hallo Marcus,

Post by Marcus Roeckrath
Hallo Dirk,

Your lilo configuration is broken!

Ist das ein RAID-System?

nein, das ist kein RAID-System. Das ist nur eine CF-Karte in einem
IDE2CF-Adapter.

Post by Marcus Roeckrath
IMHO kann das nicht sein, denn Thomas konvertiert RAID-Systeme nicht auf
by-id.

stat("/dev/disk/by-id/ata-TS8GCF133_625736CB2361DF000029_")
Repair your lilo configuration, cancelling installation.
-------------------------------------------------
Könnte der hintere "Unterstrich" bei der Disk-ID der Fehler sein?  Ich
traue mich grad gar nicht den kleinen Server runterzufahren, zumal ich
da keinen Monitor dran habe.

IMHO ja.

scanner # ls /dev/disk/by-id
ata-TS8GCF133_625736CB2361DF000029
ata-TS8GCF133_625736CB2361DF000029-part1
ata-TS8GCF133_625736CB2361DF000029-part2

Hast du ein Backup vor dem Update?

Nein, habe ich nicht, weil der zur Not auch wieder schnell neu gemacht
ist. Außer SANE läuft da nicht viel anderes drauf.

Post by Marcus Roeckrath
War da auch schon der 4er-Kernel installiert?

Ich habe vorigen Sonntag vom aktuellen 3er Kernel auf 4.1.2 hochgezogen,
was ohne Probleme lief.

Post by Marcus Roeckrath
Wie sieht da /etc/lilo.conf aus?

scanner # cat /etc/lilo.conf
lba32
#boot = /dev/hda
boot = /dev/disk/by-id/ata-TS8GCF133_625736CB2361DF000029_

Der Unterstrich kann hier nicht richtig sein.
Läuft lilo -t durch, wenn du den Unterstrich entfernst?

Ja, läuft durch.

Post by Marcus Roeckrath

Mit dem Kernel 4.1.2 bootete das System ganz normal und beim Upgrade vom
3er Kernel gab es auch keine Probleme. Nur eben jetzt mit dem Update zu
4.1.3.

Übrigens wurde das Kernelupdate doch überhaupt nicht durchgeführt, du
müsstest noch auf dem Stand davor sein.

Ja, läuft jetzt noch mit Kernel 4.1.2

Post by Marcus Roeckrath
Möglicherweise, ist das auch eine /etc/lilo.conf, die nun beim Kernelupdate
noch nicht angefasst wurde, weil Thomas diesen Check sehr früh macht.
Datumstempel der /etc/lilo.conf?

Der ist von vorhin, weil ich den falschen Unterstrich manuell entfernt
habe. Aber es liegt dort die lilo.conf.OLD, welche vom 2.12. ist,
Zeitpunkt des Upgrades zum Kernel 4.1.2. Dort ist dieser Unterstrich
auch schon drin.

scanner # cat /etc/lilo.conf.OLD
lba32
#boot = /dev/hda
boot = /dev/disk/by-id/ata-TS8GCF133_625736CB2361DF000029_
read-only
prompt
timeout = 50
vga = normal
menu-scheme = wr:bw:wr:Yr
image = /boot/kernel
#root = /dev/hda2
root = "UUID=566bfcff-92f6-40db-b74a-bdc9b358fa90"
label = eis
initrd = /boot/initrd.gz
append = "ide-core.nodma=0.0 hda=nodma ide=nodma ide0=nodma libata.dma=0
longhaul.enable=1 raid=noautodetect"
image = /boot/old-kernel
#root = /dev/hda2
root = "UUID=566bfcff-92f6-40db-b74a-bdc9b358fa90"
label = oldeis
initrd = /boot/old-initrd.gz
append = "ide-core.nodma=0.0 hda=nodma ide=nodma ide0=nodma libata.dma=0
longhaul.enable=1 raid=noautodetect"
image = /boot/kernel-3.16.70-SMP
#root = /dev/hda2
root = "UUID=566bfcff-92f6-40db-b74a-bdc9b358fa90"
label = 3.16.70-SMP
initrd = /boot/initrd-3.16.70-SMP.gz
append = "ide-core.nodma=0.0 hda=nodma ide=nodma ide0=nodma libata.dma=0
longhaul.enable=1 raid=noautodetect"

Post by Marcus Roeckrath
Eventuell eine unbewußt reingerutschte Änderung an der /etc/lilo.conf, weil
die ja durchaus Änderungen deinerseits hat.

Was für eine Änderung soll das sein? Ich habe wissentlich daran nichts
gemacht bzw. kann mich nicht daran erinnern.


Dirk

[Marcus Roeckrath]

Hallo Dirk,

Post by Dirk Alberti

Post by Marcus Roeckrath
Datumstempel der /etc/lilo.conf?

Der ist von vorhin, weil ich den falschen Unterstrich manuell entfernt
habe. Aber es liegt dort die lilo.conf.OLD, welche vom 2.12. ist,

Uhrzeit? Zeitgleich mit dem Kernelupdate (schaue in /var/log/log.eis-install
nach) oder später?

Post by Dirk Alberti
Zeitpunkt des Upgrades zum Kernel 4.1.2. Dort ist dieser Unterstrich
auch schon drin.

Kannst du nochmal den 3er booten und dann schauen, was

ls -l /dev/disk/by-id

ausgibt.

Post by Dirk Alberti
append = "ide-core.nodma=0.0 hda=nodma ide=nodma ide0=nodma libata.dma=0
longhaul.enable=1 raid=noautodetect"

Post by Marcus Roeckrath
Eventuell eine unbewußt reingerutschte Änderung an der /etc/lilo.conf,
weil die ja durchaus Änderungen deinerseits hat.

Was für eine Änderung soll das sein? Ich habe wissentlich daran nichts
gemacht bzw. kann mich nicht daran erinnern.

Diese ungewöhnlichen append-Zeilen musstest du also nicht manuell
nachpflegen?

[Dirk Alberti]

Hallo Marcus,

Post by Marcus Roeckrath
Hallo Dirk,

Post by Dirk Alberti
Zeitpunkt des Upgrades zum Kernel 4.1.2. Dort ist dieser Unterstrich
auch schon drin.

Kannst du nochmal den 3er booten und dann schauen, was
ls -l /dev/disk/by-id
ausgibt.

ääääh, ja, wenn ich das irgendwie per ssh hinbekommen würde. Oder müsste
ich dazu die ganze Konfiguration inkl. lilo.conf und Kernel wieder ändern?
Das Lilo-Bootmenü fällt ja aus, mangels Moni u. Tastatur.

Post by Marcus Roeckrath

Post by Dirk Alberti
append = "ide-core.nodma=0.0 hda=nodma ide=nodma ide0=nodma libata.dma=0
longhaul.enable=1 raid=noautodetect"

Post by Marcus Roeckrath
Eventuell eine unbewußt reingerutschte Änderung an der /etc/lilo.conf,
weil die ja durchaus Änderungen deinerseits hat.

Was für eine Änderung soll das sein? Ich habe wissentlich daran nichts
gemacht bzw. kann mich nicht daran erinnern.

Diese ungewöhnlichen append-Zeilen musstest du also nicht manuell
nachpflegen?

Achja, mit einigem grübeln in der hintersten Ecke meines Gedächtnisses
glaube ich, dass das was mit den Eigenheiten dieses Epia-Boards bzw. dem
Prozessor (VIA C3 Samuel) zu tun hatte.

Gruß Dirk

[Marcus Roeckrath]

Hallo Dirk,

Post by Dirk Alberti

Post by Marcus Roeckrath
Kannst du nochmal den 3er booten und dann schauen, was
ls -l /dev/disk/by-id
ausgibt.

ääääh, ja, wenn ich das irgendwie per ssh hinbekommen würde. Oder müsste
ich dazu die ganze Konfiguration inkl. lilo.conf und Kernel wieder ändern?
Das Lilo-Bootmenü fällt ja aus, mangels Moni u. Tastatur.

Da müsste man an der lilo.conf drehen und natürlich dann auch lilo aufrufen.

Post by Dirk Alberti

Post by Marcus Roeckrath

Post by Dirk Alberti
append = "ide-core.nodma=0.0 hda=nodma ide=nodma ide0=nodma libata.dma=0
longhaul.enable=1 raid=noautodetect"
Was für eine Änderung soll das sein? Ich habe wissentlich daran nichts
gemacht bzw. kann mich nicht daran erinnern.

Diese ungewöhnlichen append-Zeilen musstest du also nicht manuell
nachpflegen?

Achja, mit einigem grübeln in der hintersten Ecke meines Gedächtnisses
glaube ich, dass das was mit den Eigenheiten dieses Epia-Boards bzw. dem
Prozessor (VIA C3 Samuel) zu tun hatte.

Hast du also diese Zeile wieder selbst ergänzt?

Hast du danach auch wieder lilo aufgrufen, denn sonst werden die sowieso
nicht wirksam?

Wir können es auch einfach auf sich beruhen lassen, woher der _ kam.

[Dirk Alberti]

Hallo Marcus,

Post by Marcus Roeckrath
Hallo Dirk,
Wir können es auch einfach auf sich beruhen lassen, woher der _ kam.

ja genau, ich bin ja der Einzige, bei dem das aufgetreten ist. ;-)   Und
jetzt geht ja alles.


Vielen Dank, für die Eure Hilfe und Anstöße


Dirk

[Marcus Roeckrath]

Hallo Dirk,

Post by Dirk Alberti

Post by Marcus Roeckrath
Wir können es auch einfach auf sich beruhen lassen, woher der _ kam.

ja genau, ich bin ja der Einzige, bei dem das aufgetreten ist. ;-)

Wenn du damit zufrieden ins Bett gehen kannst :-)), gehen wir dem nicht mehr
weiter nach.

Post by Dirk Alberti
Und jetzt geht ja alles.

Fein.

Post by Dirk Alberti
Vielen Dank, für die Eure Hilfe und Anstöße

Gerne, "hier werden se geholfen."

[Thomas Bork]

Post by Dirk Alberti

Post by Marcus Roeckrath
Ist das ein RAID-System?

nein, das ist kein RAID-System. Das ist nur eine CF-Karte in einem
IDE2CF-Adapter.

Die Bezeichnung raid_setup wirft lilo ein. Das bedeutet nicht
zwangsläufig, dass es sich um ein RAID-System handelt, das ist nur der
Name der Funktion in lilo.

Post by Dirk Alberti
append = "ide-core.nodma=0.0 hda=nodma ide=nodma ide0=nodma libata.dma=0
longhaul.enable=1 raid=noautodetect"

Keine Ahnung, ob Du irgendwas von den obskuren ide-Optionen für den 4er
Kernel noch benötigst. Der kommt ja ohne hdX-Treiber.

[Thomas Bork]

die USB-Stick-Installation hat mehrere Reboots ohne busybox überlebt.

Danke für die Rückmeldung.

[Thomas Quast]

Hallo Tom,

Post by Thomas Bork
es ist eine Version 4.1.3 von eiskernel mit dem Status 'testing' für
eisfair-1 verfügbar.

Installation hier ohne Probleme.

Post by Thomas Bork
Beim Update von einem älteren Kernel als 4.9.196-eisfair-1 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.

Stellt kein Problem dar. Habe bei mir die Partition auf 140 MByte
vergroessert. Das sollte einige Zeit reichen. :)

Gruss,
Thomas

[Stefan Heidrich]

Hallo Tom,

ich habe zuerst /boot auf 120 MB vergrößert.

Post by Thomas Bork
es ist eine Version 4.1.3 von eiskernel mit dem Status 'testing' für
eisfair-1 verfügbar.

Danach gab es bei Update keinerlei Probleme.

Viele Grüße und Danke
Stefan

[Marcus Roeckrath]

Hallo Stefan,

Post by Stefan Heidrich
ich habe zuerst /boot auf 120 MB vergrößert.

Jetzt entwickelt sich hier so langsam ein Wettbewer, "wer hat das Grßte
boot". ;-)

Post by Stefan Heidrich

Post by Thomas Bork
es ist eine Version 4.1.3 von eiskernel mit dem Status 'testing' für
eisfair-1 verfügbar.

Danach gab es bei Update keinerlei Probleme.

Fein, danke für die Rückmeldung.