Re: [SLE] Problems with initrd after mkinitrd
- From: Carl Hartung <suselinux@xxxxxxxxxxxxx>
- Date: Tue, 27 Dec 2005 19:18:42 -0500
Hi Patrick,
More fodder to keep you up at nights ;-)
On Tuesday 27 December 2005 13:16, Patrick Freeman wrote:
<snip>
> (BTW, thanks for the input, Terry) Well, interestingly, all of the
> machines were booting at cylinder 2082 prior to the mkinitrd problem --
Each cloned drive should theoretically have /boot and initrd "land" in 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...!)
> All machines:
> -- AIC RMC2E2 chassis with hotpluggable SATA backplane.
> -- Intel SE7520BD2 motherboards with 6GB Registered ECC DDR RAM.
> -- Dual 2.8GHz (Low Voltage) Xeon's
> -- Ages range from ~1 year to ~2 months.
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 prepped and
used in situ under the same BIOS. Have any of *these* systems experienced
boot failures following mkinitrd?
> 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...)
regards,
- Carl
--
Check the headers for your unsubscription address
For additional commands send e-mail to suse-linux-e-help@xxxxxxxx
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@xxxxxxxx
- Follow-Ups:
- Re: [SLE] Problems with initrd after mkinitrd
- From: Carlos E. R.
- Re: [SLE] Problems with initrd after mkinitrd
- References:
- RE: [SLE] Problems with initrd after mkinitrd
- From: Patrick Freeman
- RE: [SLE] Problems with initrd after mkinitrd
- Prev by Date: Re: [SLE] SPAM: dhcpd Doesn't Run
- Next by Date: Re: [SLE] Re: OT: Tax software: Comments, votes
- Previous by thread: RE: [SLE] Problems with initrd after mkinitrd
- Next by thread: Re: [SLE] Problems with initrd after mkinitrd
- Index(es):
Relevant Pages
|