Ack, trotzdem bleibt die Frage wofür brauchst du das?spoensche schrieb:Du wirst niemals einen Rechner haben, der sämtliche Controller verwendet die der Kernel unterstützt.
spoensche schrieb:Eine universelle initrd ist doch absolut schwachsinnig.
whois schrieb:Ack, trotzdem bleibt die Frage wofür brauchst du das?
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.
spoensche schrieb:Was machst du den, wenn die Systeme unterschiedliche Kernelversionen haben? Dann geht das mit der initrd so wieso nicht.
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.
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.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?
Gimpel schrieb:Wozu überhaupt eine initrd?
Bau alles was du willst/brauchst in den kernel (wird bei live-cds auch meist so gemacht).
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.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.
towo schrieb:Nur, daß ein anderes System trotzdem nicht booten wird, von diesem Image, weil die initrd ist das geringste Übel bei der Sache.
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..)
Gimpel schrieb:Sicherheit und Performance scheinen bei dem Pfusch ja keine Rolle zu spielen.
nicibuild schrieb:Welche Sicherheitsprobleme siehst Du?
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.
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.
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.
Kernelparameterjengelh 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.
ramdisk_size=N (in KByte)
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