Tag Archives: fedora

Fedora Linux and OSX Dual Boot on Mid-2010 (6,2) 15″ MacBook Pro Laptop

Posted on by

As part of the transition from a contractor to a full-time employee of Cox Media Group Digital & Strategy (check out our github), I’ve been issued a Mid-2010 (6,2) 15″ MacBook Pro laptop, to replace my current Early-2008 (3,1) MacPro desktop. The desktop is currently running Fedora 17, dual-boot with with Mac OS X (left in place for firmware updates and emergencies) using the rEFInd boot manager to choose between the two OSes. It took me two days to get this working right on my desktop, but it had been my plan to duplicate this setup on my laptop. I found a lot of conflicting information online, but I decided to give it a try.

Well, I have Fedora 18 and OS X 10.8 dual-booting on the laptop, but not as planned. After a day and a half of research, troubleshooting and re-installs, here’s what I found to actually work, in the hope that nobody else will go through the ordeal I went through. Following that are some notes about the new Fedora 18 installer (Anaconda 18), especially important for anyone who’s used Linux for a while. To those who are new to Linux, don’t be dissuaded by the above. Most of the frustration I experienced is because I’ve been using Linux for a relatively long time (about 10 years), had my own ideas about exactly how I wanted things setup (which are decidedly not supported by Fedora), and had some assumptions about the installation process based on earlier versions.

How to get it working:

Forget about rEFInd. This had been the original advice from Matthew Garrett, @mjg59, kernel coder, contributor to the Anaconda project, and all-around authority on booting Linux on EFI/UEFI hardware. My advice, and the method that worked for me:

  1. Shrink your Mac partitions and leave as much free space as you want for Fedora. using the Disk Utility tool in OS X (I also created an 8GB VFAT partition that both OSes can read/write to).
  2. Download Fedora 18 64-bit DVD image, I chose the KDE version. Verify the sha256 sum if you want (they don’t have a readily visible link to the checksum file. Copy the download link, paste it into your address bar and remove the filename. You should get a directory index that includes a -CHECKSUM file.
  3. Per the Installation Guide’s Making Fedora USB Media page, use liveusb-creator to setup the installation image on the USB flash drive (I needed to start it with the --reset-mbr option). You can also use other tools (dd if you’re not on a Fedora-based distro), or a DVD, but this is the method I chose.
  4. Due to a bug in liveusb-creator, you may need to manually edit /EFI/boot/grub.cfg on the created USB stick if grub gives you a file not found error. If that happens, please see my bug report above for the action to take (in short, you need to mount the USB stick, chmod u+w /EFI/boot/grub.cfg then edit that file and replace every occurrence of “isolinux” with “syslinux” and every occurrence of “root=live:LABEL=Fedora-18-x86_64-Live-KDE.iso” with “root=live:LABEL=LIVE”).
  5. Boot the USB drive (use the alt key when you turn on the laptop to select the USB drive) and just install Fedora normally, letting it do its thing. Select a boot disk and let it put GRUB2 on the EFI partition.

When you boot, it will boot to GRUB. There will be some options for Mac OS there, but they don’t work (more on that below). If you want to boot Mac, hold down the alt/option key when you power on the laptop, which will bring you to the boot disk selector and you can pick the Mac disk. I know it’s not pretty or ideal, but it’s the best option right now.

Making it Better:

GRUB2 tries to automatically detect other OSes and configure them in the boot loader (this is done through /etc/grub.d/30_os-prober, commonly just referred to as os-prober). It tries to boot Mac directly through the xnu_kernel64 module, which not only isn’t installed on the boot partition by default, but just doesn’t work with at least Mountain Lion (10.8). So getting GRUB to boot Mac means either having the bugs in the xnu module fixed, or figuring out how to setup a chainloader to boot from GRUB to Mac. The latter is probably the method I’ll investigate, but for now, since I rarely use Mac, I’m happy having to use the alt key at boot to get there. To remove the annoying, broken Mac OS options from the grub screen, run the following commands as root (they assume you have your EFI partition mounted at /boot/efi which I believe Fedora should do by default:

cp /boot/efi/EFI/fedora/grub.cfg /boot/efi/EFI/fedora/grub.cfg.bak
echo 'GRUB_DISABLE_OS_PROBER="true"' >> /etc/default/grub
grub2-mkconfig > /boot/efi/EFI/fedora/grub.cfg

Thoughts on the Fedora 18 Anaconda Installer

I found a couple of issues with the new Anaconda 18 installer that were either unweildy or confusing for someone who’s been installing Linux for a long time. Overall, the new installer is very nice. It has a clean, even elegant UI, a relatively nice flow from start to completion, and is certainly beginner-friendly. It has fewer options than any Linux installer I’ve ever used before – not even options for package selection, firewall or SELinux configuration, etc. – but I guess this is in line with the goal of making Fedora a desktop OS for the masses. I would have appreciated an “advanced mode” installer that was more like Fedora 17 (or even much older versions), but I guess I’m an edge case, at least in the Fedora community. However, I did find two things especially difficult, both related to the fact that my laptop has two main drives (a 500GB hard drive and a 120GB SSD):

First, the installer prompted me to select a “boot disk”. I guess I should have read the installation guide, but I assumed that nomenclature translated to either “which disk should the automatic partitiioning put yout /boot partition on” or “which disk should I set the bootable flag on in the partition table”. In fact, it means “which disk should I put GRUB on the EFI partition of”. I installed, rebooted, and was shocked – and somewhat distressed – to boot directly to GRUB2 instead of the rEFInd installation I had setup. The installer didn’t have any of the previously-customary “warning: this will overwrite your MBR/EFI boot partition” notices, so I felt safe letting it continue. It turned out that this was the way I ended up going, and it also turns out that there’s a bug in Anaconda that makes it fail installation if you tell it not to write a bootloader to disk (though it’s patched by one line of Python code). But I was deeply distressed that – contrary to the experience of every, admittedly more complicated, Linux installer I’d used before – the Fedora 18 installer overwrote my EFI bootloader (analogous to overwriting the MBR on a BIOS boot machine) without ever warning me or asking for a confirmation.

Secondly, the partitioning tool is clearly designed for only one destination disk. The overview screen lists configured partitions by label and mount point, but not by physical device, so figuring out which partitions are on which physical disks takes a click on each and every partition to view that information in the detail panel. When you create a new partition, it’s automatically put in a LVM volume group spanning all disks. Changing the target of the automatically created volume group requires a few clicks, as does changing the physical disks backing any new volume groups. To assign a newly created partition to a specific disk, you have to click on an unlabeled “tool” icon under the list of partitions, far away from the information on the partition in question. It’s a nice interface for someone who clicks the “partition automatically” button, or who just knows they want to add “an extra partition”, but for anyone who has a specific layout in mind (like having /, /boot and /var, specifically sized, on the SSD and /home on the rotating disk) it takes about 4-5 more clicks and dialogs to add a partition than the last Fedora installer did. Mainly, it’s lacking any sort of Advanced Mode for partitioning that allows the user to quickly and accurately layout a more complex partitioning scheme.

Below are some screenshots from the Fedora 17 and Fedora 18 Installation Guides, which contrast both the overview of all partitions and the individual partition settings:

Fedora 18 Overview, from 9.13. Creating a Custom Partition Layout:

Fedora 17 Overview, from 9.14. Creating a Custom Layout or Modifying the Default Layout:

Fedora 18 Partition Creation/Editing, from 9.13.3. Create LVM Logical Volume:

Fedora 17 Partition Creation/Editing, from 9.14.2. Adding Partitions:

Fedora Init Script Specification Summary

Posted on by

I’ve been deploying some new software lately (specifically selenesse, which combines Selenium and fitnesse, xvfb). None of these seem to come with init scripts to run as daemons, and the quality of the few Fedora/RedHat/CentOS init scripts I was able to find was quite poor. The Fedora project has a Specification for SysV-style Init Scripts in their Packaging wiki, which specifies what a Fedora/RedHat/CentOS init script should look like, in excruciating detail. What follows is an overview of the more important points, which I’m using to develop or modify the scripts I’m currently working on.

  • Scripts must be put in /etc/rc.d/init.d, not in the /etc/init.d symlink. They should have 0755 permissions.
  • Scripts must have a Fedora-style chkconfig header (“chkconfig:”, “description:” lines), and may have an LSB-style header (BEGIN INIT INFO/END INIT INFO). See Initscript template.
  • Scripts must make use of a lockfile in /var/lock/subsys/, and the name of the lockfile must be the same as the name of the init script. (There is a technical reason for this relating to how sysv init terminates daemons at shutdown). The lockfile should be touched when the daemon successfully starts, and removed when it successfully stops.
  • Init scripts should not depend on any environment variables set outside the script. They should operate gracefully with an empty/uninitialized environment (or only LANG and TERM set and a CWD of /, as enforced by service(8), or with a full environment if they are called directly by a user.
  • Required actions – all of the following actions are required, and have specific definitions:
    • start: starts the service
    • stop: stops the service
    • restart: stop and restart the service if the service is already running, otherwise just start the service
    • condrestart (and try-restart): restart the service if the service is already running, if not, do nothing
    • reload: reload the configuration of the service without actually stopping and restarting the service (if the service does not support this, do nothing)
    • force-reload: reload the configuration of the service and restart it so that it takes effect
    • status: print the current status of the service
    • usage: by default, if the initscript is run without any action, it should list a “usage message” that has all actions (intended for use)
  • There are specified exit codes for status actions and non-status actions.
  • They must “behave sensibly”. I’ve found this to be one of the biggest problems with homegrown init scripts. If servicename start is called while the service is already running, it should simply exit 0. Likewise if the service is already stopped. Init scripts must not kill unrelated processes. I don’t know how many times I’ve seen scripts that kill every java or python process on a machine.

I intend to use this as a quick checklist when developing or evaluating init scripts for RedHat/Fedora based systems. In my experience, the biggest problems with most init scripts revolve around poor handling of PID files and lockfiles, mainly:

  • Killing processes other than the one that the script started (i.e. killing all java or python processes), usually because the PID isn’t tracked at start
  • Starting a second instance of the subsystem because lockfiles aren’t used, or the status function is broken.
  • improper exit codes
  • either explicitly relying on environment variables (and therefore breaking when called through service(8)), or conversely, not cleaning/resetting environment variables that are used by dependent code or processes.

Nagstamon on Fedora 17

Posted on by

Since I started my last job, I’ve been using Nagstamon on my workstation; it’s a really handy little system tray application that monitors a Nagios/Icinga instance and shows status updates/summary in a handy fashion, including flashing and (optionally) a sound alert when something changes. Unfortunately, there doesn’t seem to be a Fedora 17 package for it, though there is an entry on the Fedora package maintainers wishlist. The closest I was able to find is a repoforge/RPMforge package of Nagstamon 0.9.7.1, along with a source RPM.

Here are the steps to build that package on F17:

  1. Download and install rpm-macros-rpmforge.
  2. As root, edit /etc/rpm/macros.rpmforge and comment out the %dist macro, so we’ll still have the default “fc17″ dist tag.
  3. wget http://apt.sw.be/source/nagstamon-0.9.7.1-2.rf.src.rpm
  4. rpmbuild –rebuild nagstamon-0.9.7.1-2.rf.src.rpm

Hopefully this will help someone else as well. At the moment, Nagstamon is actually up to version 0.9.9, so hopefully I’ll build a newer package sometime soon.

Getting oVirt up and running

Posted on by

The bulk of this post was written way back in April 2012. If you’re just coming here, and looking to setup oVirt, you should probably skip down to the postscript for an update, and ignore most of the content here (as it’s applicable to an older oVirt version).

I recently started setting up oVirt, the community version of Red Hat Enterprise Virtualization, at work for some testing (mainly a “sandbox” VM environment, and because Foreman supports it). To start with, I had two nodes, each with two dual-core Xeon processors (VT-x capable) with 20GB RAM, one with 600GB internal storage and one with 140GB internal. While oVirt’s documentation isn’t exactly wonderful, I found a blgo post by Jason Brooks, How to Get Up and Running with oVirt, which gives a great walkthrough of getting the oVirt Engine setup on a machine, and also setting up that same machine as a VM host. As oVirt is still fairly young, this is all done on Fedora. I performed my installation via Cobbler, though I’m afraid to admit it was an entirely manual, interactive install.

I did run into a few bumps during Jason’s tutorial. In step 15, adding the data NFS export as a Storage Domain, I was unable to add the NFS export. I found the Troubleshooting NFS Storage Issues page on the oVirt wiki, ensured that SELinux was disabled and that the export had the correct permissions, confirmed that /etc/nfsmount.conf specified Nfsvers=3, rebooted, and then ran the nfs-check.py script. At this point, I was able to add the other storage domains in steps 15 and 16.

My second issue was that even on Fedora 16, I simply can’t get the spice client (through the spice-xpi browser plugin) to work. As far as I can tell from the logs, it looks like spicec is being sent a value of “None” for the secured port parameter, instead of the correct port number. I assume this is a bug in oVirt, but I’ll revisit this problem when I have time. In the mean time, I changed my test VM to use VNC, which is launched by installing the ovirt-engine-cli package (see below) on your client computer, connecting to the oVirt API with ovirt-shell:

ovirt-shell --connect --url=https://ovirt-engine.example.com:8443/api --user=admin@internal --password adminpassword

and then running console vm_name. This launches the vncviewer binary, which is in the “tigervnc” package on Fedora.

Installing ovirt-engine-cli

To run ovirt-shell on your workstation (Fedora 16, of course…) you’ll need the ovirt-engine-cli and ovirt-engine-sdk packages. I manually downloaded them from http://www.ovirt.org/releases/nightly/fedora/16/, versions 2.1.3 and 1.6.2, respecitively. The SDK and CLI are python based, so there are a few Python dependencies, all of which were automatically solved by yum. I know there are SDK and CLI packages out there for other distros, but haven’t tried them yet.

Installing Linux Guests

Installing a CentOS 6.2 x86_64 guest was relatively straightforward, and my usual kickstart infrastructure worked fine. The only catch was the VirtIO storage interface, which shows up as /dev/vdx instead of /dev/sdx; I just added another kickstart metadata option in Cobbler that allows me to use sdx by specifying “virtual=yes” (for our VMWare hosts), or vdx by specifying “virtual=ovirt”.

Setting up Authentication

As installed, oVirt only has one user, “admin@internal”; it requires an external directory service for user authentication. Currently, it supports IPA, Red Hat’s Enterprise Identity Management tool (combines RHEL, oVirt Directory Server, Kerberos and NTP; perhaps FreeIPA would work as well?) and Microsoft Active Directory. As much as I’d like to give IPA or FreeIPA a try, my company already has an AD infrastructure, so I opted to go that route. Documentation is given in the oVirt 3.0 Installation Guide, starting on page 96. Unfortunately, I was never about to get AD auth working correctly, so I just worked with the one admin user.

Adding a Node

The biggest issue I had was adding the second node to oVirt. I attempted to use the DVD Import feature of Cobbler on the oVirt Node Image ISO, but that failed. I then found the image’s LiveOS/livecd-iso-to-pxeboot script and used that to make a kernerl and initrd, and kernel parameters, for Cobbler. PXE works fine.

Postscript: I ended up blowing away my oVirt installation in favor of testing other things. At some point, the engine install got corrupted in a way that I just couldn’t fix; even though I spent all day one Saturday working on it, it took more time than I could allocate to a personal project. So this post is really semi-complete at best. However, there is some good news. Jason Brooks’ original post, How to Get Up and Running with oVirt, was written for oVirt 3.0, as was this post. Since then, there has been a new release, oVirt 3.1, which apparently has a better UI and a better installer. Jason Brooks has a new post, Up and Running with oVirt, 3.1 Edition, which covers installation and configuration of both an all-in-one machine and a separate node. If you’re looking to try oVirt, I’d recommend you give that a shot. Unfortunately (and strangely, given that this is supposed to be the “upstream” of RedHat’s proprietary RHEV) it’s still all based on Fedora.

CentOS/Fedora Install on SuperMicro Servers via IPMI Card KVM Over IP

Posted on by

I recently had to setup Fedora 16 to test something on a SuperMicro 6015T-TV 1U “dual” server. This is a 1U enclosure with two separate servers in it – based on the SuperMicro X7DBT motherboards – each with an AOC-SIMSO+ IPMI and KVM-over-IP management card. Every time I tried different options for the kernel parameters (I was using Cobbler), I could get the OS to boot, but once Anaconda started, I’d lose image (“No Signal”) on the IP KVM, and the serial console would go quiet. It took me about a dozen tries before I found a mailing list reference to the “nomodeset” option. This did the trick perfectly, and kept Anaconda working.