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

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

Please help me identify package so I can report an important bug

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

Contents

  Please help me identify package so I can report an important bug Peter Goodall <pjgoodall@gmail.com> - 2024-06-12 08:30 +0200
    Re: Please help me identify package so I can report an important bug Richard <rrosner5@gmail.com> - 2024-06-12 13:00 +0200
      Re: Please help me identify package so I can report an important bug Jeffrey Walton <noloader@gmail.com> - 2024-06-12 17:20 +0200
        Re: Please help me identify package so I can report an important bug Richard <rrosner5@gmail.com> - 2024-06-12 19:00 +0200
          Re: Please help me identify package so I can report an important  bug debian-user@howorth.org.uk - 2024-06-12 21:50 +0200
      Re: Please help me identify package so I can report an important bug "Roy J. Tellason, Sr." <roy@rtellason.com> - 2024-06-12 20:50 +0200
        Re: Please help me identify package so I can report an important bug <tomas@tuxteam.de> - 2024-06-12 21:10 +0200
          Re: Please help me identify package so I can report an important bug Greg Wooledge <greg@wooledge.org> - 2024-06-12 21:20 +0200
            Predictable network device names [was: Please help me identify  package so I can report an important bug tomas@tuxteam.de - 2024-06-13 06:40 +0200
            Re: Please help me identify package so I can report an important bug <tomas@tuxteam.de> - 2024-06-13 06:40 +0200

#270041 — Please help me identify package so I can report an important bug

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

Hello,

This  bug, or a close relative, has already been reported in
https://github.com/raspberrypi/bookworm-feedback/issues/239
as 'Predictable network names broken for ASIX USB ethernet in kernel 6.6.20'

I added a comment reporting my experience in Proxmox here:
https://github.com/raspberrypi/bookworm-feedback/issues/239#issuecomment-2162166863

Because it happens in proxmox and rpi I assume its Debian or higher. I have
not reported a Debian bug before...

Thanks,
--Peter G

[toc] | [next] | [standalone]

#270043

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

Question is, does it make that much sense to report it to Debian directly?
Are you encountering this issue on Debian itself or
Armbian/Raspbian/whatever? You reported this to the Raspberry Pi GitHub, so
I'd expect them to take this up with the upstream devs themselves, so by
the time Trixie is being released, it may already be included.

But besides that, what you describe in the first link sounds to me not like
a bug, but as a well thought-through decision. Network adapter names like
eth0 have been dropped with Debian 11 (I think, maybe even 10). So don't
get your hopes up too high to ever see this coming back. But also, just
searching the web for this topic, you should have come across this
answering your questions: https://wiki.debian.org/NetworkInterfaceNames

Richard

Am Mi., 12. Juni 2024 um 12:43 Uhr schrieb Peter Goodall <
pjgoodall@gmail.com>:

> Hello,
>
> This  bug, or a close relative, has already been reported in
> https://github.com/raspberrypi/bookworm-feedback/issues/239
> as 'Predictable network names broken for ASIX USB ethernet in kernel
> 6.6.20'
>
> I added a comment reporting my experience in Proxmox here:
>
> https://github.com/raspberrypi/bookworm-feedback/issues/239#issuecomment-2162166863
>
> Because it happens in proxmox and rpi I assume its Debian or higher. I
> have not reported a Debian bug before...
>
> Thanks,
> --Peter G
>

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

#270044

On Wed, Jun 12, 2024 at 10:33 AM Richard <rrosner5@gmail.com> wrote:
>
> Question is, does it make that much sense to report it to Debian directly? Are you encountering this issue on Debian itself or Armbian/Raspbian/whatever? You reported this to the Raspberry Pi GitHub, so I'd expect them to take this up with the upstream devs themselves, so by the time Trixie is being released, it may already be included.
>
> But besides that, what you describe in the first link sounds to me not like a bug, but as a well thought-through decision. Network adapter names like eth0 have been dropped with Debian 11 (I think, maybe even 10). So don't get your hopes up too high to ever see this coming back. But also, just searching the web for this topic, you should have come across this answering your questions: https://wiki.debian.org/NetworkInterfaceNames

The random MAC address discussed in the bug report (with mention of
Network Manager) could be
<https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/>.

Jeff

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

#270048

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

Good catch. With the title of this thread and not seeing any proper
description of what's actually wrong on GitHub, I figured the change of the
adapter name was meant. Yes, with MAC randomization, that's what you'll
get. But it's nothing Debian defaults to. So question is, can this be
disabled on Proxmox? But with this hint, it should be easy enough to figure
out if this can be deactivated on the affected systems, and if not the bug
reports must be against these issues, as Debian itself doesn't do such
things. If it is an issue with Debian preventing the disablement, the devs
need to talk to each other.

Richard

Am Mi., 12. Juni 2024 um 17:10 Uhr schrieb Jeffrey Walton <
noloader@gmail.com>:

> The random MAC address discussed in the bug report (with mention of
> Network Manager) could be
> <
> https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/
> >.
>
> Jeff
>

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

#270054 — Re: Please help me identify package so I can report an important bug

Richard <rrosner5@gmail.com> wrote:
> Good catch. With the title of this thread and not seeing any proper
> description of what's actually wrong on GitHub, I figured the change
> of the adapter name was meant. Yes, with MAC randomization, that's
> what you'll get. But it's nothing Debian defaults to. So question is,
> can this be disabled on Proxmox? But with this hint, it should be
> easy enough to figure out if this can be deactivated on the affected
> systems, and if not the bug reports must be against these issues, as
> Debian itself doesn't do such things. If it is an issue with Debian
> preventing the disablement, the devs need to talk to each other.
> 
> Richard
> 
> Am Mi., 12. Juni 2024 um 17:10 Uhr schrieb Jeffrey Walton <
> noloader@gmail.com>:  
> 
> > The random MAC address discussed in the bug report (with mention of
> > Network Manager) could be
> > <
> > https://blogs.gnome.org/thaller/2016/08/26/mac-address-spoofing-in-networkmanager-1-4-0/  
> > >.  
> >
> > Jeff

I think before anybody else suggests anything, they should read
https://lore.kernel.org/netdev/20240326092459.GG403975@kernel.org/T/

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

#270051

On Wednesday 12 June 2024 06:54:54 am Richard wrote:
> But also, just
> searching the web for this topic, you should have come across this
> answering your questions: https://wiki.debian.org/NetworkInterfaceNames
> 

Wow.  Just wow...

That sort of thing just drives me crazy!  :-)

