[Solaris x86] Kernel bootet nicht

[Harleckin]

Jemand anwesend der sich "etwas" mit Solaris auskennt?

Folgendes Problem.. hab 'ne alte x86 SMP Gurke, die mit Sol10u1 problemlos läuft => Kernel Patchlevel 118844-23.

Sie dient seit längeren als SamFS Testumgebung. Hab zuletzt den Kernel auf die rev-36 aktualisiert. Das Updateprozedere ging ohne weiteres über die Bühne.

Nun steh ich vor dem Delima das er beim Booten den IDE-Controller (ICH2/PIIX) nicht initialisieren kann und somit einfriert.

Ohne den IDE-Controller kann ich leben, da alles an den beiden SCSI Channels des Adaptec Controllers hängt.
Also wenn sich jemand damit auskennt wie man die Modules-Ramdisk vom Kernel bearbeiten kann, um das fehlerhafte Modul zu deaktivieren, solle sich bitte jetzt melden.

Ach, und das BIOS bietet leider nicht die Möglichkeit den Controller zu deaktivieren. Fabelhaft.


failed to prgramm IO space [0/7/2] Bar@0x20 length 0x20


Den Patch zu entfernen und ein Rollback zu fahren ist zwar etwas tricky, aber darin besteht ja nicht meine Absicht. Es sollte die aktuelle Kernelbuild laufen, daher würde ich gerne das Modul deaktivieren.

[sun-man]

Hi,

schick mir mal die Fehlermeldungen bitte. Ich kann auch erstmal nur nachschaun was los ist und ob ich was finde.

Die SUN's kann man auch über CD/DVD booten, chroot setzen udn den Kernelpatch (oder irgendeinen anderen) wieder entfernen. Hab ich mal vor 3-4 Jahren gebraucht, sonst nie.

MFG

[TheGamer]

Hi,

schick mir mal die Fehlermeldungen bitte. Ich kann auch erstmal nur nachschaun was los ist und ob ich was finde.

Die SUN's kann man auch über CD/DVD booten, chroot setzen udn den Kernelpatch (oder irgendeinen anderen) wieder entfernen. Hab ich mal vor 3-4 Jahren gebraucht, sonst nie.

MFG


JO harleckin lass sun-man das Porblem lösen, der Mann sitzt an der Quelle :)

[sun-man]

Hi,

also lösen kann ich hier erstmal gar nix ;). Ich kann nur erstmal suchen. wir haben zwar x86 Büchsen die rennen wie die sau, aber die laufen auch nach den Patches noch ;).
Anyway: Ich bin leider noch am Flughafen und sitze im RZ fest und komme nicht an die internen sachen ran. Ich melde mich falls ich was finde, falls nicht auch.

Hast Du mal bei Bigadmin geschaut? Kleiner großer Tip: www.sonnenblen.de - die könnten fast schneller als ich sein ;)

MFG

[Harleckin]

Gut, ich arbeite seit Jahren mit Solaris und ansonsten sind wir direkter Sun Partner. Also bei zertifizierten x86/sparc Büchsen kam mir dies noch nie unter. Was solls, ich werd mal schauen was sich finden lässt.
Erstmal danke.

[sun-man]

Hi,

dann solltest Du Dir trotzdem überlegen auf u3 zu gehen. u1 wird auch für Kunden nicht mehr empfohlen da div. Updates in u3 eingeflossen sind.
Sicherheitshalber gefragt: Den reconfigure reboot hast Du gemacht? Was ist mit den req. Patchen? Auch eingespielt?
außerdem könnte es helfen auf -35 zu gehen.

Falls Du eine Lösung hast wie man solche Module ausschaltet sag mir bitte Bescheid. Ich hocke noch immer fest.

Update:

Hilft das?
http://www.sun.com/bigadmin/features/articles/grub_boot_solaris.html
4.3 Boot Archive

The boot archive refers to the file platform/i86pc/boot_archive. It is a collection of core kernel modules and configuration files packed in either UFS or ISOFS format. At boot time, GRUB loads the boot archive into system memory. The kernel can now initialize itself from data and text in the boot archive without performing I/O to the root device. Once the kernel gains sufficient I/O capability, it will mount the root file system on the real root device as specified by the bootpath property. At this point, the boot archive loaded by GRUB is discarded from memory.

The content of the boot archive is specified in /boot/solaris/filelist.ramdisk. Upon system shutdown, the system checks for updates to the root file system and updates the boot archive when necessary. The system may manually update the boot archive prior to system shutdown by running the bootadm(1M) command.

4.4 The Failsafe Menu Entry

New to the Solaris 10 1/06 OS is a file, /boot/x86.miniroot-safe, containing a bootable, standalone Solaris image. This file can be loaded by choosing the Solaris failsafe entry from the GRUB menu. This is for the convenience of system administrators when the normal entry fails to boot.

