bug#18549: parted causes scsi raid to not boot up.

[Phillip Susi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Please keep the bug in the Cc list so that others can follow the
conversation ( possibly in the distant future ).

On 10/1/2014 5:23 PM, Price, Eric - Exelis.Contractor wrote:
> Sir:
> 
> A little background on our problem we are copying disk images off
> of a hard drive, and in some cases repartitioning the drive, And
> then restoring the image.
> 
> We have two drives that are SCSI RAID 0 drives (mirroring is done
> in firmware), that are failing the restoration process.

How is it "failing"?  If it is only the CHS values that have changed,
then nobody should notice or care since any software written in the
last 20 years has ignored these values as they have been meaningless
and obsolete since the '90s.  I gather that you are using parted to
recreate the partition table on the drive so you can then restore the
data to those partitions using some other means?  Just to make sure,
there is only a single logical drive in /dev on which you are using
parted right?

> This is the reference I am using: 
> http://thestarman.pcministry.com/asm/mbr/PartTables.htm 
> [cid:image002.png@01CFDD81.70D9DF00] The original MBR/Partition
> Table is on the left the one we recreated with parted that is
> corrupted is on the left The partition-type descriptors have
> changed from NTFS (07) to Linux native files systems (83) but in
> out testing that did not seem to be a problem,
> 
> As the files systems were always correctly resored. On the data
> obtained from the SCSI RAID drives we notices the Ending CHS for
> partition 0 is off
> 
> By one bit as is the Starting CHS for partition 1.

Looking at your picture, it appears that the original CHS values were
Head = 7, Sector = 61, Cylinder = 1023, and the new values are Head =
131, Sector = 62, Cylinder = 1023.  In both cases the ending LBA is
20482560, which is too large to be represented in CHS, so presumably
these values are the maximum allowed values going by whatever the
partitioner thinks the drive's "actual" ( no such thing ) geometry is.
 I'm guessing that whatever you originally used to partition the drive
believed it had 8 heads and 62 sectors per track, and now your kernel
thinks it has 132 heads and 63 sectors per track.  Normally the kernel
assumes 255 heads and 63 sectors per track, so I'm not sure where the
132 is coming from.

> We are using a 5.8 kernel.

Did you mean 3.8?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJULakhAAoJEI5FoCIzSKrwCvwIAKBABIChgAQuN/4xvvLoHavY
jN7b83F1undHGsBbCQEJ934v2yhGRaOVeX6UL75jNtGDkZW1yYRXdTeClHpS4FnG
x4kgYYeYT6hD7bv25MR+yuJXjeTiGpi0QZJ1D0MsXIK/i+6ePEftl64hW2mS4hWM
HXiUqzQ+GEIEPSFgZPrPdROcd6L0E2VB/5oCDAT3aZu3i8P/09CNd37rIqlpQHEn
12Vxixsk8obor2vCVy9oipJAT8BAgP3lZRD8jLvAa2WrK3kDzkxMotujNF9k64Pk
wfkUYaBgVQpM/BYTF4ghYUT9fXOKxBC08ZIuohL99b57fZl9yhw2MBsbm2WepFo=
=CEUq
-----END PGP SIGNATURE-----