Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

After doing a fresh install of Ubuntu 12.10 from a USB Thumb Drive, (Using UNetBootin to Copy the ISO to the Thumb Drive ... If that matters.) I installed Ubuntu onto my system.

I have these devices available to me.

P1: ASUS DVD/Blue Ray RW P2: Corsair 240GB SSD (Windows) P3: Corsair 240GB SSD (Ubuntu) P4: Western Digital 750 GB HDD (Data Drive) P5: Western Digital 80 GB HDD (Data Drive)

I installed Ubuntu onto P3, resulting in the system showing up on the /dev/sdc drive. I removed all of the old partitions on that drive, did a quick format of the file system using the installer, and left the drive empty. I then clicked on the drive, and hit next. The installer from the Live USB Drive complained that I did not have a SWAP volume, but I ignored that warning. About 5 minutes later, the install was done. Restarted the system, only to have the GRUB Rescue menu pop up.

I followed the guide found here ... ... and managed to get the system to boot. Thinking that was going to be the end of it, I installed all of the software I used and did the updates as normal. After it asked me to restart, I did and this time I got a GRUB prompt.

Following the guide above again, I used the configfile command and pointed it to the grub.cfg file and everything booted just fine again. Not wanting this problem to happen every time I wanted to boot, I followed the section Post-Boot Follow Up and got the following errors ...

dygear@Dygear-Ubuntu:~$ sudo update-grub
[sudo] password for dygear: 
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.5.0-23-generic
Found initrd image: /boot/initrd.img-3.5.0-23-generic
Found linux image: /boot/vmlinuz-3.5.0-17-generic
Found initrd image: /boot/initrd.img-3.5.0-17-generic
Found memtest86+ image: /boot/memtest86+.bin
Found Windows 7 (loader) on /dev/sdd1
/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..
/usr/sbin/grub-probe: warning: Couldn't find physical volume `(null)'. Some modules may be missing from core image..

This is the drive with my linux install on it.

dygear@Dygear-Ubuntu:~$ sudo fdisk -l /dev/sdc

Disk /dev/sdc: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x75a8b2f8

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1            2048   468860927   234429440   83  Linux

I've had little luck beyound this point, and I have no idea how to repair this problem when the tools provided don't seem to work.

It should be noted that I have an ASUS UEFI capable motherboard. Most of the commands that I was using in the GRUB recovery console pointed to an i386-pc path, where it should of been an x86_64-efi path. That might be part of the problem, I'm not sure.

dygear@Dygear-Ubuntu:~$ ls /boot/grub
fonts  grub.cfg  grub.efi  grubenv  locale  x86_64-efi

Any ideas on how to fix this, or should I report this as a bug?

share|improve this question
Fun fact, the boot-repair config actually made this worse. I was brought back into a grub repair> screen on my next boot, and had to do set prefix=/grub_old, insmod normal that gave me a colored prompt, then I did insmod linux. From there I did linux /vmlinuz root=/dev/sdc1 ro and initrd /initrd.img followed by boot to get back into my system. – Mark Tomlin Feb 22 '13 at 8:45

In the 13.04 beta, I downloaded you can fix the underlying cause for this problem by manually partitioning the drive you are installing too, to add a EFI partition at the very beginning of the drive. This makes the installer realize that it needs to install grub-efi there.

Let's first off, boot your system from the Rescue GRUB prompt.

Reboot the system, and boot into the correct drive for your install with Ubuntu. You should be presented with a grub rescue> prompt. From there type the following to boot into the system.

  1. set prefix=/boot/grub/
  2. insmod normal This should turn your prompt's text from grey to white.
  3. insmod linux.
  4. linux /vmlinuz root=/dev/sdXY ro Replace X and Y with letter and number of your drive.
  5. initrd /initrd.img
  6. boot.

This should start the boot process for your system.

Now that your are in your system, it's time to fix the underlying problem. For me that problem is that it can't find the /grub/i386-pc/ folder. The following should have you booting your system without having to rescue it.

  1. Press Alt + F2.
  2. Type gksudo nautilus and press Enter.
  3. Type your password.
  4. Copy your /boot/grub/ directory into your / root directory.

The end result should be that you still have a /boot/ and now you have a /grub/ directory. Reboot the system and it should work. If it does not work, well, you're back at square one.

It seems to me that the under the following circumstances that GRUB will fail to boot the system right after installation of Ubuntu 12.10 if the following conditions are TRUE.

  1. You have an UEFI based system.
  2. During the install process you delete the entire disk that you are installing too.
  3. After deleting the entire disk, you do not make a new partition, but simply click next and let the installer do it's magic.

This seems to me where the problem stems from, because the installer does not take into account that it needs to make a EFI partition for the /boot/ directory, but GRUB does not get this memo at all and as far as it knows the /boot/ directory is on it's own partition. From there GRUB tries to read /grub/ but it can't because it's nested in /boot/grub.

That's my take on it anyway. Thankfully my system now boots without me having to do some crazy kung-fo on the grub command line.

share|improve this answer

I had a similar problem with my Ubuntu machine. I used software-update to upgrade to 12.04 from 11.10 and somewhere along the way something broke. I was booting into the grub rescue prompt and then I did something I can't remember and was then constantly booting to the grub prompt. From the grub prompt I could load the configfile with the command:

grub> configfile (hd0,msdos1)/boot/grub/grub.cfg

I tried update-grub, but that didn't help. Then I just reinstalled grub with:

$ sudo grub-install /dev/sda

...and then ran update-grub for good measure, rebooted and it worked.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.