Can't boot linux after new mobo and proc

[Shep]

Hey guys, I'm going crazy trying to get my linux box up after installing my new motherboard and processor. I've been using linux for over 5 years exclusivly at home. I've installed it more times than I can think of. This is the first time my install has been a complete failure. Anyhow on to the relevant info. My new hardware is:
nForce3-A motherboard
AMD Athlon64 3000+

So I installed the hardware and started up my box. It immediately have me a grub error saying "Grub 1.5 Read Error" or something similar. So I figured this was due to my new hardware and wasn't a big deal. I went about installing Kubuntu on hda2 where my slack install used to reside. The install went fine without errors. After it installed grub into my MBR, I rebooted and received the same grub read error. It all has gone down hill from there.

I've tried every disk I have laying around my office. The live Kubuntu AMD64 DVD boots fine and I can do anything I need to in that. I also booted using a 32 bit version of Knoppix live CD and I can mount my partitions and all looks fine. I can also get to the grub CLI from there and it looks like it installs grub fine. I have also tried to install the AMD64 testing version of Debian. This gives me a different error after I do the base install. It says "System boot disk failure. Please insert boot disk and press return" or something of that nature. It does not look like its a error that grub is spitting out though.

I'm hoping this is just somthing I have overlooked in the bios or hardware install. Here are some of the things I've tried.

Reinstall grub via CLI
"root (hd0,1)"
"setup (hd0)"
it says its successful

Changed BIOS setting
"set access mode to LBA on HDs"
"changed boot order around"

Flashed/updated BIOS (already latest version)

Let Debian installer wipe out my whole HD and all partitions

Created /boot partition

I have list any more info needed. Please help, this is driving me crazy not having my linux apps.

BTW hda is a 160GB hd that now only has a swap and ext3 partition on it. It used to tripple boot on my old hardware. I've never had any problems with grub in the MBR previously.

[leonpmu]

What was your proc and motherboard before?

I had this when I changed from and AMD with forced change to an Intel (yuck) and the system wouldn't boot... I had to recompile the kernel, selecting the right proc type, and then it would boot fine..

Someone reckoned it might've been the northbridge, I am not sure, but recompiling the kernel for the right proc did the trick...

[Shep]

I figured I'd just reinstall OS all together since this one is 64bit. Before I was using the AMD Athlon 2200+. I also had a Gygabyte mobo, don't remember the model. It looks like everything is fine when I boot on the live CD/DVD, but when I try to boot to the harddisk it pukes.

[leonpmu]

Arb suggestion, have you tried Lilo??

Simply becaue in the past on some hardware the system would use Grub and NOT Lilo, and vice versa...

[Shep]

No, all the distros I've tried use Grub. On my list to try tonight are Slack10 and Gentoo. I've used Slack before, but never Gentoo. Do either of those use Lilo?

[gehidore]

Remove all extra disk drives, then boot your <livecd> and do this...

(grub might be getting called from another drive...)


from a root consoe:

mkdir /mnt/chroot
mount /dev/hda1* /mnt/chroot <where * is your / partition>
mount /dev/hda2* /mnt/chroot <where * is your /boot partition if you have one>
mount -t proc none /mnt/chroot/proc
chroot /mnt/chroot/


This should bring you into a shell that has the old hostname of your old install.

Then...


cd /boot/grub
<yourfaveditor> menu.1st (*or on some older versions grub.conf*)

you're looking for the line that says

root (hd*,*)


Assuming there are no other drives plugged in INCLUDING usb thumbdrives the "root" would be pointing at /boot in my case. therfor:

root (hd0,1)

then we save and exit.
while still in your chroot environment:

grub
root (hd0,1)
setup (hd0)
quit


Since we're already chrooted now would also be a good time to roll a new kernel with the drivers for your new hardware... once done follow the directions for your distro into copying the kernel/initrd* <if required> to /boot and setting up your grub config file to point to them.

[dannybunkins]

Slackware uses Lilo By Default, and you can install Lilo Instead of Grub on Gentoo.

[Shep]

Remove all extra disk drives, then boot your <livecd> and do this...

(grub might be getting called from another drive...)


from a root consoe:

mkdir /mnt/chroot
mount /dev/hda1* /mnt/chroot <where * is your / partition>
mount /dev/hda2* /mnt/chroot <where * is your /boot partition if you have one>
mount -t proc none /mnt/chroot/proc
chroot /mnt/chroot/


This should bring you into a shell that has the old hostname of your old install.

Then...


cd /boot/grub
<yourfaveditor> menu.1st (*or on some older versions grub.conf*)

you're looking for the line that says

root (hd*,*)


Assuming there are no other drives plugged in INCLUDING usb thumbdrives the "root" would be pointing at /boot in my case. therfor:

root (hd0,1)

then we save and exit.
while still in your chroot environment:

grub
root (hd0,1)
setup (hd0)
quit


Since we're already chrooted now would also be a good time to roll a new kernel with the drivers for your new hardware... once done follow the directions for your distro into copying the kernel/initrd* <if required> to /boot and setting up your grub config file to point to them.

Thanks for the tip, I'll give that a try. I ended up wiping my whole HD clean, so there shouldn't be a need for a new kernel(besides the base). I haven't tried unplugging my second hard drive. Thanks for the tips.

