integrating mac os x with linux as a vm to support raspberry pi development

Update 1 January 2019

This is probably one of the lamest posts I’ve ever written. I leave it here as example of how far into the weeds I tend to get. If you want to use macOS (as it’s now known) to support Raspberry Pi development, and in particular to program Linux images onto micro SDHC cards, then download balena Etcher from https://www.balena.io/etcher/ and install it. Etcher is extremely easy to use, walking you through the three steps necessary to create a bootable image on a card. Don’t do what I did below; that’s just an absolute waste of time.

Original Post

You’re viewing CentOS 7 running in VirtualBox 5.0.16, with a micro SDHC card mounted and in turn viewing the Arch Linux ARM ext4 native Linux filesystem I created for my RP3. When I originally created the RP3 micro SDHC card I used my Ubuntu 15.10 notebook as the workbench. But I’ve been wanting to do similar work using my MBP as the primary tool bench, with an eye towards retiring the native Ubuntu notebook with the MBP due to the Ubuntu notebook’s age, rather than attempting to replace the Ubuntu notebook as I’ve written I originally wanted to do. The biggest hurdle to using the MBP was just reading the native ext4 file system on the MBP, as Max OS X has no native provisions to read Linux file systems. This post is about getting to that point. As time goes along I’ll be doing more than just reading the microSDHC, but reading (and then writing) is the foundational requirement, else this is all a waste of time and resources.

Before I go much farther let me properly attribute this from another post, “Mount SD card in VirtualBox from Mac OS X Host,” written by Brady Holt on 21 July 2014. Please note this was done nearly two years ago. This is an update to his post using contemporary software and with my observations.

Software and hardware I’ll be using:

  • OS X El Capitan, version 10.11.3 running on a MacBook Pro (Retina, 15-inch, Mid 2015)
  • VirtualBox 5.0.16 with Oracle_VM_VirtualBox_Extension_Pack-5.0.16
  • CentOS 7 with all updates as of the date of this post with VBoxGuestAdditions_5.0.16 running as a VM

I’m going to create a Linux VM with VirtualBox and use that to mount and at least read the micro SDHC card with the Arch Linux ARM ext4 file system. I had originally looked for a Mac OS X utility to do this, but eventually gave up as the utilities that claimed they could do that had allegedly stopped working with the release of El Capitan because of System Integrity Protection, or rootless, mode. Far be it from me to disable in El Capitan what is supposed to add additional security to OS X. I’m somewhat surprised that I could get this to work, but I suppose that if, at some point in the future, Apple releases a Mac OS X update that breaks what I’ve built here that I’ll be back to using a separate Linux machine.

The first step is to install VirtualBox and then to install CentOS 7 within a VirtualBox VM. I won’t cover that here, as there are plenty of existing how-tos for that. Just make sure that the Virtual Box Extension Pack is installed and that you’ve downloaded and installed the VBoxGuesAdditions and have built it within the VM. That gets everything prepared both on the OS X host side as well as within the VM.

The next step is to get the overall system prepared to mount the RP3 micro SDHC card within the CentOS 7 VM.

  1. Plug in the microSDHC card into the MBP using the microSDHC adapter. I’m using a Samsung 32GB Evo Plus device. Note that it’s named “NO NAME” on the desktop. This is the MSDOS 100MB boot partition on the microSDHC card.
  2. Go to Launchpad and search for diskutil. Launch diskutil. Select “NO NAME.”

  1. Click the Info button at the top right. Note the device associated with “NO NAME.” It’s the third line down from the top, called “BSD device node.” In my case it’s disk2s1. The device associated with this partition is /dev/disk2. We’ll use this later.

  1. At the top of the utility click the ‘Unmount’ button with your mouse. The button text will then change to ‘Mount.’ Please note you don’t want to eject the device, just unmount.

  1. Now we need to create a VirtualBox VMDK file to point to this device. That’s how we’ll get it to mount inside the Linux VM. Open a terminal and type sudo VBoxManage internalcommands createrawvmdk -filename sd-card.vmdk -rawdisk /dev/disk2 at the prompt. The file will be created where ever you run it, so my advice is to change directory to a location where you want this (or preface the file name with a full path) to create the file. Just remember where you left it.
  2. Change permissions on the microSDHC device and the VMDK file to 777. At the prompt type chmod 777 sd-card.vmdk /dev/disk2. This opens up permissions for the file and card to be used later by the VM
  3. Add sd-card.vmdk to the VM’s storage devices. In VirtualBox, under the CentOS VM, select the Storage dialog, and in the Storage Tree under Controller: SATA click the add device button. You will be prompted to either create a new device or add an existing device. Choose to add existing and add sd-card.vmdk.
  4. Check diskutil one more time and make sure that the microSDHC card is still unmounted. OS X has automount and can silently remount the drive. If it does then you will fail to start the Linux VM.
  5. Once the VM is started bring up Nautilus and note two new ejectable entries for the card, a 103MB entry and a 32GB entry. Click on the 32GB volume. You’ll be prompted by Nautilus to enter root’s password for that VM to view that volume. Once that’s done Nautilus opens into the 32GB volume. You can drag and drop files into and out of the midroSDHC’s 32GB volume. I do this to add content as well as pull log files while developing.

One caveat. If you shut down the VM and then want to bring it back up, you’ll need to unmount the microSDHC card like before and execute chmod 777 /dev/disk# again, or the VM will fail to start due to lack of permissions on the raw device.

rolling with a different distro: centos 7

Because they’re so cheap I bought another 1TB Western Digital Blue drive from a local big box electronics store, swapped it into my R580 notebook, and installed a few other Linux distributions on the blank drive, eventually stopping at CentOS (Community ENTerprise Operating System) 7. CentOS 7 is Redhat Enterprise Linux (RHEL) 7 with all the Redhat branding and logos stripped out as well as the RHEL licensing structure. What’s left is an enterprise class version of Linux without any of the paid for RHEL hand holding.

There are a number of key differences between CentOS 7 and Ubuntu 14.04. One that’s important to me is support for RPM (Redhat Package Management) install files as opposed to Ubuntu’s DEB (DEBian) files, and all the tools built around those formats. Truth be told I prefer rpm and yum to deb and apt-get, although when you compare them dispassionately there’s really very little difference between them. Those folks that claim there is are the “fan boys (and girls)” of their distribution. I’ll be honest enough to say that long years of experience make me more comfortable using rpm, but that doesn’t make it overwhelmingly better.

One language I use and develop with is Java, choosing to use the official Oracle releases, which are pushed out either as ZIP, TGZ, or RPM files. No DEB files. It’s far easier to install via RPM on RPM supporting operating systems, such as RHEL/CentOS, Fedora, and openSUSE. If I want to use Oracle Java on Ubuntu then I have to go through some additional gyrations unpacking the TGZ file, as I’ve documented in previous Ubuntu posts.

In order to use Oracle Java I have to completely uninstall the Open Java/Iced Tea variants that just about every distribution wants to install. I dislike all those variants because they’re incomplete, don’t operate as correctly as the official Oracle release, and are always a few releases behind. And every time I uninstall Open Java I’m also forced to uninstall Libre Office due to insane dependencies of Libre Office on Open Java built-in to the distro.

CentOS 7 was no different, but it was straight forward and fast, unlike openSUSE 13.1. After removing Open Java and Libre Office, I installed Oracle Java 8 update 20, then downloaded the latest Libre Office (version 4.3.2.2). Sometimes you need to bypass the repos due to version rot not only for the latest Java, but the latest Libre Office as well. The CentOS versions of Libre Office are at 4.1.4.2 as of the date of this post. The primary driver is that Microsoft Office compatibility in Libre Office 4.3 is much better than in version 4.1.

I just mentioned openSUSE 13.1. That’s because I tried out OpenSUSE 13.1 KDE before settling on CentOS 7. While openSUSE installed fairly well, it had enough oddball quirks to it that I eventually installed CentOS 7 over it. Biggest problem with openSUSE is KDE itself; it’s changed to the point where I don’t like it at all any more. That’s a shock from my early days of 2007, when I fell in love with KDE 3. OpenSUSE is now completely off my radar.

One thing I will say about the latest Linux distributions, and that’s how they all effortlessly handle hardware. With all distributions both screen and network were easily detected and used. The wireless chip set on the R580 was the most surprising success; in all cases the chip set was detected and enabled. All I had to do was pick my home network and give it the password. After that it just ran.

Another big surprise is how all the distributions have current browsers, and how the current browsers handle multimedia. You’re looking at Firefox 31.1 above running a YouTube cat video using HTML 5 (no flash here!), complete with audio. When something as conservatively hidebound as CentOS 7 can run YouTube cat videos without flash, without turning to running arcane post-install command-line tools or installing additional “non-free” software from “non-free” repos, then you know the apocalypse has truly arrived.

Once installed it ran smoothly and without any incidents. I installed Oracle Java as well as the latest Libre Office. I also installed a few tools, such as gcc and g++, and then forked and built the latest node.js off of Github. It all built cleanly, and ran as well as it has on every other OS I’ve dropped it on. I tried some other hackery and it all worked as expected. From a software development perspective, CentOS 7 is like Mary Poppins, practically perfect in every way.

As good as CentOS 7 might be operationally and internally, I do have a number of complaints about CentOS 7. The first is how it looks.

CentOS 7’s desktop, which is their version of Gnome 3, looks like a poorly implemented copy of Mac OS X 10.5 (see above). If I’d wanted that look I’d have bought myself a Mac. Back in 2008 or so. The shadowing looks better on Mac OS X, while CentOS 7’s desktop decorations seem to take up too much space, especially between widgets.

Other annoyances include the desire of the Gnome developers to remove features, such as Nautilus’ ability to show previews (it once did), or the Gnome terminal’s loss of transparency in Gnome 3 (in Gnome 2 it was really very nice), or the inability to select gedit’s color theme (I always go in and select cobalt). Thankfully, they’re features that are still available in the same tools under Ubuntu 14.04. These are the kind of operational issues that tend make people like me cranky.

It’s been interesting playing with CentOS 7 this weekend, and I’ve certainly learned a lot. There’s certainly much to appreciate in CentOS 7. But as much as CentOS 7 has improved over all other versions of CentOS, I think I’ll stick with Ubuntu for the time being. In the mean time the CentOS 7 drive goes into storage until such time as I might have need of it.