Re: Out of memory killer misconfigured?

[Tixy]

On Tue, 2022-03-29 at 19:39 +0100, piorunz wrote:
> On 29/03/2022 10:56, Sven Hoexter wrote:
> 
> > The in kernel oom killing is a constant issue. If you look through the
> > lwn.net articles of the past years there is work done to improve the
> > situation, but I believe that's not in a default setup yet.
> 
> Yes it's terrible, how this can be broken so badly? Logic is very simple
> here, even back in Windows XP times it was already solved by Microsoft?
> Just one simple thing, one line of logic:
> 
> 1. If RAM memory usage > 95% AND no swap available AND I/O cache already
> dropped THEN kill most memory hungry process
> 2. Repeat
> 
> Job done!

I may be wrong here, but I seem to remember that something like that
used to happen a long time ago, and it had a habit of picking the X
server as the first thing to kill, not very friendly for GUI users.

-- 
Tixy

Re: installing on Lenovo Ideapad 3 now working

[Andrew M.A. Cater]

On Wed, Mar 30, 2022 at 07:14:39AM +0200, to...@tuxteam.de wrote:
> On Tue, Mar 29, 2022 at 08:31:38PM +0100, Brian wrote:
> > On Tue 29 Mar 2022 at 20:57:48 +0200, to...@tuxteam.de wrote:
> 
> [...]
> 
> > > One of the caveats with dd (or cat, or...) is that you might
> > > be tempted to pull the USB stick too early [...]
> 
> > A reasonable observation. However, it should be noted that there has
> > never been a well-documneted case of dd, cat or cp failing. I doubt
> > the OP will provide substantial reproducible evidence, whatever
> > "worked" meant.
> 
> What I have observed, and that is a strong hint, is that if you do
> a simple "dd", it comes back as soon as the stuff is in the buffers
> (they're there exactly for that). If you then do "sync", it takes
> quite a while (especially for USB 2 and larger media).
> 
> If you think things are done as soon as dd comes back and pull the
> stick, chances are that your write is incomplete.
> 
> So my recommendation is still: either do the sync or dd with
> oflag=sync.
> 
> Cheers
> -- 
> t

So, something close to:

Where sdX is the drive your USB shows up as when you do a dmesg 

dd if=[iso] of=/dev/sdX bs=4M oflag=sync status=progress

if is the input file name  - the iso

of is the output file to write to

bs is the block size

oflag=sync will sync each write and flush buffers

status=progress gives you an indication of how far through the process is

dd if=debian-10.12.0-amd64-i386-netinst.iso of=/dev/sdb bs=4M oflag=sync 
status=progress 

is a command I wrote the other day to write the multi-arch netinst to USB
for testing the Buster release.

Hope this helps - all the very best, as ever,

Andy Cater

Re: installing on Lenovo Ideapad 3 now working

[tomas]

On Wed, Mar 30, 2022 at 08:43:06AM +, Andrew M.A. Cater wrote:

[...]

> So, something close to:
> 
> Where sdX is the drive your USB shows up as when you do a dmesg 
> 
> dd if=[iso] of=/dev/sdX bs=4M oflag=sync status=progress

Yes, thereabouts. The difference with my proposal is you are using
a 4M buffer size while I had 64k. Not a big deal -- as I said, my
informal measurements once gave a very broad maximum, noticeably
falling off (slowly!) in the 1G region.

The default, 512, is definitely too small for somewhat-more-or-less
current-ish [1] hardware configurations.

Cheers

[1] I always buy refurbished computers :)

-- 
t


signature.asc
Description: PGP signature

Re: installing on Lenovo Ideapad 3 now working

[Thomas Schmitt]

Hi,

Andrew M.A. Cater wrote:
> > dd if=[iso] of=/dev/sdX bs=4M oflag=sync status=progress

to...@tuxteam.de wrote:
> Yes, thereabouts. [...]

For those who do not trust themselves to choose the right /dev/sdX
i have prepared a script which asks for plugging in the USB stick
and then uses the newly appeared device file in the output of lsblk.

  https://wiki.debian.org/XorrisoDdTarget

It is meanwhile in Debian Testing
  https://packages.debian.org/unstable/xorriso-dd-target

but can also be downloaded for other Linux systems from
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/xorriso-dd-target/xorriso-dd-target
  
https://dev.lovelyhq.com/libburnia/libisoburn/raw/master/xorriso-dd-target/xorriso-dd-target.sig

It also unmounts possibly the possibly automounted filesystems on the
USB stick and overwrites a possible GPT backup header at the end of the
device.
Like
  sudo /bin/umount /dev/sdd1
  sudo /bin/umount /dev/sdd2
  sudo /bin/umount /dev/sdd3
  sudo /bin/dd if=/dev/zero of=/dev/'sdd' bs=512 seek='7864318' count=1 
status=none
  sudo /bin/dd if='debian-10.0.0-amd64-netinst.iso' bs=1M of=/dev/'sdd' 
status=progress oflag=dsync ; sync


> The default, 512, is definitely too small for somewhat-more-or-less
> current-ish [1] hardware configurations.

I guess dd is from a time when the drives were so slow that this did
not matter.
There are meanings attributed to the block size which matter with
(at least) conv={block,unblock,sync}. So changing the default bs= might
break very old and venerable scripts.


Have a nice day :)

Thomas

Re: installing on Lenovo Ideapad 3 now working

[tomas]

On Wed, Mar 30, 2022 at 11:56:55AM +0200, Thomas Schmitt wrote:

[...]

> For those who do not trust themselves to choose the right /dev/sdX
> i have prepared a script which asks for plugging in the USB stick
> and then uses the newly appeared device file in the output of lsblk.
> 
>   https://wiki.debian.org/XorrisoDdTarget

Nifty, I'll sure have a look into :)

> Have a nice day :)

Likewise & thanks
-- 
t


signature.asc
Description: PGP signature

Re: mngtmpaddr IP

[Jevin Gala]

It's already disabled for all and eth0 as well.

On Tue, Mar 29, 2022 at 12:53 PM Jevin Gala  wrote:

> Hi,
>
> I am un-able to find how to disable mngtmpaddr IPv6 IP in Debian 11 in a
> KVM VPS.
>
> /proc/sys/net/ipv6/conf/default/use_tempaddr file shows 0 but it's still
> assigning mngtmpaddr IP to the VPS.
>
> --
> Regards,
> Jevin  Gala
>
> Virtualizor support - Softaculous Ltd.
>


-- 
Regards,
Jevin  Gala

Virtualizor support - Softaculous Ltd.

Re: Debian 11.3 kernel panics on Epyc 7281 CPU

[Greg Marks]

> Our servers were running Debian 10 without any issues
> We have been trying to do a fresh install of debian 11.3 on exactly the
> same hardware. The install works without any errors but on rebooting the
> system fails with kernel panics
> 
> By adding  init=/bin/bash from within grub works and we can then do things
> like
> 
> mount - o remount /
> cd /etc/init.d
> ./networking start
> ./ssh start
> apt install stress
> stress -c 16 -m 16 --vm-bytes 50GB
> 
> This stress test (without running the normal init process)  runs for hours
> without issues
> 
> We then tried adding systemd.confirm_spawn=true from the boot line in grub
> to try to see at what stage the kernel crashes
> Even if we don't confirm the first systemd spawn and leave the computer
> waiting for an answer for a few minutes the kernel panics
> 
> Has anyone else seen this or have a fix for it?
> The board is a GIGABYTE  R181-Z90-00 Version F01 , the CPU is AMD EPYC
> 7281,the total memory is 1TB from 64GB sticks of Samsung DDR4
> M386A8K40BM2-CTD

I don't have any of this hardware, and I can only speculate as to the
cause of the problem.  Is it, by any chance, related to the following?

   
https://cloudlinux.zendesk.com/hc/en-us/articles/360014242019-AMD-CPU-Unable-to-Boot-after-CPU-Microcode-Update

Debian not booting on EPYC CPUs is an extremely serious problem.
I hope some solution is discovered.

Best regards,
Greg Marks


signature.asc
Description: PGP signature

Re: installing on Lenovo Ideapad 3

[황병희]

>> Unfortunately now the install doesn't detect an Ethernet card and gives 
>> me a long list of driver choices and I will have to figure out which one 
>> this laptop needs.
>
> Maybe a binary module is missing? Did you try an "unofficial" image with
> non-free components?

+1;

Months ago, the installation was successful. At that time my laptop was
Lenovo ThinkPad E495.

Relative link is:
https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

Esteemed Debian experts and maintainers -

On Sun, Mar 27, 2022 at 11:26:37PM -0700, Larry Doolittle wrote:
> On Sun, Mar 27, 2022 at 10:45:03PM -0700, Larry Doolittle wrote:
> > I just upgraded my first machine from 11.2 to 11.3.
> > xauth fails in the context of startx.
> Workaround: create an empty directory, cd to that, and then startx.
> Something about running startx (and therefore xauth) in my home
> directory has it very confused.

The key command is
  xauth list $(hostname -f):0
When run in my home directory, it yields a Segmentation fault,
and leaves behind two zero-length lock files
  .Xauthority-l .Xauthority-c
that are hard-linked together.  I have to remove those files before
continuing.  When run in an empty subdirectory, that xauth command
(correctly) prints one line with an MIT-MAGIC-COOKIE-1, and
does not segfault.

In the context of /usr/bin/startx (xinit-1.4.0-1), this fault shows up
in line 199-200
authcookie=`xauth list "$displayname" \
| sed -n "s/.*$displayname[[:space:]*].*[[:space:]*]//p"` 2>/dev/null;
and the lock files left behind prevent the following xauth calls from
functioning.

I can run xauth (xauth-1:1.1-1) under gdb, but until and unless I recompile 
it with debugging symbols, the result is not so helpful:
Program received signal SIGSEGV, Segmentation fault.
__strncpy_avx2 () at ../sysdeps/x86_64/multiarch/strcpy-avx2.S:301
301 ../sysdeps/x86_64/multiarch/strcpy-avx2.S: No such file or directory.
(gdb) bt
#0  __strncpy_avx2 () at ../sysdeps/x86_64/multiarch/strcpy-avx2.S:301
#1  0x8cc3 in ?? ()
#2  0x9c8c in ?? ()
#3  0xa53d in ?? ()
#4  0xaa1e in ?? ()
#5  0x8634 in ?? ()
#6  0x77ca0d0a in __libc_start_main (main=0x8480, argc=3,
argv=0x7fffe378, init=, fini=,
rtld_fini=, stack_end=0x7fffe368)
at ../csu/libc-start.c:308
#7  0x870a in ?? ()
(gdb)

This behavior started when I upgraded to Bullseye 11.3 from 11.2.
Until I understand the fault and its trigger better, I can't guarantee 
that wasn't a coincidence.  The xauth segfault is definitely real and
a problem for me.

  - Larry

Predictable Network Interface Names

[basti]

Hello,

as I can read here [1] network names should be stable.
(Stable interface names even when hardware is added or removed)

First of all I have multiple PCIe NIC in a server.

What I see now is:

When I add or remove a PCIe card (USB card) the name is changed from 
enp5s3 to enp6s3 and back for example.


This is not what I understand with "Stable interface names", especially
when it rename multiple nic's.

I guess an empty PCI / PCIe slot is ignored.

Is there a way to not ignore empty slots?

[1] 
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> as I can read here [1] network names should be stable.
> (Stable interface names even when hardware is added or removed)

> [1] 
> https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

Sorry, but you've been lied to.

> What I see now is:
> 
> When I add or remove a PCIe card (USB card) the name is changed from enp5s3
> to enp6s3 and back for example.

Yes.  You've now seen direct evidence of the lie.  I guess I won't need
to post links to the wiki articles that say the same thing you've already
observed.

For most people, there are two paths forward:

1) If your system has exactly one ethernet interface, and if this is not
   likely to change at any point in the future, you can go back to the
   old old way of doing things -- let the kernel assign "eth0" to the
   first interface it finds, "eth1" to the second interface it finds,
   and so on.  Since it will only ever find one interface, that interface
   will always be named "eth0", and you can configure from there.

2) If you have multiple ethernet interfaces, or the possibility of this
   occurring in the future, take control of their names yourself.  Set
   up systemd.link(5) files to assign a name to each interface based on
   its MAC address, or some other identifying characteristic.

Re: Predictable Network Interface Names

[Brian]

On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:

> On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > as I can read here [1] network names should be stable.
> > (Stable interface names even when hardware is added or removed)
> 
> > [1] 
> > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> 
> Sorry, but you've been lied to.

I would see that as a bit strong. A lie is a deliberate action,
knowing the reality rests elesewhere. Good faith and all that :).
 
> > What I see now is:
> > 
> > When I add or remove a PCIe card (USB card) the name is changed from enp5s3
> > to enp6s3 and back for example.
> 
> Yes.  You've now seen direct evidence of the lie.  I guess I won't need
> to post links to the wiki articles that say the same thing you've already
> observed.

I would be interested in a couple of links to the same observations
as given by the OP.
> 
> For most people, there are two paths forward:
> 
> 1) If your system has exactly one ethernet interface, and if this is not
>likely to change at any point in the future, you can go back to the
>old old way of doing things -- let the kernel assign "eth0" to the
>first interface it finds, "eth1" to the second interface it finds,
>and so on.  Since it will only ever find one interface, that interface
>will always be named "eth0", and you can configure from there.

Recently, we have had a mail or two about iwd. It uses the kernel
interface wlan0, which broke my /e/n/i. In the end I went with the
flow on the basis that wlan0 is stable enough and changed /e/n/i
rather than fighting iwd.

If you were of the opinion that, with a single interface, a user
gets a stable. *easily memorable* name, I could agree with you.

> 2) If you have multiple ethernet interfaces, or the possibility of this
>occurring in the future, take control of their names yourself.  Set
>up systemd.link(5) files to assign a name to each interface based on
>its MAC address, or some other identifying characteristic.

That's good advice, but are MAC addresses memorable?

-- 
Brian.

Surgical instruments supply

[Saleem Yousaf]

We are manufacturer all kinds dental  surgical and beauty instruments then
supply to the others countries if you are interested in our instruments
please contact with us we can provide you our best quality with good price

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > Yes.  You've now seen direct evidence of the lie.  I guess I won't need
> > to post links to the wiki articles that say the same thing you've already
> > observed.
> 
> I would be interested in a couple of links to the same observations
> as given by the OP.


tries very hard to avoid mentioning the issue directly, but ultimately
has this paragraph down near the bottom of the section:

  it turns out even after all this there are still reported cases of
  interfaces changing their name on a reboot. All that needs to happen
  is that some buggy BIOS (or some new, less buggy version of a driver
  module, or systemd's naming policy) changes its mind about some detail
  like whether or not your hardware counts as the kind that should have
  an ONBOARD name. There are even reports of devices changing their
  PCI-port numbering due to other hardware being installed.

This links to
 which
goes into some detail.

I'm sure there are many more pages like this one.

> Recently, we have had a mail or two about iwd. It uses the kernel
> interface wlan0, which broke my /e/n/i. In the end I went with the
> flow on the basis that wlan0 is stable enough and changed /e/n/i
> rather than fighting iwd.

Wireless interfaces are not my strong suit.  I don't have any advice
for those.

> > 2) If you have multiple ethernet interfaces, or the possibility of this
> >occurring in the future, take control of their names yourself.  Set
> >up systemd.link(5) files to assign a name to each interface based on
> >its MAC address, or some other identifying characteristic.
> 
> That's good advice, but are MAC addresses memorable?

Doesn't matter.  You can choose a memorable name.  The MAC address is
simply the data point you place in the config file, so the system knows
this is the interface you're talking about.

unicorn:~$ cat /etc/systemd/network/10-lan0.link 
[Match]
MACAddress=18:60:24:77:5c:ec

[Link]
Name=lan0

That's what I'm using.  Of course, this relies on the MAC address being
consistent across boots.  I've heard of some cases where this isn't
true, but I believe those cases involved removable devices (USB network
interfaces or similar).

"lan0" is familiar to me from HP-UX, and it also isn't "eth0", so there's
no risk of collision with the kernel's default name scheme.  I have
no idea what happens if you try to assign the names "eth0" and "eth1"
to a pair of interfaces that come up as "eth1" and "eth0" by default.
Are the renames done sequentially?  Will they fail in this case?  I don't
know, and I don't want to find out the hard way.

Re: Predictable Network Interface Names

[Erwan David]

Le 30/03/2022 à 20:39, Greg Wooledge a écrit :


Doesn't matter.  You can choose a memorable name.  The MAC address is
simply the data point you place in the config file, so the system knows
this is the interface you're talking about.

