RE: [Fedora] Re: FC14 Installation Hangs



-----Original Message-----
From: users-bounces@xxxxxxxxxxxxxxxxxxxxxxx [mailto:users-
bounces@xxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of JB
Sent: Tuesday, January 25, 2011 4:43 PM
To: users@xxxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [Fedora] Re: FC14 Installation Hangs

Do not worry, be happy.
You are a brave girl - the way you read all that extended output proves
that your are a pro :-)

I am afraid you have to give it a shot or two more.

Firstly, the reason you updated BIOS was to potentially fix ACPI as well.
But you tried F13 with acpi=off kernel parameter ...
So, back to a drawing board :-)

Once again, remove all parameters, except debugging-output:
ignore_loglevel initcall_debug
Run it.

Secondly, as I asked you before, take a look at BIOS. Just for a kick,
every
menu (there may be some new stuff as well due to update), do not try to
change anything, just get a sense of it all.
Then consider if restoring all defaults would be an option, or selecting
automatic (where available), or giving up any unnecessary/fancy manual
option.
Run it. As above.

Thirdly, stick around the thread for many days (even weeks) - there is a
good
chance somebody will have time (like Lamar next week) and come up with a
good idea.
Or F15 devs will deliver new code that will fix these things in a few
months.
Do not expect wonders - yes, some of these guys are true pusycats, but
these devs are heroes as well - they do not have access to specs, have to
deal with proprietary code (like in your case) - but look Ma, they come up
with a working software, again and again.



Restoring the BIOS to default settings is something the update does
by default. In fact, it completely clears the CMOS, updates the BIOS and
upon reboot a message pops up saying the CMOS isn't set and it's reverting
to default values. The only thing I changed after that was to set the power
failure option to 'power on' when AC is restored. Everything else is at
default. That was one of the things I tried early on too, just to make sure
it wasn't me that messed something up.

And I also did just boot up, with no parameters at all, after the
update. Then slowly started adding stuff ... The acpi=off was one of the
first parameters I added after the first boot failed. By now I've seen so
many different iterations of the lock up, I couldn't tell you where exactly
it locked up.

There are other hardware quirks that I've discovered throughout all
of this. For example, if I were to disable the on-board SCSI bus, it pegs
the HDD light to on at all times. No clue why. Leaving the SCSI bus at the
default 'enabled' state, the HDD light works as expected. I'd rather
disable it since it's not being used at all but if I do that, someone else
will inevitably call me at 3 in the morning just to tell me the machine is
overloaded because the HDD light is pegged on. Not a phone call I'm willing
to take and he or she who called will not want to face me the next morning.
Floppy drive? What floppy drive? By default that's turned on in BIOS, as
is the bus itself (yes, this board allows you to disable one or both) ...
disabling the floppy is a two-step process: disable it on the main screen,
exit out of it, go back in just to see it enabled again, select disable
again and now it sticks.

So you see, I know the motherboard has issues, issues I had hoped
would eventually get fixed through BIOS updates. I gave Intel the benefit
of the doubt and upgraded from 1.1 to 1.3, then 1.5, then 1.7 when I
stopped. And then today to 1.13 ... the quirks are still there (and they
know about them too because I have a rather lengthy thread from them about
these problems.)

With the machine now in full production, and having "settled" if you
will, I'm more inclined to just say 'To hell with it.' And move on. I have
other servers to tend to - like a second RH7.3, also from the same era, but
completely different hardware. All in all, I have 9 servers that need an
upgrade, some more urgent than others. This was the first one, and was
supposed to take all of about 4 hours, not 4 days. :)

Now as for sticking around, that I will. As you pointed out,
there's a possibility that someone else might have a completely different
take on the problem and suggest a different approach, like Lamar.

Ash

--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines



Relevant Pages