How Cool is That ?
Bob Netherton's Weblog
« Previous day (Sep 24, 2005) | Main | Next day (Sep 25, 2005) »
20050925 Sunday September 25, 2005
Bootloaders and order of OS installation
There is a tremendous amount of information on bootloaders available on the web. And a lot of the information is good. But some of it isn't, and the assumptions (and limitations that are suggested) can make this a lot more difficult than it needs to be.

So some very quick observations.

GRUB (the Grand Unified Bootloader) is the easiest to use of all of the bootloaders. It provides all that we need to boot Windows, Linux, and both of my Solaris instances. GRUB will be the final bootloader in the master boot record (MBR) when we are finished, but it won't get there right away.

The Windows bootloader, which is in the MBR at the moment, is very well suited to boot Windows. Making it boot other operating systems is almost an unnatural act. I may blog about my experiments in this area in the future, but the short version is that we want to get rid of it as quickly as we can.

Now, the Solaris 10 bootloader is a good intermediate step (which suggests that Solaris might be the next operating system to install). It will boot both Windows and Solaris (well one instance of Solaris) but doesn't work well with Linux distributions in the extended partition. Before we call this a deficiency or bug, we should note that we are now operating well outside of the design center, so a bit of tolerance will help get us through this step.

OK, so we have Windows, we'll do Solaris 10 next, but what about the two Linux instances ? Hmmmm, that's worth a bit of thought.

The Java Desktop System is more of an end user type of system, so things like kernel updates will come out on a regular schedule, but it won't be too frequent. It is also based on SuSE, so new kernels will be symbolically linked to /boot/vmlinux so that the GRUB configuration doesn't change.

Fedora Core, on the other hand, is a rapidly evolving developer snapshot and kernels can be expected quite frequently. And since it was derived from the original Red Hat consumer distribution, the deployment method is to drop in a new kernel (or kernels) and then modify the GRUB (and Lilo) configuration as part of the installation.

Putting all of this together suggest that the most maintainable solution is to end up with the Fedora Core bootloader in the MBR and add the static bits required to boot JDS, Windows, and the two Solaris instances. This would suggest that JDS would be the best choice for installation after Solaris 10. Fedora Core after that - and with some edits to /boot/grub/menu.lst we will be a flexible multi-booting system.

Oh, what about OpenSolaris ? Good question. I have it on good authority (OK, I've already installed it on a couple of systems) that it will leave the MBR alone, so it will go in last. I also know that we will have to do some serious partition manipulation to keep the two Solaris instances out of each others way - and GRUB from Fedora Core will do exactly what we need.

Next time, the Solaris 10 installation.

Technocrati Tags:

Sep 25 2005, 10:46:11 PM CDT Permalink Comments [3]

Carving up the disk
Now that we have a plan, time to get to work.

Resizing the NTFS partition is our first challenge. Using a commercial partition tool like Partition Magic would violate the prime directive, so let's see what's available in the land of free software.

The GNU project qtparted seems like a good choice. It is a lightweight graphical front end tool that calls back end worker primitives such as resize_ntfs to do the actual work. Since it is a small application it is very well suited for CDROM based Linux distributions such as Knoppix and the System Rescue CD. Since I'm downloading this over my home DSL line, I'll opt for the somewhat more compact System Rescue CD.

note: We have experienced a few troublesome notebook computers in various installfests and the more complete Knoppix distribution helped us solve some tricky issues. If you run into a situation where the CDROM distribution fails to boot (locks up or panics) then try things like passing fb1024 or noacpi, noapic to the kernel.

Before we break out the sharp tools, let's think about one more thing. If I've booted XP on this system, it is likely that either the disk has become fragmented or perhaps something like a pagefile or suspend file may be in a really inconvenient place (like at the end of the partition). qtparted does a good job of adjusting the file system boundaries, but it wont reorganize the file system (since NTFS writes aren't considered safe). So let's boot up XP in safe mode, run a disk defragmentation, and delete the pagefile.

Time to boot the System Rescue CD (or Knoppix if you prefer). Once booted and configured, start up qtparted. For the non-graphical System Rescue CD, there is a shell script called run_qtparted that will start up a minimal graphical environment.

The first task is to resize the NTFS partition. The Toshiba OEM configuration is a single large NTFS partition, so I select it and set the new size to 12GB. Since fragmentation isn't a problem, this operation succeeds. Now you are left with another big decision, do you carve the rest up now, or do it later when you install the various operating systems. If this wasn't such a lab experiment I would suggest that you leave the unallocated storage as free space and let the installers gobble it up as needed. But we're going to push a couple of boundaries here, so I am going to carve up the rest of the disk now. I'll mark all of the partitions (except for the extended) as Linux, but we can change that later.

Now that we have our disk configuration, time to boot back to XP (maybe for the last time) to run a file system check to make sure things are OK. qtparted marks the file system as dirty so this should happen automatically when you reboot, but if not you can start it manually.

Technocrati Tags:

Sep 25 2005, 10:40:59 PM CDT Permalink Comments [1]

Getting Started
It doesn't matter whether you call it living the Open Source lifestyle or creating a Microsoft-free zone, the notion of build a fully functional mobile user environment out of openly available technologies has its appeal.

Before we get started, let's be clear on a number of requirements. This has to be a real functioning system that can do real work while on the road (which also means that some entertainment value must be found). Some of this is going to be easy, some may require a bit of thought.
So what are the minimum requirements ?


Some things that would be nice to get working might include

Oh - one very important caveat. I'm not afraid to try some strange unsupported things, so consider this a "do not try this at home" warning. That said, you probably will do some of these things, so I might as well share what worked and what didn't.

Let's see how far we can take this experiment without spending any money.

For this particular example, I am starting with a pretty basic Toshiba Tecra-M2 laptop system (for no other reason than it was readily available). This particular system came with Windows XP Home Edition pre-installed. It also has an 80GB internal disk which should allow some creative configurations.

The first step is to carve up the disk for the various operating systems and data partitions  that we will need. Since I don't know where this is going, flexibility will be the primary requirement.

For my operating systems I have decided to leave Windows XP on, at least for a while. Yes, it's a crutch, but until I get everything working I want to be able to fall back and play a little Alpha Centauri while I work through troublesome spots.

I'm also interested in looking at both Solaris and OpenSolaris, so I'll plan for both.

And I might as well put on a Linux distribution or two - and like XP, the space may well be reclaimed later. For the Linxux distributions I have selected Fedora Core 4 (as my Xen dom0) and the Linux version of the Java Desktop System.

I'm suddenly feeling like 80GB of storage might not be enough.

My disk partition plan is beginning to look like

Partition
Size
Type
Mount Point
Notes
1
12GB
NTFS
Window XP C:
/xp
Read-only access under Linux using Linux-ntfs kernel modules
No access from Solaris
2
12GB
Solaris UFS

s0 - Solaris root (10GB)
s1 - swap (2GB) - available to Linux as  /dev/hda10
3
24GB
Solaris UFS

s0 - Solaris root (12GB)
s1 - swap (2GB) - available to Linux as /dev/hda10
s7 - /export (10GB)
4
30GB
Extended
N/A

5
4GB
FAT32
Windows XP E:
/pc on Solaris and Linux

6
10GB
Linux (ext3)
Fedora Core root

7
6GB
Linux (reiserfs)
Java Desktop root

8
10GB
Linux (ext3)
/export


Ahhhh, but what about Linux swap you ask ?

The Solaris slices are available to Linux, so I will take advantage of that and share swap partitions between Solaris and Linux. It also means that I will have to create the same swap slice in both of my Solaris partitions. As a safeguard, Linux requires that the swap partition be properly formatted, so we will do that later when we install our first Linux distribution.

Good grief, this is starting to sound complicated. You might be saying something like "with something like VMware I don't have to thing about any of this, I just create things and they run." And that might be true, but remember the prime directive - this is to explore just how far we can take commodity system that can be built out of free parts. So VMware is out, but perhaps Xen can perform that role - we'll certainly explore that idea with vigor.

So much for the plan. Next time we'll carve up the disk and get started installing some software.

Technocrati Tags:

Sep 25 2005, 08:40:48 PM CDT Permalink Comments [0]