Hi,

Today we moved a few computers in the server room to us the space more
optimal.

One Sun UltraSparc2, our NIS server, refused to boot up in normal mode,
single user mode works fine, but I don't want that right now...

It stops doing anyting after checking and mounting the local
filesystems, starting a few services, and setting the gateway...

The last things on screen are:
Setting netmask of hme0 to 255.255.255.0 (like it should be)
Setting default IPv4 interface for multivast: add net 224.0/4: gateway
hostname

Where hostname is subistituted by my hostname...


Any pointers??

Thanks,

Wimmy

> Is the system connected to the same subnet it was before? I have seen
> things like this when moving systems to different networks and the
> interface settings are not setup for the new subnet.
>
> The system cannot start ssh because of inability to resolve properly.
> for instance, you have name servers listed in your /etc/resolv.conf
> file which are on different networks, and your /etc/nsswitch.conf file
> has:
> "hosts: files dns"
>
> If you have moved the system to a new network, or if the network is not
> connected at all, you could just change the /etc/nsswitch.conf file to:
> "hosts: files".
>
> hth,

Well, it's in the same room, on the same network...

So I don't see anything that could trigger this...

Wimmy

In comp.unix.solaris Wim Cossement <wcosseme@nospam.bcol.be> wrote:
> Hi,

> Today we moved a few computers in the server room to us the space more
> optimal.

> One Sun UltraSparc2, our NIS server, refused to boot up in normal mode,
> single user mode works fine, but I don't want that right now...

> It stops doing anyting after checking and mounting the local
> filesystems, starting a few services, and setting the gateway...

> The last things on screen are:
> Setting netmask of hme0 to 255.255.255.0 (like it should be)
> Setting default IPv4 interface for multivast: add net 224.0/4: gateway
> hostname

> Where hostname is subistituted by my hostname...


> Any pointers??


one thing i've used in the past with pretty decent success when startup
scripts have hung is to add a startup script early in the process
(i.e /etc/rc2.d/S00DEBUG.sh) that simply contains:

#
#!/bin/sh

set -x
#

this shows sh -x deubbing output for all following scripts.

Note that your script must end in .sh to be eval'ed by the startup process;
otherwise it will be executed in a subshell and will not affect subsequent
startup scripts.

Wim Cossement wrote:
> Hi,
>
> Today we moved a few computers in the server room to us the space more
> optimal.
>
> One Sun UltraSparc2, our NIS server, refused to boot up in normal mode,
> single user mode works fine, but I don't want that right now...
>
> It stops doing anyting after checking and mounting the local
> filesystems, starting a few services, and setting the gateway...
>
> The last things on screen are:
> Setting netmask of hme0 to 255.255.255.0 (like it should be)
> Setting default IPv4 interface for multivast: add net 224.0/4: gateway
> hostname
>
> Where hostname is subistituted by my hostname...
>
>
> Any pointers??
>
> Thanks,
>
> Wimmy

Is the system connected to the same subnet it was before? I have seen
things like this when moving systems to different networks and the
interface settings are not setup for the new subnet.

The system cannot start ssh because of inability to resolve properly.
for instance, you have name servers listed in your /etc/resolv.conf
file which are on different networks, and your /etc/nsswitch.conf file
has:
"hosts: files dns"

If you have moved the system to a new network, or if the network is not
connected at all, you could just change the /etc/nsswitch.conf file to:
"hosts: files".

hth,

Wim Cossement wrote:

> Well, it's in the same room, on the same network...
> So I don't see anything that could trigger this...

It sounds like it lost network connection. Check the cables,
might have been damaged during the move.

Thanks for the tip Christopher, now I know what went wrong and fixed it...

Apparently my nfs.client script hung because the NFS servers are also
down, but I thought Solaris would (by default) give up on mounting them
if they were not available after sometime and continue booting up, but
now way...

This is kinda stupid if you aks me...
But hardmounting is apparently the default, now I will never forget it ;-)
It's supposed to printout an error on the console though, but I saw
naught...

Thanks, I can go home now ;-)

Wimmy

Wim Cossement <wcosseme@nospam.bcol.be> writes:

> Thanks for the tip Christopher, now I know what went wrong and fixed it...
>
> Apparently my nfs.client script hung because the NFS servers are also down,
> but I thought Solaris would (by default) give up on mounting them if they
> were not available after sometime and continue booting up, but now way...
>
> This is kinda stupid if you aks me...
> But hardmounting is apparently the default, now I will never forget it ;-)

That's what bg option is for.

bg | fg

If the first attempt fails, retry in the background,
or, in the foreground. The default is fg.


Don't change hard option to soft. As per mount_nfs(1M) man page:

Hard versus Soft

File systems that are mounted read-write or that contain
executable files should always be mounted with the hard
option. Applications using soft mounted file systems can
incur unexpected I/O errors, file corruption, and unex-
pected program core dumps. The soft option is not recom-
mended.


Bye, Dragan

--
Dragan Cvetkovic,

To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!

Well, that'll teach me for using no options when mounting NFS...

Wimmy

Wim Cossement wrote:
> Apparently my nfs.client script hung because the NFS servers are also
> down, but I thought Solaris would (by default) give up on mounting them
> if they were not available after sometime and continue booting up, but
> now way...

You can also use the automounter instead of static nfs mounts.

In article <d74sbu$868$1@snic.vub.ac.be>,
Wim Cossement <wcosseme@nospam.bcol.be> writes:
> Thanks for the tip Christopher, now I know what went wrong and fixed it...
>
> Apparently my nfs.client script hung because the NFS servers are also
> down, but I thought Solaris would (by default) give up on mounting them
> if they were not available after sometime and continue booting up, but
> now way...
>
> This is kinda stupid if you aks me...
> But hardmounting is apparently the default, now I will never forget it ;-)
> It's supposed to printout an error on the console though, but I saw
> naught...

Nowadays, you normally only see NFS mounts in /etc/vfstab if those
filesystems are essential to the system starting up, either the OS
itself (such as /usr), or a key application on the system. For such
mounts, it mostly does make sense to sit waiting on them forever,
e.g. you aren't going to get far without /usr, and (sadly) your
key application may fall to pieces if it comes up with half its
files missing and isn't designed to handle such a failure.

Filesystems which are not essential to the operation of the system
would normally be handled by the automounter, and don't get mounted
during boot so they won't hang it up. In its crudest form, you can
often do this just by replacing the mountpoint with a symlink
pointing at /net/remoteserver/exportedpath. A better solution is
to create appropriate automount maps to mount the filesystems
automatically on their expected mount points when they are accessed.
Automount maps can be shared across a network if you have several
systems mounting the same things in the same place.

--
Andrew Gabriel