Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

booting standalone under Solaris

0 views
Skip to first unread message

Scott D. Anderson

unread,
Jul 23, 1996, 3:00:00 AM7/23/96
to

I'm not a sysadmin; I don't even play one on TV. However, I have a
workstation and I need to do some sysadmin-like changes. I do have the
root password to my workstation, but not to any of the other systems on
our LAN. I've done some homework (read Frisch's "Essential System
Administration" and Stern's "Managing NFS and NIS" and many man pages),
but I still have some questions, and I hope someone will help me with
them. The main question involves being able to successfully boot *either*
networked or standalone (without access to network machines, particularly
NIS/NFS servers). The rest of this message is the few details I've worked
out.

My machine, Ashe, is a SPARC 20 running Solaris. How do I find out what
version of Solaris? Here is what "uname -a" returns:

SunOS ashe 5.4 Generic_101945-34 sun4m sparc

Ashe is an NFS client to the main NFS server of our LAN, which I'll call
Ethel. Ethel is, at best, overloaded, and is frequently out of service.
My goal is to get Ashe to stand on its own two feet as much as possible,
so that when Ethel is down, I'll be okay. The first problem I have is
that Ashe doesn't boot when its network connection is broken. To be
precise, it starts to boot and then gets stuck. I have looked at the boot
logs and haven't been able to tell exactly where (what boot script) it
gets stuck.

I'm testing this by disconnecting Ashe from the network and attempting to
boot it. Is that a reasonable way to test its ability to boot standalone?

I had a hypothesis that the boot problem is that the NFS mount is failing
because the network connection is broken, and so it's not really getting
stuck, it's just waiting forever for the NFS mount (well, not forever,
just for 100000 tries). The filesystems that are being mounted are
/usr/local and /var/spool/mail, neither of which I would think are
essential for booting. Is that right? I thought the fix for this would
be to change the /etc/vfstab file to mount those filesystems in
background, but it didn't work.

The last lines of the log during the unsuccessful boot are as follows.
I'm not surprised at the "no carrier" complaint, but I don't know why that
stops the booting.

Jul 23 14:27:48 ashe unix: le0 at ledma0: SBus slot f 0xc00000 sparc ipl 6
Jul 23 14:27:48 ashe unix: le0 is /iommu@f,e0000000/sbus@f,e0001000/ledma@f,400010/le@f,c00000
Jul 23 14:27:48 ashe unix: dump on /dev/dsk/c0t3d0s6 size 262188K
Jul 23 14:27:48 ashe unix: le0: No carrier - cable disconnected or hub link test disabled?
Jul 23 14:27:48 ashe unix: le0: No carrier - cable disconnected or hub link test disabled?

The last lines from the successful boot are:

Jul 23 14:27:51 ashe unix: le0 at ledma0: SBus slot f 0xc00000 sparc ipl 6
Jul 23 14:27:51 ashe unix: le0 is /iommu@f,e0000000/sbus@f,e0001000/ledma@f,400010/le@f,c00000
Jul 23 14:27:51 ashe unix: dump on /dev/dsk/c0t3d0s6 size 262188K
Jul 23 14:28:01 ashe unix: pseudo-device: vol0
Jul 23 14:28:01 ashe unix: vol0 is /pseudo/vol@0
Jul 23 14:28:03 ashe unix: SUNW,fdtwo0 at obio0
Jul 23 14:28:03 ashe unix: :
Jul 23 14:28:03 ashe unix: obio 0x700000
Jul 23 14:28:03 ashe unix:
Jul 23 14:28:03 ashe unix: sparc ipl 11
Jul 23 14:28:04 ashe unix: SUNW,fdtwo0 is /obio/SUNW,fdtwo@0,700000

Main Question: Why is the standalone boot failing and how can I fix it?

By the way, earlier in both boot logs, I see the following stream of
messages. What do they mean? Are they bad?

Jul 20 21:25:45 ashe unix: Unable to install/attach driver 'vme'
Jul 20 21:25:45 ashe unix: Unable to install/attach driver 'mcp'
Jul 20 21:25:45 ashe unix: Unable to install/attach driver 'mcpzsa'
Jul 20 21:25:45 ashe unix: Unable to install/attach driver 'vme'
Jul 20 21:25:45 ashe unix: Unable to install/attach driver 'mcp'
Jul 20 21:25:45 ashe unix: Unable to install/attach driver 'mcpzsa'
Jul 20 21:25:45 ashe unix: Unable to install/attach driver 'stc'

I suppose that's more than enough bandwidth for now. Thanks for reading
this far. I hope you'll help.


--
Scott D. Anderson
Spelman College
ande...@auc.edu
--
Scott D. Anderson
Spelman College
ande...@auc.edu

Brian D. Stevens

unread,
Jul 24, 1996, 3:00:00 AM7/24/96
to

Scott D. Anderson (ande...@lindy.cs.umass.edu) wrote:
: I'm not a sysadmin; I don't even play one on TV. However, I have a

Well, I do pretend to be one!

: workstation and I need to do some sysadmin-like changes. I do have the


: root password to my workstation, but not to any of the other systems on
: our LAN. I've done some homework (read Frisch's "Essential System
: Administration" and Stern's "Managing NFS and NIS" and many man pages),
: but I still have some questions, and I hope someone will help me with
: them. The main question involves being able to successfully boot *either*
: networked or standalone (without access to network machines, particularly
: NIS/NFS servers). The rest of this message is the few details I've worked
: out.

: My machine, Ashe, is a SPARC 20 running Solaris. How do I find out what
: version of Solaris? Here is what "uname -a" returns:

: SunOS ashe 5.4 Generic_101945-34 sun4m sparc

Subtract 3 from the SunOS and you get the Solaris - you're running Solris2.4

: Ashe is an NFS client to the main NFS server of our LAN, which I'll call


: Ethel. Ethel is, at best, overloaded, and is frequently out of service.
: My goal is to get Ashe to stand on its own two feet as much as possible,
: so that when Ethel is down, I'll be okay. The first problem I have is
: that Ashe doesn't boot when its network connection is broken. To be
: precise, it starts to boot and then gets stuck. I have looked at the boot
: logs and haven't been able to tell exactly where (what boot script) it
: gets stuck.

: I'm testing this by disconnecting Ashe from the network and attempting to
: boot it. Is that a reasonable way to test its ability to boot standalone?

Sounds like a reasonable way to test that.

: I had a hypothesis that the boot problem is that the NFS mount is failing


: because the network connection is broken, and so it's not really getting
: stuck, it's just waiting forever for the NFS mount (well, not forever,
: just for 100000 tries). The filesystems that are being mounted are
: /usr/local and /var/spool/mail, neither of which I would think are
: essential for booting. Is that right? I thought the fix for this would
: be to change the /etc/vfstab file to mount those filesystems in
: background, but it didn't work.

You are probably correct in that idea. Your machine is trying to NFS mount
those directories at boot time and since it's failing, it's hanging. You
might try commenting them out of vfstab just for the heck of it. Once it
does come up (a little more on that later) you won't have /usr/local/ which
might or might not be a problem - that's where many local apps are stored.

: The last lines of the log during the unsuccessful boot are as follows.


: I'm not surprised at the "no carrier" complaint, but I don't know why that
: stops the booting.

[snip log messages]

: Main Question: Why is the standalone boot failing and how can I fix it?

I'm not getting a lot out of those log messages. One other thing to check
might be your NIS. If your box is trying to ypbind to "Ethel" and your
network is disconnected, it won't come up. An easy check for this is to
bring it up on the network, and do "ps -eaf | grep ypbind" to see if it is
binding to something. If ypbind is running, you'll need to fix that. If
you think you want to do that, there are more steps involved, i.e. setting
up your own host table, passwd file, etc. DON'T just kill ypbind!

[snip]

Hope this is accurate and helps you some.

B

--------------------------------------------------------------------------------
The views expressed here do not necessarily reflect those of Hughes Aircraft Co.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian D. Stevens
bste...@redwood.dn.hac.com
Hughes Information Technology Systems

Bruce McLeod

unread,
Jul 25, 1996, 3:00:00 AM7/25/96
to

Scott D. Anderson wrote:
>
> I'm not a sysadmin; I don't even play one on TV. However, I have a
> workstation and I need to do some sysadmin-like changes. I do have the
> root password to my workstation, but not to any of the other systems on
> our LAN. I've done some homework (read Frisch's "Essential System
> Administration" and Stern's "Managing NFS and NIS" and many man pages),
> but I still have some questions, and I hope someone will help me with
> them. The main question involves being able to successfully boot *either*
> networked or standalone (without access to network machines, particularly
> NIS/NFS servers). The rest of this message is the few details I've worked
> out.
>

You could try SUNWnsdis, a package that comes with the Solaris/X86 2.4
Notebook Supplement Diskette. The raw image for this diskette is at
ftp://ftp.uu.net/vendor/sun/solaris/x86/2.4/NBSUP/ns24ns.img.Z
and the documentation (including how to generate the diskette) is at
ftp://ftp.uu.net/vendor/sun/solaris/x86/2.4/NBSUP/ns24gd.tar.Z
Once the diskette is created simply install the SUNWnsdis package
(pkgadd -d <floppy-mount>/packages.pkg).

This package alters your boot files/scripts to check whether a network
interface was successfully configured and bring up the system
accordingly. Unfortunately I haven't figured out how make the
built-in SPARC/SBus ethernet adapter (le0) give up when not
connected to the network, so when I want to boot truly standalone I
simply move /etc/hostname.le0 to something else (not starting with
"hostname") and it works. (You probably want to back up your root
partition before installing the SUNWnsdis package...)

>
> [other stuff deleted]
>

Bruce

0 new messages