Re: udev being an ass

[Brian]

On Fri 30 Aug 2019 at 07:47:09 -, Curt wrote:

> On 2019-08-28, Gene Heskett  wrote:
> >
> > If you can't say something constructive Brian, please just stfu. I won't 
> > claim to speak for the rest of the list, but I am damned tired of your 
> > negative attitude. You have, I assume the same clothes to get glad in
> > that you got mad in. Use them.
> 
> In your defense I'll say that your negativity is infrequently, if ever,
> *ad hominem*, and udev, brltty et. al. are all inanimate things, not
> animate beings, the former being incapable of taking umbrage at being
> the target of diverse epithets, as they are, like rocks, lacking in all
> sensibility (despite the inane OT babbling of the AI bullshit artists of
> the group, and not to mention the self-righteous assholes who hijack
> legitimate threads from the /blind/ without compunction, for whom I will
> save my personal indignation, thank you very much*).

A different view is espoused at

https://lists.debian.org/debian-devel/2019/08/msg00161.html

 > Personally, I'd be happy if people would just stop hating on any free
 > software in general.  Even buggy free software is someone's effort,
 > released into the world hopefully for our benefit.  These conversations
 > would be so much easier to have if they were framed in terms of costs and
 > benefits, different use cases, and personal preferences, rather than
 > making supposedly-objective statements grounded in strong personal
 > opinions about the merits or worthlessness of some piece of software.

-- 
Brian.

Re: udev being an ass

[Larry Martell]

On Thu, Aug 29, 2019 at 9:51 PM Felix Miata  wrote:
>
> David Wright composed on 2019-08-29 19:49 (UTC-0500):
>
> > Unfortunately, virtually every conversation about any of your systems
> > begins with a tirade about how Debian is completely broken, whether
> > it's the...
>
> I'm guessing most of it would be curtailed if he could install the current 
> stable
> release of what has proven to be the most stable OS available and upgrade to a
> realtime kernel that controlled all his machine tools just like it used to be 
> able
> to do before all the "improvements" got rolled into it.
>
> Be kind. It ain't so much fun getting old, and the unfun is multiplied by 
> being a
> caregiver for a spouse with dementia or strains simply to breathe even using 
> an
> oxygen bottle or generator while limping along on a bunch of chemicals and
> replacement body parts to keep the old kicker kicking. Given his spouse's
> condition, this might be one of few opportunities he gets to communicate with
> people of intelligence. I'm sure he, like many in his age group, needs mental
> exercise as available here as much as he and others like him need physical
> exercise they don't get because of the existence of electronic video displays 
> and
> all that appears on them for whatever reason.

+100

Re: udev being an ass

[Gene Heskett]

On Friday 30 August 2019 03:47:09 Curt wrote:

> On 2019-08-28, Gene Heskett  wrote:
> > If you can't say something constructive Brian, please just stfu. I
> > won't claim to speak for the rest of the list, but I am damned tired
> > of your negative attitude. You have, I assume the same clothes to
> > get glad in that you got mad in. Use them.
>
> In your defense I'll say that your negativity is infrequently, if
> ever, *ad hominem*, and udev, brltty et. al. are all inanimate things,
> not animate beings, the former being incapable of taking umbrage at
> being the target of diverse epithets, as they are, like rocks, lacking
> in all sensibility (despite the inane OT babbling of the AI bullshit
> artists of the group, and not to mention the self-righteous assholes
> who hijack legitimate threads from the /blind/ without compunction,
> for whom I will save my personal indignation, thank you very much*).
>
> Also, you're /old/, man, which deserves the cutting of slack in my
> book as a matter of simple elegance, like giving your seat to the
> pregnant lady at rush hour on the bus.

Which as you might guess, I would do. But this county seat village has no 
commercial busses. Too small. The senior center has a van or two for the 
shoppers living in small apts without personal wheels.  Generally we 
take care of our own. When I married this lady 30 years ago this Dec 
2nd, we were both working, me as the Chief Engineer of the local CBS 
affiliate, she as an elementary music teacher who moved her classroom in 
her car 2 to 4 times a day to the various schools around the county, so 
our combined income was impetus to replace her 30 year mortgage with a 7 
year thats been paid off for 20 years. Both vehicles are also paid off. 
Not too many can say that.  So taxes, utils and maintenance are our 
outgoes.  Its a nice village to slow down and eventually end in. 
Recommended by grandpa Gene if you are looking for a place to 
retire.. ;-)
>
> *https://www.mail-archive.com/debian-user@lists.debian.org/msg746883.h
>tml
>
> > Cheers, Gene Heskett


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Curt]

On 2019-08-28, Gene Heskett  wrote:
>
> If you can't say something constructive Brian, please just stfu. I won't 
> claim to speak for the rest of the list, but I am damned tired of your 
> negative attitude. You have, I assume the same clothes to get glad in
> that you got mad in. Use them.

In your defense I'll say that your negativity is infrequently, if ever,
*ad hominem*, and udev, brltty et. al. are all inanimate things, not
animate beings, the former being incapable of taking umbrage at being
the target of diverse epithets, as they are, like rocks, lacking in all
sensibility (despite the inane OT babbling of the AI bullshit artists of
the group, and not to mention the self-righteous assholes who hijack
legitimate threads from the /blind/ without compunction, for whom I will
save my personal indignation, thank you very much*).

Also, you're /old/, man, which deserves the cutting of slack in my book
as a matter of simple elegance, like giving your seat to the pregnant
lady at rush hour on the bus.

;-)

*https://www.mail-archive.com/debian-user@lists.debian.org/msg746883.html


> Cheers, Gene Heskett


-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

Re: udev being an ass

[Gene Heskett]

On Thursday 29 August 2019 21:34:33 Felix Miata wrote:

> David Wright composed on 2019-08-29 19:49 (UTC-0500):
> > Unfortunately, virtually every conversation about any of your
> > systems begins with a tirade about how Debian is completely broken,
> > whether it's the...
>
> I'm guessing most of it would be curtailed if he could install the
> current stable release of what has proven to be the most stable OS
> available and upgrade to a realtime kernel that controlled all his
> machine tools just like it used to be able to do before all the
> "improvements" got rolled into it.
>
I'd love it. Unforch, its often past a new distros sell by date by the 
time someone gets around to patching an rtai version compatible with the 
new kernels. Depending on the machine, acceptable performance can 
sometimes be had with the much easier to build fully pre-emptible 
kernel.  We have found one of the stretch kernels is almost working, but 
it has a habit of disconnecting from its own keyboard at random 
intervals.  Usually after a key down event but missing the key up that 
would stop the jog. Unplugging the dongles will usually restore 
operation after 2 or 3 reconnections. In the mean time the machine, 
never having received the key up, is merrily moving a couple hundred 
pounds of itself at up to 200 inches a minute until it runs out of room 
and slams into the end of its travel, and $diety's help will be needed 
for anyone unlucky enough to be in the way.

To be blunt, no way in hell will we install this
4.9.0-9-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.168-1+deb9u5 (2019-08-11) 
x86_64 GNU/Linux on a machine actually running a machine.  I can 
tolerate this as theres no real machinery tied to this box. So this is a 
nuisance, not a potential maimer.

I have one buster installed, I'm very impressed, from raspian on a 
raspberry pi 3b, which can use the newest buster build, something I 
cannot get from debian because debian won't touch the new broadcom video 
code and likely never will.  Because the video in the latest raspian is 
> 15x faster, its the only game in town to run on a pi.

We don't have that problem with amd64, and I expect we'll soon have a 
good preempt-rt kernel for buster. But that won't fix my big lathe.  So 
I am building, installing and testing, working well except for the 
snails pace video on what is basically a stretch install. All of which 
takes time. Either a new kernel, or the latest linuxcnc is around a 4 
hour build a deb job on the pi's.  And AFAIK, no one is working on it 
but me.  I wanted to see, 2 years ago, If I could run big machinery from 
a pi, I've done quite well, but I've also painted myself into a corner.

TBT, our coders spend more time chasing linux's changes that wreck our 
stuff, than in making improvements to our code. It would be truly a 
blessing if the changes to linux incrementally resulted in stable code 
that barring security stuff, was long term stable. But it seems to be 
getting worse, not better since wheezy.

My job, self appointed, is running the latest master code on all my 
machines, serving as the canary in the coal mine, finding new bugs if I 
can, so that the guys running the released code in a job shop making 
5000 copies of something, don't get expensive surprises. You folks would 
be surprised at the places you will find this code. Go into any car 
parts place, and look at the high horsepower stuff.  linuxcnc probably 
carved 20% of the high performance crate engines you can only lease.

> Be kind. It ain't so much fun getting old, and the unfun is multiplied
> by being a caregiver for a spouse with dementia or strains simply to
> breathe even using an oxygen bottle or generator while limping along
> on a bunch of chemicals and replacement body parts to keep the old
> kicker kicking. Given his spouse's condition, this might be one of few
> opportunities he gets to communicate with people of intelligence. I'm
> sure he, like many in his age group, needs mental exercise as
> available here as much as he and others like him need physical
> exercise they don't get because of the existence of electronic video
> displays and all that appears on them for whatever reason.
>
> If you get old, and wise at the same time, you eventually figure out
> it's usually best to not fix what ain't broke, and highly annoying to
> have to fix what broke due to unavoidable purported software
> improvements that only got tested on hardware that's barely had the
> smell of new burned away.

Thanks for the flowers Felix, its actually a pretty good description. The 
mental degradation as the years go by is the most maddening. To put that 
into a long term perspective, I sat for Mensa 2 years ago, and failed. 
In 1952 at 18 yo, I scored a 98 on the AFQT.  If I could produce that 
test page today I'd be an automatic Mensa member. Part of that 
degradation was a pulmonary embolism that starved my brain in and out of 
reality for several hours while the clot buster shot was working 

Re: udev being an ass

[Felix Miata]

David Wright composed on 2019-08-29 19:49 (UTC-0500):

> Unfortunately, virtually every conversation about any of your systems
> begins with a tirade about how Debian is completely broken, whether
> it's the...

I'm guessing most of it would be curtailed if he could install the current 
stable
release of what has proven to be the most stable OS available and upgrade to a
realtime kernel that controlled all his machine tools just like it used to be 
able
to do before all the "improvements" got rolled into it.

Be kind. It ain't so much fun getting old, and the unfun is multiplied by being 
a
caregiver for a spouse with dementia or strains simply to breathe even using an
oxygen bottle or generator while limping along on a bunch of chemicals and
replacement body parts to keep the old kicker kicking. Given his spouse's
condition, this might be one of few opportunities he gets to communicate with
people of intelligence. I'm sure he, like many in his age group, needs mental
exercise as available here as much as he and others like him need physical
exercise they don't get because of the existence of electronic video displays 
and
all that appears on them for whatever reason.

If you get old, and wise at the same time, you eventually figure out it's 
usually
best to not fix what ain't broke, and highly annoying to have to fix what broke
due to unavoidable purported software improvements that only got tested on
hardware that's barely had the smell of new burned away.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: udev being an ass

[David Wright]

On Wed 28 Aug 2019 at 20:19:29 (-0400), Gene Heskett wrote:
> On Wednesday 28 August 2019 16:04:48 Greg Wooledge wrote:
> > On Wed, Aug 28, 2019 at 08:42:56PM +0100, Brian wrote:
> > > On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote:
> > > > I've resorted to the chattr on more than one occasion.  Works well
> > > > if you can get it all done before before the timer runs the N-M
> > > > script again.
> > >
> > > Users (particularly new users) who read chattr(1), and who think
> > > getting their own way with chattr is a good way to go, are deluded.
> > > Setting up a simple network never requires it. If you think it is -
> > > you have lost.
> >
> > Which part of Gene's plans has ever been "simple"?
> 
> :-)
> 
> > He apparently wants to make his operating system refuse to register
> > persistent interface names, on the grounds that he frequently moves
> > a physical hard drive from one system to another, and doesn't want to
> > go through the hassle of reassigning the interface names each time.
> 
> Thats a miss-statement. I do want persistent interface names EVEN if I 
> move this boot drive to a whole new box.
> 
> > If you know a way to do that other than the ways I suggested, go ahead
> > and tell us.
> >
> > I've already warned him that it will fail catastrophically on a system
> > with more than one NIC.
> 
> This machine does in fact have 2 nic's.  And I have indeed used both at 
> the same time but haven't mastered "consistently".

What a ridiculous time waster. Everything I've posted in this thread
is predicated on your having just one. Why? Because you wrote:

"But udevs UN-persistent rules have apparently run out of eth0 names,
renaming the only ethernet port it has to eth2."
 
https://lists.debian.org/debian-user/2019/08/msg01311.html

Cheers,
David.

Re: udev being an ass

[David Wright]

On Wed 28 Aug 2019 at 19:59:53 (-0400), Gene Heskett wrote:
> On Wednesday 28 August 2019 15:42:56 Brian wrote:
> > On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote:
> > > I've resorted to the chattr on more than one occasion.  Works well
> > > if you can get it all done before before the timer runs the N-M
> > > script again.
> >
> > Users (particularly new users) who read chattr(1), and who think
> > getting their own way with chattr is a good way to go, are deluded.
> > Setting up a simple network never requires it. If you think it is -
> > you have lost.
> 
> Haveing quite successfully used chattr to defeat N_M from tearing down a 
> perfectly good network setup ever since N_M was introduced as Gods gift 
> to Woman over a decade ago, I'll claim to have won that battle.
> 
> If you can't say something constructive Brian, please just stfu. I won't 
> claim to speak for the rest of the list, but I am damned tired of your 
> negative attitude. You have, I assume the same clothes to get glad in 
> that you got mad in. Use them.

Unfortunately, virtually every conversation about any of your systems
begins with a tirade about how Debian is completely broken, whether
it's the partitioner, the screen reader, aptitude, ncurses,
network-manager, resolvconf, IPv6, CUPS, logging and log rotation,
tail, ssh, ip, man pages generally, kmail's font rendering, brltty,
or Debian's policy on stable and any improvements in its security
policies. That's 4½ years worth. And everything becomes a battle,
an enemy that must be defeated, often by reckless means.

Cheers,
David.

Re: udev being an ass, SOLVED

[Gene Heskett]

On Thursday 29 August 2019 15:23:42 Greg Wooledge wrote:

> > > and yet you can't actually describe what you DO want to happen.
> >
> > I just did, in a step by step description, Greg.  How you choose to
> > understand it is up to you.
>
> I just reviewed
>  again. 
> There is nothing in it about how you want interface names to be
> assigned.
>
> There isn't even a single interface name mentioned.  Not one.
> No instances of "eth0" or "eno0" or "enp2s6" or anything.
>
> All you talk about are hosts files and DNS, with a side of offtopic
> medical issues.
>
> I can only conclude that you don't understand what anyone is talking
> about.  I think I've wasted enough time on this thread.

My main point is that a scheme to give consistent names to an interface, 
goes completely aglay when the drive is moved to a different machine. It 
does not matter what the interfaces name was, never has and never will.

In the instant case it was eth1, but it became a totally non-existent 
eth2 according to the last stanza of /e/u/r.d/70-persistent-net.rules.  
An eth2 which could not be brought on line by the /e/n/i settings for 
eth1.

So as far as I'm concerned, the current scheme to "assure consistent net 
port names", is an abject failure.  What I wanted was a foolproof method 
to reset this whole circus to square 1 and keep it there.  The puzzle to 
me is why did it take a weeks worth of name calling and denegrateing 
each other to finally elicit a working answer.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Greg Wooledge]

> > and yet you can't actually describe what you DO want to happen.
> 
> I just did, in a step by step description, Greg.  How you choose to 
> understand it is up to you.

I just reviewed 
again.  There is nothing in it about how you want interface names to
be assigned.

There isn't even a single interface name mentioned.  Not one.
No instances of "eth0" or "eno0" or "enp2s6" or anything.

All you talk about are hosts files and DNS, with a side of offtopic
medical issues.

I can only conclude that you don't understand what anyone is talking
about.  I think I've wasted enough time on this thread.

Re: udev being an ass

[Gene Heskett]

On Thursday 29 August 2019 12:55:10 Greg Wooledge wrote:

> On Thu, Aug 29, 2019 at 11:41:55AM -0400, Gene Heskett wrote:
> > Its all hosts file based, no dhcp involved this side of the router.
> > If the desired fqdn is not in the /etc/hosts file, which is
> > identical on all machines (so is the /etc/resolv.conf file, which
> > assigns the router
>
> [...]
>
> None of this has anything to do with the topic at hand, which is how
> you wish Debian to assign the interface names to the interfaces that
> it discovers at boot time.  Apparently you don't want to use ANY of
> the various schemes that have been in use for the last decade or so,
> and yet you can't actually describe what you DO want to happen.

I just did, in a step by step description, Greg.  How you choose to 
understand it is up to you.

> Hostnames, IP addresses, DNS nameserver addresses, domain names, etc.
> are all separate from this.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Greg Wooledge]

On Thu, Aug 29, 2019 at 11:41:55AM -0400, Gene Heskett wrote:
> Its all hosts file based, no dhcp involved this side of the router. If 
> the desired fqdn is not in the /etc/hosts file, which is identical on 
> all machines (so is the /etc/resolv.conf file, which assigns the router 
[...]

None of this has anything to do with the topic at hand, which is how
you wish Debian to assign the interface names to the interfaces that
it discovers at boot time.  Apparently you don't want to use ANY of the
various schemes that have been in use for the last decade or so, and
yet you can't actually describe what you DO want to happen.

Hostnames, IP addresses, DNS nameserver addresses, domain names, etc.
are all separate from this.

Re: udev being an ass

[Brian]

On Thu 29 Aug 2019 at 12:03:22 -0400, Gene Heskett wrote:

> On Thursday 29 August 2019 09:26:25 mick crane wrote:
> 
> > On 2019-08-29 13:45, Greg Wooledge wrote:
> > > On Wed, Aug 28, 2019 at 08:19:29PM -0400, Gene Heskett wrote:
> > >> Thats a miss-statement. I do want persistent interface names EVEN
> > >> if I move this boot drive to a whole new box.
> > >>
> > >> This machine does in fact have 2 nic's.  And I have indeed used
> > >> both at
> > >> the same time but haven't mastered "consistently".
> > >
> > > I cannot for the life of me figure out what you want.  If you can
> > > ever figure out how to state your desires clearly, we'll try to help
> > > you.
> > >
> > > Until then, um, good luck with whatever this is.  I mean this
> > > literally,
> > > because apparently your network configuration relies on random
> > > chance to succeed.
> >
> > hardly scientific but if you want to see which NIC is which do some
> > network activity and see which light is flashing.
> > mick
> 
> That requires turning the whole 30" tall tower around, and hoping all the 
> cables still reach. A genuine PITA.  This room is mine.  Its a midden 

Not at all. Turn the back of the tower with a couple of  mirrors.

-- 
Brian (ConstructiveSolutionsAreUs)

Re: udev being an ass

[Gene Heskett]

On Thursday 29 August 2019 09:26:25 mick crane wrote:

> On 2019-08-29 13:45, Greg Wooledge wrote:
> > On Wed, Aug 28, 2019 at 08:19:29PM -0400, Gene Heskett wrote:
> >> Thats a miss-statement. I do want persistent interface names EVEN
> >> if I move this boot drive to a whole new box.
> >>
> >> This machine does in fact have 2 nic's.  And I have indeed used
> >> both at
> >> the same time but haven't mastered "consistently".
> >
> > I cannot for the life of me figure out what you want.  If you can
> > ever figure out how to state your desires clearly, we'll try to help
> > you.
> >
> > Until then, um, good luck with whatever this is.  I mean this
> > literally,
> > because apparently your network configuration relies on random
> > chance to succeed.
>
> hardly scientific but if you want to see which NIC is which do some
> network activity and see which light is flashing.
> mick

That requires turning the whole 30" tall tower around, and hoping all the 
cables still reach. A genuine PITA.  This room is mine.  Its a midden 
heap, but its my midden heap. Its main switch src's 5 pieces of cat-5 
reaching to the corners of the property, some of which has been blowing 
in the wind since the turn of the century, even surviving a 120 mph 
recorded direcho that took down 4 mature pines, removed part of my roof, 
a bunch of privacy fence and demolished several sheet steel garden sheds 
in 2010.  Given the path one of those garden sheds followed going by the 
back of my house, ripping off the gutter and damaging the siding, it 
should have been ripped out. Still there, still working.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Gene Heskett]

On Thursday 29 August 2019 08:45:47 Greg Wooledge wrote:

> On Wed, Aug 28, 2019 at 08:19:29PM -0400, Gene Heskett wrote:
> > Thats a miss-statement. I do want persistent interface names EVEN if
> > I move this boot drive to a whole new box.
> >
> > This machine does in fact have 2 nic's.  And I have indeed used both
> > at the same time but haven't mastered "consistently".
>
> I cannot for the life of me figure out what you want.  If you can ever
> figure out how to state your desires clearly, we'll try to help you.
>
> Until then, um, good luck with whatever this is.  I mean this
> literally, because apparently your network configuration relies on
> random chance to succeed.

Nothing random about it Greg.

Its all hosts file based, no dhcp involved this side of the router. If 
the desired fqdn is not in the /etc/hosts file, which is identical on 
all machines (so is the /etc/resolv.conf file, which assigns the router 
as the nameserver and commands it to search hosts nameserver) then the 
dns query gets sent to the router, which is running dnsmasq.  If dnsmasq 
doesn't have it cached, it consults the dns server given to it by my 
isp. In any event pings to an unknown name are usually resolved and 
returned in less than 90 milliseconds. Fixed ip, needed to make my web 
page work without paying a monthly fee for dynamic updates, is done at 
the router by cloning the mac of the router so that I can swap routers 
if I have to. My isp hand's out net ipv4 addresses according to the 
routers MAC.  That hasn't changed in at least half a decade. There is 
not any ipv6 that I know of beyond the cable/phone modem.

And it all Just Works, with no dhcpd drama anyplace but the router to isp 
modem connection.  Since its a cable modem the connection is full time 
live barring power failure long enough to kill the cable systems backup 
batteries, typically nearly 24 hours. My telephone also works during 
this time. I have a wife in the later stages of COPD, so there is (and 
its a common sight locally, 5 that I've noticed in this little 
cul-de-sac) a 20 kw nat gas fed generator on a pad behind the garage, so 
I have 100% lights and AC and more importantly oxygen generation for the 
wife typically 5 seconds after the substation faults.

Whats not to like? The router does the NAT from 192.168.xx.yy, so all 
machines have full access to the net, but with the exception of my web 
page running on a port forward, nothing here is visible from the  net 
itself.

dd-wrt, flashed into the routers, has very sharp teeth. So I've not been 
bothered by attacks from the network. Ever. I rather like it that 
way. :-)

But you all claim I'm doing it bass ackward. I don't agree, and I don't 
fight with poisoned routes either.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[mick crane]

On 2019-08-29 13:45, Greg Wooledge wrote:

On Wed, Aug 28, 2019 at 08:19:29PM -0400, Gene Heskett wrote:

Thats a miss-statement. I do want persistent interface names EVEN if I
move this boot drive to a whole new box.


This machine does in fact have 2 nic's.  And I have indeed used both 
at

the same time but haven't mastered "consistently".


I cannot for the life of me figure out what you want.  If you can ever
figure out how to state your desires clearly, we'll try to help you.

Until then, um, good luck with whatever this is.  I mean this 
literally,

because apparently your network configuration relies on random chance
to succeed.


hardly scientific but if you want to see which NIC is which do some 
network activity and see which light is flashing.

mick


--
Key ID4BFEBB31

Re: udev being an ass

[Greg Wooledge]

On Wed, Aug 28, 2019 at 08:19:29PM -0400, Gene Heskett wrote:
> Thats a miss-statement. I do want persistent interface names EVEN if I 
> move this boot drive to a whole new box.

> This machine does in fact have 2 nic's.  And I have indeed used both at 
> the same time but haven't mastered "consistently".

I cannot for the life of me figure out what you want.  If you can ever
figure out how to state your desires clearly, we'll try to help you.

Until then, um, good luck with whatever this is.  I mean this literally,
because apparently your network configuration relies on random chance
to succeed.

Re: udev being an ass

[Brian]

On Wed 28 Aug 2019 at 19:59:53 -0400, Gene Heskett wrote:

> If you can't say something constructive Brian, please just stfu. I won't 
> claim to speak for the rest of the list, but I am damned tired of your 
> negative attitude. You have, I assume the same clothes to get glad in 
> that you got mad in. Use them.

"Negative attitude"? I was merely following the example set by the
subject header.

-- 
Brian.

Re: udev being an ass, SOLVED

[Gene Heskett]

On Wednesday 28 August 2019 16:55:20 Greg Wooledge wrote:

> On Wed, Aug 28, 2019 at 04:04:48PM -0400, Greg Wooledge wrote:
> > He apparently wants to make his operating system refuse to register
> > persistent interface names, on the grounds that he frequently moves
> > a physical hard drive from one system to another, and doesn't want
> > to go through the hassle of reassigning the interface names each
> > time.
> >
> > If you know a way to do that other than the ways I suggested, go
> > ahead and tell us.
>
> This came up by surprise in IRC for a totally unrelated issue, but it
> appears to be relevant to Gene's wish set:
>
> In squeeze, wheezy, and jessie, and *possibly* stretch, the persistent
> interface names that are stored in
> /etc/udev/rules.d/70-persistent-net.rules are created by
> /lib/udev/rules.d/75-persistent-net-generator.rules.
>
> If for some reason one wishes to AVOID having udev's persistent
> interface names in these older Debian releases (and is not using the
> "predictable" net.ifnames thing in stretch), one may follow these
> steps:
>
>   touch /etc/udev/rules.d/75-persistent-net-generator.rules
>   rm /etc/udev/rules.d/70-persistent-net.rules
>
> Apparently, creating an *empty* file named
> /etc/udev/rules.d/75-persistent-net-generator.rules overrides the
> instructions in /lib/udev/rules.d/75-persistent-net-generator.rules
> and causes the generator not to run, when it would normally run.
>
That is not exactly whats been done. That /e/d/r/70-p*-net.rules file has 
only been deleted once. After a reboot, using the net.ifnames=0 kernel 
option, its re-created and reads like this:

root@GO704:~# cat /etc/udev/rules.d/70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x14e4:/sys/devices/pci:00/:00:1c.0/:02:00.0 
(tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:13:72:72:66:3c", ATTR{dev_id}=="0x0", 
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

EOF

eth0, which I fixed in /e/n/i.  And its since been rebooted quite a few 
times with no further change.  And That Is What I Wanted.  And I expect 
I could move that drive back to its original box with no further drama.

I have more interface cards ordered, but its come to my attention that 
powering the cards from separate psu's of their own, is also preventing 
them from being given a powerdown reset by power cycleing the computer. 
I can and will jumper them  to the computer 5 volts tomorrow, and that 
may well fix it.  If not, replacement cards, to be flashed to the proper 
firmware by me, are one day closer by priority mail.

> This prevents the recreation of
> /etc/udev/rules.d/70-persistent-net.rules which means your interfaces
> will not be saved across reboots.  You'll go through the fun steps of
> having the system pull interfaces out of a hat and name them, every
> single time.  Which seems to be what Gene wants.

Not what I am getting, see above.

> I have not tested this.  I am not going to.  If it doesn't work, too
> bad.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Gene Heskett]

On Wednesday 28 August 2019 16:04:48 Greg Wooledge wrote:

> On Wed, Aug 28, 2019 at 08:42:56PM +0100, Brian wrote:
> > On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote:
> > > I've resorted to the chattr on more than one occasion.  Works well
> > > if you can get it all done before before the timer runs the N-M
> > > script again.
> >
> > Users (particularly new users) who read chattr(1), and who think
> > getting their own way with chattr is a good way to go, are deluded.
> > Setting up a simple network never requires it. If you think it is -
> > you have lost.
>
> Which part of Gene's plans has ever been "simple"?

:-)

> He apparently wants to make his operating system refuse to register
> persistent interface names, on the grounds that he frequently moves
> a physical hard drive from one system to another, and doesn't want to
> go through the hassle of reassigning the interface names each time.

Thats a miss-statement. I do want persistent interface names EVEN if I 
move this boot drive to a whole new box.

> If you know a way to do that other than the ways I suggested, go ahead
> and tell us.
>
> I've already warned him that it will fail catastrophically on a system
> with more than one NIC.

This machine does in fact have 2 nic's.  And I have indeed used both at 
the same time but haven't mastered "consistently".

So lets see what sort of a mess its 70-persistent-net.rules looks like.?:
But I can't show it, it doesn't exist. This is a sorta stretch install, 
patched for running linuxcnc, complete with a buggy as hell rtai kernel.  
The keyboard, and occasionally the mouse goes away. Unplug the bt dongle 
and replug it several times, and it comes back, for 2 to 8 days. So I 
won't install it to replace my old wheezy installs that are actually 
running machinery. Until this kernel has been replaced by one that works 
100%. This one doesn't.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Gene Heskett]

On Wednesday 28 August 2019 15:42:56 Brian wrote:

> On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote:
> > I've resorted to the chattr on more than one occasion.  Works well
> > if you can get it all done before before the timer runs the N-M
> > script again.
>
> Users (particularly new users) who read chattr(1), and who think
> getting their own way with chattr is a good way to go, are deluded.
> Setting up a simple network never requires it. If you think it is -
> you have lost.

Haveing quite successfully used chattr to defeat N_M from tearing down a 
perfectly good network setup ever since N_M was introduced as Gods gift 
to Woman over a decade ago, I'll claim to have won that battle.

If you can't say something constructive Brian, please just stfu. I won't 
claim to speak for the rest of the list, but I am damned tired of your 
negative attitude. You have, I assume the same clothes to get glad in 
that you got mad in. Use them.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Brian]

On Wed 28 Aug 2019 at 03:18:59 -0400, Gene Heskett wrote:

> On Wednesday 28 August 2019 02:10:02 Andrei POPESCU wrote:
> 
> > On Ma, 27 aug 19, 14:27:02, Gene Heskett wrote:
> > > What, in wheezy
> >
> > Do you mean Debian 7?
> >
> > > /lib/udev/rules.d rule do I nuke so eth0 remains eth0 regardless of
> > >which box I put that drive in?
> >
> > Try booting with 'net.ifnames=0' on the kernel command line, though
> > I'm not sure this works in wheezy.
> >
> > /usr/share/doc/udev/README.Debian(.gz) could have more info.
> >
> Thanks Andrei, I'll take a look at that when its a "civilized" time of 
> day.

Having got there (and assuming you have had an opportunity to test),
what is your opinion?

-- 
Brian.

Re: udev being an ass

[Brian]

On Wed 28 Aug 2019 at 16:04:48 -0400, Greg Wooledge wrote:

> On Wed, Aug 28, 2019 at 08:42:56PM +0100, Brian wrote:
> > On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote:
> > 
> > > I've resorted to the chattr on more than one occasion.  Works well if you 
> > > can get it all done before before the timer runs the N-M script again.
> > 
> > Users (particularly new users) who read chattr(1), and who think
> > getting their own way with chattr is a good way to go, are deluded.
> > Setting up a simple network never requires it. If you think it is -
> > you have lost.
> 
> Which part of Gene's plans has ever been "simple"?
> 
> He apparently wants to make his operating system refuse to register
> persistent interface names, on the grounds that he frequently moves
> a physical hard drive from one system to another, and doesn't want to
> go through the hassle of reassigning the interface names each time.
> 
> If you know a way to do that other than the ways I suggested, go ahead
> and tell us.

I don't, so I won't.
 
> I've already warned him that it will fail catastrophically on a system
> with more than one NIC.

What will that achieve?

-- 
Brian.

Re: udev being an ass

[Greg Wooledge]

On Wed, Aug 28, 2019 at 04:04:48PM -0400, Greg Wooledge wrote:
> He apparently wants to make his operating system refuse to register
> persistent interface names, on the grounds that he frequently moves
> a physical hard drive from one system to another, and doesn't want to
> go through the hassle of reassigning the interface names each time.
> 
> If you know a way to do that other than the ways I suggested, go ahead
> and tell us.

This came up by surprise in IRC for a totally unrelated issue, but it
appears to be relevant to Gene's wish set:

In squeeze, wheezy, and jessie, and *possibly* stretch, the persistent
interface names that are stored in
/etc/udev/rules.d/70-persistent-net.rules are created by
/lib/udev/rules.d/75-persistent-net-generator.rules.

If for some reason one wishes to AVOID having udev's persistent interface
names in these older Debian releases (and is not using the "predictable"
net.ifnames thing in stretch), one may follow these steps:

  touch /etc/udev/rules.d/75-persistent-net-generator.rules
  rm /etc/udev/rules.d/70-persistent-net.rules

Apparently, creating an *empty* file named
/etc/udev/rules.d/75-persistent-net-generator.rules overrides the
instructions in /lib/udev/rules.d/75-persistent-net-generator.rules
and causes the generator not to run, when it would normally run.

This prevents the recreation of /etc/udev/rules.d/70-persistent-net.rules
which means your interfaces will not be saved across reboots.  You'll
go through the fun steps of having the system pull interfaces out of
a hat and name them, every single time.  Which seems to be what Gene
wants.

I have not tested this.  I am not going to.  If it doesn't work, too
bad.

Re: udev being an ass

[Greg Wooledge]

On Wed, Aug 28, 2019 at 08:42:56PM +0100, Brian wrote:
> On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote:
> 
> > I've resorted to the chattr on more than one occasion.  Works well if you 
> > can get it all done before before the timer runs the N-M script again.
> 
> Users (particularly new users) who read chattr(1), and who think
> getting their own way with chattr is a good way to go, are deluded.
> Setting up a simple network never requires it. If you think it is -
> you have lost.

Which part of Gene's plans has ever been "simple"?

He apparently wants to make his operating system refuse to register
persistent interface names, on the grounds that he frequently moves
a physical hard drive from one system to another, and doesn't want to
go through the hassle of reassigning the interface names each time.

If you know a way to do that other than the ways I suggested, go ahead
and tell us.

I've already warned him that it will fail catastrophically on a system
with more than one NIC.

Re: udev being an ass

[Brian]

On Wed 28 Aug 2019 at 15:05:18 -0400, Gene Heskett wrote:

> I've resorted to the chattr on more than one occasion.  Works well if you 
> can get it all done before before the timer runs the N-M script again.

Users (particularly new users) who read chattr(1), and who think
getting their own way with chattr is a good way to go, are deluded.
Setting up a simple network never requires it. If you think it is -
you have lost.

-- 
Brian.

Re: udev being an ass

[Gene Heskett]

On Wednesday 28 August 2019 12:53:15 Greg Wooledge wrote:

> On Wed, Aug 28, 2019 at 12:26:05PM -0400, Gene Heskett wrote:
> > So: delete /etc/udev/rules.d/70-persistent-net.rules AND edit /e/n/i
> > to put it back on eth0 where it belongs and it should work.
>
> Only on machines that have precisely ONE (1) network interface.  On
> any machine with more than one, you will have a disaster.
>
> > But I want that file deleted at every bootup before any attempt to
> > use it is made.
>
> How about deleting it during shutdown, instead of during boot?
>
> > So I'm going to go out and see if that can be made to work by
> > deleting that file as the first line of if-up...
>
> It's much too late at that point ... unless your intent was actually
> to delete it for the NEXT boot, similar to my suggestion above, in
> which you delete it during system shutdown.  In that case, it might
> kinda sorta not fail, by accident.  It's certainly not *obvious* that
> you're deleting it for the next boot at that point, so the intent of
> your changes would be completely opaque to future-you.  I do not
> advise it.
>
> A slightly less horrible alternative might be to delete all the
> non-comment lines from the file, add a comment that says "this file
> is intentionally empty because I made it so", then chattr +i the
> file.  That should prevent udev from registering interfaces in it for
> future boots.  It also has the advantage (over "delete during
> shutdown") that it'll still achieve your goal even if the system isn't
> shut down normally (e.g. power loss, or major kernel crash).
>
> Or, hell, for all I know, there may be some configuration knob in udev
> that says "never register my interface names in a file", and you can
> just find and turn that knob.

Instant reaction, Greg: Paranoia reigns supreme, so they would never, 
ever, in a million years, give the user such a knob.

I've resorted to the chattr on more than one occasion.  Works well if you 
can get it all done before before the timer runs the N-M script again.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Gene Heskett]

On Wednesday 28 August 2019 11:38:14 David Wright wrote:

> On Wed 28 Aug 2019 at 03:07:24 (-0400), Gene Heskett wrote:
> > On Tuesday 27 August 2019 23:54:02 David Wright wrote:
> > > On Tue 27 Aug 2019 at 19:51:21 (-0400), Gene Heskett wrote:
> > > > On Tuesday 27 August 2019 17:44:18 David Wright wrote:
> > > > > On Tue 27 Aug 2019 at 21:39:52 (+0100), Brian wrote:
> > > > > > On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > > > > > > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > > > > > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett 
 wrote:
> > > > > > > > > I've just swapped machines because that failed one got
> > > > > > > > > nailed by a lightning surge while I was in the shop
> > > > > > > > > with a heart attack.  3 different psu's didn't restore
> > > > > > > > > the green led in a decade old dell, so I swapped the
> > > > > > > > > whole box except for the HD.
> > > > > > > > >
> > > > > > > > > But udevs UN-persistent rules have apparently run out
> > > > > > > > > of eth0 names, renaming the only ethernet port it has
> > > > > > > > > to eth2.  So I either rename it to eth2 in /e/n/i, or
> > > > > > > > > kill the rule that advances the name. Since those old
> > > > > > > > > dells only come with one port, I'd much druther have a
> > > > > > > > > fixed name.
> > > > > > > > >
> > > > > > > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so
> > > > > > > > > eth0 remains eth0 regardless of which box I put that
> > > > > > > > > drive in?
> > > > > > > > >
> > > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > I usually just blow away
> > > > > > > > /etc/udev/rules.d/70-persistent-net.rules to solve stuff
> > > > > > > > like that... I'm not absolutely sure that's the same in
> > > > > > > > Wheezy though.
> > > > > > >
> > > > > > > I'll do it, but the date on it is today, so I suspect
> > > > > > > something in /lib/udev/rules.d is behind the re-write. 
> > > > > > > And thats probably where to apply the nuclear option. 
> > > > > > > They really should have renamed it 70-un-persistent-net.
> > > > > > > T'would have been a much more accurate description.
> > > > > >
> > > > > > In spite of posts about it in -user, you are just about
> > > > > > clueless about status of
> > > > > > /etc/udev/rules.d/70-persistent-net.rules, aren't you?
> > > > > >
> > > > > > As for wheezy - deary me; we are living in the past.
> > > > >
> > > > > Evidently, Gene never got round to writing the script
> > > > > mentioned in:
> > > > > https://lists.debian.org/debian-user/2016/05/msg00707.html
> > > > > which would have cleaned
> > > > > /etc/udev/rules.d/70-persistent-net.rules already.
> > > >
> > > > one must have a working network before any such script can be
> > > > posted. next fictitious request?
> > >
> > > I didn't ask you to post a script. Three years ago I suggested
> > > you write one that would erase the contents of
> > > /etc/udev/rules.d/70-persistent-net.rules and you replied:
> > >
> > > "Now thats a jolly good idea, so next time it has to start
> > > from scratch."
> >
> > Its still a good idea, but I have a now faint memory of not doing it
> > because I couldn't figure out where in the init sequence to put it.
> > Maybe incorporate it as the first line of the if-up?
>
> Possibly. But it does mean you could never check whether udev did its
> job correctly because you'd only ever see an empty/absent file.
> Perhaps better to install it as a /etc/init.d/foo script that's
> run by, say, a K09foo link in /etc/rc0.d/ (I take it you're using
> sysvinit in wheezy. I only have a fossil squeeze system to look at.)
> It appears that K08ifupdown would have run by then, assuming these
> K numbers are venerable.
>
I think they are, or at least were. But someone claimed it worked for 
wheezy so I used the kernel "net.ifnames=0", which worked well while I 
played with cables trying to determine which of the interface cards, or 
all 3, that I needed to order. 3.3 volt fpga's are a bit fragile when 
mother nature is playing with fireworks. :(

Thanks David. 1st of 2 instant Problems solved. Money will fix the other.

> > > I guess you've forgotten that you had exactly the same problem
> > > with the persistence of /etc/udev/rules.d/70-persistent-net.rules
> > > three years ago. If you'd implemented the script, you wouldn't
> > > have had the same problem today.
>
> Cheers,
> David.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Greg Wooledge]

On Wed, Aug 28, 2019 at 12:26:05PM -0400, Gene Heskett wrote:
> So: delete /etc/udev/rules.d/70-persistent-net.rules AND edit /e/n/i to 
> put it back on eth0 where it belongs and it should work.

Only on machines that have precisely ONE (1) network interface.  On any
machine with more than one, you will have a disaster.

> But I want that file deleted at every bootup before any attempt to use it 
> is made.

How about deleting it during shutdown, instead of during boot?

> So I'm going to go out and see if that can be made to work by 
> deleting that file as the first line of if-up...

It's much too late at that point ... unless your intent was actually
to delete it for the NEXT boot, similar to my suggestion above, in
which you delete it during system shutdown.  In that case, it might
kinda sorta not fail, by accident.  It's certainly not *obvious* that
you're deleting it for the next boot at that point, so the intent of
your changes would be completely opaque to future-you.  I do not
advise it.

A slightly less horrible alternative might be to delete all the
non-comment lines from the file, add a comment that says "this file
is intentionally empty because I made it so", then chattr +i the
file.  That should prevent udev from registering interfaces in it for
future boots.  It also has the advantage (over "delete during shutdown")
that it'll still achieve your goal even if the system isn't shut down
normally (e.g. power loss, or major kernel crash).

Or, hell, for all I know, there may be some configuration knob in udev
that says "never register my interface names in a file", and you can
just find and turn that knob.

Re: udev being an ass

[Gene Heskett]

On Wednesday 28 August 2019 10:54:56 Curt wrote:

> On 2019-08-28, Gene Heskett  wrote:
> > It may, looks as  if it could, but by itself lacks sufficient
> > context to ring any bells.
>
> https://www.mail-archive.com/debian-user@lists.debian.org/msg747147.ht
>ml
>
>  Drop Revert-udev-network-device-renaming-immediately-give.patch.
> ...
>  In case you rely on the udev renaming mechanism now would be a good
>  time to switch to the new scheme
>
> AFAIK, '/etc/udev/rules.d/70-persistent-net.rules' is the udev network
> device renaming mechanism (which won't work without the patch, I
> guess).
>
> > Cheers, Gene Heskett

What I am getting out of all this, is that its worked once before, 
renaming eth0 to eth1, as it says in /e/n/i now. But its now trying to 
bring up eth2. But eth2 does not exist. I'll search dmesg again to make 
sure.

So: delete /etc/udev/rules.d/70-persistent-net.rules AND edit /e/n/i to 
put it back on eth0 where it belongs and it should work.

But I want that file deleted at every bootup before any attempt to use it 
is made. So I'm going to go out and see if that can be made to work by 
deleting that file as the first line of if-up...

But still couldn't find what looked like the right place.  So I used the 
grub line above. Works. A new 70-persistent-net.rules file is created 
and its correct for eth0.

Now I've got to figure out whats blown in the interfaces, the symptoms 
resemble a failure of the high speed seriel communications.

But thats a different problem entirely, this instant problem seems to be 
solved.  Thanks to all that contributed to my education on this.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[David Wright]

On Wed 28 Aug 2019 at 03:07:24 (-0400), Gene Heskett wrote:
> On Tuesday 27 August 2019 23:54:02 David Wright wrote:
> > On Tue 27 Aug 2019 at 19:51:21 (-0400), Gene Heskett wrote:
> > > On Tuesday 27 August 2019 17:44:18 David Wright wrote:
> > > > On Tue 27 Aug 2019 at 21:39:52 (+0100), Brian wrote:
> > > > > On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > > > > > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > > > > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett 
> > > > > > >  wrote:
> > > > > > > > I've just swapped machines because that failed one got
> > > > > > > > nailed by a lightning surge while I was in the shop with a
> > > > > > > > heart attack.  3 different psu's didn't restore the green
> > > > > > > > led in a decade old dell, so I swapped the whole box
> > > > > > > > except for the HD.
> > > > > > > >
> > > > > > > > But udevs UN-persistent rules have apparently run out of
> > > > > > > > eth0 names, renaming the only ethernet port it has to
> > > > > > > > eth2.  So I either rename it to eth2 in /e/n/i, or kill
> > > > > > > > the rule that advances the name. Since those old dells
> > > > > > > > only come with one port, I'd much druther have a fixed
> > > > > > > > name.
> > > > > > > >
> > > > > > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0
> > > > > > > > remains eth0 regardless of which box I put that drive in?
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > >
> > > > > > > I usually just blow away
> > > > > > > /etc/udev/rules.d/70-persistent-net.rules to solve stuff
> > > > > > > like that... I'm not absolutely sure that's the same in
> > > > > > > Wheezy though.
> > > > > >
> > > > > > I'll do it, but the date on it is today, so I suspect
> > > > > > something in /lib/udev/rules.d is behind the re-write.  And
> > > > > > thats probably where to apply the nuclear option.  They really
> > > > > > should have renamed it 70-un-persistent-net. T'would have been
> > > > > > a much more accurate description.
> > > > >
> > > > > In spite of posts about it in -user, you are just about clueless
> > > > > about status of /etc/udev/rules.d/70-persistent-net.rules,
> > > > > aren't you?
> > > > >
> > > > > As for wheezy - deary me; we are living in the past.
> > > >
> > > > Evidently, Gene never got round to writing the script mentioned
> > > > in: https://lists.debian.org/debian-user/2016/05/msg00707.html
> > > > which would have cleaned /etc/udev/rules.d/70-persistent-net.rules
> > > > already.
> > >
> > > one must have a working network before any such script can be
> > > posted. next fictitious request?
> >
> > I didn't ask you to post a script. Three years ago I suggested
> > you write one that would erase the contents of
> > /etc/udev/rules.d/70-persistent-net.rules and you replied:
> >
> > "Now thats a jolly good idea, so next time it has to start
> > from scratch."
> >
> Its still a good idea, but I have a now faint memory of not doing it 
> because I couldn't figure out where in the init sequence to put it.  
> Maybe incorporate it as the first line of the if-up?

Possibly. But it does mean you could never check whether udev did its
job correctly because you'd only ever see an empty/absent file.
Perhaps better to install it as a /etc/init.d/foo script that's
run by, say, a K09foo link in /etc/rc0.d/ (I take it you're using
sysvinit in wheezy. I only have a fossil squeeze system to look at.)
It appears that K08ifupdown would have run by then, assuming these
K numbers are venerable.

> > I guess you've forgotten that you had exactly the same problem
> > with the persistence of /etc/udev/rules.d/70-persistent-net.rules
> > three years ago. If you'd implemented the script, you wouldn't have
> > had the same problem today.

Cheers,
David.

Re: udev being an ass

[Curt]

On 2019-08-28, Gene Heskett  wrote:
>
> It may, looks as  if it could, but by itself lacks sufficient context to 
> ring any bells.

https://www.mail-archive.com/debian-user@lists.debian.org/msg747147.html

 Drop Revert-udev-network-device-renaming-immediately-give.patch.
...
 In case you rely on the udev renaming mechanism now would be a good
 time to switch to the new scheme

AFAIK, '/etc/udev/rules.d/70-persistent-net.rules' is the udev network
device renaming mechanism (which won't work without the patch, I
guess).

> Cheers, Gene Heskett


-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

Re: udev being an ass

[David Wright]

On Wed 28 Aug 2019 at 03:00:01 (-0400), Gene Heskett wrote:
> On Tuesday 27 August 2019 23:42:25 David Wright wrote:
> > On Tue 27 Aug 2019 at 19:41:41 (-0400), Gene Heskett wrote:
> > > On Tuesday 27 August 2019 17:38:34 David Wright wrote:
> > > > On Tue 27 Aug 2019 at 16:13:25 (-0400), Greg Wooledge wrote:
> > > > > On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> > > > > > I'll do it, but the date on it is today, so I suspect
> > > > > > something in /lib/udev/rules.d is behind the re-write.
> > > > >
> > > > > If that file exists, it's used.  Quotes in the file are ignored.
> > > > > Valid content in the file is used to map various interfaces
> > > > > (typically identified by their MAC addresses) to interface
> > > > > names.
> > > > >
> > > > > If the file does not exist, it will be (re)created.
> > > > >
> > > > > If the file exists, but your interface isn't in it (as
> > > > > determined by whatever criteria are being used to identify the
> > > > > interface, typically the MAC address), then a new name will be
> > > > > assigned for it (skipping the names that are already in use),
> > > > > and this will be written to the file.
> > > > >
> > > > > So, the suggestion was to remove the file from the system before
> > > > > replacing all your interfaces (or moving the hard drive to a new
> > > > > computer, which from the hard drive's point of view is
> > > > > equivalent to "you replaced all the interfaces").  In that
> > > > > situation, the file doesn't exist, so it will be created from
> > > > > scratch.  You've got one or more interfaces that don't (yet)
> > > > > have assigned names, so names will be assigned to them.  One of
> > > > > them will become eth0, one of them will become eth1, and so on,
> > > > > depending on how many interfaces there are in the new machine.
> > > > >
> > > > > If you have exactly one interface, it will become eth0, and you
> > > > > will be happy.
> > > > >
> > > > > If you have more than one interface, you have no way of knowing
> > > > > which one will become eth0.  That's the situation the newfangled
> > > > > thing was intended to remedy, but it doesn't really succeed at
> > > > > that either.
> > > >
> > > > I think you're being oblique. There's a race. The udev method was
> > > > not designed to eliminate that, but to make sure that the
> > > > resulting names would forever be the same, once the race has been
> > > > run the first time.
> > > >
> > > > In the past, when I have had a mobo fail and moved everything into
> > > > a spare box, I've found that the new machine (I assume it's the
> > > > CMOS sensu lato) is happiest when you add one card at a time, run
> > > > the POST and let the CMOS deal with it; then add the next.
> > > > In a similar manner, you *could* fix the race by booting up linux
> > > > with one new interface at a time …
> > > >
> > > > > In almost every situation, you need to let the computer ASSIGN
> > > > > the names first, then login to it and see what interface got
> > > > > what name, and then adjust your configs accordingly.
> > > >
> > > > … but really there's no need, because it's obvious from the rules
> > > > file what is going on.
> > > >
> > > >   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> > > >   ATTR{address}=="00:a0:24:93:4d:8e", ATTR{dev_id}=="0x0", \
> > > >   ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> > > >
> > > >   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> > > >   ATTR{address}=="00:a0:24:b8:63:b5", ATTR{dev_id}=="0x0", \
> > > >   ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
> > >
> > > Add another stanza that ends with eth2.
> > >
> > > And normally, one expects to see discovery someplace in dmesg.
> > > but /dev/eth2 is not created. No /dev/eth nor is there a /dev/eth*
> > > anyplace in the dmesg.  Nor have I found a 6 doublet MAC address.
> >
> > Why? Here's an entry from one of my laptops:
> >
> > # USB device 0x:0x (ndiswrapper)
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> > ATTR{address}=="c4:3d:c7:bf:8d:0e", ATTR{dev_id}=="0x0", \
> > ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
> >
> Nothing even remotely resembling that in my dmesg from that machine.  

Wait a minute: you've just proved that you recognise stanzas in
/etc/udev/rules.d/70-persistent-net.rules, so why are you looking for
it in dmesg? And anyway, all the stanzas listed here are from my
machines, not yours.

> Since I have to goto the machine, which I'll do much later today, and 
> see if I can still make notes that make sense. I'll start by 
> editing /e/n/i to use the eth2 I do see.

Why bother to do that: when you're lining up the sights on a mounted
gun, why would you start shifting the target around?

> > That entry is over five years old, from when I briefly used a Netgear
> > wifi stick in it. Why should dmesg know anything about it today?
> 
> Good question, David. Here all this time I've been convinced that dmesgs 
> were always freshly generated.

They are. That's why my dmesg doesn't 

Re: udev being an ass

[Gene Heskett]

On Wednesday 28 August 2019 08:34:17 Curt wrote:

> On 2019-08-28, Gene Heskett  wrote:
> >> in Bullseye it appears that
> >> '/etc/udev/rules.d/70-persistent-net.rules' won't even kind of sort
> >> of maybe work in specifically unspecified cases (if I understood a
> >> recent announcement here correctly).
> >
> > A link?
>
> https://www.mail-archive.com/debian-user@lists.debian.org/msg747147.ht
>ml
>
> When I saw this, after splitting a gut, I thought this kind of sort of
> maybe meant that.

It may, looks as  if it could, but by itself lacks sufficient context to 
ring any bells.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Curt]

On 2019-08-28, Gene Heskett  wrote:
>
>> in Bullseye it appears that 
>> '/etc/udev/rules.d/70-persistent-net.rules' won't even kind of sort of
>> maybe work in specifically unspecified cases (if I understood a recent
>> announcement here correctly).
>
> A link?
>

https://www.mail-archive.com/debian-user@lists.debian.org/msg747147.html

When I saw this, after splitting a gut, I thought this kind of sort of
maybe meant that.


-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

Re: udev being an ass

[Gene Heskett]

On Wednesday 28 August 2019 05:58:09 Curt wrote:

> On 2019-08-27, Gene Heskett  wrote:
> >> In spite of posts about it in -user, you are just about clueless
> >> about status of /etc/udev/rules.d/70-persistent-net.rules, aren't
> >> you?
> >
> > I can read them just fine. But when written in swahili, they aren't
> > that easy to understand. But first, make them do as they should do. 
> > And write them in English so they can be understood.
>
> "Deprecated" in Squeeze, "officially unsupported" (wonderful Orwellian
> techno-speak, I guess, but maybe within these parentheses one should
> simply write 'sic') in Buster according to the release notes, although
> "it may still work" (the specific circumstances under which it does is
> left as an exercise for the reader),

luverly, just friggin luverly.

> in Bullseye it appears that 
> '/etc/udev/rules.d/70-persistent-net.rules' won't even kind of sort of
> maybe work in specifically unspecified cases (if I understood a recent
> announcement here correctly).

A link?

> Got it?

No, that figure in the corner, crying unconsoleably, is me..

Following that line of reasoning, means that somewhere, someone has an 
idea to move it to systemd. Obviously I'll need another pot of coffee, 
first pot is making now, before I'm wired enough that starts to make 
sense or nonesense.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Curt]

On 2019-08-27, Gene Heskett  wrote:
>>
>> In spite of posts about it in -user, you are just about clueless about
>> status of /etc/udev/rules.d/70-persistent-net.rules, aren't you?
>>
> I can read them just fine. But when written in swahili, they aren't that 
> easy to understand. But first, make them do as they should do.  And 
> write them in English so they can be understood.
>  

"Deprecated" in Squeeze, "officially unsupported" (wonderful Orwellian
techno-speak, I guess, but maybe within these parentheses one should
simply write 'sic') in Buster according to the release notes, although
"it may still work" (the specific circumstances under which it does is
left as an exercise for the reader), in Bullseye it appears that
'/etc/udev/rules.d/70-persistent-net.rules' won't even kind of sort of
maybe work in specifically unspecified cases (if I understood a recent
announcement here correctly).

Got it?

-- 
“We are all in the gutter, but some of us are looking at the stars.” 
― Oscar Wilde, Lady Windermere's Fan

Re: udev being an ass

[Gene Heskett]

On Wednesday 28 August 2019 02:35:51 Felix Miata wrote:

> Andrei POPESCU composed on 2019-08-28 09:10 (UTC+0300):
> > Gene Heskett wrote:
> >> What, in wheezy
> >
> > Do you mean Debian 7?
> >
> >> /lib/udev/rules.d rule do I nuke so eth0 remains eth0 regardless of
> >> which box I put that drive in?
> >
> > Try booting with 'net.ifnames=0' on the kernel command line, though
> > I'm not sure this works in wheezy.
>
> It's what I have on my remaining 64 bit Wheezy, resulting in eth0 as
> only networking device.

Thanks Felix. Who knows, might make this thing work again!

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Gene Heskett]

On Wednesday 28 August 2019 02:10:02 Andrei POPESCU wrote:

> On Ma, 27 aug 19, 14:27:02, Gene Heskett wrote:
> > What, in wheezy
>
> Do you mean Debian 7?
>
> > /lib/udev/rules.d rule do I nuke so eth0 remains eth0 regardless of
> >which box I put that drive in?
>
> Try booting with 'net.ifnames=0' on the kernel command line, though
> I'm not sure this works in wheezy.
>
> /usr/share/doc/udev/README.Debian(.gz) could have more info.
>
Thanks Andrei, I'll take a look at that when its a "civilized" time of 
day.

> Kind regards,
> Andrei


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Gene Heskett]

On Wednesday 28 August 2019 01:45:04 Felmon Davis wrote:

> On Tue, 27 Aug 2019, Gene Heskett wrote:
> > On Tuesday 27 August 2019 16:01:30 Brian wrote:
> >> (P.S.
> >> Could we have posts without medical details. They make me feel
> >> quesy).
> >
> > Life, fully lived, can and will have its queasy moments.  Perhaps
> > you are overdue of an annual physical?
>
> I see Brian's point about etiquette on the list but I did notice your
> absence with either joy (all his computer problems solved!) or concern
> (no need to solve them any more!)
>
> I am glad you are ok (according as the circumstances permit).
>
Thank you.  Once the new valve is in and working, I should be good for a 
while.  Then I'll be back to my usual self with a failing wet ram. ;)

> f.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 23:54:02 David Wright wrote:

> On Tue 27 Aug 2019 at 19:51:21 (-0400), Gene Heskett wrote:
> > On Tuesday 27 August 2019 17:44:18 David Wright wrote:
> > > On Tue 27 Aug 2019 at 21:39:52 (+0100), Brian wrote:
> > > > On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > > > > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > > > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett 
 wrote:
> > > > > > > I've just swapped machines because that failed one got
> > > > > > > nailed by a lightning surge while I was in the shop with a
> > > > > > > heart attack.  3 different psu's didn't restore the green
> > > > > > > led in a decade old dell, so I swapped the whole box
> > > > > > > except for the HD.
> > > > > > >
> > > > > > > But udevs UN-persistent rules have apparently run out of
> > > > > > > eth0 names, renaming the only ethernet port it has to
> > > > > > > eth2.  So I either rename it to eth2 in /e/n/i, or kill
> > > > > > > the rule that advances the name. Since those old dells
> > > > > > > only come with one port, I'd much druther have a fixed
> > > > > > > name.
> > > > > > >
> > > > > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0
> > > > > > > remains eth0 regardless of which box I put that drive in?
> > > > > > >
> > > > > > > Thanks.
> > > > > >
> > > > > > I usually just blow away
> > > > > > /etc/udev/rules.d/70-persistent-net.rules to solve stuff
> > > > > > like that... I'm not absolutely sure that's the same in
> > > > > > Wheezy though.
> > > > >
> > > > > I'll do it, but the date on it is today, so I suspect
> > > > > something in /lib/udev/rules.d is behind the re-write.  And
> > > > > thats probably where to apply the nuclear option.  They really
> > > > > should have renamed it 70-un-persistent-net. T'would have been
> > > > > a much more accurate description.
> > > >
> > > > In spite of posts about it in -user, you are just about clueless
> > > > about status of /etc/udev/rules.d/70-persistent-net.rules,
> > > > aren't you?
> > > >
> > > > As for wheezy - deary me; we are living in the past.
> > >
> > > Evidently, Gene never got round to writing the script mentioned
> > > in: https://lists.debian.org/debian-user/2016/05/msg00707.html
> > > which would have cleaned /etc/udev/rules.d/70-persistent-net.rules
> > > already.
> >
> > one must have a working network before any such script can be
> > posted. next fictitious request?
>
> I didn't ask you to post a script. Three years ago I suggested
> you write one that would erase the contents of
> /etc/udev/rules.d/70-persistent-net.rules and you replied:
>
> "Now thats a jolly good idea, so next time it has to start
> from scratch."
>
Its still a good idea, but I have a now faint memory of not doing it 
because I couldn't figure out where in the init sequence to put it.  
Maybe incorporate it as the first line of the if-up?

> I guess you've forgotten that you had exactly the same problem
> with the persistence of /etc/udev/rules.d/70-persistent-net.rules
> three years ago. If you'd implemented the script, you wouldn't have
> had the same problem today.
>
> Cheers,
> David.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 23:42:25 David Wright wrote:

> On Tue 27 Aug 2019 at 19:41:41 (-0400), Gene Heskett wrote:
> > On Tuesday 27 August 2019 17:38:34 David Wright wrote:
> > > On Tue 27 Aug 2019 at 16:13:25 (-0400), Greg Wooledge wrote:
> > > > On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> > > > > I'll do it, but the date on it is today, so I suspect
> > > > > something in /lib/udev/rules.d is behind the re-write.
> > > >
> > > > If that file exists, it's used.  Quotes in the file are ignored.
> > > > Valid content in the file is used to map various interfaces
> > > > (typically identified by their MAC addresses) to interface
> > > > names.
> > > >
> > > > If the file does not exist, it will be (re)created.
> > > >
> > > > If the file exists, but your interface isn't in it (as
> > > > determined by whatever criteria are being used to identify the
> > > > interface, typically the MAC address), then a new name will be
> > > > assigned for it (skipping the names that are already in use),
> > > > and this will be written to the file.
> > > >
> > > > So, the suggestion was to remove the file from the system before
> > > > replacing all your interfaces (or moving the hard drive to a new
> > > > computer, which from the hard drive's point of view is
> > > > equivalent to "you replaced all the interfaces").  In that
> > > > situation, the file doesn't exist, so it will be created from
> > > > scratch.  You've got one or more interfaces that don't (yet)
> > > > have assigned names, so names will be assigned to them.  One of
> > > > them will become eth0, one of them will become eth1, and so on,
> > > > depending on how many interfaces there are in the new machine.
> > > >
> > > > If you have exactly one interface, it will become eth0, and you
> > > > will be happy.
> > > >
> > > > If you have more than one interface, you have no way of knowing
> > > > which one will become eth0.  That's the situation the newfangled
> > > > thing was intended to remedy, but it doesn't really succeed at
> > > > that either.
> > >
> > > I think you're being oblique. There's a race. The udev method was
> > > not designed to eliminate that, but to make sure that the
> > > resulting names would forever be the same, once the race has been
> > > run the first time.
> > >
> > > In the past, when I have had a mobo fail and moved everything into
> > > a spare box, I've found that the new machine (I assume it's the
> > > CMOS sensu lato) is happiest when you add one card at a time, run
> > > the POST and let the CMOS deal with it; then add the next.
> > > In a similar manner, you *could* fix the race by booting up linux
> > > with one new interface at a time …
> > >
> > > > In almost every situation, you need to let the computer ASSIGN
> > > > the names first, then login to it and see what interface got
> > > > what name, and then adjust your configs accordingly.
> > >
> > > … but really there's no need, because it's obvious from the rules
> > > file what is going on.
> > >
> > >   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> > >   ATTR{address}=="00:a0:24:93:4d:8e", ATTR{dev_id}=="0x0", \
> > >   ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> > >
> > >   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> > >   ATTR{address}=="00:a0:24:b8:63:b5", ATTR{dev_id}=="0x0", \
> > >   ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
> >
> > Add another stanza that ends with eth2.
> >
> > And normally, one expects to see discovery someplace in dmesg.
> > but /dev/eth2 is not created. No /dev/eth nor is there a /dev/eth*
> > anyplace in the dmesg.  Nor have I found a 6 doublet MAC address.
>
> Why? Here's an entry from one of my laptops:
>
> # USB device 0x:0x (ndiswrapper)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> ATTR{address}=="c4:3d:c7:bf:8d:0e", ATTR{dev_id}=="0x0", \
> ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"
>
Nothing even remotely resembling that in my dmesg from that machine.  
Since I have to goto the machine, which I'll do much later today, and 
see if I can still make notes that make sense. I'll start by 
editing /e/n/i to use the eth2 I do see.

> That entry is over five years old, from when I briefly used a Netgear
> wifi stick in it. Why should dmesg know anything about it today?

Good question, David. Here all this time I've been convinced that dmesgs 
were always freshly generated. Maybe its still plugged in?

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Felix Miata]

Andrei POPESCU composed on 2019-08-28 09:10 (UTC+0300):

> Gene Heskett wrote:

>> What, in wheezy

> Do you mean Debian 7?

>> /lib/udev/rules.d rule do I nuke so eth0 remains eth0 regardless of 
>> which box I put that drive in?

> Try booting with 'net.ifnames=0' on the kernel command line, though I'm 
> not sure this works in wheezy.

It's what I have on my remaining 64 bit Wheezy, resulting in eth0 as only
networking device.
-- 
Evolution as taught in public schools is religion, not science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: udev being an ass

[Andrei POPESCU]

On Ma, 27 aug 19, 14:27:02, Gene Heskett wrote:
> 
> What, in wheezy

Do you mean Debian 7?

> /lib/udev/rules.d rule do I nuke so eth0 remains eth0 regardless of 
>which box I put that drive in?

Try booting with 'net.ifnames=0' on the kernel command line, though I'm 
not sure this works in wheezy.

/usr/share/doc/udev/README.Debian(.gz) could have more info.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: udev being an ass

[Felmon Davis]

On Tue, 27 Aug 2019, Gene Heskett wrote:


On Tuesday 27 August 2019 16:01:30 Brian wrote:



(P.S.
Could we have posts without medical details. They make me feel quesy).


Life, fully lived, can and will have its queasy moments.  Perhaps you are
overdue of an annual physical?


I see Brian's point about etiquette on the list but I did notice your 
absence with either joy (all his computer problems solved!) or concern 
(no need to solve them any more!)


I am glad you are ok (according as the circumstances permit).

f.

--
Felmon

Re: udev being an ass

[David Wright]

On Tue 27 Aug 2019 at 19:51:21 (-0400), Gene Heskett wrote:
> On Tuesday 27 August 2019 17:44:18 David Wright wrote:
> > On Tue 27 Aug 2019 at 21:39:52 (+0100), Brian wrote:
> > > On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > > > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett  
> > > > > wrote:
> > > > > > I've just swapped machines because that failed one got nailed
> > > > > > by a lightning surge while I was in the shop with a heart
> > > > > > attack.  3 different psu's didn't restore the green led in a
> > > > > > decade old dell, so I swapped the whole box except for the HD.
> > > > > >
> > > > > > But udevs UN-persistent rules have apparently run out of eth0
> > > > > > names, renaming the only ethernet port it has to eth2.  So I
> > > > > > either rename it to eth2 in /e/n/i, or kill the rule that
> > > > > > advances the name. Since those old dells only come with one
> > > > > > port, I'd much druther have a fixed name.
> > > > > >
> > > > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0
> > > > > > remains eth0 regardless of which box I put that drive in?
> > > > > >
> > > > > > Thanks.
> > > > >
> > > > > I usually just blow away
> > > > > /etc/udev/rules.d/70-persistent-net.rules to solve stuff like
> > > > > that... I'm not absolutely sure that's the same in Wheezy
> > > > > though.
> > > >
> > > > I'll do it, but the date on it is today, so I suspect something
> > > > in /lib/udev/rules.d is behind the re-write.  And thats probably
> > > > where to apply the nuclear option.  They really should have
> > > > renamed it 70-un-persistent-net. T'would have been a much more
> > > > accurate description.
> > >
> > > In spite of posts about it in -user, you are just about clueless
> > > about status of /etc/udev/rules.d/70-persistent-net.rules, aren't
> > > you?
> > >
> > > As for wheezy - deary me; we are living in the past.
> >
> > Evidently, Gene never got round to writing the script mentioned in:
> > https://lists.debian.org/debian-user/2016/05/msg00707.html
> > which would have cleaned /etc/udev/rules.d/70-persistent-net.rules
> > already.
> 
> one must have a working network before any such script can be posted.
> next fictitious request?

I didn't ask you to post a script. Three years ago I suggested
you write one that would erase the contents of
/etc/udev/rules.d/70-persistent-net.rules and you replied:

"Now thats a jolly good idea, so next time it has to start
from scratch."

I guess you've forgotten that you had exactly the same problem
with the persistence of /etc/udev/rules.d/70-persistent-net.rules
three years ago. If you'd implemented the script, you wouldn't have
had the same problem today.

Cheers,
David.

Re: udev being an ass

[David Wright]

On Tue 27 Aug 2019 at 19:41:41 (-0400), Gene Heskett wrote:
> On Tuesday 27 August 2019 17:38:34 David Wright wrote:
> > On Tue 27 Aug 2019 at 16:13:25 (-0400), Greg Wooledge wrote:
> > > On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> > > > I'll do it, but the date on it is today, so I suspect something
> > > > in /lib/udev/rules.d is behind the re-write.
> > >
> > > If that file exists, it's used.  Quotes in the file are ignored. 
> > > Valid content in the file is used to map various interfaces
> > > (typically identified by their MAC addresses) to interface names.
> > >
> > > If the file does not exist, it will be (re)created.
> > >
> > > If the file exists, but your interface isn't in it (as determined by
> > > whatever criteria are being used to identify the interface,
> > > typically the MAC address), then a new name will be assigned for it
> > > (skipping the names that are already in use), and this will be
> > > written to the file.
> > >
> > > So, the suggestion was to remove the file from the system before
> > > replacing all your interfaces (or moving the hard drive to a new
> > > computer, which from the hard drive's point of view is equivalent to
> > > "you replaced all the interfaces").  In that situation, the file
> > > doesn't exist, so it will be created from scratch.  You've got one
> > > or more interfaces that don't (yet) have assigned names, so names
> > > will be assigned to them.  One of them will become eth0, one of them
> > > will become eth1, and so on, depending on how many interfaces there
> > > are in the new machine.
> > >
> > > If you have exactly one interface, it will become eth0, and you will
> > > be happy.
> > >
> > > If you have more than one interface, you have no way of knowing
> > > which one will become eth0.  That's the situation the newfangled
> > > thing was intended to remedy, but it doesn't really succeed at that
> > > either.
> >
> > I think you're being oblique. There's a race. The udev method was not
> > designed to eliminate that, but to make sure that the resulting names
> > would forever be the same, once the race has been run the first time.
> >
> > In the past, when I have had a mobo fail and moved everything into
> > a spare box, I've found that the new machine (I assume it's the CMOS
> > sensu lato) is happiest when you add one card at a time, run the
> > POST and let the CMOS deal with it; then add the next.
> > In a similar manner, you *could* fix the race by booting up linux
> > with one new interface at a time …
> >
> > > In almost every situation, you need to let the computer ASSIGN the
> > > names first, then login to it and see what interface got what name,
> > > and then adjust your configs accordingly.
> >
> > … but really there's no need, because it's obvious from the rules file
> > what is going on.
> >
> >   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> >   ATTR{address}=="00:a0:24:93:4d:8e", ATTR{dev_id}=="0x0", \
> >   ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> >
> >   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
> >   ATTR{address}=="00:a0:24:b8:63:b5", ATTR{dev_id}=="0x0", \
> >   ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
> >
> Add another stanza that ends with eth2.
> 
> And normally, one expects to see discovery someplace in dmesg.
> but /dev/eth2 is not created. No /dev/eth nor is there a /dev/eth* 
> anyplace in the dmesg.  Nor have I found a 6 doublet MAC address.

Why? Here's an entry from one of my laptops:

# USB device 0x:0x (ndiswrapper)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
ATTR{address}=="c4:3d:c7:bf:8d:0e", ATTR{dev_id}=="0x0", \
ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

That entry is over five years old, from when I briefly used a Netgear
wifi stick in it. Why should dmesg know anything about it today?

Lastly, I've never seen a /dev/eth* or /dev/wlan* and have no idea
who would create them or what they would be used for.

> > There's a machine with two 3Com NICs. If you don't like the
> > allocation, you just switch eth0 and eth1. (One assumes that the
> > backplanes have been physically marked so that the connectors
> > themselves can be distinguished.) So you don't need to touch
> > your configuration, by which I assume you mean /e/n/i and suchlike.
> >
> yes.
> 
> > > I do not know of any way around this, other than only ever having
> > > one interface per computer, which may work OK in some situations,
> > > but definitely not in others.

Cheers,
David.

Re: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 17:44:18 David Wright wrote:

> On Tue 27 Aug 2019 at 21:39:52 (+0100), Brian wrote:
> > On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett 
 wrote:
> > > > > I've just swapped machines because that failed one got nailed
> > > > > by a lightning surge while I was in the shop with a heart
> > > > > attack.  3 different psu's didn't restore the green led in a
> > > > > decade old dell, so I swapped the whole box except for the HD.
> > > > >
> > > > > But udevs UN-persistent rules have apparently run out of eth0
> > > > > names, renaming the only ethernet port it has to eth2.  So I
> > > > > either rename it to eth2 in /e/n/i, or kill the rule that
> > > > > advances the name. Since those old dells only come with one
> > > > > port, I'd much druther have a fixed name.
> > > > >
> > > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0
> > > > > remains eth0 regardless of which box I put that drive in?
> > > > >
> > > > > Thanks.
> > > >
> > > > I usually just blow away
> > > > /etc/udev/rules.d/70-persistent-net.rules to solve stuff like
> > > > that... I'm not absolutely sure that's the same in Wheezy
> > > > though.
> > >
> > > I'll do it, but the date on it is today, so I suspect something
> > > in /lib/udev/rules.d is behind the re-write.  And thats probably
> > > where to apply the nuclear option.  They really should have
> > > renamed it 70-un-persistent-net. T'would have been a much more
> > > accurate description.
> >
> > In spite of posts about it in -user, you are just about clueless
> > about status of /etc/udev/rules.d/70-persistent-net.rules, aren't
> > you?
> >
> > As for wheezy - deary me; we are living in the past.
>
> Evidently, Gene never got round to writing the script mentioned in:
> https://lists.debian.org/debian-user/2016/05/msg00707.html
> which would have cleaned /etc/udev/rules.d/70-persistent-net.rules
> already.

one must have a working network before any such script can be posted.
next fictitious request?

> Cheers,
> David.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 17:38:34 David Wright wrote:

> On Tue 27 Aug 2019 at 16:13:25 (-0400), Greg Wooledge wrote:
> > On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> > > I'll do it, but the date on it is today, so I suspect something
> > > in /lib/udev/rules.d is behind the re-write.
> >
> > If that file exists, it's used.  Quotes in the file are ignored. 
> > Valid content in the file is used to map various interfaces
> > (typically identified by their MAC addresses) to interface names.
> >
> > If the file does not exist, it will be (re)created.
> >
> > If the file exists, but your interface isn't in it (as determined by
> > whatever criteria are being used to identify the interface,
> > typically the MAC address), then a new name will be assigned for it
> > (skipping the names that are already in use), and this will be
> > written to the file.
> >
> > So, the suggestion was to remove the file from the system before
> > replacing all your interfaces (or moving the hard drive to a new
> > computer, which from the hard drive's point of view is equivalent to
> > "you replaced all the interfaces").  In that situation, the file
> > doesn't exist, so it will be created from scratch.  You've got one
> > or more interfaces that don't (yet) have assigned names, so names
> > will be assigned to them.  One of them will become eth0, one of them
> > will become eth1, and so on, depending on how many interfaces there
> > are in the new machine.
> >
> > If you have exactly one interface, it will become eth0, and you will
> > be happy.
> >
> > If you have more than one interface, you have no way of knowing
> > which one will become eth0.  That's the situation the newfangled
> > thing was intended to remedy, but it doesn't really succeed at that
> > either.
>
> I think you're being oblique. There's a race. The udev method was not
> designed to eliminate that, but to make sure that the resulting names
> would forever be the same, once the race has been run the first time.
>
> In the past, when I have had a mobo fail and moved everything into
> a spare box, I've found that the new machine (I assume it's the CMOS
> sensu lato) is happiest when you add one card at a time, run the
> POST and let the CMOS deal with it; then add the next.
> In a similar manner, you *could* fix the race by booting up linux
> with one new interface at a time …
>
> > In almost every situation, you need to let the computer ASSIGN the
> > names first, then login to it and see what interface got what name,
> > and then adjust your configs accordingly.
>
> … but really there's no need, because it's obvious from the rules file
> what is going on.
>
>   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
>   ATTR{address}=="00:a0:24:93:4d:8e", ATTR{dev_id}=="0x0", \
>   ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>
>   SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
>   ATTR{address}=="00:a0:24:b8:63:b5", ATTR{dev_id}=="0x0", \
>   ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
>
Add another stanza that ends with eth2.

And normally, one expects to see discovery someplace in dmesg.
but /dev/eth2 is not created. No /dev/eth nor is there a /dev/eth* 
anyplace in the dmesg.  Nor have I found a 6 doublet MAC address.
 
> There's a machine with two 3Com NICs. If you don't like the
> allocation, you just switch eth0 and eth1. (One assumes that the
> backplanes have been physically marked so that the connectors
> themselves can be distinguished.) So you don't need to touch
> your configuration, by which I assume you mean /e/n/i and suchlike.
>
yes.

> > I do not know of any way around this, other than only ever having
> > one interface per computer, which may work OK in some situations,
> > but definitely not in others.
>
> Cheers,
> David.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 16:39:52 Brian wrote:

> On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett
> > > 
> >
> > wrote:
> > > > Greetings all;
> > > >
> > > > I've just swapped machines because that failed one got nailed by
> > > > a lightning surge while I was in the shop with a heart attack. 
> > > > 3 different psu's didn't restore the green led in a decade old
> > > > dell, so I swapped the whole box except for the HD.
> > > >
> > > > But udevs UN-persistent rules have apparently run out of eth0
> > > > names, renaming the only ethernet port it has to eth2.  So I
> > > > either rename it to eth2 in /e/n/i, or kill the rule that
> > > > advances the name. Since those old dells only come with one
> > > > port, I'd much druther have a fixed name.
> > > >
> > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0
> > > > remains eth0 regardless of which box I put that drive in?
> > > >
> > > > Thanks.
> > > >
> > > > Cheers, Gene Heskett
> > > > --
> > > > "There are four boxes to be used in defense of liberty:
> > > >  soap, ballot, jury, and ammo. Please use in that order."
> > > > -Ed Howdershelt (Author)
> > > > If we desire respect for the law, we must first make the law
> > > > respectable. - Louis D. Brandeis
> > > > Genes Web page 
> > >
> > > I usually just blow away /etc/udev/rules.d/70-persistent-net.rules
> > > to solve stuff like that... I'm not absolutely sure that's the
> > > same in Wheezy though.
> >
> > I'll do it, but the date on it is today, so I suspect something
> > in /lib/udev/rules.d is behind the re-write.  And thats probably
> > where to apply the nuclear option.  They really should have renamed
> > it 70-un-persistent-net. T'would have been a much more accurate
> > description.
>
> In spite of posts about it in -user, you are just about clueless about
> status of /etc/udev/rules.d/70-persistent-net.rules, aren't you?
>
I can read them just fine. But when written in swahili, they aren't that 
easy to understand. But first, make them do as they should do.  And 
write them in English so they can be understood.
 
> As for wheezy - deary me; we are living in the past.

Get me an rtai patched kernel for buster, running on amd64 or armhf/64, 
and I'll be running buster this time two weeks down the log. On all 5 
machines here.  If not willing to help, then don't throw stones from 
your glass house.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Brian]

On Tue 27 Aug 2019 at 17:22:27 -0400, Gene Heskett wrote:

> On Tuesday 27 August 2019 16:01:30 Brian wrote:
> 
> > On Tue 27 Aug 2019 at 14:27:02 -0400, Gene Heskett wrote:
> > > Greetings all;
> > >
> > > I've just swapped machines because that failed one got nailed by a
> > > lightning surge while I was in the shop with a heart attack.  3
> > > different psu's didn't restore the green led in a decade old dell,
> > > so I swapped the whole box except for the HD.
> > >
> > > But udevs UN-persistent rules have apparently run out of eth0 names,
> > > renaming the only ethernet port it has to eth2.  So I either rename
> > > it to eth2 in /e/n/i, or kill the rule that advances the name. 
> > > Since those old dells only come with one port, I'd much druther have
> > > a fixed name.
> > >
> > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains
> > > eth0 regardless of which box I put that drive in?
> >
> > The subject header is completely uninformative. The subject body is
> > unformative but unintellible.
> 
> Oh, I'd argue the point. udev has been accused of being uptight and 
> cantankerous many times before. Surely I am not the first to call it an 
> ass.
> 
> Supposedly invented to make things more stable, but here it has never 
> been in a same building with the word stable.

I would urge all users, particularly new ones, to take little notice
of this opinion. The OP has a track record of lacing his posts with
criticism of core components of the Debian system. Generally without
evidence and, nearly always, obscuring the point he wants to make.

> OTOH, Brian, since I actually do use computers to do useful work, 
> something that seems well beyond your ability to comprehend why I should 
> want them to do real work, I will continue asking them to Just Do It. 
> Sharpening fingers pointed in my direction will generally be ignored, 
> once I have ascertained the source.
> 
> > (P.S.
> > Could we have posts without medical details. They make me feel quesy).
> 
> Life, fully lived, can and will have its queasy moments.  Perhaps you are 
> overdue of an annual physical?

I leave my family and personal matters behind when I post here. I
do not expect to encounter those from others. Taking a hint is not
your strong point, is it?

-- 
Brian.

Re: udev being an ass

[David Wright]

On Tue 27 Aug 2019 at 21:39:52 (+0100), Brian wrote:
> On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:
> > On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> > > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett  wrote:
> > > >
> > > > I've just swapped machines because that failed one got nailed by a
> > > > lightning surge while I was in the shop with a heart attack.  3
> > > > different psu's didn't restore the green led in a decade old dell,
> > > > so I swapped the whole box except for the HD.
> > > >
> > > > But udevs UN-persistent rules have apparently run out of eth0 names,
> > > > renaming the only ethernet port it has to eth2.  So I either rename
> > > > it to eth2 in /e/n/i, or kill the rule that advances the name. 
> > > > Since those old dells only come with one port, I'd much druther have
> > > > a fixed name.
> > > >
> > > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains
> > > > eth0 regardless of which box I put that drive in?
> > > >
> > > > Thanks.
> > >
> > > I usually just blow away /etc/udev/rules.d/70-persistent-net.rules to
> > > solve stuff like that... I'm not absolutely sure that's the same in
> > > Wheezy though.
> > 
> > I'll do it, but the date on it is today, so I suspect something 
> > in /lib/udev/rules.d is behind the re-write.  And thats probably where 
> > to apply the nuclear option.  They really should have renamed it 
> > 70-un-persistent-net. T'would have been a much more accurate 
> > description.
> 
> In spite of posts about it in -user, you are just about clueless about
> status of /etc/udev/rules.d/70-persistent-net.rules, aren't you?
> 
> As for wheezy - deary me; we are living in the past.

Evidently, Gene never got round to writing the script mentioned in:
https://lists.debian.org/debian-user/2016/05/msg00707.html
which would have cleaned /etc/udev/rules.d/70-persistent-net.rules
already.

Cheers,
David.

Re: udev being an ass

[David Wright]

On Tue 27 Aug 2019 at 16:13:25 (-0400), Greg Wooledge wrote:
> On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> > I'll do it, but the date on it is today, so I suspect something 
> > in /lib/udev/rules.d is behind the re-write.
> 
> If that file exists, it's used.  Quotes in the file are ignored.  Valid
> content in the file is used to map various interfaces (typically identified
> by their MAC addresses) to interface names.
> 
> If the file does not exist, it will be (re)created.
> 
> If the file exists, but your interface isn't in it (as determined by
> whatever criteria are being used to identify the interface, typically the
> MAC address), then a new name will be assigned for it (skipping the
> names that are already in use), and this will be written to the file.
> 
> So, the suggestion was to remove the file from the system before
> replacing all your interfaces (or moving the hard drive to a new
> computer, which from the hard drive's point of view is equivalent to
> "you replaced all the interfaces").  In that situation, the file doesn't
> exist, so it will be created from scratch.  You've got one or more
> interfaces that don't (yet) have assigned names, so names will be
> assigned to them.  One of them will become eth0, one of them will become
> eth1, and so on, depending on how many interfaces there are in the new
> machine.
> 
> If you have exactly one interface, it will become eth0, and you will be
> happy.
> 
> If you have more than one interface, you have no way of knowing which
> one will become eth0.  That's the situation the newfangled thing was
> intended to remedy, but it doesn't really succeed at that either.

I think you're being oblique. There's a race. The udev method was not
designed to eliminate that, but to make sure that the resulting names
would forever be the same, once the race has been run the first time.

In the past, when I have had a mobo fail and moved everything into
a spare box, I've found that the new machine (I assume it's the CMOS
sensu lato) is happiest when you add one card at a time, run the
POST and let the CMOS deal with it; then add the next.
In a similar manner, you *could* fix the race by booting up linux
with one new interface at a time …

> In almost every situation, you need to let the computer ASSIGN the names
> first, then login to it and see what interface got what name, and then
> adjust your configs accordingly.

… but really there's no need, because it's obvious from the rules file
what is going on.

  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
  ATTR{address}=="00:a0:24:93:4d:8e", ATTR{dev_id}=="0x0", \
  ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", \
  ATTR{address}=="00:a0:24:b8:63:b5", ATTR{dev_id}=="0x0", \
  ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

There's a machine with two 3Com NICs. If you don't like the
allocation, you just switch eth0 and eth1. (One assumes that the
backplanes have been physically marked so that the connectors
themselves can be distinguished.) So you don't need to touch
your configuration, by which I assume you mean /e/n/i and suchlike.

> I do not know of any way around this, other than only ever having one
> interface per computer, which may work OK in some situations, but
> definitely not in others.

Cheers,
David.

Re: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 16:01:30 Brian wrote:

> On Tue 27 Aug 2019 at 14:27:02 -0400, Gene Heskett wrote:
> > Greetings all;
> >
> > I've just swapped machines because that failed one got nailed by a
> > lightning surge while I was in the shop with a heart attack.  3
> > different psu's didn't restore the green led in a decade old dell,
> > so I swapped the whole box except for the HD.
> >
> > But udevs UN-persistent rules have apparently run out of eth0 names,
> > renaming the only ethernet port it has to eth2.  So I either rename
> > it to eth2 in /e/n/i, or kill the rule that advances the name. 
> > Since those old dells only come with one port, I'd much druther have
> > a fixed name.
> >
> > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains
> > eth0 regardless of which box I put that drive in?
>
> The subject header is completely uninformative. The subject body is
> unformative but unintellible.

Oh, I'd argue the point. udev has been accused of being uptight and 
cantankerous many times before. Surely I am not the first to call it an 
ass.

Supposedly invented to make things more stable, but here it has never 
been in a same building with the word stable.

OTOH, Brian, since I actually do use computers to do useful work, 
something that seems well beyond your ability to comprehend why I should 
want them to do real work, I will continue asking them to Just Do It. 
Sharpening fingers pointed in my direction will generally be ignored, 
once I have ascertained the source.

> (P.S.
> Could we have posts without medical details. They make me feel quesy).

Life, fully lived, can and will have its queasy moments.  Perhaps you are 
overdue of an annual physical?

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Brian]

On Tue 27 Aug 2019 at 15:50:31 -0400, Gene Heskett wrote:

> On Tuesday 27 August 2019 14:58:37 Tyler D wrote:
> 
> > On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett  
> wrote:
> > > Greetings all;
> > >
> > > I've just swapped machines because that failed one got nailed by a
> > > lightning surge while I was in the shop with a heart attack.  3
> > > different psu's didn't restore the green led in a decade old dell,
> > > so I swapped the whole box except for the HD.
> > >
> > > But udevs UN-persistent rules have apparently run out of eth0 names,
> > > renaming the only ethernet port it has to eth2.  So I either rename
> > > it to eth2 in /e/n/i, or kill the rule that advances the name. 
> > > Since those old dells only come with one port, I'd much druther have
> > > a fixed name.
> > >
> > > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains
> > > eth0 regardless of which box I put that drive in?
> > >
> > > Thanks.
> > >
> > > Cheers, Gene Heskett
> > > --
> > > "There are four boxes to be used in defense of liberty:
> > >  soap, ballot, jury, and ammo. Please use in that order."
> > > -Ed Howdershelt (Author)
> > > If we desire respect for the law, we must first make the law
> > > respectable. - Louis D. Brandeis
> > > Genes Web page 
> >
> > I usually just blow away /etc/udev/rules.d/70-persistent-net.rules to
> > solve stuff like that... I'm not absolutely sure that's the same in
> > Wheezy though.
> 
> I'll do it, but the date on it is today, so I suspect something 
> in /lib/udev/rules.d is behind the re-write.  And thats probably where 
> to apply the nuclear option.  They really should have renamed it 
> 70-un-persistent-net. T'would have been a much more accurate 
> description.

In spite of posts about it in -user, you are just about clueless about
status of /etc/udev/rules.d/70-persistent-net.rules, aren't you?

As for wheezy - deary me; we are living in the past.

-- 
Brian.

Re: udev being an ass

[Greg Wooledge]

On Tue, Aug 27, 2019 at 03:50:31PM -0400, Gene Heskett wrote:
> I'll do it, but the date on it is today, so I suspect something 
> in /lib/udev/rules.d is behind the re-write.

If that file exists, it's used.  Quotes in the file are ignored.  Valid
content in the file is used to map various interfaces (typically identified
by their MAC addresses) to interface names.

If the file does not exist, it will be (re)created.

If the file exists, but your interface isn't in it (as determined by
whatever criteria are being used to identify the interface, typically the
MAC address), then a new name will be assigned for it (skipping the
names that are already in use), and this will be written to the file.

So, the suggestion was to remove the file from the system before
replacing all your interfaces (or moving the hard drive to a new
computer, which from the hard drive's point of view is equivalent to
"you replaced all the interfaces").  In that situation, the file doesn't
exist, so it will be created from scratch.  You've got one or more
interfaces that don't (yet) have assigned names, so names will be
assigned to them.  One of them will become eth0, one of them will become
eth1, and so on, depending on how many interfaces there are in the new
machine.

If you have exactly one interface, it will become eth0, and you will be
happy.

If you have more than one interface, you have no way of knowing which
one will become eth0.  That's the situation the newfangled thing was
intended to remedy, but it doesn't really succeed at that either.

In almost every situation, you need to let the computer ASSIGN the names
first, then login to it and see what interface got what name, and then
adjust your configs accordingly.

I do not know of any way around this, other than only ever having one
interface per computer, which may work OK in some situations, but
definitely not in others.

Re: udev being an ass

[Brian]

On Tue 27 Aug 2019 at 14:27:02 -0400, Gene Heskett wrote:

> Greetings all;
> 
> I've just swapped machines because that failed one got nailed by a 
> lightning surge while I was in the shop with a heart attack.  3 
> different psu's didn't restore the green led in a decade old dell, so I 
> swapped the whole box except for the HD.
> 
> But udevs UN-persistent rules have apparently run out of eth0 names, 
> renaming the only ethernet port it has to eth2.  So I either rename it 
> to eth2 in /e/n/i, or kill the rule that advances the name.  Since those 
> old dells only come with one port, I'd much druther have a fixed name.
> 
> What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains eth0 
> regardless of which box I put that drive in?

The subject header is completely uninformative. The subject body is
unformative but unintellible.

(P.S.
Could we have posts without medical details. They make me feel quesy).

-- 
Brian

Re: udev being an ass

[Gene Heskett]

On Tuesday 27 August 2019 14:58:37 Tyler D wrote:

> On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett  
wrote:
> > Greetings all;
> >
> > I've just swapped machines because that failed one got nailed by a
> > lightning surge while I was in the shop with a heart attack.  3
> > different psu's didn't restore the green led in a decade old dell,
> > so I swapped the whole box except for the HD.
> >
> > But udevs UN-persistent rules have apparently run out of eth0 names,
> > renaming the only ethernet port it has to eth2.  So I either rename
> > it to eth2 in /e/n/i, or kill the rule that advances the name. 
> > Since those old dells only come with one port, I'd much druther have
> > a fixed name.
> >
> > What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains
> > eth0 regardless of which box I put that drive in?
> >
> > Thanks.
> >
> > Cheers, Gene Heskett
> > --
> > "There are four boxes to be used in defense of liberty:
> >  soap, ballot, jury, and ammo. Please use in that order."
> > -Ed Howdershelt (Author)
> > If we desire respect for the law, we must first make the law
> > respectable. - Louis D. Brandeis
> > Genes Web page 
>
> I usually just blow away /etc/udev/rules.d/70-persistent-net.rules to
> solve stuff like that... I'm not absolutely sure that's the same in
> Wheezy though.

I'll do it, but the date on it is today, so I suspect something 
in /lib/udev/rules.d is behind the re-write.  And thats probably where 
to apply the nuclear option.  They really should have renamed it 
70-un-persistent-net. T'would have been a much more accurate 
description.

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page 

Re: udev being an ass

[Tyler D]

On Tue, Aug 27, 2019 at 2:45 PM Gene Heskett  wrote:
>
> Greetings all;
>
> I've just swapped machines because that failed one got nailed by a
> lightning surge while I was in the shop with a heart attack.  3
> different psu's didn't restore the green led in a decade old dell, so I
> swapped the whole box except for the HD.
>
> But udevs UN-persistent rules have apparently run out of eth0 names,
> renaming the only ethernet port it has to eth2.  So I either rename it
> to eth2 in /e/n/i, or kill the rule that advances the name.  Since those
> old dells only come with one port, I'd much druther have a fixed name.
>
> What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains eth0
> regardless of which box I put that drive in?
>
> Thanks.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> If we desire respect for the law, we must first make the law respectable.
>  - Louis D. Brandeis
> Genes Web page 
>

I usually just blow away /etc/udev/rules.d/70-persistent-net.rules to
solve stuff like that... I'm not absolutely sure that's the same in
Wheezy though.

udev being an ass

[Gene Heskett]

Greetings all;

I've just swapped machines because that failed one got nailed by a 
lightning surge while I was in the shop with a heart attack.  3 
different psu's didn't restore the green led in a decade old dell, so I 
swapped the whole box except for the HD.

But udevs UN-persistent rules have apparently run out of eth0 names, 
renaming the only ethernet port it has to eth2.  So I either rename it 
to eth2 in /e/n/i, or kill the rule that advances the name.  Since those 
old dells only come with one port, I'd much druther have a fixed name.

What, in wheezy, /lib/udev/rules.d rule do I nuke so eth0 remains eth0 
regardless of which box I put that drive in?

Thanks. 

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page