Installationskernel / initrd für SuSE10.0 bauen?
Hallo zusammen, ich hab einen angemieteten dedicated Server auf dem SuSE9.3 läuft, aber nicht mit dem Standartkernel. Jetzt möchte ich da gerne "remote" ein SuSE10.0 aufspielen - dazu hab ich mich an die Anleitung gehalten: http://www.opensuse.org/Network_Install Das Problem ist, dass die Kernel und initrd, die unter boot/loader/ zu finden sind, auf dem Zielserver nur "halb" laufen, sprich sie booten, ich kann per ssh connecten und auch (sinnloserweise) Yast starten. ABER die Festplatten werden nicht erkannt, und somit kann ich nirgens hin installieren. Es scheint so zu sein, dass wegen der Hardware ein Kernel größer 2.6.14 installiert sein muß. Vermutlich liegt es an dem Fehlenden Modul sata_sis. Ich hab auch erfolgreiche einen 2.6.15.1 aus den Quellen von kernel.org installiert und boote damit das 9.3 System. Jetzt dachte ich mir einen eigenen Kernel und initrd zu bauen, mit dem ich dann das SuSE 10.0 installieren kann. Ich müßte dann ja nach der Installation nur als erstes wieder nen eigenen Kernel bauen (ggf. über das remote-rescue-system). Nach der langen Einleitung jetzt die einfache Frage: Wie mache ich das? Ein Ansatz würde mir reichen. Ich vermute, dass eigendlich nur die initrd erweitert werden muss - kann es sein, dass da linuxrc oder so mit "reingebaut" werden muss? Wenn jemand eine andere - einfachere - Möglichkeit kennt, auf den Server ein SuSE 10.0 auf zu spielen, sind Antworten natürlich auch erwünscht ;-) Vielen dank schon mal Torben
* Torben Schultz wrote on Tue, Jan 24, 2006 at 17:21 +0100:
Ich hab auch erfolgreiche einen 2.6.15.1 aus den Quellen von kernel.org installiert und boote damit das 9.3 System. Jetzt dachte ich mir einen eigenen Kernel und initrd zu bauen, mit dem ich dann das SuSE 10.0 installieren kann. Ich müßte dann ja nach der Installation nur als erstes wieder nen eigenen Kernel bauen (ggf. über das remote-rescue-system).
Nach der langen Einleitung jetzt die einfache Frage: Wie mache ich das? Ein Ansatz würde mir reichen.
Ich vermute, dass eigendlich nur die initrd erweitert werden muss - kann es sein, dass da linuxrc oder so mit "reingebaut" werden muss?
Die initrd wird mit mkinitrd gebaut, dass kennt Parameter für Image (kernel) und initrd selbst (sonst überschreibt mkinitrd gleich mal alles, was er in /boot/ findet). mkinitrd benutzt dabei diverse Parameter und Files, ich glaub sowas wie /etc/fstab und so, da muss man sich das Script genau anschauen und ggf. auch ändern. Die zu ladenden Module stehen in irgendeiner /etc/sysconfig/* drin. Vermutlich musst Du aber ein bisschen trixen, wenn Du nicht die gerade laufenden Module (/lib/modules/`uname -??` oder sowas) haben möchtest. Das initrd:/init script (bin/init?) wird von mkinitrd dynamisch erzeugt. Mit cpio kannst Du Dir die initrd "auspacken" (und auch wieder geändet einpacken - aber dann weisst Du das nächste mal nicht mehr, was Du geändert hast - Script nehmen oder machen!). Soweit ich weiss, ist es nicht direkt vorgesehen, eingene Sachen "reinzubauen", musst dann ggf. mkinitrd aufbohren. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo, also der Tipp die initrd mit cpio (und gunzip) zu entpacken ist schon mal super und hilft mir weiter - zumindest nach meiner Vorstellung. Dafür schon mal vielen Dank. Also in der "installations" initrd ist tatsächlich deutlich mehr drinne und auch das von mir vermutete linuxrc. Ich hab jetzt einfach aus meiner eigenen initrd und der "Vorlage" eine gemacht - nur die bootet leider (noch) nicht. Ich befürchte, dass ich das mit den /dev "Dateien" nicht hinbekommen habe. Beim entpacken als User kam auch ne Fehlermeldung: ich@rechnern:~/initrd_build> gunzip -c ./initrd64 | cpio -cid cpio: dev/null: Die Operation ist nicht erlaubt cpio: dev/ram0: Die Operation ist nicht erlaubt cpio: dev/tty1: Die Operation ist nicht erlaubt cpio: dev/tty3: Die Operation ist nicht erlaubt cpio: dev/tty4: Die Operation ist nicht erlaubt cpio: dev/tty9: Die Operation ist nicht erlaubt cpio: dev/zero: Die Operation ist nicht erlaubt cpio: dev/console: Die Operation ist nicht erlaubt 39845 blocks Deswegen hab ich es als root gemacht, aber ich weiß nicht ob ich das dann beim wieder packen auch richtig gemacht habe. Ich hab das so gepackt: find ./initrd_neu/ -depth | cpio -o > ./initrd-2.6.15-install-v1 dann: gzip -c ./initrd-2.6.15-install-v1 > ./initrd-2.6.15-install-v1.gz Und eben alles nach /boot und die grub menu.lst geändert. Tja irgendwie bleibt das aber beim booten hängen, und ich kann ja nicht schauen was auf dem Bildschirm ist :( Jemand eine Idee wie ich das mit den Devices richtig mache, oder wo es sonst dran liegen könnte? Gruß Torben
* Torben Schultz wrote on Wed, Jan 25, 2006 at 00:35 +0100:
Beim entpacken als User kam auch ne Fehlermeldung: [klar, User dürfen natürlich nicht mit Devices rumspielen]
[...]
Deswegen hab ich es als root gemacht, aber ich weiß nicht ob ich das dann beim wieder packen auch richtig gemacht habe. Ich hab das so gepackt: find ./initrd_neu/ -depth | cpio -o > ./initrd-2.6.15-install-v1
mmm... Eigentlich sollte cpio doch kein find brauchen? Wollte man in mkinitrd reingucken, aber mein altes Linux hier macht noch images und das neue konnte ich nicht installieren: link:~ # rpm --force --nodeps -i --prefix /tmp/xxx /home/public/tmp/linux/mkinitrd-1.2-26.noarch.rpm error: package mkinitrd is not relocateable Gut, dass der gute alte Midnight Commander das "vfs" hat :) (Wie packt man ein RPM aus, wenn man reingucken will, und es nicht installieren kann?) mmm... Auch find: find . ! -name "*~" | cpio -H newc --create | gzip -9 > $tmp_initrd.gz (mkinitrd-1.2-26)
dann: gzip -c ./initrd-2.6.15-install-v1 > ./initrd-2.6.15-install-v1.gz
("gzip ./initrd-2.6.15-install-v1" sollte /hier/ das gleiche sein) Weiss nicht, ob "-H newc" wichtig ist, könnte es mir aber vorstellen.
Und eben alles nach /boot und die grub menu.lst geändert.
Tja irgendwie bleibt das aber beim booten hängen, und ich kann ja nicht schauen was auf dem Bildschirm ist :(
Boote die initrd doch mal an Deinem lokalen System, falls es ein Flüchtigkeitsfehler ist; natürlich als zusätzliche Bootversion. Also im lilo.conf Sektion kopieren, dann label und initrd ändern und lilo -v. Von Grub hab ich keine Ahnung.
Jemand eine Idee wie ich das mit den Devices richtig mache, oder wo es sonst dran liegen könnte?
Ja, als root machen. User dürfen keine Devices anlegen (und auch kein chown etc. pp). Sonst könnten sich ja user ein /dev/kmem oder sowas nettes anlegen und gemeine Sachen reinschreiben, kernelmodule laden oder sowas, ein Filesystem mit setuid->0 Shell mounten oder sowas. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo, also ich bin wieder ein Stück weiter, Danke. Ich hab noch sowas ähnliches als Anleitung für RedHat gefunden: http://www.linux-magazin.de/Artikel/ausgabe/2003/04/058_kickstart/kickstart.... Geht da zwar um ne boot Diskette, aber es zeigt den weg. Aber klappen tut es immernoch nicht. also: Am Mi, 2006-01-25 um 01.14 schrieb Steffen Dettmer:
find ./initrd_neu/ -depth | cpio -o > ./initrd-2.6.15-install-v1 mmm... Eigentlich sollte cpio doch kein find brauchen? Hatte ich so in der Art mal gefunden, und das klappt eigendlich schon. Mag aber ne elegantere Lösung geben.
(Wie packt man ein RPM aus, wenn man reingucken will, und es nicht installieren kann?) hm - wüßte nur, dass man beim installieren ein prefix angeben kann.
find . ! -name "*~" | cpio -H newc --create | gzip -9 > $tmp_initrd.gz [...] Weiss nicht, ob "-H newc" wichtig ist, könnte es mir aber vorstellen. jo das scheint richtig zu sein, in der gefundenen Anleitung machen die es auch so.
Boote die initrd doch mal an Deinem lokalen System, .... Der Server ist ein 64bit System und sowas hab ich hier nicht. Aber ich hab den Weg einfach mal bei mir zuhause ausprobiert. Das klappte, nur haben da die beiden "Vorlage" initrds eine fast gleiche Struktur (und Dateien). Bei den beiden initrds für den Server ist alles unterhalb "lib/" völlig anders. Und es gibt bei der SuSE-Vorlage ein "lib64/" und bei der anderen nicht. Da muß ich jetzt weiter dran arbeiten (aber nicht mehr heute nacht). Ich befürchte auch, dass ich noch einige zusätzliche Module mit aufnehmen - noch überblicke ich die ganzen Unterschiede nicht. Und wie ich die ganzen modules.conf und Ähnliche Dateien anpassen muß ist mir auch noch unklar. Von Hand ist ja viel zu viel, und wie ich das mit depmod für eine initrd machen soll ist mir nicht klar.
Gruß Torben
* Torben Schultz wrote on Wed, Jan 25, 2006 at 02:45 +0100:
Boote die initrd doch mal an Deinem lokalen System, .... Der Server ist ein 64bit System und sowas hab ich hier nicht.
Schlecht! Dann mach doch ein 32bit Mini-Rettungssystem drauf. Wenn das bootet und Du via KVM/Netzwerk an die Console (LILO/Grub) kommst, kannste dann lokal booten, ohne das jemand ne CD einlegen muss - oder?
Aber ich hab den Weg einfach mal bei mir zuhause ausprobiert. Das klappte, nur haben da die beiden "Vorlage" initrds eine fast gleiche Struktur (und Dateien). Bei den beiden initrds für den Server ist alles unterhalb "lib/" völlig anders. Und es gibt bei der SuSE-Vorlage ein "lib64/" und bei der anderen nicht. Da muß ich jetzt weiter dran arbeiten (aber nicht mehr heute nacht). Ich befürchte auch, dass ich noch einige zusätzliche Module mit aufnehmen - noch überblicke ich die ganzen Unterschiede nicht.
Ja, das kann schnell ne Wissenschaft werden.
Und wie ich die ganzen modules.conf und Ähnliche Dateien anpassen muß ist mir auch noch unklar. Von Hand ist ja viel zu viel, und wie ich das mit depmod für eine initrd machen soll ist mir nicht klar.
Am besten gar nicht, oder? Werden initrd Module normalerweise nicht direkt geladen? Na ja, ein modprobe und autoloading in initrd's würde mich heut auch nicht mehr überraschen. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo Torben, hallo Leute, Am Mittwoch, 25. Januar 2006 00:35 schrieb Torben Schultz: [...]
Deswegen hab ich es als root gemacht, aber ich weiß nicht ob ich das dann beim wieder packen auch richtig gemacht habe. Ich hab das so gepackt: find ./initrd_neu/ -depth | cpio -o > ./initrd-2.6.15-install-v1
find liefert in diesem Fall Pfade, die initrd_neu vorangestellt haben - und das ist wohl nicht das, was Du willst ;-) Vermutlich liegt alles in Deiner initrd im Verzeichnis initrd_neu/... Wechsle ins Verzeichnis initrd_neu und probiers nochmal ;-) Gruß Christian Boltz -- CUPS is great when it works, impossible when it doesn't, and configuration using the CUPS tools is illegal in locations where extreme profanity is a crime. [Jeffrey L. Taylor]
Hallo Christian, hallo Leute, Am Do, 2006-01-26 um 19.31 schrieb Christian Boltz:
find liefert in diesem Fall Pfade, die initrd_neu vorangestellt haben - und das ist wohl nicht das, was Du willst ;-) Vermutlich liegt alles in Deiner initrd im Verzeichnis initrd_neu/... Wechsle ins Verzeichnis initrd_neu und probiers nochmal ;-) Du hast recht, das Problem hatte ich - hab ich aber schon gemerkt und Abgeändert gehabt (und dann eben vergessen mal irgendwo in der Diskussion zu erwähnen). Ich bekomme inzwischen schon ne lauffähige initrd zusammen - aber eben leider ohne die für die Installation benötigten "Zusätze". Ich hab auch schon mal versucht im Developer Bereich zu suchen, denn da muss doch eigendlich Documentiert sein, wie ich die "Installations-Initrd" baue, aber ich finde da nichts. Weiß vielleicht jemand, ob sich mein Problem erledigt, wenn ich nen "Build Server" aufsetze? Also nach dieser Anleitung: http://www.opensuse.org/How_to_setup_a_build_server Ich verspreche mir davon eigendlich wenig, und vor allem kann ich es nicht mal eben Ausprobieren, weil ich erstmal den Platz schaffen müßte (und der ganze Download ja auch nicht gerade schnell geht).
Trotzenm Danke Gruß Torben
Torben Schultz wrote:
[...] Ich bekomme inzwischen schon ne lauffähige initrd zusammen - aber eben leider ohne die für die Installation benötigten "Zusätze". Ich hab auch schon mal versucht im Developer Bereich zu suchen, denn da muss doch eigendlich Documentiert sein, wie ich die "Installations-Initrd" baue, aber ich finde da nichts.
Ich habe bisher in diesem Thread nicht geantwortet, weil ich schlicht von Anfang an nicht verstanden habe, wo eigentlich Dein Problem liegt und um was es eigentlich genau geht. Aber egal, das liegt vielleicht auch an mir. Daher hier nur kurz eine Anregung: schaue Dir die Datei mkinitrd an, das ist lediglich ein Skript, dort siehst Du, wie eine initrd gebaut wird. Gegebenenfalls musst Du halt dieses Skript anpassen oder Dir ein eigenes schreiben. Allerdings gehoeren IMO Aenderungen an mkinitrd schon eher zu den selten (bis nie) benoetigten Sachen fuer einen Endanwender... Cheers, Th.
Hallo zusammen, also ich hab es jetzt mit Euer aller Hilfe geschafft, dass ich zuverlässig eine eigne initrd zusammenbauen kann - auch eine die alle benötigten Module/Scripte/Programme für die Installation enthält. Den Weg dafür hab ich mal für Intressierte unten dran gehangen. NUR jetzt hab ich noch ein Problem das von mir benötigte Modul sata_sis richtig zu Patchen / bauen :( Aber der Reihe nach: Zu dem richtigen "bauen der initrd" bin ich durch den Tipp von Thomas (in mkinitrd schauen) gekommen - Danke! Und Entschuldigung Steffen - war wirklich ein Versehen, dass ich einmal nur an dich geantwortet habe. Also das Rettungssystem (Ubuntu) kann ich über ein Webinterface beim Provider starten, die anderen (lokalen) Kernel wähle ich mit "grubonce" aus. So jetzt zum neuen Problem: Ich habe das Modul sata_sis.ko ja Patchen müssen, wenn ich das jetzt laden will kommt folgende Meldung: inst-sys:~ # modprobe sata_sis FATAL: Error inserting sata_sis (/lib/modules/2.6.13-15-default/updates/initrd/sata_sis.ko): Invalid module format Ich hab gefunden, dass es was mit falschen Headern zu tun haben könnte/muss. Ich hab das Modul wie Folgt gebaut: - Kernelquellen für 2.6.13-15 von suse installiert - die config in die Quellen Kopiert: cp /boot/config-2.6.13-15-default /usr/src/linux-2.6.13-15/config - in das Verzeichnis /usr/src/linux-2.6.13-15/drivers/scsi/ gewechselt - den von Rainer geschickten Patch so installiert: cat /root/software/sata_sis.patch | patch -p0 (Kann hier der Fehler in der Anwendung des Patches liegen?) - ins Verzeichnis /usr/src/linux-2.6.13.15 und "make modules" gemacht Danach hatte ich ein "neues" sata_sis.ko Modul, mit "strings" gab es mir u.A. diese Zeile aus: vermagic=2.6.13-15-default 586 REGPARM gcc-4.0 Die "orginal" Zeile des ungepatchten Moduls aus der heruntergeladenen initrd ist: vermagic=2.6.13-15-default gcc-4.0 Jemand einen Tipp wie ich das Modul richtig Patche, so dass es dann past? Und eine hoffentlich nicht zu blöde Frage: Wie kann ich nur dies eine Modul erstellen? (bei meinem weg werden ja immer alle Module gebaut) Gruß Torben ============= Weg wie ich meine initrd für eine _Installation_ zusammengebaut habe: 1) "Passende Orginal" (für mich die initrd64) initrd Runterladen und Entpacken: lampe:~/software/initrd # mkdir initrd64-uni-erlangen-final lampe:~/software/initrd # wget -O initrd64-uni-erlangen-final.gz ftp://ftp.uni-erlangen.de/pub/mirrors/opensuse/distribution/SL-10.0-OSS/inst-source/boot/loader/initrd64 lampe:~/software/initrd # gunzip -c initrd64-uni-erlangen-final.gz > initrd64-uni-erlangen-final.cpio lampe:~/software/initrd # cd initrd64-uni-erlangen-final/ lampe:~/software/initrd/initrd64-uni-erlangen-final # cpio -idv < ../initrd64-uni-erlangen-final.cpio 2) Module wie gewünscht Löschen/Hinzufühgen/ersetzen (bei mir nur sata_sis ersetzt): lampe:~/software/initrd/initrd64-uni-erlangen-final # cp /usr/src/linux/drivers/scsi/sata_sis.ko ./lib/modules/2.6.13-override-default/initrd/sata_sis.ko 3) initrd neu zusammensetzen (da waren bisher 2 Fehler drinne): lampe:~/software/initrd/initrd64-uni-erlangen-final # find . ! -name "*~" | cpio -H newc --create | gzip -9 > ../initrd64-uni-erlangen-final-out.gz 4) Danach wie in der NetzInstallationsdocu: http://www.opensuse.org/Network_Install den grub einrichten - natürlich mit der eigenen initrd! Und dran denken "grubonce [NR]" ist sehr vorteilhaft!
Torben Schultz wrote:
[...] Ich hab das Modul wie Folgt gebaut: - Kernelquellen für 2.6.13-15 von suse installiert
Falls Du den Kernel via YOU bereits aktualisiert hast, musst Du nach dem Einspielen der Kernel-Sourcen noch einmal YOU aufrufen, damit auch die Quellen des Kernels aktualisiert werden koennen! Ansonsten passen die Kernel-Quellen nicht zum laufenden Kernel. Aktuell ist bei SuSE 10 AFAIK 2.6.13-15.7.
- die config in die Quellen Kopiert: cp /boot/config-2.6.13-15-default /usr/src/linux-2.6.13-15/config
Bei SuSE funktioniert in dem Falle ein einfaches "make cloneconfig" im Kernel-Source-Tree. Danach (auch bei Deinem Vorgehen) solltest/musst Du ein "make prepare-all" eingeben - dadurch wird der Kernel-Source-Tree fuer das Compilieren (externer) Kernel-Module vorbereitet. Bei aktuellem SuSE Kernel incl. Updates muesste es eigentlich die Datei config-2.6.13-15.7-default sein, die Du kopieren musst. Aber, wie gesagt, ein "make cloneconfig && make prepare-all" duerfte einfacher sein (vorausgesetzt, der Kernel, dessen Source Du konfigurieren willst, laeuft auch).
- in das Verzeichnis /usr/src/linux-2.6.13-15/drivers/scsi/ gewechselt - den von Rainer geschickten Patch so installiert: cat /root/software/sata_sis.patch | patch -p0 (Kann hier der Fehler in der Anwendung des Patches liegen?)
Das Programm "patch" sollte Dir sagen, ob der Patch erfolgreich war oder nicht. Am besten logst Du die Ausgabe in einer Datei mit und schaust Dir diese Datei nach dem Patchen genau auf Fehler an. Bsp: patch -p0 < sata_sis.patch 2>&1 | tee patch.log Dein "cat" ist unnoetig, da der Patch unkomprimiert ist und patch selbst direkt von stdin lesen kann.
- ins Verzeichnis /usr/src/linux-2.6.13.15 und "make modules" gemacht
Das ist ein wenig "overkill", siehe unten...
[...] Und eine hoffentlich nicht zu blöde Frage: Wie kann ich nur dies eine Modul erstellen? (bei meinem weg werden ja immer alle Module gebaut)
Kernel-Source-Tree, "make help": [...] other generic targets: [...] dir/ - Build all files in dir and below dir/file.[ois] - Build specified target only dir/file.ko - Build module including final link [...] Cheers, Th.
Hallo, Am So, 2006-01-29 um 15.19 schrieb Thomas Hertweck:
Falls Du den Kernel via YOU bereits aktualisiert hast, musst Du nach dem Einspielen der Kernel-Sourcen noch einmal YOU aufrufen, damit auch die Quellen des Kernels aktualisiert werden koennen! Da ich das Modul ja für den "Installationskernel" Bauen muss, sind die Quellen des 2.6.13-15 schon richtig: inst-sys:~ # uname -a Linux 10.20.30.40 2.6.13-15-default #1 Tue Sep 13 14:56:15 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux
Danach (auch bei Deinem Vorgehen) solltest/musst Du ein "make prepare-all" eingeben - dadurch wird der Kernel-Source-Tree fuer das Compilieren (externer) Kernel-Module vorbereitet. Hab ich jetzt mal gemacht, der Fehler bleibt aber der gleiche. Ich hab auch mal versucht erst "make oldconfig" (was ja aber wohl Sinnlos sein müßte) und dann "make prepare-all". Alles natürlich immer mit "sauberen" Quellen.
Aber, wie gesagt, ein "make cloneconfig && make prepare-all" duerfte einfacher sein (vorausgesetzt, der Kernel, dessen Source Du konfigurieren willst, laeuft auch). Da ist wohl leider der Haken, wenn der Kernel läuft, hab ich ja keine Festplatten die erkannt werden - also scheidet cloneconfig aus :(
patch -p0 < sata_sis.patch 2>&1 | tee patch.log Also der Patch meldet keine Fehler, das ist ja schon mal was.
Dein "cat" ist unnoetig, ... Oh ja - ich weiß - ich bin ein Kandidat für den "Useless Use of cat Award" ;-)
Und eine hoffentlich nicht zu blöde Frage: Wie kann ich nur dies eine Modul erstellen? (bei meinem weg werden ja immer alle Module gebaut) Kernel-Source-Tree, "make help": [...] other generic targets: [...] dir/ - Build all files in dir and below dir/file.[ois] - Build specified target only dir/file.ko - Build module including final link [...] Super, das spart schon mal einiges an Zeit.
Ich befürchte es wird mir nicht gelingen, das Modul exakt auf den Kernel abzustimmen - dafür fehlt mir wohl das "config" File, was für den "Installationskernel" (boot/loaders/linux64) verwendet wurde. Oder besser gesagt: Ich bin noch nicht so weit um den "Nach zu bauen" Ich werd wohl die Tage nochmal einen Anlauf machen den gesammten Installationskernel und initrd dazu zu bauen. Danke und Gruß Torben
Torben Schultz
Das Problem ist, dass die Kernel und initrd, die unter boot/loader/ zu finden sind, auf dem Zielserver nur "halb" laufen, sprich sie booten, ich kann per ssh connecten und auch (sinnloserweise) Yast starten. ABER die Festplatten werden nicht erkannt, und somit kann ich nirgens hin installieren.
Es scheint so zu sein, dass wegen der Hardware ein Kernel größer 2.6.14 installiert sein muß. Vermutlich liegt es an dem Fehlenden Modul sata_sis.
AMD-System mit SiS965L Southbridge. SATA-Controller mit PCI-ID 1039:0182? Hier ist ein Patch für das sata_sis modul im original SUSE 10.0-Kernel: Wenn Du also auf einer anderen Maschine den Kernel compilieren kannst und die initrd erzeugen kannst (evtl. mußt du im YAST auch noch konfigurieren, daß das sata_sis-modul in die initrd rein muß), dann sollte es damit klappen. Der Patch ist ein Backport von 2.6.14 auf den SUSE-Kernel 2.6.13-15-default. HTH Rainer -- Dipl.-Inf. (FH) Rainer Koenig Project Manager Linux Business Clients Fujitsu Siemens Computers VP BC E SW OS Phone: +49-821-804-3321 Fax: +49-821-804-2131
Hallo zusammen, auch wenn der bisherige Weg sicher der richtige ist - ich bekomme es so nicht hin :( Aber ich scheine jetzt doch eine Möglichkeit über ein Update gefunden zu haben. Aber mal der Reihe nach: Aus meinem eigenen Kernel/Initrd und der "Installations-Vorlage" eine initrd zusammen zu bauen schlägt immer fehl. Die Struktur von "lib/" und "lib64/" bekomme ich nicht zusammen. Manipuliere ich auf diesem Weg nur meine eigene initrd klappt das. Dann zu dem Patch: Am Mi, 2006-01-25 um 07.49 schrieb Rainer Koenig:
AMD-System mit SiS965L Southbridge. SATA-Controller mit PCI-ID 1039:0182? So ziemlich, die SATA PCI-ID stimmt, zur Southbrige hat mir hwinfo nichts ausgespuckt. Es ist auf jeden Fall ein FuSi Server.
Hier ist ein Patch für das sata_sis modul im original SUSE 10.0-Kernel: [...] Wenn Du also auf einer anderen Maschine den Kernel compilieren kannst und die initrd erzeugen kannst [...] Also dass wäre mir ja die liebste und eleganteste Lösung, aber ich bin schon an den Richtigen Quellen für den SuSE-Kernel gescheitert. Hab es z.B. mit diesem Paket versucht: ftp://ftp.uni-erlangen.de/pub/mirrors/opensuse/distribution/SL-10.0-OSS/inst-source/suse/x86_64/kernel-source-2.6.13-15.x86_64.rpm oder den hier: ftp://ftp.uni-erlangen.de/pub/mirrors/opensuse/distribution/SL-10.0-OSS/inst-source/suse/src/kernel-source-2.6.13-15.src.rpm Aber das scheinen beides die völlig falschen Packete zu sein. Also hab ich es mit den Quellen von kernel.org Probiert, aber damit hatte ich dann sofort das gleiche "Strukturdurcheinander" wie schon oben beschrieben. Weiß jemand welches SuSE-Paket ich dafür nehmen muß? Oder hat jemand das gepatchte Modul einzelnd - dann müßte ich dass doch in die initrd mit einbauen können.
Und zu guter letzt, da ich einfach nicht weiterkam hab ich nochmals den Weg eines Updates versucht - und diesmal klappte das (so halbwegs). Ich hab erst die linuxrc von SuSE10.0 installiert (und entsprechend div. andere Pakete), und danach über Yast "System-Update". Danach nur die grub menu.lst wieder auf den eigenen Kernel umgestellt und es lief. Eigendlich hatte ich das ganz am Anfang schon mal so gemacht, aber da hat das Update immer abgebrochen. Keine Ahnung was jetzt anders war. Nur trotzdem hätte ich lieber eine Neuinstallation, denn ein wenig "Unsauber" scheint das System so zu sein. Jede Menge unaufgelöste Abhängigkeiten die ich gerade versuche von Hand zu beseitigen. Und es ist eigendlich eine Minimal-Nur-Textinstallation, hat aber fast 3,5GB ohne die Backupfiles, die unter /var/ liegen. Die ganzen Reste hätte ich natürlich gerne noch weg. Also schon mal vielen Dank an alle, wenn jemand noch Ideen hat, immer her damit. Gruß Torben
participants (5)
-
Christian Boltz -
Rainer Koenig -
Steffen Dettmer -
Thomas Hertweck -
Torben Schultz