PDA

View Full Version : GRUB got problem in Fedora 7.0



Cyberman
3rd May 2008, 03:40 PM
This is not the first time. But before that I just notice that some bytes changed, this time I made a step by step record.

My disk:
First master partition is Windows XP boot partition.
Second master parition is Linux mount at /.
Third master partition is Linux Swap.
Then the extended partition has two logical partition for WinXP.

Boot:
I installed GRUB in /dev/sda2, and boot it with OS loader in XP.

Problem:
It just print out 'GRUB', then stopped.

Fix:
Use disc to boot in rescue mode, and reinstall GRUB, re-generate the file OS loader use.

I've do the following steps:
1. After boot in rescue mode, I just use dd to read the data, and compared with the original one, and three bytes changed, see the attached file 'cmp_1.GIF'. But this one couldn't make the system boot, GRUB did go one, but the rebooted the system.
2. I ust 'grub-install /dev/sda2', then re-generate the file. This file works fine, but comapred to the original file, that three bytes still changed to other values. See the attached file 'cmp_2.GIF' for details.

stoat
3rd May 2008, 04:44 PM
Hello Cyberman,

Those bytes are the block location of the next stage (stage2 in your case). They are embedded into stage1 at the time GRUB is installed (or re-installed). As you know, stage1 is a tiny, simple program that must have the block location of the next stage embedded into it in order to find it on the disk. When GRUB is installed in the master boot record, it usually also installs stage1.5 in the DOS Compatibility Area immediately following the master boot record. In that situation, stage1 has the block location of stage1.5 embedded into it. Stage1.5 is larger, more complex, and capable of finding stage2 in the filesystem even if its block location changes. However, when GRUB is installed in a boot sector such as when another boot loader is used to launch it, stage1.5 is not installed. In that case, stage1 has the block location of stage2 embedded into it. Stage1 then directly launches stage2 by knowing its block location. So now if the block location of stage2 changes on the disk for any reason, then stage1 can no longer launch stage2. GRUB must then be re-installed to recreate all of the stage files.

You can read more about this interesting subject at The Starman's page on the GRUB Boot Loader (http://www.geocities.com/thestarman3/asm/mbr/GRUB.htm). There you can examine the stage1 code and study what each section does. That very section that changed in your stage1 is discussed in detail.

Cyberman
4th May 2008, 05:08 AM
Thanks. But why the location of stage2 changed? I do nothing about it.

I didn't install GRUB into MBR because these computers are using XP the most time, but that's OK. The real reason is because the tragedy I experienced after I'd installed LILO of Reahat 5.1 into MBR. Its about 1999, Linux share a hard disk with NT4.0. It always going fine, but some day the NT system crashed and when I tried to install it again, it can't read the partition correctly and made me had to use debug clear the MBR. Then I lost every thing about my work in NT. After then when I install Linux share a disk with windows I never install its boot loader into the MBR.

stoat
4th May 2008, 04:52 PM
But why the location of stage2 changed? I do nothing about it.Hello again Cyberman,

I have no way to know that. In fact, maybe it didn't happen that way. Here is another plausible explanation in my imagination for what you observed. Maybe "something" occurred that corrupted stage2 producing the infamous GRUB _ hang when you next attempted to boot Fedora...
boot.ini /--> kernel
| /
BIOS --> Partition Loader --> Boot Sector Code --> ntldr --> XP Menu -----> kernel grub.conf /--> kernel
(Master Boot (Volume Boot | \ | /
Record) Record) ntdetect.com \--> fedora.lnx --> GRUB stage2 --> GRUB Menu -----> kernel
(stage1) (/boot/grub) \
\--> kernel...And maybe when you re-installed GRUB to repair that situation, the new stage2 was written to a different block location on the disk which would then be reflected in the new fedora.lnx that you created. See what I mean? The grub-install command will not only install a new stage1 where your command indicates, it will also rewrite all of the stage files in /boot/grub (including stage2). In other words, maybe what you observed in the two versions of fedora.lnx is not the cause of the GRUB _ hang, but is instead only an effect of the repair.

Cyberman
5th May 2008, 01:14 AM
Thanks again. Reinstall stage1 one makes stage2 changed I can understand. The problem, however, is that I didn't change anything about GRUB, but state1 actually changed, this is what the second picture shows. It after I got the problem I just dump the stage1 out, no modify of it.

stoat
5th May 2008, 01:30 AM
Thanks again. Reinstall stage1 one makes stage2 changed I can understand. The problem, however, is that I didn't change anything about GRUB, but state1 actually changed, this is what the second picture shows. It after I got the problem I just dump the stage1 out, no modify of it.Hello Cyberman,

