Graham White: My Notes

This post documents how I installed Linux and Windows side-by-side in a dual boot configuration.  This isn't something particularly difficult to do but I wanted to note down what I did so I remember in years to come.  Also, my new PC build contains some very up-to-date hardware (such as UEFI and an SSD drive) and with the combination of the many changes and updates to Fedora 17 (F17) and Windows 7 SP1 (Win7) it made the installation a first of a kind for me in quite a few different ways.

This post may well be updated in the future if I do further installation tweaks and optimisations to the system.  There's also clearly a lot more you can do in terms of system set up than I've written here, installation of drivers in Win7 very much being one of those.  This is simply intended as an installation and base optimisation guide.

Create USB Boot Sticks

Due to a fault with the DVD writer I ordered, it's on its way back to the retailer for replacement.  Not one to let this stop an installation going ahead I wrote install images for F17 and Win7 onto USB stick.

F17 is still in beta with the full release delayed until 29th May at the time of writing.  I tried writing and booting from the KDE Spin Beta Live image but it stopped with a kernel panic during the boot process after the grub screen.  I found using a later copy of the boot.iso (which is the same as a netinst.iso) from the distribution nightly builds solved the problem so clearly whatever the bug is on the beta image it's already been solved.

Creating a USB stick for Fedora is pretty easy these days, no messing around on the command line, I decided to use the liveusb-creator utility.  It fires up a GUI from which you basically just select the iso image you want to write and the USB device to write to, then hit "go" and it does the magic for you.

For me, writing the Windows stick was a little more complicated as it requires a Windows system to run the stick writing utility with the somewhat strange and long winded name of the Windows 7 USB/DVD Download Tool.  Fortunately, I had a Windows 7 VM laying around so I used that and writing the image to USB stick was similarly easy as it was for Fedora.  Simply choose the image file to write, the target device to write it on, then hit "go" and it does the magic for you.

Install Fedora 17

Once I worked around the kernel panic bug I mentioned above and booted with a later F17 image, the installation process was a fairly familiar affair.

With the new PC being a UEFI box there was no need to add the GPT partition when partitioning the SSD. I simply created one large root partition and a 4GB swap partition, leaving half the disk unallocated for the Win7 install later.

Since I didn't boot from the KDE spin image, I swapped out the default Gnome desktop (I've tried hard for a long time to Like Gnome 3 but I just don't so I'm moving back to KDE) and did a lot of package selection using the installer to save me messing around later but also to optimise the amount of data downloaded since I would be installing over my ADSL connection.

Once tip when installing Windows after Linux these days is to ensure the os-prober RPM gets installed.  This was done by default for me.  This package allows grub to detect the presence of other operating systems and add boot entries for them in the grub menu.  It'll come in very handy later on...!

SSD Optimisations for Linux

Even with a distribution as current as Fedora 17, the settings chosen for SSD usage are really rather sub-standard.  There are a lot of handy tips and guides out there for which settings you should change or add to the system to enhance both the performance and longevity of your SSD.  I decided to go with the rather comprehensive information provided for the Arch Linux distribution as they have a great wiki page on SSD optimisation.

Update /etc/fstab

Add the "noatime" and "discard" options to SSD partitions.  The discard option is the really super-important one as it turns on TRIM.

Mount /tmp as tmpfs by adding a line similar to the following:

Doing this allows the system to write temporary files to RAM instead of the SSD.  This will improve performance (RAM is faster than SSD) and reduce writes to the SSD (improving the life of the SSD).  I've added an option to increase the allowable size of the tmpfs file system to 75% of RAM from the default of 50%.  This means I can run compilations or other intensive tasks in RAM without ruining the SSD and get the performance benefits too.  With 16GB main RAM, this will allocate up to 12GB for my /tmp directory.  In normal usage I wouldn't expect to use anywhere near this but it's nice to have it there for when I'm not running too many apps but doing something else such as compiling RPMs.

Change the Scheduler

Optimise Kernel Parameters

With 16GB main RAM I'm not expecting to do much in the way of swapping.  However, I did add a couple of lines to /etc/sysctl.conf to make the system less likely to do so:
  # make the system less likely to swap
  vm.swapiness=1
  vm.vfs_cache_pressure=50

Install Windows 7

Similarly to the F17 install, the Win7 install proceeded with little in the way of drama.  I did select the advanced install option when given the chance but that was just to ensure Win7 installed into the free space I had left on the SSD rather than rudely splat my shiny new F17 installation.

And yes, for those of you wondering why I'm installing Win7 at all, especially dual boot rather than in a VM, it's simply for those times when only Windows will do... so gaming mostly I should think.

There's not much else to do with Windows after installation.  Unlike current Linux distributions it's said to  detect the presence of an SSD drive and apply the appropriate optimisations automatically.  Whether this is entirely true or not I suspect I'll never be any the wiser to.

Update the Boot Loader

PCs boot first using a system known as a BIOS (basic input output system), that's the bit you might see when you very first switch on your computer and might say something like "Press F1 to enter system menu" or similar. The BIOS is responsible for knowing enough about your hardware such that it can start the computer, run your boot loader and ultimately pass on some information to your operating system which takes over control of the hardware. The Joggler doesn't boot using the mechanism most of us as PC users are familiar with, however, abandoning the BIOS in favour of EFI (extensible firmware interface). EFI is much bigger, more flexible and inevitably a lot more complicated than the older BIOS system. I'll attempt to unravel in simple terms some of the mysteries of booting your own operating system on the Joggler here.

EFI has its roots in Intel in the same way as a BIOS has its roots in IBM.  Basically, it consists of a set of executables able to run within the simple environment EFI provides.  These executables are just little computer programs that can vary extremely widely from talking to a piece of your hardware to providing you with a shell environment in which you can interact with EFI through to booting your operating system.  This last function is quite important to us as computer users if we're to understand how EFI is used to start your machine, in this case your Joggler.  A BIOS will boot your machine by looking at the master boot record and starting the boot loader that your installed operating system has put there; your operating system is responsible for booting itself.  EFI does away with this, moving the responsibility for booting operating systems into the firmware interface itself, you no longer need a boot loader for your operating system.  Instead, the boot loader is now just another EFI program that runs within the simple EFI environment I mentioned earlier.

You've been wondering what this FAT partition on your Joggler image is all about?  FAT is just another file system like NTFS for Windows or ext for Linux, it's very widely understood so is commonly used these days on USB sticks but not necessarily many other places.  If your disk is to be used to boot an operating system then EFI says you need a FAT file system as the first partition of that disk.  EFI actually says FAT12 or FAT16 must be used for "removable media" so for us Joggler users with USB sticks or hard disks we should be using FAT16 even though EFI can understand FAT32 as well.  You could boot any other disk from your FAT partition but all the simple Joggler cases would just involve booting an operating system somewhere else on the same disk i.e. the second partition.

Fortunately for us, when you start your Joggler its EFI looks both at its internal disk (the one with the O2 interface on it) and removable media (your USB disk).  The FAT partition is discovered on your USB disk and by convention the file called startup.nsh is executed.  This file is simply a script which can be used to execute any EFI script commands you wish.  For Joggler USB booting it just runs a local script on your disk to start your boot loader EFI program.

So for the Joggler we might have something like this in startup.nsh on our disk in order to call the boot.nsh:
fs1:boot2
fs0:boot

And the following in the file boot.nsh to start the grub EFI boot loader program:
fs1:
grub

You now know what to do in order to boot your Joggler from a USB disk but the final missing piece to the puzzle is the EFI boot loader program itself. In the example above I used grub as the boot loader program. Yes, this is the same grub you're familiar with from booting Linux on BIOS based machines. However, in this example it's an EFI program so you'd be right to be wondering how you go about getting a copy of it.  In my example here your FAT partition already has 2 files on it (startup.nsh and boot.nsh) and you'll need another 2 files (grub.efi and grub.cfg) to be able to boot your disk

There are two versions of grub.  The old version, grub 1 or grub legacy as it's know known is not the one you want.  You're looking for the current version which is (or will become) grub 2.  At the time of writing grub 1.98 is the latest version, download the released version.  Unfortunately, it doesn't work on the Joggler without applying a patch.  So it's with thanks and reference to the guys over at Joggler Hacks I got my Joggler booting with my own grub 2.

To compile an EFI version of grub 2, unpack the source you've downloaded, then apply the Joggler grub 2 patch (using patch -p1), run ./configure --with-platform=efi and make.  The compilation should proceed through to completion leaving you just finish off by making the grub EFI program.  You can do this with ./grub-mkimage -d . -o grub.efi part_msdos hfsplus fat ext2 normal sh chain boot configfile linux.  The file grub.efi will be created and you can copy this to your FAT partition.

The one remaining thing to do is create the grub configuration file.  In grub 2 this is called grub.cfg and can be put in the root directory of your FAT partition with the other three files already there.  If you've got your root file system on your second partition then the following should be enough for you to boot it:
set timeout=0
menuentry "Linux" {
set root=(hd0,1)
linux /vmlinuz root=/dev/sda2 acpi=force ro idle=halt
initrd /initrd
}

This configuration requires your kernel (vmlinuz) and ram disk (initramfs or initrd) to be on the FAT partition too.   The final piece to the puzzle is to copy these files from your installed version of Linux in the second partition from the /boot directory.  With all six files in place on the FAT partition you're all set to boot the OS on the second partition.  Most recent versions of Linux should at least boot on the Joggler. However, the Joggler does have some interesting hardware which may not be optimally supported.  Hence, for the quickest out of the box working system you're still better off using a pre-built image from someone else as now you've got the thing booted the hard work is only about to begin.

You can find a lot more of my information about the Joggler at my Joggler Index post. I also have a list of Joggler Bookmarks.