Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #210495 > unrolled thread

Document removal of ecryptfs-utils from Buster

Back to article view | Back to linux.debian.user

Contents

  Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-06-30 12:00 +0200
    Re: Document removal of ecryptfs-utils from Buster Andrea Borgia <andrea@borgia.bo.it> - 2019-06-30 17:40 +0200
      Re: Document removal of ecryptfs-utils from Buster Sven Hartge <sven@svenhartge.de> - 2019-06-30 18:20 +0200
        Re: Document removal of ecryptfs-utils from Buster Gene Heskett <gheskett@shentel.net> - 2019-06-30 18:50 +0200
          Re: Document removal of ecryptfs-utils from Buster Jonathan Dowland <jmtd@debian.org> - 2019-07-01 10:00 +0200
            Re: Document removal of ecryptfs-utils from Buster Gene Heskett <gheskett@shentel.net> - 2019-07-01 12:10 +0200
              Re: Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-07-01 15:20 +0200
                Re: Document removal of ecryptfs-utils from Buster Jonathan Dowland <jmtd@debian.org> - 2019-07-01 15:50 +0200
                  Re: Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-07-01 16:10 +0200
                Re: Document removal of ecryptfs-utils from Buster Gene Heskett <gheskett@shentel.net> - 2019-07-01 22:00 +0200
              Re: Document removal of ecryptfs-utils from Buster David Wright <deblis@lionunicorn.co.uk> - 2019-07-01 15:40 +0200
                Re: Document removal of ecryptfs-utils from Buster Jonathan Dowland <jmtd@debian.org> - 2019-07-01 15:50 +0200
                Re: Document removal of ecryptfs-utils from Buster Gene Heskett <gheskett@shentel.net> - 2019-07-01 22:00 +0200
                  Re: Document removal of ecryptfs-utils from Buster Jonathan Dowland <jmtd@debian.org> - 2019-07-01 22:20 +0200
                  Re: Document removal of ecryptfs-utils from Buster David Wright <deblis@lionunicorn.co.uk> - 2019-07-02 01:50 +0200
                    Re: Document removal of ecryptfs-utils from Buster Gene Heskett <gheskett@shentel.net> - 2019-07-02 11:20 +0200
                      Re: Document removal of ecryptfs-utils from Buster Richard Hector <richard@walnut.gen.nz> - 2019-07-07 02:10 +0200
        Re: Document removal of ecryptfs-utils from Buster Andrea Borgia <andrea@borgia.bo.it> - 2019-06-30 19:00 +0200
        Re: Document removal of ecryptfs-utils from Buster Tixy <tixy@yxit.co.uk> - 2019-06-30 19:50 +0200
          Re: Document removal of ecryptfs-utils from Buster deloptes <deloptes@gmail.com> - 2019-06-30 21:20 +0200
      Re: Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-07-01 09:50 +0200
        Re: Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-07-01 16:20 +0200
          Re: Document removal of ecryptfs-utils from Buster Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-01 16:50 +0200
            Re: Document removal of ecryptfs-utils from Buster Curt <curty@free.fr> - 2019-07-01 17:50 +0200
        Re: Document removal of ecryptfs-utils from Buster Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-01 16:20 +0200
        70-persistent-net-rules no longer supported? (Was Re: Document removal  of ecryptfs-utils from Buster) The Wanderer <wanderer@fastmail.fm> - 2019-07-02 14:10 +0200
          Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Curt <curty@free.fr> - 2019-07-02 14:40 +0200
            Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) The Wanderer <wanderer@fastmail.fm> - 2019-07-02 15:00 +0200
              Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) The Wanderer <wanderer@fastmail.fm> - 2019-07-02 15:20 +0200
              Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Greg Wooledge <wooledg@eeg.ccf.org> - 2019-07-02 15:20 +0200
              Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Curt <curty@free.fr> - 2019-07-02 16:20 +0200
                Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) The Wanderer <wanderer@fastmail.fm> - 2019-07-02 16:30 +0200
                  Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Brian <ad44@cityscape.co.uk> - 2019-07-02 21:20 +0200
                    Re: 70-persistent-net-rules no longer supported? Stephan Seitz <stse+debian@fsing.rootsland.net> - 2019-07-03 09:20 +0200
                      Re: 70-persistent-net-rules no longer supported? Curt <curty@free.fr> - 2019-07-03 10:10 +0200
                      Re: 70-persistent-net-rules no longer supported? Brian <ad44@cityscape.co.uk> - 2019-07-03 11:30 +0200
                  Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Geoff <unit735@bigpond.com> - 2019-07-03 04:30 +0200
          Re: 70-persistent-net-rules no longer supported? (Was Re: Document  removal of ecryptfs-utils from Buster) Andrei POPESCU <andreimpopescu@gmail.com> - 2019-07-08 11:20 +0200

Page 2 of 2 — ← Prev page 1 [2]

#210518

On 2019-06-30, Andrea Borgia <andrea@borgia.bo.it> wrote:
> Il 30/06/19 11:52, Curt ha scritto:
>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928956
>> 
>>   Due to #765854 ecryptfs-utils has been removed from Buster.
>>   The kernel module (ecryptfs.ko) is still built but depending on the
>>   upgrade path users will be unable to mount their encrypted home
>>   directories (pam module, ecryptfs-mount-private missing).
>>   So they should probably be strongly advised to not upgrade.
>
> Should I count myself lucky that I have two systems running "testing" 
> with also "stable" sources? Perhaps it's time to mark the package as 
> "hold" :)
>
> I'd be interested to know if there is an alternative: not so much for my 
> desktop but my laptop really needs it. Thanks for the heads up, though.

I haven't yet investigated the alternatives. 

I guess I will be rolling back the encryption and purging the
incriminated software. I have nagging doubts about my encrypted swap and
whether I need to roll that back, too. I guess I will.

Another, less serious, gotcha for those inveterate upgraders and newbies
who don't read the release notes is that
'/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
mechanism for defining device names. This mechanism (automagically)
permitted users upgrading from Wheezy to Stretch (where the old-style
names were deprecated) to continue using their obsolete, legacy
interface names (eth0, anyone?).  

Me, I migrated to the new-fangled denominations as per the instructions
at the link below to obviate the eventual loss of network connectivity,
which is a bummer when you don't what you're doing and all the help
available is at the other end of the severed wire.

https://www.debian.org/releases///buster/s390x/release-notes/ch-information.en.html#migrate-interface-names

The Wanderer and other recalcitrants allergic to progress (just kidding)
can still resort to the 'net.ifname=0 kernel' command line option for
relief.

> Regards,
> Andrea.
>
>

[toc] | [prev] | [next] | [standalone]

#210541

On 2019-07-01, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> On Mon, Jul 01, 2019 at 07:47:35AM -0000, Curt wrote:
>> Another, less serious, gotcha for those inveterate upgraders and newbies
>> who don't read the release notes is that
>> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
>> mechanism for defining device names.
>
> For whatever it's worth, when I upgraded this machine from stretch to
> buster a couple months ago, it continued using eth0 as the interface
> name without any immediately obvious issues.  I did the conversion to
> "predictable interface names" anyway, just in case there might be some
> subtle problem that I wasn't yet seeing.
>
>

And you had that device name defined (as I did) in
'/etc/udev/rules.d/70-persistent-net.rules' when you upgraded?

[toc] | [prev] | [next] | [standalone]

#210545

On Mon, Jul 01, 2019 at 02:15:50PM -0000, Curt wrote:
> On 2019-07-01, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> > On Mon, Jul 01, 2019 at 07:47:35AM -0000, Curt wrote:
> >> Another, less serious, gotcha for those inveterate upgraders and newbies
> >> who don't read the release notes is that
> >> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
> >> mechanism for defining device names.
> >
> > For whatever it's worth, when I upgraded this machine from stretch to
> > buster a couple months ago, it continued using eth0 as the interface
> > name without any immediately obvious issues.  I did the conversion to
> > "predictable interface names" anyway, just in case there might be some
> > subtle problem that I wasn't yet seeing.
> >
> >
> 
> And you had that device name defined (as I did) in
> '/etc/udev/rules.d/70-persistent-net.rules' when you upgraded?

Yes.  In fact it's still there, but I commented it out by hand after
the buster upgrade.

wooledg:~$ 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 0x8086:0x15b7 (e1000e)
# SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:8c:fd:c3:89:e0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

[toc] | [prev] | [next] | [standalone]

#210553

On 2019-07-01, Greg Wooledge <wooledg@eeg.ccf.org> wrote:
>> >
>> > For whatever it's worth, when I upgraded this machine from stretch to
>> > buster a couple months ago, it continued using eth0 as the interface
>> > name without any immediately obvious issues.  I did the conversion to
>> > "predictable interface names" anyway, just in case there might be some
>> > subtle problem that I wasn't yet seeing.
>> 
>> And you had that device name defined (as I did) in
>> '/etc/udev/rules.d/70-persistent-net.rules' when you upgraded?
>
> Yes.  In fact it's still there, but I commented it out by hand after
> the buster upgrade.
>
> wooledg:~$ 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 0x8086:0x15b7 (e1000e)
> # SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="a0:8c:fd:c3:89:e0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>
>

Assuming the name was not also defined elsewhere, I'm at a loss to know
why the release notes for Buster state 

 ...you should be aware that udev in buster no
 longer supports the mechanism of defining their names via
 /etc/udev/rules.d/70-persistent-net.rules. To avoid the danger of your
 machine losing networking after the upgrade to buster, it is recommended
 that you migrate in advance to the new naming scheme...

Well, I'm enp6s0 anyway now and somehow feel better about it.

[toc] | [prev] | [next] | [standalone]

#210542

On Mon, Jul 01, 2019 at 07:47:35AM -0000, Curt wrote:
> Another, less serious, gotcha for those inveterate upgraders and newbies
> who don't read the release notes is that
> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid
> mechanism for defining device names.

For whatever it's worth, when I upgraded this machine from stretch to
buster a couple months ago, it continued using eth0 as the interface
name without any immediately obvious issues.  I did the conversion to
"predictable interface names" anyway, just in case there might be some
subtle problem that I wasn't yet seeing.

[toc] | [prev] | [next] | [standalone]

#210597 — 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[Multipart message — attachments visible in raw view] — view raw

On 2019-07-01 at 03:47, Curt wrote:

> Another, less serious, gotcha for those inveterate upgraders and
> newbies who don't read the release notes is that 
> '/etc/udev/rules.d/70-persistent-net.rules' is no longer a valid 
> mechanism for defining device names. This mechanism (automagically) 
> permitted users upgrading from Wheezy to Stretch (where the
> old-style names were deprecated) to continue using their obsolete,
> legacy interface names (eth0, anyone?).
> 
> Me, I migrated to the new-fangled denominations as per the
> instructions at the link below to obviate the eventual loss of
> network connectivity, which is a bummer when you don't what you're
> doing and all the help available is at the other end of the severed
> wire.
> 
> https://www.debian.org/releases///buster/s390x/release-notes/ch-information.en.html#migrate-interface-names

(Any particular reason you linked to the s390x version of the release
notes? It seems to match e.g. the amd64 one for this purpose, so it
shouldn't make a difference, it's just a little unexpected.)

I'm skeptical as to whether this is (still/currently) accurate.

After reading the conversation in the ensuing subthread about cases
where the old-style names as defined in that file were still picked up
and used without troubles after a buster upgrade, I went looking for
more information.

/usr/share/doc/udev/README.Debian.gz has a section on the subject of
migration from the old naming scheme to the new one. Although it does
not seem to state as much explicitly, from that section (and other parts
of the file related to interface names), it appears as if this detail
may apply only to machines running systemd. In particular, the file's
multiple references to /etc/systemd/network/99-default.link seem as if
they may be relevant.

Searching /usr/share/doc/udev/changelog.Debian.gz for 'interfaces' found
a reference to bug 919390, which seems to be about someone reporting
this behavior as a bug. That bug has been closed as "fixed upstream",
and that closure is what I found in the changelog. The patch which fixes
the bug was committed as being a revert of an earlier change. That
commit happened in January, and the package was released to unstable on
January 27th; it's long since made it to testing, i.e., buster.

It's still possible that there's other activity which affects all of
this and which I've missed (related to the non-udev systemd packages,
most likely), but at a glance, it looks as if the release notes and the
README alike may be inaccurate / out of date. Even if they aren't, it
looks as if they may be incomplete, by describing only the situation as
it affects machines with systemd.


Although I don't run systemd on this machine, and my second system which
used to have it (and I think still does) doesn't use it as the init
system, I manage a very minor server at work which does use it as init
system. In the event that we actually upgrade that server rather than
migrating its service to another machine, this change may wind up being
relevant to me; I'll want to keep it in mind.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#210599 — Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

On 2019-07-02, The Wanderer <wanderer@fastmail.fm> wrote:

>> https://www.debian.org/releases///buster/s390x/release-notes/ch-informa=
> tion.en.html#migrate-interface-names
>
> (Any particular reason you linked to the s390x version of the release
> notes? It seems to match e.g. the amd64 one for this purpose, so it
> shouldn't make a difference, it's just a little unexpected.)

I screwed up and didn't realize, but that guy in Philly running Debian
on an IBM mainframe feels less left out maybe.

> I'm skeptical as to whether this is (still/currently) accurate.

Me too, after speaking briefly over the wire with Greg Wooledge.

> After reading the conversation in the ensuing subthread about cases
> where the old-style names as defined in that file were still picked up
> and used without troubles after a buster upgrade, I went looking for
> more information.

That's the spirit.

> /usr/share/doc/udev/README.Debian.gz has a section on the subject of
> migration from the old naming scheme to the new one. Although it does
> not seem to state as much explicitly, from that section (and other parts
> of the file related to interface names), it appears as if this detail
> may apply only to machines running systemd. In particular, the file's
> multiple references to /etc/systemd/network/99-default.link seem as if
> they may be relevant.

Well, in the bug thread 919390 referenced below Martin Pitt does say

 We believe that the bug you reported is fixed in the latest version of
 systemd, which is due to be installed in the Debian FTP archive.

"in the latest version of systemd."

> Searching /usr/share/doc/udev/changelog.Debian.gz for 'interfaces' found
> a reference to bug 919390, which seems to be about someone reporting
> this behavior as a bug. That bug has been closed as "fixed upstream",
> and that closure is what I found in the changelog. The patch which fixes
> the bug was committed as being a revert of an earlier change. That
> commit happened in January, and the package was released to unstable on
> January 27th; it's long since made it to testing, i.e., buster.

That appears to be correct from a rapid perusal of the referenced
bug.

> It's still possible that there's other activity which affects all of
> this and which I've missed (related to the non-udev systemd packages,
> most likely), but at a glance, it looks as if the release notes and the
> README alike may be inaccurate / out of date. Even if they aren't, it
> looks as if they may be incomplete, by describing only the situation as
> it affects machines with systemd.

Not even that, it seems (no longer affects systemd).

> Although I don't run systemd on this machine, and my second system which
> used to have it (and I think still does) doesn't use it as the init
> system, I manage a very minor server at work which does use it as init
> system. In the event that we actually upgrade that server rather than
> migrating its service to another machine, this change may wind up being
> relevant to me; I'll want to keep it in mind.

I was going to upgrade to Buster a couple of weeks ahead of time, taking
the bull by the horns for once rather than procrastinating, which is my
ultimate tendency in life, and began reading the release notes (for the
wrong architecture, but, come on, nobody's perfect). It never crossed my
mind to doubt the accuracy of those notes until yesterday when Greg
piped up. 

Maybe we should file a bug report against the release notes.

[toc] | [prev] | [next] | [standalone]

#210601 — Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[Multipart message — attachments visible in raw view] — view raw

On 2019-07-02 at 08:37, Curt wrote:

> On 2019-07-02, The Wanderer <wanderer@fastmail.fm> wrote:

>> /usr/share/doc/udev/README.Debian.gz has a section on the subject
>> of migration from the old naming scheme to the new one. Although it
>> does not seem to state as much explicitly, from that section (and
>> other parts of the file related to interface names), it appears as
>> if this detail may apply only to machines running systemd. In
>> particular, the file's multiple references to
>> /etc/systemd/network/99-default.link seem as if they may be
>> relevant.
> 
> Well, in the bug thread 919390 referenced below Martin Pitt does say
> 
> We believe that the bug you reported is fixed in the latest version
> of systemd, which is due to be installed in the Debian FTP archive.
> 
> "in the latest version of systemd."

That's an artifact of the fact that udev is maintained as part of the
systemd source package, because it's maintained upstream as part of the
systemd project. If my understanding is correct, committing a change to
the Debian udev package means committing a change to the systemd package
collection's changelog.

I consider that maintenance situation to have unfortunate negative
consequences, and this is one of them, albeit one of the more minor
examples.

>> Searching /usr/share/doc/udev/changelog.Debian.gz for 'interfaces'
>> found a reference to bug 919390, which seems to be about someone
>> reporting this behavior as a bug. That bug has been closed as
>> "fixed upstream", and that closure is what I found in the
>> changelog. The patch which fixes the bug was committed as being a
>> revert of an earlier change. That commit happened in January, and
>> the package was released to unstable on January 27th; it's long
>> since made it to testing, i.e., buster.
> 
> That appears to be correct from a rapid perusal of the referenced 
> bug.
> 
>> It's still possible that there's other activity which affects all
>> of this and which I've missed (related to the non-udev systemd
>> packages, most likely), but at a glance, it looks as if the release
>> notes and the README alike may be inaccurate / out of date. Even if
>> they aren't, it looks as if they may be incomplete, by describing
>> only the situation as it affects machines with systemd.
> 
> Not even that, it seems (no longer affects systemd).

Have you confirmed that? It seems possible that on a systemd machine,
things in other packages (such as whatever would provide that
99-default.link file, which unfortunately - because it's under /etc/ -
can't be easily found through 'apt-file search') might still be
overriding 70-persistent-net.rules, even with this change reverted.

>> Although I don't run systemd on this machine, and my second system
>> which used to have it (and I think still does) doesn't use it as
>> the init system, I manage a very minor server at work which does
>> use it as init system. In the event that we actually upgrade that
>> server rather than migrating its service to another machine, this
>> change may wind up being relevant to me; I'll want to keep it in
>> mind.
> 
> I was going to upgrade to Buster a couple of weeks ahead of time,
> taking the bull by the horns for once rather than procrastinating,
> which is my ultimate tendency in life, and began reading the release
> notes (for the wrong architecture, but, come on, nobody's perfect).
> It never crossed my mind to doubt the accuracy of those notes until
> yesterday when Greg piped up.
> 
> Maybe we should file a bug report against the release notes.

If we can confirm that the behavior described is inaccurate (i.e., that
70-persistent-net.rules still works, even on a latest-buster machine
running full-on systemd), then yes, I think that would be definitely best.

We're a bit late for it, given that the release is scheduled for the
coming Friday or Saturday (I forget which), but at least reporting it
couldn't hurt. (Assuming there isn't a report about it already; I
haven't checked.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#210603 — Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[Multipart message — attachments visible in raw view] — view raw

On 2019-07-02 at 09:10, Greg Wooledge wrote:

> On Tue, Jul 02, 2019 at 08:51:10AM -0400, The Wanderer wrote:
> 
>> On 2019-07-02 at 08:37, Curt wrote:
>> 
>>> Not even that, it seems (no longer affects systemd).
>> 
>> Have you confirmed that?
> 
> I'm using systemd, and the 70-* file was used when I upgraded to
> buster, but that was roughly 2 months ago.  I haven't tested on
> current buster.

It would be worth trying, although I'm not currently in a position to
easily put together a testbed machine (or VM) for this purpose.

>> It seems possible that on a systemd machine, things in other
>> packages (such as whatever would provide that 99-default.link file,
>> which unfortunately - because it's under /etc/ - can't be easily
>> found through 'apt-file search') might still be overriding
>> 70-persistent-net.rules, even with this change reverted.
> 
> wooledg:~$ locate 99-default
> /lib/systemd/network/99-default.link
> 
> wooledg:~$ dpkg -S 99-default
> udev: /lib/systemd/network/99-default.link

Hmm. Apparently I didn't search for the right thing; I just used the
full explicit path, including /etc/, which found nothing.

I'm guessing this is a case where the systemd pattern of having config
files under /lib/ and symlinking them from under /etc/ is in use, and
that one of /etc/systemd, /etc/systemd/network/, and
/etc/systemd/network/99-default.link is a symlink.

/etc/systemd/network/ doesn't appear on my system, but 99-default.link
does exist under /lib, with the same contents as you gave from yours.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#210604 — Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

On Tue, Jul 02, 2019 at 08:51:10AM -0400, The Wanderer wrote:
> On 2019-07-02 at 08:37, Curt wrote:
> > Not even that, it seems (no longer affects systemd).
> 
> Have you confirmed that?

I'm using systemd, and the 70-* file was used when I upgraded to buster,
but that was roughly 2 months ago.  I haven't tested on current buster.

> It seems possible that on a systemd machine,
> things in other packages (such as whatever would provide that
> 99-default.link file, which unfortunately - because it's under /etc/ -
> can't be easily found through 'apt-file search') might still be
> overriding 70-persistent-net.rules, even with this change reverted.

wooledg:~$ locate 99-default
/lib/systemd/network/99-default.link

wooledg:~$ dpkg -S 99-default
udev: /lib/systemd/network/99-default.link

wooledg:~$ cat /lib/systemd/network/99-default.link 
#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Link]
NamePolicy=keep kernel database onboard slot path
MACAddressPolicy=persistent

[toc] | [prev] | [next] | [standalone]

#210606 — Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

On 2019-07-02, The Wanderer <wanderer@fastmail.fm> wrote:

>> Not even that, it seems (no longer affects systemd).
>
> Have you confirmed that? It seems possible that on a systemd machine,
> things in other packages (such as whatever would provide that
> 99-default.link file, which unfortunately - because it's under /etc/ -
> can't be easily found through 'apt-file search') might still be
> overriding 70-persistent-net.rules, even with this change reverted.

https://github.com/systemd/systemd/issues/11436

https://github.com/systemd/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3bf571
 
 Let's revert, and start with a clean slate. This fixes #11436.

(#11436 being 'network interface is renamed although NAME has been set by
udev rule'.)

Maybe I'm not understanding this (quite possible).

Somebody on an up-to-date Buster could perform Michael Biebl's bug
reproduction test:

 To reproduce the issue, create a file /etc/udev/rules.d/70-persistent-net.rules containing

 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="<MAC>", KERNEL=="eth*", NAME="lan0"

 with the mac address of your ethernet network interface.
 Unload the network module (in my case 8139cp), then load it again.
 Notice how the interface is properly renamed:

 [ 3750.870434] 8139cp 0000:00:03.0 lan0: renamed from eth0
 Now run udevadm trigger --action=add

 [ 3752.509458] 8139cp 0000:00:03.0 ens3: renamed from lan0
 The interface is renamed although a custom NAME has been set.

Sorry if this is noise.

[toc] | [prev] | [next] | [standalone]

#210607 — Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[Multipart message — attachments visible in raw view] — view raw

On 2019-07-02 at 10:10, Curt wrote:

> On 2019-07-02, The Wanderer <wanderer@fastmail.fm> wrote:
> 
>>> Not even that, it seems (no longer affects systemd).
>> 
>> Have you confirmed that? It seems possible that on a systemd
>> machine, things in other packages (such as whatever would provide
>> that 99-default.link file, which unfortunately - because it's under
>> /etc/ - can't be easily found through 'apt-file search') might
>> still be overriding 70-persistent-net.rules, even with this change
>> reverted.
> 
> https://github.com/systemd/systemd/issues/11436
> 
> https://github.com/systemd/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3bf571
>  
>  Let's revert, and start with a clean slate. This fixes #11436.
> 
> (#11436 being 'network interface is renamed although NAME has been
> set by udev rule'.)

Yeah, I read that, although I didn't read #11436.

> Maybe I'm not understanding this (quite possible).

I think you're reading it the same way I am. I'm just questioning
whether what we're seeing here represents the whole picture, and partly
also whether this is the latest word on the subject.

It might be interesting to know when that section of the release notes
was last modified, relative to when this change was made.

> Somebody on an up-to-date Buster could perform Michael Biebl's bug 
> reproduction test:

In particular, someone on a machine running full-on systemd. My
available machines are either non-systemd or not systemd-as-init, so my
observed results aren't applicable.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#210618 — Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

On Tue 02 Jul 2019 at 10:22:56 -0400, The Wanderer wrote:

> On 2019-07-02 at 10:10, Curt wrote:
> 
> > On 2019-07-02, The Wanderer <wanderer@fastmail.fm> wrote:
> > 
> >>> Not even that, it seems (no longer affects systemd).
> >> 
> >> Have you confirmed that? It seems possible that on a systemd
> >> machine, things in other packages (such as whatever would provide
> >> that 99-default.link file, which unfortunately - because it's under
> >> /etc/ - can't be easily found through 'apt-file search') might
> >> still be overriding 70-persistent-net.rules, even with this change
> >> reverted.
> > 
> > https://github.com/systemd/systemd/issues/11436
> > 
> > https://github.com/systemd/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3bf571
> >  
> >  Let's revert, and start with a clean slate. This fixes #11436.
> > 
> > (#11436 being 'network interface is renamed although NAME has been
> > set by udev rule'.)
> 
> Yeah, I read that, although I didn't read #11436.
> 
> > Maybe I'm not understanding this (quite possible).
> 
> I think you're reading it the same way I am. I'm just questioning
> whether what we're seeing here represents the whole picture, and partly
> also whether this is the latest word on the subject.
> 
> It might be interesting to know when that section of the release notes
> was last modified, relative to when this change was made.

Not long after 6th April 2019:

  https://lists.debian.org/debian-doc/2019/04/msg00012.html


> > Somebody on an up-to-date Buster could perform Michael Biebl's bug 
> > reproduction test:
> 
> In particular, someone on a machine running full-on systemd. My
> available machines are either non-systemd or not systemd-as-init, so my
> observed results aren't applicable.

My upgrade from stretch to buster left networking as it was before. My
70-persistent-net.rules is

 SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:90:dc:a2:4d:26",
 ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Following Curt's suggestion I removed the relevant module and rebooted.
'ip a' shows eth0. The advice in the Release Notes

 > ....you should be aware that udev in buster no longer supports the mechanism
 > of defining their names via /etc/udev/rules.d/70-persistent-net.rules.

does not accord with my experience. In the light of #919390 it seems
doubtful to me that the "Migrating from legacy network interface names"
section is useful.

-- 
Brian.
> 
> -- 
>    The Wanderer
> 
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man.         -- George Bernard Shaw
> 

[toc] | [prev] | [next] | [standalone]

#210634 — Re: 70-persistent-net-rules no longer supported?

[Multipart message — attachments visible in raw view] — view raw

On Di, Jul 02, 2019 at 08:14:02 +0100, Brian wrote:
>My upgrade from stretch to buster left networking as it was before. My
>70-persistent-net.rules is
>
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:90:dc:a2:4d:26",
> ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
>
>Following Curt's suggestion I removed the relevant module and rebooted.
>'ip a' shows eth0. The advice in the Release Notes

You probably meant that you removed the line?

I noticed that since Debian 9 this file is added to the initrd. So if you 
change or delete the file you have to rebuild the initrd before 
rebooting.

Shade and sweet water!

	Stephan

-- 
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |

[toc] | [prev] | [next] | [standalone]

#210635 — Re: 70-persistent-net-rules no longer supported?

On 2019-07-03, Stephan Seitz <stse+debian@fsing.rootsland.net> wrote:
>
>>Following Curt's suggestion I removed the relevant module and rebooted.
>>'ip a' shows eth0. The advice in the Release Notes
>
> You probably meant that you removed the line?
>
> I noticed that since Debian 9 this file is added to the initrd. So if you
> change or delete the file you have to rebuild the initrd before
> rebooting.

I was wondering about this, too. 

Michael Biebl bug reproduction test did not involve a reboot
('udevadm trigger --action=add' regenerates, sources, or
re-reads---I don't know the correct term--the rule in
'/etc/udev/rules.d/70-persistent-net.rules').

So with a rule in that file he unloaded and reloaded his network module
(and all was good, the interface adopting the custom name defined in
the file). Then he ran

 udevadm trigger --action=add

reproducing the bug (interface renamed to a default name though 
a custom name was set in '70-persistent-net.rules').

> Shade and sweet water!
>
> 	Stephan

[toc] | [prev] | [next] | [standalone]

#210637 — Re: 70-persistent-net-rules no longer supported?

On Wed 03 Jul 2019 at 09:15:47 +0200, Stephan Seitz wrote:

> On Di, Jul 02, 2019 at 08:14:02 +0100, Brian wrote:
> > My upgrade from stretch to buster left networking as it was before. My
> > 70-persistent-net.rules is
> > 
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:90:dc:a2:4d:26",
> > ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> > 
> > Following Curt's suggestion I removed the relevant module and rebooted.
> > 'ip a' shows eth0. The advice in the Release Notes
> 
> You probably meant that you removed the line?

No, I meant what I wrote, but didn't put much investigation or thought
into into what I was doing. In any case, it was somewhat secondary to
to my other points. I can well imagine that the OP's scepticism as to
the advice in

https://www.debian.org/releases/testing/i386/release-notes/ch-information.en.html#migrate-interface-names

has not diminished.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#210627 — Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

The Wanderer wrote:
> On 2019-07-02 at 10:10, Curt wrote:
> 
>> On 2019-07-02, The Wanderer <wanderer@fastmail.fm> wrote:
>>
>>>> Not even that, it seems (no longer affects systemd).
>>>
>>> Have you confirmed that? It seems possible that on a systemd
>>> machine, things in other packages (such as whatever would provide
>>> that 99-default.link file, which unfortunately - because it's under
>>> /etc/ - can't be easily found through 'apt-file search') might
>>> still be overriding 70-persistent-net.rules, even with this change
>>> reverted.
>>
>> https://github.com/systemd/systemd/issues/11436
>>
>> https://github.com/systemd/systemd/commit/ed30802324365dde6c05d0b7c3ce1a0eff3bf571
>>   
>>   Let's revert, and start with a clean slate. This fixes #11436.
>>
>> (#11436 being 'network interface is renamed although NAME has been
>> set by udev rule'.)
> 
> Yeah, I read that, although I didn't read #11436.
> 
>> Maybe I'm not understanding this (quite possible).
> 
> I think you're reading it the same way I am. I'm just questioning
> whether what we're seeing here represents the whole picture, and partly
> also whether this is the latest word on the subject.
> 
> It might be interesting to know when that section of the release notes
> was last modified, relative to when this change was made.
> 
>> Somebody on an up-to-date Buster could perform Michael Biebl's bug
>> reproduction test:
> 
> In particular, someone on a machine running full-on systemd. My
> available machines are either non-systemd or not systemd-as-init, so my
> observed results aren't applicable.
> 

I'm running up to date sid and using systemd and still have an eth0 as set by 70-persistent-net.rules.

Geoff

[toc] | [prev] | [next] | [standalone]

#210977 — Re: 70-persistent-net-rules no longer supported? (Was Re: Document removal of ecryptfs-utils from Buster)

[Multipart message — attachments visible in raw view] — view raw

On Ma, 02 iul 19, 08:02:22, The Wanderer wrote:
> On 2019-07-01 at 03:47, Curt wrote:
> > 
> > https://www.debian.org/releases///buster/s390x/release-notes/ch-information.en.html#migrate-interface-names
> 
> I'm skeptical as to whether this is (still/currently) accurate.

This was fixed in the meantime, thanks for noticing.

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web