[Eisfair] [e1] eiskernel 2.14.0 (Status 'stable') verfügbar - 3.2er Kernel für eisfair-1

[Thomas Bork]

Am 02.11.2015 um 11:32 schrieb Jürgen Witt:

> Nur auf einer ziemlich alten, gewachsenen Installation ist die sehr
> kleine Partition boot nun sehr voll.
> eis 2.6.4 # df -h
> Filesystem                     Size  Used Avail Use% Mounted on
[...]
> /dev/md1                        16M   15M  201K  99% /boot

Ja, das alte Problem mit der zu kleinen Boot-Partition der alten 
Installer...

> Daher bekomme ich jetzt von einem Überwachungsscript permanent
> Warnmeldungen. Die Einträge oldeis und kernel-3.2.67-SMP scheinen (bis
> auf das Datum) ja identisch zu sein.

Sind sie auch. Die Routine arbeitet bei kontinuierlichen Updates der 
stable-Kernel so, dass der letzte eis immer zu oldeis wird und 
zusätzlich ein Fallback-Eintrag für den letzten stabilen Kernel angelegt 
wird. Das erlaubt es dann, bei genügend Platz z.B. noch einen neuen 
Testing-Kernel zu installieren, womit man dann die Möglichkeit hat,

1.
den neuen Testing-Kernel über eis zu starten

2.
den aktuellen stabilen Kernel über oldeis zu starten

3.
den vorigen stabilen Kernel über z.B. 3.2.67-SMP zu starten

Das ist ganz nützlich, um etwaige Fehler einzugrenzen, die in den 
verschiedenen Kernel-Versionen stecken.

> Welchen der Einträge aus lilo.conf und die entsprechende Dateien in boot
> kann ich gefahrlos löschen, damit ich mehr Platz bekomme und die
> Meckereien meines Scriptes aufhören?

Du kannst wahlweise entweder

1.
kernel-3.2.67-SMP und initrd-3.2.67-SMP.gz aus /boot und den Abschnitt 
3.2.67-SMP aus lilo.conf löschen und lilo aufrufen

oder

2.
old-kernel und old-initrd.gz aus /boot und den Abschnitt oldeis aus 
lilo.conf löschen und lilo aufrufen

Ein Abschnitt beginnt immer mit

image = ...

und endet mit

append = ...

Ich habe den Fallback damals nur auf Wunsch eingeführt und ihn seitdem 
auch schon dutzende Male verflucht, weil er die Installations-Prozedur 
und die Säuberung alter Kernel verkompliziert und natürlich notorisch 
kappen Platz belegt.
Aber der Fallback bietet den Vorteil, dass er bis zur Installation eines 
neuen stabilen Kernels erhalten bleibt, während eis und oldeis nicht 
statisch sind.

-- 
der tom
[eisfair-team]