Suppose you add a new package containing a faulty driver, and the system panics at boot time. Upon reboot, you can pick the Solaris failsafe menu entry. While in the failsafe session, mount the root file system on /a and run pkgrm -R to remove the faulty package. Once this is complete, you can reboot to the normal Solaris entry to resume system operation.

The file /boot/x86.miniroot-safe can also be copied to portable media, such as a USB stick, as a recovery tool.

usw usw usw

[Harleckin]

Den Artikel kenn ich bestens. War damals beim Update auf U1 eine ziemliche Arbeit "grub" zum Laufen zu bewegen. Da lob ich mir den OPB auf Sparc.

Zum debuggen kann man die Parameter "-kv" dem Kernel übergeben. Werd mich später daran versuchen das boot archive zu präparieren.

Ach und U3 nutzen wir natürlich ansonsten. Nur eben bei dieser alten Dose zickt der Kernel unerwartet herum. Zur Vollständigkeit, Tests mit U2 brachten das gleiche Ergebnis.

[sun-man]

Hi,

also ich finde da jetzt nicht so irre viel dazu, eigentlich gar nichts.
Aber diese filelist.ramdisk scheint eine Textdatei zu sein, zumindest kann man echos umleiten (hab ein Cluster x86 Prob gefunden bei dem man sowa smachen sollte) - da heisst dort steht halt Klartext drinne. Nach änderungen "bootadm update-archive" ausführen.
Ich hab zwar Sol10 auf dem Schlepptop, kann da aber auch gerade nicht ran.

MFG

[Harleckin]

Also folgender Sachstand..

a.) ich hab mir ein eigenes "boot_archive" gebastelt (gzip, lofiadm, mkisofs)
b.) alle ide/ata module entfernt
c.) default kernel 118844-23 bootet wunderbar ohne die module
d.) patched kernel 118855-36 kommt weiterhin die gleiche Fehlermeldung

hmm, die Fehlermeldung prangert doch eindeutig das Gerät am Bus 0, Lun 7, Target 2 an oder interpretiere ich dies falsch?!

failed to prgramm IO space [0/7/2] Bar@0x20 length 0x20


Wahrscheinlich liegt das Problem an einen anderen Device. :/

Ach übrigens, wie kann man per chroot() ein 'patchrm' nutzen. Programme wie 'showrev -p' coredump'en, wahrscheinlich weil noch ein paar Objekte (libc, /proc, ctfs, objfs) gemountet werden müssen.
Und zu guter letzt befindet sich das Rootdevice (s0) in einem md-raid0 Verbund. Alles nicht ohne, aber genau für solche Fälle gibt es ja Testmaschinen.

[sun-man]

bus - device - function, so wird das gesehen und mehr als die -kv Bootoption kann ich auch nicht bieten.
Ansonsten war das afar root/var und usr mounten und dann patchrm -R /a/ patch - sollte eigentlich funzen. Mit "md" meinst Du sicherlich SDS oder Solaris Volume Manager (svm), sprich mit metadbs und Co.

MFG

[Harleckin]

na klar, 'patchrm -R (..)' hätte ich ja wissen müssen. Werd ich im Laufe der der Woche durch führen.
Ansonsten 'prtconf -v' sagt nicht wirklich etwas über das Device 0,7,2 aus. strange. :/

(bei Gelegenheit poste ich die Ausgabe)

[Harleckin]

[..]
Programme wie 'showrev -p' coredump'en, wahrscheinlich weil noch ein paar Objekte (libc, /proc, ctfs, objfs) gemountet werden müssen.
[..]

sun-man,
falls es interessiert "124631-03" löst das 'showrev' Problem. Klar im Recommended Patchcluster ist es enthalten, aber das wäre ja zu einfach.

[sun-man]

Ohje...Note 58. Nunja, die blöden KJPs eben. Wobei ich entweder über EIS oder tLP eben immer die recommended einspiele weil deren Abhängigkeiten doch größer sind.
Solltest Du nen Explorer haben kann ich auch gerne mal ne Auswertung fahren ob irgendwas anderes nicht so stimmt.

[sun-man]

und? Hast Du es hinbekommen?

Im übrigen soll man nach dem -36 Kernel ein reboot -r durchführen, andere Patche scheinen sonst nicht mehr ins System zu laufen.

MFG

[Gast]

probier doch mal Windows
da gibts so probleme nicht

[Harleckin]

Bei der Geräteadresse 0,7,2 handelt es sich um den USB Controller. Nun ja, wenn ich das Modul entferne bootet der Kernel (build 36) wie gehabt.
Also im Moment läuft es erstmal wunderbar.