Solaris

PXE / Net booting Open Solaris 200805 release.

Introduction

After the disk in my laptop recently died I decided that it would be a good time to try and install the latest version of Open Solaris onto my laptop. Unfortunately the only option I have for installing new operating systems onto this laptop is via PXE boot, this has not been an issue in the past as I’ve been installing Debian / Ubuntu.

Solaris is fully capable of being network installed, in fact there are a multitude of tools out there that assist you in doing so. However, this is not true for the latest release of Open Solaris, support is planned but its currently not available. As a learning exercise I decided that I’d attempt to get this working on my laptop, turns out its entirely possible with a little bit of fiddling.

Note: This does not create a hands-off installer, it merely boots the livecd from the network. You can then install the system as you would normally from the gui installer.

Note 2: Part of this guide contains an ugly hack, its awful and may not work for you at all - you have been warned.

Requirements

You will need to the following to PXE / Net boot Open Solaris

  • Time
  • One copy of the Open Solaris CD Image.
  • One system already running Open Solaris (to manipulate the boot archive)
  • One PXE Boot Server (one part DHCP server, one part TFTP server and one part NFS server)
  • One PXE Boot Client (with sufficient hardware to run Open Solaris)
  • One network which both the client and server are connected to.

Setting up PXE Boot.

I’m going to assume that you know how to setup a PXE boot server, there are many documents regarding this for other operating systems which can be used to fill in the blanks here. Personally I used ubuntu Gutsy Gibbon as my PXE boot server.

The following steps explain which files need to be taken from the cdrom image and placed on your PXE boot server.

  • Mount the cdrom image somewhere on your system (I chose /mnt/cdromimage/)
  • From the cdrom image copy out the following files into your tftp directory (/tftpboot/ on my system)

# cp /mnt/cdromimage/boot/grub/pxegrub /tftpboot/boot/grub/
# cp /mnt/cdromimage/boot/x86.microroot /tftpboot/solaris/
# cp -r /mnt/cdromimage/platform/* /tftpboot/solaris/platform/

  • Note: you do not need all of the contents of of the /platform/ directory, however, its only 6mb in total its easier to include it all than remove what we don’t need.
  • Create the file /tftpboot/boot/grub/menu.lst with the following contents:

default=0
timeout=60
timeout=3
title Open Solaris PXE Install
kernel$ /solaris/platform/i86pc/kernel/$ISADIR/unix -m verbose -B install_server=[ip of your nfs server]:/export/opensolaris/
module /solaris/x86.microroot

  • When setting up your dhcpd boot entry for the Open Solaris client machine ensure that you include the following dhcp options (this is for the ubuntu dhcpd server, this is different under Solaris)

option grubmenu code 150 = text;

host laptop {
hardware ethernet 00:XX:00:XX:00:XX;
option grubmenu “/boot/grub/menu.lst”;
fixed-address 192.168.1.34;
option subnet-mask 255.255.255.0;
option routers 192.168.1.10;
next-server 192.168.1.20;
filename “/boot/grub/pxegrub”;
}

With your dhcpd and tftpd services up and running you should now be in a position to boot the client, this will get you to a point where the system has loaded the kernel + microroot. The boot will fail when we attempt to mount the cd rom.

Editing the miniroot

To complete the boot process we need to update the microroot and tell it to mount the cdrom from an nfs server instead of from a local cdrom drive. Now is the time to load up the Open Solaris machine you installed earlier, mount the open solaris iso and copy the x86.miniroot file somewhere handy (ready for editing).
The miniroot is a gziped ufs file system image, its relatively easy for us to open it up and manipulate as we please.

# mv x86.microroot x86.microroot.gz;gunzip x86.microroot.gz
# lofiadm -a /path/to/x86.microroot /dev/lofi/1
# mount /dev/lofi/1 /mnt/microroot

So now we have the microroot mounted under /mnt/microroot, lets make some changes. First of all there are three utilities I’ve added to the microroot to aid in net booting. These can be added in the following way:

# cp /usr/sbin/prtconf /mnt/microroot/usr/sbin/
# cp /usr/sbin/i86/prtconf /mnt/microroot/usr/sbin/i86/
# cp /usr/bin/cut /mnt/microroot/usr/bin/
# cp /usr/bin/sed /mnt/microroot/usr/bin

We now have all the utilities required on the microroot to mount the cd image over nfs, the next step is to update the script that mounts the cdrom image.

Note: Here is where the nasty hack is, as I couldn’t convince nwamd (network automagic daemon) or the default network service to actually bring up the network correctly I run perform a dhcp request in the script that mounts the cdrom image. Ideally we should bring networking online via the networking physical service (or nwamd if thats what its actually designed to be used for) and have the live-fs-root service depend on the networking. Anyway, as there is an official net boot utility in the pipeline I hope this will suffice until thats available.

On with the hacking, edit the /mnt/microroot/lib/svc/method/live-fs-root startup script. Find the following line:

echo “\rPreparing live image for use” >/dev/msglog

Just below this line add in our few lines to grab the install_server value, send out a dhcp request followed by mounting the network file system.

# grab the install_server setting from boot
install_server=`/usr/sbin/prtconf -v /devices|/usr/bin/sed -n ‘/install_server/{;n;p;}’|/usr/bin/cut -f 2 -d\’`
# Awful hack - configure dhcp for all the plumbed interfaces
/sbin/ifconfig -a dhcp
# now mount the install server onto /.cdrom
/sbin/mount $install_server /.cdrom

The above few lines do not perform any sanity checks, if any of the commands fail you’ll just get dumped to a single user login prompt.

Now that we are finished editing the micro root its time to unmount and re-compress it before dumping it back into the tftp directory on your PXE boot server.

# umount /mnt/microroot
# lofiadm -d /dev/lofi/1
# gzip x86.microroot;mv x86.microroot.gz x86.microroot

Finally..

The last thing to do is to export the contents of the cd image over nfs, I chose to export it from /export/opensolaris/. It may help you to know that Solaris has issues mounting nfs v4 from Linux servers (certainly from ubuntu gutsy release), I had to disable nfs v4 services under linux to mount the nfs file system from my Solaris system.

If everything has gone smoothly you should now be in a position to boot your client machine, which once the pxe boot has completed should run just as it would had it been booted from cdrom.

If you get dumped to a single user login prompt its safe to assume something has gone wrong, I’d recommend logging in (root pw: opensolaris) and verifying that each of the steps we take in the mount cdrom script works correctly.

code
hacks
networking
debug
Solaris
Open Solaris
PXE
Net Boot

Comments (2)

Permalink

ZFS Compression, when du and ls appear to disagree.

I have recently been migrated to a new ZFS based home directory at work, I’ve got hourly snapshots of my data and (as I’ve just found it) automatic on disk compression is enabled. Recently, when dealing with a corrupt .tar archive the on disk compression managed to suitably confuse me - enough to write this blog entry.

After saving my .tar file into my home directory I decided to verify the size on disk with the size on the ftp, the tar file on the ftp was roughly 20mb.

# du -hs download.tar
6.2M download.tar

That didn’t look right so I verified the file size with ls

# ls -ahl download.tar
-rw-r–r– 1 iain staff 20M May 9 17:41 download.tar

So, ls thinks my file is 20mb in size and du thinks its only 6mb, turns out that this is the expected behavior when you have compression enabled on the file system.
Both du and ls get their information about a file by performing the stat() system call against the file, /bin/stat under Solaris Nevada shows us the information returned from the stat() system call.

#/bin/stat download.tar
File: `download.tar’
Size: 20616912 Blocks: 12769 IO Block: 8192 regular file
Device: 5102d9ah/84946330d Inode: 76465 Links: 1
Access: (0644/-rw-r–r–) Uid: (50000/iain) Gid: ( 10/ staff)
Access: 2008-05-09 17:53:17.653543700 +0100
Modify: 2008-05-09 17:41:18.136951400 +0100
Change: 2008-05-09 17:41:18.136951400 +0100

The file attributes returned contain the files size in bytes, this is what ls returns to us when performing a directory listing. However, the same is not true for du. Based on the source of du.c one can see that du calculates the file size on disk by multiplying the number of blocks the file takes on disk up by 512.

12769 * 512 = 6537728 Bytes or 6.23Mb

Although there is a clear explanation for this behavior I think that it may cause some confusion. I am sure that many people rely on du returning the actual size of the file, this could cause problems if you are preparing to copy the files to cdrom or to any other file system that does not perform compression. It is certainly something that anyone administrating ZFS file systems should be aware of.

debug
Solaris
ZFS

Comments (0)

Permalink