BIOS Hangs with Old Drives

[sechs]

I'm running into a strange situation with the new NAS that I'm building.

When I attach any of the drives from the old NAS, the BIOS hangs with an "IDE" error code. If I turn on the AHCI BIOS, it IDs all of the drives, but the BIOS then hangs with an error concerning the option ROM. I have two new drives, and they give no problems; they're the same models as the old drives.

After resetting the BIOS, I made sure that secure boot was turned off. I've checked all the connections, as well as the backplane that they're on. In fact, if I plug the drives in after POST, FreeNAS, IDs and mounts the drives without any issues.

Is there something that I'm missing?

 

[mubs]

Maybe zero the old drives for the first 5% using a tool like DBAN or Minitool Parition Wizard?

 

[sechs]

The BIOS shouldn't be interacting with the data on the drives until hand-off, so I'm not sure why that should do anything. I'm booting from a USB stick.

Once I redo the back-up that I accidentally deleted, I'm destroying the existing RAIDZ1 that the drives are in to create a RAIDZ2 along with the new drives. Do you think that would do the trick?

 

[ddrueding]

I think you're on the right track with SATA modes in the BIOS. Can you force them into IDE mode? Maybe even SATA1 (150)? Try disabling all the ports you can?

 

[Mercutio]

I've run in to something similar with Intel server boards. The system didn't hang exactly. It would just take about 20 minutes to boot SATA3 drives on a SATA1 contorller interface and then an extra-long boot process after that, suggesting a dramatically reduced data transfer rate. I wound up using a firmware tool to switch the drive mode to SATA1 and then everything started behaving normally.

 

[sechs]

I think you're on the right track with SATA modes in the BIOS. Can you force them into IDE mode? Maybe even SATA1 (150)? Try disabling all the ports you can?

My choices are AHCI, RAID, and IDE. Tried IDE with the same results.

If it makes any difference, the new machine has a UEFI BIOS, whereas the old one didn't.

 

[sechs]

I've run in to something similar with Intel server boards. The system didn't hang exactly. It would just take about 20 minutes to boot SATA3 drives on a SATA1 contorller interface and then an extra-long boot process after that, suggesting a dramatically reduced data transfer rate. I wound up using a firmware tool to switch the drive mode to SATA1 and then everything started behaving normally.

This is an AMD board with a SATA3 controller. I tried waiting it out, but it never seemed to proceed.

All of the drives appear to be negotiating at 6Gb/s except the drives on channels 5 and 6. That's probably to do with the SATA/IDE combined mode setting, which I probably toggled and some point and didn't put back.

 

[Mercutio]

So there's no attempt to ever load an OS? Can you see a BIOS status code for where it's sticking in the boot sequence?

 

[Stereodude]

You can't hotswap them in after the OS is loaded?

 

[Chewy509]

The BIOS shouldn't be interacting with the data on the drives until hand-off

UEFI will interact with the drives during POST, typically reading the partition table (MBR/GPT) and looking for EFI boot volumes.

Couple of things that aren't mentioned, but I'll assume that you have done them:
1. Reflashed the BIOS to ensure a clean state.
2. Connected only one of the drives that cause the issue to SATA port 0 using a direct cable (avoiding the backplane) to ensure it's a controller/drive issue. Repeat for all drives, one at a time... Recommend you stick with AHCI.
3. Are there multiple SATA controllers or only a single one? (Some boards will add an additional SATA controller to give additional ports). Ensure the back plane is only connected to a single controller.
4. New cables?
5. Can you enable staggered spin-up on the drives? (possible drop in voltage during POST due to all drives spinning up at once).
6. Have you checked that the drives are spread across different PSU rails if applicable?
7. Related to 5 and 6, tried an alternate PSU?
8. Wipe the existing drives as mubs mentioned.

 

[sechs]

So there's no attempt to ever load an OS? Can you see a BIOS status code for where it's sticking in the boot sequence?

The BIOS is hanging with the boot code A2, which is simply described as an IDE error.

 

[sechs]

You can't hotswap them in after the OS is loaded?

What I'm doing for the moment is pushing them into the backplane after POST and before GRUB loads the OS. Everything runs perfectly after that. No problems from BSD.

 

[sechs]

UEFI will interact with the drives during POST, typically reading the partition table (MBR/GPT) and looking for EFI boot volumes.

Couple of things that aren't mentioned, but I'll assume that you have done them:
1. Reflashed the BIOS to ensure a clean state.
2. Connected only one of the drives that cause the issue to SATA port 0 using a direct cable (avoiding the backplane) to ensure it's a controller/drive issue. Repeat for all drives, one at a time... Recommend you stick with AHCI.
3. Are there multiple SATA controllers or only a single one? (Some boards will add an additional SATA controller to give additional ports). Ensure the back plane is only connected to a single controller.
4. New cables?
5. Can you enable staggered spin-up on the drives? (possible drop in voltage during POST due to all drives spinning up at once).
6. Have you checked that the drives are spread across different PSU rails if applicable?
7. Related to 5 and 6, tried an alternate PSU?
8. Wipe the existing drives as mubs mentioned.

1. Haven't reflashed the BIOS (not even sure how), but I have reset it using the jumper.
2. It's definitely the drives and not the ports, cables, or backplane. I've tried a number of combinations, including directly through a cable.
3. There's only one SATA controller, through the FCH
4. All of the cables are new. Seeing as everything runs perfect once we get past POST, I don't see them as a likely source of problems.
5. No, but since I can remove all of the drives except one of the old ones and have it hang, I don't think that's the issue.
6. See 5.
7. See 6.
8. Once I've confirmed that my back-up is good (for some reason, LZ4 is compressing the files differently on the copy), I'll destroy the old RAIDZ1 and wipe the disks.

 

[sechs]

I may have a conclusion on this.

After a 16 hour power outage yesterday, I was able to finish scrubbing the the back-up and wipe the old disks. Suddenly, happy days. I built the new RAIDZ2, and that works fine, as well. I will start the restore this evening.

WTF happened here?

 

[mubs]

I've had bizarre, unexplainable problems go away when I wiped the HDDs. There's something in the way of the setup - partition table, MFT, etc., that sometimes cause problems.