unicorn:~$ cat /etc/systemd/network/10-lan0.link
[Match]
MACAddress=18:60:24:77:5c:ec

[Link]
Name=lan0

That's what I'm using.  Of course, this relies on the MAC address being
consistent across boots.  I've heard of some cases where this isn't
true, but I believe those cases involved removable devices (USB network
interfaces or similar).

"lan0" is familiar to me from HP-UX, and it also isn't "eth0", so there's
no risk of collision with the kernel's default name scheme.  I have
no idea what happens if you try to assign the names "eth0" and "eth1"
to a pair of interfaces that come up as "eth1" and "eth0" by default.
Are the renames done sequentially?  Will they fail in this case?  I don't
know, and I don't want to find out the hard way.


Be aware that bridge or bond interfaces get their mac address from one 
of the inner inetrface, thus you may have to add a macth (eg a match on 
the driver)

Re: Predictable Network Interface Names

[Brian]

On Wed 30 Mar 2022 at 14:39:33 -0400, Greg Wooledge wrote:

> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > > Yes.  You've now seen direct evidence of the lie.  I guess I won't need
> > > to post links to the wiki articles that say the same thing you've already
> > > observed.
> > 
> > I would be interested in a couple of links to the same observations
> > as given by the OP.
> 
> 
> tries very hard to avoid mentioning the issue directly, but ultimately
> has this paragraph down near the bottom of the section:
> 
>   it turns out even after all this there are still reported cases of
>   interfaces changing their name on a reboot. All that needs to happen
>   is that some buggy BIOS (or some new, less buggy version of a driver
>   module, or systemd's naming policy) changes its mind about some detail
>   like whether or not your hardware counts as the kind that should have
>   an ONBOARD name. There are even reports of devices changing their
>   PCI-port numbering due to other hardware being installed.
> 
> This links to
>  which
> goes into some detail.

Thanks. Very informative. As the second link says:

  The resulting reality is that your PCI based names are only
  stable if you change no hardware in the system. The moment
  you change any hardware all bets are off for all hardware.

This, plus your advice, could point the OP to a way forward.

How hardare specific the claim is is not explored.
 
> I'm sure there are many more pages like this one.
> 
> > Recently, we have had a mail or two about iwd. It uses the kernel
> > interface wlan0, which broke my /e/n/i. In the end I went with the
> > flow on the basis that wlan0 is stable enough and changed /e/n/i
> > rather than fighting iwd.
> 
> Wireless interfaces are not my strong suit.  I don't have any advice
> for those.

I only mentioned what I did bcause, om the whole, I am prepared to
accept interface renaming. The vast majority of users will not notice
that it has taken place.

-- 
Brian.

Re: Predictable Network Interface Names

[Erwan David]

Le 30/03/2022 à 21:15, Brian a écrit :

= which

goes into some detail.

Thanks. Very informative. As the second link says:

   The resulting reality is that your PCI based names are only
   stable if you change no hardware in the system. The moment
   you change any hardware all bets are off for all hardware.

This, plus your advice, could point the OP to a way forward.



I also got a name change with an upgrade (I do not remember wether it 
was kernel, systemd or udev).


SInce interfaces where combined in a bond, imagine the mess...

Re: Predictable Network Interface Names

[Dan Ritter]

Greg Wooledge wrote: 
> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > That's good advice, but are MAC addresses memorable?
> 
> Doesn't matter.  You can choose a memorable name.  The MAC address is
> simply the data point you place in the config file, so the system knows
> this is the interface you're talking about.
> 
> unicorn:~$ cat /etc/systemd/network/10-lan0.link 
> [Match]
> MACAddress=18:60:24:77:5c:ec
> 
> [Link]
> Name=lan0
> 
> That's what I'm using.  Of course, this relies on the MAC address being
> consistent across boots.  I've heard of some cases where this isn't
> true, but I believe those cases involved removable devices (USB network
> interfaces or similar).

Some NICs can have their MAC addresses changed permanently.

There were at least a few terrible NICs in history where an
entire production run got the same MAC address assigned.

Most NICs can have their MAC addresses reassigned after boot,
which will almost always be reset on next power cycle.

lan0 is a good name. I like names like "internal" and "dmz" and  "internet"
or "cogent" and "level3" -- either functional descriptors or
where their other ends are connected.

-dsr-

Re: Predictable Network Interface Names

[tomas]

On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> 
> > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > as I can read here [1] network names should be stable.
> > > (Stable interface names even when hardware is added or removed)
> > 
> > > [1] 
> > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> > 
> > Sorry, but you've been lied to.
> 
> I would see that as a bit strong. A lie is a deliberate action,
> knowing the reality rests elesewhere. Good faith and all that :).

Perhaps. But once I understood what problem this is trying to solve,
and how, I decided I haven't that problem, I have net.ifnames=0 in
my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.

Cheers
-- 
t


signature.asc
Description: PGP signature

Potential DNS leak with Wireguard + iwd + resolvconf

[Celejar]

Hi,

My wireless interface is controlled via iwd
(EnableNetworkConfiguration=true, NameResolvingService=resolvconf), and
I have a wireguard VPN used to remotely access my private network,
managed via e/n/i / ifupdown (using wg-quick).
In /etc/wireguard/wg0.conf, I have a "DNS=xxx.xxx.xxx.xxx" line,
pointing to a nameserver I run within my private network (reachable
through the wireguard tunnel).

When I connect to a wireless network (using DHCP,
handled by iwd, as above), /etc/resolv.conf gets populated with the
standard:

nameserver nnn.nnn.nnn.nnn
search a.b.c

When I then do "ifup wg0", my specified nameserver xxx.xxx.xxx.xxx is
*prepended* to the above lines, so I end up with the following
in /etc/resolv.conf:

nameserver xxx.xxx.xxx.xxx
nameserver nnn.nnn.nnn.nnn
search a.b.c

This seems wrong, and a potentially serious DNS leak: if my nameserver
xxx.xxx.xxx.xxx ever goes down, then nameserver nnn.nnn.nnn.nnn will be
automatically queried, which may be undesirable.

My understanding is that the VPN configuration should be *replacing* the
pre-VPN /etc/resolv.conf, rather then *prepending* the new nameserver to
it. Am I misunderstanding things, have I misconfigured things, or is
this indeed a (serious) bug?

-- 
Celejar

Re: startx xauth fails after upgrade to Bullseye 11.3

[Felix Miata]

Larry Doolittle composed on 2022-03-30 08:57 (UTC-0700):

> The xauth segfault is definitely real and
> a problem for me.

Is the problem avoided if you login via a display manager (gdm, sddm, lightdm,
etc.) instead of using startx?
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

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

Felix Miata

Re: Predictable Network Interface Names

[Nicholas Geovanis]

On Wed, Mar 30, 2022, 2:15 PM Brian  wrote:

> On Wed 30 Mar 2022 at 14:39:33 -0400, Greg Wooledge wrote:
>
> > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > > > Yes.  You've now seen direct evidence of the lie.  I guess I won't
> need
> > > > to post links to the wiki articles that say the same thing you've
> already
> > > > observed.
> > >
> > > I would be interested in a couple of links to the same observations
> > > as given by the OP.
> >
> > <
> https://wiki.debian.org/NetworkInterfaceNames#Complications_and_corner_cases
> >
> > tries very hard to avoid mentioning the issue directly, but ultimately
> > has this paragraph down near the bottom of the section:
> >
> >   it turns out even after all this there are still reported cases of
> >   interfaces changing their name on a reboot. All that needs to happen
> >   is that some buggy BIOS (or some new, less buggy version of a driver
> >   module, or systemd's naming policy) changes its mind about some detail
> >   like whether or not your hardware counts as the kind that should have
> >   an ONBOARD name. There are even reports of devices changing their
> >   PCI-port numbering due to other hardware being installed.
> >
> > This links to
> >  which
> > goes into some detail.
>
> Thanks. Very informative. As the second link says:
>
>   The resulting reality is that your PCI based names are only
>   stable if you change no hardware in the system. The moment
>   you change any hardware all bets are off for all hardware.
>
> This, plus your advice, could point the OP to a way forward.
>
> How hardare specific the claim is is not explored.
>
> > I'm sure there are many more pages like this one.
> >
> > > Recently, we have had a mail or two about iwd. It uses the kernel
> > > interface wlan0, which broke my /e/n/i. In the end I went with the
> > > flow on the basis that wlan0 is stable enough and changed /e/n/i
> > > rather than fighting iwd.
> >
> > Wireless interfaces are not my strong suit.  I don't have any advice
> > for those.
>
> I only mentioned what I did bcause, om the whole, I am prepared to
> accept interface renaming. The vast majority of users will not notice
> that it has taken place.
>

Does anyone here know how the BSD-derived "free" unices handle this
situation?
And how about free-ish Oracle/Solaris?
And AIX running on Intel hard/firmware?

-- 
> Brian.
>
>

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 04:00:42PM -0500, Nicholas Geovanis wrote:
> Does anyone here know how the BSD-derived "free" unices handle this
> situation?

I haven't used OpenBSD in several years, but the last time I used it,
it went something like this:

The OpenBSD kernel has drivers for lots of different kinds of network
interfaces.  Each driver has a separate concise name.  Some examples:

  ath — Atheros IEEE 802.11a/b/g wireless network device with GPIO
  fxp — Intel EtherExpress PRO/100 10/100 Ethernet device
  ie — Intel i82596 Ethernet device
  rl — Realtek 8129/8139 10/100 Ethernet device

When the kernel boots and does its hardware detection, any devices that
are detected are "claimed" by the appropriate drivers, and given a name
according to the driver which claims it.  E.g. if the system has one
Realtek 8129 interface, that interface will be named "rl0", regardless
of whether it's detected before or after an Intel PRO/100, which is
claimed by the fxp driver and named "fxp0".

As long as there's only one interface claimed by each driver, there will
never be any unpredictability in the names.

I'm not sure how it handles the naming when there are two or more
interfaces claimed by the same driver.  They'll be called "rl0" and "rl1"
for example, but I don't know how it determines which one gets which
name.

Re: Predictable Network Interface Names

[Brian]

On Wed 30 Mar 2022 at 21:50:53 +0200, to...@tuxteam.de wrote:

> On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > 
> > > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > > as I can read here [1] network names should be stable.
> > > > (Stable interface names even when hardware is added or removed)
> > > 
> > > > [1] 
> > > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> > > 
> > > Sorry, but you've been lied to.
> > 
> > I would see that as a bit strong. A lie is a deliberate action,
> > knowing the reality rests elesewhere. Good faith and all that :).
> 
> Perhaps.

Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?

> But once I understood what problem this is trying to solve,
> and how, I decided I haven't that problem, I have net.ifnames=0 in
> my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.

Well done! But, if there isn't any problem for you, why go to this
trouble? Leaving things as they are would seem not to do any harm.

-- 
Brian.

Re: Predictable Network Interface Names

[Michael Stone]

On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote:

Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
the truth and peddles false information purposefully?


Some people get excessively worked up over things like interface names 
and like to throw around strong words for dramatic effect. Just ignore 
the noise.


We've been over all this before. In general, for server-class systems, 
predictable interface names Just Work. These are the kinds of systems 
mostly likely to have 1) lots of interfaces and 2) a need for 
standardized build profiles. I've got quite a lot of these in 
production, and it works as advertised. One really nice thing this gets 
you that MAC-based renamed interfaces can't (apart from not needing to 
plug hundreds of MAC addresses into config files) is that when a NIC 
goes bad and you pop in a replacement...it has the same name. 

For most consumer sytems the interface name matters not one bit, because 
it's auto-discovered on install, will never change, and there's little 
likelihood that another interface will be added.


Then there's a small sliver of systems whose users like to shuffle 
things around, but for some reason can't stand having to learn anything 
new or change a config file or whatever, so they get unbelievably angry 
about a rather sensible naming scheme and throw out hot words like 
"lies" rather than just getting on with their lives. You'd think they'd 
just set their defaults the way they want them instead of venting on 
mailing lists, but the internet is the internet.

Re: Predictable Network Interface Names

[Greg Wooledge]

On Wed, Mar 30, 2022 at 05:55:11PM -0400, Michael Stone wrote:
> For most consumer sytems the interface name matters not one bit, because
> it's auto-discovered on install, will never change, and there's little
> likelihood that another interface will be added.

It's like you haven't even read this thread.

Predictable interface names *do* sometimes change.  And when that happens,
it's a huge deal, because all of the configuration files are set up for
the old name.  Things break, in an extremely visible way.

This is not some theoretical issue.  This is real.

Re: Predictable Network Interface Names

[Michael Stone]

On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:

It's like you haven't even read this thread.


of course I have


Predictable interface names *do* sometimes change.  And when that happens,
it's a huge deal, because all of the configuration files are set up for
the old name.  Things break, in an extremely visible way.


And they also broke before the predictable name scheme! And they can 
break if you lock names to MAC addresses! There are always ways things 
can break. If they break in an extremely visible way that's actually a 
good thing--the impact of simple interface reordering can be much more 
severe. And when they do break, the fix is generally pretty 
straightforward (that is, not such a big deal as to justify the bytes 
wasted complaining about it).



This is not some theoretical issue.  This is real.


It's also real that for the majority of systems it works fine. Why are 
you so invested in denying that reality?

Re: Running Steam Proton Games with primusrun

[Jonathan Marquardt]

On Tue, Mar 29, 2022 at 01:24:50PM -0500, Paul Johnson wrote:
> I'd recommend using pvkrun instead of primusrun if available.

Gives me the same error messages :(

>  This looks like you're somehow missing nvidia-glx.

$ apt search nvidia-glx
Sorting... Done
Full Text Search... Done
libegl-nvidia0/stable,now 460.91.03-1 amd64 [installed,automatic]
  NVIDIA binary EGL library

libgles-nvidia1/stable,now 460.91.03-1 amd64 [installed,automatic]
  NVIDIA binary OpenGL|ES 1.x library

libgles-nvidia2/stable,now 460.91.03-1 amd64 [installed,automatic]
  NVIDIA binary OpenGL|ES 2.x library

libglx-nvidia0/stable,now 460.91.03-1 amd64 [installed,automatic]
  NVIDIA binary GLX library

What am i missing?

Re: Running Steam Proton Games with primusrun

[Jonathan Marquardt]

On Sun, Mar 27, 2022 at 12:34:07PM -, Curt wrote:
> TL;DR (everything) but this bug?
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876033

I am not sure. None of the solutions described there worked for me.

There isn't even a libgl1-nvidia-glx package for bullseye.

Re: Predictable Network Interface Names

[Nicholas Geovanis]

On Wed, Mar 30, 2022, 5:32 PM Michael Stone  wrote:

> On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:
> >It's like you haven't even read this thread.
>
> of course I have
>
> >Predictable interface names *do* sometimes change.  And when that happens,
> >it's a huge deal, because all of the configuration files are set up for
> >the old name.  Things break, in an extremely visible way.
>
> And they also broke before the predictable name scheme! And they can
> break if you lock names to MAC addresses! There are always ways things
> can break. If they break in an extremely visible way that's actually a
> good thing--the impact of simple interface reordering can be much more
> severe. And when they do break, the fix is generally pretty
> straightforward (that is, not such a big deal as to justify the bytes
> wasted complaining about it).
>
> >This is not some theoretical issue.  This is real.
>
> It's also real that for the majority of systems it works fine. Why are
> you so invested in denying that reality?
>

Because some of us work in corporate data centers. And everything you claim
that helps us here really does the opposite. Because it was introduced in
large part to support mobile computing. Which does not and will never be
valuable on the back-end, the server end, where commerce occurs.

It's what we call a different "use-case".

>

Re: Running Steam Proton Games with primusrun

[Paul Johnson]

On Wed, Mar 30, 2022 at 5:41 PM Jonathan Marquardt 
wrote:

> On Tue, Mar 29, 2022 at 01:24:50PM -0500, Paul Johnson wrote:
> > I'd recommend using pvkrun instead of primusrun if available.
>
> Gives me the same error messages :(
>
> >  This looks like you're somehow missing nvidia-glx.
>
> $ apt search nvidia-glx
> Sorting... Done
> Full Text Search... Done
> libegl-nvidia0/stable,now 460.91.03-1 amd64 [installed,automatic]
>   NVIDIA binary EGL library
>
> libgles-nvidia1/stable,now 460.91.03-1 amd64 [installed,automatic]
>   NVIDIA binary OpenGL|ES 1.x library
>
> libgles-nvidia2/stable,now 460.91.03-1 amd64 [installed,automatic]
>   NVIDIA binary OpenGL|ES 2.x library
>
> libglx-nvidia0/stable,now 460.91.03-1 amd64 [installed,automatic]
>   NVIDIA binary GLX library
>
> What am i missing?
>

Thing that should not work but almost always works for me:  Mark the nvidia
GL packages for reinstall and let aptitude do its thing, restart and run
pvkrun glxgears to make sure things are working.  If that breaks, try
including the output of pvkrun glxinfo

Re: Predictable Network Interface Names

[Intense Red]

> Some people get excessively worked up over things like interface names
> and like to throw around strong words for dramatic effect. Just ignore
> the noise.

   I've just come to accept that the actual interface name is going to be some 
bizarre name. So I look it up, and then promptly rename it in "/etc/network/
interfaces" like so:

 - - - snip - - -
iface enp18s0f0 inet manual

auto LAN
iface LAN inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.1.1
dns-nameservers 192.168.168.1
dns-search locallan.net
bridge_ports enp18s0f0
 - - - snip - - -

   This uses Debian's bridge-utils package to rename the interface.

   From then on, my machines have an interface named LAN, WAN, DMZ, etc. -- 
all "logical" names and I don't have to deal with enp18s0f0 or enp18s1e0 or 
some such nonsense.


-- 
"When law and morality contradict each other, the citizen has the cruel 
alternative of either losing his moral sense or losing his respect for the 
law." -- Frederic Bastiat, 19th century French author and economist.

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

Felix -

Felix Miata  wrote:
> Is the problem avoided if you login via a display manager (gdm, sddm, lightdm,
> etc.) instead of using startx?

Beats me.  I don't have any software like that installed.
Would they run xauth before or after cd'ing to my home directory?

  - Larry

P.S.  Sorry about breaking threading; I can only read this list
via the web.

Upgrade from Buster to Bullsye: what to do about source.list for buster-backports

[Tom Browder]

I've been following the update guide and only have one apt source.list left
to handle: buster-backports:

Do I change it to bullseye-backports or just comment the line out?

Thanks.

-Tom

Re: Upgrade from Buster to Bullsye: what to do about source.list for buster-backports

[Greg Wooledge]

On Wed, Mar 30, 2022 at 06:53:26PM -0500, Tom Browder wrote:
> I've been following the update guide and only have one apt source.list left
> to handle: buster-backports:
> 
> Do I change it to bullseye-backports or just comment the line out?

Comment it out, and only add bullseye-backports (later) if you actually
need them.

Re: Predictable Network Interface Names

[gene heskett]

On Wednesday, 30 March 2022 18:31:36 EDT Michael Stone wrote:
> On Wed, Mar 30, 2022 at 06:19:17PM -0400, Greg Wooledge wrote:
> >It's like you haven't even read this thread.
> 
> of course I have
> 
> >Predictable interface names *do* sometimes change.  And when that
> >happens, it's a huge deal, because all of the configuration files are
> >set up for the old name.  Things break, in an extremely visible way.
> 
> And they also broke before the predictable name scheme! And they can
> break if you lock names to MAC addresses! There are always ways things
> can break. If they break in an extremely visible way that's actually a
> good thing--the impact of simple interface reordering can be much more
> severe. And when they do break, the fix is generally pretty
> straightforward (that is, not such a big deal as to justify the bytes
> wasted complaining about it).
> 
> >This is not some theoretical issue.  This is real.
> 
> It's also real that for the majority of systems it works fine. Why are
> you so invested in denying that reality?
> 
Perhaps because to the OP, it is a big deal, being locked away from the 
info that makes it and easy fix. I'm one that that fairly numerous crowd 
who has suffered thru fixing that, but from reading the mail for 20 some 
years, I've learned that complaining is a waste of time, the coder are 
gonna do it their way regardless of the crowd wanting blood. So I don't, 
until this attitude pushes my button.

Take care and stay well, thats more important than complaining to a stone 
wall today.

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, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis

Re: Does this happen often with sid?

[Chuck Zmudzinski]

On 3/29/22 3:16 PM, Joe wrote:

On Tue, 29 Mar 2022 14:36:55 -0400
Chuck Zmudzinski  wrote:



I do like synaptic also because it saves a history of all the
changes that it makes to the system.



The apt tools also do this, but in a more user-hostile way. See
/var/log/apt/history.log.

This may be what Synaptic uses, I'm never quite sure of the sharing
between the apt tools.

  


It looks to me like synaptic's history only logs the changes
synaptic makes, while /var/log/apt/history.log logs changes
made by any of the apt tools, including synaptic.

Chuck

Re: Upgrade from Buster to Bullsye: what to do about source.list for buster-backports

[Tom Browder]

On Wed, Mar 30, 2022 at 19:00 Greg Wooledge  wrote:

> On Wed, Mar 30, 2022 at 06:53:26PM -0500, Tom Browder wrote:
> > I've been following the update guide and only have one apt source.list
> left
> > to handle: buster-backports:


Thanks so much, Greg!

-Tom

Re: startx xauth fails after upgrade to Bullseye 11.3

[Felix Miata]

Larry Doolittle composed on 2022-03-30 19:31 (UTC-0700):

> Felix Miata wrote:

>> Is the problem avoided if you login via a display manager (gdm, sddm, 
>> lightdm,
>> etc.) instead of using startx?
 
> Beats me.  I don't have any software like that installed.

You could install one. Try LightDM. Uncompressed Size: 852 k, plus whatever 
deps.

> Would they run xauth before or after cd'ing to my home directory?

I don't know the middle of the chains of events that gets an X sessions
started, whether via DM, or startx, only some start and end points. I booted up 
a
Bullseye installation to multi-user.target, logged in, then ran startx, and got 
this:

# ls -alrtgG | tail -n9
drwxr-xr-x  3   4096 Feb  9 20:36 .mc
drwxr-xr-x 27   4096 Mar 16 21:23 ..
-rw---  1  33857 Mar 30 20:20 .bash_history
-rw---  1 99 Mar 30 20:23 .Xauthority
-rw-r--r--  1 52 Mar 30 20:23 .DCOPserver_ab560__0
lrwxrwxrwx  1 26 Mar 30 20:23 .DCOPserver_ab560_:0 -> 
/root/.DCOPserver_ab560__0
-rw---  1 31 Mar 30 20:23 .mcoprc
drwx-- 15   4096 Mar 30 20:23 .
-rw---  1 103873 Mar 30 20:23 .xsession-errors

Next I rebooted to graphical.target, logged in, and got this:
# ls -alrtgG | tail -n9
drwxr-xr-x  3   4096 Feb  9 20:36 .mc
drwxr-xr-x 27   4096 Mar 30 20:39 ..
-rw---  1 99 Mar 30 20:49 .Xauthority
-rw-r--r--  1 52 Mar 30 20:49 .DCOPserver_ab560__0
lrwxrwxrwx  1 26 Mar 30 20:49 .DCOPserver_ab560_:0 -> 
/root/.DCOPserver_ab560__0
-rw---  1 31 Mar 30 20:49 .mcoprc
-rw---  1  34072 Mar 30 20:49 .bash_history
drwx-- 15   4096 Mar 30 20:49 .
-rw---  1  48801 Mar 30 20:49 .xsession-errors
-- 
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

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

Felix Miata

Re: Predictable Network Interface Names

[tomas]

On Wed, Mar 30, 2022 at 05:55:11PM -0400, Michael Stone wrote:
> On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote:
> > Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
> > the truth and peddles false information purposefully?
> 
> Some people get excessively worked up over things like interface names and
> like to throw around strong words for dramatic effect. Just ignore the
> noise.

Somewhat self-referential. I'm not the one getting worked up here ;-)

Let's not quarrel over it. You like your predictable names. I like
mine. Let's Just Get Along (TM) :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: Predictable Network Interface Names

[tomas]

On Wed, Mar 30, 2022 at 10:38:10PM +0100, Brian wrote:
> On Wed 30 Mar 2022 at 21:50:53 +0200, to...@tuxteam.de wrote:
> 
> > On Wed, Mar 30, 2022 at 07:18:07PM +0100, Brian wrote:
> > > On Wed 30 Mar 2022 at 13:32:53 -0400, Greg Wooledge wrote:
> > > 
> > > > On Wed, Mar 30, 2022 at 05:35:12PM +0200, basti wrote:
> > > > > as I can read here [1] network names should be stable.
> > > > > (Stable interface names even when hardware is added or removed)
> > > > 
> > > > > [1] 
> > > > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
> > > > 
> > > > Sorry, but you've been lied to.
> > > 
> > > I would see that as a bit strong. A lie is a deliberate action,
> > > knowing the reality rests elesewhere. Good faith and all that :).
> > 
> > Perhaps.
> 
> Perhaps? Perhaps what? Perhaps it is a lie? freedesktop conceals
> the truth and peddles false information purposefully?

Calm down. There are many shades between Truth (TM) and Lie (TM).
My take is that this specific shade is failing to admit that the
freedesktop folks set out to solve a generally unsolvable problem.

This is one weakness I see with freedesktop often. They try to
fight complexity with ever more complexity, with the end result
of a more user-unfriendly (because less understandable) system.

Nevertheless I thank freedesktop for keeping X (which I do use
a lot) up and running. It's not that I hate them (much less the
people working there). I'm thankful.

Good intentions, pavements, hell, all that.

But hey, this is my take. I'm not in the mood to wage a war over
it. You get to keep your take, I get to keep mine. We could even
remain friends over that.

> > But once I understood what problem this is trying to solve,
> > and how, I decided I haven't that problem, I have net.ifnames=0 in
> > my GRUB_CMDLINE_LINUX_DEFAULT, in /etc/default/grub.
> 
> Well done! But, if there isn't any problem for you, why go to this
> trouble? Leaving things as they are would seem not to do any harm.

To what trouble? Adding a boot option to my kernel? The trouble
was to find out which one. After that, I'm a happy camper :)

See, for an anecdote: long time ago (this was Linux kernel 2.0.36)
a group of us customised a distro (yes, it was a Debian. Must
have been around Potato or Woody) for a local hardware vendor.
It was a firewall appliance, with four network cards. One of
the ethernet ports was labelled "Internet", the other three "internal
net".

Guess which kind of problem we faced?

After a dive into the PCI spec, the specs of the motherboard
we used at the time, etc. we reached the conclusion that there
is no way to be sure we know which is which (if you follow the
thread here you'll discover exactly that pattern, years down
the history). PCI slots ain't it, because, at the end, hardware
does what it wants. Things become even worse when devices are
hanging off an USB tree. MACs? Some cards are chamaleons and
can change that [1] on the fly. Some can even have more than
one. Yadda, yadda.

Since then, I learnt that I like to relax call my interfaces
"eth0" and "wlan0".

Can we still be friends?

Cheers

[1] I won't bore you with /that/ anecdote, although it's
   funny :)

-- 
t


signature.asc
Description: PGP signature

Re: startx xauth fails after upgrade to Bullseye 11.3

[Larry Doolittle]

I seem to have rediscovered Debian bug 889720
xauth crashes when directory name matches host name
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889720
(Feb 2018)

So, nothing to do with the Bullseye upgrade.
I must have created that directory-matching-hostname in the
process of setting up for the upgrade.

  - Larry