bugGNU GRUB - Bugs: bug #2394, Problem with HPT370 Raid controller

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #2394: Problem with HPT370 Raid controller

Submitted by:  None
Submitted on:  Sat 25 Jan 2003 05:46:08 PM UTC  
 
Category:  Booting Severity:  Major
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Privacy:  Public
Assigned to:  None Originator Name: 
Originator Email:  -email is unavailable- Open/Closed:  Closed
Release:  Release:  Bazaar - trunk
Reproducibility:  Every Time Planned Release:  None

( Jump to the original submission)

Sun 17 Oct 2010 12:00:26 AM UTC, comment #10: 

Now GRUB2 writes embedding zone using Reed-Solomon, so anything beyond first six sectors (the size of loader and RS decoder along with some helper functions) + some functions later in the code (but all of them before sector 9) can be overwritten without making GRUB unbootable.

Vladimir Serbinenko <phcoder>
Project Administrator
Sat 06 Jun 2009 05:40:21 PM UTC, comment #9: 

dmraid -r -vvv and dmraid -s -vvv fail to identify any raid disks.

In this setup, my disks are not actually raided together.

If I do need to extract sectors by hand,
dd if=/dev/hde skip=9 count=1
will output sector 9 to stdout, right?

I just had a quick look, and sector 9 on the primary hard disk doesn't
look anything like the structure in dmraid's hpt37x.h. It's possible
that I overwrote this sector a long time ago with grub, and it doesn't
get restored by the BIOS unless I go into the BIOS and change the RAID
configuration. Which indicates that detecting the on-disk format is a
little fragile.

Paul "TBBle" Hampson <tbble>
Sat 06 Jun 2009 02:40:06 PM UTC, comment #8: 

Well actually just use `dmraid -rD' if -vvv show something that it detects the metadata
Then superblock and offset gets dumped to dmraid.hpt37x/ for all your disks where it found it.
If that's the case please tar it and attach it either here or send it to me.

Felix Zielcke <fzielcke>
Project Member
Sat 06 Jun 2009 01:30:21 PM UTC, comment #7: 

Does `dmraid -r -vvv' or `dmraid -s -vvv' show anything useful for you? I.e. something like:
NOTICE: /dev/sda: nvidia metadata discovered?

htp37x.h mentions a DATAOFFSET of 10
For my NVIDIA fake RAID this is set to 0
In hpt37.c it says:
        /* Data offset from start of device; first device is special */
        rd->offset = hpt->disk_number ? HPT37X_DATAOFFSET : 0;

So please check sector 9 of your first disk and maybe Sector 10 and 19 of your 2nd one.

Felix Zielcke <fzielcke>
Project Member
Sat 06 Jun 2009 12:21:24 PM UTC, comment #6: 

Just a quick followup, there's no indication in this bug report that the problem has been fixed, and the current workaround I'm using (installing to the /boot partition instead of in the MBR using grub-setup "(hd0,1)") now complains that this is a bad idea.

However, I don't know of another workaround available in grub2.

Paul "TBBle" Hampson <tbble>
Sat 09 Feb 2008 02:33:41 PM UTC, comment #5: 

http://www.mail-archive.com/bug-grub@gnu.org/msg09759.html confirms sector 9, BTW. http://www.wensley.org.uk/raid suggests the entirety of sector 9 except the first 32 bytes is used.

lib/format/htp37x.h in dmraid appears to define a structure for the HPT37x metadata, so maybe we can detect this after all?

A brief glance at this code suggests that the data is all in sector 9, but is in sector 9 of each physical disk on the relevant machine. I can't check this right now, I accidentally did a grub-install hd0 since my last reboot, so once I next reboot I can confirm the metadata's presence on a machine without a RAID setup.

Sector 9 on my second disk (also on the RAID controller) contains nulls and then NULL NULL "Found a array member was" 0x20 x 22, repeated 8 times, up to the 60 bytes of filler mentioned in the dmraid structure. I dunno if this means the ondisk metadata format only applies to the first physical disk (seems likely) and the BIOS uses sector 9 on the other disks for scratch, or what.

I hope that helps?

By the by, everything else in dmraid's ataformat headers stores its metadata offset from the end of the disk, which is why this problem seems localised to the HPT3xx devices.

Paul "TBBle" Hampson <tbble>
Sat 09 Feb 2008 01:48:26 PM UTC, comment #4: 

For detecting the controller, I'd have to say that PCI blacklisting is probably the most accurate. The problem is that from what I'm reading on google (the machine is my primary file server and router so I can't confirm this myself just now) the case of no soft-raid setup produces an all-zeroes change to four bytes in sector 10, so on a blank hard disk, you can't spot the signature.

http://lists.gnu.org/archive/html/bug-grub/2004-07/msg00113.html gives 0x1220-0x1223 as the place it changes, but somewhere else suggested it varies by BIOS version. yuck

The aforementioned mailing list posting suggests that 16 sectors in  instead of 1 is safe.

Paul "TBBle" Hampson <tbble>
Sat 02 Feb 2008 08:40:01 PM UTC, comment #3: 

Do you have any idea on how to check for the presence of that controller?

Can you find the exact sector and size of the affected region?

Can you provide more details on the workaround?  If you embed core.img after the MBR, chances are it'll be overwritten, right?  What offset do we need?

Robert Millan <robertmh>
Project Administrator
Sat 02 Feb 2008 08:27:21 AM UTC, comment #2: 

According to my own bug report (twelve months ago, mind you) at http://bugs.debian.org/394868, this also affects grub2.

I don't see how to re-open the bug (I'm not the original submitter) though.

Paul "TBBle" Hampson <tbble>
Sat 15 Dec 2007 12:17:19 PM UTC, comment #1: 

We've moved to GRUB 2 as a development platform.  Please can you check if this bug still applies there, and if it does, reopen it?

Thanks

Robert Millan <robertmh>
Project Administrator
Sat 25 Jan 2003 05:46:08 PM UTC, original submission:  

HPT 370/372 controllers apparently overwrite a sector with internal configuration data of the controller, even without raid setup. The sector is around 9-10 after MBR, so it overwrites stage1_5.
Now it's possible with manual configuration to overcome the problem (embedding stage1_5 avoiding that sector), but I guess it should be possible for grub to check for it and avoid it automatically.

Regards

Max

Anonymous

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by phcoder (Posted a comment)
  • -email is unavailable- added by fzielcke (Posted a comment)
  • -email is unavailable- added by tbble (Posted a comment)
  • -email is unavailable- added by robertmh (Posted a comment)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-10-17 phcoder StatusNone => Fixed
        Open/ClosedOpen => Closed
        ReleaseNone => Bazaar - trunk
    2008-02-02 robertmh Open/ClosedClosed => Open
    2007-12-15 robertmh Open/ClosedOpen => Closed

    Back to the top


    Powered by Savane 3.6