Written by: Paul Rubin
Primary Source: OR in an OB World
Due to a research project in which I’m currently engaged (and, trust me, you do not want to know the details), I find myself needing to wander into a public computer lab on our campus (where Windows rules the machines) and run a “virtual” Linux machine (because I’ll be talking to a Linux server and, well, you really do not want to know the details). So I ended up using LinuxLive to create a USB flash drive from which I can run Linux Mint. Importantly, I can run it in a VM from Windows. Most USB installations of Linux distributions require that you boot from the USB, which in turn typically requires that you alter the order in which the PC polls devices looking for something to boot. That’s not possible in my case; because the network police tend to lock down publicly accessible machines, I basically can’t alter the boot sequence, and the boot sequence on the public machines does not include USB ports (let alone USB first). LinuxLive installs Oracle’s VirtualBox. I just have to launch VirtualBox from Windows and then run my Mint machine in the VirtualBox VM … in theory …
After one full afternoon of futzing with this, I think I’ve got it working (knock on virtual wood), and I figured I’d write down a couple of the “gotchas” and their workarounds.
You install LinuxLive on a Windows machine and then supply it (besides the USB drive) either an .iso image or a bootable CD/DVD with your Linux distribution. It supports quite a few Linux distributions, including recent versions of Mint. The LinuxLive installer is very easy to use and the steps are documented quite well on the web site, so this should be a no-brainer. Except, um, the first time out it didn’t work. I downloaded an .iso file for Mint 17 (the current version) and ran through the installation. Everything seemed to go fine, there were no error messages, and the installer told me it was done. When I tried to run Mint from the USB drive, though, I got an error message that the loader could not find vesamenu.c32. I located it manually (in the /syslinux folder), but it had a length of zero bytes, as did all but two files in that folder.
I was working in a campus computer lab, and by the time I tracked that problem down, I had to leave (and didn’t have any media with me that could transport the .iso file). My next attempt was at home, using a CD with the .iso file for Mint 14. Small problem: the installer does not recognize Mint 14 as a known distribution (even though it is on the supported list) and consequently installs it as a generic Linux distribution. I cant’ recall now if it did the same thing to me with Mint 17, but I think so. Among other things, this precluded me from setting up “persistence” (the ability to retain files on the USB stick between sessions), but I’m pretty sure I can work around that.
The installer told me it was done with no errors, and so it was time to test the USB stick. I had no trouble launching VirtualBox, where I found two virtual machines configured: “LinuxLive” (the production version of the Mint installation); and “Debug” (self-explanatory?). Starting the “LinuxLive” VM was an exercise in frustration. The good news was that it had no complaints about a missing vesamenu.c32. (Before trying to start it, I checked the driver and verified that this time the file had non-zero length.) The USB drive would flash, it would start to load something (couldn’t really tell what from the largely blank display), and then … nothing. It appeared to be frozen.
After assorted screwing around, I tried the “Debug” VM, where I at least got an error message: “This kernel requires an x86-64 CPU, but only detects an i686 CPU, unable to boot”. Suffice it to say that my PC has an AMD 64-bit processor, and the Mint 14 distribution runs fine on it. After some searching, I discovered this was a consequence of the VM being set up for “other Linux” (i.e., fallout from the LinuxLive installer not recognize Mint 14). In the VirtualBox control program, I selected the VM and changed Settings > General > Basic > Version to “Ubuntu (64 bit)”, which was as close as I could get to Mint (and, as it turns out, close enough). With that change, the Debug VM would boot.
The next problem was that the Mint asked for a user name and password. It turns out that, since I’m basically running a trial version, the user name is “mint” and the password is left empty. Once I figured that out, I could use the Debug VM … but not the main (LinuxLive) VM.
Even after I switched the LinuxLive VM from “other Linux” to Ubuntu (64 bit), it would not boot fully. It would get to the point where the user name/password prompt occurs, then go dark, then reboot in an endless cycle, with the USB activity light flashing non-stop. So I compared the settings of the two VMs and discovered that, for unknown reasons, the Debug VM was configured to use 512 MB of base memory but the LinuxLive VM was configured for only 256 MB. I suspect the LinuxLive VM was being starved. At an rate, I changed Settings > System > Base Memory to 1024 MB for the LinuxLive VM and voila, it ran!
I’ll screw around with adding persistence on another day.