Tri-Boot Refresh - Mountain Lion, Windows 8 and Fedora 18

This post has been a long time coming. Over the course of several months I spent the odd morning here and there attempting to build a new tri-boot machine for myself. My previous machine was still running Snow Leopard, Windows 7 and Fedora 14 and in dire need of upgrading. However, I was certain that an upgrade of OS X would destroy my carefully constructed partition table, which is why I opted to build a new machine so as to be able to continue to do my job!

Now, you might be wondering why it took so long for me to implement such a system, especially as I had already been through the process once before. The delay was caused by my initial insistence on a pure EFI/GPT booting solution; I wanted all three operating systems to boot via EFI and not rely on the Mac's hybrid GPT/MSDOS partition table and legacy boot options.

The main problem that I continually encountered was successfully booting Windows 8 via EFI. I tried several methods of installing the Microsoft OS, all of which failed to produce a bootable system:

• Booting directly off the DVD (by holding down although and selecting the "EFI" option). This resulted in the screen blanking and a spontaneous reboot before the installer even fully loaded.
• Following a well documented process that involved partitioning the disk using a WinPE environment and installing Windows via the dism tool that's distributed as part of the Microsoft Automated Deployment Kit. While this bypassed the initial Windows Setup step routine, I still experienced a similar issue; the screen blanked, the system rebooted and booting off the Windows partition again resulted in the following message:
  
  The computer restarted unexpectedly or encountered and unexpected error. Windows installation cannot proceed. To install Windows, click "OK" to restart the computer, and the restart installation.
  
  Grabbing the minidump from the partition and parsing it through the WinDBG tool pointed the finger at the Intel integrated GPU driver igdkmd64.sys.
• After the above discovery, I tried tweaking hardware prior to booting the operating system by issuing commands in the EFI shell provided by rEFIt. Specifically, to try and force the Nvidia GPU to be active during the initial boot. This got me a little further through the install process, but still eventually resulted in a system crash caused by the igdkmd64.sys.
• As a final attempt, I followed a suggestion to strip out the integrated graphics drivers after deploying the OS image. However, this also proved unsuccessful, even when combining this method with the previous technique of modifying the hardware settings via EFI shell.

Even after all the above failures, I was still keen to get this triple boot implementation working, but I was finally convinced to let the idea drop when I read some notes from people who stated that audio was known not to work with Windows instances booting via EFI. Given that my primary reason for having a system that boots Windows was to play games, it would have been terrible to sacrifice audio for the sake of possible faster boot times!

The Installation Process

After I made the decision to resort to the hybrid GPT/msdos partition table method, installation was much the same as before, with a couple of extra steps to carry out during the Linux install. I'll do my best to detail the process here, in case there are any brave souls out there willing to give it a go! I shouldn't have to say this, but this is a destructive process, so be sure to back up anything important first and be aware that your mileage may very, depending on the Apple hardware you're using (my current machine is a MacBook Pro 6,2)

1. Boot from the OS X installation media and use Disk Utility to create the following partition scheme (these sizes can obviously be varied, depending on your priorities):
   1. Size: 80GB, label: "OS X", FS Type: HFS+, journaled, case sensitive (my personal preference, the default is case insensitive)
   2. Size: 250GB, label: "WINDOWS", FS Type: msdos
   3. Size: 1.07GB (the smallest sized partition the GUI driven Disk Utility tool is able to create), label "BOOT", FS type: msdos
   4. Size: 20GB, label: "ROOT", FS type: msdos
   5. Size: 229GB (the remaining space), label: "LVM", FS type: msdos
2. Exit Disk Utility and begin the installation, selecting the OS X partition when prompted.
3. A dialog box will appear warning that the File Vault (probably the Full Disk Encryption mode)and the Recovery Mode will not be available; probably due to the installer not wanting to trash the complex partition scheme. Confirm you're happy to live without these features to continue the installation routine.
4. Once OS X installed, install the rEFIt bootloader to facilitate booting the other operating systems and their installers. NB: it might take a reboot or two for the bootloader to appear.
5. Insert the Windows 8 DVD and reboot the machine.
6. Boot off Win 8 DVD by CD/DVD labelled "Windows". This boots the installer using the legacy/BIOS mode of the Mac.
7. Now, it may be possible at this point to follow the usual Windows installation routine; answering questions as prompted and clicking next. However, due to all the problems I had with trusting installation Wizards, I opted to hit Fn-shift-F10 to spawn a command prompt and perform the installation manually. Technically, just shift-F10 is the necessary key-combination to bring up a command prompt, but on a Mac the function keys are by default bound to other specific purposes (volume control, screen brightness, etc.), so using the Fn (or function) key is necessary to access the regular function keys.
   1. Run Microsoft's command line partitioning tool: diskpart
   2. To be sure of the installation drive, list the available disks: list disk
   3. Select the destination drive (usually disk 0): select disk 0
   4. List the available partitions to be sure the intended destination: list partition
   5. Select the destination partition (in this case, it should be number 3): select partition 3
   6. Format the partition as NTFS: format quick fs=ntfs label=Windows
   7. Exit the partition tool: exit
   8. Change directory to the root of the X: drive. This is necessary to access the version of the Dism tool that can apply the OS image: cd \
   9. Run the Dism tool to apply the Windows 8 image (in this case, the Professional edition):
      dism /apply-image /imagefile:d:\sources\install.wim /index:1 /applydir:c:\
   10. Change directory to the root of the new installation: c:
   11. Configure the Windows boot loader: bcdboot c:\Windows /l en-gb /s c:
   12. Exit/close the command prompt.
   13. Exit/close the Windows installer, which results in the Mac rebooting.
8. Select the icon of the Windows logo to boot into the OS and finalise the installation as per usual (configuring user accounts, etc.).
9. Eject the Windows DVD and insert the Fedora DVD.
10. Reboot.
11. Select the CD/DVD icon.
12. Once the installer has completed booting, switch to an alternative virtual console by pressing Fn+ctrl+alt+F3, as it is necessary to create the layout of your LVM volumes before continuing with the installer:
    1. Launch the LVM tool: lvm
    2. Designate the last partition on the disk as an LVM Physical Volume (PV): pvcreate /dev/sda6
    3. Create a volume group: vgcreate vg_fedora /dev/sda6
    4. Create a volume for the /tmp file system: lvcreate -L 1G -n tmp vg_fedora
    5. Create a volume for the /var file system: lvcreate -L 1G -n var vg_fedora
    6. Create a volume for the /home file system: lvcreate -L 1G -n home vg_fedora
    7. Exit the tool and return to the installer by pressing the keys Fn+alt+F7.
13. Proceed as normal through the installation, using the previously created 20GB partition for the root (/) volume and LVM volumes for their respective mount points. One very important note: when selecting the disk for installation, be sure to not install a bootloader, as per the instructions in the Fedora manual. During my initial attempts, this would always fail and prevent the installation from completing successfully; it needs to be carried out manually post-install.
14. Once the installer completes, allow it to reboot the system.
15. Select the CD/DVD icon.
16. At the Linux boot prompt, navigate to and select the rescue system option.
17. Let the rescue system boot, detect and mount the installed instance of Fedora.
18. Select the shell option to be dropped to the command line.
19. Change root to the mounted install: chroot /mnt/sysimage
20. Generate a GRUB configuration: grub-mkconfig -o /boot/grub/grub.cfg
21. Install GRUB to the HDDs boot sector: grub2-install --recheck /dev/sda
22. Reboot and select the penguin icon to boot into Fedora and complete the initial setup of the OS.

If you've managed to follow all these steps, hopefully you're lucky enough to possess a triple boot machine! Some noteworthy points about the the above steps and the setup as a whole are as follows:

• If you run into a situation where either Windows or Fedora will not boot, it may be necessary to run the rEFIt sync tool. When booting it's one of the options below the available operating systems and it repairs the hybrid partition table after the use of a partitioning tool that's not aware of it's existence.
• After installing Fedora, trying to boot Windows via rEFIt will result in the GRUB bootloader appearing! However, the Windows install is an option here, simply select it to boot the OS.
• I found out about how to manually install GRUB by following steps I found on the Arch Linux wiki.

Feel free to sound off in the comments if you have anything to add, or you've tried the process yourself and hit a snag, I'd be happy to try and help.

Fedora 18 Xorg Segmentation Fault - NVidia Driver Configuration

I just encountered an extremely odd issue with my Fedora 18 this morning:

• First, I noticed that the grey background of the log in screen had been replaced by the blue "falling stars" image that's the default desktop wallpaper for the OS.
• Secondly, when logging into my usual Cinnamon session, the menu bar had switched from the Windows-esque "start" menu located at the bottom of the screen to a Gnome 2.x style menu at the top.
• Finally, when I tried to navigate to Delicious in Google Chrome, the screen blanked and returned to the log in menu!

Checking the Xorg log file showed a segmentation fault had occurred:

[ 192.214] (EE)
[ 192.215] (EE) Backtrace:
[ 192.230] (EE) 0: /usr/bin/Xorg (OsLookupColor+0x139) [0x472509]
[ 192.230] (EE) 1: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x3f6080efff]
[ 192.230] (EE)
[ 192.230] (EE) Segmentation fault at address 0x0
[ 192.230]
Fatal server error:
[ 192.230] Caught signal 11 (Segmentation fault). Server aborting
[ 192.230]
[ 192.230] (EE)
Please consult the Fedora Project support
at http://wiki.x.org
for help.
[ 192.230] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 192.230] (EE)
[ 192.236] (II) evdev: Power Button: Close
[ 192.236] (II) UnloadModule: "evdev"
[ 192.243] (II) evdev: Power Button: Close
[ 192.243] (II) UnloadModule: "evdev"
[ 192.257] (II) evdev: Sleep Button: Close
[ 192.257] (II) UnloadModule: "evdev"
[ 192.274] (II) evdev: Apple Inc. Apple Internal Keyboard / Trackpad: Close
[ 192.274] (II) UnloadModule: "evdev"
[ 192.318] (II) UnloadModule: "synaptics"
[ 192.332] (II) evdev: Built-in iSight: Close
[ 192.332] (II) UnloadModule: "evdev"
[ 192.345] (II) evdev: Logitech USB Receiver: Close
[ 192.345] (II) UnloadModule: "evdev"
[ 192.367] (II) evdev: Logitech USB Receiver: Close
[ 192.367] (II) UnloadModule: "evdev"
[ 192.877] Server terminated with error (1). Closing log file.


Thinking this would be some strange transient error, I logged in again and found that I was able to replicate the issue by simply visiting delicious.com again! Googling around on the subject pulled up a couple of forum posts that suggested adding / amending the Files section in the /etc/X11/xorg.conf file to the following:

Section "Files"
  ModulePath "/usr/lib64/nvidia/xorg"
  ModulePath "/usr/lib64/xorg/modules"
EndSection


Once I restarted the X Server, I was greeted by the original log in screen with the grey background. Logging into the system yielded another success: my Windows-style menu had returned! The final check was also a success: I was able to visit delicious.com without the X Server crashing.

Screensaver Images

Following on from my previous post about desktop backgrounds, I thought I should detail how I've been able to change the images used by various screensavers. This used to be a very simple task in earlier versions of Fedora; you were able to choose which images you wanted to use when you selected a relevant screensaver.

However, the default GNOME preferences window for configuring screensavers no longer provides this option, leaving you stuck with the images provided by your distribution.

Most implementations of the X11 Window System use xscreensaver, and the majority of the screensavers in Fedora are actually part of this package. The GNOME project has it's own program called gnome-screensaver, which has it's own configuration utility and daemon while using the screensavers from the xscreensaver package. The evidence for this can be found in the Fedora package manager; if you search for "screensaver", you will see that for every xscreensaver package there is a corresponding gnome-screensaver compatibility package.


Searching online, I found the solution to my problem was actually very simple: manually run the xscreensaver configuration utility from the command line, choose the images you want and exit. So, on my laptop, I took the following steps:

1. Executed the following command in a terminal: xscreensaver-demo.


2. Ignored the warning about the GNOME screensaver daemon and clicked "cancel".
   
   


3. Opted not to launch the xscreensaver daemon by clicking "cancel".
   
   


4. Selected the "Advanced" tab.
   
   


5. In the "Image Manipulation" section, I ensured only the "Choose Random Image" option was selected, and specified the directory containing the images I wanted to use.


6. Closed the utility.


7. Confirmed the changes by using the preview option in GNOMEs own screensaver preference utility.

The xscreensaver utility also provides further configuration options, such as choosing a source of text for those screensavers that require this. I did cause the application to crash while testing, so your mileage may vary.

One last noteworthy point if you're a Mac user, xscreensaver has been ported over to OS X and a DMG is available to download from the projects site.

Cycling Desktop Wallpaper in Gnome

I have found a couple of good applications for configuring a Gnome desktop wallpaper/background to cycle among a specific set of images.

Gnome Wallpaper Slideshow
This lightweight utility is simply a python script that renders a GTK+ GUI allowing you to choose a directory containing images, as well as set picture and transition durations.


Once you confirm your choices, it writes an xml file out to ~/.gnome-wallpaper/gnome-wallpaper-slideshow.xml, which is used by the Gnome to render the desktop. It also outputs a plaintext file to ~/.gnome-wallpaper/gnome-wallpaper-slideshow.config that records the options selected in the GUI so it's able to reload them next time you run the script. As soon as you've exited the application, you'll notice your desktop change and begin cycling through the images.

The only issue I found was not being able to set a preference for how I wanted to fit my images to the desktop; i.e. whether they should be centred, tiled, stretched, etc. Instead, Gnome simply resizes the images to fit the desktop. This was a problem for me as some of the images I had chosen were not the same size as my desktop and looked odd when scaled.

