Jarod Wilson wrote:
On Thursday 17 April 2008 11:11:40 am John Summerfield wrote:
Jarod Wilson wrote:
[...]
A drawback is that the NIC's driver has to be in the kernel for ip=dhcp
to work. I presume the same applies for this.
Yes, as I understand it, the NIC driver has to be up and running for
netconsole to work (netconsole relies on a polling mode feature that has
to be implemented in each NIC driver), so to make this doable, we'd have
to turn on the in-kernel dhcp server and build all netconsole-capable NIC
drivers into the kernel. I'm guessing chances are slim that'll happen,
but I'm not guessing in any official capacity. :)
I'd be fairly surprised to find ne2000, tulip and such, but (given the
amount of RAM commonly available these days) it might not be so silly to
build, for example, support for Gbit NICs, or for NICs commonly found
built into recent mobos.
Except that I'm pretty sure most of the big NIC vendors really want their
drivers built as modules -- easier to replace them with updated variants that
way to support new hardware before the next dot release. If anything, I think
there's more push to make more things modular than there is to make anything
built-in, without significant justification.
I've reread the documentation; it doesn't say that it does what I'd like
it to do (I don't like manually specifying IP addresses).
netconsole does work as a module, so if I get it all into an initrd it
should work, provided the kernel's dhcp _client_ it available it could
work as I'd like.
It won't get everything, but it might log up the problem I have with the
kernel not finding my disks.
Sounds plausible. I'd say file an RFE, if you haven't already. Now, if
Sounds sensible, but I'd like to propose a solution too, that might
actually work. Or at least point to this thread.
netconsole is a module, can the NIC driver be a module and still get an IP
via the in-kernel dhcp client?
Read all about netconsole:
ls -go \ /usr/share/doc/kernel-doc*/Documentation/networking/netconsole.txt
I might be in better shape now I've had a nap. Just after I wrote the
above, I flicked the wrong switch and thought I'd induced a power
failure in my computer.
ON closer inspection (after a good night's sleep), it became apparent it
was only the screen.
I can't think of any good reason the kernel's dhcp would work, but if
one were in the initrd that would. Probably it could be done faster,
with less risk of side effects etc etc too, all good points.
I think that means the whole thing could be set up in mkinitrd with the
existing (RHEL5) tools. A system administrator would need to be able to
1. Specify the correct NIC driver
2. Specify that netconsole is required
mkinitrd would act on this information, and really early, to reduce the
chance of a kernel startup message being missed
1. Load the NIC driver
2. Run the dhcp client
3. Use all relevant information -
IP address etc
log server address
Is there anything else relevant configurable?
to do the magic required as outlined in netconsole.txt
Back to Ahmed, should it not be possible to construct a procedure that
activates his network and allows remote login, even when his disk needs
a good fsck?
Certainly. The initrd created for use by kdump does quite a bit of this sort
of thing for you already, would likely only need minor extension to include
sshd and start it up...
Ahmed? You still listening? I think this is worthy of an RFE too, maybe
against mkinitrd. If you can come up with a proof of concept, or even a
good proposed solution you'd have the use of it immediately.
busybox has a telnetd applet which could be used if you don't want to
add the sshd software; it's not wonderfully secure, but firewall rules
(external to the machine[s] in question) can help, and can limiting
access to through a VPN and manual procedures at the client site.
If you can't do the prototype, don't let that prevent your filing the
RFE, folk at RH have done similar things before (Anaconda runs ssh and
vnc servers) to it's just a matter of reusing an existing wheel.
It might mean that mkinitrd needs a configuration file that's not
/sbin/installkernel and that would, I think, be a Good Thing. It would
be a good place to name other files mkinitrd uses.
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list
