EFI, Linux and other boot-loading fun a.k.a. where's my Grub gone

I've been gaming more recently, on hardware that is decent-in-some-contexts-but-definitely-not-in-this-one which has meant pathetic frame rates as low as 7~12FPS as my save files grew bigger. A kind soul took pity on me and installed a better graphics card in my machine while I wasn't looking - which of course is when everything started going wrong.

I'll gloss over the "Not turning on" part because that was due to mislabelled wires - the real problem began when Windows for some reason picked up that something had changed at boot time, and promptly overwrote the boot loader.

Cannot boot from USB keys

None of my LiveUSB sticks would boot.

This turned out to be due to the device (or the system on it?) not being compatible with EFI. I'm not sure how to make a EFI-compatible Live USB system and didn't need to in the end - if you absolutely need to, enabling CSM mode in the BIOS ("Compatibility Support Module") was useful there, but likely wouldn't have helped with fixing my boot-loader. EFI and Legacy OS shouldn't be dual-booted in parallel - you can read more about this at the beginning of that excellent page.

Side-note: "chroot: cannot execute /bin/sh"

That was because the Live USB stick turned out to be a 32 bit system, while my desktop OS is 64 bits.

Where's my EFI partition anyway

I found an old install CD for Debian testing 7.10 (64 bits) lying around that turned out to have a Rescue mode option.

To prepare the system for the chroot that would fix All My Problems, first I had to figure out what was on which partition. The rescue mode let me mount them one by one and take a peek, though using parted would have been much faster.

# parted /dev/sda print
Model: Blah
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name                          Flags
 1      1049kB  420MB   419MB   ntfs            Basic data partition          hidden, diag
 2      420MB   735MB   315MB   fat32           EFI system partition          boot, esp
 3      735MB   869MB   134MB                   Microsoft reserved partition  msftres
 4      869MB   247GB   247GB   ntfs            Basic data partition          msftdata
 6      247GB   347GB   100GB   ext4            debian-root                   msftdata
etc etc etc

So my Debian partition is on /dev/sda6, the EFI stuff is on /dev/sda2. I need to make a Debian chroot and reinstall Grub from there - that's the kind of stuff I learnt last time I broke a lot of things.

Let's chroot and grub!

After selecting the "Execute a shell in Installer environment" option:

# mount /dev/sda6 /mnt
# mount -o bind /dev /mnt/dev
# chroot /mnt

Error: update-grub: device node not found

This one I think happened because I only bind mounted /dev, when you also need things like /dev/pts, /sys, /proc.

# for i in /dev /dev/pts /proc /sys ; do mount -o bind $i /mnt$i ; done

Error: grub-install /dev/sda: cannot find EFI directory

That one was before I figured out I also needed to mount the EFI special boot partition - sda2 as shown in the printed output.

# mount /dev/sda2 /mnt/boot/efi

From then on I read about the efibootmgr tool and decided to try and use that instead.

Error: efibootmgr: EFI variables are not supported on this system

Outside the chroot, you need to load the efivars module:

# modprobe efivars

How are things looking by now

# modprobe efivars
# mount /dev/sda6 /mnt
# mount /dev/sda2 /mnt/boot/efi
# for i in /dev /dev/pts /proc /sys ; do mount -o bind $i /mnt$i ; done
# chroot /mnt

Usually I can never remember the mount syntax (does the mount point come first or second?!) but I typed these commands so many times today, I bet I'll remember the syntax for at least a week.

Playing with efibootmgr

I tried to use the following command from the "Managing EFI Boot Loaders for Linux" page but it didn't quite work for me.

# efibootmgr -c -d /dev/sda -p 2 -l \\EFI\\debian\\grubx64.efi -L Linux

While this did add a Linux entry to my F12 BIOS boot menu (yay!), that booted straight into a black screen ("Reboot and Select proper Boot Device or Insert Boot Media" etc etc). Later on I learnt about the efibootmgr --verbose command which shows the difference between the working entry and the non-working one:

# efibootmgr --verbose
Boot0000* debian    HD(2,c8800,96000,0123456789-abcd-1234)File(\EFI\debian\grubx64.efi)
Boot0005  Linux    HD(2,c8800,96000,0123456789-abcd-1234)File(\EFI\redhat\grub.efi)\EFI\debian\grubx64.efi

I'm not quite sure how the path ended up looking like that. It could be a default somewhere, or I'm quite willing to believe I did something wrong - I also made a mistake on the partition number when I first ran the command.