Wallpapoz
I found this application to be a bit more full-featured: it's possible to define a different image for each desktop, as well as specify your preference for whether an image should be scaled to the size of the desktop, used as a tile, or displayed at it's original size. On top of that, the software is available from the Fedora yum repository, so installing it was as simple as typing yum install wallpapoz into a terminal as root.
Once installed, you can access the program through the Gnome Applications menu (Applications -> Accessories -> Wallpapoz).


You are able to add directories or individual files to cycle through, while the preferences window gives you access to the more advanced functions.


Out of the two applications, I initially preferred gnome-wallpaper-slideshow because it was so lightweight. However, I eventually opted to use Wallpapoz, because of the image scaling issues I mentioned earlier.

Triple-Boot MacBook Pro: OS X, Windows 7 and Fedora 13

I have finally been able to install (and, more importantly, boot) 3 distinct operating systems on my work laptop; a MacBook Pro 3,3. I have been using my Mac in a dual-boot configuration for several years now; booting between OS X and Fedora. Being able to boot into OS X has allowed me to apply any new firmware released as part of an Apple Software Update, as well as providing a quick-booting OS for basic web browsing (less so now with the advances made in the Fedora distribution and Linux in general).

Having used Windows 7 on my home PC for some time, I decided that this would be the version of Windows that I would endeavour to install on the Mac alongside the other two operating systems. I've found Windows 7 to be a great improvement over Vista and, dare I say it, actually an enjoyable desktop OS to use. Of course, Windows 7 would also allow me to fully partake in any gaming sessions that I happened upon while I had my laptop! However, the most compelling reason to get my Mac triple-booting was to learn more about GPT, EFI and the boot process in general on an EFI-based system.

Obviously, the first step I took was to ensure I had a recent backup of all the important data from my machine, as I would be completely trashing the existing partition table. Once I had done this, I began the installation of the first operating system.

OS X


I inserted the Snow Leopard installation DVD into the machine and booted from it. From the installer, I accessed the Disk Utility and created a new GPT partition scheme consisting of 4 partitions (well, technically 5, see below for further details):

1. OS X: 90GB, HFS+, Journaled and Case-Sensitive


2. WIN7: 120GB, MSDOS


3. LINUX: 3GB, MSDOS


4. LVM: Remaining Space, MSDOS

I then exited Disk Utility and continued with the installation of the operating system, directing the installer to use the "OS X" partition.

Windows 7


As the laptop uses an Intel Core 2 Duo CPU, I opted to install the 64bit version of Windows 7 Professional. When choosing where to install the operating system, the partitioning tool displayed a rather different view to the OS X Disk Utility; a small FAT partition (used by EFI) was positioned in front of the OS X partition, while some of the drive was marked as unallocated space. I carefully selected the 3rd partition, confirming I had the correct one by looking at it's label (WIN7) and size (approximately 120GB), and formatted it using the "Advanced" features of the partitioning tool. This is a necessary step, as the OS X Disk Utility formats the file system as FAT32 and Windows 7 requires NTFS. After this, I proceeded to select the partition I had just formatted and installed the OS.
During the installation process, the machine had to reboot, which meant I had to ensure that it booted from the Windows 7 partition in order to complete the install. On a Mac, this is accomplished by holding down the "alt" key on the keyboard when the system first boots. It causes a basic boot manager to eventually be displayed, where you can select which of the installed operating systems to boot.

Fedora 13


Finally, I booted off the Fedora 13 installation disc (again, opting for the 64bit release). When I was presented with the partitioning tool, I found I had to manually format the 4th partition as ext3 and the 5th partition as an LVM physical volume using the command line. This involved switching to another virtual console, which on a Mac requires you to hold down the "fn" and "alt" keys and press "F2". From here, it is possible to use the mkfs.ext3 and lvm command line tools to format /dev/sda4 partition, create an LVM physical volume on /dev/sda5, a volume group and some volumes.
Again, I had to be wary of choosing the wrong partitions because, as with the Windows 7 installation, the tools displayed a more complicated view of the partition table; the EFI partition and un-partitioned space were visible.
Once I had finished on the command line, I switched back to the graphical installer ("fn", "alt" and "F7") and instructed the partition manager to use /dev/sda4 as the root partition and the newly created LVM volumes for /usr, /tmp, /var, /home and swap. It's important to note that I didn't define a separate /boot partition; this is because I wanted to keep the partition scheme as simple as possible, see below for details.
When the installer reached the stage where you define where GRUB should be installed, I found that the suggested default option was what I needed; /dev/sda4. This is different to a more vanilla install of Fedora, where you would usually install GRUB to the Master Boot Record (MBR); here, there is no MBR to install to as the partition scheme is GPT.

Final Steps

