Pages

Unixbhaskar's Blog

Friday, July 31, 2009

Solaris/Opensolaris boot modification

OpenSolaris: GRUB and the Boot Environment

Filed under: OpenSolaris, File Systems, Solaris — admin @ 12:26

Ever since I started working with OpenSolaris (release 2008.05 to build 118: 2010.02), I have been suffering through some of the longer load times. While the distribution is maturing fairly well and quick, the boot times are just horrible. And to my understanding the culprit is ZFS. OpenSolaris utilizes ZFS as its default file system. On top of that, one thing that I still cannot understand is why GRUB defaults its timeout value to 60 seconds. 60 seconds! Why!?! Who needs this 60 seconds and/or who wants to be constantly annoyed to hit enter to the default kernel image, initiating the boot process? Either way, this can be modified. On OpenSolaris, editing the GRUB boot options is a little different from your traditional UNIX/Linux operating system. Note that this article is for Intel architectures and not SPARC.

Traditionally we find the appropriate files for editing in the /boot path, specifically in /boot/grub; and depending on your distribution the configuration file can vary (grub.conf or menu.lst). In OpenSolaris and on the ZFS file system, while the /boot/grub/ path exists, it does not contain the menu.lst file that we need. Instead, it is located in the /rpool/boot/grub/ path.

When you really start using Solaris/OpenSolaris, you may notice one thing that sticks out when compared to the GNU/Linux counterpart; and that is Solaris/OpenSolaris tends to be better polished when it comes to using the command line for editing system configuration files. For example, two separate tools exist for managing boot configuration files and the boot environment: bootadm and beadm. I know that certain Linux distributions have their own sets of tools for managing such stuff (i.e. QGRUBEditor as I have seen in Ubuntu; among others) but when I hop back onto a Solaris machine, it just seems simpler and a lot more straight forward. It is also standardized across both operating platforms as opposed to each distribution having their own. Historically I have always opened up the menu.lst or grub.conf file with vim and made my modifications right there. While this can still be done, the development team behind Solaris/OpenSolaris have decided to standardize it within the two applications.

bootadm

As mentioned earlier, bootadm is used to list and/or redefine specific values in your menu.lst file. Its usage is as follows (man bootadm):

#petros@opensolaris:~$ bootadm
bootadm: a command option must be specified
USAGE:
bootadm update-archive [-vn] [-R altroot [-p platform>]]
bootadm list-archive [-R altroot [-p platform>]]
bootadm set-menu [-R altroot] key=value
bootadm list-menu [-R altroot]

If I wanted to list my current configuration I would type at the command line:

petros@opensolaris:~$ bootadm list-menu
the location for the active GRUB menu is: /rpool/boot/grub/menu.lst
default 0
timeout 3
0 Solaris Development snv_118 X86

I can easily modify a parameter such as the timeout with the following command:

petros@opensolaris:~$ pfexec bootadm set-menu timeout=2
petros@opensolaris:~$ bootadm list-menu
the location for the active GRUB menu is: /rpool/boot/grub/menu.lst
default 0
timeout 2
0 Solaris Development snv_118 X86

beadm

The beadm tool is used to create and enable new boot environments. What beadm can do is take a snapshot of your current environment. This routinely occurs (transparent to the user) after a system update. Usually these snapshots should be made when applications are installed/removed to even when configuration files are modified. It will then append the listing into the menu.lst file. This way, if the new image ends up bringing down the system, you can revert back to the previous image (snapshot). Such are some advantages when the ZFS file system incorporates its own native snapshot mechanism. Basic usage for this utility is extremely simple (man beadm).

petros@opensolaris:~$ beadmUsage:
beadm subcommand cmd_options

subcommands:
beadm activate beName
beadm create [-a] [-d description]
[-e non-activeBeName | beName@snapshot]
[-o property=value] ... [-p zpool] beName
beadm create beName@snapshot
beadm destroy [-fF] beName | beName@snapshot
beadm list [[-a] | [-d] [-s]] [-H] [beName]
beadm mount beName mountpoint
beadm rename beName newBeName
beadm unmount [-f] beName

To list all boot environments you would type the following on the command line:

petros@opensolaris:~$ beadm list
BE Active Mountpoint Space Policy Created
-- ------ ---------- ----- ------ -------
opensolaris NR / 6.10G static 2009-02-18 08:35

Let us say you made some changes to a configuration file or two or maybe install some applications or enable/disable services. You may want to create a new image so that if someone was wrong with the image, you can always revert back to the previous.

petros@opensolaris:~$ pfexec beadm create 22Feb09
petros@opensolaris:~$ beadm list
BE Active Mountpoint Space Policy Created
-- ------ ---------- ----- ------ -------
22Feb09 - - 92.0K static 2009-02-22 11:54
opensolaris NR / 6.10G static 2009-02-18 08:35

A new entry is created in GRUB, although the older image is still the default.

petros@opensolaris:~$ bootadm list-menu
the location for the active GRUB menu is: /rpool/boot/grub/menu.lst
default 0
timeout 2
0 Solaris Development snv_118 X86
1 22Feb09

To activate the new image and have it default in GRUB, you can invoke beadm as so:

petros@opensolaris:~$ pfexec beadm activate 22Feb09
petros@opensolaris:~$ bootadm list-menu
the location for the active GRUB menu is: /rpool/boot/grub/menu.lst
default 1
timeout 2
0 Solaris Development snv_118 X86
1 22Feb09

After reboot beadm list will look like this:

petros@opensolaris:~$ beadm list
BE Active Mountpoint Space Policy Created
-- ------ ---------- ----- ------ -------
22Feb09 NR / 6.24G static 2009-02-22 11:54
opensolaris - - 5.25M static 2009-02-18 08:35
Bhaskar Chowdhury
Chat Google Talk: unixbhaskar Skype: unixbhaskar Y! messenger: unixbhaskar
Contact Me StumbleuponFacebookDiggTwitterLinkedinRedditWordpressTechnorati


No comments:

Post a Comment