Solaris

As you know, traditionally with older Solaris versions you had to leave /sbin/sh as the default root shell. In Solaris 8 and 9, you're supposed to do this because all the libraries for dynamic linking are in /usr/lib, which could well be on a separate /usr filesystem. This filesystem may not be accessible during the maintenance boot, and therefore it is regarded as a very bad practice to change the root shell.

To make sure the superuser is always going to be able to log in, you have a /sbin/sh assigned to root, and it's a statically built binary, so it doesn't need any of the external libraries:



But did you know, that Solaris 10 has greatly improved this situation for you, and there are two major improvements? Here they are:

1) Now standard libraries are in /lib, and therefore they're always accessible during your maintenance boots.
As a result of this, your /sbin/sh shell is now a regular executable using dynamic libraries:



2) Solaris 10 has a built-in protection against non-executable root shells. So, if you change it to any other shell and it for some reason cannot be started for you, you will automatically get a standard /sbin/sh instead. The same kind of protection exists for sudo command as well.

These improvements make sure that there is nothing to stop you now from setting your root shell to anything you like.

The last few days I've been busy patching our Solaris boxes, and that's why I had to dig this old trusty table up. It shows all the patches installation error codes which usually appear in a form of:
Installation of 'patch_number' failed. Return code N.

I think the most common errors are 2 and 8, but I've seen some others too:

Last few days I'm working on debugging the Solaris 10 Jumpstart install for some old desktops (Ultra 10, Ultra 60).

Among few well-known problems, I've noticed such an anomaly: the whole Jumpstart session happens just fine, all the packages are installed, but at the very end I see the errors and the installation fails:



After a quick research, I've found out that such errors happen when you have a Solaris network image miniroot corrupted. And after a short while more, I've learned how exactly I got my miniroot image corrupted in the first place: I had my netinstall image in the /export/vol1/jumpstart/images directory, which I had previously shared out using share -o rw,anon=0 /export/vol1/jumpstart/images when I was transferring the netinstall image from a desktop with CD-ROM to the Jumpstart server.

Shortly after the copying, I got distracted and therefore had completely forgotten to unshare the resource. As the result of this, the add_install_client had tried to share the miniroot but didn't touch it as the whole netinstall image was already shared out with read/write access.

And this is how such a setup corrupts your miniroot: the very first client you Jumpstart, is trying to update some of its files - like /etc/vfstab and /etc/hosts, but they're in miniroot. With read/write access, they get corrupted right there. But what happens usually is that your client moves on to another location for these files, as it can't update the read-only miniroot ones. It normally ends up updaiting /a/etc/vfstab and /a/etc/hosts, I think.

As the result of this error, you're left with some directories of your miniroot having regular files instead of symlinks. For example:

this is the original and fully working /export/vol1/sol10/Solaris_10/Tools/Boot/etc/inet directory:



... and this is the same one, only corrupted by the first installed client:



LESSON OF TODAY: be careful and always check that your netinstall image has its miniroot shared out in read-only!