Re: bin/37656: fdisk segfault on invalid MBR entries on non-x86 geometry detection

[Eric Auge <eau%phear.org@localhost>]

The following reply was made to PR bin/37656; it has been noted by GNATS.

From: Eric Auge <eau%phear.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: bin/37656: fdisk segfault on invalid MBR entries on non-x86 
geometry
 detection
Date: Wed, 02 Jan 2008 12:59:08 +0100

 This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
 --------------enig494E6F7C055A8B6881266714
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 John Nemeth wrote:
 > The following reply was made to PR bin/37656; it has been noted by GNAT=
 S.
 >=20
 > From: jnemeth%victoria.tc.ca@localhost (John Nemeth)
 > To: Eric Auge <eau%phear.org@localhost>, gnats-bugs%NetBSD.org@localhost
 > Cc: netbsd-bugs%NetBSD.org@localhost
 > Subject: Re: bin/37656: fdisk segfault on invalid MBR entries on non-x8=
 6 geometry detection
 > Date: Wed, 2 Jan 2008 03:20:39 -0800
 >=20
 >  On May 25,  6:20am, Eric Auge wrote:
 >  } Martin Husemann wrote:
 >  } > The following reply was made to PR bin/37656; it has been noted by=
  GNATS.
 >  } >
 >  } > From: Martin Husemann <martin%duskware.de@localhost>
 >  } > Subject: Re: bin/37656: fdisk segfault on invalid MBR entries on n=
 on-x86 geometry detection
 >  } > Date: Wed, 2 Jan 2008 11:21:24 +0100
 >  } >
 >  } >  On Wed, Jan 02, 2008 at 02:13:59AM -0800, John Nemeth wrote:
 >  } >  >      Not sure how this is handled, but yes the MBR would be all=
  0s.
 >  } >
 >  } >  The MBR has a magic number at the end (see MBR_MAGIC_OFFSET and M=
 BR_MAGIC
 >  } >  in bootblock.h).
 > =20
 >       The issue here is using the partition table to guess the disk
 >  geometry.  Obviously, if there isn't a valid partition table you can't=
 
 >  do that.  BTW, I wrote code to do this 15 years ago.  At that time, PC=
 
 >  BIOSes didn't have an "auto" setting for detecting disks automatically=
 ,
 >  so you had to manually tell it the size of the disk.  Usually if you
 >  set the "type" to "47", it would let you enter the geometry manually.
 >  My program told you what numbers to stick in there, so I called it
 >  "type47".
 > =20
 >  } Can fdisk fail in writing this magic number ?
 > =20
 >       Only if there is a serious bug.
 > =20
 >  } This is an fdisk generated MBR partitioning on the cobalt, all tests=
 
 >  } I've done were reporting this bad magic number.
 > =20
 >       If that is the case, then it shouldn't have been using the
 >  partition table to guess the disk geometry.
 
 yep but using what as we are not on x86 arch ? I don't think there is
 BIOS calls on cobalt, I'm no expert though.
 
 > =20
 >  } But it now successfully boot, what the purpose of this "magic number=
 " ?
 > =20
 >       To let the BIOS know that it is a valid boot sector.  If the
 >  number isn't there, then the machine shouldn't boot at all.
 
 My previous post was including an fdisk output showing the "bad magic
 number" on each partition reported by fdisk but still the cobalt boot
 normally.
 
 fdisk was the tool used to build the partition.
 
 >  }-- End of excerpt from Eric Auge
 
 Regards,
 Eric.
 
 
 
 --------------enig494E6F7C055A8B6881266714
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: OpenPGP digital signature
 Content-Disposition: attachment; filename="signature.asc"
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.7 (NetBSD)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFHe3yPSdZNA80H8MYRArkDAKCxpqYerhZBKn9ERuFzXf9m/+jVrwCgsMJ6
 Teve85GgFeu1poTSeiXVq7s=
 =KBrk
 -----END PGP SIGNATURE-----
 
 --------------enig494E6F7C055A8B6881266714--