Re: 73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?

[Flacusbigotis]

On Wed, Feb 23, 2022 at 3:15 AM Tixy  wrote:

>
> Sorry, I know nothing about all this, I just got curious about your
> problem and looked at the source code.
>
>
Wow.  That's quite impressive Tixy.  I would not even know where to begin
looking!  Thank you for all that leg work.  I will be looking at those
references you provided.

I have also sent an email to the debian kernel list with only the latest
information I had before your email.  They suggested I open a bug report,
so I will be doing that.  I will let you know here what I find.

Re: 73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?

[Flacusbigotis]

> I did not have this problem in Debian 10.  I do not know if the card's
driver has changed between the two versions of Debian, so I am going to
boot into a Debian 10 live image and see if it displays the same behavior.

Good news:  I verified that this whole thing is indeed introduced in Debian
11 (Bullseye) and is not an issue on Debian 10 (Buster).
Bad news: this mean I can't use the card for now! :-)

I verified the above claim (bug in Bullseye) by booting into BUSTER using a
Debian 10 live USB, and I also tested the same with a Debian 11 (Bullseye)
live USB and obviously also with my hard drive install of bullseye.

The BUSTER USB booted fine and the interface came up without any issues
100% of the time, several times.  I even went back and forth randomly
between the different distros, sometimes fully powering off the machine,
others simply just rebooting...

In contrast, the BULLSEYE USB and the "BULLSEYE hard drive installed OS"
each failed 100% of the time and exhibited the same exact problem, every
single time I tested them.

Another bit of good news (well, progress) is that I also now noticed these
logs in /var/log/messages:

Feb 22 17:22:53 server1 kernel: [1.380198] xhci_hcd :1c:00.0: xHCI
Host Controller
Feb 22 17:22:53 server1 kernel: [1.380205] xhci_hcd :1c:00.0: new
USB bus registered, assigned bus number 5
Feb 22 17:22:53 server1 kernel: [1.380209] xhci_hcd :1c:00.0: Host
supports USB 3.0 SuperSpeed
Feb 22 17:22:53 server1 kernel: [1.380260] usb usb5: New USB device
found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.10
Feb 22 17:22:53 server1 kernel: [1.380261] usb usb5: New USB device
strings: Mfr=3, Product=2, SerialNumber=1
Feb 22 17:22:53 server1 kernel: [1.380263] usb usb5: Product: xHCI Host
Controller
Feb 22 17:22:53 server1 kernel: [1.380264] usb usb5: Manufacturer:
Linux 5.10.0-11-amd64 xhci-hcd
Feb 22 17:22:53 server1 kernel: [1.380265] usb usb5: SerialNumber:
:1c:00.0
Feb 22 17:22:53 server1 kernel: [1.380396] hub 5-0:1.0: USB hub found
Feb 22 17:22:53 server1 kernel: [1.380411] hub 5-0:1.0: 4 ports detected
Feb 22 17:22:53 server1 kernel: [5.508457] ax88179_178a 5-1:1.0 eth0:
register 'ax88179_178a' at usb-:1c:00.0-1, ASIX AX88179 USB 3.0 Gigabit
Ethernet, 00:11:22:33:44:55
Feb 22 17:23:25 server1 kernel: [   39.576966] xhci_hcd :1c:00.0:
WARNING: Host System Error
Feb 22 17:26:00 server1 kernel: [  194.596335] ax88179_178a 5-1:1.0
enx001122334455: Failed to read reg index 0x0002: -22
Feb 22 17:26:00 server1 kernel: [  194.596338] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0002: -22
Feb 22 17:26:11 server1 kernel: [  205.378965] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0002: -22
Feb 22 17:26:11 server1 kernel: [  205.378969] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0002: -22
Feb 22 17:26:11 server1 kernel: [  205.585506] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693515] ax88179_178a 5-1:1.0
enx001122334455: Failed to read reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693524] ax88179_178a 5-1:1.0
enx001122334455: Failed to read reg index 0x0006: -22
Feb 22 17:26:11 server1 kernel: [  205.693527] ax88179_178a 5-1:1.0
enx001122334455: invalid MAC address, using random
Feb 22 17:26:11 server1 kernel: [  205.693532] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0006: -22
Feb 22 17:26:11 server1 kernel: [  205.693535] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0005: -22
Feb 22 17:26:11 server1 kernel: [  205.693538] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693541] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693544] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693547] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693550] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0002: -22
Feb 22 17:26:11 server1 kernel: [  205.693553] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693555] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0002: -22
Feb 22 17:26:11 server1 kernel: [  205.693561] ax88179_178a 5-1:1.0
enx001122334455: Failed to read reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693564] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0001: -22
Feb 22 17:26:11 server1 kernel: [  205.693567] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x001f: -22
Feb 22 17:26:11 server1 kernel: [  205.693570] ax88179_178a 5-1:1.0
enx001122334455: Failed to write reg index 0x0019: -22
Feb 22 17:26:11 

Re: 73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?

[Flacusbigotis]

On Thu, Feb 17, 2022 at 1:06 AM Reco  wrote:

> Hi.
>
> On Thu, Feb 17, 2022 at 12:32:48AM -0600, Flacusbigotis wrote:
> > Thanks Reco & Greg.  I did see the
> > /lib/systemd/network/73-usb-net-by-mac.link file. Thanks for that.
> >
> > I don't know exactly what is happening, but the MAC address of the device
> > keeps changing  after an ifdown/ifup cycle post boot.
>
> You should've said that first.
>

I only found that out later after the 1st post :-)


> If the MAC address of the NIC is not persistent, that means udev will
> provide you with different interface name each time you boot.
> That means that you've hit yet another case of unpredictability of so
> called Predictable Network Interface Names.
>
>
I did not have this problem in Debian 10.  I do not know if the card's
driver has changed between the two versions of Debian, so I am going to
boot into a Debian 10 live image and see if it displays the same behavior.
If the drivers are the same then the issue was probably introduced by the
changes made to start using ".link" vs .rules" files.


> > I also tried adding a udev file (/etc/udev/rules.d/99_fix_usb.rules) with
> > the following content to try to force the addr_assign_type to 0, but this
> > did nothing:
> >
> > SUBSYSTEMS=="usb", SUBSYSTEM=="net", ATTR{addr_assign_type}="0"
>
> Try this:
>
> 1) Create a file called /etc/systemd/network/00-usb.link with the following
> contents:
>
> [Match]
> Driver=ax88179_178a
>
> [Link]
> MACAddressPolicy=none
> NamePolicy=kernel
>
> You may have to create an appropriate directory, and the file name has
> to start with double zeroes.
>
> 2) Invoke (really needed):
>
> update-initramfs -k all -u
>
> 3) Reboot.
>
> 4) Watch your network interface is called usb0 from now then.
>
>
> Thanks!


> Now, this approach has its caveats, so:
>
> 1) If you ever plug-in two USB devices that both served with
> "ax88179_178a" - you won't be able to distinguish between them. They
> will be called usb0, usb1, etc without any meaningful order.
>
> Ugghhh.. I am not entirely comfortable with that.


> 2) If they decide to rename "ax88179_178a" in the kernel - this link
> file will cease to work for obvious reasons.
>
>  Also not comfortable with this.

I'll first check if I can replicate the behavior in Buster.  If I can't
then I will dig to see what is it exactly that makes it different in
Bullseye.  If it's reproducible I will see if I can work with maintainers
in some part of the OS to help... Probably will try to start with the
driver's maintainers.

BTW, Reco, my apologies once again for emailing you directly instead of
through the list, that was inadvertent.

Re: 73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?

[Flacusbigotis]

np1s0:  mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
inet 10.8.0.11/24 brd 10.8.0.255 scope global enp1s0
   valid_lft forever preferred_lft forever
4: enx001234567890:  mtu 1500 qdisc pfifo_fast state
DOWN group default qlen 1000
link/ether 96:6e:37:f1:d0:34 brd ff:ff:ff:ff:ff:ff permaddr
00:12:34:56:78:90

On Wed, Feb 16, 2022 at 3:55 AM Flacusbigotis 
wrote:

> My internet connection is off the ethernet port of a PCI-E card that also
> has USB ports on it, so the ethernet device is recognized as a "USB
> ethernet device"...
>
> Back in Debian Buster, I learned that the "predictive" naming of this USB
> ethernet interface would be governed by "73-usb-net-by-mac.rules" and so I
> had it configured accordingly with a config file in
> /etc/network/interfaces.d/... Namely that the device name would basically
> be its MAC.
>
> Well, I just upgraded to Bullseye, and I can't bring up the darn
> interface.  I have tried fiddling around with the device name in my config
> file in /etc/network/interfaces.d/ directory, but it just won't come up.
> The Networking.service also fails during bootup.
>
> I also noticed that the 73-usb-net-by-mac.rules file has completely
> disappeared, never mind that the official Debian NetworkInterfaceNames page
> here <https://wiki.debian.org/NetworkInterfaceNames> still talks about it!
>
> Anyone know how the heck this is supposed to work in Bullseye?
>
> BTW, the device shows up as disabled in lshw (I obfuscated the MAC in the
> output):
>
>  *-network DISABLED
>description: Ethernet interface
>physical id: 1
>bus info: usb@7:1
>logical name: enx00XX<<<=== Yes, I tried using this
> name in the config
>serial: 00:XX:XX:XX:XX:XX
>size: 10Mbit/s
>capacity: 1Gbit/s
>capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd
> 1000bt 1000bt-fd autonegotiation
>configuration: autonegotiation=off broadcast=yes
> driver=ax88179_178a driverversion=5.10.0-11-amd64 duplex=half link=no
> multicast=yes port=MII speed=10Mbit/s
>
>
>
>

73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?

[Flacusbigotis]

My internet connection is off the ethernet port of a PCI-E card that also
has USB ports on it, so the ethernet device is recognized as a "USB
ethernet device"...

Back in Debian Buster, I learned that the "predictive" naming of this USB
ethernet interface would be governed by "73-usb-net-by-mac.rules" and so I
had it configured accordingly with a config file in
/etc/network/interfaces.d/... Namely that the device name would basically
be its MAC.

Well, I just upgraded to Bullseye, and I can't bring up the darn
interface.  I have tried fiddling around with the device name in my config
file in /etc/network/interfaces.d/ directory, but it just won't come up.
The Networking.service also fails during bootup.

I also noticed that the 73-usb-net-by-mac.rules file has completely
disappeared, never mind that the official Debian NetworkInterfaceNames page
here  still talks about it!

Anyone know how the heck this is supposed to work in Bullseye?

BTW, the device shows up as disabled in lshw (I obfuscated the MAC in the
output):

 *-network DISABLED
   description: Ethernet interface
   physical id: 1
   bus info: usb@7:1
   logical name: enx00XX<<<=== Yes, I tried using this name
in the config
   serial: 00:XX:XX:XX:XX:XX
   size: 10Mbit/s
   capacity: 1Gbit/s
   capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd
1000bt 1000bt-fd autonegotiation
   configuration: autonegotiation=off broadcast=yes driver=ax88179_178a
driverversion=5.10.0-11-amd64 duplex=half link=no multicast=yes port=MII
speed=10Mbit/s

Re: Stalled system shutdown

[Flacusbigotis]

> I wonder if the package ntopng is necessary for something.

See manpage gor ntopng it's for monitoring network resources/activity.

So if you aren't interested in doing that  then you don't need it installed.

Re: Unable to boot UEFI laptop from Debian 11 Live USB stick

[Flacusbigotis]

Thank you! I was using the 32-bit image! Duh!!!  I retried with the 64-bit
image and it is all good!


On Fri, Feb 11, 2022 at 11:16 AM Andrew M.A. Cater 
wrote:

> On Thu, Feb 10, 2022 at 07:43:56PM -0600, Flacusbigotis wrote:
> > Thomas and Andrew, thanks for your reply.
> >
> >
> > The laptop is no more than two years old and it has an Intel Core
> i3-1005G1
> > processor.
> > Also, I checked the USB stick and it only has the 32-bit EFI program in
> the
> > EFI boot folder.
> >
> > I assume based on what Andrew said that maybe the UEFI needs to be
> 64-bit.
> > I guess I will take the thread to the debian-live mailing list and ask
> why
> > there is no 64-bit UEFI program and their plans to add one.
> >
> > On Tue, Feb 8, 2022 at 5:18 AM Thomas Schmitt  wrote:
> >
> > > Hi,
> > >
> > > Andrew M.A. Cater wrote:
> > > > I had a similar issue the other day with an old Intel Baytrail
> > > > notebook where the UEFI is 32 bit and the processor is 64 bit -
> using a
> > > > Debian multi-arch installer worked. I used the one with firmware.
> > >
> > > This would match the observation that Knoppix 9.1 works.
> > > I have Knoppix 9.0 and  9.2 ISOs. On both the EFI partition has start
> > > programs for 64 bit and for 32 bit:
> > >   /mnt/fat/efi/boot/BOOTIA32.efi
> > >   /mnt/fat/efi/boot/BOOTX64.efi
> > >
> > >
> > > Have a nice day :)
> > >
> > > Thomas
> > >
> > >
>
> Check which Debian live image you downloaded - I think there are two
> versions
> -- one 32 bit, one 64 bit.
>
> To be honest, I'd be tempted to just use a standard Debian installer.
>
> If you have a machine which only has UEFI and refuses to boot a 64 bit
> Debian live at any point - at that point, you can look to say whether it's
> one of the outliers with a 32 bit BIOS and 64 bit CPU.
>
> There was a rash of netbooks a few years ago with 2GB RAM for just this
> reason
> they were sold with cut down 32 bit Windows versions.
>
> Hope this helps, all the very best, as ever,
>
> Andy C.
>
>

