Fedora 10 CANNIBALIZES GRUB.

bendib · #1 16th January 2010, 01:55 AM

Before I start, I would like to say I already got it fixed myself, and this is more of a why the hell kind of post. I have used Linux for three years, and have had four unrelated incidents under different types of Fedora of this type, so I thought it was time to take it to the forum. I will explain what happened most recently. I had not used DD on this machine all day, and I am one of those guys who reboots all the time, so I know DD had nothing to do with it. I was compiling a new kernel, 2.6.32.3 to be exact, noticed I had a compilation error, shut down, took a nap, got back up, fired up, and was greeted with a blinking cursor. I was not very happy. I had a HDD lying around with Mint 8 on it, and since this machine's CD-ROM drive has issues now and then, it shoved it in along side my Maxtor, fired up mint, copied the fedora kernel and initrd to the /boot partition on this drive, then got to a GRUB 2 prompt and then booted fedora manually. I got Fedora to start, reinstalled GRUB, and all was well. Now, my question is what could have caused this. Thanks, Ben.

***bob*** · #2 16th January 2010, 02:15 AM

(moved to End of Life Forum)

stoat · #3 16th January 2010, 02:54 AM

Quote:

Originally Posted by bendib

Now, my question is what could have caused this.

Hello bendib,

I don't know that. Sorry. But I guess about this in my imagination all the time because it gets reported here all the time. I sort of made a hobby of this subject a while back. Searched and searched and searched. Found lots of threads and posts about various GRUB issues which I categorized into three main types based on their onscreen manifestations. Found lots of anecdotes. Lots of theories. But not very much that is authoritative (from the developers). This blinking cursor thing is a fairly recent new variation. Anyway, I have always believed GRUB is a little bit fragile by its nature. For example, stage1 is so simple and small (to be able to fit in a master boot record or a partition boot sector) that it has to have the sector address of the next stage embedded into it at the time it is created (offset 44h-47h). The drive number is embedded in the code at offset 40h. If anything is done to change the sector address of the next stage or its drive number, then GRUB gets busted. The claim to fame of the larger and more complex stage1.5 has always been its ability to find stage2 in the filesystem even if it gets moved. But stage1.5 is going away in GRUB 2 according to the GRUB documentation. So I wonder if we can expect more of this in the future. Even so, I think it's a good idea. Even necessary. Stage1.5 lives in the normally unused 62 sector region between the master boot record and the first partition of a legacy hard drive. That will go away when we're all using GPT hard drives someday.

Anyway, this hasn't happened often to me. But I have had to re-install GRUB a few times over the years. But know what? I've never had to re-install a Windows boot loader for "no apparent reason". The times that I did have to re-install a Windows boot loader, I knew exactly what happened (I did something to it). I dearly love GRUB and will never stop using it, but to me, the MS way of booting (MBR-to-active-partition-boot-sector-to-boot-files) is less prone to getting busted by seemingly nothing than are GRUB's stages.

bendib · #4 16th January 2010, 05:28 AM

Does LILO do this? Or do you know? I have never used anything but GRUB exept for yaboot on my PPC eMac. LILO is sounding pretty good right now.

stoat · #5 16th January 2010, 03:21 PM

Quote:

Originally Posted by bendib

Does LILO do this? Or do you know?

I don't know that either. I haven't used LILO since the Red Hat distro (Fedora's ancestor). But I think you may be over-reacting to this incident. Busted GRUB boot loaders may get discussed here all the time, but it will be a rare event for you and me individually. People only come here to report bad things. And not only is it rare, it takes only seconds to repair with the GRUB shell or the grub-install script and the Fedora DVD or the first CD of the CD set. The LiveCD can also be used to run the GRUB shell and grub-install commands, but with the LiveCD the partitions and/or logical volumes must be manually mounted to use grub-install (a minor complication). And then there is always the Super Grub Disk which can boot a GRUB-booted system when the only thing wrong with it is the boot loader. Once the system is booted, the boot loader can be repaired from a terminal in the running system. Or the Super Grub Disk also can do the GRUB re-install job. And it can boot Windows and repair the Windows boot loader in the MBR. I think anyone that uses GRUB should keep a Super Grub Disk handy (or at least a GRUB boot disk).

bendib · #6 17th January 2010, 08:14 PM

I know how to re-install GRUB. That's the reason this thing is running to begin with. I am just irritated that my system eats it's own bootloader. Maybe someone should port Yaboot to Intel. My eMac never has bootloader issues with it's fedora 10 install, and it's been preupgrade upgraded all the way from Fedora 8. Keep in mind if this system did not have a CD drive that was kinda funky, I would not have had to shove in another hard disk to use it's copy of GRUB to get back into Fedora, so I would not have been mad. Anywhos, it's running again.

stoat · #7 18th January 2010, 11:01 AM

Quote:

Originally Posted by bendib

I know how to re-install GRUB. That's the reason this thing is running to begin with.

Well, I certainly didn't mean to provoke you or prod you in a sensitive area. My last post was more for the record I guess. For future readers of this thread. Just to summarize and conclude my opinion that what you experienced doesn't happen often and that re-installing GRUB normally takes only seconds and doesn't involve a screwdriver.

bendib · #8 23rd March 2010, 07:39 PM

Don't you just HAE it when you come off the wrong way? I wasn't mad. Just saying I already knew of the many ways to fix GRUB. And wow this thread is getting old. Better just let it die...