I have a dual-boot system with XP and Fedora, and recently applied updates to WinXP, which caused XP to give the BSOD on startup. I would like to wipe XP and reload from scratch, but the reload image is on a separate partition that I cannot access with GRUB installed. I don't have a DOS startup disk, and cannot get far enough into windows to use the fdisk /mbr option. I found a suggestion to use:

$ dd if=/dev/null of=/dev/hda bs=446 count=1

but when I use it, I get 0 Bytes copied, and no joy on reboot. I just need to disable GRUB long enough to get access to my restore partition and re-install windows. I'm a rank newbie with linux (and just switched over to Fedora from Mandriva), and would really appreciate as much detail as possible.

Thank You

Mike

I'm not sure removing/disabling grub will help you at all, if you don't replace it with something else.

What is it that you want to do? Do you want to boot into xp? Or do you want to access a partition different from your linux one where your restore image file is?

Several points:

1. If there is no boot code in the MBR, you cannot get into any other partition---only to a different physical drive (by changing BIOS settings)
   
2. fixmbr should be accessible by simply booting from the Windows CD--rescue mode.
   
3. Perhaps you need sda instead of hda in the dd command----run "fdisk -l" (as root) to see how your drives are seen by the system

I'm trying to get access to the partition where my restore image is located (it's bootable), but GRUB doesn't seem to recognize it as a partition, and the utility I have to set it as the primary boot partition gets bypassed when GRUB loads. What I'd like to do is set my mbr the way it was before GRUB was installed so that partition will boot

fixmbr from the Windows CD

Unfortunately, I don't have a Windows CD. This system came with a ghost image stored on a hidden partition for restoring it (it's a Dell Inspiron).

I tried using the fdisk command as root, but got back that it's an unrecognized command. I tried the sda instead of hda, and the system created a backup file, but would not reset the mbr.

Assuming you still have a valid reload image, it is pretty easy to chainload to it from grub.

You just need to edit the correct entry into the /boot/grub/menu.lst file to offer that choice during boot.

If you post the output from fdisk -l as root, I think someone will be able to tell you what to put into menu.lst

It also might help to post your current menu.lst

Where did you get an insane idea like that?
I don't recall dd syntax well enough to understand why trying that didn't destroy the portion of grub in the MBR. You're lucky it didn't. That would have made your task significantly harder.

Disabling GRUB would do you no good and significant harm.

The Microsoft MBR code was overwritten by installing GRUB, but breaking GRUB won't bring back the Microsoft MBR code.

If you could easily bring back the Microsoft MBR code, that would be an alternate path to booting your recovery partition, but not necessarily the easiest path and certainly not the only path.

Do you really want to help someone fix whatever lucky incorrect detail stopped a really wrong and destructive plan from doing any harm?

I hope that just means /sbin wasn't in your path. In that case you can use
Otherwise it means fdisk isn't installed. I don't know Fedora well enough to know whether fdisk is optional. In Centos, fdisk is part of a package named util-linux that appears to be installed by default.

If someone wants to install Windows, this is a very common way to clear the MBR so the Windows installer will work.

My first point was that removing the code in the MBR would not allow getting into ANY partitions.

GRUB can be re-installed from any Linux LiveCD
Would you believe right here at LQ? As I said, a very common fix.

On some systems (eg Fedora) root has a different PATH. Use "su -" to switch to root---then things like fdisk will be in the PATH.

What Windows installer needs you to remove GRUB first? None I've ever tried.
It is common when something unrelated goes wrong with a Windows installer after Linux was present, the confused user asks for help getting rid of GRUB or Linux or whatever. After they get rid of GRUB, whatever was originally wrong with the Windows installer is still wrong. Using dd might well be a common correct way to clear the MBR, and thinking you need to clear the MBR might also be correct. By actually needing to clear the MBR is certainly not common.

I saw. I just didn't think it was enough of a warning under these conditions.

I know it can and next time I need to do that, I hope I can quickly find out how. But most of the time I prefer to not break grub in the first place. My guess was the OP would have a slightly harder time figuring out how to fix GRUB than I would and thus a better reason to not break it.

