-----Original Message----- From: Carl Hartung [mailto:suselinux@cehartung.com]

Each cloned drive should theoretically have /boot and initrd "land" in

<snip> the

same physical location when the image is written, correct? Yet, sometimes and for unknown reasons, the clone doesn't completely "take" and you have to reinstall Grub to make the system bootable. Hmm... interesting clue...

Please tell me you meant "sector" as in LBA and *not* "cylinder" as in CHS addressing? <shiver!><Ugh!> (Pardon my flashbacks...!)

Yes, I meant sector 2082 -- I assumed a relationship here, which I am not totally sure about. <snip>

Your 40GB drives, mainboards and the BIOS are all contemporary enough to support LBA, meaning the physical location of /boot and initrd is not an issue... unless, of course, you accepted "Auto" in the BIOS' IDE drive setup and the default just happens to be CHS (required by M$haft.)

Under that scenario, there *is* a possibility that the BIOS could be calculating (and using) a geometry for the 'transplants' that doesn't perfectly match the imaged partition table.

...

The adapter is passive. My main problem with a hardware based resolution, is that things work 100% of the time with installation

Under this scenario, the drive starts it's service life out being

I will check the default, we do leave it at auto, however. prepped

and used in situ under the same BIOS. Have any of *these* systems experienced boot failures following mkinitrd?

Indeed, this is the very issue. Installs are fine.

...

and probably something like 95-98% of the time with imaging (the only failures being the grub hangs which are usually corrected by grub re-install -- which I think are actually the same symptom (retrospectively)

What is really missing in all of these discussions are the results of meaningful forensics on all of the drives that are failing to boot. I think this approach would bear fruit more quickly than a twenty system lab experiment (maybe it isn't as much *fun* but that's another topic...)

I have taken the output of debugreiserfs -D <device> from two machines -- one which failed after mkinitrd and one that did not -- I was planning on looking at that as time permitted. I think you are alluding to actually reading the hex off of the drive though -- do you have a tool / scenario in mind? (and actually, I will need to do the 20 machine scenario for validation anyway. This is the real world issue that I will need to show has been corrected. I agree, however, that root causing the situation is more desireable -- but time / resources wise, If I can show that the problem is solved, I will not pursue it further, because I have so many other fish to fry). <snip> Thanks again ... PATRICK FREEMAN, SYSTEMS SPECIALIST Work: (949) 330-7699 Fax: (949) 330-7691 patrickf@datallegro.com www.datallegro.com Confidential: The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized.