Solaris 10. Problems:
- volfs (vold) in maintenance mode; error:
No service found for vold on transport ticlts
- rquotad in maintenance mode with no error
- autofs not working (starts but won’t mount things). Manual NFS mounts work. Errors:
svc_create: no well known address for autofs on ticotsord svc_create: no well known address for nfsauth on transport ticotsord svc_create: no well known address for nfsauth on transport ticots
SOLUTION: Make sure these files exist and have valid content:
/etc/net/ticlts/services /etc/rpc /etc/net/ticots/services /etc/net/ticotsord/services
/etc/inet/inetd.conf, if your ticotsord has not migrated to SMF (
svcs -l rpc_ticotsord).
At my work, I have both a Sun T5220 and M3000. The T5220 has 64 ~1.2 GHz “threads” composed of one CPU with 8 cores of 8 threads each. The M3000 has 8 ~2.75GHz threads composed of 4 cores of 2 threads each.
Product installs were taking much longer than usual, and my customer asked me to find out why. The answer: his install is not very parallel, so being limited to a single slower thread really killed the uncompress and install time.
Here are some numbers. Tested on Solaris 10, with files in /tmp which is mounted on RAM. Input file is Sun Studio 12. The .tar file was removed in between tests, and de/compressions of the files were performed before timing them. Tests were repeated once :).
I recently fought with a StorageTek 2510 for a couple days trying to get it hooked up to a server running RHEL 4 (then 5). I won’t replicate the documentation provided by Sun, or other tutorials but I will tell how I solved the incredibly stupid problem I was having.
I successfully set the array up and presented it to a Solaris 10 host, which was able to see and use it, so I knew the array worked. I moved it to a RHEL 4.8 i386 host (later RHEL 5.5 ×64) and was able to manage it out-of-band with the CAM software, but could not for the life of me get the target discovery to work. Everything was set up just like on the Solaris host, and I did make the required changes on the array for the new host, but I was always presented with:
iscsid: discovery login to 192.168.130.101 rejected: initiator error (02/0b)
The array’s firmware was at the latest, and so was
iscsi-initiator-utils. I fiddled with the options in
iscsi.conf thinking the spoken protocol just needed to be tweaked, to no avail. I tried telling the array that the data host was Solaris, Windows, even Irix, but that made no difference. I undid and redid my entire configuration. I retested with a Solaris data host – still worked there.
Recently one of my AIX 5.3 systems started failing to boot with the following messages:
fsck: Performing read-only processing does not produce dependable results. + mount /tmp mount: /dev/hd3 on /tmp: Device busy + [ 1 -ne 0 ] + loopled 0x518 /TMP MNT FAILED
The problem turned out to be that /etc/inittab was corrupted. This, of course, has nothing to do with the error message. In my case, the contents of the file had been duplicated into itself.
Another problem I ran into with only obscure search results:
alucard@fileserver:~$ ssh aix04 alucard@aix04's password: Last unsuccessful login: Fri May 15 15:28:28 EDT 2009 on ssh from fileserver Last login: Tue Jun 16 10:31:45 EDT 2009 on /dev/pts/0 from fileserver Could not chdir to home directory /home/alucard: Permission denied /bin/ksh: Permission denied Connection to aix04 closed.
The solution in my case was:
chmod a+rx /
/ had permissions 0644 when they need to be 0755 to allow anyone but root to log in.
I just ran into this problem: a Linux machine stuck very shortly after “Decompressing kernel…”, prompting me to enter a runlevel. Problem being that it wasn’t accepting any keyboard input from my USB keyboards and the system doesn’t have a PS/2 port. My Google search didn’t help much, so let me put this out there: check /etc/inittab. In my case, it was a one-line file clobbered by a pre-alpha quality product install. I was booted off of a rescue CD and once I copied /etc/inittab from another Linux system, it booted just fine off of the hard drive. So there you have it – if you’re getting “Enter runlevel” when booting when you’re not supposed to, check the health of /etc/inittab, especially the initdefault line.