Re: FC2 Grub raid problem, long standing..
by Mogens Kjaer
Jaroslaw Gorny wrote:
...
> With all respect: it's a little bit weird advice because Lilo is not
> supported very well (You cannot choose lilo during install) and we/you
> are promoting grub as default.
You can select lilo during installation if you boot
the installation with "linux lilo".
Mogens
--
Mogens Kjaer, Carlsberg A/S, Computer Department
Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
Email: mk(a)crc.dk Homepage: http://www.crc.dk
19 years, 8 months
Re: FC2 Grub raid problem, long standing..
by Paul Iadonisi
On Fri, 2004-09-03 at 09:16, Hans Kristian Rosbach wrote:
[snip]
> "grub-install /dev/sda" tells me this:
> "/dev/md0 does not have any corresponding BIOS drive"
>
> /dev/md0 is /boot
>
> This bug shows that this is a LONG TIME standing bug:
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484
I have a workaround for this. I usually just edit /etc/mtab and
change the /dev/md* entries with the corresponding /dev/sda*
partitions. Use lsraid to determine what those are (or look at your
/etc/raidtab). Then the 'grub-install /dev/sda' should work. You may
also want to do the same for /dev/sdb. Don't forget to change them back
to what they were or things might get a little confused (df, for one,
will not show the correct information). It's a hack, but it's worked
for me. However, I've never tried booting either of my soft-raid1 disks
without the other one.
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
19 years, 8 months
Re: FC2 Grub raid problem, long standing..
by Jason L Tibbitts III
>>>>> "HKR" == Hans Kristian Rosbach <hk(a)isphuset.no> writes:
HKR> BUT, I cannot boot from any of the two disks since the boot disk
HKR> is the one that died.
I put GRUB on a floppy to cover this situation. I've had machines
where the BIOS will simply not boot from any disk except the first, so
I build a GRUB floppy with a menu entry for each disk that finds /boot
and loads the grub.conf from there.
- J<
19 years, 8 months
Re: FC2 Grub raid problem, long standing..
by Jaroslaw Gorny
On Fri, 03 Sep 2004 15:28:49 +0200
Mogens Kjaer <mk(a)crc.dk> wrote:
> Hans Kristian Rosbach wrote:
> ...
> > This bug shows that this is a LONG TIME standing bug:
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484
>
> I would use lilo instead of grub on a software RAID system.
With all respect: it's a little bit weird advice because Lilo is not
supported very well (You cannot choose lilo during install) and we/you
are promoting grub as default.
Besides, bug is bug, and should be fixed :)
It's not the best idea to advise somebody who found a bug in mozilla to
use konqueror ;)
regards,
Jarek
19 years, 8 months
Re: FC2 Grub raid problem, long standing..
by Hans Kristian Rosbach
> > This bug shows that this is a LONG TIME standing bug:
> > http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484
>
> I would use lilo instead of grub on a software RAID system.
I too would like to use lilo, but unfortunately lilo does
not boot on these computers at all. I think it stops at LI,
but not sure.. Long time since I tried it last.
But why has grub not been fixed for 3+ years?
And what do I do to manually do the grub-install to the disks?
Currently I have no way to boot the box without using the
defective disk to boot into grub menu, then switch sata cable
over to new disk, then boot. It works, but it isn't very nice
in a rack environment =/
-HK
19 years, 8 months
FC2 Grub raid problem, long standing..
by Hans Kristian Rosbach
One of our newly installed boxes had a diskcrash today,
luckily it was in a 2-disk softraid mirror.
Both disks are sata, and I have successfully exchanged
the defective drive with a new one. Raid has been resynced
ok.
BUT, I cannot boot from any of the two disks since the
boot disk is the one that died.
"grub-install /dev/sda" tells me this:
"/dev/md0 does not have any corresponding BIOS drive"
/dev/md0 is /boot
This bug shows that this is a LONG TIME standing bug:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55484
-HK
19 years, 8 months
Re: [FC2] OT - Desert Combat F-16 bug
by Shockwave
On Wed, 2004-09-01 at 12:58, Stephen J Smoogen wrote:
> I would add the c++ and the ncurses from FC1 'just-in-case' to your
> /usr/local/games/fc1glibc tree also. use the directions jakub gave in
> the previous email using rpm2cpio.
>
> I am guessing that these will NOT fix the problem.. but it would be best
> to get those out of the way right now. Nothing better to avoid a
> glibc/kernel finger pointing match as quickly as possible. ;).
>
Done. Now all libraries in use are the ones in my special directory.
Unfortunately, you were right. The problem remains.
> I am heading towards that in my case. My view will be that the server
> code is written expecting something that 2.4.xx gives FPU wise and
> 2.6.xx gives differently. The code is closed sourced? If it isnt it
> would be interesting to find out where it is goofy now.. because it
> might affect other people doing scientific code who assume that their
> code works on 2.4 it will work smae on 2.6
>
I agree that this has implications in areas other than this game server
code, but the game engine code is closed sourced. I could write
Electronic Arts and ask them, however I don't expect they will care to
listen. They never replied to any of my email when I wrote them asking
for non-proprietary information to develop some anti-cheat code to help
the gaming community so I don't expect them to care now when their
proprietary code is involved. I can try, but I think I would need some
fairly strong arguments and perhaps the backing of someone else who
isn't the leader of a competitive gaming team. If it had an impact on
homeland security...maybe they'd help...maybe. ;)
> rpm -ivh --force <kernel.rpm>
>
> Check grub.conf to make sure it didnt break anything.
>
Since the server is co-located in a downtown facility, I'm going to wait
until tomorrow morning to mess with the kernel. If I do something that
hoses the system, it will not only take down the game server but our
TeamSpeak server as well. Considering we have a practice tonight, I
don't think I should risk it.
In the meantime, if anyone is interested in seeing what I am talking
about with the F-16, here are some links to a few images:
http://www.clan-tf20.com/uploads/ps/F-16_bug1.JPG
http://www.clan-tf20.com/uploads/ps/F-16_bug2.JPG
http://www.clan-tf20.com/uploads/ps/F-16_bug3.JPG
When the plane spawns, the entire wheel is underground. If you jump in
and hit the thrusters, it will level itself as you gain speed and start
to act normally. However, as soon as you land and start to come to a
halt, the strut under the right wing sinks down again. If you look
closely, you'll see the strut isn't connected to the wheel on the right
as it is on the left. It's as if the calculation that places the strut
in the center of the wheel is wrong.
By the way, I just want to take a moment to thank everyone who has taken
the time to weigh in on this issue. I know it's not very important to
anyone outside of our gaming community, but I've received some top-notch
help regardless from some very cool people. The Fedora community is
truly a wonderful group of individuals that don't get nearly the amount
of praise they deserve. Thanks again!
As soon as I install the kernel files tomorrow, I'll post my results.
--
|TF20|Shockwave
http://www.clan-tf20.com/
ICQ# 57671167
#taskforce20 irc.gamesurge.net
19 years, 8 months
Re: [FC2] OT - Desert Combat F-16 bug
by Stephen Smoogen
Shockwave wrote:
> On Tue, 2004-08-31 at 14:20, Stephen J Smoogen wrote:
>
>
> /usr/lib/libstdc++.so.5.0.5
>
I would add the c++ and the ncurses from FC1 'just-in-case' to your
/usr/local/games/fc1glibc tree also. use the directions jakub gave in
the previous email using rpm2cpio.
I am guessing that these will NOT fix the problem.. but it would be best
to get those out of the way right now. Nothing better to avoid a
glibc/kernel finger pointing match as quickly as possible. ;).
> Aside from ncurses in the case of the static build using FC1 libraries,
> there don't appear to be any additional open files that have been
> missed. With respect to ncurses, I believe it is only used to create
> the status display of the server output in the shell from which it was
> launched.
>
> I matched all this against the output from ldd and I couldn't find a
> smoking gun. It looks as if Jakub's trick worked flawlessly and
> everything that would've been FC1 specific has been captured and put to
> work. Could this indicate that the kernel is the problem or more
> specifically the implementation of the FPU as you have suggested Alan?
>
I am heading towards that in my case. My view will be that the server
code is written expecting something that 2.4.xx gives FPU wise and
2.6.xx gives differently. The code is closed sourced? If it isnt it
would be interesting to find out where it is goofy now.. because it
might affect other people doing scientific code who assume that their
code works on 2.4 it will work smae on 2.6
> I did try to install the most recent FC1 kernel rpms for
> 2.4.22-1.2199.nptl as well, but it told me a newer kernel version is
> already installed and subsequently aborted the installation. Does
> anyone have any suggestions?
>
rpm -ivh --force <kernel.rpm>
Check grub.conf to make sure it didnt break anything.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 | PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
19 years, 8 months
Re: [FC2] OT - Desert Combat F-16 bug
by Stephen Smoogen
Shockwave wrote:
> On Tue, 2004-08-31 at 11:03, Jakub Jelinek wrote:
>
>>You can e.g. unpack FC1 glibc into some subtree and run the game against
>>that glibc instead.
>>1) make sure vdso=0 is passed on the kernel command line
>>2) mkdir ~/fc1glibc; cd ~/fc1glibc; rpm2cpio ~/glibc-2.3.2-101.4.i686.rpm | cpio -id
>>3) run the game with
>>~/fc1glibc/lib/ld-linux.so.2 --library-path ~/fc1glibc/lib /the/game arguments
>>
>>You can also try booting 2.4 kernel instead of 2.6 one.
>>
>> Jakub
>
>
> Thank you very much for the information. I'm certainly learning a lot
> along the way. :)
>
> I edited grub.conf to use the new parameter, rebooted, then used sysctl
> to verify it took effect. Then I performed the rest of the steps you
> mentioned, started the server, and unfortunately the problem is still
> there. I made sure to try both builds of the executable as well. Aside
> from the possibility the kernel is to blame, could there be other
> libraries native to FC1 that I may need? Perhaps the reason it still
> isn't fixed is because the virtual FC1 environment is not complete in
> some way.
>
Looking at the other libraries you are going to need the ncurses rpm
also installed in that tree.
I would also check via lsof that the program is running with just those
libraries. I would also try the last FC1 2.4.x kernel.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 | PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
19 years, 8 months
