Create an UEFI Arch USB Rescue Stick

I’ve been running Arch for awhile now and one of the items on my todo list as been to create a USB rescue stick in case my installation ever gets borked with an upgraded. The process of creating a stick is really straight forward and I thought I would document the steps I used here. The first thing someone should review is the Arch Installation Guide and it will be referred to at various points. This guide assumes you are already running Arch Linux on your PC.

The first step is to partition and format the stick. I used GParted but any similar tool will do. In GParted I created a GPT table on the stick followed by two partitions. The first partition is FAT32 and only 384 MB in size, it will be the EFI boot partition. Remember to set the boot flag for the EFI partition. The second partition will contain the Arch Linux installation and it’s set to Ext 4. The screenshot below of GParted shows the final configuration.

GParted UEFI USB Stick

The next step is to get the Arch Linux install scripts on the PC you are going to use to create the USB rescue stick. This is simply done with the following command:

pacman -S arch-install-scripts

Next we need to mount the partitions on the stick, replace [x] in the commands below with the right letter for your USB stick.

mount /dev/sd[x]2 /mnt
mkdir -p /mnt/boot
mount /dev/sd[x]1 /mnt/boot

Once the stick is mounted we can install Arch Linux on it and generate an initial fstab:

pacstrap -i /mnt base base-devel
genfstab -U -p /mnt >> /mnt/etc/fstab

