• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst] Universelle initrd

nicibuild

Newbie
Servus,

gbit's einen Weg, eine universelle ramdisk für alle vom kernel unterstützten IDE-/SCSI-/SATA-Controller und Dateisysteme zu erstellen (ausser alle möglichen Module zusammenzusuchen und in /etc/sysconfig/kernel einzutragen)?
 

spoensche

Moderator
Teammitglied
Eine universelle initrd ist doch absolut schwachsinnig. Sorry wenn ich das jetzt so hart ausdrücke. Du wirst niemals einen Rechner haben, der sämtliche Controller verwendet die der Kernel unterstützt.
 
OP
N

nicibuild

Newbie
spoensche schrieb:
Eine universelle initrd ist doch absolut schwachsinnig.

Das finde ich nicht.

whois schrieb:
Ack, trotzdem bleibt die Frage wofür brauchst du das?

Für imaging bzw. restore von Images.

Beispiel: Suse XY installiert auf einem IDE-System. Ein Image dieses Systems bootet mir nicht auf einem SCSI-System, weil in der initrd kein scsi-Modul geladen wird. Und da ich hier nicht nur ein Quell- und ein Zielsystem habe, sondern viele verschiedene, würde ich gern wissen, ob es einen Weg gibt, dieses Problem zu umschiffen? Die Lösung, die mir auf die Schnelle einfiel, ist alle Module in die initrd zu packen. Das funktioniert übrigens auch (abgesehen davon, dass natürlich alle in der initrd geladenen Module geladen bleiben, von denen eigentlich nur eins benötigt wird).
 

spoensche

Moderator
Teammitglied
Man erstellt Images bzw. Backups komplett nur von einem einzigen System, was bei einem Crash o.ä wieder genau auf den Rechner zurückgespielt wird wo es erstellt worden ist und nicht so ein Mischmasch. Das hat doch nichts mehr mit einem Backupkonzept zu tun und wirst du auch nirgends finden.
Die Gefahr, dass du dir damit dein Backup inkl. Datenverlust zerschiesst ist viel zu hoch und du hast im schlimmsten Fall kein Backup mehr und sämtliche Daten sind weg.

Was machst du den, wenn die Systeme unterschiedliche Kernelversionen haben? Dann geht das mit der initrd so wieso nicht.
 
A

Anonymous

Gast
ganz so als reine initrd ist es Quatsch, dann höchstens ein Minisystem das man dann als eigenständiges Notsystem komplett im Speicher höchläd, das wird dann als initrd eingebunden. Das Rescue auf den Suse-Cds war immer so was, was man als Ausgangspunkt da prima mit hernehmen konnte. Hab ich schon ein paar Mal mit der initrd gemischt noch etwas ausgebaut und erweitert und wieder als initrd abgelegt, so dass sie dann als eigenständiges System im Ram auf allen Systemen gelaufen ist, automatisch die wichtigste Hardware gesucht und konfiguriert hat und dann auch von außen über ssh ansprechbar war, also auch als automatisch startendes Notsystem für entfernte Rechner funktioniert hat.

robi
 
OP
N

nicibuild

Newbie
spoensche schrieb:
Man erstellt Images bzw. Backups komplett nur von einem einzigen System, was bei einem Crash o.ä wieder genau auf den Rechner zurückgespielt wird wo es erstellt worden ist und nicht so ein Mischmasch. Das hat doch nichts mehr mit einem Backupkonzept zu tun und wirst du auch nirgends finden.

Ich hab ja auch nichts von Backup gesagt, oder?

spoensche schrieb:
Was machst du den, wenn die Systeme unterschiedliche Kernelversionen haben? Dann geht das mit der initrd so wieso nicht.

Das ist mir bewußt. Ich frage aber explizit nach einer Möglichkeit, ein einmal installiertes und geimagtes System nach einem restore auf jeder vom Kernel unterstützten Hardware (Hardware beschränkt auf IDE-/SATA-/SCSI-Controller. Von anderer hardware reden wir jetzt nicht) zu booten. Wenn hier jemand einen Vorschlag hat, immer her damit.

robi schrieb:
Das Rescue auf den Suse-Cds war immer so was, hab ich schon ein paar noch etwas ausgebaut so dass sie dann als eigenständiges System im Ram auf allen Systemen gelaufen ist, automatisch die wichtigste Hardware gesucht und konfiguriert hat und dann auch von außen über ssh ansprechbar waren, also auch als automatisch startendes Notsystem für entfernte Rechner funktioniert hat.

