RE: [SLE] Problems with initrd after mkinitrd
- From: "Patrick Freeman" <patrickf@xxxxxxxxxxxxxx>
- Date: Tue, 27 Dec 2005 20:32:16 -0500
> -----Original Message-----
> From: Carl Hartung [mailto:suselinux@xxxxxxxxxxxxx]
<snip>
> 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...!)
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.)
I will check the default, we do leave it at auto, however.
> 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?
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@xxxxxxxxxxxxxx
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.
--
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
- Prev by Date: [SLE] Vera/DejaVu Fonts
- Next by Date: Re: [SLE] [+/-OT] Does gmail pop3 work for you?
- Previous by thread: Re: [SLE] Problems with initrd after mkinitrd
- Next by thread: RE: [SLE] Problems with initrd after mkinitrd
- Index(es):
Relevant Pages
|