After this long side track, I think I need to repeat: The OP should post the current contents of /boot/grub/menu.lst as well as the ouput of fdisk -l (gotten using either Pixellany's suggestion for using root with the right path or my suggestion of directly specifying /sbin or whatever works).

@johnsfine;
I'm going to avoid a lengthy debate--mostly because we're already at the limits of my competence......

For Windows to refuse to install when it sees something "alien" on the disk is (or was) quite common. My last experience was with Windows 2K. I don't remember all the tricks I used, but clearing the MBR was certainly one of them. I seem to recall reading all manner of solutions, including clearing the MBR all the way to erasing the whole disk.

I just read the Microsoft article on installing Windows over Linux. They talk about deleting partitions (which will not be done by OP's command). I have always just zeroed the whole MBR using bs=512 in the dd command.

Sorry about the delay between posts. Work always seems to get in the way of the important things :-)

Anyway, thank you for clarifying what that command would have done. I was under the impression that GRUB was an add-on in the mbr, and that the command listed would just clear out GRUB and leave the rest of the MBR intact. That would have made for a few more hours of frustration.

I did find the fdisk command, although even after using su, I had to list the entire path to use it. Here is the output from it:

Disk /dev/sda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xd0f4738c

Device Boot Start End Blocks Id System
/dev/sda1 1 6 48163+ de Dell Utility
/dev/sda2 * 7 6888 55279665 7 HPFS/NTFS
/dev/sda3 6889 9270 19133415 5 Extended
/dev/sda4 9271 9729 3686917+ db CP/M / CTOS / ...
/dev/sda5 8171 9270 8835718+ 7 HPFS/NTFS
/dev/sda6 6889 6914 208782 83 Linux
/dev/sda7 6915 8170 10088788+ 8e Linux LVM

Partition table entries are not in disk order

Disk /dev/dm-0: 8187 MB, 8187281408 bytes
255 heads, 63 sectors/track, 995 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/dm-0 doesn't contain a valid partition table

Disk /dev/dm-1: 2080 MB, 2080374784 bytes
255 heads, 63 sectors/track, 252 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x30307800

Disk /dev/dm-1 doesn't contain a valid partition table

Disk /dev/sdb: 2063 MB, 2063597056 bytes
255 heads, 63 sectors/track, 250 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x91f72d24

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 251 2015200 b W95 FAT32
Partition 1 has different physical/logical endings:
phys=(249, 254, 63) logical=(250, 225, 38)

On the hard drive, I know that there is a partition that contains Dell utilities for testing the hardware, the partition that holds the restore image, and a partition for data back up (that I created when I installed Linux), in addition to the main NTFS partition and Linux partitions.

I'm afraid I'm not familiar enough with the command line to open up menu.lst and display it (or for that matter edit it), although it does seem like it would be a lot easier route to access that partition from GRUB.

I appreciate everyone getting me on the right track!

Your menu.lst is actually just a text file (containing preferences for grub). Its path is /boot/grub/menu.lst.

You can open it just as you open any text file, simply:

If you want to be able to edit it you need to do it as root, i.e add sudo before.


You will find all your current grub entries in this file, i.e the alternatives you get when you boot. Among these you can add the following to get an option for your Dell Utility partition:

This should give you a "Dell Utility" option at startup. Although I think chances are pretty good this will work, I want to mention that there's a slight chance of booting into the restore partition will mess up your grub. If that would happen you can restore it quite easily with a live cd, so don't panic if it happens. Either get back here or read this for an excellent grub guide:

http://www.dedoimedo.com/computers/grub.html

Also, I think it should be quite clear where to add the entry I posted. If not, just post your current menu.lst and I'll tell you the exact position.

The info from everyone was a great help! Thank you. I'm starting the reload process on it now, and from everything everyone's told me, I'd suspect GRUB will be overwritten by Microsoft's MBR, but I have a live cd, so that shouldn't be a big deal, and I've learned a bit more about working with the command prompt. Thanks again!