I have had a trusty Solaris box at home now for 5-6 years running a few things;
– ZFS for my files, sharing out through SMB for media, iSCSI for playing with Netbooting and VMware shared storage.
– Xen (More recently) running on a Solaris Dom0 hosting a number of Centos5 DomU’s for other linux server based stuff.
– Multicast/Bonjour spoofing and apple filesharing making an excellent ‘fake’ timemachine for backing up my Macbook pro onto ZFS (works flawlessly and doesn’t have a single disk prone to failure unlike the time capsules
Over that time, I’ve either in-place upgraded, or overwritten the OS and let the new version of Solaris import the ZFS pool from;
Solaris 10, Solaris SNV_8X (Sun Internal), Solaris SNV_9X (Sun Internal), OpenSolaris (SNV_1XX), Oracle Solaris Express (SNV_151).
And everything was pretty much good 🙂 Until now, now I tried to take the latest update, moving to the newly released Solaris 11.
Lots of things have changed in Solaris 11 compared to the SNV/OpenSolaris/SolarisExpress years (well, i’m not saying there hasn’t been a lot of changes during that time, just none that have negatively affected me, where as these do);
– Support removed for Linux branded Solaris Zones
– Support removed for Solaris 11 to be a Xen Dom0, or indeed be the base of any form of visualization solution apart from Solaris zones and VirtualBox (Guessing to allow Oracle to push it’s visualization product)
– No check in the ‘pkg update’ procedure as to wether the Xen kernel was in use before upgrade.
So, cutting to the POINT OF THE POST, I updated, a new boot environment was created, update successful, rebooted, boot fails!
You could just boot the previous Boot Environment, which works, but this is what you’ll need to do to boot the new BE;
1. Open the grub menu.lst from /rpool/boot/grub/menu.lst
2. Find the last entry in the file (named after the Boot Environment you’re having issues with)
3. Remove the references to Xen, as below;
kernel$ /boot/$ISADIR/xen.gz console=vga dom0_mem=2048M dom0_vcpus_pin=false watchdog=false
module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS
We have just removed the Xen kernel and options and instead told grub to boot the ‘normal’ Solaris kernel. It seems pkg update don’t check for this when upgrading.
Now reboot and try the Boot Environment from the grub menu, should load fine and after some information about upgrading the SMF versions, you’ll be ready to login.
The second issue I found after this is that my SMB shares were not available, seemed that the SMB service was stopped due to dependencies, starting the following services magically made my shares come back to life;
svcadm enable idmap
svcadm enable smb/client
svcadm enable smb/server
Verify with ‘share’;
[email protected]:~# share
IPC$ smb - Remote IPC
Matt /F43Datapool/Matt smb -
Public /F43Datapool/Public smb -
c$ /var/smb/cvol smb - Default Share
I hope this helps someone, the last thing I have to work out is whether VirtualBox will provide as stable a solution for my Linux VM’s as Xen (as it seems to be the only option I have now, apart from moving back to Linux and losing ZFS/SFM/Crossbow/Comstar etc which I really don’t want to do).
That said, it really annoys me that Oracle have removed such a simple and powerful combination of Xen Dom0 and ZFS in the base solaris image, it served a perfect need for people who don’t need a full, separate, virtualization product such as testing, home use, small businesses etc. Why remove Dom0 support but keep DomU support! Anyone know?