I tried to load GRUB, and I must have done something really stupid because now my Kubuntu harddrive is dead (completely, it's not even being recognized), and my Windows XP if failing to boot, but is being recognized. I get the "BOOT DISK FAILURE " message, it instructs me to put my system disk in tray. I think the Windows CD is salvagable, I'm guessing the boot sector is fried. but i'm not sure. Any ideas anyone?

I think it is the MBR, but perhaps also the windows boot record. If you put the indows CD in, reboot and open the recovery console, you can restore the windows and the MBR, and windows will (unless something is really messed up) boot correctly.
For getting the Kubuntu back, I'd actually reccommend reinstalling. If you have important files and/or settings, copy them to windows using explore2fs and reinstall; it takes only about 20 minutes.

Key words: Linux dual boot MBR drive partition

Posted 8 August 2005 to the hardware forum at linuxquestions.org

-------------------

Here is some general information about dual-boot system problems, along with at least one apparently brand new clue about a potential fix for systems that won't boot. The latter information doesn't seem to be available anywhere else on the net and it flatly contradicts some of the established lore about MBR repairs.

1. Windows and UNIX boot sectors: a fundamental difference between the two kinds of systems is that they do not use identical approaches to the construction of the MBR, the Master Boot Record that resides at the very beginning of the first sector of your hard drive and which contains crucial information on your primary drive partitions. This is why it can be tricky to run a dual boot system. For example, installing Windows on a system that already has Linux on it is likely to wipe out the Linux loader, and the installation may also cease to be bootable at all. Other actions can also lead to these results.

For a thorough dissection of the innards of the MBR, take a look at http://www.ata-atapi.com/hiwmbr.htm. See also http://support.microsoft.com/kb/q69013/ for some information about differences between Microsoft and others in how the MBR is set up and used.

Moral #1, which applies to EVERYBODY: all Linux system owners should acquire and use one of those simple floppy-based utilities (such as the old DOS mirror.com program) that will make and restore a backup copy of the MBR. Other backup routines, even including some disk image approaches, may not be able to restore this vital information, which applies to a particular installation and a specific partitioning scheme (so if your partitions change, you may need to make a new MBR backup).

2. Many utilities and software suites are available to deal with disk partitioning problems, including repairs of an ailing MBR. Beware: most of those programs are NOT UNIX/Linux-aware and may not solve your problems (or might even make them worse, but read on). Advice on the net also reinforces my suspicion that many slightly different conventions may exist for assigning and reporting partition sizes and boundaries; I have found that some differences between the information reported by separate disk utilities, including repair tools like PC Doctor and disk imaging programs like those developed by Powerquest as well as the Linux fdisk software, will be tolerated by a system, although I assume that one should not press one's luck by running too close to the total size limits for any particular partition. Note that the partition information (for primaries, at least) is part of the stuff that's stored in the MBR. I presume that info on logical partitions is stored separately in the initial sectors of the extended primary, but this is just an assumption on my part. I am an experienced (40 years) computer user and owner with good "street smarts" but I do not have professional IT or other hardware training and don't pretend to be an expert.

Moral #2: software solutions to MBR problems may work, and in unexpected ways (see below), but don't expect miracles, and exercise reasonable caution.

3. When all else fails on a dual-boot system, meaning that you can't get any sort of hard-drive system to start up at all, then it may be time to try the recommended Windows fix that's mentioned by many people on the net: get out a DOS boot disk, fire it up, and issue the command "fdisk /mbr." This will cause Microdisk's fdisk to carry out a repair of the master boot record. For more on exactly what the command does (at least at the time that the information was was written, which was back in the DOS days), see the link to Microsoft in (1) above. Your Linux installation won't be available from a hard drive boot, but you may still be able to start it from a boot floppy, and you may be able to access it for repairs with Knoppix or a rescue system such as the one that comes with my own installation (Red Hat Enterprise Workstation 3). A new save from a Linux fdisk session may then restore your full multi-OS system (it might also be necessary to reinstall Lilo or GRUB). Alternatively, VCOM's commercial System Commander software can boot a Linux installation and installs inside a Windows system partition.

No moral here, just some possible solutions.

4. And here is the apparently new info; at least I have not seen it anywhere else, and believe me, I have looked. Last Friday, for reasons which are too embarrassingly dumb and intolerably complicated to explain here, I blew out my own MBR. I used another system to search the net for advice and picked up much of the info mentioned above. After much futile (but, in hindsight, possibly helpful) fiddling with partition and MBR repair tools, I finally concluded that I had no recourse left but to restore my installations from a four-month old full system backup (thus losing all sorts of changes during the period since the backup was made, including email messages and address books and new ongoing work -- I am a self employed consulting sociologist). Since I can't afford to lose that stuff, I used the Red Hat rescue software to get onto the supposedly blown system and spent many hours using primitive console commands to make ZIP drive backups of the most crucial files from my four-month hiatus, then I shut down Linux, made a few more apparently futile tries with the partition/MBR repair tools, and then as one final last-ditch move, I tried the "fdisk /mbr" routine, thinking that it just might let me at least get back a working Windows system. Rebooted, expecting maybe another failure or just possibly a Win splash screen. Instead, GRUB came up and my jaw about dropped off my face. The Microsoft fdisk routine had restored my Linux MBR.

If you believe what's said elsewhere on the web, this is not supposed to happen. I discussed this incident today with a pal who runs East coast IT operations for a major retail chain and so he runs into hundreds of system problems. He tells me that at least some systems store a backup copy of the MBR elsewhere on one's hard drive, maybe up near the landing zones. I presume that this might be one of those varying functions built into some ROM BIOS software, like boot block BIOS facilities. This might have been grabbed by the fdisk routines. My pal also speculated that fdisk just might be smart enough (my copy came from Win98SE) to do a partial repair on an unfamiliar version of the MBR, but that seems unlikely to me. That would be most un-Microsoft-like behavior; furthermore, it seems to me that such a move would take at least a bit of diagnostic time, and that wasn't evident in my case. The fdisk routine ran and then exited instantly. (I do have a fast system -- 3.2 GHz i-686. If it makes any difference, the other hardware in use when this incident occured included a Soyo 845PEISA motherboard with the Phoenix Award V6.00PG BIOS, and a 200 GB Seagate hard drive). According to Microsoft, "Fdisk has an undocumented parameter called /mbr that causes it to write the master boot record to the hard disk without altering the partition table information." Microsoft-style partition information, one presumes. And the article does not say where the MS fdisk program goes to get the MBR that it writes. Inside fdisk? Possibly from a backup copy of the MBR stored on the user's drive? Who knows? (<-- serious question, not just rhetoric: if anybody DOES know, I would like to hear from them. See email address below.)

Moral #3: the DOS fdisk MBR fix does NOT necessarily trash a Linux system. It might do that. But in my case, it restored everything. Go figure.

And on the usefulness of all those partition repair tools: if I didn't have partition problems to start with, I certainly did have them once I started messing with the system to find a cure to the MBR problem. During the period while I fiddled with the system, I made repeated uses of Linux fdisk, PC Doctor partition rebuilding, Partition Magic, and other software. At one point I needed to rebuild the partition tables from scratch. At another, I needed to restore the proper placement of the Linux swap partition in the extended partition tables. The support software fixed these problems, which were caused by my own errors. So I don't agree with the common advice that partition repair programs can make a situation worse. Sure, that can happen. But the same software can also cure the problems it may cause, as well as other problems that were caused by other actions. Note that repeated runs of these programs, accompanied by careful tests after each pass, may be needed.

Oh, yeah, I no longer needed those ZIP drive backups that took so many hours to make. I suppose that making them was the penance I had to pay for the dumb actions that led to the problems in the first place.

“fdisk /mbr” only works if you have a recognizable FAT16 or FAT32 partition on the disk. Otherwise, it’s time for a trip to the recovery console and a visit with fixmbr.

DOS fdisk's /mbr option won't run without a MS-style partition present? Well, okay, although that seems a bit strange. Certainly fdisk itself will run without a partition already in place; it's what you use to make the partition on a virgin drive in the first place, no? Well, I'll take yer word for it, but it don't make no difference for the fella who needed help; he's running a Windows/Linux system, just like most of the rest of us with dual (or more) operating systems.

It does make a difference if Norab tries to follow your advice and doesn't have a FAT16 or FAT32 partition on the drive.

Norab, it's hard to say what happened to your system, since there isn't much to go on. It sounds like grub stage1 is just pointing to the wrong partition, but it's hard to tell for sure. I doubt that you did any serious damage with grub.

One approach to fixing your system was pointed out by bp12345, which is to get windows running first by booting from the xp installation CD and restoring the MBR from the recovery console using FIXMBR, the 2k/xp version of “fdisk /mbr”. It's a good suggestion and worth trying.

Another approach would be to boot the system using a Live-CD linux (e.g., Knoppix) and have a look around. Running “fdisk -l” would verify that the partitions are still there. Looking in the Kubuntu /boot/grub/menu.lst would verify that nothing strange is happening there. Running “grub” would start the grub shell, which could be used to attempt a “native” grub installation (see “Installing GRUB natively” in the grub manual http://www.gnu.org/software/grub/man...l#Installation ), which would also provide some very good diagnostic information that you don't get by running grub-install.

If my system was having your problems, the first thing I would do is to boot using a Grub Boot Floppy and to try doing a native grub installation, just like is described above.

I got both drives up and running completely wiping the kubuntu disk out. I installed Suse, and am now having another complication:

at the "choose which OS" screen, when I choose Windows a black screen comes up with white letters:

root (hd1,0)
filesystem type unknown, partition type 0x7
CHAINLOADER +1

The Windows drive is physically a seperate drive from Linux. Each OS have their own entire Hardrive to play with. Any ideas?

The grub commands for selecting windows in menu.lst must be really messed up, since “root (hd1,...)” plays no role in booting windows.

Post your /boot/grub/menu.lst and the output from “fdisk -l” so that we have something to go on.

# Modified by YaST2. Last modification on Fri Aug 19 21:01:10 MDT 2005

color white/blue black/light-gray
default 0
timeout 8
gfxmenu (hd0,1)/boot/message

###Don't change this comment - YaST2 identifier: Original name: linux###
title SUSE LINUX 9.3
kernel (hd0,1)/boot/vmlinuz root=/dev/hda2 vga=0x317 selinux=0 splash=silent resume=/dev/hda1 showopts
initrd (hd0,1)/boot/initrd

###Don't change this comment - YaST2 identifier: Original name: windows###
title Windows
rootnoverify (hd1,0)
chainloader +1

###Don't change this comment - YaST2 identifier: Original name: floppy###
title Floppy
root (fd0)
chainloader +1

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- SUSE LINUX 9.3
kernel (hd0,1)/boot/vmlinuz root=/dev/hda2 showopts ide=nodma apm=off acpi=off vga=normal noresume selinux=0 barrier=off nosmp noapic maxcpus=0 3
initrd (hd0,1)/boot/initrd

Quoting from the Grub Manual ( http://www.gnu.org/software/grub/man...OS_002fWindows ):

“...If you have installed DOS (or Windows) on a non-first hard disk, you have to use the disk swapping technique, because that OS cannot boot from any disks but the first one. The workaround used in GRUB is the command map...”

Try this in menu.lst:

title Windows
map (hd0) (hd1)
map (hd1) (hd0)
rootnoverify (hd0,0)
chainloader +1
makeactive
boot

Close.
The map commands are required (make sure all the blanks are included), as these are used to setup for M$oft.
The "rootnoverify (hd0,0)" needs to be "rootnoverify (hd1,0)" as this is a directive for grub, not Windoze - by the time ntldr gets invoked, it thinks it's on hd0 (thanks to the maps).
Linux installers should do a better job of handling this correctly - all the GUI based ones I've seen can't handle Windoze being on a drive other than the first.
It ain't that hard - indicates shoddy build testing.

raellis
I find the alleged restoration of your grub boot loader code by "fdisk /mbr" wanders into the realms of the unbelievable. More likely confusion on your part after a stressful session I would think.
As to your question, fdisk contains several copies of the boot-loader code within itself. Who knows why it requires more than one.
fdisk suffers several potential shortcomings - some alleviated in later versions.
Where available, fixmbr is a better option.

worked perfectly. thanks.

Re sys00's comment in previous post:

Yer skepticism is understandable, but sorry, DOS fdisk /mbr DID restore my Linux boot sector, just like the post said. Wouldn't have gone to such wordy lengths to describe what happened if it wasn't a report on an event that runs against the common wisdom. I ain't saying the wisdom's wrong, but in this case it doesn't apply.