I have installed ubuntu 12.04 on my Thinkpad Edge (UEFI) using an USB-Stick. I guess it has been botted using EFI since a GRUB menu appeared with the options to boot a live system, install, or check the disk.

When I boot my laptop, grub only shows its command line prompt "grub>".

After manually running grub-install /dev/sda + update-grub within a chrooted environment it boots grub in recovery mode saying "File not found."

The disk is partitioned as follows:

/dev/sda1:    ntfs,  1.5GB, SYSTEM DRV
/dev/sda2:    ntfs,  150GB, Windows7 OS
/dev/sda3:    extended
  /dev/sda6:  ext4,  140GB, Ubuntu 12.04
  /dev/sda5:  ntfs, 10.7GB, Lenovo Recovery
/dev/sda4:    ntfs, 16.8GB, a custom additional partition

I guessed that the partition labelled "SYSTEM DRV" may be the EFI partition, but then I read that the EFI partition is of type FAT32. I don't have any FAT32 partition here!

So I can't follow any How-Tos explaining how to install Grub2 with EFI support. They all want me to mount my EFI partition at /boot/efi. I also can't just create an EFI partition since in most How-Tos they say that it should be the first partition (at least it has to be a primary partition), but as you see I already have a partition 1.

Isn't it possible to just use the normal Grub2 tool on EFI hardware?

If not, will creating an EFI partition solve the problem? Can I use partition 4 for that?

My BootInfo as created by using this article can be found here: http://paste.ubuntu.com/1011739/. Note that is being made from a Ubuntu Live USB drive which was at /dev/sdb, so you should ignore this drive.


As EFI doesn't seem to be the problem here, I reinstalled (non-EFI-)grub using boot-repair.

New BootInfo can be found here: http://paste.ubuntu.com/1012223/.

Problem is now, that BIOS doesn't boot but gives the error:

Operating system not found.


When you read this question when having the same issue (Operating system not found.), you might miss the forest for the trees when reading the answers, so I repeat the solution here:

The problem in my case was, that I accidently changed the boot flag of the drive to /dev/sda6, which is a logical partition. BIOS searches for boot flags on a hard drive it wants to boot from, but only looks in primary partitions. If it can't find a boot flag, it skips the hard drive. If it doesn't find any drive or media to boot from, you see the error "Operating system not found."

  • Re: "Operating system not found." I'm confused. If you were able to boot as far as GRUB command line before, what changed? I updated my answer with a variation to try on re-installing GRUB from you Live session. Commented May 28, 2012 at 23:04
  • In the first part of your question you say, "grub only shows its command line prompt grub>". Are you sure that was the prompt? I would expect you to instead see the message error: file not found. followed by the prompt grub rescue>. Commented May 28, 2012 at 23:16
  • @irrationalJohn Re: Re: "Operating system not found." This was after reinstalling grub using boot-repair. See the difference between the two BootInfos. I guess that now it's something wrong with how BIOS tries to boot my MBR now. The message means that BIOS can't even boot into grub itself, so the error can't be in grub itself. Am I right? So I'm confused too :( -- Re: "In the first part...": I'm not 100% sure but I remember that the first mistake was that Grub was installed on /dev/sdb isntead of /dev/sda by the automatic setup. So this (grub>) is irrelevant now.
    – leemes
    Commented May 28, 2012 at 23:55
  • Did you solve your problem? Commented Jun 3, 2012 at 3:18
  • @irrationalJohn Sorry that I replied not earlier. I solved it today. See my recent comment on the accepted answer.
    – leemes
    Commented Jun 3, 2012 at 22:50

2 Answers 2


The hard disk is definitely set up for BIOS-style booting. Specific evidence of this includes:

  • The partition table is MBR. Although it's theoretically possible to boot in EFI mode from an MBR partition table, to the best of my knowledge Windows does not support this configuration. Certainly its installer doesn't; the Windows installer supports MBR-on-BIOS or GPT-on-EFI, but not MBR-on-EFI or GPT-on-BIOS.
  • There's no ESP on /dev/sda. (There are EFI boot files on /dev/sdb1, but that looks like a USB flash drive, not your regular boot disk.)
  • The Boot Info Script output identifies GRUB as being installed in the MBR of /dev/sda. This is consistent with a BIOS-mode GRUB installation.
  • The Boot Info Script output has identified /Windows/System32/winload.exe as a boot file on /dev/sda2. If this were an EFI installation of Windows, you'd see a reference to winload.efi somewhere.

Thus, whatever the source of the problem, it doesn't seem to have anything to do with EFI; it's a straight-up GRUB-on-BIOS problem.

The biggest clue I see is this, from the Boot Info Script output:

=> Grub2 (v1.99) is installed in the MBR of /dev/sda and looks at sector 1 of 
   the same hard drive for core.img. core.img is at this location and looks 
   for (,msdos6)/root/grub on this drive.

Note in particular the reference to (,msdos6)/root/grub. Later in the Boot Info Script output, there's a list of boot files on /dev/sda6 ((,msdos6) in GRUB-speak). This list includes /boot/grub/grub.cfg, but there's no mention of anything in the root directory. In fact, the root directory (not to be confused with the / directory, whose name is pronounced "root") is the superuser's home directory, and it doesn't ordinarily hold boot files. Thus, I suspect that GRUB was mis-installed. Perhaps you used options to grub-install that you didn't mention and that were inappropriate, or perhaps there's a bug in the installation script. In any event, I recommend re-installing GRUB using the usual procedures for doing this on a BIOS-based computer. Note, however, that if your emergency system boots in EFI mode, that could create complications, so you should be sure to boot your emergency system in BIOS mode.

You can check your boot mode in Linux by looking for the /sys/firmware/efi directory. If it's present, you've booted in EFI mode. If it's absent, you've probably booted in BIOS mode (although there are conditions when that file will be absent even though you've booted in EFI mode).

  • Ok, first thanks for your time on this. There are some more questions arising: Should I have installed ubuntu when booted in BIOS mode? I couldn't manage to boot from the USB drive in BIOS mode. I see the directory /sys/firmware/efi when I boot the USB drive. But is this (the boot mode of the setup) important for the installed Ubuntu?
    – leemes
    Commented May 28, 2012 at 21:22
  • I looked in /root/ on /dev/sda6 when mounted and chrooted in the live setup. Before chrooting, I executed mount --bind /dev /mnt/dev and the same with /proc + /sys. Then executed grub-install /dev/sda and update-grub on the chrooted system. The How-To I found to chroot into the installed system didn't mention to mount /sys but when I did not, update-grub threw the error Cannot find list of partitions! (Try mounting /sys.) So I did. I can't remember giving /root as an argument to any command, but I maybe did ;)
    – leemes
    Commented May 28, 2012 at 21:26
  • So I now reinstalled grub exactly like described in my second comment. No change at all -- even the boot-repair output again says that grub was configured to look in /root/grub instead of /boot/grub on my hard drive. I can't explain this. /root only contains four default configuration files like .bashrc.
    – leemes
    Commented May 28, 2012 at 21:52
  • 1
    Your goal should be to boot both Ubuntu and Windows in the same mode (BIOS or EFI). Since Windows is already installed and booting in BIOS mode, it's likely to be easiest to install Ubuntu in BIOS mode, too. This, in turn, is most easily done by booting the installer in BIOS mode; however, it is possible to install in EFI mode and install a BIOS-mode boot loader.
    – Rod Smith
    Commented May 28, 2012 at 22:35
  • 1
    My suggestion now is to try to boot Ubuntu using Super GRUB 2 Disk (supergrubdisk.org). That will probably boot your system in BIOS mode. Then, re-install GRUB using grub-install, and create a new grub.cfg file with update-grub. You could do something similar by booting a BIOS-only repair disc such as System Rescue CD or PartedMagic, and using its GRUB tools to re-install GRUB.
    – Rod Smith
    Commented May 28, 2012 at 22:38

The help section linked in an earlier (deleted?) answer describes how to boot your system using its UEFI BIOS. This is what is meant by booting Linux "natively".

IF it is available on your Thinkpad, another alternative might be to use CSM or a function equivalent to it. This is an acronym for Compatibility Support Module. It is an Intel term. (The specification for the UEFI BIOS was developed by Intel.)

A CSM allows a system with a UEFI BIOS to boot legacy (non-UEFI) operating systems which only know how to interact with a legacy BIOS.

My understanding is that it is only possible to use so-called normal (i.e. legacy BIOS) GRUB tools on UEFI hardware if you can use something like CSM.


I wrote my earlier suggestions before taking a close enough look at the OPs partition table.

Apparently the MBR partitioning on the drive was placed there by Lenovo. So the Thinkpad Edge must already have some sort of BIOS compatibility in place to allow booting an MBR partitioned drive.

If that actually IS true, then erasing your current partitions and using GPT would NOT be a good way to go.

I would recommend that BEFORE making any drastic change you first discover how your system is currently functioning. Could you collect a BootInfo summary for your system? You could do this by booting using a Live CD/USB while connected to the Internet, selecting Try Ubuntu, and then using the steps outlined in this answer.

Note: At this point I would suggest only collecting information. Trying to apply fixes before you have a better understanding of your situation may only break something else.

I agree with Rod Smith's analysis of your BootInfo Summary. Ubuntu has already been installed in the partition /dev/sda6. GRUB and grub.cfg appear to be set up correctly in /boot/grub/ on /dev/sda6. The problem is that your boot sequence currently goes something like this:

  • GRUB bootstrap loader is loaded from sector 0 (MBR) of /dev/sda. It transfers control to GRUB's core.img which is at sector 1 of '/dev/sda'.
  • The core.img loader knows just enough about filesystems to load the rest of GRUB's modules from where it thinks GRUB is located, (,msdos6)/root/grub.
  • GRUB enters rescue mode when core.img is unable to load GRUB from (,msdos6)/root/grub

Update: comparing the old and new pastbins

I did a file compare on your two pastebin's. I have listed what I thought were significant differences below.

  • Line 07
    Previously, GRUB's core.img in sector 1 looked for (,msdos6)/root/grub. It now looks for (,msdos6)/boot/grub. In other words, you fixed the problem you were attempting to correct by re-installing GRUB.

  • Line 47
    I have no explanation for why it happened, but in addition to the boot file core.img which apparently still exists in sector 1, GRUB also added /boot/grub/core.img to /dev/sda6. (Perhaps this is related to the next change?)

  • Lines 77 & 81
    Previously /dev/sda1 was marked with the boot flag. Now the boot flag is on your Ubuntu partition, /dev/sda6. I think this may be what is causing your problem booting. Try switching the boot flag back to the first NTFS partition on your drive labeled SYSTEM_DRV and see if this helps. (I do not think it will hurt anything.)

  • Lines 154, 155, and 537 (old) 523 (new)
    Settings which were "efi" in the previous version of the pastebin now appear to use values for a legacy BIOS GRUB. In particular, under the section PARTITIONS & DISKS: the partition sda6 previously had the attribute grub-efi. It is now grub-pc.

There are some other changes which didn't seem worth describing in detail. For example, your edits to the file /etc/default/grub has been lost. The file is back to its default install content. Also, the menu entries for memtest are missing from the post-re-install grub.cfg file.

  • 2
    The EFI system partition has to be marked as such: wiki.archlinux.org/index.php/… And please, get rid of the "UEFI BIOS" term. There is either UEFI or BIOS, never both. Using "UEFI BIOS" while it may some how be true just creates confusion.
    – LiveWireBT
    Commented May 28, 2012 at 18:14
  • @LiveWireBT UEFI also requires a GPT drive. His drive appears to have been partitioned by Lenovo as MBR. Replacing it with GPT would destroy the Lenovo recovery partition as well as Windows 7 and whatever happens to be in that cryptic "SYSTEM DRV". Commented May 28, 2012 at 18:18
  • That would be the UEFI system partition in Microsoft-Lenovo-MBR fashion, I remember this from my Thinkpad SL500. Looks awkward, especially on non UEFI systems, but they have been shipping that. No you don't need GPT, you just use GPT if you want to do it right. But some people like to do it wrong, like Lenovo.
    – LiveWireBT
    Commented May 28, 2012 at 18:28
  • @irrationalJohn Thanks. I added my BootInfo in the quesition. I tried to boot with legacy support in the boot setup; it didn't want to boot the drive at all. By the way: Even Lenovo names it "UEFI BIOS" in its setup screen... :)
    – leemes
    Commented May 28, 2012 at 18:42
  • Thank you very much for your update. I'll try both alternatives tomorrow. My current problem is something more BIOS-related, so maybe Grub is now fixed by using boot-repair. My BIOS setup shouldn't have something to do with Grub, so maybe it will work after fixing the BIOS settings. But big thanks for such an extensive guide! Maybe I still need the now deleted part :) I report my success (hopefully) tomorrow. Cheers!
    – leemes
    Commented May 29, 2012 at 0:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .