Ryan Steele wrote:
[...]
And I forgot to mention also, that I have to use a custom script to
rewrite the IP in the boot.log, otherwise at the end of the
installation, fai-chboot fails to connect to the server and change the
pxelinux.cfg file to foo.disable. Here is that script:
#!
Ralf Utermann wrote:
Ryan Steele wrote:
[...]
And I forgot to mention also, that I have to use a custom script to
rewrite the IP in the boot.log, otherwise at the end of the
installation, fai-chboot fails to connect to the server and change the
pxelinux.cfg file to foo.disable. Here is that
Ryan Steele wrote:
[...]
Ah, I (think I) forgot to tell you that I had to put 'ip=all' in the
pxelinux.cfg, otherwise you either hang or get kernel panics.
Basically, when we PXE boot with the pxelinux.cfg file set up by
fai-chboot using ip=dhcp, we end up using the /scripts/live shell
On Fri, 12 Dec 2008 13:34:09 +0100, Ralf Utermann
ralf.uterm...@physik.uni-augsburg.de said:
An another point: for the first tests I manually changed the initrd, but
for going in production I prefer make-fai-nfsroot just coming back
with the initrd I need. Maybe I don't see it,
Ralf Utermann wrote:
Ryan Steele wrote:
[...]
Just out of curiosity, what does your udev rule hack look like? I wrote
mine in Perl, which isn't available in the initramfs. I'd be interested
to see your implementation if you care to share it.
it's just a hook sh script that does a
Ryan Steele wrote:
[...]
I suppose that could be the case - hadn't even occurred to me. The
box does have dual on-board NIC's, so that is a viable suggestion.
I'll do some more research on that front, see what comes of it.
Thanks for the suggestion.
I had similar problems with
Hi Ralf,
I had similar problems with FSC RX300S3 systems, which have an
onboard Broadcom 5715 dual port interface. My systems have an
additional Intel quad port card, so I end up with 6 interfaces, and the
one I need for FAI install is never eth0. This was no problem with
my etch environment, I
Ryan Steele wrote:
It may be that a bug needs to be filed against the klibc-utils
package; a binary that hangs after trying one interface is a horrible
implementation - it cripples PXE functionality.
I should probably clarify here - obviously Broadcom takes most of the
blame, as this doesn't
Ralf Utermann wrote:
Ryan Steele wrote:
[...]
I should probably clarify here - obviously Broadcom takes most of the
blame, as this doesn't happen with nicer Intel NICs. But I think
Hi Ryan,
then I don't understand why exactly the same hardware boots
without problems from a Debian
This may or may not be the proper list/outlet for this, so if it's not,
feel free to let me know and I'll pursue it elsewhere, but since it came
up during a FAI installation I'll start here.
I've got a server with a Broadcom network card (a 5721) and I'm using
the tg3 driver, and the box with
This may or may not be the proper list/outlet for this, so if it's not,
feel free to let me know and I'll pursue it elsewhere, but since it came
up during a FAI installation I'll start here.
I've got a server with a Broadcom network card (a 5721) and I'm using
the tg3 driver, and the
Michael Tautschnig wrote:
This may or may not be the proper list/outlet for this, so if it's not,
feel free to let me know and I'll pursue it elsewhere, but since it came
up during a FAI installation I'll start here.
I've got a server with a Broadcom network card (a 5721) and I'm using
[...]
ipconfig is part of the klibc-utils package and most likely just tries to
get an
answer from your DHCP server at that very moment.
Ah, didn't know that's where it came from - thanks for the tip. Re:
'most likely tries...' - really? It doesn't just use the info supplied
to the
13 matches
Mail list logo
