Broadcasting audio over the network using VLC

This is pretty much a rip-off of a response that I wrote in a reddit thread, but it's useful, and if nothing else, I'd like a way to be able to reference this in the future!  Of course, there are other ways to do this, but this was the easiest to do with the tools I already had installed.

Regarding, in general, a way to stream audio over the network:

VLC makes for a fairly easy solution. The syntax is a little bizarre, but the documentation[1] seems pretty good.

Here's an example that will stream my headset microphone input out over the network as a Vorbis OGG stream:

cvlc -vvv \

pulse://alsa_input.usb-Logitech_Logitech_G930_Headset-00-Headset.analog-mono \

--sout '#transcode{vcodec=none,acodec=vorb,ab=128,channels=2,samplerate=44100}:http{dst=192.168.2.170:8080/stream.ogg}'

Then, on the other computer, you can use VLC or some other audio player, or even a web browser, and point it at the URL (192.168.2.170:8080/stream.ogg in my example.)

My example uses pulseaudio. If you're also using pulseaudio, you can find the MRL for your input by running

pacmd list-sources | grep name

and replacing my "alsa_input...analog-mono" string with the one you find. You'll also need to change the IP to your IP address, obviously.

If you run into issues, you can use the VLC gui (if you're running a gui) to help you generate the proper transcode string and input MRL. In VLC, open the playlist and choose Audio capture under Devices on the left, right click the one you want, and follow through on the Stream wizard.

This should at least give you a starting point!

You've gotten better at Linux! (6)

Installing brewpi on MINIBIAN

The related projects:
  brewpi
  MINIBIAN

Why?

• Installs on 1GB SD card (you need 4GB to install raspbian).

Use the normal method of installing the minibian img to an SD card (ie # dd if=imgfile.img of=/dev/sdcardyouwanttouse bs=1M) (see http://elinux.org/RPi_Easy_SD_Card_Setup for more details).

After installing:

• Default login: root/raspberry
• You'll want to change your root password (# passwd), but wait until after you update your keyboard config/localization settings (in raspi-config), especially if you are using symbols in the password.
• I'd highly recommend disabling the ability to login as root remotely, by editing /etc/ssh/sshd_config and changing "PermitRootLogin yes" to "PermitRootLogin no".

  # apt-get install raspi-config git-core sudo
  # raspi-config
    (change appropriate settings in here)
  # useradd -mU -G sudo pi
  # passwd pi
    (enter new password)
  # apt-get update && apt-get upgrade
  # su pi

Everything else should be the same as the instructions in the brewpi docs.  Start here: http://docs.brewpi.com/installing-your-pi/rpi-setup.html#configuring-your-system.  Enjoy!


You've gotten better at Linux! (5)

EQMac on Linux

I've finally beaten this thing into submission...

High level overview: running a version of the EverQuest Mac client, which has been modified to work on Windows, in Linux under WINE.  It's actually not as difficult as it sounds.  If you follow my steps below, you should be up and running in no time.

Prerequisites:

1. A copy of EverQuest Titanium (Windows client)
2. Likely an installation of Windows -- dual boot or virtual machine
1. It may be possible to do everything under Linux (via WINE), but I happened to have a Windows install already and used it for the Titanium install + EQMac download from the SOE Launchpad.
3. An EQMac account (it's free -- go here: https://lp.soe.com/eqmac/live/)

Steps:

1. Follow these instructions to create a bastardized version of the EQMac/Titanium client IN A WINDOWS ENVIRONMENT (follow link for more EQMac info) (note -- this is the portion that may be possible under Linux via WINE, but I haven't tried it):
1. http://www.guardianhq.com/othergames/everquest-al'kabor-server-eqmac-for-pc/
2. OR, partially re-pasted here (credit goes to Borneheld and whoever originally posted it on the fohguild forums):
1. Install EverQuest Titanium edition and move the folder to C:\
2. Rename the EQ Titanium folder to "EQMac"
3. Download the new Intel EQMac Client located here: Launchpad 4
4. When the new EQMac client is fully patched, find the folder (default location is C:\Users\Public\Sony Online Entertainment\EverQuest Mac or C:\Users\Default\AppData\Sony Online Entertainment\EverQuest Mac)
5. Go into the folder "EverQuest Mac" > "Contents" > "Resources"
6. In "Resources" folder, Select All > Copy > Paste to your C:\EQMac folder. Overwrite all.
7. Extract the zip file located here: Images Host | File Host - FileB.ag - Download EQMac Windows Secrets Edition zip to C:\EQMac. Overwrite all.
2. Install PlayOnLinux (4.2.1+) (note that it IS possible to do it without PlayOnLinux, using WINE by itself -- but this will take a fair amount of "WINE on the command line" knowledge, and it's easier to walk you through doing it via PlayOnLinux):
1. Go to the PlayOnLinux download page: http://www.playonlinux.com/en/download.html
2. Follow the instructions for your distribution
3. Create a new 32-bit WINE prefix:
1. Run playonlinux
1. $ playonlinux
2. Click the "Configure" button near the top
3. In the configuration window, click "New"
4. Next
5. 32 bit windows installation
6. Select "System" (for now), hit Next
7. Enter your preferred name for the "virtual drive" (I called mine EQMac)
8. Next
9. Now you should have a new virtual drive configured
4. Copy your bastardized EQMac client to your new virtual drive.  MAKE SURE THE INSTALL IS IN THE "ROOT" OF YOUR NEW VIRTUAL DRIVE (ie "~/PlayOnLinux's virtual drives/EQMac/drive_c/EQMac")
5. Use PlayOnLinux to install necessary library overrides:
1. In PlayOnLinux, highlight your virtual drive and click "Configure" in the right pane
2. Click the "Install components" tab
3. Install dinput8
4. Install d3dx9
5. Stay in configuration
6. Set library overrides:
1. Click the "Wine" tab
2. Click "Configure Wine"
3. Click the "Libraries tab" in the Wine configuration window
4. If the following libraries aren't already included in the overrides box, enter these manually:
1. In the "New override for library:" text box, type "d3dx9_30" (without quotes) and click "Add"
2. In the "New override for library:" text box, type "dinput8" (without quotes) and click "Add"
3. You will get a warning telling you that you shouldn't override this library... do it anyway... you HAVE to
5. Stay in the Wine configuration window
7. Set the appropriate graphics overrides
1. Click the "Graphics" tab
2. Check "Automatically capture the mouse in full-screen windows"
3. Uncheck "Allow the window manager to decorate the windows"
4. Check "Emulate a virtual desktop"
1. Set the "Desktop size" to your desktop resolution to get full window play
5. Click "OK"
6. Stay in the PlayOnLinux configuration window
8. Create a shortcut to the appropriate executable:
1. Click the "General" tab
2. Click "Make a new shortcut from this virtual drive"
3. Highlight "eqw.exe" and click "Next"
4. Click "Cancel"
9. Change the WINE version in your virtual drive to a known working version for this EQMac client
1. In the "General" tab, click the "+" button next to the "Wine version" (it should say "System" currently)
2. In the 32-bit tab (x86), click Wine version 1.5.29 and add it to your system (">" button)
1. Note: other Wine versions MAY work... but once I found a working version, I left it alone.
3. Close the wine version manager window
4. Select WINE version 1.5.29 in the "Wine version" drop-down box
10. You should be ready to play!
1. Close out of the PlayOnLinux configuration window
2. Click on your eqw shortcut
3. Click "Run"
4. Enjoy

Bonus:

1. You'll probably have to tweak some settings in the eqclient.ini file (located inside your EQMac directory), such as:
1. Resolution
1. In order to capture the mouse, you'll need to set it to your current desktop resolution (or possibly just to your emulated desktop resolution... I haven't tried that)
1. A note on mouse capture... if you happen to move the window from its original pseudo-fullscreen position, you'll have a difficult time getting the mouse to stay within the bounds of the eqw window.  In order to correct it, you'll have to move your window back to the exact position it was in -- or possibly wipe a config file to get it to reset itself? (not sure which file(s) that would be)
2. Luclin models
1. Obviously optional, but if you want them on, you'll have to edit the file manually, since the client makes you turn them all off, the first time you run it, since your "system can't handle that many models" -- regardless of your system
3. Possible graphical tweaks
1. There are some graphical tweaks that you can change in the ini file that can help it to run better, look better, or increase stability.  I have everything cranked to max quality and it runs just fine (Intel i7 w/Nvidia GTX 670 and proprietary Nvidia drivers v310.40).

Feel free to comment if you have any questions and I'll TRY to help!  Also, let me know if you manage to do it entirely in Linux...

You've gotten better at Linux! (4)

Humble Bundle Blunder

<rant>

Goodbye, Humble Bundle.  You won't be getting any more of my money.

The pitch: pay what you want for a set of quality, cross-platform (including Linux!) indie games while helping a charity.  Sounds like a solid idea... which is why I paid much more than the average for two separate bundles.  So why do I have such a bad taste left in my mouth?

The ports that are released on Linux are, in many cases, broken and STILL not fixed.  I understand that software will have bugs -- it's inevitable, but one of the big advantages to playing on games on a PC is that they can be easily patched on the user's end.  But, obviously, the developers have to release fixes/patches in order for me to be able to apply them... which hasn't been happening for many of the Humble Bundle Linux ports.  This leaves us with no options but to play the Windows versions under Wine (usually with decent performance hits), or to dual boot Windows and play them there -- both of which defeat the whole idea of supporting cross-platform games.

I've gone down every support channel that I can think of to bring these issues to the developers' attention, but in too many cases, these support requests are seemingly sucked into a black hole and are never addressed.  Here's how I understand the Humble Bundle process to work: the studio that originally developed the Windows version of the game vies to get their title in an upcoming bundle, once that deal is made, they contract a 3rd party developer specifically to create the Linux (and probably Mac) versions of their game.  Since the original studio contracted this work out, they're not directly responsible for supporting these "step-child" versions of their game.  Therefore, it's typically useless to contact the original studios directly for Linux support and you're usually told to direct your support questions to Humble Bundle directly (this is first-hand experience).  Then, you send an email to the generic Humble Bundle support email address, which usually nets you a timely, courteous, yet unhelpful (since they're not developers), reply.  After that... it's just silence... then they're on to releasing the next bundle and your hard-earned dollars are stuck in a few half-complete, and support-less, native games.  This isn't what I signed up for.

Let me give you a few specific examples that you can see for yourself, instead of just taking my word for it.

1. Torchlight (Humble Bundle 6, 09/18/2012)

• http://forums.runicgames.com/viewforum.php?f=24
• This one had a pretty rocky start comprised of hard crashes (several of which occurred at certain points of progression in the game, which meant that you couldn't complete it), missing sound/music, and the player characters missing their heads.  I believe all of the sound issues and  crashes have been fixed, so at least you can finish the game.  The heads are, however, still missing -- this issue is usually the top thread in the above linked forum.  It looks like people are still, occasionally, posting on that thread, hoping for a fix -- I've given up hope.

2. Dungeon Defenders (Humble Bundle 7, 12/19/2012) 

• http://forums.trendyent.com/showthread.php?88074-Linux-Version-FAQ
• https://bugzilla.icculus.org/buglist.cgi?quicksearch=Dungeon+Defenders (official and inactive bug tracker)
• Just take a look at the bug list for this one...  I can confirm several: broken gamepad support (which limits you to one player -- keyboard and mouse only), broken LAN multiplayer support, Gamespy online play doesn't work (all versions may be affected, fault may be on Gamespy's side), each level starts on a wave that's not the first (starting on wave 2 of 6 for example), erratic window and mouse behavior on game start -- mouse isn't captured by the game and/or doesn't respond to clicks (usually resolved with an arbitrary number of clicks and alt-tabs), mana crystals aren't pulled toward the player (gathering mana during and between waves is a big part of where you spend your time)...
• Those first three bugs that I listed, together, limit your game play to SOLO.  I've spent some good time with this game (the Windows version is much more usable), and I will tell you that this game is not meant to be played solo -- it gets old, fast.

3. Vessel (Humble Bundle 6, 09/18/2012)

• https://twitter.com/humblesupport/status/278589326344982529
• The bundle was out on Sept. 18, 2012 -- but the game wasn't released until December 11, 2012.  I haven't even played this one yet, but a two month delay, in itself, is a bug in the system...  In all fairness, Humble Bundle did eventually offer a full refund for the bundle due to Vessel taking so long, if you were that bent about it, but shouldn't the game be ready for the pre-determined release date?

4. Shank 2 (Humble Bundle 7, 12/19/2012)

• http://forums.kleientertainment.com/forumdisplay.php?18-Shank
• Many bugs at launch, including (very) broken gamepad support (which is a huge deal with this game -- I like playing games on a keyboard and mouse, but this one would have been unbearable), and a bug that prevented progress on the last level.  These issues, I believe, are all fixed now, but it took about a month, and several revisions, to iron them all out.

Many of the games are seemingly relatively untested when they are released to the public, which creates a cycle of: download, install, play, crash (or run into another bug rendering the game unplayable), create feedback about the issues, wait and incessantly check the Humble Bundle website for an updated version, download, install... and repeat.  And that's if you're lucky and they actually fix the bugs.  That being said, there are a few games that I've played specifically that have given me ZERO issues from the beginning, which deserve some praise:

Dustforce

Rochard

...

Actually, I think that's it for now.  I've still probably only played about half of the games from the two bundles which, in itself, says something about this whole Humble Bundle project, considering the number of issues I have to report...

I know there are die-hards out there that will continue to support Humble Bundle solely because they're bringing more native games to Linux.  But if the games are broken, what's the point?

I think the fix lies in Humble Bundle's hands.  They really need to take the reins and set some hard rules and deadlines for these games.  Continuing on without more of a hardline approach will keep making them look bad.  They need to tell developers, "Your game isn't complete AND tested by the time the bundle is released?  Too bad.  You missed out on a big opportunity."  Even if this results in fewer games making it to a native Linux port (although it shouldn't, as it only requires a bit of planning ahead...), we will have a higher percentage of QUALITY and COMPLETE games as a result.

The developers (or studio) need to be held to a certain level of post-release support for the games -- even if the target for this support level is fixing 100% of bugs on any one target distribution (Ubuntu seems to be the popular choice for this).  I'm sure that all of the studios behind the Bundle games are making enough money to provide a decent level of support afterwards.

TL;DR:
To Humble Bundle:  I don't want a refund, I just want the games, that I paid for, fixed.

</rant>

If anybody actually reads this, please share your experiences in the comments.


You've gotten better at skimming! (1)

Creating Wine/PlayOnLinux Steam Game Shortcuts on Your Desktop

After my recent invite to the DotA 2 beta (/cheer), my Linux gaming interest has been reignited.  I already had a working install of Steam via Wine (via PlayOnLinux), which is the platform on which DotA 2 is distributed.  Consequently, the regular installation of DotA 2 from Steam went smoothly and the game ran without a hitch (Wine v1.5.13).

When you install a game through Steam, a shortcut is automatically placed on your desktop in the form of a .url file -- at least this was the case with my Fedora/KDE/PlayOnLinux combo.  The shortcut seems to work just fine, but there were a couple of issues with it for me, aesthetically.

That picture alone should tell you exactly what's wrong with it.  For installed native Linux games, you get a nice desktop link to the binary with the intended icon... with a Steam game shortcut, you get a globe on a paper with a rolled corner and a ".url" on the end of the game name.  This will never do for those of us who have an interest in the more aesthetically pleasing things of this world OR those of us who have large Steam game collections... and especially not those of us who fall into both categories.

DISCLAIMER:  This fix is specific to the KDE 4.X environment, although other desktops surely have a similar method for implementing this.  At the very least, you will find the "Command" for opening a game through Steam via Wine useful.

Enough rambling.  What's the fix here?  Well, the file that we have is a URL shortcut with contents like

[InternetShortcut] 

URL=steam://rungameid/570 

ICONFILE=C:\Program Files (x86)\Steam\steam\games\c0d15684e6c186289b50dfe083f5c562c57e8fb6.ico
ICONINDEX=0

Even if we change the ICONFILE line to a more Linux-appropriate path and file type, we still won't be able to change the icon.  Also, you can go into the Properties dialog for this shortcut to change the icon, but this will change EVERY .url file to use the same icon... not ideal.  So, we essentially need to create a new type of shortcut for our games for which we can configure an icon on a per shortcut basis; this can be accomplished with an application shortcut.  For starters, open a windowed terminal session and cd to your user's desktop directory:

cd ~/Desktop

Then do a cat of the shortcut that you intend to replace:

cat Dota\ 2.url

The output should be very similar to what I've posted above (in the [InternetShortcut] section).  The number at the end of the URL=steam://rungameid/... line is what we're most interested in here.  This is the unique number that Steam assigns to each application, and we will be creating the new shortcut using this number.  Now, right click on your Desktop panel and Create New > Link to Application...  Fill in the field at the top of the "General" tab that currently contains "Link to Application" with whatever name you'd like to appear for this shortcut.  Then, click on the application tab and fill in the "Command:" field with the following:

env WINEPREFIX="/home/user/.PlayOnLinux/wineprefix/Steam" wine "C:\\Program Files (x86)\\Steam\\Steam.exe" -applaunch 570 -no-dwrite

Here, you will fill in the WINEPREFIX portion with the root of your Wine drive.  In my case, I'm using PlayOnLinux to manage several Wine drives.  If you're using straight Wine, yours might look more like "/home/user/.wine".  You'll also need to make sure your Steam.exe is in the same relative location as mine.  Then, the last thing will be to change the number (570) to the application number that you got from the previous step.  Also, the "-no-dwrite" portion is to disable the dwrite.dll library to fix the "no text" issue in Steam for Wine versions >=1.5.10 ... so that is optional.

Now, hit the OK button and you'll have a fully functional application link that goes straight to your desired game... but we still haven't resolved the issue at hand.  Right-click on your newly created shortcut and go to Properties.  This time, there is a question mark icon to the left of the shortcut name and it will be clickable.

You can click it to open the dialog for changing the icon.  One last gotcha... you will either need to download a new icon from the web by doing a Google Image search (eg "dota 2 icon") OR browse to the ICONFILE location in the "cat" step, open it in the default image editor, and save it back as a .png, .xpm, .svg, or .svgz;  this is because you can't use a .ico file as an icon in KDE.  Either way... click the question mark icon, click the "Other icons:" radio button, then click "Browse..." and browse to whichever icon graphic you desire, select it and hit "Open".  Now hit "OK" to get out of the dialog, and... you're done!  Mission accomplished!

You've gotten better at Linux! (3)

VirtualBox Error After Kernel Upgrade

The Error

You're probably here because you're seeing a pop-up error message when trying to start a virtual machine, similar to:

Kernel driver not installed (rc=-1908)

The VirtualBox Linux kernel driver (vboxdrv) is probably not loaded.

If you installed or VirtualBox package recently you need to restart the computer for the driver to load.

Alternatively, you may attempt to load the driver by issuing the following command with system administrator (root) privileges:

'/etc/sysconfig/modules/VirtualBox.modules'


The Diagnosis

Although there are a few clues in this message as to what VirtualBox's issue is, there aren't any likely solutions included.  That being said, if you DID install VirtualBox recently and haven't restarted... try that first (and/or try the included command 'sudo /etc/sysconfig/modules/VirtualBox.modules' to attempt to load the kernel module).

The issue here is that VirtualBox requires a loaded kernel module that matches the version of the kernel you're running.  The error likely occurred after a kernel upgrade -- that's been the cause for me EVERY time.  So... the fix?  Install the VirtualBox kernel module that matches your kernel version, of course.


The Solution

In case you want a few details on it...

You can find out the version of the kernel you're running with

uname -r

This is what mine looks like

[user@i7-fedora ~]$ uname -r
3.5.4-1.fc17.x86_64

The result tells you: the kernel version (3.5.4-1), the distribution version (fc17 -- "Fedora Core 17"), and the processor architecture your distro is based around (x86_64).

Fortunately, Fedora's kernel module packages are named using this same nomenclature.  Our needed VirtualBox kernel module, for example, (for this kernel version) is called kmod-VirtualBox-3.5.4-1.fc17.x86_64.  To acquire said module, run this bad boy:

sudo yum install kmod-VirtualBox-3.5.4-1.fc17.x86_64

It's a little long-winded with all the numbers, dashes, and dots...  Fortunately, there is an easier solution.  There is a Fedora metapackage called kmod-VirtualBox.x86_64 whose description is "Metapackage which tracks in VirtualBox kernel module for newest kernel".  Awesome.  You don't have to worry about all of the details.  Just run

sudo yum install kmod-VirtualBox.x86_64

and you should be good to go!  The beautiful thing about the metapackage is that it will show up along with the rest of your system/software upgrades every time there is a kernel upgrade; so, you shouldn't have to worry about it from here on out.

Once the module is installed, you can either reboot or run

sudo /etc/sysconfig/modules/VirtualBox.modules

to get the module loaded.  Then, all that's left is to just enjoy the amazing open source virtualization software as its creators intended.


You've gotten better at Linux! (2)

Dual Booting Linux and OS X Using Grub2

My interest in the frozen-in-time EverQuest Mac server (Al'kabor), and lack of true Apple hardware, has led me to a foray into the Hackintosh world.  Since I am a full-time Linux user at home, I needed the ability to boot into both my existing Linux (Fedora 17) installation and my new OS X 10.8 Mountain Lion installation.  Fortunately, most modern Linux distributions come equipped with a bootloader that is capable of handling this scenario: Grub2.  In very basic terms, a bootloader is software that acts as the start-up link between a system's low level software that handles the initial checks and communication with the installed hardware (eg BIOS) and the higher level operating system(s).

Given the above setup, there are a couple of options for dual booting the system; each could be a viable solution, depending on the configuration.


The Easy Way

If you don't need any additional boot flags to boot OS X successfully, then you can use a built-in grub tool to automatically detect the location and disk type of all operating systems installed on your local drives -- including OS X.  The tool name and syntax varies between distros, but they will all accomplish the same thing.

For Fedora and similar distros (your grub folder may actually be /boot/grub instead):

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

For Debian/Ubuntu/Mint:

sudo update-grub

Both tools use the built-in scripts located in /etc/grub.d to collect info about installed OSes on your machine and create the appropriate entries in Grub's configuration file at /boot/grub2/grub.cfg.  Once it has finished running, you should have two new entries in Grub's boot menu when you reboot; Mac OS X (32-bit) and Mac OS X (64-bit).  Select the appropriate choice for your system and enjoy the seamless transition into OS X.


The Not-Quite-As-Easy Way

If your system requires the use of additional boot flags to boot into OS X, then the easiest solution will be to use Grub to load a Hackintosh-specific bootloader (eg Chimera or Chameleon), then use the Hackintosh boot loader to pass your required boot flags to the OS X system.  This is called chain loading.

Most Hackintosh guides cover installing a boot loader, so I won't go into that here.  I'm going to assume you have Chimera or Chameleon installed already.  To further complicate things, we will need to use boot0, which is a tiny FreeBSD bootloader, to bridge between Grub and Chimera.  Although this file will be on your OS X drive already, the easiest way will be to just grab it from a download of Chameleon boot loader from the website: http://chameleon.osx86.hu/.  Open a terminal in the directory that you just downloaded Chameleon to.

Uncompress the .tar.gz file and locate boot0 within the i386 directory, and copy it to your /boot folder:

tar -xzvf Chameleon-2.*.tar.gz

For Chameleon versions 2.0.*:

sudo cp Chameleon-2.0*/i386/boot0 /boot/

I believe that in Chameleon versions 2.1+, the folder structure has changed in the tarball, so copy the boot0 from here instead:

sudo cp Chameleon-2.1*/usr/standalone/i386/boot0 /boot/

Now that the boot0 file is in the appropriate directory, we need to add an entry for Grub to use it to get to Chimera.  The best way to do this will be to add an entry in /etc/grub.d/40_custom (as opposed to adding it directly to Grub's pre-generated menu file -- ie /boot/grub2/grub.cfg).  The reason is because if we were add it directly to the grub.cfg file, it would be wiped the next time the "grub update" tool is used -- which happens as part of every kernel upgrade.  So, since /etc/grub.d/40_custom is one of the files that are used by Grub's update tool to generate grub.cfg, our OS X/Chimera entry will be kept between kernel upgrades.  So... back to the command line:

First, we need to figure out what our OS X partition's UUID is, according to Grub -- this is different than the UUID that the blkid tool reports.  The easiest way to do that is to run Grub's update tool to generate an entry for OS X.  This won't be the entry that we use, but it WILL give us the appropriate UUID.


For Fedora and similar distros (your grub folder may actually be /boot/grub instead):

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

For Debian/Ubuntu/Mint:

sudo update-grub

Open the generated grub.cfg file in a text editor and scroll down to find the "Mac OS X ..." entry in the file (your grub folder may actually be /boot/grub instead).

sudo nano /boot/grub2/grub.cfg

Copy the entry's UUID to the clipboard.  This will be a 16-digit hexadecimal value (eg 777eaee489759bd8) and will be listed on a line similar to "search --no-floppy --fs-uuid --set=root 777eaee489759bd8".  Now we will open /etc/grub.d/40_custom in a text editor and create our code that Grub will use to generate a menu entry for Chimera.

sudo nano /etc/grub.d/40_custom

Paste the following at the end of the file and change the partition designations on the "set root=" line and the "chainloader" line:


menuentry "Mac OS X (Chimera)" {
insmod part_gpt
insmod hfsplus

#replace this location with
#your OS X partition
set root='(hd1,gpt2)'

#replace this UUID with the UUID from your grub.cfg
search --no-floppy --fs-uuid --set=root 777eaee489759bd8

#replace the (hd0,2) portion with your
#Linux partition designation
chainloader (hd0,2)/boot/boot0
} 


You should be able to get a good idea of which device ids you need to use by running:

sudo fdisk -l

and comparing that info with the output of:

mount

The hard drive listed with GPT will be your OS X drive.  Typically, your drive with OS X on it will be split into at least 2 partitions: a 200MB EFI system partition (fat32), and a much larger partition that holds the OS (hfs+).  You can verify your OS X drive partitions by running:

sudo parted /dev/sdX

(of course, change the X to the actual drive letter of your OS X drive).  Then, at the (parted) prompt enter:

print

This will list the partitions on the drive.  It is worth noting here that, by default, the Chameleon bootloader is installed on your EFI system partition and Chimera is installed on your OS X partition.

A note about partition numbering/lettering in Linux and Grub:
The Linux and Grub partition designations differ a bit.  On my system, my OS X partition is located at /dev/sdb2.  This equates to hd1,gpt2 in Grub (since it's a GPT partitioning scheme).  The root of my Linux system is located at /dev/sda2, which is hd0,2 for Grub (non-GPT).  Linux designates physical SATA drives with /dev/sdX, where X is a letter from a to z.  The first drive is /dev/sda, second drive is /dev/sdb, third drive is /dev/sdc, etc.  After the letter comes a number (starting at 1) that represents the partition within that physical drive.  The first partition on the first drive would be /dev/sda1, second partition on the first drive would be /dev/sda2, etc.  Grub's drive designations are represented as hdY, where Y is a number which starts at ZERO.  Conversely, Grub's partition designations start at ONE.  So, the first partition on the first drive for Grub would be hd0,1, second partition on first drive is hd0,2, first partition on second drive is hd1,1, etc.

Once you have your 40_custom file configuration set, run the "grub update" tool again (refer to the above section again for your distro-specific syntax) to generate a new grub.cfg file which will have our new entry in it.  Once it's done, reboot the PC and select the new entry.  If all goes well, you should be presented with the Chimera bootloader, in which you can use your required boot flags.

Troubleshooting The Chainloader

If you have issues getting from Grub to Chimera, you can select the menu entry in Grub and hit "E" to go into editing mode for it.  Here, you are able to do some basic editing so you can mess with your partition designations (both at the set root='...' line and the chainloader line) or any other syntax errors that might be present.  Once you've made your changes, hit F10 to attempt to boot the revised method.

If you're truly unsure of what your partition designations should look like, back out to the Grub menu and hit "C" to get to a Grub command line.  Use the "ls" command to show all of the partitions that Grub can see.  This could help you get a better understanding of the designation that Grub requires (eg if you need to use a hdX,msdosY convention for an MBR partition).

Note that if you make changes in Grub's edit, they will NOT be saved.  You will need to make those same edits in the /etc/grub.d/40_custom file and re-run the "grub update" tool.


You've gotten better at Linux! (1)