help: any way to keep on trucking with bad MBR ???
Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
help: any way to keep on trucking with bad MBR ???
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
Last edited by RudyMartin; 01-07-2012 at 08:34 PM.
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.
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 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.
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.
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:
Code:
dd if=/dev/sda of=mbr.img bs=512 count=1
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.
/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.
Code:
# grub-setup --directory=/boot/grub '(hd0)'
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:
Code:
--directory=/mnt/boot/grub
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.
Last edited by edbarx; 01-09-2012 at 03:36 PM.
Reason: To add a post scriptum.
@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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.