Wechsel des Bootloaders

[Holger Bruenjes]

Hallo

Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht
nun EXTlinux als Bootloader fuer eisfair bereit.


'EXTLINUX' ist eine Syslinux Variante um Linux Dateisysteme zu
booten. Unterstüzt werden FAT12/16/32, NTFS, ext2/3/4, Btrfs, XFS,
UFS/FFS Dateisysteme.


Die Konfigurationsdatei, extlinux.conf, liegt im Verzeichnis
'/boot/extlinux'


weitere Informationen unter

https://wiki.syslinux.org/wiki/index.php?title=EXTLINUX


Die kurze Doku bei eisfair

https://www.eisfair.org/fileadmin/eisfair/doc/node10.html

Holger

[Stefan Puschek]

Hallo Holger,
...

> Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht nun
> EXTlinux als Bootloader fuer eisfair bereit.

war ich nun mutig oder ängstlich? Ich habs einfach auf meinem
Rettungs-USB-Stick-e1 probiert - lief ohne Probleme durch.

Danke für Eure Arbeit!

Groetjes
Stefan

[Marcus Röckrath]

Hallo Stefan,

Stefan Puschek wrote:

>> Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht nun
>> EXTlinux als Bootloader fuer eisfair bereit.
>
> war ich nun mutig oder ängstlich?

Mulmig kann einem vielleicht sein, aber ich habe das auf meinen 3
Privatmaschinen schon eine Weile so laufen.

An den Schulserver traue ich mich aber nicht ran, da ich das aus der Ferne
machen muss und im Notfall dann 30 km fahren muss. Das mache ich, wenn das
Abi vorbei ist vor Ort.

--
Gruß Marcus
[eisfair-Team]

[Stefan Heidrich]

Hallo Holger, hallo NG,

> Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht nun
> EXTlinux als Bootloader fuer eisfair bereit.

der automatische Umstieg funktionierte tadellos.

Viele Grüße und Danke
Stefan

[Ansgar Püster]

Hallo Holger,

Am 08.05.2021 um 11:55 schrieb Holger Bruenjes:
> Hallo
>
> Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht nun
> EXTlinux als Bootloader fuer eisfair bereit.

[...]

eis32dev # eisman update
[ 9%] => Fetching extlinux (3.0.0) ... [ OK ]
[ 57%] => Fetching lilo (3.0.7) ... [ OK ]

Ich erhalte folgende Fehlermeldung:

eis32dev # eisman upgrade
error: processing package "lilo":
error: package is outdated!
error: replaced by or included in extlinux
error: installation aborted!


eis32dev # eisman query --installed lilo
name lilo
version 3.0.6
short lilo - Linux Loader, and Boot Menu
date 2021-04-06
url https://www.pack-eis.de/dl.php?l=43798/lilo.tar.bz2
status stable
---------------------------------------------------------

... und nun?

Ah, "sehr böser" Trick hilft!

eis32dev # eisman uninstall --force lilo

The following packages will be uninstalled:

version status name source
---------------------------------------------------------------------
3.0.6 stable lilo https://www.pack-eis.de

1 package(s) will free approx. 1 MB of disk space.

Continue (y/n) [yes]?
Uninstallation of: lilo (3.0.6) ...
Successfully uninstalled: lilo (3.0.6)!

eis32dev # eisman install extlinux

The following packages will be installed:

version status name source
---------------------------------------------------------------------
3.0.0 stable extlinux https://www.pack-eis.de

1 package(s) using approx. 1 MB of disk space.

Continue (y/n) [yes]?
Downloading required packages ...
=> [####################] extlinux (3.0.0)... [
OK ]
Done!
Installation of: extlinux (3.0.0) ...
Attribute Legacy Bios Bootable Set - /dev/sda1
Installed MBR (/tmp/extlinux/gptmbr.bin) to /dev/sda
install EXTlinux
Successfully installed: extlinux (3.0.0)!

In der Summe nicht so der "Brüller"!

Gruß,
Ansgar

[Alex Busam]

Hi Ansgar,

d.h. Du hattest das letzte Lilo Update noch nicht drauf? Ich schätze mal
sonst wäre der Bootloader problemlos ersetzt worden.

Bevor ich extlinux installiere und um mein mulmiges Gefühl zu reduzieren:
install extlinux, dann Reboot? Oder deinstall von lilo zuvor sinnvoller?

Viele Grüße
Alex

[Heinz-Peter Faasen]

Hallo Holger,

> Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht nun
> EXTlinux als Bootloader fuer eisfair bereit.

habe drei Systeme erst unter Ausschluss von LILO aktuallisiert, dann den
neuen 5er-Kernel installiert und, sozusagen als krönenden Abschluss,
extlinux drauf gepackt.
Die Prozedur war völlig schmerzfrei, der Reboot lief sauber durch und
auch im Betrieb sind mir bislang keinerlei Fehler aufgefallen.

Vielen Dank für diesen Superjob!
Heinz-Peter

[Marcus Röckrath]

Hallo Alex,

Alex Busam wrote:

> d.h. Du hattest das letzte Lilo Update noch nicht drauf? Ich schätze mal
> sonst wäre der Bootloader problemlos ersetzt worden.
>
> Bevor ich extlinux installiere und um mein mulmiges Gefühl zu reduzieren:
> install extlinux, dann Reboot?

Ja, so einfach.

> Oder deinstall von lilo zuvor sinnvoller?

Nein, denn extlinux ersetzt lilo automatisch; extlinux ist das
Replacement-Paket für lilo.

Übrigens für die InteressierteN. extlinux hat so manche Einschränkung von
lilo nicht, liest direkt Bootdateien und nicht wie bei lilo dumpf vorher in
einer Datei per Nummer aufgeführte Sektoren; dürfte auf den problematischen
Atomkisten funktionieren, ...

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Heinz-Peter,

Heinz-Peter Faasen wrote:

>> Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht nun
>> EXTlinux als Bootloader fuer eisfair bereit.
>
> habe drei Systeme erst unter Ausschluss von LILO aktuallisiert, dann den
> neuen 5er-Kernel installiert und, sozusagen als krönenden Abschluss,
> extlinux drauf gepackt.
> Die Prozedur war völlig schmerzfrei, der Reboot lief sauber durch und
> auch im Betrieb sind mir bislang keinerlei Fehler aufgefallen.

Danke für die Rückmeldung, ich hatte auch keine Probleme auf meinen Kisten.

> Vielen Dank für diesen Superjob!

Der gebührt hier Holger für extlinux und Daniel für den Kernel.

--
Gruß Marcus
[eisfair-Team]

[Heinz-Peter Faasen]

Hi Marcus,

>> Vielen Dank für diesen Superjob!
>
> Der gebührt hier Holger für extlinux und Daniel für den Kernel.

schon klar - hab ja auch an beide geschrieben. ;)

Gruß
Heinz-Peter

[Marcus Röckrath]

Hallo Heinz-Peter,

Heinz-Peter Faasen wrote:

>>> Vielen Dank für diesen Superjob!
>>
>> Der gebührt hier Holger für extlinux und Daniel für den Kernel.
>
> schon klar - hab ja auch an beide geschrieben. ;)

Ich wollte es auch nur nochmal betont haben. :-)

--
Gruß Marcus
[eisfair-Team]

[Ansgar Püster]

Hallo,

Die Problemsituation, die ich hatte, kann nicht mehr
auftreten, da es jetzt kein Paket lilo mehr auf pack-eis gibt.

Bei der Installation von extlinux wird automatisch
ein ggf. vorhandenes Paket lilo auf deinem Server
gelöscht.

Also nur
eisman upgrade
oder
eisman install extlinux

Wird funktionieren!

Gruß,
Ansgar

[Marcus Röckrath]

Hallo Marcus,

Marcus Röckrath wrote:

> Übrigens für die InteressierteN. extlinux hat so manche Einschränkung von
> lilo nicht, liest direkt Bootdateien und nicht wie bei lilo dumpf vorher
> in einer Datei per Nummer aufgeführte Sektoren; dürfte auf den
> problematischen Atomkisten funktionieren, ...

Gerade eine wunderbare Eigenschaft von extlinux gefunden, die besonders auf
headless oder entfent stehenden Kisten von Interesse sein kann.

Da fehlt einem ja der Zugriff auf das Bootmenu, um mal eben einmalig einen
anderen Kernel zu booten, ohne an der Konfiguraion etwas ändern und nachher
wieder rückändern zu müssen:

extlinux --once 'command' /boot/extlinux

Nimmt man als command eines der Bootlabels, wird beim nächsten Boot dieses
gebootet und dann automatisch wieder auf den "Standard" zurückgesetzt.

Hier findet man auf englisch eine sehr gut lesbare Übersicht zu extlinux:

https://wiki.syslinux.org/wiki/index.php?title=EXTLINUX

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo,

Marcus Röckrath wrote:

> Übrigens für die InteressierteN. extlinux hat so manche Einschränkung von
> lilo nicht, liest direkt Bootdateien und nicht wie bei lilo dumpf vorher
> in einer Datei per Nummer aufgeführte Sektoren; dürfte auf den
> problematischen Atomkisten funktionieren, ...

Kopiert ein vollständiges dateibasiertes Backup wieder auf eine Platte oder
macht eine Kopie eines Dateisystems (nicht sektorbasiert wie dd) werden die
Dateien nicht wieder auf den gleichen Sektoren wie vorher liegen.

Ist ja grundsätzlich egal nur für die Bootdateien bei Verwendung von lilo
fatal.

Hier hätte man zunächst vor dem ersten Boot der Kopie ein Rettungssystem
bemühen müssen, um lilo aufzurufen, damit eine neue gültige map-Datei
geschrieben wird.

extlinux braucht das nicht, da es über das Dateisystem auf die
Kernelbootdateien zugreift.



--
Gruß Marcus
[eisfair-Team]

[W. Loefstedt]

Am 08.05.2021 um 11:55 schrieb Holger Bruenjes:

> Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht nun
> EXTlinux als Bootloader fuer eisfair bereit.

Hallo allerseits,

hier läuft ein RAID-1 auf einem eis1. Was muss ich vor der Umstellung
beachten? In [1] wird für ein RAID-1 vorgeschlagen:

To clear the boot-once information:

extlinux --clear-once /boot/extlinux

If EXTLINUX is used on a RAID-1, this is recommended, since under
certain circumstances a RAID-1 rebuild can "resurrect" the boot-once
information otherwise.

Ich verstehe die Vorgehensweise(noch?) nicht. Vielleicht hat jemand die
Umstellung schon gemacht und kann mir einen Tipp geben.

Danke und Gruss,
Wolfgang

[1] https://wiki.syslinux.org/wiki/index.php?title=EXTLINUX

[W. Loefstedt]

Am 08.05.2021 um 11:55 schrieb Holger Bruenjes:

> Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht nun
> EXTlinux als Bootloader fuer eisfair bereit.

Hallo allerseits,

hier läuft ein RAID-1 auf einem eis1. Was muss ich vor der Umstellung
beachten?

Unter [

[Thomas Bork]

Am 10.05.2021 um 22:47 schrieb W. Loefstedt:

> hier läuft ein RAID-1 auf einem eis1. Was muss ich vor der Umstellung
> beachten? In [1] wird für ein RAID-1 vorgeschlagen:
> To clear the boot-once information:
> extlinux --clear-once /boot/extlinux

Das ist nur notwendig, wenn vorher schon einmal

extlinux --once 'command' /boot/extlinux

aufgerufen wurde.

--
der tom

[Marcus Röckrath]

Hallo Wolfgang,

W. Loefstedt wrote:

> hier läuft ein RAID-1 auf einem eis1. Was muss ich vor der Umstellung
> beachten? In [1] wird für ein RAID-1 vorgeschlagen:
>
> To clear the boot-once information:
>
> extlinux --clear-once /boot/extlinux
>
> If EXTLINUX is used on a RAID-1, this is recommended, since under
> certain circumstances a RAID-1 rebuild can "resurrect" the boot-once
> information otherwise.

Nein, wieso?

Das soll man tun, wenn man auf einem Raid-System mal "extlinux --once ..."
ausgeführt hat, um einmalig einen anderen Kernel zu booten.

Das hat keine Bedeutung für die hie durchgeführte Installation.

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo,

Marcus Röckrath wrote:

> Gerade eine wunderbare Eigenschaft von extlinux gefunden, die besonders
> auf headless oder entfent stehenden Kisten von Interesse sein kann.
>
> Da fehlt einem ja der Zugriff auf das Bootmenu, um mal eben einmalig einen
> anderen Kernel zu booten, ohne an der Konfiguraion etwas ändern und
> nachher wieder rückändern zu müssen:
>
> extlinux --once 'command' /boot/extlinux
>
> Nimmt man als command eines der Bootlabels, wird beim nächsten Boot dieses
> gebootet und dann automatisch wieder auf den "Standard" zurückgesetzt.

Ich habs mal probiert: Hat perfekt funktioniert.

--
Gruß Marcus
[eisfair-Team]

[W. Loefstedt]

Am 10.05.2021 um 23:40 schrieb Thomas Bork:

> Das ist nur notwendig, wenn vorher schon einmal
>
> extlinux --once 'command' /boot/extlinux
>
> aufgerufen wurde.

@Thomas, @Marcus,
danke für den Hinweis. Die Umstellung auf extlinux hat problemlos geklappt.
Gruss, Wolfgang

[Detlef Paschke]

Am 08.05.2021 um 11:55 schrieb Holger Bruenjes:

> Hallo

Hallo Holger,

> Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht
> nun EXTlinux als Bootloader fuer eisfair bereit.
>

> ...

>
> Die Konfigurationsdatei, extlinux.conf, liegt im Verzeichnis
> '/boot/extlinux'

funktioniert hier auf mehreren VM und von der Konfiguration fast
selbsterklärend. Wenn man da an GRUB denkt...

Aber bei wem muss ich jetzt wieder betteln?

Ich habe ja irgend wo schon geschrieben, dass ich diesen Eintrag "eis"
vollends Sinnfrei finde, insbesondere deswegen, weil der danach folgende
Eintrag im Bootmenü welcher die Kernelversion zeigt, exakt das selbe
System startet wie "eis".

Den Punkt "eis" aus lilo zu entfernen und glücklich zu leben ging ja
nicht, da bei einem Kernel update angemahnt wurde, dass es wohl, mangels
des Eintrag "eis", keinen default Kernel auf dem System gibt und das
Kernel update daraufhin abgebrochen wurde.

Nun habe ich eigenwillig wie ich bin, in der EXTlinux Konfiguration die
Zeile

MENU HIDE

hinter der Zeile

MENU LABEL eis

eingefügt, um den Menüpunkt "eis" auszublenden und direkt den aktuellen
Kernel als default angezeigt zu bekommen.
Das geht wunderbar und ein Kernel update lief auch ohne zu meckern durch.

Nur ist nach dem Kernel update die Zeile MENU HIDE wieder aus
/boot/extlinux/extlinux.conf verschwunden und somit erscheint im
Bootmenü natürlich wieder "eis" und als nächste "alternative" der
identische Kernel, nur mit Vor- und Nachnamen.

> Holger

Viele Grüße
Detlef Paschke

--
Das "Zitat des Augenblicks" gibt es nur auf
http://schabau.eu
Meine "Merkzettel"
http://helpdesk.schabau.eu

[Holger Bruenjes]

Hallo Detlef

Am 11/05/2021 um 16.00 schrieb Detlef Paschke:
> Am 08.05.2021 um 11:55 schrieb Holger Bruenjes:

> funktioniert hier auf mehreren VM und von der Konfiguration fast
> selbsterklärend. Wenn man da an GRUB denkt...
>
> Aber bei wem muss ich jetzt wieder betteln?

Nirgends ;-)

es gibt auch einige Systeme, XEN VM z.B., die sind auf die Eintraege

../kernel
../initrd.gz

angewiesen.

Das|ein Kernelupdate stoert sich nicht an deinen Anpassungen, nur
musst du sie dann hinterher wieder eintragen. Da geht kein Weg
dranvorbei.

Eine bessere Antwort habe ich nicht.

Holger

[hilix]

Hallo Holger,
Am 11.05.21 um 16:00 schrieb Detlef Paschke:

...
> Aber bei wem muss ich jetzt wieder betteln?
>
> Ich habe ja irgend wo schon geschrieben, dass ich diesen Eintrag "eis"
> vollends Sinnfrei finde, insbesondere deswegen, weil der danach folgende
> Eintrag im Bootmenü welcher die Kernelversion zeigt, exakt das selbe
> System startet wie "eis".
>
> Den Punkt "eis" aus lilo zu entfernen und glücklich zu leben ging ja
> nicht, da bei einem Kernel update angemahnt wurde, dass es wohl, mangels
> des Eintrag "eis", keinen default Kernel auf dem System gibt und das
> Kernel update daraufhin abgebrochen wurde.

Da stimme ich Dir deswegen voll und ganz zu!!
Ich kann lesen und weiß auch dass eine 5.10.31 aktueller ist als eine 4.9.261 und die sehr wahrscheinlich auch aktiv ist.
Ansonsten: uname -r. Es verwirrt/verunsichert eher, als dass es nützt. Meine Bitte daher auch, den "eis" Eintrag aus dem
Boot-Menü entfernen.
Davon ab, begrüße ich die Umstellung auf Extlinux! :-)

Grüße. / Hilmar.

[Nelson Matias]

On 08.05.2021 11:55, Holger Bruenjes wrote:
> Nach einer langen Zeit mit LILO als Bootloader fuer eisfair, steht nun
> EXTlinux als Bootloader fuer eisfair bereit.

So und ich möchte meinem Eis eine neue Boot-SSD gönnen. Kann ich jetzt
einfach mit Gparted die Partitionen kopieren, dabei /boot ein wenig
vergrößern weil noch aus einer Installation aus grauer Vorzeit stammt.

Muss ich um davon booten zu können irgend etwas beachten?

Vielleicht kann auch jemand kurz den Befehl hier nennen um eine Platte
bootfähig zu machen, sollte aus irgendeinem Grund der MBR mal
durcheinander sein.

Danke schon mal.

Nelson

[Marcus Röckrath]

Hallo Nelson,

Ich nehme an, du wirst die alte Platte mittels gparted bootfähig auf das
neue Medium kopieren können.

Dann sollte auch der für extlinux notwendige mbr mitkopiert werden, ebenso
die Partitonen mit den urspünglichen UUIDs und auch die Bootpartition als
aktiv gekennzeichnet werden.

Um den mbr neu schreiben zu können, musst du das Paket syslinux
installieren, denn das extlinux-Paket löscht die Dateien nach der
Installation (Binary extlinux und die verschiedenen MBRs).

Im syslinux-Paket gibt es:

/usr/libexec/syslinux/gptmbr.bin
/usr/libexec/syslinux/mbr.bin

Je nachdem, ob die Platte Dos oder GPT partitioniert ist, muss der passende
mbr gewählt werden. schreiben kannst du ihn mit:

/usr/bin/dd bs=440 count=1 conv=notrunc if=<mbrfile> of=<plattendevice>

Das sollte es gewesen sein - und die alte Platte beiseitelegen, damit man
einen zweiten, dritten, ... Versuch hat.

--
Gruß Marcus
[eisfair-Team]

[Detlef Paschke]

Am 11.05.2021 um 16:12 schrieb Holger Bruenjes:
> Hallo Detlef

Hallo Holger,

> Das|ein Kernelupdate stoert sich nicht an deinen Anpassungen, nur

natürlich stört sich das Kernel update, oder hat sich gestört, wenn ich
in lilo den Eintrag "eis" entfernt habe und weil damit unnötig, die
Links in /boot entfernt habe.

Aber evtl. hat sich das Kernel update auch nur daran gestört, dass die
Links entfernt waren.

Dieses LariFari ist es auch. Erst heißt es, wir machen mit dem Kernel
einen großen Sprung und jetzt alles ein bisschen Debian like (kümmere
dich aber gefälligst selbst um das deinstallieren der alten Kernel und
aller Anhängsel) und dann kommen doch wieder solche Krücken.

Ich habe in den Eisfair Gruppen, weil ich eine eigene Meinung habe
ohnehin verspielt, von daher: "Wenn ein Sprung kommen soll, macht doch
einen Richtigen und nicht diese homöopathische herantasterei an jede
kleine Veränderung!"

Ich weiß noch was ich hier für Feuer bekommen habe als ich mich
erdreistete zu Fragten, ob das Update-System nicht so Funktionieren
könnte, dass man alle verfügbaren Updates mit ein mal nach dem Motto "ja
ich will alle" ausführen kann...

[Detlef Paschke]

Am 11.05.2021 um 18:26 schrieb Marcus Röckrath:

Hallo Marcus,

> Um den mbr neu schreiben zu können, musst du das Paket syslinux
> installieren, denn das extlinux-Paket löscht die Dateien nach der
> Installation (Binary extlinux und die verschiedenen MBRs).
>
> Im syslinux-Paket gibt es:
>
> /usr/libexec/syslinux/gptmbr.bin
> /usr/libexec/syslinux/mbr.bin
>
> Je nachdem, ob die Platte Dos oder GPT partitioniert ist, muss der passende
> mbr gewählt werden. schreiben kannst du ihn mit:
>
> /usr/bin/dd bs=440 count=1 conv=notrunc if=<mbrfile> of=<plattendevice>
>
> Das sollte es gewesen sein - und die alte Platte beiseitelegen, damit man
> einen zweiten, dritten, ... Versuch hat.

für die üblichen bekannten MBR-Notfall-Hilfen per Life-CD, schlicht und
einfach lilo oder grub in chroot ausführen, gibt es bei extlinux somit
keine Möglichkeit?

Mit freundlichen Grüßen

[Marcus Röckrath]

Hallo Detlef,

Detlef Paschke wrote:

> Ich weiß noch was ich hier für Feuer bekommen habe als ich mich
> erdreistete zu Fragten, ob das Update-System nicht so Funktionieren
> könnte, dass man alle verfügbaren Updates mit ein mal nach dem Motto "ja
> ich will alle" ausführen kann...

Was ist mit dem Menüpunkt "Automatic system update"?

I ch benutze ihn nicht, aber das dürfte dir alle stable-Updates auf einen
Schlag ins System spielen.

Auf der Kommandozeile:

eisman upgrade

oder, um auch unstable/testing einzubeziehen:

eisman upgrade --unstable

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Detlef,

Detlef Paschke wrote:

>> Je nachdem, ob die Platte Dos oder GPT partitioniert ist, muss der
>> passende mbr gewählt werden. schreiben kannst du ihn mit:
>>
>> /usr/bin/dd bs=440 count=1 conv=notrunc if=<mbrfile> of=<plattendevice>
>>

