Re: [suse-autoinstall] AutoInstall and Western Digital HDD issues.
Anthony, Can you please provide the log files for a failed installation? Thanks, Anas Anthony Staples wrote:
Anas,
RE: Strange behavior regarding Autoinstall and some Western Digital HDDs:
I am trying to develop an autoinstall for NLD 1.6 using a boot cd and an NFS repository. I have three machines that I am using for testing of autoinstall deployments. All are Dell GX60s with 40GB WD HDD, 512 MB RAM and Cereron 2.2Ghz CPUs. All have been updated to the latest DELL GX60 Bios (A08).
As I have posted previously, I have not been able to get any control files built on my primary test PC to work correctly on the other two units. Autoinstall always fails during the format phase on these other two units, and so the install does not complete. Here is the text of the error.
"Could not format /dev/hda2. you can continue if you know what you are doing, but, to prevent damage to your filesystems, it is safer to cancel and reboot"
I have tried many different approaches from explicitly setting the partition scheme to using the most generic scheme outlined in the documentation. Each time, the control file works as planned on my primary machine, but fails on the other two test units.
Yesterday, Tuesday, 8/24/2004, I had Steve Wilson and Don Vosburg from Novell in to help me troubleshoot and possibly solve this conundrum. Together we went thru all the different iterations of control files I had tried and some that Don came up with on the spot to try and make partitioning work on the secondary test machines. We rec'd the same results I had encountered over and over. Finally, as a last effort, we switched the hard drive in the "good" primary unit with the hard drive in one of the "bad" secondary units. This switch cause the two machines to exchange behavior. On closer inspection of the HDD we switched out, they were not exactly identical. Though both are Western Digital 40GB HDD, the model numbers differed slightly and they were manufactured in different countries...
The "good" drive details from visual inspection and WD diagnostics: Completely black outer shell. Manufactured in Thailand M/N: WDC WD400BB-75FJA1 S/N: WD-WCAJC2052229 Firmware: 14.03G14 C H S : 77504 16 63 Drive 0, port 0x01F0 Build Date unknown
The "bad" drive details from visual inspection and WD diagnostics: Black and silver outer shell Manufactured in Malaysia M/N: WDC WD400BB-75FRA0 S/N: WD-WMAJF1089739 Firmware: 77.07W77 C H S: 77504 16 63 Drive 0, port 0x01F0 Build Date: 8-JAN-04
The other failing test machine's drive was manufactured in Singapore... and also has the black and silver outer shell.
During the testing we also were able to recreate the issue using SLES 9.0 while performing a cdrom autoinstall to the "bad" secondary test unit.
Manual installs do not seem encounter the issue.
Autoinstalls seemed to ignore the partitioning info in the control files on the secondary test machines.
I have attached many of the autoinstall control files I have used during my testing and the testing done with Steve and Don from Novell.
(See attached file: ay_006.xml)(See attached file: autoyast2_gx60.xml)(See attached file: autoyast3_gx60.xml)(See attached file: autoyast_generic_gx60.xml)(See attached file: autoyast_refpro_gx60.xml)(See attached file: ay_003.xml)(See attached file: ay_004.xml)(See attached file: ay_005.xml)
Anyone's insights appreciated!!! If other info is needed please let me know, I will be happy to provide whatever I can .
Cheers, Tony
The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
Hi All, This is not a solution but something I have just found out. I do not know if my problem is the same but I had a similar problem, but if I use SuSE 9.0 Prof everything works. I have found that the kernel 2.6.4 does work most of the time. I have disks from various manufactures that have the exact same problem as described here, they would not work exactly the same. If I installed 9.0 on it and then did an upgrade to 9.1 it would work with the exception that only the primary linux partition is mountable. All other partitions are not. The Rescue 2.6.4 is able to mount all the partitions just not the final kernel build. I was able to get this exact problem described here with four manufactures of drives. -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 On Wed, 25 Aug 2004, Anas Nashif wrote:
Anthony Staples wrote:
Anas,
RE: Strange behavior regarding Autoinstall and some Western Digital HDDs:
I am trying to develop an autoinstall for NLD 1.6 using a boot cd and an NFS repository. I have three machines that I am using for testing of autoinstall deployments. All are Dell GX60s with 40GB WD HDD, 512 MB RAM and Cereron 2.2Ghz CPUs. All have been updated to the latest DELL GX60 Bios (A08).
As I have posted previously, I have not been able to get any control files built on my primary test PC to work correctly on the other two units. Autoinstall always fails during the format phase on these other two units, and so the install does not complete. Here is the text of the error.
"Could not format /dev/hda2. you can continue if you know what you are doing, but, to prevent damage to your filesystems, it is safer to cancel and reboot"
I have tried many different approaches from explicitly setting the partition scheme to using the most generic scheme outlined in the documentation. Each time, the control file works as planned on my primary machine, but fails on the other two test units.
Yesterday, Tuesday, 8/24/2004, I had Steve Wilson and Don Vosburg from Novell in to help me troubleshoot and possibly solve this conundrum. Together we went thru all the different iterations of control files I had tried and some that Don came up with on the spot to try and make partitioning work on the secondary test machines. We rec'd the same results I had encountered over and over. Finally, as a last effort, we switched the hard drive in the "good" primary unit with the hard drive in one of the "bad" secondary units. This switch cause the two machines to exchange behavior. On closer inspection of the HDD we switched out, they were not exactly identical. Though both are Western Digital 40GB HDD, the model numbers differed slightly and they were manufactured in different countries...
The "good" drive details from visual inspection and WD diagnostics: Completely black outer shell. Manufactured in Thailand M/N: WDC WD400BB-75FJA1 S/N: WD-WCAJC2052229 Firmware: 14.03G14 C H S : 77504 16 63 Drive 0, port 0x01F0 Build Date unknown
The "bad" drive details from visual inspection and WD diagnostics: Black and silver outer shell Manufactured in Malaysia M/N: WDC WD400BB-75FRA0 S/N: WD-WMAJF1089739 Firmware: 77.07W77 C H S: 77504 16 63 Drive 0, port 0x01F0 Build Date: 8-JAN-04
The other failing test machine's drive was manufactured in Singapore... and also has the black and silver outer shell.
During the testing we also were able to recreate the issue using SLES 9.0 while performing a cdrom autoinstall to the "bad" secondary test unit.
Manual installs do not seem encounter the issue.
Autoinstalls seemed to ignore the partitioning info in the control files on the secondary test machines.
I have attached many of the autoinstall control files I have used during my testing and the testing done with Steve and Don from Novell.
(See attached file: ay_006.xml)(See attached file: autoyast2_gx60.xml)(See attached file: autoyast3_gx60.xml)(See attached file: autoyast_generic_gx60.xml)(See attached file: autoyast_refpro_gx60.xml)(See attached file: ay_003.xml)(See attached file: ay_004.xml)(See attached file: ay_005.xml)
Anyone's insights appreciated!!! If other info is needed please let me know, I will be happy to provide whatever I can .
Cheers, Tony
The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
participants (2)
-
Anas Nashif -
Boyd Lynn Gerber