Re: FC3 install and grub failure on HP Proliant DL380, kernel issue?
by Gene C.
On Monday 13 December 2004 14:08, Sam Hart wrote:
> This occurs during installation. It occurs only on the hardware I
> mentioned, namely:
> * HP Proliant DL380
> * HP SmartArray 5i RAID controller card
Having recently completed beating my head against the wall to get FC3
installed and running on a Proliant DL360 G2 ... have you set the system type
to "Linux"? Untill I realized that this needed to be done, it was a lot of
pain.
If the Dl380 is anything like the DL360 G2, you need to hit F9 during the
initial stuff the system goes through (it is toward the end), this will bring
up configuration of the BIOS stuff where you can select system type. I found
that it needed to be set BEFORE you did the install. Why the Compaq/HP
Proliant needs to know the system type it will be running is a puzzle to me.
--
Gene
19 years, 5 months
Re: FC3 install and grub failure on HP Proliant DL380, kernel issue?
by Sam Hart
On Mon, 2004-12-13 at 12:26 -0600, Otto Haliburton wrote:
> It failed to read the file type. I'm confused though you see grub gets
> installed in the installation process and it is there that stage1 is
> written to the MBR.
This is the end of the installation process. Here grub never is written
to the MBR.
> so when the boot occurs is when stage1 is executed
> to either read stage1.5 or stage2. I'm not sure what you have here.
> And your exclamation is not clear to me. I have not ever gotten this
> sort of thing with GRUB, but it maybe an incompatibility with your
> computer. But I can see where you might have problems having people
> diagnose it because, your explanation and the info supplied doesn't come
> close to anything I have seen with grub.
This occurs during installation. It occurs only on the hardware I
mentioned, namely:
* HP Proliant DL380
* HP SmartArray 5i RAID controller card
When you install FC3 on this hardware (or any Linux distro using a
kernel later than 2.6.5) grub fails to be able to read the stage1 file
from the disk when writing it to the MBR. Thus, grub is not installed,
and the system will not boot.
Specifically on FC3, Anaconda does not mention this failure. Instead,
Anaconda finishes its duties and reports that the install was successful
(ejecting the CD, and waiting for the user to select "Reboot").
Now I know this is a bizarre problem. I have gone back and checked and
have discovered that when this stopped working was immediately after
kernel 2.6.5. I am not sure how much clearer I can make it.
> The first question I have is that you seem to be suppling info from a
> grub-install. Is that true?
Like I said before, this is not grub-install nor any user-typed command.
This is Anaconda. This is during the FC3 installer.
After Anaconda finishes installing the various RPMs on the machine, and
after it finishes setting up various configuration files on the machine,
Anaconda calls grub in batch mode. There, it passes the following to
grub:
root (hd0,0)
install /grub/stage1 d (hd0) /grub/stage2 p (hd0,0)/grub/grub.conf
It is here that the failure occurs. After "root (hd0,0)", grub responds
with:
Filesystem type is ext2fs, partition type is 0x83
(which tells me that grub can, at least, identify the file system).
After the "install" line, grub responds:
Error 2: Bad file or directory type
So grub is able to determine the partition type, but it cannot actually
read any files from that partition (here it is failing on "stage1").
> Anyway, Try to give a clearer picture including the command you are
> executing to get the info you are suppling.
As I said in my original post (and in the subject of the message) this
is during the FC3 install itself. I am not executing any command. This
is the FC3 Anaconda install.
I am pretty certain that it is a kernel issue, like I said before. The
reason I am certain is we have a custom FC2 (soon to be FC3) based
distro which needs to run on this hardware. In essence, I have built FC2
installers using all of the updated FC2 kernels, and this problem only
occurs in kernels after 2.6.5. Since FC3 CD install is 2.6.9, FC3 has
the same problem.
BTW, the image I posted (and the above error) is from a stock FC3
install.
I know it's complicated, feel free to message me (criswell on
freenode.net, criswell4069 on Yahoo! and AIM) for more info.
--
'''''''''''''''''''''''''
.O. Sam Hart, sam(a)progeny.com
..O Progeny Linux Systems, Inc
OOO <http://www.progeny.com/>
19 years, 5 months
Re: FC3 install and grub failure on HP Proliant DL380, kernel issue?
by Otto Haliburton
On Mon, 2004-12-13 at 11:57 -0500, Sam Hart wrote:
> When installing FC3 on an HP Proliant DL380 w/ HP SmartArray 5i
> controller grub fails to install successfully (leaving the system unable
> to boot). In essence, when Anaconda is nearly finished and gets to the
> grub install, grub fails and Anaconda does not report it (instead it
> gives you the "Reboot" screen saying installation is complete).
>
> However, by switching the proper console (5, as I recall) you can see
> the actual error:
> http://hackers.progeny.com/~sam/ZZ-Images/hp_bug.png
>
> As you can see, grub identifies the filesystem type, but cannot actually
> read any files from it (there it is failing to read stage1, but I have
> verified it can't read any files on the system).
>
> Now, I haven't filed this as a bug in Bugzilla yet because this seems to
> be a problem well beyond just FC3. I have verified that other distros
> exhibit the same behavior.
>
> Also, I have isolated it down to some sort of kernel issue. In checking
> with some custom FC2-based distros, I've verified that the problem only
> occurs with kernel versions after 2.6.5. I have tried both stock and
> patched Fedora kernels.
>
> Has anyone else encountered this problem? Note that if you install FC2
> on the machine and then upgrade, everything works except for future Grub
> installs ;-) To see the bug the installer must be running on a kernel
> newer than 2.6.5.
>
> Since this is not really a FC3 bug, does it even have a place in RH's
> bugzilla? FWIW, I would wager that RHEL would have the same problem,
> even though I have not verified it myself.
>
> BTW, since this is grub-legacy, I'm yet to find anyone in the grub
> community who's willing to diagnose it ;-)
>
> Here are the outputs of dmesg/lspci from the machine after a successful
> FC2 install:
> http://hackers.progeny.com/~sam/ZZ-Docs/dmesg.out
> http://hackers.progeny.com/~sam/ZZ-Docs/lspci.out
>
> --
> '''''''''''''''''''''''''
> .O. Sam Hart, sam(a)progeny.com
> ..O Progeny Linux Systems, Inc
> OOO <http://www.progeny.com/>
>
It failed to read the file type. I'm confused though you see grub gets
installed in the installation process and it is there that stage1 is
written to the MBR. so when the boot occurs is when stage1 is executed
to either read stage1.5 or stage2. I'm not sure what you have here.
And your exclamation is not clear to me. I have not ever gotten this
sort of thing with GRUB, but it maybe an incompatibility with your
computer. But I can see where you might have problems having people
diagnose it because, your explanation and the info supplied doesn't come
close to anything I have seen with grub.
The first question I have is that you seem to be suppling info from a
grub-install. Is that true?
Anyway, Try to give a clearer picture including the command you are
executing to get the info you are suppling.
--
Otto Haliburton <ottohaliburton(a)comcast.net>
19 years, 5 months
FC3 install and grub failure on HP Proliant DL380, kernel issue?
by Sam Hart
When installing FC3 on an HP Proliant DL380 w/ HP SmartArray 5i
controller grub fails to install successfully (leaving the system unable
to boot). In essence, when Anaconda is nearly finished and gets to the
grub install, grub fails and Anaconda does not report it (instead it
gives you the "Reboot" screen saying installation is complete).
However, by switching the proper console (5, as I recall) you can see
the actual error:
http://hackers.progeny.com/~sam/ZZ-Images/hp_bug.png
As you can see, grub identifies the filesystem type, but cannot actually
read any files from it (there it is failing to read stage1, but I have
verified it can't read any files on the system).
Now, I haven't filed this as a bug in Bugzilla yet because this seems to
be a problem well beyond just FC3. I have verified that other distros
exhibit the same behavior.
Also, I have isolated it down to some sort of kernel issue. In checking
with some custom FC2-based distros, I've verified that the problem only
occurs with kernel versions after 2.6.5. I have tried both stock and
patched Fedora kernels.
Has anyone else encountered this problem? Note that if you install FC2
on the machine and then upgrade, everything works except for future Grub
installs ;-) To see the bug the installer must be running on a kernel
newer than 2.6.5.
Since this is not really a FC3 bug, does it even have a place in RH's
bugzilla? FWIW, I would wager that RHEL would have the same problem,
even though I have not verified it myself.
BTW, since this is grub-legacy, I'm yet to find anyone in the grub
community who's willing to diagnose it ;-)
Here are the outputs of dmesg/lspci from the machine after a successful
FC2 install:
http://hackers.progeny.com/~sam/ZZ-Docs/dmesg.out
http://hackers.progeny.com/~sam/ZZ-Docs/lspci.out
--
'''''''''''''''''''''''''
.O. Sam Hart, sam(a)progeny.com
..O Progeny Linux Systems, Inc
OOO <http://www.progeny.com/>
19 years, 5 months
Re: Xen in rawhide
by Rik van Riel
On Sun, 12 Dec 2004, Dimitrie O. Paun wrote:
> On Sun, Dec 12, 2004 at 06:26:20PM -0500, Rik van Riel wrote:
>> Any help in getting the network routing to unprivileged domains
>> working again is appreciated. Hmmm, maybe I should publish my
>> TODO list ?
>
> Yes, that would be nice. Having a working Xen setup would be
> more then cool.
Well, at this stage of the project I've only got few items on
my TODO list:
- figure out why network routing to unprivileged domains
does not work right (probably a config option)
- teach grubby to make xen + xenolinux bootable entries
in grub.conf
- get Xen packages into rawhide
- talk with the installer people, to figure out the best
way of allowing anaconda to install a virtual host
Once these things are done, IMHO the Xen development should
happen in the upstream Xen community, which is where I hope
to help out.
One of the things I would like to do there is work on the
light-weight Xen daemon x2d2, which should allow Fedora
developers to run a lighter-weight guest 0, with more memory
remaining for their unprivileged guests - good for developers
who want to run every version of Fedora on their build system. ;)
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
19 years, 5 months
Re: Splash.xpm.gz
by Colin Charles
On Thu, 2004-12-02 at 20:30 -0600, W. Michael Petullo wrote:
> Oops. Let me rephrase my question why is splash.xpm.gz a part of the
> fedora-logos... Well, that makes a little more sense I suppose (obvious
> trademark-type material should not go in GRUB RPM). Sorry for the
> confusion. I suppose /boot/grub/splash.xpm.gz will remain on my system
> while I patiently wait for GRUB 2's Mac support? I'll concede that a
> fedora-logos-grub package would be a bit much.
Yes, you do however have better luck as we release a testing tree of
Fedora Core 3 so get all excited
And as Jeremy said, its probably a good idea to make fedora-logos *not*
arch specific
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you,
then you win." -- Mohandas Gandhi
19 years, 5 months
Re: Splash.xpm.gz
by Jeremy Katz
On Sat, 2004-12-04 at 17:18 +0800, Colin Charles wrote:
> Looks like fedora-logos needs a fix, but the funny thing is, when you
> take a look at the fedora-logos.spec file, it has a nice little stub of
> information that mentions the /boot/grub/splash.xpm.gz bit should be
> ifarch i386, but its not been implemented/changed :)
>
> I guess this is a peril of having fedora-logos as noarch, as opposed to
> making it arch-specific
There's no way to fix it without making fedora-logos arch specific. And
the value in having it as noarch (and thus the reduced build system
load, mirror space requirements, etc) outweigh the few kilobytes it puts
on people's systems who don't need it
Jeremy
19 years, 5 months
Re: Splash.xpm.gz
by Colin Charles
On Thu, 2004-12-02 at 16:39 -0600, W. Michael Petullo wrote:
> Why is boot/grub/splash.xpm.gz included in the kernel RPM? Why is it
> not in the grub RPM instead? The reason I ask is that, when using
> Fedora's kernel, splash.xpm.gz is installed on my PowerPC-based system.
> Yaboot is used instead of grub on PowerPC.
Its fedora-logos-1.1.29-1, I just installed FC-3 on PowerPC (fresh
install) to make sure
Looks like fedora-logos needs a fix, but the funny thing is, when you
take a look at the fedora-logos.spec file, it has a nice little stub of
information that mentions the /boot/grub/splash.xpm.gz bit should be
ifarch i386, but its not been implemented/changed :)
I guess this is a peril of having fedora-logos as noarch, as opposed to
making it arch-specific
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you,
then you win." -- Mohandas Gandhi
19 years, 5 months
Re: Splash.xpm.gz
by Féliciano Matias
Le jeudi 02 décembre 2004 à 16:39 -0600, W. Michael Petullo a écrit :
> Why is boot/grub/splash.xpm.gz included in the kernel RPM?
$ rpm -q -f /boot/grub/splash.xpm.gz
fedora-logos-1.1.29-1
19 years, 5 months
Re: Splash.xpm.gz
by W. Michael Petullo
>> Why is boot/grub/splash.xpm.gz included in the kernel RPM? Why is it
>> not in the grub RPM instead? The reason I ask is that, when using
>> Fedora's kernel, splash.xpm.gz is installed on my PowerPC-based system.
>> Yaboot is used instead of grub on PowerPC.
> on my x86 fc3 system splash.xpm.gz is part of fedora-logos package
> in the development i386 tree splash.xpm.gz is part of fedora-logos packages
> in fact the version of fedora-logos is the same in fc3 as in
> development at the moment.
> are you really really sure /boot/grub/splash.xpm.gz on your system is
> part of the kernel rpm?
Oops. Let me rephrase my question why is splash.xpm.gz a part of the
fedora-logos... Well, that makes a little more sense I suppose (obvious
trademark-type material should not go in GRUB RPM). Sorry for the
confusion. I suppose /boot/grub/splash.xpm.gz will remain on my system
while I patiently wait for GRUB 2's Mac support? I'll concede that a
fedora-logos-grub package would be a bit much.
--
Mike
:wq
19 years, 5 months