I can see sticking with older versions of some things.

-- 
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space,  a critter that can
be killed but can't be tamed.  --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James 
M Dakin

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

#270052

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

On Wed, Jun 12, 2024 at 02:30:40PM -0400, Roy J. Tellason, Sr. wrote:
> On Wednesday 12 June 2024 06:54:54 am Richard wrote:
> > But also, just
> > searching the web for this topic, you should have come across this
> > answering your questions: https://wiki.debian.org/NetworkInterfaceNames
> > 
> 
> Wow.  Just wow...
> 
> That sort of thing just drives me crazy!  :-)
> 
> I can see sticking with older versions of some things.

No need. You can have your traditional names (I do). Just add
"net.ifnames=0" (if necessry separated by a space, should
other stuff be already there) to your GRUB_CMDLINE_LINUX_DEFAULT
in your /etc/default/grub, then ru update-grub.

Mine loks like this:

  GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"

Cheers
-- 
t

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

#270053

On Wed, Jun 12, 2024 at 09:01:44PM +0200, tomas@tuxteam.de wrote:
> No need. You can have your traditional names (I do). Just add
> "net.ifnames=0" (if necessry separated by a space, should
> other stuff be already there) to your GRUB_CMDLINE_LINUX_DEFAULT
> in your /etc/default/grub, then ru update-grub.
> 
> Mine loks like this:
> 
>   GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"

People who are thinking of doing this should take a moment to consider
whether it will be better or worse than the default.

For a machine that has exactly one ethernet interface, this is a vast
improvement over the default.  Your interface will always be named
"eth0" no matter what crazy things happen on the PCI bus.

For a machine with multiple interfaces, however, the original problem
that "predictable interface names" were supposed to solve is still an
issue.  The kernel may not assign the names in the same order every
time you boot.  In that situation, "net.ifnames=0" is not likely to
be an improvement.  You'd be better off using systemd.link(5) files to
customize your interface names according to your own specific needs.

> > > https://wiki.debian.org/NetworkInterfaceNames

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

#270067 — Predictable network device names [was: Please help me identify package so I can report an important bug

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

On Thu, Jun 13, 2024 at 06:30:27AM +0200, tomas@tuxteam.de wrote:

[following up on myself, bad style, I know]

> For my laptop, I very much prefer to say "sudo ifup eth0" than to
> say "sudo ifup en0ps&&@*#!☠" thankyouverymuch :)

and of course, if you are using a desktop environment and NetworkManager
or systemd-networkd, it's probably better to go with the flow and let
them do.

Cheers
-- 
t

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

#270068

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

On Wed, Jun 12, 2024 at 03:16:41PM -0400, Greg Wooledge wrote:
> On Wed, Jun 12, 2024 at 09:01:44PM +0200, tomas@tuxteam.de wrote:

[...]

> > Mine loks like this:
> > 
> >   GRUB_CMDLINE_LINUX_DEFAULT="quiet net.ifnames=0"
> 
> People who are thinking of doing this should take a moment to consider
> whether it will be better or worse than the default.

Absolutely. I did, and I decided that in my case, this is the better
choice...

> For a machine that has exactly one ethernet interface, this is a vast
> improvement over the default.  Your interface will always be named
> "eth0" no matter what crazy things happen on the PCI bus.

...but it's not always, as you say.

> For a machine with multiple interfaces, however, the original problem
> that "predictable interface names" were supposed to solve is still an
> issue.  The kernel may not assign the names in the same order every
> time you boot.  In that situation, "net.ifnames=0" is not likely to
> be an improvement.  You'd be better off using systemd.link(5) files to
> customize your interface names according to your own specific needs.

I think PCI is not the worst offender. The worst is if you have a bunch
of adapters hanging off an USB tree. Then, as they say, God does play
dice :-)

Back Then (TM) (I think it was a Debian 3.x aka Sarge), a bunch of
us cobbled a "router thingy" together on some off-the-shelf hardware.
It had four Ethernets hanging off whatever PC bus was fashionable
back then (too lazy to look it up).

Not many of those were sold, luckily :-)

One was for "the bad Internet", the other three for "the inside".
Our big fear was that, after a BIOS upgrade the interfaces would
come up in a mangled order. That would have been a good application
of this scheme (provided it works at all: I'm somewhat sceptic.
Hardware and firmware are known to do... things).

We ended up going by the card's MAC addresses, at the price of
having a set up step on assembly. But then, if you change one
Ethernet card...

Alas, you can't do it right.

For my laptop, I very much prefer to say "sudo ifup eth0" than to
say "sudo ifup en0ps&&@*#!☠" thankyouverymuch :)

Cheers
-- 
t

[toc] | [prev] | [standalone]

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

csiph-web