Re: Stalled system shutdown

[Flacusbigotis]

Just a question to help you start troubleshooting:

Does the shutdown finish quickly/quicker if you first stop the ntopng
systemd service manually before doing the full shutdown?

On Thu, Feb 10, 2022, 5:59 PM José Luis González  wrote:

> Hi,
>
> When shutting down, after upgrading to Debian 11, system shutdown hangs
> (freezes) for some time (about 1-2 minutes) anytime, making it
> bothersome to shut the system down.
>
> The freeze happens afther the "Stopped target remote filesystems"
> status line. After a while "A stop job is running for ntopng" is
> printed with an "in progress" status in red and a timeout of 1 minute
> 30 seconds, which is exhausted. So everyt time I shut down I get a 1
> minute and 30 seconds delay.
>
> Anyone can help, please?
>
>

Re: Unable to boot UEFI laptop from Debian 11 Live USB stick

[Flacusbigotis]

Thomas and Andrew, thanks for your reply.


The laptop is no more than two years old and it has an Intel Core i3-1005G1
processor.
Also, I checked the USB stick and it only has the 32-bit EFI program in the
EFI boot folder.

I assume based on what Andrew said that maybe the UEFI needs to be 64-bit.
I guess I will take the thread to the debian-live mailing list and ask why
there is no 64-bit UEFI program and their plans to add one.

On Tue, Feb 8, 2022 at 5:18 AM Thomas Schmitt  wrote:

> Hi,
>
> Andrew M.A. Cater wrote:
> > I had a similar issue the other day with an old Intel Baytrail
> > notebook where the UEFI is 32 bit and the processor is 64 bit - using a
> > Debian multi-arch installer worked. I used the one with firmware.
>
> This would match the observation that Knoppix 9.1 works.
> I have Knoppix 9.0 and  9.2 ISOs. On both the EFI partition has start
> programs for 64 bit and for 32 bit:
>   /mnt/fat/efi/boot/BOOTIA32.efi
>   /mnt/fat/efi/boot/BOOTX64.efi
>
>
> Have a nice day :)
>
> Thomas
>
>

Unable to boot UEFI laptop from Debian 11 Live USB stick

[Flacusbigotis]

I have followed Debian's instructions (
https://wiki.debian.org/DebianInstall#Creating_a_Bootable_Debian_USB_Flashdrive)
for creating a bootable USB stick but it fails to boot on my UEFI laptop.
In contrast, I am able to create the same for Knoppix 9.1 following their
instructions. So not sure why the debian one doesn't work.

The debian instructions basically say to do a normal cp of the hybrid iso
unto the raw USB device as follows (assume USB stick is on /dev/sdf):

cp  debian11_hybrid.iso  /dev/sdf

However, although the USB stick ends up with the 2 corresponding
partitions, and I can mount/see the content of those, my laptop refuses to
recognize the USB stick during boot and so it won't boot off it.

I have tried the Debian 10 and Debian 11 hybrid images on 2 different USB
sticks and I get the same result.

According to [this](https://wiki.debian.org/UEFI#UEFI_support_in_live_images)
page the debian live images should boot on UEFI-based systems when USB
sticks are prepared as described above...

I have inspected the boot options of the laptop in is setup screen, with
the USB stick plugged-in, but the USB stick is not listed as a possible
target.

BTW, in that laptop setup screen I see a note that says that Legacy Boot
mode is not supported on the laptop.