I have a system (a zone on which this blog is hosted) that has been running the same installation of Solaris since 11/11/2009, starting with OpenSolaris 2009.06. In the time since, it has seen every public build of OpenSolaris, then OpenIndiana, and finally Solaris 11 Express. Now, exactly two years later, I’ve updated it to Solaris 11 11/11, and I’d like to share my experience so far.
The update itself did not go smoothly. I was sitting at Solaris 11 Express SRU 8 and thought, like every update I’ve done in the past, that I could just run pkg image-update. Silly me, because when I did and then rebooted, the kernel panicked. No big deal, that’s what boot environments are for. I reverted to the previous boot environment and found some helpful documentation that told me to do exactly what I just did. It turns out that there is no way to update to SRU 13 using the support repositories because they already contain the Solaris 11 11/11 packages, and pkg tries to pull some of them in. And there is no way to update just pkg because the ips-consolidation prevents it, and trying to update the ips-consolidation pulls the entire package which breaks everything just the same. In short, Oracle bungled it. The only way to update to SRU 13 that I could see was to download the SRU 13 repository ISO from My Oracle Support and set up a local repository. Once I was on SRU 13, I could continue with the update to the 11/11 release. But there were more surprises in store for me.
First, it looks like pkg decided to start enforcing consistent attributes on files shared by multiple packages. Fine, I can understand that. As a result, I had to remove a lot of my custom packages (mostly from spec-files-extra) which I’ll have to rebuild. Second, pkg decided it doesn’t like the opensolaris.org packages anymore so I had to uninstall OpenOffice.org. Also fair enough.
Happily, after that, the updates got applied successfully and the system rebooted into the 11/11 release. Next came the zone updates. When I did the normal zoneadm -z foo detach && zoneadm -z foo attach -u deal, I was told I had to convert my zones to a new ZFS structure which more closely matches the global zone. The script /usr/lib/brand/shared/dsconvert actually worked flawlessly and the updated zones came up fine.
Unfortunately I couldn’t SSH into my zones because my DNS server didn’t know where they were. It seems that with the updated networking framework, DHCP doesn’t request a hostname anymore. (/etc/default/dhcpagent still says inet <hostname> can be put in /etc/hostname.<if> to request the hostname.) I found that you can create an addr object that requests a hostname with ipadm create-addr -T dhcp -h <hostname> <addrobj>, but NWAM pretty much won’t let you create or modify anything with ipadm, and there were no options for requesting hostnames with nwamcfg. As a result, I had to disable NWAM (netadm enable -p ncp DefaultFixed) and then I could set up the interface with ipadm. Why doesn’t Solaris request hostnames by default? Not very “cloud-like” if you ask me.
I have to say, I’m impressed by the way global zones and non-global zones are linked in the new release. Zone updates were an obvious shortcoming of previous releases. We’ll see how well it works when Solaris 11 Update 1 comes out.
What else…I lost my ability to pfexec to root. Oracle removed the “Primary Administrator” profile for security reasons so I had to install sudo. Not a big deal, I just wish they had said something a little louder about it.
Also, whatever update to pkg happened, it wiped out my repositories under /var/pkg. I had to restore them from a snapshot. Bad Oracle!
I’m also a little confused about some of the changes to the way networking settings are stored. For example, when I first booted the global zone, I found that my NFSv4 domain name was reset by NWAM. I set it to what it should be with sharectl set -p nfsmapid_domain=thestaticvoid.com nfs, but is that going to be overwritten again by NWAM? Also, the name resolver settings are now stored in the svc:/network/dns/client:default service, and according to the documentation, DHCP will set the service properties properly, but I have yet to see this work.
And the last problem I’ll mention is that the update removed my virtual consoles. I had to install the virtual-console package to restore them.
Overall, I’m happy that I was at least able to update to the latest release. Oracle could have cut off any update path from OpenSolaris. However, the update should have been a lot smoother. It doesn’t speak well of future updates when I can’t even update from one supported release (SRU 8) to another. I also wish Oracle were more open about upcoming changes (as in, having more preview releases or, dare I say it, opening development the way OpenSolaris was). Even to me, a long time pre-Solaris 11 user, the changes to zones and networking are huge in this release, and I would rather have not been so surprised by them.
The /var/pkg directory is a project private interface. You should not be surprised to see files disappear from there. pkg(1) documents that it is private and subject to change. Please do not store files there.
You know as well as anyone that /var/pkg/repo used to be the default repository path. So it should be reasonable to expect that some installations will still be using it, and other paths under /var/pkg for repositories. Therefore, the behavior for the upgrade should have been for svc:/application/pkg/server to go into maintenance mode with a helpful message to say to move the data outside of /var/pkg instead of just deleting it.
Yes, I know that, which is why /var/pkg/repo is preserved during image format upgrades and there are unit tests to verify this behaviour:
However, *no other directories* would have been preserved.
Please note that this was fixed in build 152.
Hey if you try to boot single user mode off the Solaris 11 11/11/11 x86 install image, or try to choose menu option #3 for (single user mode) it prompts you for a user name for system maintenance mode.
root/what is was under OSOL b131
do not work. then it says “login incorrect or user root not authorized”.
The release notes say, the root user password is expired immediately after a successful install from the x86 USB image, but nothing is said about the x86 or SPARC standard versions.
This is really disappointing, because there is not a seasoned Solaris administrator who HASN”T recovered from a botched root disk by booting single user from a install CDROM and fixing it from here.
Yes my md5 checksums match the published ones.
I’m completely out of line here, but i see no other place to ask/inform, that probably you haven’t yet fixed the iriverter project page (or Trac).
Not out of line at all. I did have to uninstall Trac to upgrade to Solaris 11. I honestly didn’t think anyone still used iriverter, it’s so old. Anyway, the page is back up now. Enjoy.
I use it sometimes, to convert videos for my old iriver clix2. So i was automatically tracking that page for an update. Though i still haven’t tried out the latest 17.1 version. Thanks.
Mr. Bongo, try root/solaris11
Pingback: Upgrading Solaris 10 to Solaris 11: things you should know | Rainbow Chard