Using the GParted LiveCD, I did a series of copying, resizing, and pasting in a certain order to move things around, so I could get things into a logical order, unlike how I had the partitions set up before.
Right.
grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup --stage2=/boot/grub/stage2 (hd0) (hd0,0)
setup --stage2=/boot/grub/stage2 (hd0) (hd0,0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 17 sectors are embedded.
succeeded
Running "install --force-lba --stage2=/boot/grub/stage2 /boot/grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/boot/grub/stage2 /boot/grub/menu.1st"... failed
Error 15: File not found
[Same result without --force-lba]
You left out something I asked for in post #20. So please do all of the following: Boot again into either Rescue System at the command line as root, or LiveCD from a terminal as root (which are you using, by the way?), and do:
mount -t ext3 /dev/sda1 /mnt
ls -l /mnt/etc/grub
cat /mnt/boot/grub/menu.lst
cat /mnt/grub/grub/device.map
Post back output of commands after mount.
You don’t have any boot code in the MBR. We are trying to determine why. There is another solution we have not tried yet, but first I want to see the above output.
I wasn’t emailed about posts 19 and 20, for some reason. Odd. Well, let’s try this out… I’m using the openSUSE DVD in Rescue mode, BTW.
Rescue:~ # mount -t ext3 /dev/sda1 /mnt
Rescue:~ # ls -l /mnt/etc/grub
ls: cannot access /mnt/etc/grub: No such file or directory
Since the directory isn’t found, no reason to go on to the next lines, eh?
Would you suggest I go ahead and reinstall openSUSE over sda1, or would you want to continue figuring this out? (I have my Eee, and can access my files via a Live disc.)
Re Kubuntu: You posted that initially it is on sda1. The menu.lst you just posted was generated in your openSUSE install, when you put it on sda6. So the Kubuntu stanza is pointing to where Kubuntu was when this file was created. The openSUSE Boot Loader installation will search the disk for other linux installs, and add a stanza for such when found. That is why the stanza is there - and wrong, if Kubuntu is actually now on sda2.
And the openSUSE boot stanzas in the file are all wrong, too. Because they point to openSUSE being on sda6, whereas you moved it to sda2.
Looking back more closely at the MBR, there is actually boot code there - “generic” code; the question is whether it is executable. Please do this: Boot the DVD into Rescue System, login as root. Now do:
The machine reboots. Do you get the openSUSE grub menu? Note that you will see a quick error for failing to get the graphical screen and if you attempt to boot if will fail - all that will be easily fixed. For now, we just want to see if grub gets this far.
By the way, you do have only one disk on this machine, a Seagate, correct?
That is “A” as in “Alpha” and the numeral 1 (one). It tells sfdisk to set the boot flag (in Windows, make “active”) for the first partition and turn off any others. It looks like your MBR has “generic” boot code in it; if so, it’s looking for the active partition in the table to chain to. If there is no partition marked active, the code will fail with the error message IIRC you received previously.
The second set of grub commands puts grub’s stage1 in the first partition boot sector. Previously, grub choked when embedding the stage2 pointer into a stage1 going into the MBR. So we try putting stage1 in the PBR instead. Per the above, if the code in the MBR is good and sda1 is marked boot, the MBR code will call the PBR jump instruction and execute the stage1 there.
As a side note: Earlier you were moving around contents of partitions. When doing so, always remember that the file system inode table (or the MFT in Windows) is built according to the size of the partition on which it was formatted, and that PBR’s contain data blocks which tell the OS where to find some things - this varies by file system and OS. In other words, data in the file system is portable but not necessarily the sectors which control what the partition is being used for. That’s why moving partitions is usually done via store/restore and the PBR re-created.
(The letter l comes first, the numeral 1 comes second, and then they alternate.)
1l1l1l1l1l1l1l1l1l1l1l1l1l1l1l1l1l1
Huh, I can’t really tell them apart… That’s a problem.
grub> root (hd0,0)
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0,0) (hd0,0)
setup (hd0,0) (hd0,0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0,0)"... failed (this is not fatal)
Running "embed /boot/grub/e2fs_stage1_5 (hd0,0)"... failed (this is not fatal)
Running "install /boot/grub/stage1 (hd0,0) /boot/grub/stage2 p /boot/grub/menu.lst "... succeeded
Done.
----------
(restart and removal of DVD here)
----------
GRUB Loading stage2...
(hd0,5)/boot/message: file not found
----------
GNU GRUB version 0.97 (693K lower / 2087552K upper memory)
Xen -- openSUSE 11.1 - 2.6.27.7-9
openSUSE 11.1
Ubuntu 8.04.1, kernel 2.6.24-22-generic (/dev/sda1)
Failsafe -- openSUSE 11.1
----------
Booting 'Ubuntu 8.04.1, kernel 2.6.24-22-generic (/dev/sda1)'
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
configfile /boot/grub/menu.lst
(hd0,5)/boot/message: file not found
----------
Booting 'openSUSE 11.1'
root (hd0,5)
Error 22: No such partition
Press any key to continue...
----------
(Xen and Failsafe had the same result as above, with only the name changing.)
In my post where I gave you these instructions (before our “l” and “1” mistakes), I wrote:
The machine reboots. Do you get the openSUSE grub menu? Note that you will see a quick error for failing to get the graphical screen and if you attempt to boot if will fail - all that will be easily fixed. For now, we just want to see if grub gets this far.
Grub installed stage1 in the sda1 boot sector! At reboot the bios executed the MBR code! That code found the active partition! The boot sector jump instruction found grub stage2! It only then failed because menu.lst has not been changed to accommodate your moving the partitions around, that’s all.
Here is all you have left to do: I don’t know exactly what tools you have (LiveCD?), but you need to open /boot/grub/menu.lst as root in a text editor. Then find all the occurrences of (hd0,5) and change those to (hd0,0) - don’t forget the boot message line near the top. That Ubuntu stanza, change its (hd0,0) to (hd0,1). Save the file and reboot.
Heh, what I meant was that I really screwed things up when I did all the partition editing. It’s cool though, I was just making fun. Of myself.
Well, it seems there’s only one thing left to do now. Notice the 'part5’s and 'part6’s in the root= parts? I should change those, right? 'Cause that causes a problem with openSUSE starting up, and not Kubuntu (as its stanza doesn’t use that).
Here is all you have left to do: I don’t know exactly what tools you have (LiveCD?), but you need to open /boot/grub/menu.lst as root in a text editor. Then find all the occurrences of (hd0,5) and change those to (hd0,0) - don’t forget the boot message line near the top. That Ubuntu stanza, change its (hd0,0) to (hd0,1). Save the file and reboot.
So, yes, changing those incorrect partition numbers is exactly what I suggested. It appears you have the grub code set up now as needed, it’s only menu.lst that needs to be fixed.
- but I made a typo mistake. That should have been:
