[DE] Neutrale Kernel- und Initrd-Bezeichnung in /boot

[ro_sid]

Liebe Siductioner,

es wäre schön, (auch) einen neutralen Namen für den Kernel und die Initrd in /boot zu haben, der nicht von der Version abhängt.

Der Hintergrund: Ich lade das Live-ISO-Image von einem externen Datenträger mit einem eigenen Grub Boot-Eintrag. Wenn sich die ISO-Datei ändert (z.B. durch Updates), kann ich den Eintrag (fast) komplett durch deren Namen abändern, jedoch mit einer Ausnahme. Ich muß die Datei "Loop-Mounten" um an den Versions-Anteil des Kernel- und Initrd-Namens zu gelangen.

Wenn man nun den gleichen Ansatz wie im Dateisystem verfolgt, wo - wohl aus LILO-Tagen - selbst heute noch ein neutraler Sym-Link auf Kernel- und Initrd-Datei (vmlinuz und initrd.img (+ ggf. .old-Eintrag)) verweist, kann man/könnte ich mir diese "Mühe" ersparen .

Ein gleich- oder ähnlichlautender Eintrag in /boot im Root-Verzeichnis der ISO-Datei wäre sehr schön. Vorzugsweise per (Sym- oder Hard-)Link, notfalls aber auch als Dateikopie.

PS: Worauf ich für Siduction gerne hinsteuern würde, ist ein Live-ISO-Image (schon vorhanden!), das auch "Persistenz kann". Etwa wie in der "alten" Fassung (von Ubuntu: "casper-rw" (und "home-rw")), vorzugsweise aber in einer neuen Variante wie bei Debian-Live. Dazu aber mehr zu anderer Zeit und vor allem an anderer Stelle - wegen fll und live-config. Dazu brauche ich vermutlich auch Hilfe und Rat von Kenntnisreichen .

[der_bud]

Kannst Du denn nicht einfach die generischen /vmlinuz und /initrd.img im root der Iso nutzen, statt in /boot abzutauchen? Ich habe z.B.  bei einem Dualboot Setup für das "andere" System eine 40-custom in /etc/grub.d, um dort immer mit

Code: [Select]

...
linux /vmlinuz root=UUID=40d51e0b-6eb5-41b9-9e57-e1f0b63c5299 ro  quiet
initrd /initrd.img
...
den jeweils aktuellen Kernel zu laden.

[unklarer]

Guter Punkt @der_bud.

Vor vielen Jahren bin ich genau auch an diesem Problem gescheitert und habe siduction-iso nicht zum starten gebracht.
Mit anderen Distri-Iso's ging das einwandfrei. Nur mit der siduction nicht. Schließlich habe ich das dann zugunsten von QEMU aufgegeben, weil es hier viel einfacher ist und man nicht ständig für die entsprechenden Parameter in die ISO "schauen" muß. 

[ro_sid]

@der_bud:

Kannst Du denn nicht einfach die generischen /vmlinuz und /initrd.img im root der Iso nutzen, statt in /boot abzutauchen? Ich habe z.B.  bei einem Dualboot Setup für das "andere" System eine 40-custom in /etc/grub.d, um dort immer mit

Code: [Select]

...
linux /vmlinuz root=UUID=40d51e0b-6eb5-41b9-9e57-e1f0b63c5299 ro  quiet
initrd /initrd.img
...
den jeweils aktuellen Kernel zu laden.

(Eine Einschränkung vorweg: Meine Aussagen beziehen sich derzeit nur auf den KDE-Desktop; vermutlich ist es bei den anderen ISO-Dateien aber genauso.}
Das ist oft eine gute Idee, hier aber nicht, sofern ich nicht etwas Wesentliches übersehen habe. Root (/) des Dateisystems in dem sich die Links (/vmlinuz, ...) befinden ist seinerseits eine squashfs-Datei, die sich in der ISO-Datei befindet (Verzeichnis /siduction). Ich brauche den Loop-mount des Grub ja schon um an dieses root (/) zu kommen! Daher gibt es kein "vmlinuz" in dem "linux /vmlinux ..." aus dem Beispiel-Code oben. Ich müßte zunächst noch "squashfs" (loop) mounten um überhaupt darauf zugreifen zu können.
Es ist aber noch ein bißchen schlimmer : Selbst wenn ich das täte, ist dort /initrd.img ein "dangling Link", denn in /boot liegt gar keine initrd-Datei. Sie wird ja nicht gebraucht, da der Kernel schon in/aus der vorigen "Schicht" geladen wurde. Leider ist sie eben dort aber auch gar nicht vorhanden. /initrd.img... liegt nur in /boot, bei mir derzeit als "initrd.img-6.2.6-1-siduction-amd64".

Eine Abhilfe wäre vielleicht, in Grub durch 'ls' und Stringmanipulation den aktuellen Namen zu ermitteln. Eventuell mache ich das sogar im Notfall. Ein Link wäre in meinen Augen aber einfacher und komfortabler.

