Changing the line worked, as the UUID is no longer present in the "linux" line.
The next thing to try is to remove the search line. While we can change the scripts to omit the "search" line, it would probably be easier for testing purposes to just edit grub.cfg once to see if removing the "search" line is the cause of your troubles.
Open /boot/grub/grub.cfg for editing (yes, I know it is not normally edited).
This should open grub.cfg to the "search" line of your first menu entry (Ubuntu, with Linux 2.6.32-25-generic). Remove the search line, save the file, do not update grub, reboot and select the first menu entry and see if it boots normally. If it boots normally, we will alter your scripts to eliminate the search line.Code:gksu gedit +154 /boot/grub/grub.cfg
Added:
I also noted in your RESULTS.txt that you have a /grub/core.img file. I don't know how that folder/file ended up there, but it's not part of the grub file structure. The core.img file should be in /boot/grub and there is no /grub folder. You have copies of the correct folders/files, so you shouldn't move /grub/core.img to /boot/grub. I would either rename it or move it out of your system partition to prevent any confusion.
Last edited by drs305; November 3rd, 2010 at 07:24 PM.
I see what you mean and I renamed the extra /grub directory to /bgrub. I have no clue how it got there. I edited /boot/grub/grub.cdg as you asked and then rebooted my computer. I am still not getting the boot menu. It still goes immediately to the grub> prompt.
I noticed that there is another search command at line 119.
Attached is my results2.txt file.
I am still assuming you can boot normally if you go to the grub prompt and type:
There are two search lines still existing in your grub.cfg file, so we will get rid of them plus some additional lines which are normally not used.linux /boot/vmlinuz-2.6.32-25-generic root=/dev/sda1 ro
initrd /boot/initrd.img-2.6.32-25-generic
boot
Try editing grub.cfg again, make a backup, then remove the following section.
Save the file, do NOT update grub, and see if it will boot from the first menu entry.
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set 996f5576-b087-45d0-87ab-72b53b33dd06
if loadfont /usr/share/grub/unicode.pf2 ; then
set gfxmode=640x480
insmod gfxterm
insmod vbe
if terminal_output gfxterm ; then true ; else
# For backward compatibility with versions of terminal.mod that don't
# understand terminal_output
terminal gfxterm
fi
fi
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set 996f5576-b087-45d0-87ab-72b53b33dd06
set locale_dir=($root)/boot/grub/locale
set lang=en
insmod gettext
This is so weird. I renamed grub.cfg to grub.cfg.bak. I edited the file and removed the lines specified and saved the file as grub.cfg. I did not update-grub.
The first time I rebooted, the grub menu appeared and booted into linux 2.6.32-25-generic, as it should have done.
Just in case it might have been a fluke, I rebooted again. I got the grub> prompt and had to boot manually.
Well, I can say that I am losing my fear of terminal. It's starting to become my best friend. Please take a look at my latest results.txt file. Oh by the way, I removed all of the search lines from grub.cfg without any luck.
What result do you get when you run:
The /boot/grub/grubenv file contains instructions to boot a preset menuentry.Code:grub-editenv list
At this point, once you boot to your normal installation (even if you have to type it) it might be time to just run "sudo grub-install /dev/sda" to rebuild the core.img (Note you do not use sda1)
Reboot and see what happens.
If you still have no success, (and you still have your backup of grub.cfg), edit your current shortened grub.cfg and remove everything above the line:
Save the file and reboot. Press ENTER on the first entry. You will probably see a message about executing a command list, but it should boot.### BEGIN /etc/grub.d/10_linux ###
If things still aren't working, I'd remake your grub.cfg file with:
Code:sudo update-grub
First of all, Thanks for all your patience with this newbie.
I tried everything on the list today. Ugh! I'm open to any other suggestions. I finally ran "update-grub" and everything seems to match up with my backup file. I am still able to boot manually from the "grub>" prompt.
James
@ jamesamccarty,
I think I know what is happening. Based on our discussions and trials, I went back and reviewed all the old posts.
Since you system boots with only a minimal input into the terminal, the modules are being loaded and the paths are correct, I am pretty certain the missing link is grub.cfg. I don't believe G2 is seeing it.
The most logical reason for this is that your BIOS isn't looking beyond the 137GB limit. This was the case for older BIOS's, or perhaps a newer BIOS that doesn't have the disk options correctly set.
Enter BIOS during boot and see what size it reports for your Ubuntu drive. If it doesn't list it as at least 200GB, see if there is a setting you can change. The reason for my suspicion is in the RESULTS.txt. Notice they are all below the 137GB limit except grub.cfg.
The behavior you are getting is exactly the behavior G2 will exhibit if it can't find a valid grub.cfg file.98.9GB: boot/grub/core.img
193.8GB: boot/grub/grub.cfg
99.0GB: boot/initrd.img-2.6.32-25-generic
98.9GB: boot/vmlinuz-2.6.32-25-generic
99.0GB: initrd.img
98.9GB: vmlinuz
If you can't change the BIOS, try reinstalling grub and run the boot info script to see if G2 has now placed the grub.cfg file below the 137GB limit.
From your normal Ubuntu installation:
If it still doesn't find grub.cfg, the next time you get to the grub prompt, type:Code:sudo grub-install --recheck /dev/sda sudo update-grub
and see if it lists grub.cfg among the files.Code:ls (hd0,1)/boot/grub/grub.cfg
You are correct. In the BIOS, it shows only a 137GB Drive. There is no way to change it.
I installed grub again and ran update-grub. I then ran boot_info_script to check where it installed grub.cfg. Same location as before. I rebooted to the grub> prompt and typed "ls (hd0,1)/boot/grub/grub.cfg" It listed. Just for fun, I typed "ls (hd0,1)/boot/grub" and got the list of everything in the directory. grub.cfg was there, as expected.
I don't wish to have to back up everything and start over. Is there any way to specify where on the hard drive to install a file?
I was hoping I wouldn't have to address this because I'll have to show my ignorance on the manner. I don't know precisely how disk operations work. I spent some time this weekend playing with a system to find a solution, as I figured someone eventually would ask what you just did.
What I tried was to delete non-essential files on / . I deleted a lot of the /var/log backup files, ran "sudo apt-get clean", emptied root's trash, and then renamed the Grub2 file(s) outside the 137GB limit. I renamed the file(s) so the space they currently occupied couldn't be reused and the system would have to put the file(s) elsewhere. Then I ran the commands necessary to regenerate the files I'd renamed. In my case it was successful. So give these things a try, and then run "sudo update-grub" to generate a new grub.cfg and see where it is placed.
Even if successful, there may be a time when files are once again put outside the limit. The long-term solution is to get a BIOS update or create a separate /boot partition. Hopefully someone can provide a better way around this issue.
Last edited by drs305; November 8th, 2010 at 06:31 PM. Reason: "emptied root's trash"
Bookmarks