But how did you fix it?!

Despite showing all the options I wanted in the efibootmgr output within the chroot, running grub-install and update-grub multiple times did nothing: I'd still boot straight into Windows or straight into a black screen. The strange thing is that even though only "Windows Boot Manager" and my new "Linux" entry were in the F12 boot menu, the BIOS setup did offer a 'debian' entry (created automatically at install time a long time ago) was in the boot ordering options. Moving it around didn't change a thing though.

The efibootmgr man page talks of a "BootNext" option. With the 'debian' entry right in front of me, why not try it? It's entry Boot0000 on my list, therefore:

# efibootmgr -n 0

Ta-dah! I rebooted straight into Grub then Debian. From there, grub-install /dev/sda and update-grub worked just fine.

Things I still don't know

  • Why did this happen in the first place? Can I prevent it from happening again?
  • I'm not sure why the grub install properly worked that last time. Did I miss something when working from the chroot?
  • Where does the "redhat\grub.efi" line come from, and can I amend that?
  • Why does Windows take so long to restart each time, when I don't even log in?


  • Linux on UEFI: A quick installation guide - I found this site incredibly informational.
  • The efibootmgr man page is very nice and contains useful examples.
  • GrubEFIReinstall - I probably would have tried that tool at some point. I postponed because I didn't have an easy way to burn a CD and wasn't sure about how to boot from USB without enabling CSM.
  • Booting with EFI, a blog entry about fallback boot loaders. While this didn't help in my case, I found the article very clear and enjoyed getting an explanation of the context around the problem in addition to the solution.

Punch line: the graphics card wasn't the bottle neck and my frame rate still hovers around 9FPS.

Leave a comment | 2 so far

Switching locale (Gnome 3, Fedora 20) and making sure all the menus switch too

In the spirit of immersion, I switched the laptop's language to Japanese, however most of the Gnome menus remained in English even after switching the System Language altogether, logging out etc. Another profile on the laptop shows the menus for Activities, etc in Japanese just fine so it wasn't a missing package. I found the following in ~/.profile, which seems a bit heavy-handed but does do the trick. For future reference:


Note on restarting X one is asked if they want to change the names for the default folders like Documents, etc. Personally I find it makes using the CLI a pain and don't recommend it.

Leave a comment

Adventures with Steam on Linux Today: Mark of the Ninja doesn't start

I've been getting back into PC gaming for the last couple of months, and that has involved a lot of checking out what Steam on Linux looks like nowadays (i.e. playing lots of games). Most of the time everything works just fine and smoothly, but sometimes there are hiccups and yesterday I was motivated to learn how to debug them. Our story begins: Mark of the Ninja wouldn't start when clicking on the "Play" button from within the Steam client.

For context I'm running Steam on Fedora 19, 64 bits. I have a separate "Library" folder on another partition on which I install the games instead of Steam's default location in ~/.local/share.

Running the game from the command-line

Launching from the Steam client gives me zero information, just a brief black screen, so I thought I would see what happens when attempting to launch the game from the command-line.

jpichon@localhost:~/games/steam/SteamApps/common/mark_of_the_ninja/bin$ ./ninja.sh 
dlopen failed trying to load:
/home/jpichon/.local/share/Steam/ubuntu12_32/steamclient.sowith error:
libtier0_s.so: cannot open shared object file: No such file or directory
[S_API FAIL] SteamAPI_Init() failed; Sys_LoadModule failed to load: /home/jpichon/.local/share/Steam/ubuntu12_32/steamclient.so
[S_API FAIL] SteamAPI_Init() failed; unable to locate a running instance of Steam, or a local steamclient.dll.
./ninja.sh: line 3:  6477 Segmentation fault      (core dumped) ./ninja-bin32

Note that the Steam client must be started in order to even get that far. That library does exist at that location, let's see what's preventing it from being loaded:

$ ldd /home/jpichon/.local/share/Steam/ubuntu12_32/steamclient.so
    linux-gate.so.1 =>  (0xf77cb000)
    libtier0_s.so => not found
    libvstdlib_s.so => not found
    librt.so.1 => /lib/librt.so.1 (0xf67f4000)
    libX11.so.6 => /lib/libX11.so.6 (0xf66ba000)
    libusb-1.0.so.0 => /lib/libusb-1.0.so.0 (0xf66a1000)
    libopenal.so.1 => /lib/libopenal.so.1 (0xf664a000)
    libpulse.so.0 => /lib/libpulse.so.0 (0xf65fa000)
    libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0xf65aa000)
    libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0xf647b000)
    libdbus-glib-1.so.2 => not found
    libnm-glib.so.4 => not found
    libnm-util.so.2 => not found
    libudev.so.0 => not found
    libm.so.6 => /lib/libm.so.6 (0xf6437000)
    libdl.so.2 => /lib/libdl.so.2 (0xf6432000)

A number of these libraries already exist in Steam's ubuntu12_32 directory. Let's add it to our library path.

$ export LD_LIBRARY_PATH=/home/jpichon/.local/share/Steam/ubuntu12_32:/home/jpichon/.local/share/Steam/linux32
jpichon@localhost:~/games/steam/SteamApps/common/mark_of_the_ninja/bin$ ldd /home/jpichon/.local/share/Steam/ubuntu12_32/steamclient.so
    linux-gate.so.1 =>  (0xf7749000)
    libtier0_s.so => /home/jpichon/.local/share/Steam/ubuntu12_32/libtier0_s.so (0xf676b000)
    libvstdlib_s.so => /home/jpichon/.local/share/Steam/ubuntu12_32/libvstdlib_s.so (0xf6727000)
    libdbus-glib-1.so.2 => not found
    libnm-glib.so.4 => not found
    libnm-util.so.2 => not found
    libudev.so.0 => not found

Yup, that does seem to help. Let's add the rest:

$ export LD_LIBRARY_PATH=/home/jpichon/.local/share/Steam/ubuntu12_32:/home/jpichon/.local/share/Steam/linux32:
$ ldd /home/jpichon/.local/share/Steam/ubuntu12_32/steamclient.so | grep not

Excellent! Let's see if the game can run from the CLI now:

$ ./ninja-bin32 
[S_API FAIL] SteamAPI_Init() failed; no appID found.
Either launch the game from Steam, or put the file steam_appid.txt containing the correct appID in your game folder.
Segmentation fault (core dumped)

How to find a Steam appID?

That one's easy to find a solution for. One can either look at the ID in the store URL as linked earlier or check out steamdb. Let's create a file with the correct ID in that directory and try again.

$ emacs -nw steam_appid.txt
jpichon@localhost:~/games/steam/SteamApps/common/mark_of_the_ninja/bin$ ./ninja-bin32 
Setting breakpad minidump AppID = 214560
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198074768941 [API loaded no]
ERROR: Missing required OpenGL extensions.
ERROR: Missing required OpenGL extensions.
ERROR: Missing required OpenGL extensions.
ERROR: Missing required OpenGL extensions.

Missing required OpenGL extensions

At first I thought that was it - my laptop simply wasn't powerful enough to play the game. But fear not, ArchLinux came to the rescue and thanks to them I learnt about the handy -enablelog flag for the game.

$ ./ninja-bin32 -enablelog
$ less ~/.klei/ninja/log/rendering.log 
[16:34.09] (4144580416) EXT_texture_compression_s3tc required

The solution is to install the libtxc_dxtn package (available in rpmfusion-free) and/or set force_s3tc_enable=true as an environment variable (discovered in a cached version of the developer's official forum, as it's currently showing blank pages for me).

I think I had to restart X to make sure the new library was picked up correctly, and then success!

Additional notes: The game still requires the Steam client to be running, and the Steam overlay won't work. However your Steam status will be correctly shown as in-game and the time, etc, should update correctly.

Starting the game from Steam

Unfortunately, starting the game from Steam still didn't work, and I also happen to quite like the overlay especially for games that don't react well to Alt-tabbing. I modified the ninja.sh script to add the new paths and environment variables, with no luck.

To help with troubleshooting: right-click on the game name then go to Properties, there is a "Set launch options" button. There we can add the friendly -enablelog flag discovered earlier. Trying and failing to launch the game again gives us some helpful logs in the same location as before in ~/.klei.

[17:25.42] (4144023360) Failed to CreateDevice
[17:25.42] (4144023360) KGraphics failed to initialize.

[17:25.42] (4144023360) EXT_texture_compression_s3tc required

Sadly, the same problem as before - it turns out ninja.sh is likely not used at all when launching from Steam so the extra environment variables are not being picked up.

If Steam isn't using ninja.sh, how can I find out what it is using and if I can change it?

