Re: Question about NIC link state initialization
Steve Polyack wrote:
> I was able to "fix" the single-user mode behavior (which I agree,
> isn't necessarily broken) and get it to bring up the links by
> simply patching init(8) to call system("/sbin/ifconfig") before
> prompting for the single-user shell. It works, but I feel dirty.
I see no particular objection to adding a way of running "something"
ahead of the single-user shell, but system(3) is not necessarily the
best mechanism to use for the purpose because it invokes a shell.
It would be both more efficient and more robust to call fork(2) and
exec(3) (or execve(2)) directly.
It would be more general to fork/exec "/etc/rc.single" instead of
"/sbin/ifconfig", expecting "/etc/rc.single" to be an executable
script (with an appropriate shebang line) and ignoring the failure
which would occur if it did not exist. (In your case, instead of
a script, you could make /etc/rc.single a link to /sbin/ifconfig.)
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Question about NIC link state initialization
On 6/30/2011 1:10 AM, per...@pluto.rain.com wrote: Steve Polyack wrote: ... An occaisional fat-finger in /etc/fstab may cause one to end up in single-user mode ... some of these systems have a LOM (lights-out management) controller which shares the system's on-board NICs ... when the system drops out of init(8) and into single-user mode, the links on the interfaces never come up, and therefore the LOM becomes inaccessible. ... all one has to do is run ifconfig to cause the NIC's links to come up ... why do we have to run ifconfig(8) to bring the links up on the attached interfaces? When trying to troubleshoot a problem that was known or suspected to involve the network or its hardware, one might not _want_ the NICs alive. Short of patching init(8) (or perhaps the NIC drivers?), I don't see another way for me to ensure the links come up even when the system drops into single-user mode on boot. Something in /root/.profile, perhaps? That should get run when the single-user shell starts up, if it's started as a "login" shell. This won't work. When the system kicks you into single-user mode, you are prompted to enter the name of a shell or press enter for /bin/sh. If no one is there to press enter, or enter the path to an alternate shell, then a shell never starts. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Question about NIC link state initialization
On 6/30/2011 6:49 AM, Daniel Feenberg wrote:
On Wed, 29 Jun 2011, per...@pluto.rain.com wrote:
Steve Polyack wrote:
... An occaisional fat-finger in /etc/fstab may cause one to
end up in single-user mode ... some of these systems have a LOM
(lights-out management) controller which shares the system's
on-board NICs ... when the system drops out of init(8) and into
single-user mode, the links on the interfaces never come up,
and therefore the LOM becomes inaccessible.
... all one has to do is run ifconfig to cause the NIC's links to
come up ... why do we have to run ifconfig(8) to bring the links
up on the attached interfaces?
When trying to troubleshoot a problem that was known or suspected to
involve the network or its hardware, one might not _want_ the NICs
Well, maybe, but if the system needs to boot into multi-user mode for
the LOM to be available, what is the need for the LOM? At that point
you can do everything you might need through the OS interface. Can I
ask what is the brand of this so-called LOM? Is there any
documentation implying something more useful? Do they describe doing a
bare metal install of an
OS?
They are the Dell Remote Access Controllers (DRACs). Now, they do have
their own dedicated NIC, which we use for anything that really needs the
attention. However, the shared feature saves us a switchport per server
we use it on. When both on-board NICs are cabled (i.e. for lagg(4)
failover), then the DRAC's shared NIC mode *also* supports automatic
failover between both on-board NICs. This doesn't help however if the
operating system never turns on the links to either on-board NIC.
I was able to "fix" the single-user mode behavior (which I agree, isn't
necessarily broken) and get it to bring up the links by simply patching
init(8) to call system("/sbin/ifconfig") before prompting for the
single-user shell. It works, but I feel dirty.
- Steve
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Question about NIC link state initialization
On Wed, 29 Jun 2011, per...@pluto.rain.com wrote: Steve Polyack wrote: ... An occaisional fat-finger in /etc/fstab may cause one to end up in single-user mode ... some of these systems have a LOM (lights-out management) controller which shares the system's on-board NICs ... when the system drops out of init(8) and into single-user mode, the links on the interfaces never come up, and therefore the LOM becomes inaccessible. ... all one has to do is run ifconfig to cause the NIC's links to come up ... why do we have to run ifconfig(8) to bring the links up on the attached interfaces? When trying to troubleshoot a problem that was known or suspected to involve the network or its hardware, one might not _want_ the NICs Well, maybe, but if the system needs to boot into multi-user mode for the LOM to be available, what is the need for the LOM? At that point you can do everything you might need through the OS interface. Can I ask what is the brand of this so-called LOM? Is there any documentation implying something more useful? Do they describe doing a bare metal install of an OS? Daniel Feenberg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Question about NIC link state initialization
Steve Polyack wrote: > ... An occaisional fat-finger in /etc/fstab may cause one to > end up in single-user mode ... some of these systems have a LOM > (lights-out management) controller which shares the system's > on-board NICs ... when the system drops out of init(8) and into > single-user mode, the links on the interfaces never come up, > and therefore the LOM becomes inaccessible. > > ... all one has to do is run ifconfig to cause the NIC's links to > come up ... why do we have to run ifconfig(8) to bring the links > up on the attached interfaces? When trying to troubleshoot a problem that was known or suspected to involve the network or its hardware, one might not _want_ the NICs alive. > Short of patching init(8) (or perhaps the NIC drivers?), I don't > see another way for me to ensure the links come up even when the > system drops into single-user mode on boot. Something in /root/.profile, perhaps? That should get run when the single-user shell starts up, if it's started as a "login" shell. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Question about NIC link state initialization
I have a handful of systems running FreeBSD 8.1-RELEASE. An occaisional fat-finger in /etc/fstab may cause one to end up in single-user mode from time to time. This would normally not be a problem, but some of these systems have a LOM (lights-out management) controller which shares the system's on-board NICs. This works great 99% of the time, but when the system drops out of init(8) and into single-user mode, the links on the interfaces never come up, and therefore the LOM becomes inaccessible. Cue remote-hands at the facility to help us remedy the problem. I've been playing around with this configuration on a local system, and I've noticed that once at a single-user shell, all one has to do is run ifconfig to cause the NIC's links to come up. You don't even have to specify the interface, nor do you have to specify "up". As soon as I hit enter, ifconfig prints the typical interface summary - intermingled in with this are the bold kernel log messages stating "bce0: link state changed to UP" and "bce1: link state changed to UP". So, my question is - why do we have to run ifconfig(8) to bring the links up on the attached interfaces? Shouldn't they come up after the driver discovers and initializes the devices? Keep in mind that I don't even have to pass any arguments (such as "up") to ifconfig. Furthermore, the behavior is exactly the same for bce(4) and em(4). Short of patching init(8) (or perhaps the NIC drivers?), I don't see another way for me to ensure the links come up even when the system drops into single-user mode on boot. - Steve ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