[Shep]

Well no luck at all with the suggestions. So I deciede to wipe out my harddrive and try windows. And what do you know, it wouldn't boot. So I wiped out my other harddrive and tried that. Still wouldn't boot any OS. I even tried making a CD with my Boot folder to boot from CDrom. Still gave me a grup read error. I'm going to pick up a new mobo today and send this one back. What a POS. Oh yeah, I also disabled ACIP or AICP what ever it is in bios with no luck.

[hard candy]

Do you have the bios setting to boot from a hard disk correctly enabled?
And if you are looking to get rid of GRUB, you will need the MS-DOS version of fdisk, and run "fdisk /mbr", the linux version will not do this. Then do your Windows install and then your Linux install. The old GRUB was probably basing it's boot sequence off a invalid disk geometry since the bios had changed.


"There are several methods of using the BIOS to access a disk before any kind of driver is active. The only consistent one is the INT 13h interface, which uses an addressing scheme based on the Cylinder, Head, and Sector positions of a block, packed into a value consisting of 10 bits, 8 bits, and 6 bits, respectively.

To attempt to get around this issue, and in the case of SCSI disks, to allow a differential number of sectors in different physical cylinders without confusing the heck out of the software, the concept of Geometry Translation was introduced. Geometry Translation produces a transparent virtual mapping from some phantom number of Cylinders, Sectors and Heads onto the real hardware of the disk, generally trying to increase the space of the disk accessible via the INT 13h interface.

Another problem created from the above is that different controller/BIOS combinations (and possibly even different particular installations of software) can use different geometry translations, and since the bootloaders on the disk depend on the particular numbers, they either have to be carefully updated, or, in some cases, the whole OS must be re-installed when moving the disk to another controller/BIOS combination.

The essential issue is that pretty much all bootloaders prior to GRUB use Cylinder/Head/Sector numbers for the first stage of booting, so if that mapping should change, your OS can't boot, even though the linear mapping is the same, and if you could get it booted somehow, everything work would fine.

GRUB solves this by translating from/to a linear block-number AT ALL TIMES. This turns out to be OK, as the major OS used to test a BIOS translation mechanism, DOS, uses exactly the same mappings."

[Shep]

Do you have the bios setting to boot from a hard disk correctly enabled?
And if you are looking to get rid of GRUB, you will need the MS-DOS version of fdisk, and run "fdisk /mbr", the linux version will not do this. Then do your Windows install and then your Linux install. The old GRUB was probably basing it's boot sequence off a invalid disk geometry since the bios had changed.


"There are several methods of using the BIOS to access a disk before any kind of driver is active. The only consistent one is the INT 13h interface, which uses an addressing scheme based on the Cylinder, Head, and Sector positions of a block, packed into a value consisting of 10 bits, 8 bits, and 6 bits, respectively.

To attempt to get around this issue, and in the case of SCSI disks, to allow a differential number of sectors in different physical cylinders without confusing the heck out of the software, the concept of Geometry Translation was introduced. Geometry Translation produces a transparent virtual mapping from some phantom number of Cylinders, Sectors and Heads onto the real hardware of the disk, generally trying to increase the space of the disk accessible via the INT 13h interface.

Another problem created from the above is that different controller/BIOS combinations (and possibly even different particular installations of software) can use different geometry translations, and since the bootloaders on the disk depend on the particular numbers, they either have to be carefully updated, or, in some cases, the whole OS must be re-installed when moving the disk to another controller/BIOS combination.

The essential issue is that pretty much all bootloaders prior to GRUB use Cylinder/Head/Sector numbers for the first stage of booting, so if that mapping should change, your OS can't boot, even though the linear mapping is the same, and if you could get it booted somehow, everything work would fine.

GRUB solves this by translating from/to a linear block-number AT ALL TIMES. This turns out to be OK, as the major OS used to test a BIOS translation mechanism, DOS, uses exactly the same mappings."

Thanks, that is good information. I have double, triple, and uhh well I've checked the grub menu list numerous times. It lists the correct partitions to boot etc. On my 80 GB HD I did a full format of the disk, so that should have wiped out the MBR right? I then tried to install Windows first. It still couldn't boot the OS. I am taking into a local shop here to test for booting. Hope they can give me some insight into this. I'll grab the fdisk ms-dos and try the fdisk /mbr. I tried that under a live cd, but it said /mbr not found.

[hard candy]

On my 80 GB HD I did a full format of the disk, so that should have wiped out the MBR right?
No, only if you do a low level format (which can take hours since each bit is written over instead of the file system pointers/journals being erased), the mbr is protected and cannot be overwritten by OS level formatting programs.

[Shep]

OK, I downloaded freeDos, and will try the FDISK /MBR command when I get home. I really hope this will do the trick.

[hard candy]

I had run into the same thing before, Grub on the MBR, would not let anything be installed since the boot up OS (Linux or WinXP) disk could not access the MBR. The "fdisk /mbr" did the trick. And I had changed the HD's around so that GRUB was looking for love in all the wrong places.

[Shep]

Well I'm finally posting from a booted OS. I got desperate and started messing with the bios settings. It was disabling DMA that finally did it for me.

[enshum]

You have to fdisk /mbr then you should boot just fine with a new install.