After the Fedora installation completed, I rebooted into OS X (by simply not pressing anything when the machine initially boots) and installed rEFIt. This appears to be the only bootloader that would allow me to boot all three installed operating systems. I had to run the rEFIt partitioning tool before this was possible however; accessible when rEFIt loads at boot-time. This performs the necessary magic that syncs the hybrid GPT/MBR partition table, allowing each OS to boot correctly. I had to perform one final restart of the machine, which is another option in the rEFIt bootloader, and then my triple-boot Mac was complete; apart from all the subsequent OS updates and configuration, of course!

Troubles Encountered and Lessons Learnt

As mentioned previously, this install procedure took me several attempts to get right. I tried using boot camp originally, but soon found that it added unnecessary complexity to the partitioning process. I also found some guides that demonstrated methods for partitioning the disc using the Disk Utility in OS X, but this assumed an existing OS X installation was present on the system. However, as this second approach mentioned the use of Disk Utility, I assumed that using this tool to create the partition scheme for all the operating systems would work; and I was correct!

While on the subject of partitioning, I did end up discovering exactly how the hybrid GPT/MBR partition table works. OS X itself requires a GPT partition scheme; it simply refuses to install to any MBR-style disk. However, Windows requires an MBR partition scheme to boot from and will refuse to install into a partition that it believes resides on a GPT formatted disk.

The hybrid GPT/MBR scheme allows the first 4 partitions of the GPT scheme to be used as an MBR-style disk. However, it is not possible for one of these partitions to be created as an extended partition. On a pure MBR disk, you are restricted to defining 4 primary partitions. One of these can be used to hold further logical partitions, which allows for more complicated partition schemes (i.e. more than 4 partitions).

Because GPT does not allow for extended and logical partitions to be defined, a hybrid implementation limits the MBR scheme to 4 primary partitions. On top of that, because we're booting an EFI based system, there is a hidden FAT32 partition at the beginning of the disk where boot configuration is stored. This brings the total number of MBR partitions available for operating systems to 3; hence why my 2nd, 3rd and 4th partitions are used by OS X, Windows 7 and Fedora's root/boot file systems respectively. Theoretically, it should be possible to install a Linux distribution into higher numbered partitions, however the GRUB boot loader used by Fedora only understands MBR, not GPT. In order to maintain some file system organisation, I created the 5th partition as an LVM logical volume, bringing all the flexibility of resizeable volumes to the Fedora install.

The other major issue encountered was actually booting off the Windows 7 install DVD. I had sourced a copy of Windows 7 Professional 64bit from the Microsoft Partner program site; which resulted in a rather large ISO image being downloaded to my machine. After burning this to DVD and attempting to boot off the disc, I found I was unable to progress past what appeared to be a broken boot menu. There were 2 options, however, both were lacking any explanation as to what it was I would be booting into! On top of that, neither option appeared to want to boot, and I was left with the impression that the system had actually crashed.

I did some research and found that the problem because of the way the image was mastered. Apparently, some important component used in the boot process is not able to handle files that conform to the ISO 9660 standard; specifically, version numbers being appended to the file name.

This made it necessary to re-master the provided image and burn it with some rather specific settings; the most important seemed to be force the omission of the version numbers (see the previously linked blog post for further details). Once I did this, the laptop booted from the disc perfectly.

Overall, I'm very pleased with the fruits of my labour. The real test will be to see if I can replicate the results on another machine.

Adobe Flash Plugin on Fedora 13 x86_64

I upgraded my work laptop to Fedora 13 over the weekend. As always, I was impressed with the new features and desktop theme! In order to extend the core system's functionality, I used the Personal Fedora 13 Install Guide. There has been a version of these guides produced for each release of Fedora as far as I'm aware and they're a great resource for adding all the additional apps and utilities you might need to a fresh install of Fedora.