Next, follow the install guide as per the System Configuration ( section and use arch-chroot to switch to the stick and do an initial configuration of the new install.

I chose to use rEFInd as the boot loader as it is very straight forward to install and configure. To install and do an initial configuration run the following from the change root shell (i.e. Within arch-chroot /mnt) remembering to once again replace the [x] with the letter for your device.

pacman -S refind-efi
refind-install –usedefault /dev/sd[x] –alldrivers
Once this is done, go into /etc/fstab and note the UUID for the second partition (the EXT4 partition) on the stick. edit the file /boot/EFI/BOOT/refind.conf and add the following at the end of the file, replace the UUID in the options line with your UUID that you noted from /etc/fstab.

menuentry “Linux Rescue” {
icon EFI/BOOT/icons/os_linux.png
loader /vmlinuz-linux
initrd /initramfs-linux.img
options “rw root=UUID=[YOUR UUID HERE]”

I would also recommend commenting out all of the other menuentry items besides this one but that’s optional.

Once done, exit arch-chroot and re-start your computer. Using the BIOS boot menu, select to boot from the stick and if everything went well it should boot to a text based login. At this point you can continue configuring Arch for your specific needs.

GNOME Boxes and Samba Shares

This is a followup to my earlier post about using GNOME Boxes to manage a Windows virtual machine. One of the comments I made was that I used Samba on the host (Arch Linux) to share the host file system with the Windows guest. I got a comment asking for further details about this as I mentioned it pretty superficially originally and thought it would make a good follow-up blog post.

This blog post is assuming Arch Linux as the host, if you are using a different variant of Linux check your distribution’s documentation on installing Samba. For Arch Linux, the Arch wiki does an excellent job of explaining how to install and configure Samba and this is what I followed with one exception.

That exception is that I opted to enable the smbd.socket service instead of smbd.service. Also, I didn’t bother enabling the nmbd.service which is used for Netbios since I only use the Samba service for my VM and not to share my local file system on the network at large.

Once you have followed the Arch install procedure, you need to create and modify smb.conf so that the host folders are available to the guest. As per the Arch wiki, this simply involves copying /etc/smb.default to /etc/smb.conf and adding an entry for each folder at the end of the file. Here is my entry for the Documents folder as an example:

comment = Documents
browseable = yes
writeable = yes
path = /home/[username]/Documents
valid users = [username]
public = no
read only = no
create mask = 0700
directory mask = 0700

Make sure to replace [username] in the above with the name of the user you login into Linux with. I keep things simple by using the same username/password in the host and the guest, if you don’t you may need to do some tinkering to a to enter credentials in the guest to access the shares.

Once this is done, run the Windows Guest and open the File Explorer. I believe the default IP for the host in QEMU when using the slirp network stack is so in Windows File Explorer, try accessing the network share using \\\Documents. If everything is configured correctly you should see the host’s folders and files under Documents appear. If it works, you can opt to create permanent shares by creating mapped drives (right click Computer in Windows File Explorer and select Map Network Drive…).

So that’s it in a nutshell, pretty straight forward and hopefully it helps.

Learning Python, GNOME and GTK+3

While it’s a new year and I thought for my new years resolution that I would get back into doing a side project in my spare time. In my day job I do a lot of Java development but in the past I’ve typically taken on a side project doing something different from what I do for work to exercise the brain and keep my skills sharp. The last side project I did was an Android application called OnTrack Diabetes and it was a good experience that gave me some appreciation for mobile development.

I’ve been using Linux now for almost three years with the GNOME desktop environment so this time around I figured I’d get into writing a GTK+ 3 application and blog about the experience here. In terms of an application, I’m going to start with something relatively simple which is a Visual Grep tool. While I’m perfectly comfortable using grep from the command line, there are use cases for me where I like to have a GUI as I’m doing some analysis on code or other files that requires me to access the grep results in a random but persistent way.

So my first task was selecting a language for the development of this application. The two languages I considered are Python and Vala since they are both first class GNOME languages with excellent GTK+ 3 bindings. After doing some investigation, I decided to go with Python for this application for a couple of reasons. The first is that Python is more widely used then Vala which isn’t used anywhere outside of GNOME development as far as I can tell. This leads into the second reason which is that learning Python better actually benefits my day job as I’m often writing WebLogic scripts in Jython. The final reason is that Python has more mature tools then Vala.

Now that the language decision was made, the second order of business was to get an IDE setup. I opted for the PyCharm Community Edition from JetBrains. It appears to be a robust Python IDE with full support for code completion, re-factoring and debugging. Also, it didn’t hurt that I have heard nothing but good things about IntelliJ which is the JetBrains IDE for Java. Installing PyCharm in Arch is simple using the AUR package for it.

After installing PyCharm, I copied in my first GTK 3 program from a tutorial as follows:

from gi.repository import Gtk

win = Gtk.Window()
win.connect(“delete-event”, Gtk.main_nquit)


And this is where I ran into my first problem. The first line had a red underline for the Gtk import indicating PyCharm could not resolve it and code completion wasn’t working for any GTK classes. After doing some googling I could see that this was a common complaint. Apparently GTK 3 uses introspective bindings which are problematic for some IDEs. PyCharm was supposed to handle it by generating a skeleton (hit Alt-Enter after Gtk and select “Generate stubs for binary module”)  but it never worked for me.

Instead I ended up using a package called fakegir which generates skeleton source files for the GTK 3 API. To use fakegir, I first imported the python-lxml dependency fakegir requires and then executed the fakegir script using the following commands:
git clone
cd fakegir
And this is where I hit my next issue when I got the following error:

Parsing /usr/share/gir-1.0/Cogl-2.0.gir
Traceback (most recent call last):
File “”, line 234, in
File “”, line 226, in generate_fakegir
fakegir_content = parse_gir(gir_path)
File “”, line 195, in parse_gir
namespace_content = extract_namespace(namespace)
File “”, line 165, in extract_namespace
namespace_content += insert_enum(element)
File “”, line 88, in insert_enum
if enum_name[0].isdigit():
IndexError: string index out of range
To work around this, I patched the to simply ignore this exception. Not sure if this is the best route to fixing the issue (Hey I just started learning Python!) but it worked for me:
def insert_enum(element):
“””Returns an enum (class with attributes only) as text”””
enum_name = element.attrib[‘name’]
docstring = get_docstring(element)
enum_content = “\n\nclass %s:\n \”\”\”%s\”\”\”\n” % (enum_name, docstring)
members = element.findall(“{%s}member” % XMLNS)
for member in members:
enum_name = member.attrib[‘name’]
if enum_name[0].isdigit():
enum_name = ‘_’ + enum_name
except IndexError:
print(“Enumeration failed ” + enum_name)
enum_value = member.attrib[‘value’]
enum_value = enum_value.replace(‘\\’, ‘\\\\’)
enum_content += ” %s = ‘%s’\n” % (enum_name.upper(), enum_value)
return enum_content
Notice the new try…except, apparently the XML element causing this issue does not have a ‘name’ attribute hence why it fails. Like I said my fix probably isn’t the greatest but it gets it going.

Once the fakegir cache is generated, you have to add it as a content root in PyCharm as per the screenshot below:

Screenshot from 2015-01-10 15:01:48

Once this is done, code completion works successfully:

Screenshot from 2015-01-10 15:02:34

However if you try to run the application within PyCharm it now fails because the fakegir files are supplanting the real GTK 3 implementation. To workaround this, I disabled the options in Run Configurations to “Add content roots to PYTHONPATH” and was able to run the code successfully within PyCharm.

PyCharm Run Configuration

So that’s my first entry on my foray into the world of Python, GNOME and GTK+ 3 development. As I work through this application I’ll update the blog with my progress, hope you’ll find it interesting.