> für die üblichen bekannten MBR-Notfall-Hilfen per Life-CD, schlicht und
> einfach lilo oder grub in chroot ausführen, gibt es bei extlinux somit
> keine Möglichkeit?

Ich habe nicht nachgeschaut, aber syslinux/extlinux könnte auf
Rettungssystemen durchaus vorhanden sein.

--
Gruß Marcus
[eisfair-Team]

[Detlef Paschke]

Am 11.05.2021 um 18:51 schrieb Marcus Röckrath:
> Hallo Detlef,

Hallo Marcus,

>
> Detlef Paschke wrote:
>
>> Ich weiß noch was ich hier für Feuer bekommen habe als ich mich
>> erdreistete zu Fragten, ob das Update-System nicht so Funktionieren
>> könnte, dass man alle verfügbaren Updates mit ein mal nach dem Motto "ja
>> ich will alle" ausführen kann...
>
> Was ist mit dem Menüpunkt "Automatic system update"?
>
> I ch benutze ihn nicht, aber das dürfte dir alle stable-Updates auf einen
> Schlag ins System spielen.

genau das macht er.
Als ich die Frage gestellt habe, gab es das aber noch gar nicht. Man hat
jedes Update einzeln ausgewählt und nach Möglichkeit beachtet, zunächst
Pakete zu wählen welche möglichst viele Abhängigkeiten haben, um dann
viele Pakete mitzuziehen.
Optionen wie -all oder den Eisman selbst, kamen erst später.

Irgend einer der Entwickler schrieb damals als Antwort nach dem Motto, "
wenn Du einen Server betreiben willst, musst Du auch regelmäßig Updates
machen. Dann sind das nicht so viele auf einmal..."

[Marcus Röckrath]

Hallo,

Marcus Röckrath wrote:

> Ich habe nicht nachgeschaut, aber syslinux/extlinux könnte auf
> Rettungssystemen durchaus vorhanden sein.

Die sysrescuecd-LiveCD enthält syslinux:

https://www.system-rescue.org/Detailed-packages-list/

--
Gruß Marcus
[eisfair-Team]

[Marcus Röckrath]

Hallo Detlef,

Detlef Paschke wrote:

>> Was ist mit dem Menüpunkt "Automatic system update"?
>>
>> I ch benutze ihn nicht, aber das dürfte dir alle stable-Updates auf einen
>> Schlag ins System spielen.
>
> genau das macht er.
> Als ich die Frage gestellt habe, gab es das aber noch gar nicht. Man hat
> jedes Update einzeln ausgewählt und nach Möglichkeit beachtet, zunächst
> Pakete zu wählen welche möglichst viele Abhängigkeiten haben, um dann
> viele Pakete mitzuziehen.

Wann war das, denn dieser Punkt hat inzwischen bestimmt auch schon jahre auf
dem Buckel, was genau garantiert Holger sagen kann.

> Optionen wie -all oder den Eisman selbst, kamen erst später.
>
> Irgend einer der Entwickler schrieb damals als Antwort nach dem Motto, "
> wenn Du einen Server betreiben willst, musst Du auch regelmäßig Updates
> machen. Dann sind das nicht so viele auf einmal..."

Das bezog sich bestimmt darauf, dass manche Systeme nur alle Jubeljahre mal
Updates bekamen.

Da zwischendrin auch mal ein glibC ausgetauscht wird, oder die
inkrementellen base-Updates sich mit anderen Updates verzahnen können (z.
B. Reboot erforderlich), kann es zu Problemen kommen; das hat mit einem
"Update all" als Funktion nichts zu tun.

--
Gruß Marcus
[eisfair-Team]

[Detlef Paschke]

Am 11.05.2021 um 19:14 schrieb Marcus Röckrath:
> Hallo,

Hallo Marcus,

>
> Marcus Röckrath wrote:
>
>> Ich habe nicht nachgeschaut, aber syslinux/extlinux könnte auf
>> Rettungssystemen durchaus vorhanden sein.
>
> Die sysrescuecd-LiveCD enthält syslinux:
>
> https://www.system-rescue.org/Detailed-packages-list/

im Fall der Fälle dann noch mit dd runzuspielen ist auch nicht schön
aber man hatte ja ohnehin keine andere Wahl.
Es kam so wie es beschlossen war und ohne ALternative.
Doch wie hieß es so schön:

"...aber es ist kein "Wunschkonzert"...", "...dass das eisfair-Team in
den letzten Jahren viel zu viel Wünschen nachgegeben hat..."

Ob das auf Dauer gut ist...?

Viele Grüße

[Detlef Paschke]

Am 11.05.2021 um 19:26 schrieb Marcus Röckrath:
> Hallo Detlef,

Hallo Marcus,

> Detlef Paschke wrote:
>
>>> Was ist mit dem Menüpunkt "Automatic system update"?
>>>
>>> I ch benutze ihn nicht, aber das dürfte dir alle stable-Updates auf einen
>>> Schlag ins System spielen.
>>
>> genau das macht er.
>> Als ich die Frage gestellt habe, gab es das aber noch gar nicht. Man hat
>> jedes Update einzeln ausgewählt und nach Möglichkeit beachtet, zunächst
>> Pakete zu wählen welche möglichst viele Abhängigkeiten haben, um dann
>> viele Pakete mitzuziehen.
>
> Wann war das, denn dieser Punkt hat inzwischen bestimmt auch schon jahre auf
> dem Buckel, was genau garantiert Holger sagen kann.
>

ja, das ist schon länger her. Die Option -all kam so meine ich, nicht
einmal viel später. Der Gedanke wird also schon da gewesen sein. Nur
meine Frage danach war natürlich dreist.

Ich möchte damit nur ausdrücken, dass Vorschläge hier gern als
persönlicher Angriff auf die Person interpretiert werden, was überhaupt
nicht die Absicht ist.

So macht dieser ganze Eisfair keinen Spaß mehr.
Eisfair entwickelt sich immer mehr in ein Projekt, was ein paar
Entwickler aus einer tollen Idee übernommen haben und unter sich und für
sich weiterführen.

[Marcus Röckrath]

Hallo Detlef,

Detlef Paschke wrote:

>>> Ich habe nicht nachgeschaut, aber syslinux/extlinux könnte auf
>>> Rettungssystemen durchaus vorhanden sein.
>>
>> Die sysrescuecd-LiveCD enthält syslinux:
>>
>> https://www.system-rescue.org/Detailed-packages-list/
>
> im Fall der Fälle dann noch mit dd runzuspielen ist auch nicht schön
> aber man hatte ja ohnehin keine andere Wahl.
> Es kam so wie es beschlossen war und ohne ALternative.
> Doch wie hieß es so schön:
>
> "...aber es ist kein "Wunschkonzert"...", "...dass das eisfair-Team in
> den letzten Jahren viel zu viel Wünschen nachgegeben hat..."

Das wir von lilo weg mussten, war schon lange klar, weil das zuviele
Probleme machte, die extlinux löst.

--
Gruß Marcus
[eisfair-Team]

[Detlef Paschke]

Am 11.05.2021 um 21:04 schrieb Marcus Röckrath:
> Hallo Detlef,

Hallo Marcus,

>

Ich war völlig vorurteilsfrei gegen EXTlinux auch wenn ich zuvor noch
nie von diesem Bootmanager gehört habe. Doch was ich nun hier lese,
insbesondere betreffs MBR wiederherstellen, und sicher viele hier
mussten das an der einen oder anderen Stelle schon machen, ist einfach
Anwender feindlich. Was sprach gegen GRUB wenn Lilo nicht megr möglich
war auch wenn GRUB nicht so einfach zu konfigurieren ist aber zumindest
mehr oder weniger einen "Standard" darstellt. Insbesondere bei
Hilfeanfragen zur hier grundlegenden Problemstellung MBR wieder
Herstellen, sei es nach einem X-Belibigen Fehler, sei es nach einer
Backup Rückspielung per rsync. So was hat man doch immer wieder mal.

Fragt doch zuvor mal die Leute oder sagt offiziell, Ihr entwickelt
Eisfair ausschließlich unter Euch für euch weiter.

[Marcus Röckrath]

Hallo Detlef,

Detlef Paschke wrote:

> Ich war völlig vorurteilsfrei gegen EXTlinux auch wenn ich zuvor noch
> nie von diesem Bootmanager gehört habe.

Das ist alles unter dem Dach von syslinux; extlinux richtet u. a. an
Datenträger mit ext-Dateisystem.

> sei es nach einer Backup Rückspielung per rsync.

Wieso sollte die Rückspielung von Daten mit rsync ein Neuschreiben des MBR
erfordern?

lilo erfordert hier einen Eingriff, wenn auch die daten in Boot betroffen
sind; für extlinux ist das völlig ohne Belang.

Mit lilo war in der Regel immer eine Reparatur mit Live-System erforderlich,
bei extlinux spielt das keine Rolle.

--
Gruß Marcus
[eisfair-Team]

[D. Oezbilen]

Hallo Detlef, Marcus,

> Ich war völlig vorurteilsfrei gegen EXTlinux auch wenn ich zuvor noch
> nie von diesem Bootmanager gehört habe. Doch was ich nun hier lese,
> insbesondere betreffs MBR wiederherstellen, und sicher viele hier
> mussten das an der einen oder anderen Stelle schon machen, ist einfach
> Anwender feindlich.

diesen Eindruck habe ich auch.

Wie ich im anderen Thread geschrieben habe, lilo war in den letzten
Dekaden *nie* mein Problem, uralte Maschinen und/oder neue, sehr akt.
auf Blech oder virt.
*** Lilo war nie der Showstopper. ***

Eine Part. bootet nicht!? Wie loese ich es schnell, elegant *und*
sicher, dass der Befehl nicht was kaputt macht.
Ich fremdele jetzt meinen eisx64 mit einer home-produktiven Umgebung zum
Testen der mbr-Restauration mit extlinux malt kurz ;-) zu testen. Wenn
es schief geht, ist alles weg(?)
Das Leben ist dafuer zu kurz.
(wahrscheinlich, dass ich das Lilo v. der zweiten Part. nutze und
extlinux fuer Updates auf der ersten lasse)

Lilo war nie hier ein Stopper. Wenn man ein grub2-ISO bootet, ist man
extrem schnell im Spiel, diese ISO bootet *alles*.

Insofern, bis auf die Atomboardproblematik und Speichergeschichte kann
ich den Wechsel auf Extlinux nicht nachvollziehen.

Was sprach gegen GRUB wenn Lilo nicht megr möglich
> war auch wenn GRUB nicht so einfach zu konfigurieren ist aber zumindest
> mehr oder weniger einen "Standard" darstellt.

Das ist auch meine Pos.
Wenn wir weitergehen, dann doch nicht auf den alten Gleisen, sondern was
auch Zukunft hat, weil es mehr kann im Sinne v. andere HW/UEFI Booten,
oder gar v. LVM. Und ebenso einfach handzuhaben.

@Atomboards
Habt ihr auf diesen problematischen Spielzeugboards grub getestet?
Ich habe zwei Atom NB, MSI, grub mit deb6 einfach ohne nix. Aber vllt.
meint ihr auch andere Konstellationen.

> Hilfeanfragen zur hier grundlegenden Problemstellung MBR wieder
> Herstellen, sei es nach einem X-Belibigen Fehler, sei es nach einer
> Backup Rückspielung per rsync. So was hat man doch immer wieder mal.

Manchmal.
Ich bin immer alert, wenn ich viel Neues kommt, dann ziehe ich ein
dd-Image in dem ich die zweite (1:1 Duplikat der produktiven Part) boote.

Nach dem dd-IMage lasse ich ein update laufen, oder installiere etwas,
was ich selbst kompiliert habe, um zu schauen, ob/wie es mit eis funkt.

Wenn alles OK, ist alles OK. Wenn jedoch nicht, boote ich per Lilo -D
zweitePart, die andere Part. Binde per loop das dd-Image, formatiere die
erst Part, sichere vorher die UUID, per cpio kopiere ich alles aus dem
Image rueck.

Das alles geht in wenigen Minuten (da ich immer, zu jederzeit eine HD,
keine ISO/USB boote), der Copy-Job bindet die groesste Zeit.
Am Ende lilo ausfuehren, cest ca.
dd image in paar Minuten, das rueckspielen auch in 10-15 min.
Selbiges gilt fuer grub(-Maschinen)

> Fragt doch zuvor mal die Leute oder sagt offiziell, Ihr entwickelt
> Eisfair ausschließlich unter Euch für euch weiter.

*Das* denke ich nicht. Das Eis-Team nimmt Wuensche an und realisiert
viel so nebenbei. Es ist das **erste** Mal, wo ich wahrlich etwas
Kopfschmerzen habe, was da eingefuehrt wurde.
Vllt waere es gut gewesen, diese Umstellung vorher hier in den Raum
zustellen?

Ich selbst wuerde auf lilo bleiben oder grub einfuehren, wo ich weiss,
was ich mache, aber jedesmal beim Kernelupdate das Gefrickel ist auch
nervtoetend.

Ich denke hier ist das Entwicklerteam zu kurz gesprungen. ;-)

Gruss
Derya

[Detlef Paschke]

Am 11.05.2021 um 22:48 schrieb Marcus Röckrath:
> Hallo Detlef,

Hallo Marcus,

> Detlef Paschke wrote:
>
>

>> sei es nach einer Backup Rückspielung per rsync.
>
> Wieso sollte die Rückspielung von Daten mit rsync ein Neuschreiben des MBR
> erfordern?

wort vergessen, war schon spät. Rückspielen auf andere Platte.

> lilo erfordert hier einen Eingriff, wenn auch die daten in Boot betroffen
> sind; für extlinux ist das völlig ohne Belang.
>
> Mit lilo war in der Regel immer eine Reparatur mit Live-System erforderlich,
> bei extlinux spielt das keine Rolle.

Ja aber diesen Krampf mit evtl. noch syslinux installieren und dd hatte
man nicht. Im Idealfall musste man in chroot noch genau ein Wort eingeben.

[Marcus Röckrath]

Hallo Derya,

D. Oezbilen wrote:

> auch Zukunft hat, weil es mehr kann im Sinne v. andere HW/UEFI Booten,

Grundsätzlich kann syslinux UEFI:

https://wiki.syslinux.org/wiki/index.php?title=Install#UEFI

--
Gruß Marcus
[eisfair-Team]

[Andreas Hager]

Sollte es noch jemanden so gehen:

Dadurch, daß Linux die Laufwerke einfach in ein Verzeichnis mountet,
kann es zu folgendem Problem kommen.

Ich hatte mal ein Problem, daß meine boot-Partition zu klein war.
Ich habe daraufhin in einer chroot-Umgebung die Partitionsgrößen der
Platte verändert, und danach die notwendigen Dateien darein kopiert.
Ich nahm an, daß es sich dabei um die boot-Partition handelte.

Rechner bootete, weitere Kernel-Updates liefen, kein sichtbares Problem.


Jetzt beim Wechsel auf extlinux, fiel mir dies aber auf die Füße.
Der Rechner fand kein Config-File in /boot/extlinux.

Also wieder Live-System her, Config-File suchen oder neu erstellen.

Da stellte ich fest, daß es vor dem Start von chroot, sehr wohl ein
config-File gab.
Nach dem Wechsel in die chroot-Umgebung allerdings nicht mehr. Da waren
komischerweise auch andere kernel- und initrd-Files. Alle vom Januar
2021.