So was ähnliches habe ich mir auch schon überlegt, allerdings bin ich mit meinen Überlegungen noch nicht weit gekommen. Kannst Du mir ein bisschen detaillierter erklären, wie Du vorgegangen bist?
 
A

Anonymous

Gast
So was ähnliches habe ich mir auch schon überlegt, allerdings bin ich mit meinen Überlegungen noch nicht weit gekommen. Kannst Du mir ein bisschen detaillierter erklären, wie Du vorgegangen bist?
Ist nicht so einfach, da ne ganze Menge Handarbeit, hatte hier vor Jahren mal ein längeres Howto dazu ins Forum gesetzt, ist allerdings mittlerweile wegen zu speziell, zu kompliziert und zu lang nach /dev/null gewandert.

Wichtig erstmal beschäftigen mit http://wiki.linux-club.de/opensuse/Bootvorgang#Starten_der_initrd und wahrscheinlich noch einigen Dingen mehr, es ist also nichts für absulut Unerfahrene.

Dann kleines System zB die Rescue sowie den Kernel und die initrd dazu suchen. Eine Maximale Größe für das Notsystem festlegen, ich habe immer so zwischen 64 max 80 MB genommen.
Auf ein Loopdevice ein entsprechend deiner maximal gewünschten Größe ein ext2 Filesystem erzeugen, (Achtung: kleinste Blockgröße, hoher Anteil von Inodes; bei 11.0 auf 128er Inodegröße achten.) Da hinein erstmal die Rescue "richtig" kopieren. Dann dieses System untersuchen insbesondere welche Geräteinitialisierung wird verwendet und ist das das Richtige für mich. Danach erst mal wieder löschen, die initrd auspacken und in dieses Filestem kopieren, danach die Rescue darüber kopieren (Achtung einige Dateinamen sind gleich, dabei muss entschieden werden welche Version man benötigt) Dann wird das System erweitert, unnötige Dateien werden gelöscht, benötigte Module dazugepackt, (auf der Rescue sind wahrscheinlich einige die gelöscht werden können), Programme, Konfigurationsdateien und Librarys die benötigt werden, werden noch rüberkopiert. modules.dep und Linux-loader konfigurieren. Danach das System konfiurieren, insbesondere Ramdevices für /tmp usw anlegen , fstab, und je nach dem Hardwarescan und Konfiguration, automatische default Netzconfigurationen, Startscripte anpassen. usw. Ist nicht immer einfach weil man ja dabei immer an die Maximalgrenze des Dateisystems stößt, man muss sich schon stark einschränken.
Hin und wieder in einer Chrootumgebung austesten. danach eventuell noch aus allen bin und libs die unnötigen Debuginfos rauslöschen um Platz zu sparen. Wenn man denkt, fertig, dann das ganze zu einer initrd zusammenpacken, und mit dem passenden Kernel und angepassten Kerneloptionen für entsprechend großere Ramdevices ausprobieren. Ich habe immer 2 Stufigen Ablauf gewählt, erst die Erstinitialisierung ala initrd durch zB linuxrc, und danach anschließend umschwenken auf die inittab und daraus die Boot und Startscripte.Ganz zum Schluss bei initrc Variante komprimiertes Filesystem noch das Filsystem bereinigen damit sich das Ganze dann wunderschön kómprimieren lässt.
Wenn man sowas das erste Mal ohne genaues und spezielles Howto macht, sind da selbst für erfahrene Linuxer schon bequem ein paar Tage für das Ganze einzurechnen.

robi
 

Gimpel

Guru
Wozu überhaupt eine initrd?

Bau alles was du willst/brauchst in den kernel (wird bei live-cds auch meist so gemacht).
 
OP
N

nicibuild

Newbie
Gimpel schrieb:
Wozu überhaupt eine initrd?
Bau alles was du willst/brauchst in den kernel (wird bei live-cds auch meist so gemacht).

Es handelt sich nicht um ein einziges System, sondern um >> 100 Systeme, die untereinder wild hin- und hergeimaget werden können sollen. Da kann ich nicht an jedem Rechner alles benötigte in den Kernel bauen. Aus dem gleichen Grund kann ich auch nicht für jeden Rechner nach dem restore eine neue, an die entsprechende Hardware angepasste ramdisk basteln.

Was ich möchte: Image ziehen von System X, restore auf System Y, unterjubeln meiner universellen initrd, booten des Systems Y. Eine neue ramdisk mit allen für den jew. Kernel verfügbaren Modulen zu bauen ist kein Problem. Es bleiben halt alle Module aus der ramdisk geladen, egal ob sie benötigt werden oder nicht.

Wahrscheinlich werd ich mir einen anderen Weg einfallen lassen müssen oder mal untersuchen, wie Suse bei der Installation die ramdisk bastelt. Dann sehen wir weiter.
 

towo

Moderator
Teammitglied
Nur, daß ein anderes System trotzdem nicht booten wird, von diesem Image, weil die initrd ist das geringste Übel bei der Sache.
 

Gimpel

Guru
nicibuild schrieb:
Es handelt sich nicht um ein einziges System, sondern um >> 100 Systeme, die untereinder wild hin- und hergeimaget werden können sollen. Da kann ich nicht an jedem Rechner alles benötigte in den Kernel bauen.
Du baust auf dem "template" System einen Kernel der einfach alles an Chipset-, IDE/ATA/SCSI und sonstwas Treibern drin hat was menuconfig hergibt, und damit hat sich's.

Nicht die ramdisk ist universell, sondern der kernel an sich. Wo keine Module, da keine initrd. (ich benutze seit Jahren keine initrd mehr..)

Sicherheit und Performance scheinen bei dem Pfusch ja keine Rolle zu spielen.
 
OP
N

nicibuild

Newbie
towo schrieb:
Nur, daß ein anderes System trotzdem nicht booten wird, von diesem Image, weil die initrd ist das geringste Übel bei der Sache.

Wie kommst Du zu der Aussage?

Gimpel schrieb:
Nicht die ramdisk ist universell, sondern der kernel an sich. Wo keine Module, da keine initrd. (ich benutze seit Jahren keine initrd mehr..)

Ich stimme Dir voll und ganz zu. Ich persönlich benutze auch schon ewig keine initrd mehr. Ich habe aber hier eine Umgebung, in der der Kernel nicht angetastet werden darf, sondern nur ein Image von Maschine X auf Maschine Y übertragen wird. Meine erste Idee war die beschriebene universelle Ramdisk.
Als OS kommen RedHat Enterprise und seine Verwandtschaft, OpenSUSE und SUSE Enterprise zum Einsatz. Alle haben sie gemeinsam, dass mit Hilfe einer Ramdisk gebootet wird.
Ich werd mir mal die Installationsroutinen von RH und Suse angucken. Vielleicht werd ich schlau draus.

Gimpel schrieb:
Sicherheit und Performance scheinen bei dem Pfusch ja keine Rolle zu spielen.

Welche Sicherheitsprobleme siehst Du?
 
Nun kann man ja alle Treiber nach belieben eintragen (z.B. über yast) und die initrd erzeugen.
Problem ist bei Systemen mit z.b. verschiedenen Plattencontrollern: Es ist entscheidend, in welcher Reihenfolge die Treiber aufgerufen werden, denn danach werden die Laufwerksbezeichnungen sdx vergeben.
Ich fall da jedesmal drau rein, weil die Installations-DVD eine andere Reihenfolge hat als das damit installierte System => erster Boot ergibt crash. Rescue, Treiberreihenfolge umstellen und dann gehts.

aber ich denk auch, daß ein Monster-monolitischer Kernel da einfacher ist...
 

spoensche

Moderator
Teammitglied
nicibuild schrieb:
Welche Sicherheitsprobleme siehst Du?

Wenn System X kompromittiert (gecrackt) ist und du fröhlich das Image von X nach Y und Z überträgst, hast du schon 3 kompromittierte Systeme. Wenn du dann das Image von X fröhlich weiter auf anderen Rechnern in deinem Netzwerk verteilst, ist irgendwann dein ganzes Netzwerk kompromittiert und der Angreifer freut sich, das er ein ganzes Netzwerk zur Verüfung hat, von wo aus er weitere Angriffe starten kann.
 
OP
N

nicibuild

Newbie
spoensche schrieb:
Wenn System X kompromittiert (gecrackt) ist und du fröhlich das Image von X nach Y und Z überträgst, hast du schon 3 kompromittierte Systeme. Wenn du dann das Image von X fröhlich weiter auf anderen Rechnern in deinem Netzwerk verteilst, ist irgendwann dein ganzes Netzwerk kompromittiert und der Angreifer freut sich, das er ein ganzes Netzwerk zur Verüfung hat, von wo aus er weitere Angriffe starten kann.

Achso. Ich dachte an ein Sicherheitsproblem mit der ramdisk.
 
A

Anonymous

Gast
Wenn ich das jetzt richtig verstanden habe, dann geht es gar nicht um eine universelle initrd, sondern um komplette Systemimages, die problemlos auf mehreren Rechnern auch unter anderer Hardware laufen sollen.

