|
Funky NIC configurations - MAXNICS setting in /etc/rc.d/rc.inet1too low.
Hi,
I have three Linux boxes, one of which is our internet gateway that has 5 NICs in it. I use ultra cheap (a la eBay) PCI PNP NICs based on the Realtek 8139 chip for 10/100 connections and the Realtek 8169 chip for 10/100/1000 traffic. To make a really long, convoluted story short, I've found that the current NIC setup and configuration files in Slackware may be failing to find NICs that may be subsequently assumed to be bad and tossed or otherwise abused. I was going to post a long narrative about I fell onto this but decided to more or less let the script code speak for itself. There are four snippets here; two sets of rc.inet.conf snips and the output of 'ifconfig' after running '/etc/rc.d/rc.inet1' with an rc.inet.conf containing each of the rc.inet.conf snippets. I have populated the stanzas with IP and netmask data so that rc.inet1 script can have something to work with. The IP addresses are completely bogus and are written to 1)be absurd, and 2)to help indicate which interface number a NIC may have been assigned... Anyway, the "short" set is as follows (This is the 'standard' number of stanzas you will find in rc.inet.conf after a new installation of Slackware): /etc/rc.d/rc.inet.conf (Short) Code:
# Config information for eth0:Code:
lo Link encap:Local Loopback Now, the "long" set is as follows: /etc/rc.d/rc.inet.conf (Long) Code:
# Config information for eth0:Code:
eth4 Link encap:Ethernet HWaddr 00:A0:0C:C8:A1:E2 The cards I get are so cheap that I am inclined to toss one without much thought if it doesn't configure on the first try. I'm afraid this is happening with other folks, too. Anyway, if you have a NIC lying around that doesn't seem to work but should, save your working conf file, populate the working conf file with the info above, set MAXNICS in rc.inet1 to 16, restart rc.inet1 and see if ifconfig will be willing to talk about it then. I have another machine whose two interfaces configure to eth0 and eth13 (thirteen). If you remove the 'eth0' NIC the other remains at eth13 after rebooting. I have not the slightest idea why. I wrote to Pat V. and the Slackware folks about this and got no reply. I first noticed all of this with Slack v10 or thereabouts. Googling 'Slackware MAXNICS' gets nothing relevant on the first few pages and this all tells me that I have either stumbled onto something that really deserves some attention or I am re-hashing an old issue that really doesn't. That's it. Nothing broken, just some weirdness...Thanks for listening. Regards, Ken |
Hi,
You should look at the '/etc/udev/rules.d/70-persistent-net.rules'. If you don't change the network rules then the NIC assignment will be the same. BTW, it would be nice if you place your code snippets in vbcode tags, use the # at the top of the reply window. You can still edit your post to place the data within tags. |
Hi, Onebuck,
Thanks for the info about why such things occur. I can't recall with certainty when udev made its first appearance in Slackware (I want to say v11.0) but this NIC business has been a consideration for me since v10. Anyway, the issue I have is that for a user who just wants to upgrade and get on with his/her WORK without having to delve into the innermost Slackware, udev and the stock rc.inet* files effectively make up a broken configuration. It looks like the ability of your system to use a particular NIC is to be determined--without intervention--by some esoteric processing of the NIC's MAC address. Oh, wow, THAT's cool... I like to think I read the CHANGES and HINTS file and I don't recall anything that gently and respectfully suggests: HEY!!!!! When using a system with multiple network interfaces with udev for the first time, You MUST be prepared to edit either '/etc/udev/rules.d/70-persistent-net.rules' or '/etc/rc.d/rc.inet.conf' to reflect or rectify the changes that udev WILL impose on your system. That is, either edit /etc/udev/rules.d/70-persistent-net.rules' to contain NIC info consistent with '/etc/rc.d/rc.inet.conf' or vica versa. If you don't take this step, it is quite possible that your network configuration WILL BREAK INTO TINY, CONFUSING, INFURIATING PIECES and you may put yourself at risk of not liking Patrick Volkerding anymore. And who wants THAT, SlackGeek? A recent example is psmouse in Slackware 12.1. I recently upgraded to a wide LCD panel so I can rotate it (and the console) and see vast amounts of code on one screen. I upgrade to 12.1 to take advantage of whatever improvements may have been made to better enable/handle console and screen rotation. CHANGES and HINTS just mentions in passing that psmouse is not blacklisted anymore. Okay. whatever. And, on reboot, the mouse cursor is gone, gone, gone. I'm sure you can understand a feeling of being blindsided at this point. Imagine bringing home a new car and then reading on page 32 (while you are looking for info about the new braking system) that the manufacturer has decided to change the dimmer function for the lights (for whatever IMPORTANT reason) so that high and low beams work in reverse from what they used to. It probably won't occur to you that this is significant until 19 other drivers have flashed you because you are blinding them with your high beams. Are you going to step up and adjust serenely to the new environment or are you going to find yourself subconsciously calculating the cost of returning the damned car like, RIGHT NOW. People need to be told LOUD and CLEAR about the effects of changes that udev implies. Most are going to run across the 'notice' while looking earnestly at something else and get into (unnecessary, I think) trouble. A few words up front could save a LOT of people a LOT of time late at night when they're trying to fix a SYSTEM broken by the Latest and Greatest Slackware. Oh, yeah, one more thing: the HUGE config file for compiling the kernel ain't. It's the GENERIC config file. I yield the soapbox... Regards, Ken --If I didn't like Slackware so much, it wouldn't annoy me so much... |
Quote:
Quote:
Quote:
Code:
zcat /proc/config.gz > .config |
Yes it is the correct command :)
Really handy, I often use zcat /proc/config.gz | grep -i <something> to check if a feature is enabled or not in the kernel |
Hi,
A lot of people don't read the README.txt files that are provided to the end user. It would be nice if everyone would read them. That way a lot of the problems the user develop wouldn't waste everyone's time if the reference text had been read. PV and team have given the Slackware community a lot of information that should be required reading before any install. EULA anyone? Just in jest so don't get your shorts in a kink. :) |
Quote:
THIS one goes near the top of my "Gotta Keep On A Post-It Note" list. THANK YOU |
Oh, my, my, my.
Evidently some folks have taken what I have been saying as simply a rant. I'll lower my voice so I can make the content of my message a little more clear. '/etc/rc.d/rc.inet.conf' comes with 4 stock stanzas, presumably because so few, if any, users are going to have more than four NICs in their systems. These stanzas are numbered sequentially (0-3). They are unpopulated with IP/Netmask info. If the user supplies the info during the configuration segment of Slackware Setup, the first stanza (eth0, NOT eth13) will be populated with the supplied info. '/etc/rc.d/rc.inet1' comes with a stock MAXNICS setting of 6. When 'rc.inet1' runs it must, as I understand things, find a stanza in '/etc/rc.d/rc.inet.conf' with a number corresponding to the 'eth<#>' interface ID being considered AND the stanza must have meaningful IP/Netmask info (or be set to use DHCP) for the NIC to be properly configured and made usable. Enter udev. The file Onebuck pointed out to me says the 'eth<#>' associated with the interface is calculated using the MAC address as a base. In my own experience, this can range as high as eth13. I suspect it will max at 15 but--who really knows?--it could go to 31 or beyond. Okay? Now, watch... eth13. MAXNICS=6. Four unpopulated stanzas. This is a broken system that will fail to configure a significant percentage of NICs (About 50% of my mine). Yet there is no accommodation in /etc/rc.d/rc.inet.conf and vanishingly little in /etc/rc.d/rc.inet1 for these udev shenanigans and apparently no need to spell all of this out to folks who never had a problem until 'udev' stepped in to make things so much easier and nicer. 'udev', as I understand it, is designed to make your computer more universally plug 'n' play running Linux. IMHO, it is achieving just the opposite. One of the main reasons I've used Slackware for so long is because it tries to stay on the simple side of things and the Slack folks seemed so accessible. 'udev' is not on the simple side of things and it is not, clearly, nearly as accessible. I did a simple file count in /lib/udev, /dev/.udev, /etc/udev. 3036 files. This simplifies things? Come on. Call me pessimistic, but I consider every operating system file to also be a PPOF (Potential Point of Failure). I am clearly underwhelmed by 'udev'. That is not why I'm posting. I am posting because the stock network configuration with 'udev' is broken and I fear that a lot of folks are going to find it easier to go elsewhere rather than fraggle a solution that they will likely decide they should not have been required to fraggle because it's so clear the solution could easily be a part of the setup/initialization routines. You know, increased number of stanzas in 'rc.inet.conf', the ability to populate a stanza out of sequence, increased MAXNICS setting. Or, modify '/etc/udev/rules.d/70-persistent-net.rules' as part of the setup routine so that the NICs are assigned consecutive interface numbers. You know, things like that. RTFM'ing is not going to fix the issue I have been referring to all along, folks. The 'manual' assumes the rc.inet*/udev triad is not a priori broken for a significant percentage of NICs and it is. If Slackware is satisfied with its place in the server/gateway world, OK. If not, this is an issue that deserves more attention than a paragraph or two in the occasional HINTS file. Kernels: When I compiled the 2.6.24.5 (12.1) kernel using the 'huge-SMP' config file, the kernel image was half the size of the stock (pre-compiled) 'huge-SMP' kernel. All I did was turn screen rotation. Then, make; make modules; make modules_install; make install. The kernel failed. To be sure, I compiled it a second time and ditto. I compiled with the 'generic' config file and the kernel was of comparable size to the stock 'huge' kernel. For v12.0, The stock 'huge' kernel is just about twice the size of the stock 'generic' one. I think the config file names for v12.1 have been reversed. I'm still sifting through this one, though... I yield the soapbox... Regards, Ken |
Hi,
In order to get to the 'eth13' you state then you some how had multiple recognitions for the udev to set a rule. How did you break your kernel? What were the errors that you got from the kernel? |
I feel a bit sorry to say this, but Slackware is not for you. You are the first person who manages to add 13 (mostly defective) NICs to a Slackware box while failing to notice that every new card's interface name is incremented by one. The Internet is literally overflowing with helpful hints about how to cure that (beneficial!) udev behaviour by removing it's network configuration file "/etc/udev/rules.d/70-persistent-net.rules". Yet you failed to either look for - or find this information. Or decided to just ignore it and get mad at Slackware.
Slackware's network configuration is not broken. As for kernel compilation - you do not make any sense at all with your story. Check the output of Code:
diff /kernels/hugesmp.s/config /source/k/config-generic-smp-2.6.24.7-smpEric |
Crikey...
Biostar M7NCG400, Athlon 2500+, 3G RAM, Bootable RAID1, Data on RAID5, Sound, Video, NICs. A PC. The first Slackware version I ever installed was 1.1.2. I patched the kernel to 1.1.23 and it stayed up for a year. I patched the kernel in Slack v3.1 once or twice. I've configured and built the kernel in a couple of versions to support IP Masq'ing. Built one to run Slackware on a laptop with Windows 2000. Otherwise, I've used pre-compiled kernels. Now, I just want to rotate the screen. If Pat, et al., had seen fit to click one more time in the Graphics Kernel Configuration area, I wouldn't be messing with this one. I've been doing this long enough to at least try to avoid fixing things that aren't broken. I'm hoping that someone will (someday) get that I'm not talking about strange network interface configurations so much as an apparent lack of interest in the Slack folks to rise up and adjust the system to accommodate the new weirdness brought about by 'udev'. Slackware is just right for me, all in all, and thank you very much. Over the last decade or so I've spent MUCH less time futzing with Slackware Linux than I have Winblows. I had an infatuation with Redhat around RH v5, but, thankfully, I got over it in a very short time. This list isn't right for me. I'm not talking to hackers or even geeks. I'm talking to acolytes. Bye, y'all... Crikey... |
| All times are GMT -5. The time now is 07:00 PM. |