Der Link muß übrigens nicht unbedingt in /boot liegen, falls das ein Problem sein sollte. Jedes andere (festgelegte) Verzeichnis in oder unterhalb von "/" täte es auch, solange die Links auf Kernel und Initrd zeigen.

Aber danke für das Interesse. Anregungen sind immer gut!

[towo]

Ich will ja nicht meckern, aber

https://github.com/siduction/pyfll

da ist das Script, Du darfst gerne einbauen, was Du brauchst.

[ro_sid]

Dank an @towo

Ich will ja nicht meckern, aber

https://github.com/siduction/pyfll

da ist das Script, Du darfst gerne einbauen, was Du brauchst.

das will ich gerne versuchen, also das Einbauen, nicht das Meckern .
Dabei benötige ich aber Hilfe. Was brauche ich alles um das ausführen zu können? Wie kann ich die Wirkung von Änderungen dann testen? Ich bin bisher eher so "Pakete" mit Makefile gewöhnt.
[Ausgecheckt bekomme ich so ein "Git"-Repository schon. Eventuell einfach als .zip heruntergeladen. Aber dann ...?]
PS: Das README habe ich gelesen, aber wie entsteht dann mein "ISO" oder auch nur das /boot-Directory davon.

[towo]

https://testbuilds.siduction.org/kde/siduction-Masters_of_War-kde-amd64-latest.iso

Dort habe ich initrd.img und vmlinuz als Hardlinks in /boot mit im ISO.
Als symlink wollte es irgendwie nicht.

Du kannst das gerne testen und berichten.

[ro_sid]

https://testbuilds.siduction.org/kde/siduction-Masters_of_War-kde-amd64-latest.iso

Dort habe ich initrd.img und vmlinuz als Hardlinks in /boot mit im ISO.
Als symlink wollte es irgendwie nicht.

Du kannst das gerne testen und berichten.

Tue ich gerade und es funktioniert ganz wunderbar. Ich schreibe aus dem laufenden Live-Image.
Vielen Dank, das war sehr nett!

Eine Information, nur als solche, nicht als Meckerei: In der ISO-Datei sind die beiden Varianten mit verschiedenen I-nodes (ls -li) gelistet, allerdings mit einem Link-Count von 2. Das habe ich noch nie gesehen. Vermutlich ist es effektiv wohl eine Kopie. Das ist vielleicht auch der Grund, warum der Symlink nicht funktioniert. Es könnte am Dateisystem liegen, obwohl laut Wikipedia die Rock Ridge Erweiterung von ISO 9660 Links unterstützt, oder am Build-System, das vielleicht kein RR erzeugt.
Wie dem auch immer sei, jedenfalls nochmals herzlichen Dank.

Mal sehen ob ich herausbekomme, wie die Änderung im pyfll aussehen muß(te).

[towo]

Die Änderung habe ich ja im pyfll gemacht.

Code: [Select]

os.link(os.path.join(boot_dir, 'initrd.img-' + k), os.path.join(boot_dir, 'initrd.img'))
os.link(os.path.join(boot_dir, 'vmlinuz-' + k), os.path.join(boot_dir, 'vmlinuz'))

Im entsprechenden Abschnitt.

Vorher hatte ich eben os.symlink() versucht, im Build-Ordner waren die Symlinks auch da, aber dann nicht im erzeugten ISO.

[ro_sid]

@towo: Noch mal vielen Dank für die Vorlage!

Inzwischen habe ich herausgefunden, warum die Symlinks nicht funktioniert haben und kann sagen, wie es klappt. Nämlich so:

Code: [Select]

os.symlink('initrd.img-' + k, os.path.join(boot_dir, 'initrd.img'))
os.symlink('vmlinuz-' + k, os.path.join(boot_dir, 'vmlinuz'))Ich hab's erfolgreich ausprobiert.

Der Grund warum es in der Form wie im Link-Beispiel

Code: [Select]

os.link(os.path.join(boot_dir, 'initrd.img-' + k), os.path.join(boot_dir, 'initrd.img'))
os.link(os.path.join(boot_dir, 'vmlinuz-' + k), os.path.join(boot_dir, 'vmlinuz'))nicht funktioniert hat ist, daß beim Symlink und so auch os.symlink der "src-Parameter/-Pfad" relativ zum Pfad des zu erzeugenden (Sym-)Links ("dst") angegeben werden muß. [Sonst zeigt er (meistens) ins Leere, so wie es hier sogar die absolute Pfadangabe nach dem Kopieren ins "staging" tut.]

Es wäre schön, diese (zusätzliche) neutrale Benennung zukünftig grundsätzlich mit in Siduction aufzunehmen. Auch dafür meinen Dank.

[towo]

Also ich habe das jetzt nochmal getestet, da sind keine Symlinks im ISO.

[towo]

Kommando zurück: https://forum.siduction.org/index.php?topic=9002.msg71387#msg71387