My ubuntu 10.4 computer stopped booting. Apparently the MBR or something nearly as bad happened (the computer beeps, but then just prints a newline and a "J" character, then stops).

When I boot and run from the installation DVD, I can browse the disk and the entire filesystem seems to be intact. I say that because I can browse through the directories and look at random text files.

I bought a new 3TB seagate drive and created a fresh ubuntu 10.4 on it. Of course, none of my applications are on the new boot drive, and even worse, nearly two years of configuration settings are not on the new boot drive. But apparently everything is fine and intact on the other drive, which I can browse.

My question is... is there some way I can avoid re-installing all my software development tools and other applications that I've installed and configured over the past two years, even though it isn't on the boot drive? I don't see how due to path differences to all the files (then vs now), but then again, I'm not a linux guru by any stretch.

Or lacking that, is there some way to make the prospect of installing all the applications and configuring them a lot easier? I thought I made a "cheat sheet" (text file) that described all the painful-to-figure-out steps required to get the whole shebang working... but apparently not. At least I can't find any.

I guess the other way to fix this problem would be for someone to tell me how to fix the MBR. Of course I'm not 100% certain the problem is the MBR, but it seems likely (or something very low level that happens right at the start of the bootup process).

are you absolutely sure there's no hardware problem? have you tried to boot the root fs with the rescue cd ? (slackware allows that by passing a parameter to the boot prompt, dunno the rest of the distros)

what loader are you using? if you can mount the partition and chroot it perhaps you can reinstall lilo if thats the loader.

edit: removed "have you connected another disk ?" because thats the case, I wonder if you have swapped disk order in the computer and the boot disk is no longer recognized as /dev/sda for example

I assume my hardware is not the issue, since I purchased a new motherboard, CPU, RAM and HDD. Now that I have a fresh ubuntu installed on the new HDD I purchased, it boots fine but the old drive doesn't. Hence, not a hardware problem. Also, even on the old motherboard I was able to boot and run ubuntu from the ubuntu DVD just fine, which implies to me the computer is fine but the HDD is not.

I don't know for 100% what loader ubuntu installs during a fresh install, but I'm about 90% sure the loader is grub. I remember seeing grub appear somewhere along the line.

I can attempt to boot of whichever HDD I want --- boot order can be selected in the BIOS.

Boot from the Live DVD, mount your old drive, chroot into your old ubuntu root partition and run `grub-install /dev/sda`, or whatever your old drive is called. That should replace grub in the MBR.

From your first post it is clear that the partition table is not the cause. Maybe, the primary boot loader ie the first 446 bytes of the boot sector are corrupted but definitely not the partition table.

Primary boot sector: 512 bytes
first 446 bytes = the primary boot loader
succeeding 64 bytes = the partition table: 16 bytes per record
final 2 bytes = signature.

Note:
The system is different for the new UEFI based computers.

From what I've read, it is absolutely crucial that only the first 446 bytes are replaced, because after the first 446 bytes is partition information. So, does that command you mention ONLY write the first 446 bytes? I have read about the "grub-install" command, but so far none answers this clearly.

I gather the other option might be to copy the first 446 bytes from my fresh install of ubuntu on another drive with the "dd" command, then write those 446 bytes over the defective drive also with the "dd" command. Of course, I'm assuming the "dd" command reads the whole sector, merges in the first 446 bytes, then writes out the whole sector, so only the first 446 bytes are changed. Unfortunately, so far, that's also only an assumption on my part.

Later Note: I think I can confirm our assumption that only the first 446 bytes of the MBR sector are trashed. What I did was this. I made sure my old busted 1TB HDD that won't boot any more was the primary hard disk drive (hooked to first SATA cable, and reported as primary drive in BIOS). Then I booted from the ubuntu installation DVD. It got me to a screen where I could continue to boot from the DVD, run memory test, or boot from the first hard disk drive. When I chose "boot from first hard disk drive", it booted successfully into the ubuntu 10.4 that I've been working with the past two years but stopped booting recently.