In the end, installing libtxc_dxtn.i686 (in parallel to the .x86_64 version) resolved the problem. I'm not sure why the game insists on using 32 bits libraries when articles over the web make it clear it supports 64 bits, but either way that did the trick and the game now behaves correctly like any other Steam game.

I'm still somewhat unhappy about that last part because it was more guesswork than debugging, and I don't feel equipped to properly gather information next time a similar issue occurs. How can I know which binary / path / file Steam is trying to launch and with what flags?

Hopefully while I go on to continue my Steam journey, this will have been helpful to someone else. Happy gaming!

Bonus track: the game is sloooow

After all this, it turns out my laptop is indeed a bit underpowered to play this particular game. Deactivating blur, bloom and displacement in the options helped, and so did greatly lowering the resolution (windowed mode would help too but it became pretty much unreadable to me then, so I favoured the fullscreen 640x480 instead. Your tolerance levels may vary!)

Leave a comment | 1 so far

git diff showing a weird output ^[[1;33m^[[mmmmh?!

I came back to an old project on another machine only to find that the git diff command did not behave as expected anymore:

^[[1;33mdiff --git a/myproject/myapp/models.py b/myproject/myapp/models.py^[[m
^[[1;33mindex 0216829..d9e1637 100644^[[m
^[[1;33m--- a/myproject/myapp/models.py^[[m
^[[1;33m+++ b/myproject/myapp/models.py^[[m
^[[1;35m@@ -87,6 +87,12 @@^[[m ^[[mclass DoomDoomDoom(models.Model):^[[m

Instead of showing the colours defined in ~/.gitconfig, it was displaying escaped sequences in black and white, as well as a "(stdin)" prompt at the bottom of the page.

At first I thought it was a difftool issue but actually it relates to the pager, i.e. with either of these commands things works well:

$ git --no-pager diff # No paging
$ git diff --color | less -R # With paging

The default pager in git is supposed to be 'less'... Still, making sure it actually is fixed this for me:

$ git config --global core.pager 'less'

I'm still annoyed. Why was a different pager being used (and not showing in git config --list) and what tool was it?

Leave a comment | 2 so far

wvdial: stackmaster assertion failure & EuroPython

At EuroPython, I happily took advantage of the prepaid SIM card that you could order together with your ticket. However tethering with Wind (Italy) was not to work that simply. On Debian Wheezy I ended up with the following error:

--> Modem initialized.
wvdial: utils/wvtask.cc:409: static void WvTaskMan::_stackmaster(): Assertion `magic_number == -0x123678' failed.

A bit of astute googling reveals that libwvstreams needs to be downgraded.

$ aptitude versions libwvstreams4.6-base # or apt-cache policy libwvstreams4.6-base
Package libwvstreams4.6-base:                        
p A 4.6.1-1                                       stable                    500 
i A 4.6.1-4                                       testing,unstable          500 
$ sudo aptitude install libwvstreams4.6-base=4.6.1-1

Tadam! wvdial now works. The same configuration as last year seems to do the trick (though on Fedora 16, the Network Manager's Mobile Broadband tool was easy to set up with Wind without  bothering with wvdial.)

[Dialer wind]
Modem Type = USB Modem
Modem = /dev/ttyACM0
Username = "wind"
Password = "wind"
Init6= AT+CGDCONT=1,"IP","internet.wind"
Leave a comment

Debugging udev rules under Debian

I've been playing with the Finch, however today I was unhappy to discover that the robot stopped working again for non-root users. The Finch documentation helpfully links to this blog post on how to write a udev rule, which is the script I was using in the first place.

SUBSYSTEM=="usb", SYSFS{idVendor}=="2354", SYSFS{idProduct}=="1111", MODE="0660", GROUP="plugdev"

Time to figure out how to debug udev rules! The debian wiki hints at a tool called udevtest, which doesn't exist on my system or in aptitude. Turns out nowadays one should use udevadm test instead. Here we go: thanks to lsusb I know that the Finch is on bus 001, device 007.

# udevadm test /dev/bus/001/007

In the output around the rules file for the finch, there is this:

add_rule: unknown key 'SYSFS{idVendor}' in /etc/udev/rules.d/55-finch.rules:1
add_rule: invalid rule '/etc/udev/rules.d/55-finch.rules:1'

Looking for documentation on how to write udev rules, one would find the following guide, which indicates that ATTR should be used instead of SYSFS. Let's rewrite the rule:

SUBSYSTEM=="usb", ATTR{idVendor}=="2354", ATTR{idProduct}=="1111", MODE="0660", GROUP="plugdev"

The error doesn't show in the udevadm test output anymore, and unplugging/replugging the Finch makes it usable by non-root users again. Victory!

Leave a comment | 4 so far

aptitude / apt-get limbo

A couple of weeks ago I started getting in trouble when trying to update my system (Debian Wheezy) via aptitude. A dozen or so packages were failing to configure, and while these failures occurred other packages couldn't install.

Output would contain things like this:

Setting up install-info (4.13a.dfsg.1-8) ...
/var/lib/dpkg/info/install-info.postinst: 32: /var/lib/dpkg/info/install-info.postinst: update-info-dir: not found
dpkg: error processing install-info (--configure):
 subprocess installed post-installation script returned error exit status 127
configured to not write apport reports
                                      Setting up gconf2 (2.32.4-1) ...
/var/lib/dpkg/info/gconf2.postinst: 52: /var/lib/dpkg/info/gconf2.postinst: gconf-schemas: not found
dpkg: error processing gconf2 (--configure):
 subprocess installed post-installation script returned error exit status 127
configured to not write apport reports
                                      dpkg: dependency problems prevent configuration of evolution:
 evolution depends on gconf2 (>= 2.28.1-2); however:
  Package gconf2 is not configured yet. [...etc... updaterc.d not found... update-initramfs not found...]

I'm not quite sure how or why that happened but it turned out to be a $PATH issue. Widespread problems that wreck systems tend to be small changes in one critical place, I find.

To debug it, I picked the first item not found:

$ locate update-info-dir
$ echo $PATH
<lots of stuff but not /usr/sbin>

From then on, append the missing directory to your $PATH in .bashrc, and/or you can also switch to the root user who hopefully would have a clean environment. $ dpkg --configure -a and you're flying again!

Leave a comment | 2 so far

Getting Hibernate (Suspend to disk) working Linux Debian Squeeze / Lenovo Thinkpad X201

Here's how I got Hibernate working on my Thinkpad X201, currently running Debian Squeeze.

First, make sure you have a swap partition at least as large as your RAM. Following that little incident last year, my swap had a different UUID and I never realised it was never mounted. Manually editing /etc/fstab following the useful blkid output did the trick.

Second, install uswsusp, helpfully discovered thanks to the ThinkWiki.

And that's it! Hibernate works, through the Shutdown menu and pm-hibernate, and so far Suspend doesn't seem to have been adversely affected. Woohoo!

Leave a comment

FOSDEM, over and out

Another fantastic edition of FOSDEM is now finished. Many thanks to the organisers for another great job!

Welcome talk, picture of the room

Amazingly, the Welcome talk managed to top off last year's FOSDEM dance, this time by making the audience contribute the music. I hope they do it again next year, it was kind of fun smashing hands on the wooden board (middle row, yep!)

Lift door with the writing: Today's recommendation: Make a friend. Smile at the person next to you.

Many stands, a ton of talks, even more people than last year. Some dev rooms remained closed because full for most of the conference, but surprisingly if one carefully planned which talks to attend and made sure to be there a little early, it was usually possible to get in and even grab a seat.

Lots of people standing outside

I'll post short summaries of some of the talks I attended. This year I took notes on my phone (my lovely lovely N900) for all talks but one. I also took more pictures, which is great (although the quality of the pictures isn't always). Looks like getting the phone out to snap a pic is less of an effort than having an actual camera to carry around, get out of the case etc.

A huge camel plush at a stand

This was my 3rd FOSDEM and this time I spent a bit more time on the social aspect, sometimes even skipping talks (gasp!) I cared a little bit less about to chat with interesting people. This is great, though it made the conference quite a bit more exhausting. Must balance better -- and find a nice hotel in a quieter neighbourhood.

Once again delighted with the experience. Until next year, FOSDEM! :)

A chocolate snowman

Leave a comment

Tethering on the N900

As FOSDEM (woohoo \o/) draws closer and the likelihood of spending a lot of time in the airport doesn't change, I thought it was time to find out how to use my N900 as a modem or for "tethering" as I'm told the proper word is.

Some background:

  • my laptop runs Debian Squeeze (unstable) -- the stable release is coming out this week-end by the way!
  • my phone carrier is Meteor (Ireland) and I use their 3G/GPRS connection for data.

Tethering via the USB cable

The official Maemo webpage makes it all sound real simple but it didn't quite work this way for me. The wizard did not appear either on Debian or when I tried on Ubuntu 10.10. Although the phone did show up in Network Manager -> Wired networks, it only displayed as Disconnected and I couldn't find any option to set up a new 3G network.

After many failed attempts, this is the approach that worked for me. It requires wvdial. One annoyance: it works once, then I need to unplug and re-plug the phone.

Here's the wvdial information for Meteor Ireland:

APN: data.mymeteor.ie
Username: my
Password: meteor

Tethering via Bluetooth

Emboldened by my success I decided to follow the link to the Debian wiki on how to set up the same using Bluetooth. I was very disappointed to see they recommend using a KDE app even under Gnome, and when I looked at the number of dependencies it would bring I thought I'd take my chance the Gnome way.

...I'll skip on the embarrassing moments where I was thinking Gnome 3 wasn't set up yet to handle Bluetooth then found out the Bluetooth service was actually turned off... *cough* I used the Bluetooth applet to pair with the phone and followed the rest of the instructions on the wiki page, until the rfcomm command brought up the following error.

Can't connect RFCOMM socket: Connection refused

Using "sdptool browse <N900_MAC_ADDRESS>" revealed that I did not have the "Dial up networking service" running on the phone. You actually need to install an extra app, available in the repos first (application name is: Bluetooth Dial-Up Networking). I then followed these instructions on the Maemo wiki to set up rfcomm.conf, until "Restart the bluetooth stack" in the first section, and ta-dah! With "wvdial bluetooth" I can now start the connection via Bluetooth.

To be honest I'm sure this is a battery drain nightmare and I can't imagine tethering without the cable but heh! I learnt about several new tools and if I ever need it, it's there :-)

Final wvdial.conf, in all its mighty glory

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Baud = 460800
New PPPD = yes
ISDN = 0
New PPPD = yes
Phone = *99***1#
Username = "my"
Password = "meteor"
Init6= AT+CGDCONT=1,"IP","data.mymeteor.ie"

[Dialer usb]
Modem Type = USB Modem
Modem = /dev/ttyACM0

[Dialer bluetooth]
Modem = /dev/rfcomm0
Leave a comment | 5 so far

Linux on the Lenovo ThinkPad X201

As anyone who's been within hearing range can tell you, I've acquired a new laptop recently that I've grown quite fond of. Here's my experience getting various Linux distributions working on it, your mileage may vary (e.g. my experience with Debian was widely different from others'). I ordered the laptop from the Lenovo website, the only significant specs change was to upgrade to the i5-540M processor.

Ubuntu 10.10

The latest version, Maverick Meerkat / 10.10 installed fine, no issues whatsoever.

Debian Squeeze

Debian is my main development distro and I absolutely needed it working on the laptop before setting up everything to be Just RightTM. Unfortunately, stable wouldn't boot, and the daily testing images were acting very weird, asking me for a password and, no matter what I typed, showing me an empty grub menu that slowly disappears up the screen.

Eventually I solved this thanks to UNetbootin, using it to create a LiveUSB from Debian unstable. I'm not quite sure how it does that, but whatever it did did the trick (yay!) and I was able to boot from the stick and install Debian off it. If you go this way, don't forget to update your apt sources.list to point to unstable. Also, Suspend works for the first time ever, wahoo :D Hibernate was a bit more moody, though it worked last time I tried it. The option seems to have disappeared from my menus a couple of weeks back, but I've been messing with various things including Gnome Shell, which may be related.

Fedora 13/14

The Fedora 13 stick seemed a bit reluctant to boot up fully, but did so after a couple of tries. The installer's partition editor wasn't playing so nice and I ended up using GParted first to create the partition (which led to entirely unrelated problems due to my own clumsiness). Once this was done everything was fine, including the wireless. When I was trying Fedora 14 prerelease in late October the stick booted fine, and since then I've upgraded to Fedora 14 without an issue either.

Sugar on a Stick (Mirabelle -- based on Fedora 13)

The stick does not boot :/ (Black screen with the grey blinking underscore on the top left). I must install Mango Lassi (based on Fedora 14) on a stick soon and check out if that works...

I still have more space than I need after installing those 3. I'll probably try to install a source-based distro as well, either Arch or Gentoo, not sure yet. Recommendations?

Leave a comment | 2 so far

Recovering a lost partition table Trial by fire

If your hard drives are currently doing fine and you're ready to skip this article, please just do this for me: run fdisk -l as root, maybe fdisk -u -l as well and store the output in a file on a usb stick or another machine. Thanks. That's the kind of thing you chuckle at until a twitch or update destroys your partition table and you're staring at a black screen with a blinking grey underscore instead of a boot screen, knowing that your data is there somewhere but the computer doesn't know where to find it. Neither do you. With that info you'll be able to recreate the partition table using fdisk or parted, following tutorials online.

Now let's assume you're like me and you don't have that data. Here are a few links and ideas that you can try out, most of which didn't work for me but all taken together ended up giving me a working system back. Arm yourself with a LiveUSB stick running Linux, and let's begin.

Try #1: gpart

Not to confuse with gparted, which by the way is the tool I messed up my laptop with. I was reading the menus wondering why the resize option was greyed out, when I had one of those finger twitches (too much caffeine?) and bam! An 'error' alert popped up and the layout of my hard drive changed to "Unallocated" -- and that was it. One twitch! I should try to reproduce the bug now that I have my fdisk output, but I'm not brave enough yet... (Working machines are so handy!)

...Anyhow. Gpart came with the recommendation that "it worked for me X years ago, and here's the actual web page I used to fix things", so I tried it. Gpart works non-destructively and tries to guess where your lost partitions start and end.

I'm afraid to say gpart failed miserably for me, only listing a 3Mb partition that I don't think actually exist, after a 2h run. It's still worth a shot, and won't do any harm if it doesn't work.


  • Recovering a lost partition table, including what to do after gpart gives you back accurate looking information
  • Partition-Rescue HOWTO -- I was reading this while waiting for gpart to finish, it gives other tips on how to find/guess your partition table, including a command (cat /proc/partitions) that should work beautifully if you haven't rebooted the machine yet after erasing/losing the partition table
  • gpart -- A bit more information, example output, manpage, changelog

Try #2: Testdisk

Running testdisk (quick search)

Googling more I came across Testdisk, a very cool utility that do the same thing as gpart and then more, and is also available in the Fedora repositories. The most important thing I can say is to read the site carefully. I found the step by step guide especially useful. The commands are not always straightforward (p to list files?) but it's incredibly powerful and the second the "Quick search" started running it was already listing a fairly good idea of my 6 main partitions and their types.

Running testdisk (deep search)

I thought deep search wasn't working for me but reading the step by step guide, I realised it gives back potentially overlapping partitions and it's up to you to examine them to find the most likely one. Considering I could list the files off all my partitions after the quick search, I decided to give up on the deep search output and start again, using what quick search gave me as my best bet for writing a new partition table.

Writing the partition table

Select the Write option when you feel ready. This is not a destructive option either, in that if you get it wrong you can try running gpart or testdisk again, and write another table based on a different guess.

Win #1: Data backup

The new partition table didn't actually quite work for me. Windows wouldn't boot, and Grub was gone so I had no access to my Linux partitions. I booted off the LiveUSB stick again, and mounted the newly remade partitions from the 'Places' menu to back up the files I sort of cared about (this is a 1-week old laptop! Not much data).

chroot magic + grub

Making sure I only had one partition mounted (Ubuntu in this case), I chrooted into it from its mount point in /media.

chroot /media/1234-5678-90ab-cdef 

From there the idea was to use grub-install to reinstall grub. The hard drive I was trying to rehabilitate was /dev/sda, replace with the drive you want to fix.

grub-install /dev/sda

Now that didn't quite work for me. I forgot to write down the exact error messages, but it was complaining about not being able to write to /dev/null. This Ubuntu Forum post helped me solve that one, and by the way also contains more ideas to try out if you end up still grub-less.

Now, for the proper /dev directory to be picked up in your chroot environment:

mount -o bind /dev /media/1234-5678-90ab-cdef/dev

grub-install /dev/sda should now works handsomely :) Rebooting the machine, only Ubuntu was visible in the Grub boot menu. Running update-grub within Ubuntu resulted in an accurate list of every OS during the following boot, yay.

Note that I actually sort of lost a partition in the process, the OEM "Rescue partition" that Lenovo set up at the end of the drive. TestDisk picked it up properly, but this partition is supposed to run when pressing the blue ThinkVantage button, and wouldn't start anymore. I didn't feel too sorry and deleted it (one more primary partition slot for me!). I also had to recreate the swap partition, which is pretty minor.

Thanks TestDisk for saving the day! :)


Leave a comment