Les Mikesell wrote:
On 5/2/2011 8:57 AM, Steve Clark wrote:
On 05/02/2011 09:38 AM, Lamar Owen wrote:
On Monday, May 02, 2011 06:48:37 AM Christopher Chan wrote:
biosdevname for nics...bye bye eth0!
Not by default, and according to the release notes only for certain Dell servers ATM.
But, yes, a different way of looking at NICs is coming down the pipe.
It's about
time.
EGADS Why? After working with FreeBSD for ten years it so nice not to
have to worry
is this rl0, vr0, em0, fxp0, bge0, ed0, etc in networking scripts. Why
would you
want to go back to that?
The numbers chosen in the eth? scheme are more or less randomized even
on identical hardware, so it is pretty much impossible to prepare a disk <snip> Anybody know *why*? Is it based on the order of response of the NIC firmware? Certainly, were I writing the code, I'd have based it on the bus address.
mark
On 5/2/2011 9:58 AM, m.roth@5-cent.us wrote:
But, yes, a different way of looking at NICs is coming down the pipe.
It's about
time.
EGADS Why? After working with FreeBSD for ten years it so nice not to
have to worry
is this rl0, vr0, em0, fxp0, bge0, ed0, etc in networking scripts. Why
would you
want to go back to that?
The numbers chosen in the eth? scheme are more or less randomized even
on identical hardware, so it is pretty much impossible to prepare a disk
<snip> Anybody know *why*? Is it based on the order of response of the NIC firmware? Certainly, were I writing the code, I'd have based it on the bus address.
I think the 2.4 kernel did it that way, and was single-threaded during detection. At least I seldom had problems omitting the HWADDR= setting from ifcfg-eth? files and moving disks to a different chassis. My impression was that 2.6 tries to do device detection in parallel to speed up booting and thus makes the order unpredictable. As I recall, there was a bug in early RHEL/Centos 5.x versions where the HWADDR= setting was ignored if it was wrong, fixed in an update that made the interface not come up at all. That made for fun times after the update/reboot on remote machines...
On 05/02/2011 11:07 AM, Les Mikesell wrote:
On 5/2/2011 9:58 AM, m.roth@5-cent.us wrote:
But, yes, a different way of looking at NICs is coming down the pipe.
It's about
time.
EGADS Why? After working with FreeBSD for ten years it so nice not to
have to worry
is this rl0, vr0, em0, fxp0, bge0, ed0, etc in networking scripts. Why
would you
want to go back to that?
The numbers chosen in the eth? scheme are more or less randomized even
on identical hardware, so it is pretty much impossible to prepare a disk
<snip> Anybody know *why*? Is it based on the order of response of the NIC firmware? Certainly, were I writing the code, I'd have based it on the bus address.
I think the 2.4 kernel did it that way, and was single-threaded during detection. At least I seldom had problems omitting the HWADDR= setting from ifcfg-eth? files and moving disks to a different chassis. My impression was that 2.6 tries to do device detection in parallel to speed up booting and thus makes the order unpredictable. As I recall, there was a bug in early RHEL/Centos 5.x versions where the HWADDR= setting was ignored if it was wrong, fixed in an update that made the interface not come up at all. That made for fun times after the update/reboot on remote machines...
Trying to save a few seconds when rebooting a server seems pointless to me. It is not as if this is something that happens with a great deal of frequency.
My $.02
On 5/2/2011 11:19 AM, Steve Clark wrote:
Anybody know *why*? Is it based on the order of response of the NIC firmware? Certainly, were I writing the code, I'd have based it on the bus address.
I think the 2.4 kernel did it that way, and was single-threaded during detection. At least I seldom had problems omitting the HWADDR= setting from ifcfg-eth? files and moving disks to a different chassis. My impression was that 2.6 tries to do device detection in parallel to speed up booting and thus makes the order unpredictable. As I recall, there was a bug in early RHEL/Centos 5.x versions where the HWADDR= setting was ignored if it was wrong, fixed in an update that made the interface not come up at all. That made for fun times after the update/reboot on remote machines...
Trying to save a few seconds when rebooting a server seems pointless to me. It is not as if this is something that happens with a great deal of frequency.
The Linux kernel is also used in laptops/desktops and isn't great at sleep/hibernate (or at least wasn't when this change was introduced), so I can see the value in a fast boot but it would have been nice to have a boot option to use the more predictable 2.4 approach when you need it.
On 5/2/2011 10:25 AM, Les Mikesell wrote:
Trying to save a few seconds when rebooting a server seems pointlessto me
The Linux kernel is also used in laptops/desktops
Fast boots also matter for embedded systems.
We integrate a series of Linux-based boxes made by another company into our system, and one of them reboots in about 9 seconds, while the other version takes about a minute. The latter are a pain to code for, since it means you have to have timeouts that can cope with a device going MIA for over a full minute before they can be talked to again.
centos-bounces@centos.org wrote:
On 5/2/2011 10:25 AM, Les Mikesell wrote:
Trying to save a few seconds when rebooting a server seems pointlessto me
The Linux kernel is also used in laptops/desktops
Fast boots also matter for embedded systems.
+1
So does booting on small, non-PAE hardware. RH wants to drop the embedded world, but the centosplus kernel may yet "save us" from ignominy.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On 5/3/11 8:17 AM, Brunner, Brian T. wrote:
centos-bounces@centos.org wrote:
On 5/2/2011 10:25 AM, Les Mikesell wrote:
Trying to save a few seconds when rebooting a server seems pointlessto me
The Linux kernel is also used in laptops/desktops
Fast boots also matter for embedded systems.
+1
So does booting on small, non-PAE hardware. RH wants to drop the embedded world, but the centosplus kernel may yet "save us" from ignominy.
So you save a second in boot time, then waste half an hour trying to figure out which wire goes to which network interface... Doesn't sound like a win to me unless you only have one NIC.
centos-bounces@centos.org wrote:
On 5/3/11 8:17 AM, Brunner, Brian T. wrote:
centos-bounces@centos.org wrote:
On 5/2/2011 10:25 AM, Les Mikesell wrote:
Trying to save a few seconds when rebooting a server seems pointlessto me
The Linux kernel is also used in laptops/desktops
Fast boots also matter for embedded systems.
+1
So does booting on small, non-PAE hardware. RH wants to drop the embedded world, but the centosplus kernel may yet "save us" from ignominy.
So you save a second in boot time, then waste half an hour trying to figure out which wire goes to which network interface... Doesn't sound like a win to me unless you only have one NIC.
I got one nic on one single-core non-PAE i586 CPU (GEODE LX800) that roars at 800MHz with 1/4GB ram. I got 1 hard drive with DMA, the other "drive" is a CF socket accessed by PIO.
Look up the ETX boards, and consider those with 4 amps max total current. They're used all over the world for process control and special-situation comms systems.
It's headless, access is by ssh; it *must* go from power-on to full operation in 90 seconds, it *should* get there in 30. That includes BIOS startup. Once installed, it does NOT change hardware configuration exception hard-drive-swap for application version upgrade every 2-3 years.
Insert spiffy .sig here: Life is complex: it has both real and imaginary parts.
//me ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
On 5/3/2011 8:49 AM, Brunner, Brian T. wrote:
So you save a second in boot time, then waste half an hour trying to figure out which wire goes to which network interface... Doesn't sound like a win to me unless you only have one NIC.
I got one nic on one single-core non-PAE i586 CPU (GEODE LX800) that roars at 800MHz with 1/4GB ram. I got 1 hard drive with DMA, the other "drive" is a CF socket accessed by PIO.
Look up the ETX boards, and consider those with 4 amps max total current. They're used all over the world for process control and special-situation comms systems.
It's headless, access is by ssh; it *must* go from power-on to full operation in 90 seconds, it *should* get there in 30. That includes BIOS startup. Once installed, it does NOT change hardware configuration exception hard-drive-swap for application version upgrade every 2-3 years.
If you've got one nic, it'a a pretty sure bet that any detection order is going to call it eth0. Add a few more and I think you'll change your opinion, especially with that headless situation where all you can do is move wires until ssh works. That's extra fun when you on the phone and paying by the hour for remote support.
Les Mikesell wrote:
On 5/3/2011 8:49 AM, Brunner, Brian T. wrote:
So you save a second in boot time, then waste half an hour trying to figure out which wire goes to which network interface... Doesn't sound like a win to me unless you only have one NIC.
I got one nic on one single-core non-PAE i586 CPU (GEODE LX800) that roars at 800MHz with 1/4GB ram. I got 1 hard drive with DMA, the other "drive" is a CF socket accessed by PIO.
Look up the ETX boards, and consider those with 4 amps max total current. They're used all over the world for process control and special-situation comms systems.
It's headless, access is by ssh; it *must* go from power-on to full operation in 90 seconds, it *should* get there in 30. That includes BIOS startup. Once installed, it does NOT change hardware configuration exception hard-drive-swap for application version upgrade every 2-3 years.
If you've got one nic, it'a a pretty sure bet that any detection order is going to call it eth0. Add a few more and I think you'll change your opinion, especially with that headless situation where all you can do is move wires until ssh works. That's extra fun when you on the phone and paying by the hour for remote support.
*shrug* I don't have a lot of systems with more than one NIC, but I can always do ethtool eth<whatever> till I see a link detected - that's a matter of a minute or two, unless you've got a *lot* of ports.
mark
On 5/3/2011 9:42 AM, m.roth@5-cent.us wrote:
If you've got one nic, it'a a pretty sure bet that any detection order is going to call it eth0. Add a few more and I think you'll change your opinion, especially with that headless situation where all you can do is move wires until ssh works. That's extra fun when you on the phone and paying by the hour for remote support.
*shrug* I don't have a lot of systems with more than one NIC, but I can always do ethtool eth<whatever> till I see a link detected - that's a matter of a minute or two, unless you've got a *lot* of ports.
We typically have at least 2 active, some with 4 or 5, and the machines mostly come with broadcomm NICs on the motherboard which we ignore and add Intel server cards. So there are always 4 to 8 possibilities and 2 to 5 connected wires with link up and the intel cards have an approximately random chance of starting at eth0 or eth2. We have machines at several locations and like to ship preconfigured disks to meet them, but it doesn't work very well. If we only used one OS I suppose it would be worth building some specialized infrastructure to support it's quirks, but it would be nicer if it just did something predictable. At least most of them go to our larger data centers where we have our own operators present to configure the addresses. These machines generally aren't rebooted for many months at a time and are in load balanced groups so it doesn't matter how long it takes.
Les Mikesell wrote:
On 5/3/2011 9:42 AM, m.roth@5-cent.us wrote:
If you've got one nic, it'a a pretty sure bet that any detection order is going to call it eth0. Add a few more and I think you'll change your opinion, especially with that headless situation where all you can do is move wires until ssh works. That's extra fun when you on the phone and paying by the hour for remote support.
*shrug* I don't have a lot of systems with more than one NIC, but I can always do ethtool eth<whatever> till I see a link detected - that's a matter of a minute or two, unless you've got a *lot* of ports.
We typically have at least 2 active, some with 4 or 5, and the machines mostly come with broadcomm NICs on the motherboard which we ignore and add Intel server cards. So there are always 4 to 8 possibilities and 2 to 5 connected wires with link up and the intel cards have an
<snip> Sorry, I sit corrected: most of our servers do have two NICs, but we only use one, except for clustered systems.
mark
On 05/03/2011 09:25 AM, Les Mikesell wrote:
On 5/3/11 8:17 AM, Brunner, Brian T. wrote:
centos-bounces@centos.org wrote:
On 5/2/2011 10:25 AM, Les Mikesell wrote:
Trying to save a few seconds when rebooting a server seems pointlessto me
The Linux kernel is also used in laptops/desktops
Fast boots also matter for embedded systems.
+1
So does booting on small, non-PAE hardware. RH wants to drop the embedded world, but the centosplus kernel may yet "save us" from ignominy.
So you save a second in boot time, then waste half an hour trying to figure out which wire goes to which network interface... Doesn't sound like a win to me unless you only have one NIC.
But udev keeps these straight across reboots - at least for me.
On 5/3/2011 9:01 AM, Steve Clark wrote:
Trying to save a few seconds when rebooting a server seems pointlessto me
The Linux kernel is also used in laptops/desktops
Fast boots also matter for embedded systems.
+1
So does booting on small, non-PAE hardware. RH wants to drop the embedded world, but the centosplus kernel may yet "save us" from ignominy.
So you save a second in boot time, then waste half an hour trying to figure out which wire goes to which network interface... Doesn't sound like a win to me unless you only have one NIC.
But udev keeps these straight across reboots - at least for me.
Once the hardware address matches in the ifcfg-eth? file, it pins the name to the device, but move a disk to a new chassis or swap a network card and you are fried again.
-
Brunner, Brian T. -
Les Mikesell -
m.roth＠5-cent.us -
Steve Clark -
Warren Young