Well as I said before, there is no way that I can possibly know what happened there. I can only think about it and propose theories. I have always booted Fedora the same way that you do using NTLoader to launch a binary file containing GRUB stage1 that was copied from the Fedora boot sector. There is no stage1.5 which can find stage2 in the file system, so stage1 directly launches stage2 only by having its block location. And like you, I occasionally have to re-install GRUB for no apparent reason. It has never really bothered me because it happens so rarely and can be fixed in 90 seconds. You seem to be more irritated by this occurrence. Here is my proposal for you to consider: GRUB for DOS (aka GRUB4DOS).

Now before you discard the idea, please hear me out. I have known about GRUB for DOS for a long time and experimented with it before. But I never used it because I did not see an advantage. Today, for the first time, I see the advantage: NTLoader can use it to boot Linux without using any of those GNU GRUB stages. By getting stage1 out of the chain of events, that GRUB _ hang should no longer occur by stage1 losing the location of stage2.

In GRUB for DOS, the main functions of GRUB reside in a single file named grldr. NTLoader can launch grldr which then can launch Fedora. An additional refinement is to use the configfile menu command in the GRUB for DOS menu.lst file which makes the setup "immune" to kernel updates (no editing of the menu.lst after a new Fedora kernel). The only disadvantages that I noticed are an extra menu at boot time and the Fedora splash screen displays only behind the countdown text if the menu is hidden (so I commented out hiddenmenu in grub.conf). Those could be considered acceptable nuisances if the overall result is to get rid of the GNU GRUB stage files while booting Fedora with NTLoader.




HOWTO Launch Fedora with NTLoader and GRUB for DOS

Prerequisites for this to work...
Fedora was successfully installed.
GRUB was installed in the first sector of the Fedora boot partition.

NOTE: This step is included only because it causes anaconda to create a grub.conf file which is important for using the configfile method of booting the system. The stage1 code installed in the boot sector does no harm just sitting there unused.


The computer boots directly into Windows from BIOS as normal.

What GRUB for DOS is...
GRUB for DOS is a universal boot loader that is based on GNU GRUB.
GRUB for DOS can be started from DOS, Windows, Linux, a master boot record, a partition boot sector, or a CD.
GRUB for DOS can be started by other boot loaders such as GNU GRUB, NTLoader (NT/W2K/XP/Server 2003), and the Vista Boot Manager.
GRUB for DOS does not boot in stages like GNU GRUB (the reason I am doing this).

Use GRUB for DOS to boot Fedora with NTLoader...
Download the GRUB4DOS zip file (easy to find on the Internet)
Unzip it and copy these two files to C:\ (or your particular Windows root directory)

grldr
menu.lst

Edit boot.ini to add C:\grldr="Start GRUB"
Edit menu.lst to add entries for booting Fedora (and clean it up a little for those many examples)

NOTE: The usual menu commands all work in the menu.lst file. The title, root, kernel, and initrd lines can be copied from another configuration file to directly boot a kernel. Or, the chainloader command can be used to launch boot sector code such as is commonly done for Windows systems. And the configfile command works to reload the menu with the information from another configuration file.
Example of how I used the configfile menu command in the GRUB for DOS menu.lst to launch Fedora...
title Fedora
configfile (hd0,2)/boot/grub/grub.confNote: If I had a separate boot partition (but I don't), then I would do the command like this...
title Fedora
configfile (hd0,2)/grub/grub.confHow it looks on "paper"...
boot.ini /--> kernel
| /
BIOS --> Partition Loader --> Boot Sector Code --> ntldr --> XP Menu -----> kernel /--> kernel
(Master Boot (Volume Boot | \ /
Record) Record) ntdetect.com \--> grldr --> GRUB Menu -----> kernel
| \
menu.lst \--> kernelAnyway, there it is. You should at the very least give this idea some consideration for your situation there. Good luck and goodbye.

Cyberman
5th May 2008, 02:13 AM
Thanks stoat, maybe some days later I'll try it. I post here just to want the reason, I'm confused about the result. The fix is not that easy since our computers have noe CDROM, I have to use the USB-external CD-ROM, and these computers' USB ports are disabled in the usually time, and the Windows system has a protection card, I have to boot the system to disable it.

It's not two much, we have 30 computers installed WinXP+Fedora7.0 for about half a year, only two computer got that problem. We don't use Fedora too much, most time these computers are running XP.