When I tried to install the Adobe Flash Plugin, I followed the guide as usual (in fact, I've performed the installation of the plugin on Red Hat systems so many times, it has become second nature). However, I was greeted by an error message:


Transaction Check Error:
package nss-softokn-3.12.4-19.fc13.x86_64 (which is newer than nss-softokn-3.12.4-17.fc13.i686) is already installed


There appeared to be a clash between the 64bit (x86_64) and 32bit (i686) versions of the nss-softokn package. When installing 32bit software on a 64bit distro release, you often have to install some additional 32bit libraries to support the application in question. In this case The 32bit version of the nss-softokn package was required in order for the 32bit Flash plugin to be installed.

A bit of searching online revealed that the workaround was to simply downgrade the 64bit nss-softokn package to the same version as the 32bit package that yum was attempting to install:


[root@redpill ~]# yum downgrade nss-softokn-3.12.4-17.fc13
Loaded plugins: presto, priorities, refresh-packagekit
Setting up Downgrade Process
4 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package nss-softokn.x86_64 0:3.12.4-17.fc13 set to be updated
---> Package nss-softokn.x86_64 0:3.12.4-19.fc13 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================================================
Package Arch Version Repository Size
=====================================================================================================================
Downgrading:
nss-softokn x86_64 3.12.4-17.fc13 fedora 168 k

Transaction Summary
=====================================================================================================================
Remove 0 Package(s)
Reinstall 0 Package(s)
Downgrade 1 Package(s)

Total download size: 168 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 168 k
nss-softokn-3.12.4-17.fc13.x86_64.rpm | 168 kB 00:02
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : nss-softokn-3.12.4-17.fc13.x86_64 1/2
Cleanup : nss-softokn-3.12.4-19.fc13.x86_64 2/2

Removed:
nss-softokn.x86_64 0:3.12.4-19.fc13

Installed:
nss-softokn.x86_64 0:3.12.4-17.fc13

Complete!


--------------------------------------------------

[root@redpill ~]# yum install flash-plugin
Loaded plugins: presto, priorities, refresh-packagekit
4 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package flash-plugin.i386 0:10.1.53.64-release set to be updated
--> Processing Dependency: libsmime3.so for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libsmime3.so(NSS_3.4) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libssl3.so for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libsmime3.so(NSS_3.2) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnss3.so(NSS_3.11) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnss3.so(NSS_3.9.2) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnspr4.so for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnss3.so(NSS_3.2) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libssl3.so(NSS_3.2) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnss3.so(NSS_3.6) for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libplc4.so for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libnss3.so for package: flash-plugin-10.1.53.64-release.i386
--> Processing Dependency: libplds4.so for package: flash-plugin-10.1.53.64-release.i386
--> Running transaction check
---> Package nspr.i686 0:4.8.4-2.fc13 set to be updated
---> Package nss.i686 0:3.12.6-4.fc13 set to be updated
--> Processing Dependency: nss-softokn(x86-32) = 3.12.4 for package: nss-3.12.6-4.fc13.i686
--> Processing Dependency: libnssutil3.so(NSSUTIL_3.12.3) for package: nss-3.12.6-4.fc13.i686
--> Processing Dependency: libnssutil3.so for package: nss-3.12.6-4.fc13.i686
--> Processing Dependency: libnssutil3.so(NSSUTIL_3.12.5) for package: nss-3.12.6-4.fc13.i686
--> Processing Dependency: libnssutil3.so(NSSUTIL_3.12) for package: nss-3.12.6-4.fc13.i686
--> Running transaction check
---> Package nss-softokn.i686 0:3.12.4-17.fc13 set to be updated
---> Package nss-softokn.x86_64 0:3.12.4-19.fc13 set to be updated
---> Package nss-util.i686 0:3.12.6-1.fc13 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

=====================================================================================================================
Package Arch Version Repository Size
=====================================================================================================================
Installing:
flash-plugin i386 10.1.53.64-release adobe-linux-i386 4.5 M
Installing for dependencies:
nspr i686 4.8.4-2.fc13 fedora 112 k
nss i686 3.12.6-4.fc13 fedora 741 k
nss-softokn i686 3.12.4-17.fc13 fedora 169 k
nss-util i686 3.12.6-1.fc13 fedora 45 k
Updating for dependencies:
nss-softokn x86_64 3.12.4-19.fc13 updates 168 k

Transaction Summary
======================================================================================================================
Install 5 Package(s)
Upgrade 1 Package(s)

Total size: 5.7 M
Total download size: 168 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 168 k
nss-softokn-3.12.4-19.fc13.x86_64.rpm | 168 kB 00:01
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : nspr-4.8.4-2.fc13.i686 1/7
Installing : nss-util-3.12.6-1.fc13.i686 2/7
Updating : nss-softokn-3.12.4-19.fc13.x86_64 3/7
Installing : nss-softokn-3.12.4-17.fc13.i686 4/7
Installing : nss-3.12.6-4.fc13.i686 5/7
Installing : flash-plugin-10.1.53.64-release.i386 6/7
Cleanup : nss-softokn-3.12.4-17.fc13.x86_64 7/7

Installed:
flash-plugin.i386 0:10.1.53.64-release

Dependency Installed:
nspr.i686 0:4.8.4-2.fc13 nss.i686 0:3.12.6-4.fc13 nss-softokn.i686 0:3.12.4-17.fc13 nss-util.i686 0:3.12.6-1.fc13

Dependency Updated:
nss-softokn.x86_64 0:3.12.4-19.fc13

Complete!
[root@redpill ~]#



After restarting my browser, I was able to access Flash content online. The package manager even prompted me afterwards to upgrade the 64bit version of the nss-softokn back to version 3.12.4-19 and doing so seemed to have no impact on my ability to view Flash content.

Getting Back to Your Root(s)

After performing an upgrade of my work laptop from Fedora 11 to 12, I needed to restore access to my virtual machines. My upgrade consisted of booting off the installation media and wiping all the partitons and volumes that didn't contain important data, essentially leaving me with a fresh install of Fedora 12.

As I had originally built the machines using logical volumes as the virtual disks, the VMs were untouched by the Fedora upgrade. However, the / partition of my Fedora installation had been overwritten and the VM definitions were lost, which meant that I was presented with a blank virtual machine manager when I opened the tool.

I ran through the wizard for creating new virtual machines and when prompted to define the storage to use, I simply used the relevant logical volumes from my local hard disk. When I tried to boot the VMs, however, the process only got so far before a kernel panic would occur, with the following error message:


mount: cannot find "dev/root"

After some investigation, I realised that the VMs were configured to present the virtual disks to the instances as virtio devices. The machines had originally been instantiated using virtual IDE disks, so I modified their current configuration to reflect this.



This time when I powered on the machines, they booted successfully and I was able to get on with the original task I had in mind. However, this wouldn't help me should I end up in the same situation again following another upgrade / rebuild. The reason why the system failed to boot in the first place was that the initial ramdisk image did not contain the relevant modules to allow the kernel to recognise the virtio disks. The initial ramdisk image is used to store the kernel modules required to allow a booting system to locate the root file system; a critical step!

In order to build a ramdisk image, I had to reconfigure one of the VMs so that the disk was presented as a virtio device again and use CentOS installation media to boot into the available "rescue mode". This can locate and mount an existing Linux installation on the available storage at the mount point: /mnt/sysimage - this means that running the command chroot /mnt/sysimage places you inside a chroot jail, essentially allowing you to execute commands as if you had booted into the operating system as per usual.

The command to generate an initial ramdisk image requires two arguments:

mkinitrd <image_file> <kernel_version>

The first of these two arguments, <image_file>, is used to define the file output by the process of creating the ramdisk image. The second is the version of the kernel you are making the image for. I knew that my system would, by default, boot into the latest kernel present, so I simply listed the installed kernels to confirm the version. I made a copy of the existing ramdisk image stored in the /boot directory and executed the following command:

mkinitrd /boot/initrd-2.6.18-164.11.1.el5.img 2.6.18-164.11.1.el5

Once the command finished, I simply exited the rescue system and successfully booted the installed operating system!

GKrellM on MacBook Pro

I used to always install GKrellM on my machines as standard, but due to the number of machines I've been having to update and manage recently (work laptop, personal laptop, personal desktop, etc.) it's simply slipped my mind. That is, until recently...


I was performing some pretty CPU intensive tasks at work on my MacBook Pro (3,1); archiving data using 7zip and producing parity data for the resulting .7z files using PyPar2. I was using the top shell utility to monitor the CPU utilisation, but I fancied something a bit more graphical in nature, so I installed GKrellM. Running Fedora, all I needed to do was open a root terminal and type yum install gkrellm to get the software installed.

While configuring the application, I happened to enable to temperature monitors (out of interest). To my surprise, 10+ sensors were available (see the image to the left)! I'm not sure where each sensor is installed in the system, however, so I'll need to do a bit of digging around online to find out that information. Another nice surprise is that I'm able to monitor fan speed too; they're labelled "left side" and "right side" in the application.

I was pleased that this "just worked", because I've tried monitoring system temperature before on other machines, but it's not been as simple as switching it on in GKrellM. I didn't expect it to be so easy on a Mac!

Once I know more about what the temperature sensors are actually monitoring, I'll update the article!

Fedora 11 on PPC Mac Mini

When I needed to set up a monitoring station for our developers, I found an old G4 (PowerPC architecture) Mac Mini in the office that was simply gathering dust.

While the rest of the office Macs were being either upgraded or freshly installed with Snow Leopard, it wouldn't be possible on this little device, as the PowerPC architecture isn't supported by the latest release of their operating system. I could have installed the previous iteration of OS X, Leopard, but I decided to have a crack at installing a Linux distro on the machine.

My work-supplied laptop is a MacBook Pro that I have configured as a dual boot machine; OS X and Fedora 11 are the two options presented by rEFIt when I power it on. Additionally, we use CentOS 5.x as our primary hosting platform and I consider myself a Red Hat man, so I opted to go with the PPC version of Fedora 11. I downloaded the PPC net installation ISO image and began. Unfortunately, the installation wasn't without difficulty, as I'll explain.

Display Issues

When I first attempted to boot the installation disk, I held down the "c" key on the keyboard to boot from the optical drive and I was presented with the Linux bootloader. I hit return to continue and, after some information about available memory was printed to the screen, the display went completely blank. I could still hear the disk being accessed, so this was clearly a problem with the display driver.

I hit CTRL+ALT+DEL, which the installer gracefully caught and restarted the machine. But, after holding down the "c" key again, the machine wouldn't display the bootloader; instead I just had a blank screen! Worried that I might have damaged the graphics card, I rebooted the machine again, this time letting it boot into the existing OS X install. No white screen and Apple logo appeared and for a short while I thought I was going to have to simply label the device as "bricked". However, the OS X log in screen eventually appeared and I breathed a sigh of relief!

After a few more attempts at booting the Fedora install disc, each failing to display anything, I tried a Debian PPC install CD, which gave similar results. I can't remember why I thought to attempt this next step, but it appeared to work: I completely unplugged the Mini from it's PSU and left it for a few minutes. When I came back to it, I was able to boot off the installation media and see the boot loader. I tried to launch the Debian installer, but this had the same problem of failing to render anything to the display.

I tried booting the installer several times, using various options to alter the output to the monitor; for example, disabling the framebuffer, forcing a low resolution, etc. However, none of these appeared to work either.

I was actually thinking of giving up attempting to install a Linux distro on the machine when I had another thought: I had up until now been connecting to the monitor (a ViewSonic VG2030wm) using a DVI cable. So I tried using the, older, VGA connection to the monitor, which required the use of an Apple DVI-to-VGA adaptor as the Mac Mini only has a DVI output on the rear.

To my surprise, this actually worked! The initial bootloader appeared at a much lower resolution, however, when I hit return to begin installation the system managed to display the installer.

I actually still had the Debian media in the machine, so I ran through a basic installation of Debian to see if I could actually get it to boot into a working OS. This was successful and I managed to log into the Gnome desktop without any problem.

LVM Issues

I was still determined to install Fedora 11 on the box, so I rebooted the machine to attempt this. With the Mac Mini connected to the ViewSonic using the VGA cable, the installer launched without any issue and I proceeded to install the OS.

Everything was going well, until I reached the partitioning stage. As there was already a Apple BootStrap defined from the previous Debian install, I simply deleted the Linux partitions and created an LVM based install, with a partition for /boot, one for the root file system, one dedicated to swap, with another dedicated to be used as an LVM physical volume. After defining this partition scheme and all my logical volumes, I tried to continue to the next step in the installer, however, I was presented with the message: "You have not defined a boot partition".

After some reading through the Fedora PPC howto guide, I decided to recreate the Apple BootStrap partition. so I simply removed all the partitions and started from scratch. I created a 1MB Apple BootStrap partition (as suggested by the howto) and the rest of the partitions/volumes as before.

This time, when I hit "Next", the installer began to create all the relevant partitions and logical volumes. But I was again presented with an error; this time the installer had failed to create the volume group. This meant I had to exit the installation and reboot the machine.

After the reboot, I booted into the installer again, and hit CTRL+ALT+F2 to bring up another virtual console; this one is a basic shell you can use to assist in troubleshooting installations. Running the LVM command I inspected the configuration of the system. I immediately found that the installer had not actually run the appropriate commands to turn the specific partition into an LVM physical volume. I ran this command manually (pvcreate /dev/hda4) and then created the volume group too.

I then switched back to the installer console (ATL+F6) in an attempt to use the partitioning tool to assign the already existing partitions (/boot, root and swap) to their relevant roles and create the logical volumes I wanted to have. Unfortunately, the partitioning tool didn't appear to see the Apple BootStrap partition(s) that had been created previously and, as I suspected, I was unable to progress through the install as I was presented with the "You have not defined a boot partition" message again!

I could not see a way to get the system working with logical volumes and, by this time, I just wanted to get a working Fedora install, so I resort to merely creating basic partitions for the file systems I wanted. There is no room in the Mac Mini to install additional HDDs, so I wouldn't have the opportunity to extend my file systems in the future anyway!

After settling for this more basic configuration, the installation progressed without any further problems and I eventually managed to boot into a working install of Fedora 11.

Here's a pic of the machine in-situ; note the monitor in the picture is not the ViewSonic monitor that I described having trouble with in the article:


Summary

In summary, the issues I had with installing Fedora 11 on an Apple Mac Mini were:

• I experienced issues with ViewSonic VG2030wm monitor; the installer wouldn't display when using a DVI cable to connect to the screen. I needed to use a VGA cable in conjunction with a DVI-to-VGA adaptor.


• Issues creating logical volumes. It appeared that the installer had not executed the pvcreate command before attempting to create the volume group. I ended up resorting to a system based on standard partitions.

I hope this post can help others attempting to install Fedora (or any other distro) on the G4 Mac Mini. If nothing else, at least I can come back to it, should I need to install Linux on an old Mac Mini again.