My old Dell Vostro 1720 is on the way out, after giving sterling service for over six years. The replacement is a Lenovo E560. I just spent a day trying to get it to dual boot the installed Windows 7 and Ubuntu.

The first problem was that it would not boot Ubuntu at all – not even off a USB stick! I got an error message that seemed to be related to the AMD Radeon R7 M360 graphics card. It booted, then displayed a couple of messages in white text on a black screen before locking up completely with this message (prefaced by a timestamp):

[drm:si_dpm_set_power_state] *ERROR* si_upload_sw_stat failed

I was trying to use Ubuntu 14.04, because I like to stick to the LTS versions, but that is pretty old, so I tried 15.10 (the latest release at time of writing). That at least booted off USB, so that’s the version I will go with for now.

Booting it was not completely straightforward – instead of going to the usual options screen it complained about “not a CR32 image” and displayed a boot: prompt. I pressed TAB to see the boot options and typed “live” to get a LiveCD image booted, after which a normal looking Ubuntu desktop eventually appeared.

Sadly no wifi, but sticking a USB wifi dongle in resolved that for the moment. The touch pad and trackpoint devices didn’t work either, but a USB mouse did, which was also enough to be getting on with.

Ran “Install Ubuntu”; a vanilla install except that I elected to shrink the Windows7 partition and install Ubuntu alongside Windows 7. The install seemed to go through without issues, but after finishing there was no “ubuntu” option in the boot menu. The only option was “Windows Boot Manager”, and selecting that provided only Windows-related options.

By the way – the boot process on an E560 can be interrupted with F1, to go to the BIOS setup, or F12 to select the boot device. F12 is more useful, because the resulting menu lets you TAB between the boot device list and other options including the BIOS setup. F1 just takes you to the BIOS setup. I used F12 to select the USB stick for booting.

The BIOS settings were pretty good by default – secure boot was already disabled, UEFI support was set to “both” (UEFI and legacy). All I did in the BIOS was disable network booting.

The problem seemed to be the UEFI boot list. After rebooting back into Ubuntu off the USB stick, I installed efibootmgr and took a look at the UEFI details:

sudo apt-get install efibootmgr
sudo efibootmgr -v

There was no “ubuntu” entry.

I tried “reinstall” instead of “install” and this time when the install process got to the partitioning step and I clicked “Continue”, I was informed that the package grub-efi-amd64-signed had failed to install:

The "grub-efi-amd64-signed" package failed to install
into /target/. Without the GRUB boot loader the
installed system will not boot"

Another attempt and I got something related but different:

The partition table format in use on your disk normally
requires you to create a separate partition for boot
loader code. This partition should be marked for use
as an "EFI boot partition" and should be at least 35MB
in size. Note that this is not the same as a partition
mounted on /boot

I double checked and there was definitely a suitable partition there – the Windows Boot Manager partition, of type “efi” (code EF00), with plenty of spare space, and mounted on /boot/efi.

I tried adding another one, but was told that I now had two partitions sharing a mount point, so I unflagged my new partition and tried explicitly flagging the existing one as an “EFI System Partition”. That got me this error:

ubi-partman failed with exit code 141. Further
information may be found in /var/log/syslog [...]

So I undid my changes. All in all, it looked as if the necessary UEFI information was somehow just not making it onto my disk, and something was confusing the Ubuntu installer about it.

Rebooting into the LiveCD again, I tried manually installing the grub-efi-amd64-signed package:

sudo apt-get install grub-efi-amd64-signed

… and rather to my surprise it installed without error. On a hunch, I tried installing a default boot loader entry as well, using efibootmgr:

sudo efibootmgr -c

On rebooting, there was a new entry, “Linux” in the boot menu, so efibootmgr had done its job.

At this point I figured that the necessary boot loader was now on the disk, so I ran the Ubuntu install again – and this time, it went through without a hitch, the boot menu gained an “ubuntu” entry and I could boot into Ubuntu from the hard disk! I deleted the test boot entry I’d made and was good to go:

sudo efibootmgr -b 1 -B

It’s still not clear to me what fixed the problem. Was it the change to the boot list? Was it manually installing the UEFI boot loader code? Was it random good luck that the fifteenth install actually worked?

I think it was probably the boot loader code.

My thanks to the people on the Ubuntu users support mailing list, who pointed me at many useful links discussing UEFI, and offered many helpful suggestions.

This page has a very accessible description of UEFI, with plenty of links:

https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/

PS: The touchpad and trackpoint devices work fine in the final install, even though they didn’t from the LiveCD. The built-in wifi works too, yay! Suspending and unsuspending the laptop works fine using the menu options, the power button and the lid. Most of the special function keys work, too. Video and sound play fine, and the camera and microphone work too – with Skype at least, which is pretty much all I use them for. Compiz things like the rotating cube worked out of the box. The main strangeness is that if I hold a key down so that it repeats, then keep holding it down for a little longer, the key will keep repeating even after I let it go! I’ve never seen this before. It will repeat forever, or until I press the same key again, or any other key (though shift, ctl, alt etc don’t stop it). This only happens in X – not in consoles, not in Windows, so it’s not a  hardware issue.