RE: [SLE] Problems with initrd after mkinitrd
- From: "Patrick Freeman" <patrickf@xxxxxxxxxxxxxx>
- Date: Tue, 27 Dec 2005 13:16:00 -0500
Carl,
Thanks again -- I just wanted to fill you in on the information that was
missing, but have not yet finished my experiment. Thanks, again -- see
below.
> -----Original Message-----
<snip>
> I have to acknowledge this problem exist(s/ed) on older hardware, but
it
> is
> also important to point out that modern drives and BIOSes set to use
LBA
> (which Grub and Linux 'speak') cleanly eliminates this specific
> limitation.
> AIUI, under LBA, the current "interesting" addressing barrier is
137GB.
(BTW, thanks for the input, Terry) Well, interestingly, all of the
machines were booting at cylinder 2082 prior to the mkinitrd problem --
because I wasn't concerned with it (see the board info below). My
previous practice had been to use a 100 MB /boot partition, but I was
doing much different things then -- and on older equipment.
>
> And Patrick,
>
> I've studied the entire thread again, top to bottom, to see if we have
> overlooked something, and I'll share these thoughts:
>
> 1. We don't know the manufacturer or age of the machines we're
> discussing...
> no mainboard or CPU models/numbers etc... the only 'clue' is that
you've
> seen
> this problem "to some degree" under SuSE 9.1. The ages and make/model
of
> these systems are important clues.
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.
> 2. Is the 2.5" to 3.5" "adapter" just a mechanical carrier, or is it
also
> involved in the (data) cabling? This adapter (coupled with WD's
specific
> recommendation that you *not* use this drive in your application)
*and*
> the
> inclusion of the highpoint driver are big enough 'atypical' factors
that
> they
> deserve special attention. You need to be certain that these have been
> properly ruled out and aren't involved/contributing/confusing matters.
The adapter is passive. My main problem with a hardware based
resolution, is that things work 100% of the time with installation 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) except it is hanging loading the kernel and before
printing to the screen??).
> 3. We should not overlook this one important clue: "... requires re-
> installing
> grub which sometimes produces a hang on loading stage1.5."
>
> All things being equal, I think Carlos' hypothesis is likely correct.
I'll
> be
> looking forward to your "report", so have fun and good luck!
<snip>
Thanks -- my initial results: I resized reiserfs on three machines that
were hanging (to move swap to the inside of the drive) -- created an
ext2 formatted partition between cylinders 1 and 900 (which, predictably
solved the problem). I am now waiting to allocate 20 machines (10
control, 10 experimental) to perform initrd updates on and reboot where
the control group has a single / partition and the experimental group
would have the /boot partition as described above.
I'll keep you all updated -- thanks again.
Patrick
--
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: Carl Hartung
- Re: [SLE] Problems with initrd after mkinitrd
- Prev by Date: [SLE] Tech Support - Installation TaxACT Deluxe (fwd)
- Next by Date: Re: [SLE] Problems with initrd after mkinitrd
- Previous by thread: RE: [SLE] Problems with initrd after mkinitrd
- Next by thread: Re: [SLE] Problems with initrd after mkinitrd
- Index(es):
Relevant Pages
|
