11.04 fresh install: boots into grub CLI and just sits there

[Martinus2u]

Hi,

first off I'd like to say I am quite familiar with linux and some distributions. However, in the land of Ubuntu and Grub I am to be considered a total noob.

My setup: a work laptop that has a corporate Win7 image, and to which I have added a few partitions to try various linux distributions. The MBR is governed by Lilo from the Slackware 13.37 installation in /dev/sda5. The MBR boots no kernel image directly, it only chainloads the boot sectors of partitions /dev/sda1, /dev/sda5, /dev/sda6 and /dev/sda7. The latter three are formatted ext4.

The Win7 boot mechanism traditionally resides in /dev/sda1, and the linux distros are required to install their boot machines into their respective partitions.

What I am trying to say is, I installed Ubuntu 11.04 into /dev/sda7, and told the grub installer the same thing: install yourself into the boot sector of /dev/sda7. Kudos btw for the Ubuntu installer, it comes across as a very professional piece of software.

Installation went without a problem. However, whenever I boot the /dev/sda7 installation I get stuck in a sort of grub terminal:




GNU GRUB version 1.99~rc1-13ubuntu3

Minimal BASH-like line editing is supported. For the first word, TAB
lists possible commend completions. Anywhere else TAB lists possible
device or file completions.

grub> _
After the "exit" command it tries a PXE boot until it times out, and then says it could not find an OS on any partition. Yeah, right.

In this forum I found a recipe: boot into live DVD and issue



sudo mount /dev/sda7 /mnt
sudo grub-install --root-directory=/mnt /dev/sda7
However, that results in the following message:



ubuntu@ubuntu:~$ sudo grub-install --root-directory=/mnt /dev/sda7
/usr/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea..
/usr/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
/usr/sbin/grub-setup: error: will not proceed with blocklists.
Any pointers?

Thanks.

Martin

[Hedgehog1]

- EDIT: - deleted - OP already knows all the stuff I just typed -

The Hedge

:KS

[Martinus2u]

- EDIT: - deleted - OP already knows all the stuff I just typed -

The Hedge

:KS

Thanks anyway. ;) Btw, I discovered the forum software generates <br />
tags in your quotes but not in mine. Fore some reason my line-feeds are ignored.

Heureka, I found the likely cause for the line-feed issue: This forum needs Javascript. With Javascript it works. I may try and fix the original post for readability.

I have found most people in this forum report their setup using a script called boot_info_script.sh. I have run the same and attached the result.

[MAFoElffen]

sudo mount /dev/sda1 /mnt
sudo grub-install --root-directory=/mnt /dev/sda7
However, that results in the following message:


ubuntu@ubuntu:~$ sudo grub-install --root-directory=/mnt /dev/sda7
/usr/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea..
/usr/sbin/grub-setup: warn: Embedding is not possible.
GRUB can only be installed in this setup by using blocklists.
However, blocklists are UNRELIABLE and their use is discouraged..
/usr/sbin/grub-setup: error: will not proceed with blocklists.

Yes... There is a sysntax change in 1.99 which is between --boot and --root and another thing I see... First, Is Ubuntu in sda1 which it's boot directory is the default /boot directory in that partition? (I am confused by your sda7 refrence) If so, then:


sudo mount /dev/sda1 /mnt
sudo grub-install --boot-directory=/mnt /dev/sda
And when you do get it working > Check and run updates... as Grub has updated from 1.99~rc1 to 1.99. since then

[Martinus2u]

Yes... There is a sysntax change in 1.99 which is between --boot and --root and another thing I see... First, Is Ubuntu in sda1 which it's boot directory is the default /boot directory in that partition? (I am confused by your sda7 refrence)


No, the Ubuntu installation is in /dev/sda7 including the /boot directory, and the boot loader should go into the boot sector of /dev/sda7 as well. It should not touch the MBR.

In the meantime I got grub-install working by adding the option --force. However, the result when booting is the same as before:




GNU GRUB version 1.99~rc1-13ubuntu3

Minimal BASH-like line editing is supported. For the first word, TAB
lists possible commend completions. Anywhere else TAB lists possible
device or file completions.

grub> _

[MAFoElffen]

No, the Ubuntu installation is in /dev/sda7 including the /boot directory, and the boot loader should go into the boot sector of /dev/sda7 as well. It should not touch the MBR.

In the meantime I got grub-install working by adding the option --force. However, the result when booting is the same as before:


GNU GRUB version 1.99~rc1-13ubuntu3

Minimal BASH-like line editing is supported. For the first word, TAB
lists possible commend completions. Anywhere else TAB lists possible
device or file completions.

grub> _

Oh- Then do you think that that is your problem? Because here is what you said you were doing...



sudo mount /dev/sda1 /mnt

Here you are mounting the first directory of your first hard drive and assigning it a name as /mnt... Then




sudo grub-install --root-directory=/mnt /dev/sda7

You are installing the grub files to the first directory of the fiirst drive but installing the MBR to the directory SDA7 instead of the base of the drive. This is what you said you are doing.

Where it should have been more like this:

sudo mount /dev/sda7 /mnt
sudo grub-install --root-directory=/mnt /dev/sda
Which will have you mounting your sda7 directory, where Ubuntu is installed, installing the grub files to the default /boot/grub directory of that partition and installing the MBR to the base of the sda drive... That's what you want to do right?

Did that make sense now? Are we following the same now or am I not understanding something else in your install? (That could always be so also...)

What you might want to do is remove purge the grub-install before you install it again... as I think you'll currently find a /boot/grub directory in your sda1 and an MBR in your sda7.

EDIT-- I noticed your "should not toouch the MBR" comment... Are you calling Grub2 from another boot loader? Or using encrypted volumes? (2 instances where you would do that)

[Martinus2u]

Oh- Then do you think that that is your problem? Because here is what you said you were doing...


Sorry, that was a typo when creating the post. In the terminal window I correctly typed sda7. I verified the contents of /mnt after the mount command.



Did that make sense now? Are we following the same now or am I not understanding something else in your install? (That could always be so also...)


Yes, we're on the same page now. It's sda7 only. I'm even slowly getting to grips with grub and can confirm the location of the boot directory as (hd0,msdos7)/boot.



EDIT-- I noticed your "should not toouch the MBR" comment... Are you calling Grub2 from another boot loader?

Yes I do. The MBR chainloads the boot sectors of the installed operating systems, of which Ubuntu is one.

Right this minute I am repeating the installation procedure. Because when I got the hang of the grub command line I noticed I had installed the 32 bit version (don't ask, it was a double-sided DVD).

We'll see if the re-install solves the problem. ;)

[Martinus2u]

We'll see if the re-install solves the problem. ;)

Unfortunately not. Same issue after 64 bit install.

[MAFoElffen]

Sorry, that was a typo when creating the post. In the terminal window I correctly typed sda7. I verified the contents of /mnt after the mount command.

Right this minute I am repeating the installation procedure. Because when I got the hang of the grub command line I noticed I had installed the 32 bit version (don't ask, it was a double-sided DVD).

We'll see if the re-install solves the problem. ;)
LOL- Okay...



Unfortunately not. Same issue after 64 bit install.
(EDITED)
Yes I do. The MBR chainloads the boot sectors of the installed operating systems, of which Ubuntu is one.
So what "bootloader" are you trying to call it from?

[MAFoElffen]

I looked at your bootinfo script... LILO to Grub2.

Is your version of BIOS recent enough to see your sda7? Older BIOS'es have an 8GB limit on that...

Can your version of LILO "read" an ext4 filesystem? Not sure where they are with that. If there is a problem there, that might change your mind what you use as your bootlaoder and what to chainload to.

Problems with either of those and LILO would return an 0x04 sector not found error... But if you "are" getting to a CLI... That may not be those problems.

At the CLI- You could try to boot manually to confirm what's there:


set root(hd0,6)
linux /vmlinuz root=/dev/sda7 ro nospalsh nomodeset text
initrd /initrd.img
boot
If that works, then it's LILO and how you are trying to call your Ubuntu sys.

[Martinus2u]

I looked at your bootinfo script... LILO to Grub2.

Is your version of BIOS recent enough to see your sda7? Older BIOS'es have an 8GB limit on that...

Can your version of LILO "read" an ext4 filesystem? Not sure where they are with that. If there is a problem there, that might change your mind what you use as your bootlaoder and what to chainload to.

Problems with either of those and LILO would return an 0x04 sector not found error... But if you "are" getting to a CLI... That may not be those problems.


The lilo boot loader does not know any file system. In fact, that is the key difference between lilo and grub. The lilo installer does know ext4 for sure. Anyway, the MBR is only used as a chainloader. It loads the boot sector of /dev/sda7 and transfers control to it. From this point onwards grub is in charge. This step is successful as we can tell from the grub cli I'm getting.

When using a modified version of your commands:



set root=(hd0,7)
linux /vmlinuz root=/dev/sda7 ro
initrd /initrd.img
boot
this will indeed boot me into the Ubuntu installation. Success! ;)

Thanks for your help with that one.

Now all I need to do is to get grub to do this automatically every time I boot through /dev/sda7.

I noticed there is a file /boot/grub/grub.cfg.new in /dev/sda7. However, there is no /boot/grub/grub.cfg. Could that be part of the problem?

[oldfred]

One of the main causes of grub> not going further is not reading grub.cfg for what ever reason. If no file that may be a good reason.

Try this:


sudo update-grub

The boot script you posted also did not have a grub.cfg. Is this because you installed to a partition rather than MBR? It should have created grub.cfg as part of the install. You should have seen during the install the same text the above command should show you.

[Martinus2u]

One of the main causes of grub> not going further is not reading grub.cfg for what ever reason. If no file that may be a good reason.

Try this:


sudo update-grubThe boot script you posted also did not have a grub.cfg. Is this because you installed to a partition rather than MBR? It should have created grub.cfg as part of the install. You should have seen during the install the same text the above command should show you.

Thanks mate, you solved it! Maybe I can now shed more light on what might have gone wrong.

The update-grub command did start to create a grub.cfg file. However, it reported syntax errors. Upon checking I found a file grub.cfg.new, but no grub.cfg, just as before. When looking at the contents it transpired that some agent (most likely a so called "os-prober" or "os-checker") had parsed all my other partitions and created boot menu entries for them. It had obviously misinterpreted some items in one of the lilo.conf and produced those syntax errors. I removed those garbled entries from grub.cfg.new and saved the file as grub.cfg.

Next I called grub-install, and lo and behold, the next reboot presented me with a fully functional grub boot menu. 8)

Just in case someone upstream wants to investigate the issue further I shall attach the offending lilo.conf file (which is a perfectly valid lilo configuration file) and the grub.cfg.new file with syntax errors. It appears the quotation marks were causing problems...

I'm wondering now if I should set this post to "solved"...

[oldfred]

You probably should submit a bug on grub2's os-prober with the files you attached. I am surprised prober created an invalid entry.

bug reports info on how to do:
http://ubuntuforums.org/showthread.php?t=1011078
Check bugs
https://bugs.launchpad.net/ubuntu/+source/grub2


I do not know lilo enough to tell but yes it looks like " and or ^ are part of the problem.

The new os-prober is a lot more particular. One user has the .new grub file but also a working one and his problem was with 40_custom I tried testing with my 40_custom and got the same error with grub 1.99 where I never had an error before. It turned out I had a typo in my 40_custom also and was missing a }. But I never noticed it as the old versions just skipped that entry and I had not used it or ages and did not notice it was missing.