Ein Löschen dieser Dateien reichte aus. Rechner bootet. Alles schick.

Scheinbar hatte der Installationsprozess von extlinux Zugriff auf die
Partition, während der anschließende Reboot mit den Dateien in /boot
arbeiten wollte, also noch vor dem Einhängen der Partition in das
/boot-Verzeichnis.

Sehe ich dies richtig ?

Gruß
Andreas

[Nelson Matias]

Hallo Marcus,

kennst du das auch? Du hast Urlaub aber irgendwie weniger Zeit für dein
Hobby als wenn du arbeiten würdest?

On 11.05.2021 18:26, Marcus Röckrath wrote:
> Hallo Nelson,
>
> Nelson Matias wrote:
>
>> Danke schon mal.
>
> Ich nehme an, du wirst die alte Platte mittels gparted bootfähig auf das
> neue Medium kopieren können.

Nahm ich auch an ... aber irgendwas hab ich falsch gemacht oder das ging
nicht so wie ich es mir vorgestellt hatte. Jedenfalls war die Platte
nach dem Kopieren nicht bootfähig.

Ich vermute es lag daran, das ich die Platte nicht 'geclont' hatte,
sondern die boot-Partition kopiert und auf 256MB vergrößert hab. Dann
die swap-Partition einfach erstellt hatte und den Rest der Platte mit
der root-Partition gefüllt hab. Nach einem 'mkswap /dev/sde2' ein
reboot. Keine bootfähige Platte da. Also nochmal gparted gestartet und
klar ... keine aktive Partition und die Label waren auch nicht gesetzt.
Macht nix. MBR kopiert und bei der Gelegenheit die UUIDs gleich
angepasst und dann bekam ich beim reboot auch das EXTLINUX-Menu.

ABER. Der boot-Vorgang bleibt einfach stehen. ich kann nicht genau sagen
was alles passiert weil das Teil echt schnell scrollt. Alles was noch
sichtbar ist: die letzte Platte wurde erkannt und die USB-Maus/Tastatur
sind erkannt. Dann steht alles. Nach 10-15 Sek. kommen noch 3 Zeilen
wegen Random von haveged und dann ist Schluss.

Was passt denn jetzt nicht? Kann ich da irgendwie feststellen wo das
Problem liegt? Ich hätte vermutet, das der Kopiervorgang doch irgendwie
schief gegangen ist, aber dann hätte ich ja eine Fehlermeldung beim
einhängen der Partitionen erwartet und ein Sprung ins Rettungssystem.

Ratlos

Nelson

[Marcus Röckrath]

Hallo Nelson,

Nelson Matias wrote:

> kennst du das auch? Du hast Urlaub aber irgendwie weniger Zeit für dein
> Hobby als wenn du arbeiten würdest?

Ich habe eigentlich nie Zeit für das, was ich gene machen möchte. :-))

> ABER. Der boot-Vorgang bleibt einfach stehen. ich kann nicht genau sagen
> was alles passiert weil das Teil echt schnell scrollt. Alles was noch
> sichtbar ist: die letzte Platte wurde erkannt und die USB-Maus/Tastatur
> sind erkannt. Dann steht alles. Nach 10-15 Sek. kommen noch 3 Zeilen
> wegen Random von haveged und dann ist Schluss.

Das heißt aber, dass Kernel gebootet wird, initrd gestartet wird und danach
auch an den init-Prozess übergeben wurde, denn haveged wird als S36
gestartet.

Kannst du auf eine zweite Konsole schalten und dann mal dmesg aufrufen, um
die Bootmeldungen zu ssehen?

Mal mount aufufen, ob alles sauber gemountet wurde.

> Was passt denn jetzt nicht? Kann ich da irgendwie feststellen wo das
> Problem liegt? Ich hätte vermutet, das der Kopiervorgang doch irgendwie
> schief gegangen ist, aber dann hätte ich ja eine Fehlermeldung beim
> einhängen der Partitionen erwartet und ein Sprung ins Rettungssystem.

Eine Rettungskonsole des Bootmanagers kommt, wenn er das Root-Dateisystem
nicht findet, aber darüber ist der Bootversuch locker gekommen.

--
Gruß Marcus
[eisfair-Team]

[Nelson Matias]

Hallo Marcus,

On 15.05.2021 19:06, Marcus Röckrath wrote:
> Hallo Nelson,
>
> Nelson Matias wrote:
>
>> kennst du das auch? Du hast Urlaub aber irgendwie weniger Zeit für dein
>> Hobby als wenn du arbeiten würdest?
>
> Ich habe eigentlich nie Zeit für das, was ich gene machen möchte. :-))

Gene mach ich keine mehr. Das sollen lieber die von mir gemachten Gene
machen. Die eine hat das auch schon gemacht und mir ein neues Hobby
gegeben: Opa sein. :)

>> ABER. Der boot-Vorgang bleibt einfach stehen. ich kann nicht genau sagen
>> was alles passiert weil das Teil echt schnell scrollt. Alles was noch
>> sichtbar ist: die letzte Platte wurde erkannt und die USB-Maus/Tastatur
>> sind erkannt. Dann steht alles. Nach 10-15 Sek. kommen noch 3 Zeilen
>> wegen Random von haveged und dann ist Schluss.
>
> Das heißt aber, dass Kernel gebootet wird, initrd gestartet wird und danach
> auch an den init-Prozess übergeben wurde, denn haveged wird als S36
> gestartet.

Nee da täuscht du dich. mag sein das kernel und initrd gestartet wurden.
Aber ich hab noch die Pinguine am oberen Rand und kann keine Konsolen
wechseln.
Ich glaube sogar, das INIT nicht startet. Kann es sein, dass irgendwie
ein image nicht gefunden wird?

Ich werde jetzt mal die UUIDs nochmal vergleichen und auch die
extlinux.conf.

> Kannst du auf eine zweite Konsole schalten und dann mal dmesg aufrufen, um
> die Bootmeldungen zu ssehen?
>
> Mal mount aufufen, ob alles sauber gemountet wurde.

So weit komme ich ja noch nicht.

>> Was passt denn jetzt nicht? Kann ich da irgendwie feststellen wo das
>> Problem liegt? Ich hätte vermutet, das der Kopiervorgang doch irgendwie
>> schief gegangen ist, aber dann hätte ich ja eine Fehlermeldung beim
>> einhängen der Partitionen erwartet und ein Sprung ins Rettungssystem.
>
> Eine Rettungskonsole des Bootmanagers kommt, wenn er das Root-Dateisystem
> nicht findet, aber darüber ist der Bootversuch locker gekommen.
>

Nee, so weit kommt der auch noch nicht. Ich denke das wäre der nächste
Schritt. Soweit ich erkennen konnte hat er die HW erkannt. Das letzte
waren die USB-Geräte. Die von mir genannten Meldungen sind von random:
das Meldungen wegen limit nicht angezeigt wurden.

Nelson

[Marcus Röckrath]

Hallo Nelson,

Nelson Matias wrote:

>> Das heißt aber, dass Kernel gebootet wird, initrd gestartet wird und
>> danach auch an den init-Prozess übergeben wurde, denn haveged wird als
>> S36 gestartet.
>
> Nee da täuscht du dich. mag sein das kernel und initrd gestartet wurden.
> Aber ich hab noch die Pinguine am oberen Rand und kann keine Konsolen
> wechseln.

Dann frage ich mich, wo die haveged-Meldungen herkommen.

Kannst du den Boot mal abfilmen und zum Download bereitstellen.

> Nee, so weit kommt der auch noch nicht. Ich denke das wäre der nächste
> Schritt. Soweit ich erkennen konnte hat er die HW erkannt. Das letzte
> waren die USB-Geräte. Die von mir genannten Meldungen sind von random:
> das Meldungen wegen limit nicht angezeigt wurden.

random oder haveged?

--
Gruß Marcus
[eisfair-Team]

[Nelson Matias]

On 15.05.2021 20:28, Marcus Röckrath wrote:
> Hallo Nelson,
>
> Nelson Matias wrote:
>
> Kannst du den Boot mal abfilmen und zum Download bereitstellen.

Dazu fehlt mir das Equipment. Bin aber weiter.

>> Nee, so weit kommt der auch noch nicht. Ich denke das wäre der nächste
>> Schritt. Soweit ich erkennen konnte hat er die HW erkannt. Das letzte
>> waren die USB-Geräte. Die von mir genannten Meldungen sind von random:
>> das Meldungen wegen limit nicht angezeigt wurden.
>
> random oder haveged?
>

die Meldungen waren von random.

Der Kernel findet root nicht. Ich habe scheinbar die UUID nicht
verstanden. Die neue Platte hat andere UUIDs als die alte.

Obwohl fdisk bei beiden Platten die gleichen UUIDs anzeigt.

Die extlinux.conf hat da was ganz anderes drin stehen.

Ich habe jetzt mal beide Platten in den laufenden Eis gesteckt und mir
/dev/disk/by-UUID angeschaut. Die ID der root-partition der neuen Platte
hab ich dort mal in die extlinux.conf beim LABEL eis eingetragen.

Jetzt meldet dracut einen Fehler. Der kann root nicht mounten. Ich
vermute das fs der neuen Platte ist hier nicht ganz ok. Wie kann ich das
reparieren? Oder soll ich das nochmal kopieren?

Nelson

[Marcus Röckrath]

Hallo Nelson,

Nelson Matias wrote:

>> random oder haveged?
>
> die Meldungen waren von random.

Ok, das steht sofort mit dem Laden des Kernels zur Verfügung.

> Der Kernel findet root nicht. Ich habe scheinbar die UUID nicht
> verstanden. Die neue Platte hat andere UUIDs als die alte.
>
> Obwohl fdisk bei beiden Platten die gleichen UUIDs anzeigt.

Für die Platte oder die Partitionen?

fdisk zeigt mir hier die UUIDs der Partitionen nicht an, dafür nehme ich
blkid <device>.

> Die extlinux.conf hat da was ganz anderes drin stehen.
>
> Ich habe jetzt mal beide Platten in den laufenden Eis gesteckt und mir
> /dev/disk/by-UUID angeschaut. Die ID der root-partition der neuen Platte
> hab ich dort mal in die extlinux.conf beim LABEL eis eingetragen.
>
> Jetzt meldet dracut einen Fehler. Der kann root nicht mounten. Ich
> vermute das fs der neuen Platte ist hier nicht ganz ok. Wie kann ich das
> reparieren? Oder soll ich das nochmal kopieren?

Ich hätte von Beginn an eine 1:1-Kopie der alten Platte auf die neue mit
Erhalt der UUIDs erzeugt. Danach dann noch die Partitionen wie gewünscht
aufgezogen.

Due ID der ganzen Platte ist hier ziemlich egal.

Wenn du reparierst musst du die Partitions-UUIDs auf die der alten Platte
setzen. Außerdem muss auch ein richtiger MBR auf der Platte geschrieben
werden, damit extlinux funktionabel ist.

--
Gruß Marcus
[eisfair-Team]

[Nelson Matias]

Guten Morgen Marcus,

On 15.05.2021 21:38, Marcus Röckrath wrote:
> Hallo Nelson,

>> Der Kernel findet root nicht. Ich habe scheinbar die UUID nicht
>> verstanden. Die neue Platte hat andere UUIDs als die alte.
>>
>> Obwohl fdisk bei beiden Platten die gleichen UUIDs anzeigt.
>
> Für die Platte oder die Partitionen?
>
> fdisk zeigt mir hier die UUIDs der Partitionen nicht an, dafür nehme ich
> blkid <device>.

Was sind das dann für UUIDs im erweiterten Modus?

eis # fdisk /dev/sdb

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): x

Expert command (m for help): p

Disk /dev/sdb: 465.78 GiB, 500107862016 bytes, 976773168 sectors
Disk model: WDC WD5000AAKS-0
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: C6659BBD-711F-46CA-85E1-85FE66B1AD72
First LBA: 34
Last LBA: 976773134
Alternative LBA: 976773167
Partition entries LBA: 2
Allocated partition entries: 128

Device Start End Sectors Type-UUID
UUID Name Attrs
/dev/sdb1 2048 198655 196608
0FC63DAF-8483-4772-8E79-3D69D8477DE4
4C9659B4-B491-4A47-9220-6449BEBFCE16 boot LegacyBIOSBootable
/dev/sdb2 198656 8587263 8388608
0657FD6D-A4AB-43C4-84E5-0933C84B4F4F
E119A822-0988-4A9B-9251-73B0D98874CA swap
/dev/sdb3 8587264 936577023 927989760
0FC63DAF-8483-4772-8E79-3D69D8477DE4
F85540C3-2F88-4B36-8E8C-78B306C31271 root

eis # blkid

/dev/sdb1: UUID="c5e73f7a-b4e4-47b5-ba46-d845b27ca1d9" TYPE="ext4"
PARTLABEL="boot" PARTUUID="4c9659b4-b491-4a47-9220-6449bebfce16"
/dev/sdb2: UUID="633ed8ae-a30b-4d24-914b-a880bf86928c" TYPE="swap"
PARTLABEL="swap" PARTUUID="e119a822-0988-4a9b-9251-73b0d98874ca"
/dev/sdb3: UUID="9224a1cc-fbc8-4767-a76f-719f0894b4ce" TYPE="ext4"
PARTLABEL="root" PARTUUID="f85540c3-2f88-4b36-8e8c-78b306c31271"

Wenn ich das richtig lese sind das die gleichen PARTUUID.

eis # ls -la /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 May 15 20:45
c5e73f7a-b4e4-47b5-ba46-d845b27ca1d9 -> ../../sdb1
lrwxrwxrwx 1 root root 10 May 15 20:45
633ed8ae-a30b-4d24-914b-a880bf86928c -> ../../sdb2
lrwxrwxrwx 1 root root 10 May 15 20:45
9224a1cc-fbc8-4767-a76f-719f0894b4ce -> ../../sdb3

Aber hier werden die Type-UUID verwendet. Das verstehe ich jetzt nicht.

Auszug aus extlinux.conf

LABEL eis

MENU LABEL eis

KERNEL ../kernel

INITRD ../initrd.gz

APPEND root=UUID=9224a1cc-fbc8-4767-a76f-719f0894b4ce
raid=noautodetect consoleblank=600

Das alles die alte Platte.

>> Die extlinux.conf hat da was ganz anderes drin stehen.
>>
>> Ich habe jetzt mal beide Platten in den laufenden Eis gesteckt und mir
>> /dev/disk/by-UUID angeschaut. Die ID der root-partition der neuen Platte
>> hab ich dort mal in die extlinux.conf beim LABEL eis eingetragen.
>>
>> Jetzt meldet dracut einen Fehler. Der kann root nicht mounten. Ich
>> vermute das fs der neuen Platte ist hier nicht ganz ok. Wie kann ich das
>> reparieren? Oder soll ich das nochmal kopieren?
>
> Ich hätte von Beginn an eine 1:1-Kopie der alten Platte auf die neue mit
> Erhalt der UUIDs erzeugt. Danach dann noch die Partitionen wie gewünscht
> aufgezogen.

Ich habe auf der alten Platte die root-Partition an die Größe der neuen
Platte angepasst. Danach habe ich die mit dd im gparted-system kopiert.
Das sollte also eine 1:1-Kopie sein.
Gut. Vielleicht ist was bei den ganzen Versuchen kaputt gegangen. Ich
kopiere die nochmal und probiere nochmal.

Was passiert eigentlich, wenn ich 2 Platten im System habe mit gleichen
UUIDs? Gibt es dann nur einen link in /dev/disk/by-uuid?

> Due ID der ganzen Platte ist hier ziemlich egal.
>
> Wenn du reparierst musst du die Partitions-UUIDs auf die der alten Platte
> setzen. Außerdem muss auch ein richtiger MBR auf der Platte geschrieben
> werden, damit extlinux funktionabel ist.
>

Das habe ich ja gemacht. Die Type-UUIDs sind unterschiedlich. Wie setze
ich die denn?

Nelson

[Marcus Röckrath]

Hallo Nelson,

Nelson Matias wrote:

> Was sind das dann für UUIDs im erweiterten Modus?
>
> eis # fdisk /dev/sdb
>
> Welcome to fdisk (util-linux 2.34).
> Changes will remain in memory only, until you decide to write them.
> Be careful before using the write command.
>
> Command (m for help): x
>
> Expert command (m for help): p
>
>

> Device Start End Sectors Type-UUID
> UUID Name Attrs

> /dev/sdb3 8587264 936577023 927989760
> 0FC63DAF-8483-4772-8E79-3D69D8477DE4
> F85540C3-2F88-4B36-8E8C-78B306C31271 root
>
> eis # blkid
>

> /dev/sdb3: UUID="9224a1cc-fbc8-4767-a76f-719f0894b4ce" TYPE="ext4"
> PARTLABEL="root" PARTUUID="f85540c3-2f88-4b36-8e8c-78b306c31271"
>
> Wenn ich das richtig lese sind das die gleichen PARTUUID.
>
> eis # ls -la /dev/disk/by-uuid
> total 0
> lrwxrwxrwx 1 root root 10 May 15 20:45

> 9224a1cc-fbc8-4767-a76f-719f0894b4ce -> ../../sdb3
>
> Aber hier werden die Type-UUID verwendet. Das verstehe ich jetzt nicht.

Bin ich blind? Die UUID aus blkid taucht doch im fdisk überhaupt nicht auf.

Du brauchst aus der blkid-Ausgabe die UUID nicht die PARTUUID:

eis # blkid /dev/sda3
/dev/sda3: UUID="766b01c2-d5e3-4129-979d-f8e5e2558ae4" TYPE="ext3"
PARTUUID="10a3ad76-03"

eis # ls -l /dev/disk/by-uuid/
lrwxrwxrwx 1 root root 10 May 13 09:31 766b01c2-d5e3-4129-979d-f8e5e2558ae4
-> ../../sda3

eis # cat /boot/extlinux/extlinux.conf
APPEND root=UUID=766b01c2-d5e3-4129-979d-f8e5e2558ae4 raid=noautodetect
net.ifnames=1 consolebla

> APPEND root=UUID=9224a1cc-fbc8-4767-a76f-719f0894b4ce

Genau die.

> Was passiert eigentlich, wenn ich 2 Platten im System habe mit gleichen
> UUIDs? Gibt es dann nur einen link in /dev/disk/by-uuid?

IMHO kann das nur Ärger machen. Der Link wird auf die zuletzt erkannte
Platte verweisen.

--
Gruß Marcus
[eisfair-Team]

[Holger Bruenjes]

Hallo

Am 16/05/2021 um 09.07 schrieb Nelson Matias:

> Das habe ich ja gemacht. Die Type-UUIDs sind unterschiedlich. Wie setze
> ich die denn?

ermitteln kannst du die UUID mit blkid

blkid -o value -s UUID /dev/sda3

dann musst du da noch UUID= davorschreiben

sowas

blkid -o value -s UUID /dev/sda3
70097adc-f1e0-438b-aadb-1fcac1a00538

UUID=70097adc-f1e0-438b-aadb-1fcac1a00538


Holger

[Nelson Matias]

Hallo Marcus,

On 16.05.2021 09:22, Marcus Röckrath wrote:
>> Aber hier werden die Type-UUID verwendet. Das verstehe ich jetzt nicht.
>
> Bin ich blind? Die UUID aus blkid taucht doch im fdisk überhaupt nicht auf.

Ja so ging es mir auch. Aber das lag evtl. daran, das hier beide Platten
mal am Eis hingen. Das hatte ich übersehen.

>> APPEND root=UUID=9224a1cc-fbc8-4767-a76f-719f0894b4ce
>
> Genau die.

Ja das hat jetzt auch geklappt. Das letzte Problem lag wo anders. Siehe
unten.

>> Was passiert eigentlich, wenn ich 2 Platten im System habe mit gleichen
>> UUIDs? Gibt es dann nur einen link in /dev/disk/by-uuid?
>
> IMHO kann das nur Ärger machen. Der Link wird auf die zuletzt erkannte
> Platte verweisen.
>

Aha.

Also mein Eis läuft jetzt mit der neuen Platte. Das Problem mit den
UUIDs habe ich dann so gelöst wie es von euch vorgeschlagen wurde. Warum
bei fdisk die Ausgabe teilweise anders ist, ist mir jetzt auch egal. Ich
nehme halt nicht mehr diese Abkürzung ;)

Das letzte Problem war wieder das eingangs schon erwähnte mit dem
Urlaub. Die Ursache war, dass ich nicht mehr alle Latten am Zaun hatte.
Daher hat mein Papa beschlossen den Zaun zu reparieren. Mit meiner Hilfe
natürlich. Und dabei hab ich den letzten Befehl nicht mehr eingegeben.
Das wäre der eigentliche Kopiervorgang für die root-Partition. Kein
Wunder, dass dracut meckerte er fände seine root-files nicht. Die
Partition war leer. *seufz*

Also diesmal wirklich kopiert und schon läuft alles wieder.

Vielen Dank für die Hilfe. Und noch viel mehr Dank für eure Geduld.

Wünsche noch einen schönen Sonntag.

[Nelson Matias]

Hallo Holger,

Und setzen kann ich sie mit tune2fs:

tune2fs /dev/sdb3 -U 70097adc-f1e0-438b-aadb-1fcac1a00538

evtl. meckert tune2fs noch das du einen e2fsck -f machen musst.

Danke für die Hilfe und jetzt gehts wieder.

Schönen Sonntag noch

Nelson

[Marcus Röckrath]

Hallo Nelson,

Nelson Matias wrote:

> Das letzte Problem war wieder das eingangs schon erwähnte mit dem
> Urlaub. Die Ursache war, dass ich nicht mehr alle Latten am Zaun hatte.
> Daher hat mein Papa beschlossen den Zaun zu reparieren. Mit meiner Hilfe
> natürlich. Und dabei hab ich den letzten Befehl nicht mehr eingegeben.

Mal een etwas unterbrechen und etwas anderes machen, ist eine ganz blöde
Idee. :-))

> Das wäre der eigentliche Kopiervorgang für die root-Partition. Kein
> Wunder, dass dracut meckerte er fände seine root-files nicht. Die
> Partition war leer. *seufz*

So simpel kann eine Erklärung sein und da sucht man nach dem ganz großen
Zusammenhang. :-)))

> Also diesmal wirklich kopiert und schon läuft alles wieder.

Prima.

> Vielen Dank für die Hilfe. Und noch viel mehr Dank für eure Geduld.

Bei mir ist die Berufsbedingt - Lehrer.

> Wünsche noch einen schönen Sonntag.

Danke gleichfalls.

--
Gruß Marcus
[eisfair-Team]