I have a v20z to which I applied the latest maintenance patches. After a
rebbot, it sits there n a loop with the messages:

----
/kernel/drv/amd64/sad: undefined symbol 'netstack_find_by_cred'
/kernel/drv/amd64/sad: undefined symbol 'netstack_rele'
WARNING: mod_load: cannot load module 'sad'

panic[cpu0]/thread=fffffffffbc22dc0: mod_hold_stub: Couldn't load stub
module drv/sad
----

I assume I need to do the equivalent of a "boot -r" but how?

Any ideas? The system is located in a co-lo quite a distance away, and
although I can access the SP, I don't seem to be able to get to the GRUB
menu.

Many thanks for any help

--

Sak Wathanasin
Network Analysis Limited
http://www.network-analysis.ltd.uk

"Sak Wathanasin" <sw@network-analysis.ltd.uk> wrote in message
news:sw-C5C04C.14310926052008@newshost...
> I have a v20z to which I applied the latest maintenance patches. After a
> rebbot, it sits there n a loop with the messages:
>
> ----
> /kernel/drv/amd64/sad: undefined symbol 'netstack_find_by_cred'
> /kernel/drv/amd64/sad: undefined symbol 'netstack_rele'
> WARNING: mod_load: cannot load module 'sad'
>
> panic[cpu0]/thread=fffffffffbc22dc0: mod_hold_stub: Couldn't load stub
> module drv/sad
> ----
>
> I assume I need to do the equivalent of a "boot -r" but how?
>
> Any ideas? The system is located in a co-lo quite a distance away, and
> although I can access the SP, I don't seem to be able to get to the GRUB
> menu.
>
> Many thanks for any help

Here's all I could find:

http://bugs.opensolaris.org/view_bug.do?bug_id=6582327

Hopefully you can figure out how to boot off the DVD-ROM.
According to the bug it's probably an out-of-sync boot archive.

Trinean

Sak Wathanasin <sw@network-analysis.ltd.uk> wrote:

> Any ideas? The system is located in a co-lo quite a distance away, and
> although I can access the SP, I don't seem to be able to get to the GRUB
> menu.

Only idea I have is pack a lunch and make the trip to the co-lo facility.

If the SP in the v20z has any more usefulness than powering the machine up
and down, I don't know what it is. Even if you followed all the
not-well-documented bios and eeprom changes to redirect the console to the
SP, when the machine can't boot like this, you really need to get in front
of it with a keyboard and monitor.

I don't know what genius at Sun (or whoever designed that thing) thought
using function keys (F2, F5, F10) and arrow keys to enter/exit/move around
in menus during the power up/boot sequence was, but I hope they are working
for Best Buy these days. (that joke applies to U.S. residents only)

I'm assuming you know about the:

ssh -l SPadmin ipaddress platform console

bit to get on the machines console over ssh, if this is where you are stuck
from going or doing anything else, good luck, is the normal brickwall.

-bruce
bje@ripco.com

In article <PKSdnY_rBtAJjabVnZ2dnUVZ_j-dnZ2d@cavtel.net>,
"Trinean" <trinean@yahoo.com> wrote:

> Here's all I could find:
>
> http://bugs.opensolaris.org/view_bug.do?bug_id=6582327
>
> Hopefully you can figure out how to boot off the DVD-ROM.
> According to the bug it's probably an out-of-sync boot archive.

Thanks for that: it's pretty helpful and gives me a plan of attack once I
get the v20z booted. It will require a trip to the co-lo but I should be
able to boot into "safe mode" from GRUB.

I think it was patch 120012 (-14 in my case) that did for me too.

--

Sak Wathanasin
Network Analysis Limited
http://www.network-analysis.ltd.uk

In article <g1h2tc$kge$1@e250.ripco.com>,
Bruce Esquibel <bje@e4500.ripco.com> wrote:

> Only idea I have is pack a lunch and make the trip to the co-lo facility.

Yeah, I'm pretty much resigned to having to do this. Right up to the point I
installed Solaris 10/6, I had the BIOS redirected to the serial-over-LAN,
and thence via the SP to my ssh session. But after I installed the GRUB
updates, I couldn't get the BIOS talking to the S-o-L anymore, though once
Solaris started to boot, console redirection worked fine.

If I had control of GRUB, I could have booted into "safe mode" and tried to
recover from there, which is my plan when I get to the co-lo. Once I
resurrect the v20z, I'll have another go at redirecting GRUB to the S-o-L.
Failing thatl I guess I'll have to invest in one of these KVM-over-IP
thingies, which would be particularly annoying since one of the selling
points of the v20z/v40z was that you didn't need one of these or a terminal
server.

Thanks for responding.

--

Sak Wathanasin
Network Analysis Limited
http://www.network-analysis.ltd.uk

In article <PKSdnY_rBtAJjabVnZ2dnUVZ_j-dnZ2d@cavtel.net>,
"Trinean" <trinean@yahoo.com> wrote:

> Here's all I could find:
>
> http://bugs.opensolaris.org/view_bug.do?bug_id=6582327
>
> Hopefully you can figure out how to boot off the DVD-ROM.
> According to the bug it's probably an out-of-sync boot archive.

Many thanks to you & Bruce for your responses. I got to the co-lo and booted
into "failsafe", and as described in the above, it detected the "out of
sync" boot archive and offered to repair it. Once done, it was able to boot
the std kernel and I applied the latest patch cluster for good measure.

I was also able to redirect the BIOS to the s-o-l. Not sure why I lost it,
but it may have been one of the BIOS updates. Anyway, hit F2 on boot, go to
the "Advanced" menu, go to "Console redirection" and redirect to ttya,
making sure the line speed &c match the settings those of the SP's "platform
get console" command.

You also need to edit the grub menu and add console redirection to the
"failsafe" entry, otherwise once you boot the "failsafe" kernel, the console
reverts to system console and you won't be able to control it remotely. To
do this, append

-B console=ttya,ttya-mode="115200,8,n,1,-"

to the line starting "kernel" in the failsafe entry. Mine looks like this:
---
title Solaris failsafe
root (hd0,1,a)
kernel /boot/multiboot kernel/unix -s -B
console=ttya,ttya-mode="115200,8,n,1,-"
module /boot/x86.miniroot-safe
---

You don't need to do this to the main netry (for booting the normal kernel)
if you followed the instructions for redirecting the console using the
"eeprom" cmd (but I don't think it hurts).

With the above in place you should have full control over the booting
process via an ssh session to the SP, including remote selection of the
failsafe option, and then accessing the console to effect any repairs.

Here's hoping that I won't have to use this again.

--

Sak Wathanasin
Network Analysis Limited
http://www.network-analysis.ltd.uk