Warum nicht einfach ín die initrd alle Module rein, die die unterschiedlichsten Rechner dort unten wirklich benötigen würde, so viele sind das auch wieder nicht, trifft in dem Fall wohl erstmal nur Plattenkontroller und ähnliches für das Rootfilesystem, alles andere wie Filesystemtype, eventuell Raid, Crypt oder was auch immer noch für das mounten des Rootfilesystems benötigt würde, bleibt ja im Image sowieso gleich. Alle anderen Module werden eh später erst in den Startscripten automatisch nach Bedarf geladen. Zugriff auf die Platten innerhalb der fstab musst du in diesem Fall über die Kennung des Filesystems realisieren. Soll er doch in der initrd alle Module laden. Wenn das System oben ist, und alles soweit konfiguriert und gestartet ist, läßt du als letztes ein Startscript laufen, mit dem du alle nicht benutzten Module mit modprobe wieder aus dem Kernel rausschmeißt. Wenn er da was rausschmeißt was er doch benötigen würde, nur weil es im Moment nicht benutzt wird, macht auch nichts, das wird dann automatisch bei nächster Notwendigkeit automatisch wieder geladen. Wenn doch zum Schluss ein Modul permanent fehlt, dann kannst du das ja im Script nach dem aufräumen separat wieder laden lassen.

robi
 
OP
N

nicibuild

Newbie
robi schrieb:
Wenn ich das jetzt richtig verstanden habe, dann geht es gar nicht um eine universelle initrd, sondern um komplette Systemimages, die problemlos auf mehreren Rechnern auch unter anderer Hardware laufen sollen.

Exakt

robi schrieb:
Warum nicht einfach ín die initrd alle Module rein, die die unterschiedlichsten Rechner dort unten wirklich benötigen würde, [...] Wenn doch zum Schluss ein Modul permanent fehlt, dann kannst du das ja im Script nach dem aufräumen separat wieder laden lassen.

Danke. Das werd ich ausprobieren.
 
Die Idee einer initrd mit allen Treibern ist nicht verkehrt. Allerdings wird das unnötig viel Speicher in Anspruch nehmen, und einige Bootloader machen ab einer gewissen Größe auch nicht mehr mit (wahrscheinlich schon jahrelang gelöst)—aber gewiss wirst du keine 64MB-Initrd in ein 32MB-System laden können. Was machen also Live-CDs? In deren initrd wird sich nur der CDROM-Treiber finden (minus Ausnahmen ;-) ). Die initrd wird danach entladen, und weitere Treiber werden über das normale von der CD gemountete Dateisystem geladen, das ist wesentlich speicherfreundlicher (load-on-demand).
 
A

Anonymous

Gast
jengelh schrieb:
und einige Bootloader machen ab einer gewissen Größe auch nicht mehr mit (wahrscheinlich schon jahrelang gelöst)—aber gewiss wirst du keine 64MB-Initrd in ein 32MB-System laden können.
Kernelparameter
Code:
ramdisk_size=N  (in KByte)
Default eingestellt sind 4 MB ich lade seit Jahren aber auch Ramdisks und initrd mit 300 und mehr MBs und fahre nur 32 Bit. Die initrd wird auch nur als ramdisk0 also /dev/ram0 geladen. Ob es da überhaupt eine harte Obergrenze gibt?

PS nach Test:
Wenn du genügend Speicher im System hast, geht schon einiges. ;) hier mal mein Rechenknecht mit 12GB Hauptspeicher
Code:
rml100:/proc # dd if=/dev/zero of=/dev/ram0 bs=1K
dd: writing `/dev/ram0': No space left on device
6116521+0 records in
6116520+0 records out
6263316480 bytes (6.3 GB) copied, 21.4855 s, 292 MB/s
rml100:/proc # mkfs /dev/ram0
mke2fs 1.40.2 (12-Jul-2007)
/dev/ram0 is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
..........
rml100:/proc # mount -o loop /dev/ram0 /mnt
rml100:/proc # mount
..........
usbfs on /proc/bus/usb type usbfs (rw)
securityfs on /sys/kernel/security type securityfs (rw)
/dev/ram0 on /mnt type ext2 (rw,loop=/dev/loop0)
rml100:/proc # df
Filesystem           1K-blocks      Used Available Use% Mounted on
...........
/dev/ram0              6020388     11960   5702604   1% /mnt
da sollten dann schon ein paar Kernel-Module in die initrd reinpassen. ;) ;) ;)

robi
 
Oben