SWEB, qemu and a Macbook Air
Posted on Sun 13 October 2013 • Tagged with University
Updated: 2013-10-18, 12:00, added solution
This term at university has just begun. I intend to finish some courses which require a little more to a lot more effort than previous ones. One of these would be Operating Systems. In said course there are practical assignments which consist of extending a minimal operating system called SWEB with lots of syscalls and other important features, such as multithreading. There will be a lot of work, both for me and my two teammates.
The first part important part consists of setting up and configuring your working environment. One has to check out the sources from git, set up the provided git repository which we are to use as the primary remote for the assignments and install requirements not yet present on the target system.
Well, that is normally. However, I wanted to reuse the virtual machine with Archlinux I already used for other courses. That turned out not to be easy.
Stumbling
SWEB needs to be built on Linux. That requires a VM. All good so far. SWEB requires a graphical environment to run, since qemu wants to display the things that are happening in the VM that SWEB uses somewhere. Now, my Macbook Air is more of a hyperpowered typewriter - though one with an insanely great battery - and less of a development machine - most of that can be blamed on its Intel Core 2 Duo processor which wasn’t up to date when it was implanted in this laptop and has aged since. I usually compensate for that by using my VM headless (“headless” just means without graphical user interface). Obviously that couldn’t work since there would be nowhere for qemu to display the SWEB terminal.
Trial (and many Errors)
Thomas already knew that problem and had figured out that X11 Forwarding was the key to working with SWEB in this particular way. He showed my the necessary entries in the config files responsible for forwarding an X11 session on the server and the client.
The server needed to have the following entries in its /etc/ssh/sshd_config (yes, both):
ForwardX11 yes
X11UseLocalhost no
In order for X11 forwarding to automatically occur every time you connect to the machine without having to specify the command line parameters every time the client’s ./ssh/config has to contain the following:
ForwardX11 yes
With the other options I use to configure my box and use public key authentication with it my config now looks like this:
Host vbox
HostName vbox.local
IdentityFile ~/.ssh/id_vbox
StrictHostKeyChecking no
ForwardX11 yes
UserKnownHostsFile /dev/null
The good thing is that after setting those options (and installing some previously missed build dependencies), I got my VM to compile and run SWEB. Sadly, that’s not the happy end, but where the trouble really began.
No Escape
SWEB started in it’s X11 window (XQuartz since Mountain Lion), I clicked its window to confirm everything was alright and typed a few characters into the SWEB terminal. I realized that qemu captured the mouse and read in the window title “press ALT+CTRL to release mouse”. I did that. Nothing happened. *sigh*
So I tried some other combinations. None worked. Thomas and I thought about how to kill the process. Simply removing the battery won’t work, it’s a Macbook Air and therefor not user-serviceable. Waiting for the battery to run out won’t work, since it would just save everything to disk and continue when connected to a power supply. Following Thomas’s suggestion I hit the power button and the operating system’s dialogue popped up. I selected “shutdown”. OS X told me that it won’t shutdown because X11.app blocked the shutdown process. Great. So I had to hold the power button and force the laptop to shut down.
We quickly realized that there was a problem with the keys not being accepted by qemu. (Yes, it is a non-default keymap, in order to be able to use a German keyboard layout. We previously modified SWEB’s qemu target to contain the additional parameter -k de. No, it doesn’t work with the default keymap either.) So, what to do?
A possible answer is “it’s Linux, it’s open source, it’s probably configurable”. It is configurable, it’s just not helpful in this case. The configuration options include –alt-grab which uses ALT+CTRL+SHIFT and –right-ctrl which uses the right CTRL key. None of these is good for my case. Since I already have trouble getting ALT+CTRL to work, ALT+CTRL+SHIFT won’t help a lot. and well, a Macbook Air doesn’t have a right CTRL key… This is getting worse, isn’t it?
Hacking for hacking's sake
Since Thomas told me that the keymap specified via command line is part of qemu and not of the underlying operating system I searched for that and found the Debian package containing said files. They are quite easy to understand, but not so easy to modify since usually one doesn’t know the key commands sent to by one’s hardware. According to what I got the easiest way would be to pretend some other keys are ALT and CTRL, so I tried overwriting those with the key codes sent by F11 and F12, because who needs those when coding for SWEB anyway. That didn’t work either, but it opened the door to some workarounds that I use now.
From X to OS X
I accidentally triggered Mission Control (formerly Expose) and that forced X11.app to lose the mouse focus. This workaround is less than ideal but should work for now. The process of finding it also involved several hours of research.
However, today I discovered that it is (now?) possible to switch away from X11 with CMD+Tab. I honestly can’t remember if I was smart enough to check that before… Anyway, that should do it. And I’m still pretty hyped about the fact that my X11 forwarded instance of Eclipse in a virtual machine is much, much faster than one which is run with a full GUI installation of Ubuntu Linux in a virtual machine on a more powerful laptop. [Insert snark about not having to install Eclipse on my main operating system here.]
Solution
When telling Markus about my problem I realized I hadn’t checked all of the configuration options of the X11.app and asked him if there’s one that stands out to him as a possible solution. Turns out ticking “Options keys send Alt_L and Alt_R” makes everything work perfectly.
SWEB, qemu and a Macbook Air is part 1 of Working on SWEB for the Operating Systems course: