[gentoo-user] Eth0 interface not found - udev that little slut!!!!!

[Nick Khamis]

After updating our systems we lost network connectivity to the
servers. When trying to start net.eth0 we got the following message:

/ib64/rc/net/wpa_supplicant.sh: line 68: _is wireless command not found
/etc/init.d/net.eth0: line 548: _exists command not found

Errror: Interface eth0 does not exist
Ensure that you have loaded the correct kernel modules for your hardware

# lsmod

module used by
tg3 0
lbphy tg3

eth0

flags=4098<broadcast,multicast> mtu 1500
....
interrupt=16


lo

flags=73<UP,LOOPBACK,RUNNING> mtu 16436
inet 127.0.0.1 BROADCAST 255.255.255.0
inet6 ::1 prefixlen 128 scopeid 0x10 <host>


Please excuse me, I am running back and forth from the servers and
typing the error message here. Did our configuration get switched to
IP6? These are our DB servers and why me!!! Why ME!!!!!

Your help is greatly appreciated,

Nick

[Alan Mackenzie]

Hi, Nick.

No, it's not just you, it's happened to pretty much everybody. udev-200
now renames eth0, eth1, .... to something else, dependent upon
complicated rules. In my case eth0 has become p6p1, though many people
seem to have got longer names.

Have a look in /sys/class/net and see if your new name is there. If so,
edit all your config files containing eth0, switching to the new name.

Once you got that done and things work again, take a deep breath and have
a look at the most recent Gentoo news item ($ eselect news read) which
explains it all, more or less. Then decide whether the above is a long
term solution, and if not start reading docs about writing udev rules.

Yes, it's a pain in the backside. But at least with Gentoo, you've a
good chance of fixing things like this quickly.

> Your help is greatly appreciated,

> Nick

--
Alan Mackenzie (Nuremberg, Germany).

[Alan McKinnon]

On 06/04/2013 17:57, Alan Mackenzie wrote:
>> Please excuse me, I am running back and forth from the servers and
>> > typing the error message here. Did our configuration get switched to
>> > IP6? These are our DB servers and why me!!! Why ME!!!!!
> No, it's not just you, it's happened to pretty much everybody. udev-200
> now renames eth0, eth1, ....

Please please PLEASE, for the love of god joseph mary and every other
$DEITY on the planet

STOP SPREADING THIS FUD

It did not happen to pretty much everybody. It happened to people who
blindly updated thignsd and walked away, who did not read the news
announcement, who did not read the CLEARLY WORDED wiki article at
freedesktop.org or alternatively went into mod-induced panic and started
making shit up in their heads.

@Nick:

all you have to do is run eselect news and read what is there. It is all
very clearly worded and makes complete sense when read in conjunction
with the wiki page (link is in the news statement).

Unless you have a very complex setup with multiple NICs (and especially
if they are USB based) you will find that the docs probably cover your
case completely (just add common sense and a bit of understanding about
what udev does on a Linux system).

All that happened is that the thing you used to know as eth0 now has a
different name.
The most important thing you need to remember is you cannot safely
rename that NIC to ethX as this can collide with what the kernel drivers
are trying to do. And that is all that happened here.

--
Alan McKinnon
alan.m...@gmail.com

[Alan Mackenzie]

'Evening, Alan.

On Sat, Apr 06, 2013 at 06:36:07PM +0200, Alan McKinnon wrote:
> On 06/04/2013 17:57, Alan Mackenzie wrote:
> >> Please excuse me, I am running back and forth from the servers and
> >> > typing the error message here. Did our configuration get switched to
> >> > IP6? These are our DB servers and why me!!! Why ME!!!!!
> > No, it's not just you, it's happened to pretty much everybody. udev-200
> > now renames eth0, eth1, ....

> Please please PLEASE, for the love of god joseph mary and every other
> $DEITY on the planet

> STOP SPREADING THIS FUD

> It did not happen to pretty much everybody. It happened to people who
> blindly updated thignsd and walked away, who did not read the news
> announcement, who did not read the CLEARLY WORDED wiki article at
> freedesktop.org or alternatively went into mod-induced panic and started
> making shit up in their heads.

Steady on, old chap! By "it" I was meaning the general inconvenience
all round occasioned by the changes between udev-{197,200}. Not
everybody encountered this. For example Dale, and Walt D. didn't have
to do anything. But pretty much everybody else did.

I was just trying to help Nick get his servers back up asap. I should
imagine having down servers is even more nerve wracking than down
desktops. (Down pillows are OK, though ;-).

I've now got p6p1 instead of eth0. It's irritating, but not irritating
enough for me to be bothered to do anything about it.

> --
> Alan McKinnon
> alan.m...@gmail.com

[Jarry]

On 06-Apr-13 19:10, Alan Mackenzie wrote:
>
>> STOP SPREADING THIS FUD
>
>> It did not happen to pretty much everybody. It happened to people who
>> blindly updated thignsd and walked away, who did not read the news
>> announcement, who did not read the CLEARLY WORDED wiki article at
>> freedesktop.org or alternatively went into mod-induced panic and started
>> making shit up in their heads.
>
> Steady on, old chap! By "it" I was meaning the general inconvenience
> all round occasioned by the changes between udev-{197,200}. Not
> everybody encountered this. For example Dale, and Walt D. didn't have
> to do anything. But pretty much everybody else did.

The problem is, news item is not correct! I followed it
and yet finished with server having old network name (eth0).
Problem was the point 4. in news item, which is not quite clear:

-----
4. predictable network interface names:
If /etc/udev/rules.d/80-net-name-slot.rules is an empty file
or a symlink to /dev/null, the new names will be disabled and
the kernel will do all the interface naming...
-----

Well, in my case 80-net-names-slot.rules was neither empty,
nor symlink to dev null, but FULL OF COMMENTS AND NOTING ELSE,
which basically did the same thing as empty file: disabled
new network names. Unfortunatelly, I found it just after
screwed reboot. But I did everything I found in news item:
checked and verified that file was not symlink to /dev/null
and that it was not empty (1667 bytes does not seem to me
to be empty file).

As I wrote previously, I am pretty sure I never created this
file manually so it must have been created by som previous
udev-version. So I finished up with similar problem as OP:
after rebooting I did not find interface I expected. The
only difference is I expected already interface with new
name, and OP is probably the old one...

So I must add my point to complaining about news item
not beeing quite clear. And this happens quite often...

Jarry
--
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

[Volker Armin Hemmann]

in my case it is still eth0:
ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.178.21 netmask 255.255.255.0 broadcast
192.168.178.255
inet6 fe80::1e6f:65ff:fe87:6f6a prefixlen 64 scopeid 0x20<link>
ether 1c:6f:65:87:6f:6a txqueuelen 1000 (Ethernet)
RX packets 4647305 bytes 6693078055 (6.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2943816 bytes 226871998 (216.3 MiB)
TX errors 0 dropped 1 overruns 0 carrier 0 collisions 0

sys-fs/udev
Available versions: (~)168-r2[1] [M]171-r10 197-r8^t{tbz2}
(~)198-r6^t{tbz2} (~)199-r1^t{tbz2} 200^t{tbz2} **9999^t {acl
action_modeswitch build debug doc edd extras +firmware-loader floppy
gudev hwdb introspection keymap +kmod +openrc +rule_generator selinux
static-libs test}
Installed versions: 200^t{tbz2}(18:30:31
29.03.2013)(firmware-loader gudev hwdb keymap kmod openrc -acl -doc
-introspection -selinux -static-libs)

I did keep net.eth0....

[Jörg Schaible]

You're not alone, this happened for me on all my 4 machines.

>
> So I must add my point to complaining about news item
> not beeing quite clear. And this happens quite often...

- Jörg

[Mick]

Is your eth0 NIC a module (modprobed), or built in the kernel?
--
Regards,
Mick

[Volker Armin Hemmann]

r8169 41918 0
module

[Jörg Schaible]

For me its built in.

- Jörg

[Tanstaafl]

On 2013-04-06 1:50 PM, Jarry <mr.j...@gmail.com> wrote:
> Well, in my case 80-net-names-slot.rules was neither empty,
> nor symlink to dev null, but FULL OF COMMENTS AND NOTING ELSE,

Well... even I know enough to reason that 'empty' in this context means
no UNcommented lines. Comments are just that, and if there are no
UNcommented lines, then nothing is active, hence it is effectively 'empty'.

[Nick Khamis]

Oh dear what did I start!@!@! I'm sorry, I did not know this was a
machine brewing. Don't follow the mailing list all that often. I
updated 3 x86 machines with no problem but the 64 just took a crap...
I agree! Should have read the notes.

N.

[Nick Khamis]

Our net card was also build as a module.... Volker, did you include
your net driver for example in /etc/conf.d/modules?

N.

[Volker Armin Hemmann]

Am 06.04.2013 23:19, schrieb Nick Khamis:
> Our net card was also build as a module.... Volker, did you include
> your net driver for example in /etc/conf.d/modules?

no
I removed the 70-something rules, and did pretty much nothing else.
/etc/udev/rules.d/80-net-name-slot.rules just exists and is full of text.

And nothing changed.

[Michael Hampicke]

I did the same on my machines. Just removed the "70 persistent rules"
file. Nothing changed. I have only one machine left which I will update
soon, but I suspect there also will be no problems.

Some machines have the nic driver as a module, some have it built into
kernel.

[Nick Khamis]

Well I looked into "/sys/class/net" as mentioned by Alan. In there I
see eth0/ eth1/ lo/ and sit0/. Not sure what too look for in (e.g.
eth0/). /sys/class/net/eth0/ifindex says 3. Other files look ok, for
example address (contains mac address if that has not changed...).

N.

[Nick Khamis]

In attempted to delete 70-something rules from /etc/udev/rules.d/ and
it was recreated on boot with the same content. I don't think the
device got renamed since "ifconfig eth0" shows the correct info.

Your help is greatly appreciated,

N.

On 4/6/13, Nick Khamis <sym...@gmail.com> wrote:

[Nick Khamis]

I took a closer look at /etc/udev/70-something-rules-net and
/sys/class/net/eth0/ and all the ATTR (i.e., address, type, dev_id)
line up fine. I did not find a "name" file in /sys/class/net/eth0 however,
name=eth0 in etc/udev/70-something-rules-net.

Ifconfig alone returns nothing. Ifconfig eth0/1 and lo returns the interface
with no tx and rx traffic. And no ip address as set in conf.d/net.

Please help guys. Server room is numbing......

[William Kenworthy]

On 07/04/13 01:10, Alan Mackenzie wrote:
> 'Evening, Alan.
>
> On Sat, Apr 06, 2013 at 06:36:07PM +0200, Alan McKinnon wrote:
>> On 06/04/2013 17:57, Alan Mackenzie wrote:
>>>> Please excuse me, I am running back and forth from the servers and
>>>>> typing the error message here. Did our configuration get switched to
>>>>> IP6? These are our DB servers and why me!!! Why ME!!!!!
>>> No, it's not just you, it's happened to pretty much everybody. udev-200
>>> now renames eth0, eth1, ....
>
>> Please please PLEASE, for the love of god joseph mary and every other
>> $DEITY on the planet
>
>> STOP SPREADING THIS FUD
>
>> It did not happen to pretty much everybody. It happened to people who
>> blindly updated thignsd and walked away, who did not read the news
>> announcement, who did not read the CLEARLY WORDED wiki article at
>> freedesktop.org or alternatively went into mod-induced panic and started
>> making shit up in their heads.
>
> Steady on, old chap! By "it" I was meaning the general inconvenience
> all round occasioned by the changes between udev-{197,200}. Not
> everybody encountered this. For example Dale, and Walt D. didn't have
> to do anything. But pretty much everybody else did.
>
>

I didnt get hit either either, but ("STRONG" hint") ... I use eudev, so
dies Dale and I believe Walt uses mdev. Time for those in server
environments to jump ship?

It may hit us eventually, but at the moment its :)

BillK

[Nick Khamis]

The problem with eudev is that we are using the hardened profile and not sure
if it is part of our source tree. Right now, I just would like to
pinpoint this stubborn
little issue....

I just wanted to mention that name did not change. ifconfig eth0 still pulls up
the interface, and same for ifconfig lo etc... /udev/rules/70-something looks
on the up and up, and same with /sys/class/eth0/1....

Think the security guard outside would not appreciate having me smash
this sticky keyboard in a room full of humming servers? ;)... I'm just being
silly.....

N

[Michael Mol]

On 04/06/2013 08:53 PM, Nick Khamis wrote:
> I took a closer look at /etc/udev/70-something-rules-net and
> /sys/class/net/eth0/ and all the ATTR (i.e., address, type, dev_id)
> line up fine. I did not find a "name" file in /sys/class/net/eth0 however,
> name=eth0 in etc/udev/70-something-rules-net.
>
> Ifconfig alone returns nothing. Ifconfig eth0/1 and lo returns the interface
> with no tx and rx traffic. And no ip address as set in conf.d/net.
>
> Please help guys. Server room is numbing......

/sbin/ip link addr show

That will tell you the names of your interfaces, as they currently exist.

You cannot reliably use 70-persistent-net-rules to assign interfaces
names which the kernel may chose. This means things like 'eth0' and
'wlan0' are unreliable in principle.

Once you know what the interface name will be, rename
/etc/init.d/net.eth0 to /etc/init.d/net.$YOUR_INTERFACE_NAME_HERE ,
remove /etc/runlevels/net.eth0 and create a symlink in /etc/runlevels
pointing at your new /etc/init.d/net.$WHATEVER file.

Then /etc/init.d/net.$WHATEVER restart ... and things should come up, at
least partially. To find anything else that might be broken:

find /etc|grep eth0
find /etc -print0|xargs -0 grep eth0|egrep -v ':#'

and rename 'eth0' there to your new interface name.

I just went through this entire process on one of my machines...but I
wiped all the files out of /etc/udev/rules.d/ and went with udev's new
defaults, rather than set up my on persistent net rules for this
machine. (That's a task for another day.)

Frankly, the process is a PITA...and I'm going to go back to a
persistent-net.rules file in the future; having to go through that
entire process because of a NIC swap or an upstream behavior tweak is
not something I care to have to do.

[Nick Khamis]

I do not have /etc/ip however, I do have /etc/ipmaddr show:

1: lo
inet6 ff02::1
2: sit0
inte6 ff02::1
3: eth0
link 33:33:00:00:00:01
inet6 ff02:1
4: eth1
link 33:33:00:00:00:01
inet6 ff02:1

Too much inte6 for my liking... Did I somehow get rid of ipv4?

N.

[Matthew Marlowe]

Read the news entry - add the designated option to your grub kernel
line - reboot. That will be the simplest solution for now.

Long term, avoid udev upgrades like the plague and test them on
non-critical systems first. Strange that the reason I think us server
people were OK with udev being added to system in the first place was
that it said it would ensure naming of disk and net devices didn't get
mixed up (eth0 would stay eth0, eth1 would stay eth1, sdb woudl remain
sdb, etc between boots)..... and no server should need to use anything
but ethX for network names....yes, I understand the theoretical point
with regard to kernel versus user space names....in real practical use
though, with good hardware and bios, it never is an issue and most of
the linux server software to date has expected ethX for names so the
benefits versus risks of this change are not worthwhile by far, at
least on the server side.

[Michael Mol]

/sbin/ip, not /etc/ip

Those inet6 addresses beginning with ff02 are link-local addresses.
Those are automatically configured on a link simply by the link being up.

Something is failing to configure your interfaces' ipv4 settings.

The culprit is almost certainly somewhere in one of these places, its
lack of being in these places it part of your problem:

/etc/conf.d/net
/etc/init.d/net.*
/etc/runlevels/*/net.*

Otherwise, try those find/grep lines I offered.

[Nick Khamis]

Sorry I did mean /sbin/ip... Long day. Regardless, /sbin/ipmaddr does
now show any ipv4 related material. Other than the network card
driver, what module should I ensure is loaded for ipv4 related stuff.
As for /etc/conf.d/net, net.eth0/eth1 these were untouched and still
point to eth0 and eth1.

As for /sbin/ip. I have no such command.

[Michael Mol]

It's probably not a module issue.

Are these interfaces supposed to be DHCP-configured, or are they
supposed to be statically and locally configured?

If they're supposed to be configured via DHCP, try "dhclient
$interface_name". If they're supposed to be statically configured, try
using ifconfig to configure them manually.

Also, ipmaddr is *not* the command you should be using. That deals
strictly in multicast addresses, not unicast addresses. I presume you're
trying to get your unicast addresses working properly.

ifconfig -a

[Randy Barlow]

On Sat, 6 Apr 2013 22:35:22 -0400
Nick Khamis <sym...@gmail.com> wrote:
> As for /sbin/ip. I have no such command.

I'd recommend installing and becoming familiar with the iproute2
package. I personally find the tools it delivers to be more intuitive
than the older tools, and I *think* they are considered to obsolote some
tools, such as ifconfig.

--
Randy Barlow

[Nick Khamis]

ifconfig -a and ifconfig eth0 etc.. lists the interfaces correctly.
When trying to start net.eth0 the error that struck me as odd was:

/lib64/rc/net/wpa_supplicant.sh: line 68: _is_wireless: command not found

/etc/init.d/net.eth0: line 548: _exists: command not found

Sorry I can't paste stuff directly. I am literally taking phone pics
and communicating through my laptop.

[Nick Khamis]

Can't do nothing right now, no network connection... Don't feel like
burning a livecd and chrooting to jail...

N.

[Stroller]

On 6 April 2013, at 16:57, Alan Mackenzie wrote:
> ...

>> Please excuse me, I am running back and forth from the servers and
>> typing the error message here. Did our configuration get switched to
>> IP6? These are our DB servers and why me!!! Why ME!!!!!
>
> No, it's not just you, it's happened to pretty much everybody. udev-200

> now renames eth0, eth1, .... to something else, dependent upon
> complicated rules. In my case eth0 has become p6p1, though many people
> seem to have got longer names.
>

> ...

> Yes, it's a pain in the backside.

The irony of it is that AIUI these changes were occasioned because the kernel devs refused to make changes which might renumber the network ports for a very small number of users (who were running, at the time, the very latest generation of Dell or HP servers, less than 6 months old).

I believe Linus himself was involved and he said "no, no, no! we cannot make changes which will break things!"

Stroller.

[Michael Mol]

The problem is that the definition of 'correctly' has changed. I don't
know if this is 'correctly' from your perspective of 'this is how I'm
used to seeing it' or 'correctly' from any of the three or more ways one
could use udev. The various defintions of 'correctly' may not overlap.

If they're showing up as eth0/eth1...why? Is it because you disabled
udev's renaming entirely via the kernel command-line parameter? Because
you've done some magic in /etc/udev/rules.d/?

If the former, then OK, this is a different issue. If the latter, be
aware that this isn't a supported configuration! You may very well have
to rename your interfaces before this is done, or let udev rename them
for you.

[Nick Khamis]

Hello Michael,

>> Is it because you disabled udev's renaming entirely via the kernel command-line parameter? >> Because you've done some magic in /etc/udev/rules.d/?

I did not change 70-something contents. I deleted it and let udev regenerate it.

The name in rules.d is net=eth0 and net=eth1 pointing to the correct
mac address.

Your help is greatly appreciated,

[Michael Mol]

On 04/06/2013 11:19 PM, Nick Khamis wrote:
> Hello Michael,
>
>>> Is it because you disabled udev's renaming entirely via the kernel command-line parameter? >> Because you've done some magic in /etc/udev/rules.d/?
>
> I did not change 70-something contents. I deleted it and let udev regenerate it.
>
> The name in rules.d is net=eth0 and net=eth1 pointing to the correct
> mac address.
>
> Your help is greatly appreciated,

Just an FYI...when I removed them, udev did not regenerate them. You
might try removing them again (or moving them to ~root/ for
safekeeping), rebooting, and seeing what happens.

That udev regenerated them for you is very, very weird.

[Joseph]

Are these new udev rules going across all Linux distros or this is something specific to Gentoo?

--
Joseph

[Stroller]

On 7 April 2013, at 07:00, Joseph wrote:
> ...

> Are these new udev rules going across all Linux distros or this is something specific to Gentoo?

I would assume across all distros.

Gentoo generally makes a policy of just packaging whatever upstream offers. In fact, the origins of the ebuild is that it does little more than automating the `configure && make && make install` of compiling upsteam's source.

I don't see why the Gentoo devs would impose this on us, unless it came from upstream.

AIUI the motive for these changes are so that you can unpack an enterprise-type server, the ones with two NICs on the motherboard, and always know which NIC is which. You can then unpack a pallet load of them, and deploy them without any need for determining which is which or for any manual intervention. This is actually pretty important and useful, but I'm not sure this has all been done the best way.

Stroller.

[Neil Bothwick]

On Sat, 06 Apr 2013 17:14:00 -0400, Tanstaafl wrote:

> > Well, in my case 80-net-names-slot.rules was neither empty,
> > nor symlink to dev null, but FULL OF COMMENTS AND NOTING ELSE,
>
> Well... even I know enough to reason that 'empty' in this context means
> no UNcommented lines. Comments are just that, and if there are no
> UNcommented lines, then nothing is active, hence it is effectively
> 'empty'.

But not actually empty. If you are correct, and I suspect you are, then
the news item is poorly worded. No effective content is not the same as
no content at all.


--
Neil Bothwick

... Never say anything more predictive than "Watch this!"

[Neil Bothwick]

On Sun, 07 Apr 2013 09:12:15 +0800, William Kenworthy wrote:

> I didnt get hit either either, but ("STRONG" hint") ... I use eudev, so
> dies Dale and I believe Walt uses mdev. Time for those in server
> environments to jump ship?

Except the problems that udev is trying to avoid are more likely to be
exerienced in server environments. Those running a desktop with a single
network card are never going to be bothered about namespace clashes.


--
Neil Bothwick

Famed tautologist dies of suicide in distressing tragedy

[Marc Joliet]

Am Sat, 06 Apr 2013 23:23:04 -0400
schrieb Michael Mol <mik...@gmail.com>:

Especially considering that the programs for generating them aren't installed
anymore. Look at the output of "qlist -e udev|grep write" and see if you find
them (the programs were /lib/udev/write_{cd,net}_rules). For me grep finds
nothing, so I have to ask: are you *really* using udev-200?

--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[Heiko Zinke]

On 06.04.2013 21:11, Jörg Schaible wrote:
> Jarry wrote:

>
>> On 06-Apr-13 19:10, Alan Mackenzie wrote:
>>>
>>>> STOP SPREADING THIS FUD
>>>
>>>> It did not happen to pretty much everybody. It happened to people
>>>> who
>>>> blindly updated thignsd and walked away, who did not read the news
>>>> announcement, who did not read the CLEARLY WORDED wiki article at
>>>> freedesktop.org or alternatively went into mod-induced panic and
>>>> started
>>>> making shit up in their heads.
>>>
>>> Steady on, old chap! By "it" I was meaning the general
>>> inconvenience
>>> all round occasioned by the changes between udev-{197,200}. Not
>>> everybody encountered this. For example Dale, and Walt D. didn't
>>> have
>>> to do anything. But pretty much everybody else did.
>>

>> The problem is, news item is not correct! I followed it
>> and yet finished with server having old network name (eth0).
>> Problem was the point 4. in news item, which is not quite clear:
>>
>> -----
>> 4. predictable network interface names:
>> If /etc/udev/rules.d/80-net-name-slot.rules is an empty file
>> or a symlink to /dev/null, the new names will be disabled and
>> the kernel will do all the interface naming...
>> -----

>>
>> Well, in my case 80-net-names-slot.rules was neither empty,
>> nor symlink to dev null, but FULL OF COMMENTS AND NOTING ELSE,

>> which basically did the same thing as empty file: disabled
>> new network names. Unfortunatelly, I found it just after
>> screwed reboot. But I did everything I found in news item:
>> checked and verified that file was not symlink to /dev/null
>> and that it was not empty (1667 bytes does not seem to me
>> to be empty file).
>>
>> As I wrote previously, I am pretty sure I never created this
>> file manually so it must have been created by som previous
>> udev-version. So I finished up with similar problem as OP:
>> after rebooting I did not find interface I expected. The
>> only difference is I expected already interface with new
>> name, and OP is probably the old one...
>
> You're not alone, this happened for me on all my 4 machines.
>

Same confusion here, but this paragraph saved my ass
------
In a normal new installation there are no files in /etc/udev/rules.d
and if you haven't edited any files you have in there, you should most
likely backup and delete them all if they don't belong to any packages.
------

So I checked and just removed all files. luckily everything went fine
:)

>>
>> So I must add my point to complaining about news item
>> not beeing quite clear. And this happens quite often...

heiko

[Nick Khamis]

Double checking the udevd version we are running 171. Not sure if we
should be effected yet? I confess, I did a world upgrade and walked
away. For some reason it was stuck on ipr.h for some apache related
package, which was odd since apache is not installed on the machine.
I reset the system and poof!!!! Here I am at the co-location on Sunday
at 9:00am.
Serves me right I guess.....

I double checked. When deleting 70-something rules and restarting the
machine they get regenerated.

Any help is greatly appreciated.

N.

[Nick Khamis]

Manually bringing up eth0 using ifconfig got me up and running. It's
quite shaky though. net.eth0 does not work any more and of course
neither does sshd or any other service that requires net.eth*. Thanks
Michael.

>> If they're supposed to be configured via DHCP, try "dhclient
>> $interface_name". If they're supposed to be statically configured, try
>> using ifconfig to configure them manually.

Now that I have internet connection, I am not sure what my line of
action should be.

N.

[Michael Mol]

On 04/07/2013 10:01 AM, Nick Khamis wrote:
> Manually bringing up eth0 using ifconfig got me up and running. It's
> quite shaky though. net.eth0 does not work any more and of course
> neither does sshd or any other service that requires net.eth*. Thanks
> Michael.
>
>>> If they're supposed to be configured via DHCP, try "dhclient
>>> $interface_name". If they're supposed to be statically configured, try
>>> using ifconfig to configure them manually.
>
> Now that I have internet connection, I am not sure what my line of
> action should be.

Figure out why you're still running udev-171. I suspect your errors come
from having the old version of udev after everything updated around it.

Or switch to mdev or eudev. Your call...but your old udev is probably at
the heart of your problem.

[Neil Bothwick]

On Sun, 7 Apr 2013 09:38:23 -0400, Nick Khamis wrote:

> Double checking the udevd version we are running 171. Not sure if we
> should be effected yet? I confess, I did a world upgrade and walked
> away. For some reason it was stuck on ipr.h for some apache related
> package, which was odd since apache is not installed on the machine.
> I reset the system and poof!!!! Here I am at the co-location on Sunday
> at 9:00am.
> Serves me right I guess.....
>
> I double checked. When deleting 70-something rules and restarting the
> machine they get regenerated.

That's how udev-171 was supposed to work. You need to update to 200 then
delete the file and it will stay deleted.

You really need to read the news item and associated page CAREFULLY, then
work through them CAREFULLY and the upgrade should do just what you want.

udev, or whatever device manager you choose, is a critical system
component, not the sort of thing you should leave to update itself
without reading the instructions, especially on a remote server.


--
Neil Bothwick

MICROSOFT: Most Intelligent Customers Realize Our Software Only Fools
Teenagers

[Michael Mol]

Are you using 802.1x or wireless on that machine? If not, I can't think
of a reason you'd need it, outside of it being a hard dependency of some
other package.

On 04/07/2013 10:22 AM, Nick Khamis wrote:
> Installing wpa_supplicant got the network scripts working again. Not
> sure why..... Does anyone know why we need wpa_supplication now?

>
> On 4/7/13, Nick Khamis <sym...@gmail.com> wrote:

>> I am upgrading each package (25) one by one, and leaving the meat and
>> potatoes (udev) for last. I am really sorry about the noise guys and
>> gals. It's been a while since I had such a scare....
>> There are 4500 people coming into work tomorrow morning, and this
>> machine also happens to be our LDAP server.
>>
>> N.

[Nick Khamis]

Installing wpa_supplicant got the network scripts working again. Not
sure why..... Does anyone know why we need wpa_supplication now?

On 4/7/13, Nick Khamis <sym...@gmail.com> wrote:
> I am upgrading each package (25) one by one, and leaving the meat and
> potatoes (udev) for last. I am really sorry about the noise guys and
> gals. It's been a while since I had such a scare....
> There are 4500 people coming into work tomorrow morning, and this
> machine also happens to be our LDAP server.
>
> N.
>
> On 4/7/13, Neil Bothwick <ne...@digimed.co.uk> wrote:

[Nick Khamis]

I am upgrading each package (25) one by one, and leaving the meat and
potatoes (udev) for last. I am really sorry about the noise guys and
gals. It's been a while since I had such a scare....
There are 4500 people coming into work tomorrow morning, and this
machine also happens to be our LDAP server.

N.

On 4/7/13, Neil Bothwick <ne...@digimed.co.uk> wrote:

[Nick Khamis]

No... I'm stumped. I really don't want it in there either... I will
attempt removing it once finished updating the system.

N.

[Neil Bothwick]

On Sun, 7 Apr 2013 10:20:02 -0400, Nick Khamis wrote:

> I am upgrading each package (25) one by one, and leaving the meat and
> potatoes (udev) for last. I am really sorry about the noise guys and
> gals. It's been a while since I had such a scare....

You should do udev first, that way if it breaks you have the maximum
amount of time to get things working again. Not that I'm a pessimist...

PS Please don't top-post, it is frowned upon on this list.


--
Neil Bothwick

the sum of all human intelligence is constant, only the number of humans
increases.

[Pandu Poluan]

AFAICT, on-board NICs have sequential MAC Adresses, with the one labeled "Port 1" has the smallest MAC Address. So far, *all* Linux distros I've used on a server will reliably name "Port X" as "eth$((X-1))". So it's never a puzzle as to which port bears which "ethX" moniker.

The new naming scheme, however, is much less intuitive. Where originally I just immediately use eth0, now I have to enumerate the monikers first, because even between servers of the same model (let's say, HP's DL360 G7), the PCI attachment point might differ.

Granted, Linux SysAdmins *are* expected to understand the vagaries of Linux, but it's still a great inconvenience.

Rgds,
--

[Nick Khamis]

>> You should do udev first, that way if it breaks you have the maximum
>> amount of time to get things working again. Not that I'm a pessimist...

>> PS Please don't top-post, it is frowned upon on this list.

Makes sense and I apologize for the top posts. Have everything up to
date with udev in the crosshairs. That being said:

1) Network drivers are compiled as modules
2) I deleted the contents of /etc/udev/rules.d (i.e, 70-something....)
3) Removed udev-postmount from runlevels.

That should be sufficient to hold onto the old names eth0/1....?

Thanks for all your help.

N.




On 4/7/13, Neil Bothwick <ne...@digimed.co.uk> wrote:

[Tanstaafl]

On 2013-04-07 6:55 AM, Neil Bothwick <ne...@digimed.co.uk> wrote:
> On Sat, 06 Apr 2013 17:14:00 -0400, Tanstaafl wrote:
>
>>> Well, in my case 80-net-names-slot.rules was neither empty,
>>> nor symlink to dev null, but FULL OF COMMENTS AND NOTING ELSE,
>>
>> Well... even I know enough to reason that 'empty' in this context means
>> no UNcommented lines. Comments are just that, and if there are no
>> UNcommented lines, then nothing is active, hence it is effectively
>> 'empty'.
>
> But not actually empty. If you are correct, and I suspect you are, then
> the news item is poorly worded. No effective content is not the same as
> no content at all.

Oh, I agree that it was poorly worded, I was just pointing out that it
was kind of silly to take quite it so literally...

Every sysadmin knows (or should know) that a config file full of nothing
but comments isn't going to do *anything* other than provide whatever
defaults the program is designed to use in such a case.

[Mick]

On Sunday 07 Apr 2013 17:00:24 Nick Khamis wrote:
> >> You should do udev first, that way if it breaks you have the maximum
> >> amount of time to get things working again. Not that I'm a pessimist...
> >>
> >> PS Please don't top-post, it is frowned upon on this list.
>
> Makes sense and I apologize for the top posts. Have everything up to
> date with udev in the crosshairs. That being said:
>
> 1) Network drivers are compiled as modules
> 2) I deleted the contents of /etc/udev/rules.d (i.e, 70-something....)
> 3) Removed udev-postmount from runlevels.
>
> That should be sufficient to hold onto the old names eth0/1....?

If they are built as modules, then I would expect the old naming convention to
be retained - unless you had renamed them in a different order in your 70-
something... rules.

This is not all though. Check the page:

http://wiki.gentoo.org/wiki/Udev/upgrade

You also need CONFIG_DEVTMPFS=y in your kernel and if there is a /dev entry in
your /etc/fstab, then it must have devtmpfs as its fs type. Most
installations would not have such an entry in /etc/fstab - but better check to
be safe.
--
Regards,
Mick

[Nick Khamis]

Oh yes! The devtempfs is enabled in the kernel, and no entry in fstab.
Forgot to mention that.

N.

[Jarry]

True, but only if admin checks content of the file. The lazy one (me)
just checked size (ls -l /etc/udev/rules.d/80-net-name-slot.rules),
found it is not linked to /dev/null and the file size is 1667 bytes,
and satisfied that he checked all what was in news-item rebooted...

Devs should not over-estimate users. Or I put it other way:
every news-item should be fool-proof (if it is possible)...

Jarry
--
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

[Joseph]

On 04/07/13 22:35, Pandu Poluan wrote:

[snip]

> AFAICT, on-board NICs have sequential MAC Adresses, with the one
> labeled "Port 1" has the smallest MAC Address. So far, *all* Linux
> distros I've used on a server will reliably name "Port X" as
> "eth$((X-1))". So it's never a puzzle as to which port bears which
> "ethX" moniker.
>
> The new naming scheme, however, is much less intuitive. Where
> originally I just immediately use eth0, now I have to enumerate the
> monikers first, because even between servers of the same model (let's
> say, HP's DL360 G7), the PCI attachment point might differ.
>
> Granted, Linux SysAdmins *are* expected to understand the vagaries of
> Linux, but it's still a great inconvenience.
>
> Rgds,
> --

In my opinion this new udev-200 naming port is a big screw-up; I wouldn't be surprised if few months down the road we will go back to old naming because of
misunderstandings.

--
Joseph

[Tanstaafl]

On 2013-04-07 12:11 PM, Mick <michael...@gmail.com> wrote:
> if there is a /dev entry in your /etc/fstab, then it must have
> devtmpfs as its fs type. Most installations would not have such an
> entry in /etc/fstab - but better check to be safe.

I've heard this many times, but can anyone explain just *when* you would
want or need a /dev entry in your fstab?

[Mick]

Only to state the obvious:

When your /dev resides in a separate partition.

--
Regards,
Mick

[Grant Edwards]

On 2013-04-07, Tanstaafl <tans...@libertytrek.org> wrote:
> On 2013-04-07 6:55 AM, Neil Bothwick <ne...@digimed.co.uk> wrote:
>> On Sat, 06 Apr 2013 17:14:00 -0400, Tanstaafl wrote:
>>
>>>> Well, in my case 80-net-names-slot.rules was neither empty,
>>>> nor symlink to dev null, but FULL OF COMMENTS AND NOTING ELSE,
>>>
>>> Well... even I know enough to reason that 'empty' in this context means
>>> no UNcommented lines. Comments are just that, and if there are no
>>> UNcommented lines, then nothing is active, hence it is effectively
>>> 'empty'.
>>
>> But not actually empty. If you are correct, and I suspect you are, then
>> the news item is poorly worded. No effective content is not the same as
>> no content at all.
>
> Oh, I agree that it was poorly worded, I was just pointing out that it
> was kind of silly to take quite it so literally...

OK, so parts of the news item are not to be taken literally, and other
parts are. Perhaps it would be wise to mark the sections so we can
tell the difference? ;)

> Every sysadmin knows (or should know) that a config file full of
> nothing but comments isn't going to do *anything* other than provide
> whatever defaults the program is designed to use in such a case.

It's entirely possible for udev (or any other program) to check
whether a file is empty or not and behave differently depending on
that test. And if it is explicitly stated that something depends on a
file being "empty", that's what I assume was indended. Of course it's
possible to determine via experimentation that "nothing but comments"
produces the same behavior as "empty". Of course we all figured that
out after we realized that udev wasn't behaving as was described in
the news entry and started reading other documentation.

--
Grant Edwards grant.b.edwards Yow! PEGGY FLEMMING is
at stealing BASKET BALLS to
gmail.com feed the babies in VERMONT.

[Tanstaafl]

On 2013-04-07 9:38 AM, Nick Khamis <sym...@gmail.com> wrote:
> Double checking the udevd version we are running 171. Not sure if we
> should be effected yet? I confess, I did a world upgrade and walked
> away.

Well, hopefully you learned a valuable lesson. I cannot even *fathom*
the *idea* of doing a world update on a remote server without going
through each and every package to be updated, reading every news item I
could find, etc etc ad nauseum, and googling if any systems critical to
booting (like udev) are involved.

For me, world updates are usually very small because I keep my server
updated weekly. I generally sync every day, checking what packages are
available, then once that update has been available/unchanged for 3 or 4
days, I update it... waiting even a bit longer (and googling for issues)
if the package(s) are critical system packages.

Admittedly, doing it this way manually wouldn't work for anyone managing
more than a few servers, although I imagine it could be scripted by one
with the knowledge/desire.

But seriously - there has been so much noise about the whole udev
situation in the last months (6+?) that you should really be kicking
yourself that you did that.

[Tanstaafl]

On 2013-04-07 12:18 PM, Jarry <mr.j...@gmail.com> wrote:
> On 07-Apr-13 18:03, Tanstaafl wrote:
>> Every sysadmin knows (or should know) that a config file full of nothing
>> but comments isn't going to do *anything* other than provide whatever
>> defaults the program is designed to use in such a case.
>
> True, but only if admin checks content of the file. The lazy one (me)
> just checked size (ls -l /etc/udev/rules.d/80-net-name-slot.rules),
> found it is not linked to /dev/null and the file size is 1667 bytes,
> and satisfied that he checked all what was in news-item rebooted...
>
> Devs should not over-estimate users. Or I put it other way:
> every news-item should be fool-proof (if it is possible)...

Or put another way, lazy devs should simply admit that they run the risk
of making silly mistakes like this because of their laziness.

Failure to check the actual contents of a file critical to system
operation (whether booting or network) when it is specifically mentioned
in release notes (or a news item) is just asking for precisely these
kinds of problems. I'm sympathetic with Nick, but I don't feel sorry for
him, he did this to himself.

Hell, I'm *still* analyzing things before pulling the trigger, and I'm
100% certain that I've got a handle on what to do now (after lots of
reading and asking questions here)...

[Tanstaafl]

On 2013-04-07 1:00 PM, Grant Edwards <grant.b...@gmail.com> wrote:
> OK, so parts of the news item are not to be taken literally, and other
> parts are. Perhaps it would be wise to mark the sections so we can
> tell the difference? ;)

Context is everything.

You can't equate

"Remove the udev-postmount init script from your runlevels."

with

"If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a
symlink to /dev/null,"

The first can obviously be taken quite literally, while the second just
might actually require a tiny bit of thought - ie, 'hmmm, wonder if they
mean literally 'empty', or just nothing in it that does anything?

Imnsho, the latter is obviously what was meant, while just as obviously
a truly *empty* file would do the same thing as one with no *effective*
content.

[Nick Khamis]

After psyching myself and everyone else for the udev 200 update, it
failed on compile phase! We are using hardened server, and error
message (which I am transferring over manually) is:

The specific snippet of code:
die econf failed


This thing is not going easy....


N.

[Michael Hampicke]

Am 07.04.2013 16:32, schrieb Nick Khamis:
> No... I'm stumped. I really don't want it in there either... I will
> attempt removing it once finished updating the system.
>
> N.
>
> On 4/7/13, Michael Mol <mik...@gmail.com> wrote:
>> Are you using 802.1x or wireless on that machine? If not, I can't think
>> of a reason you'd need it, outside of it being a hard dependency of some
>> other package.
>>

Mike is right, if it's not a dep of another ebuild, you don't need
wpa_supplicant. I just upgraded udev to 200 on the last remote box
(which is always a bit of a thrill after typing reboot <return> :-) ).
As expected, eth0 came up, everything works fine, wpa_supplicant is not
installed.

[Nick Khamis]

I just did got udev updated. Did all the steps in the news:

1. tempfs in kernel
2. nothing in /etc/udev/rules.d
3. removed udev-postmount from runlevel
4) check fstab for the /tmp....

And it changed!!!!!

This is the pits dude...

N.

[Tanstaafl]

On 2013-04-07 1:48 PM, Nick Khamis <sym...@gmail.com> wrote:
> I just did got udev updated. Did all the steps in the news:
>
> 1. tempfs in kernel
> 2. nothing in /etc/udev/rules.d
> 3. removed udev-postmount from runlevel
> 4) check fstab for the /tmp....
>
> And it changed!!!!!

WHAT changed???

[Nick Khamis]

Ooops I should have been more specific the net cards are not esp5s0
and esp6s0..... And the drivers for the network cards are built as
modules.

N

On 4/7/13, Tanstaafl <tans...@libertytrek.org> wrote:

[Nick Khamis]

Is changing it back to eth0 and eth1 like pulling teeth?

N

On 4/7/13, Nick Khamis <sym...@gmail.com> wrote:

[Nick Khamis]

For those that have an error compiling udev 200:

# emerge -1 XML-Parser
# perl-cleaner --all

There was not mention of this in the news. Nor will the package pull
them in as a
dependency.

N.

[Michael Hampicke]

Am 07.04.2013 20:08, schrieb Nick Khamis:
> For those that have an error compiling udev 200:
>
> # emerge -1 XML-Parser
> # perl-cleaner --all
>
> There was not mention of this in the news. Nor will the package pull
> them in as a
> dependency.
>
> N.
>
> On 4/7/13, Nick Khamis <sym...@gmail.com> wrote:
>> Is changing it back to eth0 and eth1 like pulling teeth?
>>
>> N
>>
>> On 4/7/13, Nick Khamis <sym...@gmail.com> wrote:
>>> Ooops I should have been more specific the net cards are not esp5s0
>>> and esp6s0..... And the drivers for the network cards are built as
>>> modules.

This is most likely related to your previous world update. Maybe there
was an update for perl, after which you did not run perl-cleaner.

[Mick]

On Sunday 07 Apr 2013 18:48:02 Nick Khamis wrote:
> I just did got udev updated. Did all the steps in the news:
>
> 1. tempfs in kernel

I guess you're talking about: CONFIG_DEVTMPFS=y


> 2. nothing in /etc/udev/rules.d

That's OK.

> 3. removed udev-postmount from runlevel

Good.

> 4) check fstab for the /tmp....

I guess again you mean: /dev


> And it changed!!!!!

If your NICs changed their name then most likely the drivers were built in the
kernel and not as modules.

If so, you have following 3 options:

1. Go with the new names. Change your entries in /etc/conf.d/net to use the
new names as these are shown here:

ls -la /sys/class/net/

and then change the symlinks in your /etc/init.d/from the old interface names
to the new:

cd /etc/init.d
rm net.eth0 && ln -s net.lo net<New_Name>
ls -l net.<New_Name>
lrwxrwxrwx 1 root root 6 Mar 31 11:51 /etc/init.d/net.enp11s0 -> net.lo

the last line is what mine shows, for what used to be net.eth0 on *my*
machine.


2. You categorically don't want the new 'predictable' names and you want to
stay as you were:

Rebuild your kernel with the drivers for the NICs as modules. The kernel
*should* rename them to what they were before. I can't vouch for this, but
NICs which are not built in here were not renamed by udev.


3. You categorically don't want the new 'predictable' names and you want to
stay as you were, but you don't want to rebuild the kernel:

3.1 Create a new empty file:

touch /etc/udev/rules.d/80-net-name-slot.rules

and reboot. The kernel will rename the interfaces hopefully as they were
before.

3.2 Instead of creating the empty 80-net-name-slot.rules file, append this
option in your grub kernel line:

net.ifnames=0


I hope some of the above will work for you and you'll be able to get back
where you were a couple of days ago.
--
Regards,
Mick

[Nick Khamis]

Oooops, I meant option 3.1:

3.1 Create a new empty file:

touch /etc/udev/rules.d/80-net-name-slot.rules

and reboot. The kernel will rename the interfaces hopefully as they were
before.

N.

On 4/7/13, Nick Khamis <sym...@gmail.com> wrote:

> I went into the kernel, rebuilt it with no changes (network driver was
> already built as a module), rebooted and nothing changed. Option 2
> worked ok.
>
> As for the x86 machines, they were also updated blindly (94 packages
> udev 200) included... 70-presistent file in rules.d and no problems.
> eth0 was still eth0...

>
> N.
>
> On 4/7/13, Michael Hampicke <gento...@hadt.biz> wrote:

[Nick Khamis]

I went into the kernel, rebuilt it with no changes (network driver was
already built as a module), rebooted and nothing changed. Option 2
worked ok.

As for the x86 machines, they were also updated blindly (94 packages
udev 200) included... 70-presistent file in rules.d and no problems.
eth0 was still eth0...

N.

On 4/7/13, Michael Hampicke <gento...@hadt.biz> wrote:

[Mick]

On Sunday 07 Apr 2013 19:48:13 Nick Khamis wrote:
> Oooops, I meant option 3.1:
>
> 3.1 Create a new empty file:
>
> touch /etc/udev/rules.d/80-net-name-slot.rules
>
> and reboot. The kernel will rename the interfaces hopefully as they were
> before.
>
> N.
>
> On 4/7/13, Nick Khamis <sym...@gmail.com> wrote:
> > I went into the kernel, rebuilt it with no changes (network driver was
> > already built as a module), rebooted and nothing changed. Option 2
> > worked ok.
> >
> > As for the x86 machines, they were also updated blindly (94 packages
> > udev 200) included... 70-presistent file in rules.d and no problems.
> > eth0 was still eth0...
> >
> > N.

Kewl! If all interfaces are as expected and the servers are up and running,
you can hopefully enjoy what's left of your weekend. :-)

Interesting to note that having the drivers as modules does not work on your
machines. Hmm ... I wonder if there is a difference between cards on the mobo
and cards on USB/cardbus and the like.

I am getting to hate udev's logic more and more with each update ...
--
Regards,
Mick

[Neil Bothwick]

On Sun, 07 Apr 2013 12:03:21 -0400, Tanstaafl wrote:

> > But not actually empty. If you are correct, and I suspect you are,
> > then the news item is poorly worded. No effective content is not the
> > same as no content at all.
>
> Oh, I agree that it was poorly worded, I was just pointing out that it
> was kind of silly to take quite it so literally...

These are computers we are dealing with, literally interpretation is the
norm. If the news item meant "devoid of actionable content", that is what
it should have said.

> Every sysadmin knows (or should know) that a config file full of
> nothing but comments isn't going to do *anything* other than provide
> whatever defaults the program is designed to use in such a case.

You do realise that you have just described the file as "full" so it
cannot be considered empty :)


--
Neil Bothwick

Last words of a Windows user: = Why does that work now?

[Neil Bothwick]

On Sun, 7 Apr 2013 19:14:36 +0100, Mick wrote:

> Rebuild your kernel with the drivers for the NICs as modules. The
> kernel *should* rename them to what they were before. I can't vouch
> for this, but NICs which are not built in here were not renamed by udev.

Where does this come from? Udev renames the interfaces when it
initialises them, what difference does it make where it loads the driver
code from? I am seeing consistent behaviour across machines with drivers
built in and as modules.


--
Neil Bothwick

If we aren't supposed to eat animals, why are they made of meat?

[Neil Bothwick]

On Sun, 7 Apr 2013 14:04:35 -0400, Nick Khamis wrote:

> Is changing it back to eth0 and eth1 like pulling teeth?

No, it's like reading the news item. Either symlink the file mentioned
to /dev/null or add the kernel boot option it recommends. The default is
the new behaviour, as you should expect. Why would they change the
behaviour because they consider the old way broken, then default to the
old way?


--
Neil Bothwick

Ralph's Observation - It is a mistake to allow any mechanical object
to realize that you are in a hurry.

[Neil Bothwick]

On Sun, 07 Apr 2013 13:16:45 -0400, Tanstaafl wrote:

> "If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a
> symlink to /dev/null,"
>
> The first can obviously be taken quite literally, while the second just
> might actually require a tiny bit of thought - ie, 'hmmm, wonder if
> they mean literally 'empty', or just nothing in it that does anything?

Even if that were reasonable, how are you supposed to know which they
mean? You guessed right and now have the benefit of hindsight, that does
not justify ambiguous or inaccurate instructions.


--
Neil Bothwick

"Unthinking respect for authority is the greatest enemy of truth."
(Albert Einstein)

[William Hubbs]

On Sun, Apr 07, 2013 at 02:04:35PM -0400, Nick Khamis wrote:
> Is changing it back to eth0 and eth1 like pulling teeth?

No, it isn't. There are several ways to name your interfaces. They are
discussed on the freedesktop.org wiki page linked in the news item.

William

[Mick]

On Sunday 07 Apr 2013 21:25:48 Neil Bothwick wrote:
> On Sun, 7 Apr 2013 19:14:36 +0100, Mick wrote:
> > Rebuild your kernel with the drivers for the NICs as modules. The
> > kernel *should* rename them to what they were before. I can't vouch
> > for this, but NICs which are not built in here were not renamed by udev.
>
> Where does this come from? Udev renames the interfaces when it
> initialises them, what difference does it make where it loads the driver
> code from? I am seeing consistent behaviour across machines with drivers
> built in and as modules.

I don't, and recall reading about this somewhere (was it this M/L? ) but can't
find it right now.

I have noticed that PCI installed NICs get renamed by udev, while extreneous
NICs, e.g. USB based devices retain their old naming convention.

In my case the non-MoBo cards and devices happened to have drivers installed
as modules - they were not renamed. Perhaps I drew an erroneous correlation.
--
Regards,
Mick

[Neil Bothwick]

On Sun, 7 Apr 2013 22:20:51 +0100, Mick wrote:

> > Where does this come from? Udev renames the interfaces when it
> > initialises them, what difference does it make where it loads the
> > driver code from? I am seeing consistent behaviour across machines
> > with drivers built in and as modules.
>
> I don't, and recall reading about this somewhere (was it this M/L? )
> but can't find it right now.

I've read suggestions, but no evidence.

> I have noticed that PCI installed NICs get renamed by udev, while
> extreneous NICs, e.g. USB based devices retain their old naming
> convention.
>
> In my case the non-MoBo cards and devices happened to have drivers
> installed as modules - they were not renamed. Perhaps I drew an
> erroneous correlation.

I have a couple of devices that are not renamed, the drivers are modules
but they also give nothing useful when running the udevadm command from
the news item. I think it is more likely that the lack of renaming is due
to udev not being able to find a unique name to give them.


--
Neil Bothwick

The law of Probability Dispersal decrees that whatever it is that hits
the fan will not be evenly distributed.

[Pandu Poluan]

On Apr 7, 2013 8:13 AM, "William Kenworthy" <bi...@iinet.net.au> wrote:
>
> On 07/04/13 01:10, Alan Mackenzie wrote:
> > 'Evening, Alan.
> >
> > On Sat, Apr 06, 2013 at 06:36:07PM +0200, Alan McKinnon wrote:
> >> On 06/04/2013 17:57, Alan Mackenzie wrote:
> >>>> Please excuse me, I am running back and forth from the servers and
> >>>>> typing the error message here. Did our configuration get switched to
> >>>>> IP6? These are our DB servers and why me!!! Why ME!!!!!
> >>> No, it's not just you, it's happened to pretty much everybody.  udev-200
> >>> now renames eth0, eth1, ....
> >
> >> Please please PLEASE, for the love of god joseph mary and every other
> >> $DEITY on the planet
> >
> >> STOP SPREADING THIS FUD
> >
> >> It did not happen to pretty much everybody. It happened to people who
> >> blindly updated thignsd and walked away, who did not read the news
> >> announcement, who did not read the CLEARLY WORDED wiki article at
> >> freedesktop.org or alternatively went into mod-induced panic and started
> >> making shit up in their heads.
> >
> > Steady on, old chap!  By "it" I was meaning the general inconvenience
> > all round occasioned by the changes between udev-{197,200}.  Not
> > everybody encountered this.  For example Dale, and Walt D. didn't have
> > to do anything.  But pretty much everybody else did.
> >
> >
>
> I didnt get hit either either, but ("STRONG" hint") ... I use eudev, so
> dies Dale and I believe Walt uses mdev.  Time for those in server
> environments to jump ship?
>
> It may hit us eventually, but at the moment its :)
>
> BillK

Well, *my* Gentoo servers are already running mdev...

Hmm... doesn't anyone think it's weird that we haven't heard any complaints / horror stories from the Gentoo-server mailing list?

Rgds,
--

[Stroller]

On 7 April 2013, at 16:35, Pandu Poluan wrote:
> On Apr 7, 2013 3:56 PM, "Stroller" <stro...@stellar.eclipse.co.uk> wrote:
>
>> AIUI the motive for these changes are so that you can unpack an enterprise-type server, the ones with two NICs on the motherboard, and always know which NIC is which. You can then unpack a pallet load of them, and deploy them without any need for determining which is which or for any manual intervention. This is actually pretty important and useful, but I'm not sure this has all been done the best way.
>
> AFAICT, on-board NICs have sequential MAC Adresses, with the one labeled "Port 1" has the smallest MAC Address. So far, *all* Linux distros I've used on a server will reliably name "Port X" as "eth$((X-1))". So it's never a puzzle as to which port bears which "ethX" moniker.

I would expect this to be the case, too, but I'm told it's not always so - you cannot be certain of it.

I think that the kernel allocates interfaces to NICs in the order in which they're found - eth0 to the first one, eth1 to the second, and so on. A pair of on-board NICs may be allocated interface IDs in the same order as their MACs, but they may not be - especially if, for some reason, one responds abnormally slowly to probing from the kernel.

A really good long discussion of this is available at [1], see also [2]:

Without biosdevname, you get all ethX names - they're just in completely
non-deterministic order. Often times after the first non-deterministic
order is set in 70-persistent-net.names, and with no other configuration
changes to your system, on reboot you'll get those same names for those
devices again, but only because no renames are actually taking place -
the kernel accidentally names them in the same way each time.

You cannot swizzle them within the ethX namespace and have it work -
it's racy and failure-prone. You must change out of ethX in order to
get consistency at all.

> The new naming scheme, however, is much less intuitive. Where originally I just immediately use eth0, now I have to enumerate the monikers first, because even between servers of the same model (let's say, HP's DL360 G7), the PCI attachment point might differ.

I agree. However, attempts to solve this in kernel (I think *several* of them), which would have allowed the eth0, ethX namespaces to be retained, were rejected. See [3].

I believe that HP shared involvement in this - I think they collaborated with Dell on how the BIOS would declare the NICs in a way that would be available to the kernel.

Stroller.



[1] http://marc.info/?l=linux-netdev&m=128163454631618&w=3
[2] http://lists.us.dell.com/pipermail/linux-poweredge/2010-November/043586.html
[3] http://marc.info/?l=linux-netdev&m=128518030400371&w=3

[Walter Dnes]

On Sun, Apr 07, 2013 at 10:30:10AM -0600, Joseph wrote

> In my opinion this new udev-200 naming port is a big screw-up; I
> wouldn't be surprised if few months down the road we will go back
> to old naming because of misunderstandings.

Some time ago, after udevd was subsumed into the systemd tarball,
firmware loading was screwed up by the udev/systemd team. They insisted
that the old way was "wrong", and only their "new and improved" method
of loading firmware was to be used. Here we go again. How long before
they create more problems?

--
Walter Dnes <walt...@waltdnes.org>
I don't run "desktop environments"; I run useful applications

[Bruce Hill]

On Sun, Apr 07, 2013 at 09:12:15AM +0800, William Kenworthy wrote:
> >
> > Steady on, old chap! By "it" I was meaning the general inconvenience
> > all round occasioned by the changes between udev-{197,200}. Not
> > everybody encountered this. For example Dale, and Walt D. didn't have
> > to do anything. But pretty much everybody else did.
> >
> >
>
> I didnt get hit either either, but ("STRONG" hint") ... I use eudev, so
> dies Dale and I believe Walt uses mdev. Time for those in server
> environments to jump ship?
>
> It may hit us eventually, but at the moment its :)

I didn't "get hit" by this either, and am still using udev. I went from 171 to
197 to 200 and all's still well on the 5 Gentoo boxen left on this LAN.
Granted, only 3 of them have multiple NICs, and only one is using multiple
ethernet cables atm.
--
Happy Penguin Computers >')
126 Fenco Drive ( \
Tupelo, MS 38801 ^^
sup...@happypenguincomputers.com
662-269-2706 662-205-6424
http://happypenguincomputers.com/

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting

[Bruce Hill]

On Sun, Apr 07, 2013 at 05:00:17PM +0000, Grant Edwards wrote:
> On 2013-04-07, Tanstaafl <tans...@libertytrek.org> wrote:
> > On 2013-04-07 6:55 AM, Neil Bothwick <ne...@digimed.co.uk> wrote:
> >> On Sat, 06 Apr 2013 17:14:00 -0400, Tanstaafl wrote:
> >>
> >>>> Well, in my case 80-net-names-slot.rules was neither empty,
> >>>> nor symlink to dev null, but FULL OF COMMENTS AND NOTING ELSE,
> >>>
> >>> Well... even I know enough to reason that 'empty' in this context means
> >>> no UNcommented lines. Comments are just that, and if there are no
> >>> UNcommented lines, then nothing is active, hence it is effectively
> >>> 'empty'.

> >>
> >> But not actually empty. If you are correct, and I suspect you are, then
> >> the news item is poorly worded. No effective content is not the same as
> >> no content at all.
> >
> > Oh, I agree that it was poorly worded, I was just pointing out that it
> > was kind of silly to take quite it so literally...
>

> OK, so parts of the news item are not to be taken literally, and other

> parts are. Perhaps it would be wise to mark the sections so we can
> tell the difference? ;)

>
> > Every sysadmin knows (or should know) that a config file full of
> > nothing but comments isn't going to do *anything* other than provide
> > whatever defaults the program is designed to use in such a case.
>

> It's entirely possible for udev (or any other program) to check
> whether a file is empty or not and behave differently depending on
> that test. And if it is explicitly stated that something depends on a
> file being "empty", that's what I assume was indended. Of course it's
> possible to determine via experimentation that "nothing but comments"
> produces the same behavior as "empty". Of course we all figured that
> out after we realized that udev wasn't behaving as was described in
> the news entry and started reading other documentation.

I'll give you all one more to chew on ... this LAN has 5 comps running udev,
upgraded from 171 > 197 > 200, and NONE of them EVER has this mysterious
/etc/udev/rules.d/80-net-name-slot.rules file. If it was there sometime during
these upgrades, and was removed, it was automatically removed and not manually
by me using rm to do so.

[Bruce Hill]

On Sun, Apr 07, 2013 at 09:31:43PM +0100, Neil Bothwick wrote:
> On Sun, 07 Apr 2013 13:16:45 -0400, Tanstaafl wrote:
>
> > "If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a
> > symlink to /dev/null,"
> >
> > The first can obviously be taken quite literally, while the second just
> > might actually require a tiny bit of thought - ie, 'hmmm, wonder if
> > they mean literally 'empty', or just nothing in it that does anything?
>
> Even if that were reasonable, how are you supposed to know which they
> mean? You guessed right and now have the benefit of hindsight, that does
> not justify ambiguous or inaccurate instructions.

Ack!

Empty means a zero byte file ... always has, and if the idiots who have
started systemd and taken over udev have somehow managed to change that, then
we are not going to be able to trust ANYTHING they ever write again, without a
new dictionary to define their terms. (Sounds like the present POTUS,
Congress, and Supreme Court in the U.S.)

Personally I don't now, nor have ever, trusted Kay and Lennart. I depend upon
WilliamH to keep the ship afloat as we sail through the udev murk...

[Bruce Hill]

On Sun, Apr 07, 2013 at 07:42:23PM +0200, Michael Hampicke wrote:
>
> Mike is right, if it's not a dep of another ebuild, you don't need
> wpa_supplicant. I just upgraded udev to 200 on the last remote box
> (which is always a bit of a thrill after typing reboot <return> :-) ).
> As expected, eth0 came up, everything works fine, wpa_supplicant is not
> installed.

Don't know what you guys do for rebooting a headless server blindly like this,
nor if it would work for the udev/NIC situation. But fwiw, what I've always
done for new kernels is:

mingdao@server ~ $ egrep -v "(^#|^ *$)" /etc/lilo.conf
compact
lba32
default = Gentoo-def
boot = /dev/md0
raid-extra-boot = mbr-only
map = /boot/.map
install = /boot/boot-menu.b # Note that for lilo-22.5.5 or later you
# do not need boot-{text,menu,bmp}.b in
# /boot, as they are linked into the lilo
# binary.
menu-scheme=Wb
prompt
timeout=50
append="panic=10 nomce dolvm domdadm rootfstype=xfs"
image = /boot/vmlinuz
root = /dev/md0
label = Gentoo
read-only # Partitions should be mounted read-only for checking
image = /boot/vmlinuz.old
root = /dev/md0
label = Gentoo-def
read-only # Partitions should be mounted read-only for checking

Then issue "lilo -R Gentoo" or whatever the label of your new kernel, and if
it boots, you're okay. If not, after 10 seconds of panic, it automatically
reboots back into the default kernel and you can check logs to see what you've
broken. (panic=10 append statement and default = Gentoo-def) After you know
the new kernel works, comment the default line. (NB: You can name them
differently, etc. It just helps to know before you reboot that if you panic,
the machine will boot back into the known, good, kernel.)

Granted, this might not help with the udev/NIC situation, but it's saved me
from a few PEBKAC situations, as well as new kernel changes I'd not learned
until the reboot.

[Michael Mol]

On 04/08/2013 12:04 PM, Bruce Hill wrote:
> On Sun, Apr 07, 2013 at 09:31:43PM +0100, Neil Bothwick wrote:
>> On Sun, 07 Apr 2013 13:16:45 -0400, Tanstaafl wrote:
>>
>>> "If /etc/udev/rules.d/80-net-name-slot.rules is an empty file or a
>>> symlink to /dev/null,"
>>>
>>> The first can obviously be taken quite literally, while the second just
>>> might actually require a tiny bit of thought - ie, 'hmmm, wonder if
>>> they mean literally 'empty', or just nothing in it that does anything?
>>
>> Even if that were reasonable, how are you supposed to know which they
>> mean? You guessed right and now have the benefit of hindsight, that does
>> not justify ambiguous or inaccurate instructions.
>
> Ack!
>
> Empty means a zero byte file ... always has, and if the idiots who have
> started systemd and taken over udev have somehow managed to change that, then
> we are not going to be able to trust ANYTHING they ever write again, without a
> new dictionary to define their terms. (Sounds like the present POTUS,
> Congress, and Supreme Court in the U.S.)
>
> Personally I don't now, nor have ever, trusted Kay and Lennart. I depend upon
> WilliamH to keep the ship afloat as we sail through the udev murk...
>

The phrase is "kernel-tinted glasses".

[Bruce Hill]

On Sat, Apr 06, 2013 at 10:58:38PM -0400, Randy Barlow wrote:
> On Sat, 6 Apr 2013 22:35:22 -0400
> Nick Khamis <sym...@gmail.com> wrote:
> > As for /sbin/ip. I have no such command.
>
> I'd recommend installing and becoming familiar with the iproute2
> package. I personally find the tools it delivers to be more intuitive
> than the older tools, and I *think* they are considered to obsolote some
> tools, such as ifconfig.

Ack to Randy's. FWIW: http://inai.de/2008/02/19

[Bruce Hill]

On Sun, Apr 07, 2013 at 01:29:20PM -0400, Nick Khamis wrote:
> After psyching myself and everyone else for the udev 200 update, it
> failed on compile phase! We are using hardened server, and error
> message (which I am transferring over manually) is:
>
> The specific snippet of code:
> die econf failed
>
>
> This thing is not going easy....
>
>
> N.
>
> On 4/7/13, Tanstaafl <tans...@libertytrek.org> wrote:
> > On 2013-04-07 9:38 AM, Nick Khamis <sym...@gmail.com> wrote:
> >> Double checking the udevd version we are running 171. Not sure if we
> >> should be effected yet? I confess, I did a world upgrade and walked
> >> away.
> >
> > Well, hopefully you learned a valuable lesson. I cannot even *fathom*
> > the *idea* of doing a world update on a remote server without going
> > through each and every package to be updated, reading every news item I
> > could find, etc etc ad nauseum, and googling if any systems critical to
> > booting (like udev) are involved.
> >
> > For me, world updates are usually very small because I keep my server
> > updated weekly. I generally sync every day, checking what packages are
> > available, then once that update has been available/unchanged for 3 or 4
> > days, I update it... waiting even a bit longer (and googling for issues)
> > if the package(s) are critical system packages.
> >
> > Admittedly, doing it this way manually wouldn't work for anyone managing
> > more than a few servers, although I imagine it could be scripted by one
> > with the knowledge/desire.
> >
> > But seriously - there has been so much noise about the whole udev
> > situation in the last months (6+?) that you should really be kicking
> > yourself that you did that.
> >
> >

You might not care, but I automatically hit D (delete) in Mutt for every email
that's top-posted. Just saying...

[Bruce Hill]

On Sun, Apr 07, 2013 at 10:35:28PM +0700, Pandu Poluan wrote:
>
> AFAICT, on-board NICs have sequential MAC Adresses, with the one labeled
> "Port 1" has the smallest MAC Address. So far, *all* Linux distros I've
> used on a server will reliably name "Port X" as "eth$((X-1))". So it's
> never a puzzle as to which port bears which "ethX" moniker.

My SuperMicro has the lower MAC wired to ID1 and the higher MAC to ID2:

[ 11.691830] tg3 0000:03:00.0: eth0: Tigon3 [partno(BCM95721) rev 4101] (PCI Express) MAC address 00:d0:68:0b:87:67
[ 11.691985] tg3 0000:03:00.0: eth0: attached PHY is 5750 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 11.692192] tg3 0000:03:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[1] TSOcap[1]
[ 11.692340] tg3 0000:03:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[ 11.699283] tg3 0000:02:00.0: eth1: Tigon3 [partno(BCM95721) rev 4101] (PCI Express) MAC address 00:d0:68:0b:87:66
[ 11.699439] tg3 0000:02:00.0: eth1: attached PHY is 5750 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
[ 11.699591] tg3 0000:02:00.0: eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[ 11.699738] tg3 0000:02:00.0: eth1: dma_rwctrl[76180000] dma_mask[64-bit]

Which is precisely the reason for me using 70-persistent-net.rules since
Gentoo was installed on it back in 2011. My ethernet cable is plugged into
ID1, or MAC address 00:d0:68:0b:87:66, and /etc/conf.d/net must know which
eth* that was assigned.

> The new naming scheme, however, is much less intuitive. Where originally I
> just immediately use eth0, now I have to enumerate the monikers first,
> because even between servers of the same model (let's say, HP's DL360 G7),
> the PCI attachment point might differ.

My old brain has chosen to stick with "intuitive", which really just means
"what you have become accustomed to", whatever that might be individually.

> Granted, Linux SysAdmins *are* expected to understand the vagaries of
> Linux, but it's still a great inconvenience.

And therein lies the rub ... systemd has overtaken udev and changed the
nomenclature.

[Michael Mol]

On 04/08/2013 12:28 PM, Bruce Hill wrote:
> On Sat, Apr 06, 2013 at 10:58:38PM -0400, Randy Barlow wrote:
>> On Sat, 6 Apr 2013 22:35:22 -0400
>> Nick Khamis <sym...@gmail.com> wrote:
>>> As for /sbin/ip. I have no such command.
>>
>> I'd recommend installing and becoming familiar with the iproute2
>> package. I personally find the tools it delivers to be more intuitive
>> than the older tools, and I *think* they are considered to obsolote some
>> tools, such as ifconfig.
>
> Ack to Randy's. FWIW: http://inai.de/2008/02/19
>

That page has a handy list at the end. I've gone back to the page twice
today...bookmarked.

[Jarry]

Maybe time to update our Gentoo Handbook to use "ip" instead
of "ifconfig/route" so that users could get used to it right
during installation...

Jarry
--
_______________________________________________________________
This mailbox accepts e-mails only from selected mailing-lists!
Everything else is considered to be spam and therefore deleted.

[Joseph]

On 04/08/13 04:36, Stroller wrote:
>
>> The new naming scheme, however, is much less intuitive. Where originally I just immediately use eth0, now I have to enumerate the monikers first, because even between servers of the same model (let's say, HP's DL360 G7), the PCI attachment point might differ.
>
>I agree. However, attempts to solve this in kernel (I think *several* of them), which would have allowed the eth0, ethX namespaces to be retained, were rejected. See [3].
>
>I believe that HP shared involvement in this - I think they collaborated with Dell on how the BIOS would declare the NICs in a way that would be available to the kernel.
>
>Stroller.

Well, if HP had an involvement in it, I'm not surprised we got screw-up with this naming; sarcasm.
If they could only put/assign a "chip/serial number" and ask us to pay the way they do with their printer cartridges they would do it :-/

If the boys with the servers, with more than two networks cards wants to have consistent naming they should have made it optional and not push this "new name crap" on
everybody.

--
Joseph

[Pandu Poluan]

On Apr 9, 2013 12:32 AM, "Jarry" <mr.j...@gmail.com> wrote:
>
> On 08-Apr-13 19:19, Michael Mol wrote:
>>
>> On 04/08/2013 12:28 PM, Bruce Hill wrote:
>>>
>>> On Sat, Apr 06, 2013 at 10:58:38PM -0400, Randy Barlow wrote:
>>>>
>>>> On Sat, 6 Apr 2013 22:35:22 -0400
>>>> Nick Khamis <sym...@gmail.com> wrote:
>>>>>
>>>>> As for /sbin/ip. I have no such command.
>>>>
>>>>
>>>> I'd recommend installing and becoming familiar with the iproute2
>>>> package. I personally find the tools it delivers to be more intuitive
>>>> than the older tools, and I *think* they are considered to obsolote some
>>>> tools, such as ifconfig.
>>>
>>>
>>> Ack to Randy's. FWIW: http://inai.de/2008/02/19
>>
>>
>> That page has a handy list at the end. I've gone back to the page twice
>> today...bookmarked.
>
>
> Maybe time to update our Gentoo Handbook to use "ip" instead
> of "ifconfig/route" so that users could get used to it right
> during installation...
>
>
> Jarry
> --
>

TBH, the first time I learnt about iproute2 -- about 3 or 4 years ago --  I no longer use ifconfig.

It's so similar to Cisco IOS commands structure that I immediately took a liking to it. (Less cognitive dissonance going back and forth between Linux and Cisco routers).

Rgds,
--

[Pandu Poluan]

Personally, I always try to install *any* Linux server on top of Xen (in my case, XenServer). That way, I got a remote "console" always.

Rgds,
--

[Bruce Hill]

On Sat, Apr 06, 2013 at 09:40:41PM -0400, Michael Mol wrote:
>
> /sbin/ip link addr show
>
> That will tell you the names of your interfaces, as they currently exist.

FWIW that command should be "ip addr show" rather than "ip link addr show",
and no need for full path in later versions (forgetting which version changed
this behavior).

[Michael Hampicke]

I have something similar with grub (with grub set default, savedefault,
fallback). Also most machines have some sort of rescue access with like
ipmi serial over lan or a eric card (kvm). But some remote machines
don't and rebooting them is always a thrill :) I mean, there are rescue
systems that can be invoked via bootp, but you are blind while rebooting.

[Bruce Hill]

On Mon, Apr 08, 2013 at 09:46:28PM +0200, Michael Hampicke wrote:
>
> I have something similar with grub (with grub set default, savedefault,
> fallback). Also most machines have some sort of rescue access with like
> ipmi serial over lan or a eric card (kvm). But some remote machines
> don't and rebooting them is always a thrill :) I mean, there are rescue
> systems that can be invoked via bootp, but you are blind while rebooting.

Hi Michael,

If you have the time, maybe you can post your GrUB setup and a short HOW-TO do
this somewhere. I've often mentioned doing it with LiLO in #gentoo on Freenode
and always get flamed by GrUB fanbois, but to date none has been able to
produce how to actually do it with GrUB. Since Gentoo now recommends GrUB
rather by default, it might be nice for folks to know how to use this.

Thanks,
Bruce

[Michael Hampicke]

Am 08.04.2013 21:56, schrieb Bruce Hill:
> On Mon, Apr 08, 2013 at 09:46:28PM +0200, Michael Hampicke wrote:
>>
>> I have something similar with grub (with grub set default, savedefault,
>> fallback). Also most machines have some sort of rescue access with like
>> ipmi serial over lan or a eric card (kvm). But some remote machines
>> don't and rebooting them is always a thrill :) I mean, there are rescue
>> systems that can be invoked via bootp, but you are blind while rebooting.
>
> Hi Michael,
>
> If you have the time, maybe you can post your GrUB setup and a short HOW-TO do
> this somewhere. I've often mentioned doing it with LiLO in #gentoo on Freenode
> and always get flamed by GrUB fanbois, but to date none has been able to
> produce how to actually do it with GrUB. Since Gentoo now recommends GrUB
> rather by default, it might be nice for folks to know how to use this.
>
> Thanks,
> Bruce
>

This actually is pretty straight forward :) Here's a small sample config
for grub 0.97. But I'm pretty sure that this will work with grub2 too.

### grub.conf ###

# set default boot entry to prev. saved state:
default saved

# seq. order of boot entries
fallback 1 2 3

# here are the kernels
title gentoo 0
kernel /kernel panic=15
savedefault fallback

title gentoo 1
kernel /kernel panic=15
savedefault fallback

title gentoo 2
kernel /kernel panic=15
savedefault fallback

title gentoo 3
kernel /kernel panic=15
savedefault fallback

### end grub.conf ###

what I now do is this: set the default boot entry to zero with
% grub-set-default 0

On the next reboot this happens:

grub reads the default: 0

grub boots entry 0 and sets the default entry to 1 (or 2.... according
to the fallback line in grub.conf)

If the systems panics, it reboots. But this time grub will load entry 1
as it is the default now (and so on, and so on).

If the systems booted successfully and you verified that it actually
booted the new kernel, you now have to set grub default to 0 with
grub-set-default.
You can to this with a small script in /etc/local.d/local.start
Maybe send the admin a warning that the system has not booted with the
default kernel. That's up to you :)

HTH