Therefore, it seems correct that I can fix this problem if (and only if) I can replace ONLY the first 446 bytes on the MBR sector (without changing any bytes after the first 446 bytes). My only worry about the "grub-install" and "dd" approaches is... so far none of the documentation on either of these commands explicitly states that the bytes after the first 446 will not be altered on the hard disk drive. I suspect they'll do the right thing, but how can I be certain? If anyone can answer these questions about "grub-install" and "dd" with ABSOLUTE 100% CERTAINTY... then please do, because that's my solution.

Note: My computer has a brand new motherboard, a brand new 3TB hard drive, and it has what they call "Hybrid EFI" (but I'm not sure whether it is technically 100% UEFI compatible or superset). Somewhere along the line (maybe in BIOS, not sure) I saw some indication that the sectors on the HDD are 4KB, not 512B.

My system (which I just built 2 days ago with new components):
- motherboard = gigabyte 990FXA-UD7 with AM3+ socket
- RAM = 8GB (2x4GB) 2133MHz DDR3 by mushkin
- new hard drive = 3TB seagate
- old hard drive = 1TB seagate
- CPU = AMD 8-core FX 8150
- GPU = nVidia GTX580

gigabyte calls it a "hybrid EFI", but elsewhere on their website they talk about UEFI, so I'm not 100% sure how to answer your UEFI question precisely. It DOES support 3TB disk drives (greater than 2.20 GB seems to mean something).

I'm afraid I don't know how it works on a UEFI type drive, but grub-install shouldn't have any effect on the partition table, no matter what type of drive it is.

On an old fashioned drive you could back up the MBR by:

Then if something went wrong you could put the old mbr back in. I'm not sure about the size of the MBR in UEFI, though.

Assume that it is not related to the MBR. Start the system using a stand-alone Knoppix DVD and start troubleshooting.

If Knoppix doesn't boot, assume that your hardware is in fact the culprit. (Keep your receipts and shipping boxes ...)

You can easily make a backup of the boot sector using dd in case you do soething very bad when you try to reinstall the primary boot loader.

/dev/sda must be replaced with the device node appropriate for your system.


I remember I can restore the primary boot loader by using the following command without affecting in any way the partition table.

If you use a live linux version, you have to first mount the partition containing the root file system. Suppose the directory onto which it is mounted is /mnt. The --directory part would be:
I am assuming the grub files are under /boot/grub. If in your case it is different, change the command accordingly.

P.S.
hd0 refers to the first hard disk according to the bios.

@edbarx: Thanks.

@sundialsvcs: I can't see how my hardware is the blame, since I replaced the motherboard, CPU, RAM and 3TB disk drive in the computer and the 1TB boot drive still wouldn't boot. A fresh new installation from the same ubuntu installation DVD on the new 3TB would boot just fine.

Also remember that on both motherboards I could begin the boot process off the ubuntu installation DVD, then at the very first screen that asked whether to "perform memtest, boot from DVD, or boot from primary hard disk drive", it would continue the boot from the old 1TB drive that I couldn't get to boot. Which means, booting that first step only via the ubuntu DVD was sufficient to get past whatever the boot problem was. That's why I figure it must have been the MBR or possibly the grub code.

@Stephan Morgan: Thanks for the information about grub-install. I'm glad to hear that's how it works. Thanks also for the "dd" command. That might come in very handy.

A question about my new 3TB drive given my system now contains this new EFI motherboard (gigabyte 990FXA-UD7). When I performed a fresh install of ubuntu64 10.04 on this 3TB drive (with the other drive disconnected), it created a "gpt" style partition, not "msdos".

Is there any way I can perform a whole new install on this 3TB drive and end up with the old style partitions? Or does the fact that the drive is bigger than 2.2TB require that the partition style be "gpt"?

@everyone: BTW, I can now boot the 1TB drive again, and the directory structure seems intact and I ran a few applications without problems (including my 3D game engine in the codeblocks IDE, which needs to find boatloads of .h files and link to boatloads of shared libraries all over the filesystem).

It got fixed by running a small application called "boot-repair". I thought I ran it in a mode that was only supposed to create a "bootinfo report" (which it did), but presto chango, after running it the 1TB drive was able to boot again. "boot-repair" is a pretty spiffy little application (even worked when I thought it wasn't supposed to). It has separate checkboxes to "restore grub" and "repair MBR", so it seems pretty useful.