Re: Where to look into when system crashes

[tomas]

On Thu, Feb 23, 2023 at 01:41:42PM +0800, Qiming Ye wrote:
> We have found out it's problem of the current.

You mean electrical current?

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: kmail ha dejado de funcionar después de actualizar.

[Camaleón]

El 2023-02-22 a las 10:15 -0600, jfernan...@boruro.com escribió:

> kmail ha dejado de funcionar después de actualizar.
> 
> Al intentar descargar los correos aparece una notificación:
> No es posible guardar los correos descargados.
> Failed to append item
> 
> Al intentar enviar correos muestra:
> Hubo problemas al intentar encolar el mensaje para enviar: Failed to append
> item
> 
> No permite guardar el correo como borrador:
> Ha fallado al guardar el mensaje: Failed to append item
> 
> 
> No deja ver los correos descargados y se queda bloqueado con un mensaje:
> "Por favor, espere mientras se transfiere el mensaje"
> 
> 
> Tengo la versión de kmail 5.9.3
> Las bibliotecas:
> KDE Frameworks 5.54.0
> Qt 5.11.3 (compilado con 5.11.3)
> El sistema de ventanas xcb

Inicia kmail desde la consola para ver qué sucede cuando intentas
descargar/enviar correos, seguramente te dé algún mensaje de error que 
te ayude a depurar el problema.

> Ayer actualice:
> Upgrade:

(...)

> mariadb-common:amd64 (1:10.3.36-0+deb10u2, 1:10.3.38-0+deb10u1),

(...)

> mariadb-server-core-10.3:amd64 (1:10.3.36-0+deb10u2, 1:10.3.38-0+deb10u1),
> mariadb-client-core-10.3:amd64 (1:10.3.36-0+deb10u2, 1:10.3.38-0+deb10u1),
> libmariadb3:amd64 (1:10.3.36-0+deb10u2, 1:10.3.38-0+deb10u1),

KMail tira de Akonadi, que a su vez usa como backend algún sistema de 
base de datos (MariaDB entre las opciones), quizá ese haya sido el 
problema.

> El sistema es:
> suprop@castor:~$ uname -a
> Linux castor 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)
> x86_64 GNU/Linux

¿Debian Buster?
 
> suprop@castor:~$ cat /etc/os-release
> PRETTY_NAME="Debian GNU/Linux bullseye/sid"
> NAME="Debian GNU/Linux"
> ID=debian
> HOME_URL="https://www.debian.org/;
> SUPPORT_URL="https://www.debian.org/support;
> BUG_REPORT_URL="https://bugs.debian.org/;
> 
> ¿Alguna sugerencia para solucionarlo?

Ese kernel tan antiguo (4.19) y esa versión de Debian (bullseye/sid) no
me cuadran. ¿Tienes repositorios con fuentes mezcladas?

Saludos,

-- 
Camaleón 

Re: Where to look into when system crashes

[Qiming Ye]

We have found out it's problem of the current.

Thank you for the support.

- Tim

On 2023-02-22 22:38+0700, Max Nikulin wrote:

On 22/02/2023 11:34, Qiming Ye wrote:


I have a Debian box running for 280+ days without rebooting, 
recently it crashes pretty much everyday.  Where should I look for 
the reason of crashing?


sudo journalctl

You may limit logs to specific boot by adding option like "--boot=-1". 
Scroll to end [G] or add "--end" flag to see last messages before 
crash, however it is better to pay some attention to all errors.

Re: XFCE updates

[tomas]

On Wed, Feb 22, 2023 at 10:20:39PM +, ghe2001 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I use XFCE4 for my GUI desktop, and I subscribe to XFCE's discussion list.  I 
> see lots of posts on the list about XFCE things being updated, but I run 
> stable, and I've been told to stick to only Debian updates.  What, if 
> anything, happens to the updates advertised by XFCE?  Do they go into Sid?  
> Testing?

I'd recommend [1] or, for the more technical description,
[2].

In a nutshell, software (major) versions don't change in
the stable distribution unless something very bad happens.
Maintainers prefer to backport security and other fixes
to the versions already there. This is what "stable" means.

As a corollary, interfaces between the different parts
stay more or less stable. One package update doesn't carry
a flurry of dependency updates after it.

The nice part of that is that you can, most of the time,
just "apt update && apt upgrade" without much risk.

You pay for that with somewhat older versions.

When some "upstream" (as Debian calls that: in your case
it would be XFCE) publishes a new version, that goes first
into sid. There it breaks other things (that's why it is
called sid). When it stops breaking things it goes into
testing.

At some point in time (called "freeze"), the stream of
packages from sid to testing is stopped: that's when the
new stable version is about to hatch from testing.

Once that is done, the stream from sid to the new testing
starts again.

That was a very rough map, possibly with some corners
cut.

Cheers
[1] https://www.debian.org/doc/manuals/debian-faq/choosing.en.html
[2] https://www.debian.org/releases/

-- 
t


signature.asc
Description: PGP signature

Re: Debian installer chooses the wrong NVidia driver

[Felix Miata]

Jeremy Hendricks composed on 2023-02-22 16:02 (UTC-0500):

> I think I know why.
> https://en.m.wikipedia.org/wiki/GeForce_600_series

> They made Kepler and Fermi variants of the GT 630. The nvidia driver
> probably wrongly assumes it’s Kepler.

> Van Snyder composed on 2023-02-22 13:01 (UTC-0800):

>> # nvidia-detect
>> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108
>> [GeForce GT 630] [10de:0f00] (rev a1)

>> Van Snyder wrote:

>> I have an NVidia GF108 video card. It works just fine, so I don't see a
>> reason to replace it.

>> It needs the nvidia-legacy-390xx-driver.

>> But when I installed Debian 11, it chose the 470 driver, which doesn't
>> work with GF108.

Jeremy's right you have a Fermi. Like mine it shouldn't need any proprietary 
driver:

# xdriinfo
Screen 0: nouveau
# inxi -C --vs
inxi 3.3.24-00 (2022-12-10)
CPU:
  Info: quad core model: AMD Phenom II X4 965 bits: 64 type: MCP cache:
L2: 2 MiB
  Speed (MHz): avg: 3423 min/max: N/A cores: 1: 3423 2: 3423 3: 3423 4: 3423
# inxi -GSaz --zl --hostname
System:
  Host: gb970 Kernel: 6.0.0-6-amd64 arch: x86_64 bits: 64 compiler: gcc
v: 12.2.0 parameters: root=LABEL= ipv6.disable=1 net.ifnames=0
plymouth.enable=0 noresume mitigations=auto consoleblank=0 vga=791
video=1440x900@60 5
  Desktop: Trinity v: R14.0.13 tk: Qt v: 3.5.0 info: kicker wm: Twin v: 3.0
vt: 7 dm: 1: TDM 2: XDM Distro: Debian GNU/Linux bookworm/sid
Graphics:
  Device-1: NVIDIA GF108 [GeForce GT 630] vendor: Gigabyte driver: nouveau
v: kernel non-free: series: 390.xx+ status: legacy-active (EOL~late 2022)

*** arch: Fermi code: GF1xx process: 40/28nm built: 2010-16 pcie: gen: 1 ***

speed: 2.5 GT/s lanes: 16 ports: active: DVI-I-1,HDMI-A-1 empty: VGA-1
bus-ID: 01:00.0 chip-ID: 10de:0f00 class-ID: 0300 temp: 46.0 C
  Display: x11 server: X.Org v: 1.21.1.6 driver: X: loaded: modesetting
dri: nouveau gpu: nouveau display-ID: :0 screens: 1
  Screen-1: 0 s-res: 3600x1200 s-dpi: 120 s-size: 762x254mm (30.00x10.00")
s-diag: 803mm (31.62")
  Monitor-1: DVI-I-1 pos: primary,left model: NEC EA243WM serial: 
built: 2011 res: 1920x1200 hz: 60 dpi: 94 gamma: 1.2
size: 519x324mm (20.43x12.76") diag: 612mm (24.1") ratio: 16:10 modes:
max: 1920x1200 min: 640x480
  Monitor-2: HDMI-A-1 mapped: HDMI-1 pos: right model: Dell P2213
serial:  built: 2012 res: 1680x1050 hz: 60 dpi: 90 gamma: 1.2
size: 473x296mm (18.62x11.65") diag: 558mm (22") ratio: 16:10 modes:
max: 1680x1050 min: 720x400
  API: OpenGL v: 4.3 Mesa 22.3.3 renderer: NVC1 direct-render: Yes

Same difference if using Bookworm.
-- 
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: Evolution doesn't receive messages in Debian 11.

[David]

On Thu, 23 Feb 2023 at 12:51, Van Snyder  wrote:
> On Thu, 2023-02-23 at 11:39 +1100, David wrote:
> On Thu, 23 Feb 2023 at 09:21, Van Snyder  wrote:
> On Wed, 2023-02-22 at 16:13 -0500, Dan Ritter wrote:
> Van Snyder wrote:

> You are mixing way too many things here. Better tell us the
> contents of all your /etc/apt/sources.list and
> /etc/apt/sources.list.d/* files.

> opm-ubuntu-ppa-kinetic.list
> opm-ubuntu-ppa-kinetic.list.save
> skype-stable.list
> skype-stable.list.save
>
> I have a line for
> deb [arch=amd64,i386] https://apt.repos.intel.com/oneapi all main
>
> but there is also a file /etc/apt/sources.list/Intel/oneAPI.list that has
> the same line.
>
> Moving everything from /etc/apt/sources.list.d to
> /etc/apt/save.sources.list.d makes the update and dist-upgrade appear to
> work without complaint.

> What output do you see for this command:
>   aptitude search '~i' -F '%p %O#' | grep -v Debian

> Output is attached.

(sorry for the broken quotes above)

I will attempt to comment on the results, but many people here are much
more competent with apt* tools than I am, so I hope they will comment also.

The command I suggested reports packages whose origin is unknown to the apt
database.  There's 118 of them in your output, including g++-9, many libs
and 6 kernels, pythons 2.7 and 3.9 and perl 5.

My understanding of the origin = (installed locally) tags in that output is
that this means that the apt* tools are unable to manage updating of these
packages because it cannot associate them with a repository.

So anything in future that involves/requires a change to any of these
packages will require you to do the dependency resolution yourself because
apt* won't be able to do that for you.

Another way to see what repositories have been used on that machine is
to run:
  ls /var/lib/apt/lists/*Packages

It would also be interesting to see the output of that command if you wish
to share it.

Debian bug report etiquette

[John Crawley]

Hello people,

with the Bookworm soft freeze already under way, the time left for fixing 
packages is running low, and there's a specific case where I'd appreciate 
advice.

The package is terminator[1], a python based extension (I think) of Gnome 
terminal. I don't use it myself, but the current Bookworm version breaks Debian 
Policy (it declares compliance with 4.6.1) in its handling of the -e option [2] 
when invoked as x-terminal-emulator. It declares Provides: x-terminal-emulator 
and sets itself as a Debian alternative for x-terminal-emulator in its 
maintainer scripts.

There is an existing bug [3] with the title "Handling of -e violates policy for 
x-terminal-emulator" - the issue was fixed upstream some time ago but the bug 
remained open. The bug has now returned with the same result of breaking compliance with 
Debian Policy.

I was unsure whether to post a new bug report or append to the existing one, 
but did the latter [4].

The issue is fixed by an upstream git commit [5] easily applied by a patch 
(confirmed), which would make the package fit for release. (Other maintainer 
options could be to drop the claim to provide x-terminal-emulator or drop the 
package itself.)

My question: I'm in doubt whether the maintainer (Debian Python Team) will notice the issue in time 
for the Bookworm release - would posting a new bug report be seen as "nagging"? Should I 
just leave it as it is? (I don't personally care all that much about Terminator itself.) Is there 
some other action that would be more appropriate? Is there a polite way to push the severity up 
from its current "normal"? How important is breaking Debian Policy?

Also: is this the right mailing list to ask such questions?

Best wishes,
John


[1] https://packages.debian.org/bookworm/terminator
[2] 
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#packages-providing-a-terminal-emulator
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901245
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901245#17
[5] 
https://github.com/gnome-terminator/terminator/commit/91cc928f0de1f9d6d51136cf50f06c35b5faca62

Re: Virtual machine affects client screen resolution

[Max Nikulin]

On 19/02/2023 01:01, Roy J. Tellason, Sr. wrote:

On Saturday 18 February 2023 12:17:20 am Max Nikulin wrote:

echo "$DISPLAY"


So this got me curious,  and I tried it out.  In the terminal that's
running inside of the virtualbox instance where I'm doing emails,  it
comes back with:

:0


Have you tried to emulate multiple monitors in virtualbox?


But in a terminal which is running on the host Debian system,  it comes back 
with:

:0.0

I wonder why the difference?


My guess is that it may depend on graphics adapter and its driver. I 
have heard that a display may have several screens (it is not the same 
as multiple monitors that show different regions of the same display and 
screen). I have never tried such configuration. I am unsure which 
approach is used in nvidia's xinerama.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[John Conover]

On 2/22/23, daven...@tuxfamily.org  wrote:
>
> There is an unidentified process that decides it's ok to delete and
> recreate /etc/resolv.conf without asking user/admin,
> The problem is, the problematic process is not work's VPN related and
> creates the file with wrong resolver's IP. The IP corresponds to my home
> router IP, which does has a DNS resolver and it works as it should. BUT
> my home's router DNS obviously don't know jack about work internal
> servers, on which I work… and work's proxy as well, which when it cannot
> be resolved… breaks everything using HTTP.

Might look at:

/etc/network/interfaces.d/setup

as explained in "man interfaces". (That file can/might be changed via
the network symbol in the window manager's configuration bar/menu
system, usually required with root/sudo privileges.)

John

-- 

John Conover, cono...@panix.com, http://www.johncon.com/

Re: Virtual machine affects client screen resolution

[Albert S.]

My thanks to David Wright and Max Nikulin.

That was a good wake-up call. Most of my VMs are safe, but it was 
interesting to learn what was really going on.


ForwardX11 was enabled for the ssh session. Initially I imagined 
vncviewer (to the KVM host though ssh) was the one causing the problem, 
but now it is clear that the ssh session to the VM was responsible for it.


This was the result of checking open tcp ports on the VM:
$ netstat -nlt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State
...
tcp0  0 127.0.0.53:53   0.0.0.0:*   LISTEN
tcp0  0 127.0.0.1:6010  0.0.0.0:*   LISTEN

$ echo $DISPLAY
localhost:10.0

It was also a good opportunity to learn about XPRA and test it.

Albert


On 2/17/23 22:15, David Wright wrote:

On Fri 17 Feb 2023 at 20:57:38 (-0500), Albert S. wrote:

Running “xrandr --size 800x600” on a virtual machine affected both
monitors on my workstation. That was completely unexpected and I am
wondering how to explain that.

Below you will find the detailed description.


[ … ]


But my real concern is how a xrandr command issued on a VM which is
running on another machine could affect the video of the client
machine used to access that VM.

I would appreciate an explanation for that.


The clue is in your use of the word "client". In fact, the "video of
the machine used to access that VM" is the X /server/. The
applications that you control on this machine, and others that you
connect to, which you thought were servers, are in fact the clients.

So, for example, I'm sitting at my All-in-One, running an X server as
usual. In a room down the hall, I have a laptop that's booted up, but
hasn't been used yet. It's sitting at a VC prompt waiting for someone
to log in. There's no X server running on it.

I've connected to the laptop with ssh from an xterm here on my A-i-O,
and typed into the /laptop/:

$ xrandr --output eDP --rotate right

and immediately, my screen blanks, comes back a second later, and
everything is sideways. When I type:

$ xrandr --output eDP --rotate normal

then normality is restored.

So I ran xrandr on the laptop, but xrandr is not concerned with that
machine, but only with the X /server/, running on my A-i-O.

https://en.wikipedia.org/wiki/X_Window_System

Cheers,
David.

Re: Evolution doesn't receive messages in Debian 11.

[Van Snyder]

On Thu, 2023-02-23 at 11:39 +1100, David wrote:
> On Thu, 23 Feb 2023 at 09:21, Van Snyder 
> wrote:
> > On Wed, 2023-02-22 at 16:13 -0500, Dan Ritter wrote:
> > Van Snyder wrote:
> 
> > You are mixing way too many things here. Better tell us the
> > contents of all your /etc/apt/sources.list and
> > /etc/apt/sources.list.d/* files.
> 
> > opm-ubuntu-ppa-kinetic.list
> > opm-ubuntu-ppa-kinetic.list.save
> > 
> > skype-stable.list
> > skype-stable.list.save
> > 
> > I have a line for
> > 
> > deb [arch=amd64,i386] https://apt.repos.intel.com/oneapi all main
> > 
> > but there is also a file /etc/apt/sources.list/Intel/oneAPI.list
> > that has
> > the same line.
> > 
> > Moving everything from /etc/apt/sources.list.d to
> > /etc/apt/save.sources.list.d makes the update and dist-upgrade
> > appear to
> > work without complaint.
> 
> Worth reading:
>   https://wiki.debian.org/DontBreakDebian
> 
> > Hopefully, that will cure the problems.
> 
> Fixing your sources.list isn't going to uninstall all your
> non-Debian packages. Which might cause problems
> in future, per the above wiki page.
> 
> What output do you see for this command:
>   aptitude search '~i' -F '%p %O#' | grep -v Debian

Output is attached.


cpp-9 (installed locally)
crda (installed locally)
edrawmax (installed locally)
freeglut3 (installed locally)
g++-9 (installed locally)
gcc-9 (installed locally)
gcc-9-base (installed locally)
gfortran-9 (installed locally)
hddtemp (installed locally)
igfxdcd (installed locally)
libabsl20200923 (installed locally)
libaom0 (installed locally)
libasan5 (installed locally)
libavcodec58 (installed locally)
libavdevice58 (installed locally)
libavfilter7 (installed locally)
libavformat58 (installed locally)
libavif9 (installed locally)
libavresample4 (installed locally)
libavutil56 (installed locally)
libcfitsio9 (installed locally)
libcodec2-0.9 (installed locally)
libdav1d4 (installed locally)
libdns-export1110 (installed locally)
libffi7 (installed locally)
libflac8 (installed locally)
libfwupdplugin1 (installed locally)
libgav1-0 (installed locally)
libgcc-9-dev (installed locally)
libgfortran-9-dev (installed locally)
libicu67 (installed locally)
libidn11 (installed locally)
libigdgmm11 (installed locally)
libigdgmm11:i386 (installed locally)
libilmbase25 (installed locally)
libisc-export1105 (installed locally)
libjim0.79 (installed locally)
libjsoncpp24 (installed locally)
libkf5screen7 (installed locally)
libldap-2.4-2 (installed locally)
libldap-2.4-2:i386 (installed locally)
libmalcontent-ui-0-0 (installed locally)
libnautilus-extension1a (installed locally)
libnetpbm10 (installed locally)
libnetpbm10-dev (installed locally)
libntfs-3g883 (installed locally)
libokular5core9 (installed locally)
libopenexr25 (installed locally)
libotf0 (installed locally)
libperl5.32 (installed locally)
libphodav-2.0-0 (installed locally)
libphodav-2.0-common (installed locally)
libplacebo72 (installed locally)
libpoppler102 (installed locally)
libpostproc55 (installed locally)
libproj19 (installed locally)
libprotobuf-lite23 (installed locally)
libpython2-stdlib (installed locally)
libpython2.7-minimal (installed locally)
libpython2.7-stdlib (installed locally)
libpython3.9 (installed locally)
libpython3.9-minimal (installed locally)
libpython3.9-stdlib (installed locally)
libqalculate20 (installed locally)
libruby2.7 (installed locally)
libsrt1.4-gnutls (installed locally)
libssl1.1 (installed locally)
libssl1.1:i386 (installed locally)
libstdc++-9-dev (installed locally)
libswresample3 (installed locally)
libswscale5 (installed locally)
libtesseract4 (installed locally)
libtiff5 (installed locally)
libtiff5:i386 (installed locally)
libvpx6 (installed locally)
libwebkit2gtk-4.0-37-gtk2 (installed locally)
libwebp6 (installed locally)
libwebp6:i386 (installed locally)
libwxbase3.0-0v5 (installed locally)
libwxgtk3.0-gtk3-0v5 (installed locally)
libx264-160 (installed locally)
libx265-192 (installed locally)
libxmlb1 (installed locally)
linux-compiler-gcc-10-x86 (installed locally)
linux-headers-4.19.0-10-common (installed locally)
linux-headers-4.19.0-12-common (installed locally)
linux-headers-4.19.0-9-common (installed locally)
linux-headers-5.10.0-10-amd64 (installed locally)
linux-headers-5.10.0-10-common (installed locally)
linux-headers-5.10.0-13-amd64 (installed locally)
linux-headers-5.10.0-13-common (installed locally)
linux-headers-5.10.0-16-amd64 (installed locally)
linux-headers-5.10.0-16-common (installed locally)
linux-headers-5.10.0-18-amd64 (installed locally)
linux-headers-5.10.0-18-common (installed locally)
linux-headers-5.10.0-20-amd64 (installed locally)
linux-headers-5.10.0-20-common (installed locally)
linux-headers-5.10.0-9-amd64 (installed locally)
linux-headers-5.10.0-9-common (installed locally)
linux-image-5.10.0-10-amd64 (installed locally)
linux-image-5.10.0-13-amd64 (installed locally)
linux-image-5.10.0-16-amd64 (installed locally)
linux-image-5.10.0-18-amd64 (installed locally)

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Cindy Sue Causey]

On 2/22/23, daven...@tuxfamily.org  wrote:
>
> There is an unidentified process that decides it's ok to delete and
> recreate /etc/resolv.conf without asking user/admin,
> The problem is, the problematic process is not work's VPN related and
> creates the file with wrong resolver's IP. The IP corresponds to my home
> router IP, which does has a DNS resolver and it works as it should. BUT
> my home's router DNS obviously don't know jack about work internal
> servers, on which I work… and work's proxy as well, which when it cannot
> be resolved… breaks everything using HTTP.


Hi.. I didn't know where to jump into this so am responding to that
paragraph in its original post. Having just debootstrap'ed again, one
thing I do is verify /etc/resolv.conf's content. The following,
slightly lengthy blurb has begun showing up where I'd never seen it
before. I'm sharing it with hopes maybe it hints at what might be a
trigger for the reset:

 BEGIN CONTENT FROM NEW, UNALTERED /etc/resolv.conf FILE +
# This is /run/systemd/resolve/stub-resolv.conf managed by
man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .
 END CONTENT FROM NEW, UNALTERED /etc/resolv.conf FILE +

Those last three lines worked for Mint, but they did not work for
Debian. So I defiantly altered that file. I commented those three
lines out, tracked down my ISP's nameserver values,** and plugged them
in. I was able to connect immediately after that.

When I tried to do that with some other distribution, possibly Mint
again, it would reset as is being described in this thread and as is
seemingly implied in resolv.conf's "do not edit" line. I have no clue
why Debian is not resetting now, but I'm VERY grateful it's remaining
stable.

Having now actually read more of that blurb, I didn't follow any
symlinks. Thanks to issues over the years, /etc/resolv.conf is the
first place I go if an Internet connection is not working as expected.

Lastly, I just tried "ls -ld" on that long /run line to
stub-resolv.conf. It's "no such file" so that would explain why it's
not resetting on my end. Resolvectl is also pulling up as not found.

Those all definitely explain why I'm able to type online right now. If
I was feeling brave right now, I would try messing around with doing
what it takes to get resolvectl in control, but I'm not (feeling
brave). :)

Cindy :)

** My ISP's nameserver values were found in connman's GUI, of all
things. Connman has NEVER worked for me. I have no idea why it's
working now. I didn't manually install it. Connman came in
automatically somehow related to the LXQt desktop environment. Just
leaving this here in case it somehow is playing a part in why my
resolv.conf is not resetting. You never know..

-- 
Talking Rock, Pickens County, Georgia, USA
* GRUB IS WORKING! Just put ^ in front of metadata_csum_seed in mke2fs.conf! *

Re: Evolution doesn't receive messages in Debian 11.

[David]

Hi Van Snyder

You replied to my mailing list message by sending
a file attachment directly to me only.
It would be better if you send that information to the
mailing list, so that other readers are not excluded
from seeing your reply, and you can benefit from group
discussion.

Re: [HS] Facturation électronique obligatoire. Comment s'y préparer ?

[debian-user-french]

Bonjour,
Ce qui est important c'est de mettre tous les éléments obligatoires 
(voir https://www.economie.gouv.fr/cedef/facture-mentions-obligatoires).

Ensuite n'importe quel logiciel va convenir.
Depuis plus de 15 ans j'adresse des factures "à la main" en traitement 
de texte converties en pdf (des entreprises du CAC 40 font partie des 
destinataires, aucun soucis).

Salutations
Yann

Le 22/02/2023 à 17:26, Olivier a écrit :

Bonjour,

Je viens d'apprendre que l'article "26 de la loi de finances
rectificative pour 2022 prévoit l’obligation de facturation
électronique dans les échanges entre entreprises assujetties à la TVA
et établies en France" (cf [1]).

Avez-vous connaissance d'outils ou prestataires permettant à des
entreprises dont l'informatique repose sur Debian, de se préparer à
cette nouvelle obligation ? Quel retour d'expérience ?

Comment se rétribuent les plateformes de dématérialisation ?

[1] 
https://www.impots.gouv.fr/facturation-electronique-entre-entreprises-et-transmission-de-donnees-de-facturation

Slts

Re: Evolution doesn't receive messages in Debian 11.

[David]

On Thu, 23 Feb 2023 at 09:21, Van Snyder  wrote:
> On Wed, 2023-02-22 at 16:13 -0500, Dan Ritter wrote:
> Van Snyder wrote:

> You are mixing way too many things here. Better tell us the
> contents of all your /etc/apt/sources.list and
> /etc/apt/sources.list.d/* files.

> opm-ubuntu-ppa-kinetic.list
> opm-ubuntu-ppa-kinetic.list.save
>
> skype-stable.list
> skype-stable.list.save
>
> I have a line for
>
> deb [arch=amd64,i386] https://apt.repos.intel.com/oneapi all main
>
> but there is also a file /etc/apt/sources.list/Intel/oneAPI.list that has
> the same line.
>
> Moving everything from /etc/apt/sources.list.d to
> /etc/apt/save.sources.list.d makes the update and dist-upgrade appear to
> work without complaint.

Worth reading:
  https://wiki.debian.org/DontBreakDebian

> Hopefully, that will cure the problems.

Fixing your sources.list isn't going to uninstall all your
non-Debian packages. Which might cause problems
in future, per the above wiki page.

What output do you see for this command:
  aptitude search '~i' -F '%p %O#' | grep -v Debian

Re: XFCE updates

[Charles Curley]

On Wed, 22 Feb 2023 22:20:39 +
ghe2001  wrote:

> What, if anything, happens to the updates advertised by XFCE?  Do
> they go into Sid?  Testing?

Eventually. Debian seems to do things by the upstream release. Right
now, XFCE for Bookworm/testing is 4.18, Bullseye/stable 4.16.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: Whole-disk RAID and GPT/UEFI

[Juri Grabowski]

Hello,

I have seen some installations with following setup:
GPT
sda1 sdb1 bios_grub md1 0.9 
sda2 sdb2 efi md2 0.9 
sda3 sdb3 /boot md3 0.9
sda4 sdb4 / md? 1.1

on such installations it's important, that  grub installation is made
with "grub-install --removable"
I mean it was some grub bugs about update grub on such installations,
but if you don't blindly update the machine and reboot it shouldn't be the
problem.

Best Regards,
Juri Grabowski

XFCE updates

[ghe2001]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I use XFCE4 for my GUI desktop, and I subscribe to XFCE's discussion list.  I 
see lots of posts on the list about XFCE things being updated, but I run 
stable, and I've been told to stick to only Debian updates.  What, if anything, 
happens to the updates advertised by XFCE?  Do they go into Sid?  Testing?

--
Glenn English
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsBzBAEBCAAnBQJj9pUWCRDmyitW0WqrdxYhBMRG7aHlwXhPX67r9+bKK1bR
aqt3AACzFAf/eyO7uieWNeVxMV6A95Y0WHk+39UkMvDE9erx+LDHsQytZc8b
teCjLPijy2VcmJuXshJbsCVy13j6Z4yGM5abyPRy04WSfIIk58D+/2BZL39+
u4oKjBFidteK3uzR3yXtFNZSMtqtP/SF8Vc0fg5m/8QBo3l3KPRA0eBYUDp5
w3tAQNsqRaTIYG30t/XyyKy/j8e/ZfVh5MsyHjmS+sbpme1LzPlEYZvZmvqw
tGz3E+L7bYfuUt5mAxeieg4gCf/jGiB24M2G/dWDaPhrSSkxqobMumnDvXp6
TrowXVT7GBP+gePMU3PfN0T0CJOWnynrjRfQ71Z7ZzEdxRvmqymGJQ==
=Iu73
-END PGP SIGNATURE-

Re: Evolution doesn't receive messages in Debian 11.

[Van Snyder]

On Wed, 2023-02-22 at 16:13 -0500, Dan Ritter wrote:
> Van Snyder wrote: 
> 

> You are mixing way too many things here. Better tell us the
> contents of all your /etc/apt/sources.list and
> /etc/apt/sources.list.d/* files.
> 
> -dsr-

Dan:

Thanks for the reminder to look in /etc/apt/sources.d

I hadn't put any files there, but apparently the half-vast upgrade
added some ubuntu sources.


opm-ubuntu-ppa-kinetic.list
opm-ubuntu-ppa-kinetic.list.save

and some installation, long ago, added

skype-stable.list
skype-stable.list.save

I have a line for

deb [arch=amd64,i386] https://apt.repos.intel.com/oneapi all main

but there is also a file /etc/apt/sources.list/Intel/oneAPI.list that
has the same line.

Moving everything from /etc/apt/sources.list.d to
/etc/apt/save.sources.list.d makes the update and dist-upgrade appear
to work without complaint. Hopefully, that will cure the problems.

Except I just noticed I have no sound. My NVidia graphics card has
sound, and there's Intel sound on the main board. The audio icon in my
KDE task bar says there are no devices. How do I know which driver is
actually running, if any?

Thanks,
Van

Re: Evolution doesn't receive messages in Debian 11.

[Dan Ritter]

Van Snyder wrote: 
> On Tue, 2023-02-21 at 15:42 -0600, David Wright wrote:
> > On Wed 22 Feb 2023 at 06:34:27 (+1000), David wrote:
> > > On Tue, 2023-02-21 at 12:09 -0800, Van Snyder wrote:
> > > > 
> > > > When I installed Debian 11, I didn't destroy Debian 10. I still
> > > > have
> > > > Debian 10 on a different drive. In attempting to repair an
> > > > entirely
> > > > different problem, I had done
> > > > 
> > > >   apt-get update; apt-get upgrade
> > > 
> > > One of the reasons I prefer aptitude's `safe-upgrade'.
> > 
> > That's the equivalent command, and would not protect you. It will
> > upgrade everything that doesn't involve a new package, but nothing
> > else, hence the mish-mash of Debian 10 and 11.
> > 
> > If you want keep an old system around, you need to make sure that the
> > sources.list has the correct version's proper name in it, ie buster
> > in your case. And if you're later going to use it at all, you need
> > to keep it updated with those two commands.
> > 
> > > > Does anybody have any suggestions to repair it?
> > 
> > As others have suggested, the easiest is probably to:
> > 
> >   # apt-get update; apt-get dist-upgrade
> 
> apt-get update doesn't work:
> 
> ...
> Err:11 http://ppa.launchpad.net/opm/ppa/ubuntu kinetic Release 
> 404 Not Found [IP: 185.125.190.52 80]
> ...
> Reading package lists... Done 
> W: https://apt.repos.intel.com/oneapi/dists/all/InRelease: Key is
> stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the
> DEPRECATION section in apt-key(8) for details.
> E: The repository 'http://ppa.launchpad.net/opm/ppa/ubuntu kinetic
> Release' does not have a Release file.
> N: Updating from such a repository can't be done securely, and is
> therefore disabled by default.
> N: See apt-secure(8) manpage for repository creation and user
> configuration details.

You are mixing way too many things here. Better tell us the
contents of all your /etc/apt/sources.list and
/etc/apt/sources.list.d/* files.

-dsr-

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[David Wright]

On Wed 22 Feb 2023 at 18:12:29 (+0100), daven...@tuxfamily.org wrote:

> What I want is: setting up /etc/resolv.conf ONLY
> -  at system startup/initial network connexion.
> - when openconnect is executed and connects to work's VPN
> - when openconnect is ^C-ed and disconnects from the works VPN
> (cleaning it's mess in the routing table, interfaces, /etc/resolv's
> and other netwwork stuff it might have modified, makes sense)

What's the output from   ls -l /etc/resolv.conf

What's responsible for restoring the previous contents of
/etc/resolv.conf to your normal network connection when you
finish "work" and tear down the VPN.

> - I don't use systemd-resolvd. My OS image (Debian stable, LXDE,
> connmann as the default network manager) ships with systemd-resolvd
> disabled and I'm totally OK with it
> - I do use connmann and didn't replace it with anything else
> - The process that deletes and recreates /etc/resolv.conf runs as
> root. I used auditd to detect when changes that file… but I can't a
> get any process name. I can just see it's root

One way of finding the process is to  # chattr +i /etc/resolv.conf
while you're "at work", so that you get permission errors in the
logs when it happens. (Remember to chattr -i before you "stop work".)

But how do you manage /etc/resolv.conf with connman. I don't use it,
but I read there's a plug-in for that. Is openconnect correctly
informing connman when it finishes.

> I was expecting to see a process name it the audit.log file BUT it
> didn't happened so I'm still stuck. so my question is: How to debug
> that further, and identify the exact process that screw up with
> /etc/resolv.conf file… So from there I could search for a way to
> prevent that by modifying the rights config file or whatever…

Whatever the "rogue process" is should be informing whatever the
"/etc/resolv.conf controller" is, shouldn't it, rather than being
blocked. (It might be legitimate rather than "rogue".)

Cheers,
David.

Re: Debian installer chooses the wrong NVidia driver

[Jeremy Hendricks]

I think I know why.
https://en.m.wikipedia.org/wiki/GeForce_600_series

They made Kepler and Fermi variants of the GT 630. The nvidia driver
probably wrongly assumes it’s Kepler.

On Wed, Feb 22, 2023 at 4:01 PM Van Snyder  wrote:

> On Wed, 2023-02-22 at 15:43 -0500, Jeremy Hendricks wrote:
>
> Van, what is the specific GPU you have? I know it’s GF108 but what is the
> actual model?
>
>
> # nvidia-detect
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108
> [GeForce GT 630] [10de:0f00] (rev a1)
>
>
> On Wed, Feb 22, 2023 at 3:33 PM Van Snyder 
> wrote:
>
> On Tue, 2023-02-21 at 23:27 +0200, Georgi Naplatanov wrote:
>
> On 2/21/23 23:16, Van Snyder wrote:
>
> On Tue, 2023-02-21 at 22:41 +0200, Georgi Naplatanov wrote:
>
> On 2/21/23 22:13, Van Snyder wrote:
>
> I have an NVidia GF108 video card. It works just fine, so I don't see a
> reason to replace it.
>
> It needs the nvidia-legacy-390xx-driver.
>
> But when I installed Debian 11, it chose the 470 driver, which doesn't
> work with GF108.
>
> Maybe that was caused by selecting "install all the drivers" instead of
> "install only the relevant drivers." I thought that meant "download them
> all in case you install some new hardware."
>
> Shouldn't the installer install only the drivers for the relevant
> hardware, even if it downloads all of them?
>
> I'm not going to re-install just to do an experiment to see if the
> installer does it right if I tell it to install only the relevant
> drivers.
>
>
>
> Hi!
>
> It seems that nvidia-legacy-390xx-driver is available in Debian 11
> (bullseye). You have just to install it. If you have problems again,
> then try to use open source driver for NVidia's cards - Nouveau. it's
> installed by default and you have just to uninstall NVidia's proprietary
> drivers - nvidia-*.
>
>
> I did install it, but it took me a week to find that that was the
> problem. I had expected Debian's installer to choose to use the correct
> driver even if all the drivers it has in its entire achive are downloaded.
>
>
>
> There is a package nvidia-detect
>
> it tells you which driver is appropriate for your NVidia's video card.
>
>
> Yeah, I used that. Why didn't the installer use it, and choose the 390
> driver instead of installing the 470 driver?
>
>
> Kind regards
> Georgi
>
>
>
>

Re: Debian installer chooses the wrong NVidia driver

[Van Snyder]

On Wed, 2023-02-22 at 15:43 -0500, Jeremy Hendricks wrote:
> Van, what is the specific GPU you have? I know it’s GF108 but what is
> the actual model?

# nvidia-detect
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108
[GeForce GT 630] [10de:0f00] (rev a1)
> 
> On Wed, Feb 22, 2023 at 3:33 PM Van Snyder 
> wrote:
> > On Tue, 2023-02-21 at 23:27 +0200, Georgi Naplatanov wrote:
> > > On 2/21/23 23:16, Van Snyder wrote:
> > > > On Tue, 2023-02-21 at 22:41 +0200, Georgi Naplatanov wrote:
> > > > > On 2/21/23 22:13, Van Snyder wrote:
> > > > > > I have an NVidia GF108 video card. It works just fine, so I
> > > > > > don't see a
> > > > > > reason to replace it.
> > > > > > 
> > > > > > It needs the nvidia-legacy-390xx-driver.
> > > > > > 
> > > > > > But when I installed Debian 11, it chose the 470 driver,
> > > > > > which doesn't
> > > > > > work with GF108.
> > > > > > 
> > > > > > Maybe that was caused by selecting "install all the
> > > > > > drivers" instead of
> > > > > > "install only the relevant drivers." I thought that meant
> > > > > > "download them
> > > > > > all in case you install some new hardware."
> > > > > > 
> > > > > > Shouldn't the installer install only the drivers for the
> > > > > > relevant
> > > > > > hardware, even if it downloads all of them?
> > > > > > 
> > > > > > I'm not going to re-install just to do an experiment to see
> > > > > > if the
> > > > > > installer does it right if I tell it to install only the
> > > > > > relevant 
> > > > > > drivers.
> > > > > > 
> > > > > 
> > > > > 
> > > > > Hi!
> > > > > 
> > > > > It seems that nvidia-legacy-390xx-driver is available in
> > > > > Debian 11
> > > > > (bullseye). You have just to install it. If you have problems
> > > > > again,
> > > > > then try to use open source driver for NVidia's cards -
> > > > > Nouveau. it's
> > > > > installed by default and you have just to uninstall NVidia's
> > > > > proprietary
> > > > > drivers - nvidia-*.
> > > > 
> > > > I did install it, but it took me a week to find that that was
> > > > the 
> > > > problem. I had expected Debian's installer to choose to use the
> > > > correct 
> > > > driver even if all the drivers it has in its entire achive are
> > > > downloaded.
> > > 
> > > 
> > > There is a package nvidia-detect
> > > 
> > > it tells you which driver is appropriate for your NVidia's video
> > > card.
> > 
> > 
> > Yeah, I used that. Why didn't the installer use it, and choose the
> > 390 driver instead of installing the 470 driver?
> > 
> > > 
> > > Kind regards
> > > Georgi
> > > 
> > 
> > 

Re: Evolution doesn't receive messages in Debian 11.

[Van Snyder]

On Wed, 2023-02-22 at 06:07 +0100, to...@tuxteam.de wrote:
> On Tue, Feb 21, 2023 at 12:09:30PM -0800, Van Snyder wrote:
> > I just upgraded to Debian 11. I had been using Debian 10. I've used
> > Evolution for many years. The version in Debian 11 is 3.48.
> > 
> > I use KDE Plasma version 5.26.90. The KDE Frameworks version is
> > 5.102.0.
> > 
> > I get pop-up notes from KDE that evolution has received new
> > messages.
> 
> Possibly a secondary thing: no messages -> no popup.
> 
> > But the messages don't appear in Evolution [...]
> 
> Since the thread is trying to derail into whether "safe upgrade"
> is somehow safer or not (spoiler: sometimes, but here most probably
> irrelevant; alas, that's how we nerds are ;)...
> 
> I have no clue with Evolution, but it might help those helping you
> to tell us how Evolution is "getting" its mails.
> 
> My hunch would be that it is set up to fetch its mails from the
> server (how? IMAP? POP3?).

Evolution is using imap to receive mail. I can read the messages on the
server in Firefox. I can read the messages in Evolution if I run
evolution in the messed-up bastardized Debian 10/11, but when I run a
pure newly-installed Debian 11, thats when Evolution doesn't display
the messages that KDE has announced have arrived.

My Evolution is set up to read several accounts. The same problem
affects all of them.

I haven't tried Thunderbird.

> It would be useful to try to debug this process. Again, I've never
> touched Evolution in my life, but here [1] is a nice debugging guide
> which might help getting things started.
> 
> Now let's hope to get back on topic and perhaps some Evolution guru
> chimes in.
> 
> Cheers
> 
> [1] https://wiki.gnome.org/Apps/Evolution/Debugging

Re: Evolution doesn't receive messages in Debian 11.

[Van Snyder]

On Tue, 2023-02-21 at 15:42 -0600, David Wright wrote:
> On Wed 22 Feb 2023 at 06:34:27 (+1000), David wrote:
> > On Tue, 2023-02-21 at 12:09 -0800, Van Snyder wrote:
> > > 
> > > When I installed Debian 11, I didn't destroy Debian 10. I still
> > > have
> > > Debian 10 on a different drive. In attempting to repair an
> > > entirely
> > > different problem, I had done
> > > 
> > >   apt-get update; apt-get upgrade
> > 
> > One of the reasons I prefer aptitude's `safe-upgrade'.
> 
> That's the equivalent command, and would not protect you. It will
> upgrade everything that doesn't involve a new package, but nothing
> else, hence the mish-mash of Debian 10 and 11.
> 
> If you want keep an old system around, you need to make sure that the
> sources.list has the correct version's proper name in it, ie buster
> in your case. And if you're later going to use it at all, you need
> to keep it updated with those two commands.
> 
> > > Does anybody have any suggestions to repair it?
> 
> As others have suggested, the easiest is probably to:
> 
>   # apt-get update; apt-get dist-upgrade

apt-get update doesn't work:

...
Err:11 http://ppa.launchpad.net/opm/ppa/ubuntu kinetic Release 
404 Not Found [IP: 185.125.190.52 80]
...
Reading package lists... Done 
W: https://apt.repos.intel.com/oneapi/dists/all/InRelease: Key is
stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the
DEPRECATION section in apt-key(8) for details.
E: The repository 'http://ppa.launchpad.net/opm/ppa/ubuntu kinetic
Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user
configuration details.



> which will take it up to stable ≡ bullseye.
> 
> Then edit the sources.list and change stable → bullseye.
> And do the same edit to the system that was already Debian 11.
> 
> In a few ?weeks, you can decide which of the two drives you want to
> upgrade to Debian 12 ≡ bookworm, and leave the other as Debian 11,
> upgradeable /safely/ as Debian 11.
> 
> Cheers,
> David.
> 

Re: Debian installer chooses the wrong NVidia driver

[Jeremy Hendricks]

Van, what is the specific GPU you have? I know it’s GF108 but what is the
actual model?

On Wed, Feb 22, 2023 at 3:33 PM Van Snyder  wrote:

> On Tue, 2023-02-21 at 23:27 +0200, Georgi Naplatanov wrote:
>
> On 2/21/23 23:16, Van Snyder wrote:
>
> On Tue, 2023-02-21 at 22:41 +0200, Georgi Naplatanov wrote:
>
> On 2/21/23 22:13, Van Snyder wrote:
>
> I have an NVidia GF108 video card. It works just fine, so I don't see a
> reason to replace it.
>
> It needs the nvidia-legacy-390xx-driver.
>
> But when I installed Debian 11, it chose the 470 driver, which doesn't
> work with GF108.
>
> Maybe that was caused by selecting "install all the drivers" instead of
> "install only the relevant drivers." I thought that meant "download them
> all in case you install some new hardware."
>
> Shouldn't the installer install only the drivers for the relevant
> hardware, even if it downloads all of them?
>
> I'm not going to re-install just to do an experiment to see if the
> installer does it right if I tell it to install only the relevant
> drivers.
>
>
>
> Hi!
>
> It seems that nvidia-legacy-390xx-driver is available in Debian 11
> (bullseye). You have just to install it. If you have problems again,
> then try to use open source driver for NVidia's cards - Nouveau. it's
> installed by default and you have just to uninstall NVidia's proprietary
> drivers - nvidia-*.
>
>
> I did install it, but it took me a week to find that that was the
> problem. I had expected Debian's installer to choose to use the correct
> driver even if all the drivers it has in its entire achive are downloaded.
>
>
>
> There is a package nvidia-detect
>
> it tells you which driver is appropriate for your NVidia's video card.
>
>
> Yeah, I used that. Why didn't the installer use it, and choose the 390
> driver instead of installing the 470 driver?
>
>
> Kind regards
> Georgi
>
>
>

Re: Debian installer chooses the wrong NVidia driver

[Van Snyder]

On Tue, 2023-02-21 at 23:27 +0200, Georgi Naplatanov wrote:
> On 2/21/23 23:16, Van Snyder wrote:
> > On Tue, 2023-02-21 at 22:41 +0200, Georgi Naplatanov wrote:
> > > On 2/21/23 22:13, Van Snyder wrote:
> > > > I have an NVidia GF108 video card. It works just fine, so I
> > > > don't see a
> > > > reason to replace it.
> > > > 
> > > > It needs the nvidia-legacy-390xx-driver.
> > > > 
> > > > But when I installed Debian 11, it chose the 470 driver, which
> > > > doesn't
> > > > work with GF108.
> > > > 
> > > > Maybe that was caused by selecting "install all the drivers"
> > > > instead of
> > > > "install only the relevant drivers." I thought that meant
> > > > "download them
> > > > all in case you install some new hardware."
> > > > 
> > > > Shouldn't the installer install only the drivers for the
> > > > relevant
> > > > hardware, even if it downloads all of them?
> > > > 
> > > > I'm not going to re-install just to do an experiment to see if
> > > > the
> > > > installer does it right if I tell it to install only the
> > > > relevant 
> > > > drivers.
> > > > 
> > > 
> > > 
> > > Hi!
> > > 
> > > It seems that nvidia-legacy-390xx-driver is available in Debian
> > > 11
> > > (bullseye). You have just to install it. If you have problems
> > > again,
> > > then try to use open source driver for NVidia's cards - Nouveau.
> > > it's
> > > installed by default and you have just to uninstall NVidia's
> > > proprietary
> > > drivers - nvidia-*.
> > 
> > I did install it, but it took me a week to find that that was the 
> > problem. I had expected Debian's installer to choose to use the
> > correct 
> > driver even if all the drivers it has in its entire achive are
> > downloaded.
> 
> 
> There is a package nvidia-detect
> 
> it tells you which driver is appropriate for your NVidia's video
> card.

Yeah, I used that. Why didn't the installer use it, and choose the 390
driver instead of installing the 470 driver?

> 
> Kind regards
> Georgi
> 

Re: Remove route '169.254.0.0/16 dev ovs-system'

[Darac Marjal]

On 22/02/2023 19:40, Greg Wooledge wrote:

On Wed, Feb 22, 2023 at 02:04:58PM -0500, Jeffrey Walton wrote:


Maybe the 'w' is not matching anything.

I thought eth0 and wlan0 went the way of the dinosaurs. I thought with
Consistent Network Device Names and biosdevname, the name will begin
with a 'p' or 'em', not a 'w', and based on the slot number.

"Predictable" interface names always begin with "e" for ethernet, or "w"
for wireless.  "Match w*" should match every wireless interface on the
system.


It would also match "wan0" if you had a network interface for your Wide 
Area Network. You might find this to be a bit more direct (that is, it 
mostly has the same effect, but matches directly what you want, rather 
than indirectly what you meant)


  [Match]
  Type=wlan




OpenPGP_signature
Description: OpenPGP digital signature

Re: Remove route '169.254.0.0/16 dev ovs-system'

[Greg Wooledge]

On Wed, Feb 22, 2023 at 02:04:58PM -0500, Jeffrey Walton wrote:

> Maybe the 'w' is not matching anything.
> 
> I thought eth0 and wlan0 went the way of the dinosaurs. I thought with
> Consistent Network Device Names and biosdevname, the name will begin
> with a 'p' or 'em', not a 'w', and based on the slot number.

"Predictable" interface names always begin with "e" for ethernet, or "w"
for wireless.  "Match w*" should match every wireless interface on the
system.

Re: Remove route '169.254.0.0/16 dev ovs-system'

[Jeffrey Walton]

On Wed, Feb 22, 2023 at 1:43 PM David Wright  wrote:
>
> On Tue 21 Feb 2023 at 13:48:58 (-0500), Jeffrey Walton wrote:
> > On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus
> >  wrote:
> > > [...]
> > > > But backing up... I suspect there's something wrong with your static
> > > > ip address assignment. The address is already taken, the netmask is
> > > > wrong, or the gateway is wrong.
> > > >
> > > > Looking back through this thread, I did not see where you showed your
> > > > static ip configuration. Maybe you should start with that. If it is
> > > > bad, then the APIPA is just a symptom of the [static ip address]
> > > > problem.
> > >
> > > This is the systemd-networkd configuration:
> > >
> > > [Match]
> > > Name=w*
> > >
> > > [Network]
> > > DHCP=no
> > > Address=192.168.0.62/24
> > > Gateway=192.168.0.32
> > > DNS=127.0.0.1
> > >
> > > I have unbound as a DNS listening at localhost. But with
> > > DNS=192.168.0.32 the behaviour has been similar.
> > >
> > > I have not yet checked the address assignment using systemd-networkd.
> > > For doing so I have to reinstall some packages.
> >
> > I don't know what the Match section does. I am suspicious of it.
>
> Oh, Match is great. For a typical, simple PC or laptop, you no longer
> have to worry about whether your wifi is called wlan0 (kernel, and
> iwd), wlo0, wlp365s7 (onboard/slot/path), or wlxf1dd1efadd1e (USB),
> it'll get matched nonetheless. Ditto for e* and ethernet.

Thanks David.

Maybe the 'w' is not matching anything.

I thought eth0 and wlan0 went the way of the dinosaurs. I thought with
Consistent Network Device Names and biosdevname, the name will begin
with a 'p' or 'em', not a 'w', and based on the slot number. Also see
https://linux.dell.com/files/whitepapers/consistent_network_device_naming_in_linux.pdf.

Jeff

Re: Remove route '169.254.0.0/16 dev ovs-system'

[David Wright]

On Wed 22 Feb 2023 at 17:45:40 (+0100), Christoph Brinkhaus wrote:
> Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> > On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > > I have no idea if it is possible to estimate a DHCP response
> > > > > time.
> > 
> > Since static IP address is assigned, it does not matter. I expected DHCP
> > configuration and that delay may be noticed in `journalctl -b 0` logs.
> > 
> > > [Unit]
> > > Description=A remote mail retrieval and forwarding utility
> > > After=network-online.target opensmtpd.service unbound.service
> > > Requires=opensmtpd.service unbound.service
> > > 
> > > But fetchmail starts before the dependencies have been finished.
> > 
> > I can not say that I fully understand interaction of After and
> > Requires/Wants options. I would try additional Wants=network-online.target
> 
> As far as I remeber correctly I have tried the Wants option without
> success.
> 
> In case of my fetchmail setup the culprit is unbound. At the startup
> of unbound it takes some time to exchange keys and so on. During that
> period names cannot be resolved. Now I call fetchmail after the
> mailserver name can be resolved to an IP. This is done in a tiny
> wrapper script. It keeps the log files clean. That workaround is fine
> for me.
>  
> > > [Match]
> > > Name=w*
> > > 
> > > [Network]
> > > DHCP=no
> > > Address=192.168.0.62/24
> > > Gateway=192.168.0.32
> > > DNS=127.0.0.1
> > 
> > There are options like RequiredForOnline, see systemd.network(5), but likely
> > default value is yes.

Might you try systemd-networkd-wait-online.service, whose name
implies that it waits for up to two minutes (configurable default).

> > However avahi-autoipd should be started concurrently
> > with network configuration to assign link-local address in the case of
> > failure.

> In a different thread - it was about IPv6 which has mutated
> slightly - several users claimed that the avahi-autoip is useful for
> their business. I am only a hobbyist, I trust the guys who do IT in
> their regular job. May be it is ok as it is implemented in Debian.

I agree with that. I think the people that report problems on the list
are, with possible exceptions, trying to get their networks into
better shape.

Perhaps one problem is that getting a 169.254.x.y address might be
useful if you're expecting to join an ad hoc network, but if you're
not (like, I suspect, many of us here), it only complicates matters.
For the latter, better surely to get no address, notice the fact,
and fix the networking, rather than to have to do all that /and/
get rid of the 169.254.x.y address.

Cheers,
David.

Re: Remove route '169.254.0.0/16 dev ovs-system'

[David Wright]

On Tue 21 Feb 2023 at 13:48:58 (-0500), Jeffrey Walton wrote:
> On Tue, Feb 21, 2023 at 1:26 PM Christoph Brinkhaus
>  wrote:
> > [...]
> > > But backing up... I suspect there's something wrong with your static
> > > ip address assignment. The address is already taken, the netmask is
> > > wrong, or the gateway is wrong.
> > >
> > > Looking back through this thread, I did not see where you showed your
> > > static ip configuration. Maybe you should start with that. If it is
> > > bad, then the APIPA is just a symptom of the [static ip address]
> > > problem.
> >
> > This is the systemd-networkd configuration:
> >
> > [Match]
> > Name=w*
> >
> > [Network]
> > DHCP=no
> > Address=192.168.0.62/24
> > Gateway=192.168.0.32
> > DNS=127.0.0.1
> >
> > I have unbound as a DNS listening at localhost. But with
> > DNS=192.168.0.32 the behaviour has been similar.
> >
> > I have not yet checked the address assignment using systemd-networkd.
> > For doing so I have to reinstall some packages.
> 
> I don't know what the Match section does. I am suspicious of it.

Oh, Match is great. For a typical, simple PC or laptop, you no longer
have to worry about whether your wifi is called wlan0 (kernel, and
iwd), wlo0, wlp365s7 (onboard/slot/path), or wlxf1dd1efadd1e (USB),
it'll get matched nonetheless. Ditto for e* and ethernet.

> 192.168.0.0 address block is /16, not /24.
> 
> I'm in the US, and I use Verizon for my ISP. Verizon gadgets, like set
> top boxes and media centers, use 192.168.0.x addresses. I never put
> anything on 192.168.0.x. I start with 192.168.1.x. And on the Verizon
> network, I've never seen a 192.168.0.x gateway. Gateways also go on
> 192.168.1.x. So I'm a bit suspicious of the network assignments.

I don't understand this. If you're actually running two subnets with
255.255.255.0 netmasks, and they intercommunicate with each other
(your computers on subnet 1, and Verizon ISP on subnet 0), then you
must have a gateway on each subnet for them to communicate through.

But backing up… the systemd-networkd configuration above is that of
Christoph, who wrote that their system had been (a) switched to
systemd-networkd from systemd-networking, and (b) purged of avahi
packages to eliminate 169.254.x.y addresses. So I'm not sure what
there is to fix here.

But (a) raises the question of what systemd was running /before/,
which was presumably what was giving rise to 169.254.x.y addresses.

And, while I can add an innocuous 169.254.0.0 route to a system
merely by installing ifupdown and avahi-autoipd, that route looks
like the second line here:

  default via 192.168.1.1 dev enp2s2 onlink
  169.254.0.0/16 dev enp2s2 scope link metric 1000
  192.168.1.0/24 dev enp2s2 proto kernel scope link src 192.168.1.10

and not like the OP's (ie Geert's):

  169.254.0.0/16 dev ovs-system scope link src 169.254.201.7 metric 1004

(which has been grepped out of its context).

Cheers,
David.

Re: ps and AIX field descriptors

[David Wright]

On Tue 21 Feb 2023 at 16:06:48 (+0100), Andreas Leha wrote:
> David Wright  writes:
> > On Mon 20 Feb 2023 at 10:39:21 (+0100), Andreas Leha wrote:
> >> Greg Wooledge  writes:
> >> > On Sun, Feb 19, 2023 at 12:04:22PM -0600, David Wright wrote:
> >> >> But even that's not enough
> >> >> because the field width is somewhat variable: try   ps -eo '%c  |  %z  
> >> >> |  %a'
> >> >> (We can still use | to make the problem somewhat more obvious.)
> >> >
> >> > Oh wow.  Yeah, OK, that's not really solvable.
> >> >
> >> > For those who don't want to try to reverse engineer David's conclusion,
> >> > or who don't just happen to stumble upon it with their current process
> >> > list, here's what I'm seeing:
> >> >
> >> > COMMAND  | VSZ  |  COMMAND
> >> > systemd  |  164140  |  /sbin/init
> >> > kthreadd |   0  |  [kthreadd]
> >> > rcu_gp   |   0  |  [rcu_gp]
> >> > rcu_par_gp   |   0  |  [rcu_par_gp]
> >> > [...]
> >> > steamwebhelper   |  4631064  |  
> >> > /home/greg/.steam/debian-installation/[...]
> >> > [...]
> >> > chrome_crashpad  |  33567792  |  
> >> > /opt/google/chrome/chrome_crashpad_handler[...]
> >> > [...]
> >> > kworker/3:0-eve  |   0  |  [kworker/3:0-events]
> >> >
> >> > ps appears to guess an initial maximum width for the VSZ field, but
> >> > when a value comes along that exceeds the guessed maximum, it simply
> >> > shoves the field barrier over.  It doesn't even become the new maximum,
> >> > with all of the fields aligning after that.  It's just a one-time shove,
> >> > breaking the current line only.
> >> >
> >> > Therefore, parsing the header line cannot give us enough information to
> >> > insert field separators correctly in body lines after the fact.
> >> 
> >> 
> >> Dear all,
> >> 
> >> Thanks for chiming in.  The example was indeed simplified and I am using
> >> %a which can contain internal whitespace.
> >> 
> >> This is the command I was using previously:
> >> 
> >>   ps -eo '%p|%c|%C' -o "%mem" -o '|%a' --sort=-%cpu

 

> >> I now replaced it with
> >> 
> >>   ps -eo '%p %c %C' -o "%mem" -o ' %a' --sort=-%cpu  | sed -E 's/([0-9]+) 
> >> (.+) ([0-9]+.?[0-9]?) ([0-9]+.?[0-9]?) (.+)/\1|\2|\3|\4|\5/'
> >>  
> >> This works, but is of course cumbersome to maintain.
> >> 
> >> Again, thanks for all the comments!
> >
> > I think there are a few too many assumptions in there;
> > in particular, numbers in %a will match patterns designed
> > to match cpu and mem, because you can't prevent sed from
> > being greedy (except with the [^ … … ]+ construction, to
> > restrict what it matches).
> >
> > This version makes a few assumptions as well:
> > . that the new format matches the old one (mine) if the
> >   delimiters given are a single space (like '%p %c %C'),
> >   or stripped (like "%mem" and '%a', but not ' %a').
> > . the short command is always 15 chars wide even if all
> >   the commands in the table are shorter, eg with ps -o.
> > . I don't have any of those new-fangled extra-long PIDs
> >   yet today.
> >
> > It might well break if a CPU or MEM is running at 100%.
> > That's not easily tested here.
> >
> > I've reordered the columns on the first pass, so that the
> > numeric ones (with their limited character set) come first,
> > which means I can use an auxiliary character for
> > correcting the spacing. (The spaces between the columns get
> > comingled with the leading spaces of numbers.) The second
> > pass sorts that out and processes the heading.
> >
> > $ ps -eo '%p %c %C' -o "%mem" -o '%a' --sort=-%cpu | sed -E 's/( *[0-9]+) 
> > (.{15})( +[0-9.]+ +[0-9.]+) (.*$)/\1~\3~\2\4/;' | sed -E 's/([^~]+)~ 
> > ([^~]+)~(.{15})(.*)/\1|\3|\2|\4/;s/^( *PID) (COMMAND) 
> > /\1|\2|/;s/%MEM COMMAND/%MEM|COMMAND/;' | less
> > $ 
> >
> > This is the same, except I deliberately chose _ for the auxiliary
> > character, knowing that short commands are stuffed with underscores:
> >
> > $ ps -eo '%p %c %C' -o "%mem" -o '%a' --sort=-%cpu | sed -E 's/( *[0-9]+) 
> > (.{15})( +[0-9.]+ +[0-9.]+) (.*$)/\1_\3_\2\4/;' | sed -E 's/([^_]+)_ 
> > ([^_]+)_(.{15})(.*)/\1|\3|\2|\4/;s/^( *PID) (COMMAND) 
> > /\1|\2|/;s/%MEM COMMAND/%MEM|COMMAND/;' | less
> > $ 
> >
> > Examples:
> >
> > PID|COMMAND|%CPU %MEM|COMMAND
> >9798|firefox-esr| 2.5  5.8|firefox-esr
> >   16143|Isolated Web Co| 1.8  2.2|/usr/lib/firefox-esr/firefox-esr 
> > -contentproc -childID 11 -isForBrowser -prefsLen 47676 -prefMapSize 232307 
> > -jsInitLen 277276 -parentBuildID 20230214011352 -appDir 
> > /usr/lib/firefox-esr/browser 9798 true tab
> >1242|Xorg   | 1.0  1.4|/usr/lib/xorg/Xorg -nolisten tcp :0 vt1 
> > -keeptty -auth /tmp/serverauth.FxvBp8B7Qn
> > [ … ]
> >   8|mm_percpu_wq   | 0.0  0.0|[mm_percpu_wq]
> >   9|rcu_tasks_rude_| 0.0  0.0|[rcu_tasks_rude_]
> >  10|rcu_tasks_trace| 0.0  0.0|[rcu_tasks_trace]
> >
> > An incestuous one, with -o rather -eo:
> >
> > PID|COMMAND|%CPU 

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Greg Wooledge]

On Wed, Feb 22, 2023 at 06:12:29PM +0100, daven...@tuxfamily.org wrote:
> There is an unidentified process that decides it's ok to delete and recreate
> /etc/resolv.conf without asking user/admin,
> The problem is, the problematic process is not work's VPN related and
> creates the file with wrong resolver's IP. The IP corresponds to my home
> router IP, [...]

Then it's probably the Debian DHCP client, rewriting resolv.conf
according to what your router's DHCP server told it to use.

 has several different strategies
for working around this sort of issue.

Good luck.

Re: hplip : looking for a workaround

[Brad Rogers]

On Wed, 22 Feb 2023 17:49:13 +0100
Erwan David  wrote:

Hello Erwan,

>I opend a bug for a missing dependency, but do someone know of a 
>workaround ?

Further to Celejar's response, I can confirm that editing password.py as
suggested in the bug report he mentions, does indeed work.

-- 
 Regards  _   "Valid sig separator is {dash}{dash}{space}"
 / )  "The blindingly obvious is never immediately apparent"
/ _)rad   "Is it only me that has a working delete key?"
He signed up for just three years, it seemed a small amount
Tin Soldiers - Stiff Little Fingers


pgpoBtNmW3oQp.pgp
Description: OpenPGP digital signature

Re: hplip : looking for a workaround

[Celejar]

On Wed, 22 Feb 2023 17:49:13 +0100
Erwan David  wrote:

> Hi,
> 
> hplip seems to need a dependency, many commands end with
> 
>    File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
>      distro_name = get_distro_std_name(os_name)
>    ^^^
> NameError: name 'get_distro_std_name' is not defined. Did you mean: 
> 'get_distro_name'?
> 
> I opend a bug for a missing dependency, but do someone know of a 
> workaround ? I cannot use my scanner anymore because it needs a binary 
> plugin installed by hplip

This is your bug:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031784

but this earlier bug discussion contains a workaround (I haven't tried
it):

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029459

FTR, here's the upstream bug:

https://bugs.launchpad.net/hplip/+bug/2003739

-- 
Celejar

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Christoph Brinkhaus]

Am Wed, Feb 22, 2023 at 06:12:29PM +0100 schrieb daven...@tuxfamily.org:
> 
> = context =
> For the context, I use a Debian 11 laptop for work. When I work remotely
> from home, I have to use a cisco VPN. Good thing is there is openconnect,
> which does work, and in teh case of ym work's VPN, it does wor. cisco's
> spyware/downloaded binry, namely using the --csd-wrapper
> /usr/libexec/openconnect/"
[snip]
> = end of context =
> What I want is: setting up /etc/resolv.conf ONLY
> -  at system startup/initial network connexion.
> - when openconnect is executed and connects to work's VPN
> - when openconnect is ^C-ed and disconnects from the works VPN (cleaning
> it's mess in the routing table, interfaces, /etc/resolv's and other netwwork
> stuff it might have modified, makes sense)
> 
> Here's what I know:
> - Whatever process does that seems does what I highly suspect to be DHCP [1]
> requests every now and then. Home's router answers giving it's own address
> as both gateway and DNS resolver. And said process thinks it's OK to delete
> and recreate resolv.conf with the wrong content… breaking everything work's
> related while the VPN is still active

If it is DHCP: You might do a countermeasure in
/etc/dhcp/dhclient.conf. On my system I have an entry as below.

interface "wlp4s0" {
supersede domain-name-servers 127.0.0.1;
}

I run unbound as a resolver. The entry in dhcclient.conf prevents that
the entry in /etc/resolv.conf is overwritten.

[snip]

My setup is stoneage like compared to your context.
Anyhow, I hope this is at least useful as a pointer :-).

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[Roberto C . Sánchez]

On Wed, Feb 22, 2023 at 06:12:29PM +0100, daven...@tuxfamily.org wrote:
> 
> There is an unidentified process that decides it's ok to delete and recreate
> /etc/resolv.conf without asking user/admin,

I will admit up front that I did not read your message in great detail.
However, overall it seems like you are experiencing something similar to
what I experienced in the past.

Here was what I found and how I solved the problem:

https://lists.debian.org/debian-user/2017/10/msg00896.html

The entire thread is rather large, so I didn't just point you to the
beginning of it, but you might find other parts of the discussion
illuminating as well.

Regards,

-Roberto
-- 
Roberto C. Sánchez

Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable

[davenull]

Hello,

= context =
For the context, I use a Debian 11 laptop for work. When I work remotely 
from home, I have to use a cisco VPN. Good thing is there is 
openconnect, which does work, and in teh case of ym work's VPN, it does 
wor. cisco's spyware/downloaded binry, namely using the --csd-wrapper 
/usr/libexec/openconnect/"


When I start openconnect, it usses some vpnc sript to write a porper, 
working, /etc/resolv.conf, with the right (work's) DNS resolver IP in 
it. And it works.
That worked flawlessly for months. But some months ago, probably after 
an upgrade or something (because I definitely didn't change anything), 
something started to screw up with /etc/resolv.conf.


So issue is not openconnect-related, at was just for the context. And to 
make it clear that totally disabling DHCP and writing the whole network 
config manually is not reasonably doable in my context. Because it's a 
laptop, sometime used with VPN, sometimes without it (even from home, 
occasionally, like during training on which I need to access external 
VMs that are not withelisted workplace's firewalls) so network context 
varies sometimes.

= end of context =

There is an unidentified process that decides it's ok to delete and 
recreate /etc/resolv.conf without asking user/admin,
The problem is, the problematic process is not work's VPN related and 
creates the file with wrong resolver's IP. The IP corresponds to my home 
router IP, which does has a DNS resolver and it works as it should. BUT 
my home's router DNS obviously don't know jack about work internal 
servers, on which I work… and work's proxy as well, which when it cannot 
be resolved… breaks everything using HTTP.


What I want is: setting up /etc/resolv.conf ONLY
-  at system startup/initial network connexion.
- when openconnect is executed and connects to work's VPN
- when openconnect is ^C-ed and disconnects from the works VPN (cleaning 
it's mess in the routing table, interfaces, /etc/resolv's and other 
netwwork stuff it might have modified, makes sense)


Here's what I know:
- Whatever process does that seems does what I highly suspect to be DHCP 
[1] requests every now and then. Home's router answers giving it's own 
address as both gateway and DNS resolver. And said process thinks it's 
OK to delete and recreate resolv.conf with the wrong content… breaking 
everything work's related while the VPN is still active
- Such requests which varies a lot and inst consistent, can be twice or 
tree time in 10 minutes or 3-5 times during one afternoon…). sometimes 
it happens the minute after I restart the VPN client to recreate a 
working resolv.conf file, sometimes it leaves the file alone for 15, 
minutes or even 2-3 hours…
- I never configured anything that to do repetitive/time-random DHCP 
requests. Except of course the initial DHCP request the system is first 
started and connected in the morning when I satrt my work day, wich is 
configurerd by default when you install debian for desktop/laptop/with 
DEs and network managers and all the fancy stuff.
- I don't use systemd-resolvd. My OS image (Debian stable, LXDE, 
connmann as the default network manager) ships with systemd-resolvd 
disabled and I'm totally OK with it

- I do use connmann and didn't replace it with anything else
- The process that deletes and recreates /etc/resolv.conf runs as root. 
I used auditd to detect when changes that file… but I can't a get any 
process name. I can just see it's root
Here's what tail -f audit.log | grep --color resolv.conf shown what it 
happens


--
type=PATH msg=audit(1677072201.558:572): item=3 name="/etc/resolv.conf" 
inode=786763 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 
nametype=DELETE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 
cap_frootid=0OUID="root" OGID="root"
type=PATH msg=audit(1677072201.558:572): item=4 name="/etc/resolv.conf" 
inode=784351 dev=fd:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 
nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 
cap_frootid=0OUID="root" OGID="root"

--

I was expecting to see a process name it the audit.log file BUT it 
didn't happened so I'm still stuck. so my question is: How to debug that 
further, and identify the exact process that screw up with 
/etc/resolv.conf file… So from there I could search for a way to prevent 
that by modifying the rights config file or whatever…


1. But didn't sniff network packets to confirma or infirm that, because 
I might wait for long time for it to happen, making extremely huge pcap 
files… Unless I know exactly what to filter out from input to have 
compact dumps… If it's not DHCP, aned I filter anything but DHCP, I'll 
end up with nothing. If I don't filter anything and it doesn't happen 
before 2 or 3 hours, it will take a shitload too much space form my home 
partition and would be PITA to use wireshark's search functions and 
display filters, and search for specific stuff, that will probably need 
several attempts with different search pattern 

Re: Whole-disk RAID and GPT/UEFI

[DdB]

Am 22.02.2023 um 17:07 schrieb Nicolas George:
> Unfortunately, that puts the partition table
> and EFI partition outside the RAID: if you have to add/replace a disk,
> you need to partition and reinstall GRUB, that makes a few more
> manipulations on top of syncing the RAID.

Yes, i get it. AFAIK, you cannot really avoid that, because a disk
replacement comes with new disk UUID's anyway and slightly different
sizes mostly. Maybe the best thing to do is to document, and maybe
script that case with your knowledge from today. that way, you can go to
sleeo until the case happens, and then read the doc (in your script) and
execute it. That is what i do (because i keep forgetting things faster
and faster ;-))

And usually, the script gets better over time after several runs ...

Sorry, that i have no better suggestion.
Good luck
DdB

hplip : looking for a workaround

[Erwan David]

Hi,

hplip seems to need a dependency, many commands end with

  File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
    distro_name = get_distro_std_name(os_name)
  ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean: 
'get_distro_name'?


I opend a bug for a missing dependency, but do someone know of a 
workaround ? I cannot use my scanner anymore because it needs a binary 
plugin installed by hplip

Re: Remove route '169.254.0.0/16 dev ovs-system'

[Christoph Brinkhaus]

Am Wed, Feb 22, 2023 at 10:24:59PM +0700 schrieb Max Nikulin:
> On 22/02/2023 01:26, Christoph Brinkhaus wrote:
> > > > I have no idea if it is possible to estimate a DHCP response
> > > > time.
> 
> Since static IP address is assigned, it does not matter. I expected DHCP
> configuration and that delay may be noticed in `journalctl -b 0` logs.
> 
> > [Unit]
> > Description=A remote mail retrieval and forwarding utility
> > After=network-online.target opensmtpd.service unbound.service
> > Requires=opensmtpd.service unbound.service
> > 
> > But fetchmail starts before the dependencies have been finished.
> 
> I can not say that I fully understand interaction of After and
> Requires/Wants options. I would try additional Wants=network-online.target

As far as I remeber correctly I have tried the Wants option without
success.

In case of my fetchmail setup the culprit is unbound. At the startup
of unbound it takes some time to exchange keys and so on. During that
period names cannot be resolved. Now I call fetchmail after the
mailserver name can be resolved to an IP. This is done in a tiny
wrapper script. It keeps the log files clean. That workaround is fine
for me.
 
> > [Match]
> > Name=w*
> > 
> > [Network]
> > DHCP=no
> > Address=192.168.0.62/24
> > Gateway=192.168.0.32
> > DNS=127.0.0.1
> 
> There are options like RequiredForOnline, see systemd.network(5), but likely
> default value is yes. However avahi-autoipd should be started concurrently
> with network configuration to assign link-local address in the case of
> failure.

In a different thread - it was about IPv6 which has mutated
slightly - several users claimed that the avahi-autoip is useful for
their business. I am only a hobbyist, I trust the guys who do IT in
their regular job. May be it is ok as it is implemented in Debian.

Kind regards,
Christoph
-- 
Ist die Katze gesund
schmeckt sie dem Hund.

Re: [HS] Facturation électronique obligatoire. Comment s'y préparer ?

[NoSpam]

Bonjour

Le 22/02/2023 à 17:26, Olivier a écrit :

Bonjour,

Je viens d'apprendre que l'article "26 de la loi de finances
rectificative pour 2022 prévoit l’obligation de facturation
électronique dans les échanges entre entreprises assujetties à la TVA
et établies en France" (cf [1]).

C'est déjà une obligation si l'on travail avec des administrations

Avez-vous connaissance d'outils ou prestataires permettant à des
entreprises dont l'informatique repose sur Debian, de se préparer à
cette nouvelle obligation ? Quel retour d'expérience ?


Rien à voir avec Debian. Je fais mes factures avec dolibarr puis je les 
dépose sur Chorus Pro en pdf.


Des fournisseurs utilisent qweeby.fr: je reçois un courriel avec un 
lien, je clique dessus et j'obtiens la facture en pdf dans une page web. 
Suffit de l'enregistrer.


Que je sache ce n'est pas obligatoire d'utiliser une plateforme agréée, 
simplement les services seront moindre. En gros, on peut continuer à les 
faire parvenir par courriel ou à les déposer sur son netxtcloud




Comment se rétribuent les plateformes de dématérialisation ?

Aucune idée

kmail ha dejado de funcionar después de actualizar.

[jfernandez]

Hola

kmail ha dejado de funcionar después de actualizar.

Al intentar descargar los correos aparece una notificación:
No es posible guardar los correos descargados.
Failed to append item

Al intentar enviar correos muestra:
Hubo problemas al intentar encolar el mensaje para enviar: Failed to  
append item


No permite guardar el correo como borrador:
Ha fallado al guardar el mensaje: Failed to append item


No deja ver los correos descargados y se queda bloqueado con un mensaje:
"Por favor, espere mientras se transfiere el mensaje"


Tengo la versión de kmail 5.9.3
Las bibliotecas:
KDE Frameworks 5.54.0
Qt 5.11.3 (compilado con 5.11.3)
El sistema de ventanas xcb


Ayer actualice:
Upgrade:
libwireshark11:amd64 (2.6.20-0+deb10u4, 2.6.20-0+deb10u5),
xserver-common:amd64 (2:1.20.4-1+deb10u7, 2:1.20.4-1+deb10u8),
google-chrome-beta:amd64 (109.0.5414.61-1, 111.0.5563.33-1),
openssl:amd64 (1.1.1n-0+deb10u3, 1.1.1n-0+deb10u4),
xserver-xorg-core:amd64 (2:1.20.4-1+deb10u7, 2:1.20.4-1+deb10u8),
libwiretap8:amd64 (2.6.20-0+deb10u4, 2.6.20-0+deb10u5),
libaprutil1:amd64 (1.6.1-4, 1.6.1-4+deb10u1),
megasync:amd64 (4.8.1-1.1, 4.8.7-2.1),
mariadb-common:amd64 (1:10.3.36-0+deb10u2, 1:10.3.38-0+deb10u1),
libarchive13:amd64 (3.3.3-4+deb10u2, 3.3.3-4+deb10u3),
libwsutil9:amd64 (2.6.20-0+deb10u4, 2.6.20-0+deb10u5), sudo:amd64  
(1.8.27-1+deb10u4, 1.8.27-1+deb10u5), google-chrome-stable:amd64  
(108.0.5359.124-1, 110.0.5481.100-1),
libaprutil1-dbd-sqlite3:amd64 (1.6.1-4, 1.6.1-4+deb10u1),  
mariadb-server-core-10.3:amd64 (1:10.3.36-0+deb10u2,  
1:10.3.38-0+deb10u1), xserver-xorg-legacy:amd64 (2:1.20.4-1+deb10u7,  
2:1.20.4-1+deb10u8), isc-dhcp-common:amd64 (4.4.1-2+deb10u2,  
4.4.1-2+deb10u3),

libpq5:amd64 (11.18-0+deb10u1, 11.19-0+deb10u1),
openjdk-11-jre-headless:amd64 (11.0.16+8-1~deb10u1, 11.0.18+10-1~deb10u1),
wireshark:amd64 (2.6.20-0+deb10u4, 2.6.20-0+deb10u5),
wireshark-gtk:amd64 (2.6.20-0+deb10u4, 2.6.20-0+deb10u5),
python-cryptography:amd64 (2.6.1-3+deb10u2, 2.6.1-3+deb10u3),
firefox-esr-l10n-es-es:amd64 (102.6.0esr-1~deb10u1, 102.8.0esr-1~deb10u1),
libaprutil1-ldap:amd64 (1.6.1-4, 1.6.1-4+deb10u1), libtiff5:amd64  
(4.1.0+git191117-2~deb10u4, 4.1.0+git191117-2~deb10u6),
libtiff5:i386 (4.1.0+git191117-2~deb10u4, 4.1.0+git191117-2~deb10u6),  
wireshark-common:amd64 (2.6.20-0+deb10u4,

2.6.20-0+deb10u5),
libwscodecs2:amd64 (2.6.20-0+deb10u4, 2.6.20-0+deb10u5),
python3-cryptography:amd64 (2.6.1-3+deb10u2, 2.6.1-3+deb10u3),
openjdk-11-jdk:amd64 (11.0.16+8-1~deb10u1, 11.0.18+10-1~deb10u1),
openjdk-11-jre:amd64 (11.0.16+8-1~deb10u1, 11.0.18+10-1~deb10u1),
libwebkit2gtk-4.0-37:amd64 (2.38.3-1~deb10u1, 2.38.5-1~deb10u1),
libsdl2-2.0-0:amd64 (2.0.9+dfsg1-1, 2.0.9+dfsg1-1+deb10u1),
libsdl2-2.0-0:i386 (2.0.9+dfsg1-1, 2.0.9+dfsg1-1+deb10u1),
mariadb-client-core-10.3:amd64 (1:10.3.36-0+deb10u2, 1:10.3.38-0+deb10u1),
libmariadb3:amd64 (1:10.3.36-0+deb10u2, 1:10.3.38-0+deb10u1),
libwireshark-data:amd64 (2.6.20-0+deb10u4, 2.6.20-0+deb10u5),
libssl1.1:amd64 (1.1.1n-0+deb10u3, 1.1.1n-0+deb10u4),
libssl1.1:i386 (1.1.1n-0+deb10u3, 1.1.1n-0+deb10u4),
libexiv2-14:amd64 (0.25-4+deb10u3, 0.25-4+deb10u4),
isc-dhcp-client:amd64 (4.4.1-2+deb10u2, 4.4.1-2+deb10u3),
libjavascriptcoregtk-4.0-18:amd64 (2.38.3-1~deb10u1, 2.38.5-1~deb10u1),
virtualbox-6.1:amd64 (6.1.40-154048~Debian~buster,  
6.1.42-155177~Debian~buster),

openjdk-11-jdk-headless:amd64 (11.0.16+8-1~deb10u1, 11.0.18+10-1~deb10u1),
libzen0v5:amd64 (0.4.37-1, 0.4.37-1+deb10u1),
libde265-0:amd64 (1.0.3-1+deb10u1, 1.0.3-1+deb10u3),
firefox-esr:amd64 (102.6.0esr-1~deb10u1, 102.8.0esr-1~deb10u1)

End-Date: 2023-02-21  22:06:42

El sistema es:
suprop@castor:~$ uname -a
Linux castor 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2  
(2019-11-11) x86_64 GNU/Linux


suprop@castor:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;

¿Alguna sugerencia para solucionarlo?

Gracias por la respuesta

[HS] Facturation électronique obligatoire. Comment s'y préparer ?

[Olivier]

Bonjour,

Je viens d'apprendre que l'article "26 de la loi de finances
rectificative pour 2022 prévoit l’obligation de facturation
électronique dans les échanges entre entreprises assujetties à la TVA
et établies en France" (cf [1]).

Avez-vous connaissance d'outils ou prestataires permettant à des
entreprises dont l'informatique repose sur Debian, de se préparer à
cette nouvelle obligation ? Quel retour d'expérience ?

Comment se rétribuent les plateformes de dématérialisation ?

[1] 
https://www.impots.gouv.fr/facturation-electronique-entre-entreprises-et-transmission-de-donnees-de-facturation

Slts

Re: Whole-disk RAID and GPT/UEFI

[Dan Ritter]

Nicolas George wrote: 
> Hi.
> 
> Is there a solution to have a whole-disk RAID (software, mdadm) that is
> also partitioned in GPT and bootable in UEFI?

Not that I know of. An EFI partition needs to be FAT32 or VFAT.

What I think you could do:

Partition the disks with GPT: 2 partitions each, EFI and mdadm
raid. We'll call these sda1 and sda2, and sdb1 and sdb2.

Install Debian. Use sda1 for EFI (/boot/efi), sda2/sdb2 for mdadm to create
md0.

Create a degraded mdadm mirror on sdb1, with metadata 1.0. Call
this md1.

mkfs vfat on md1. Mount it as /mnt/tmp. Get the UUID and put it in
/etc/fstab as the new value for /boot/efi.

copy everything from /boot/efi to /mnt/tmp. sync, and umount
/mnt/tmp.

wipefs /dev/sda1, then use mdadm to add it to md1.

After the resynch is finished (watch /proc/mdstat), try a
reboot.

Note that UEFI should detect this as two different boot disks,
and will not automatically switch between them. But booting
after sda fails should be as simple as switching to sdb1.

I have not tested this. I could be wrong.

-dsr-

Re: Whole-disk RAID and GPT/UEFI

[Nicolas George]

DdB (12023-02-22):
> I cannot say yes or no. But, of the top of my head, i know, that gdisk
> does support a strange thing called hybrid between MBR and GPT, where a
> clean GPT formatted drive contains (instead of a protective MBR)

I have toyed with hybrid GPT in the past, in the hope to make an USB
stick that was bootable in legacy mode, bootable in UEFI mode and usable
as a regular USB stick (spoiler: it worked, until I tried it with
Windows.)

But it will not help for this issue.

> The only issue, i have had a look at, was the problem to have a raid,
> that is bootable no matter which one of the drives initially fails, a
> problem, that can be solved by having at least 2 grub installs (on the
> two mirrors).
> 
> Certainly, there is a solution to your problem, even if might not
> exactly fulfill your premises.

I know of this solution. Unfortunately, that puts the partition table
and EFI partition outside the RAID: if you have to add/replace a disk,
you need to partition and reinstall GRUB, that makes a few more
manipulations on top of syncing the RAID.

Regards,

-- 
  Nicolas George

Re: Whole-disk RAID and GPT/UEFI

[DdB]

Am 22.02.2023 um 16:30 schrieb Nicolas George:
> Is there something I have missed?

I cannot say yes or no. But, of the top of my head, i know, that gdisk
does support a strange thing called hybrid between MBR and GPT, where a
clean GPT formatted drive contains (instead of a protective MBR) an MBR
with pointers to up to four partitons, in order to make a system
bootable without UEFI. I understand, that your use case is somewhat
different. But maybe you can use the idea anyway. The hybrid formatting
has some restrictions, like you should not have standard MBR tools mess
this configuration up (not use them at all) and unfortunately that
applies to standard GPT tools as well, but the dual bootability can
solve some problems.

The only issue, i have had a look at, was the problem to have a raid,
that is bootable no matter which one of the drives initially fails, a
problem, that can be solved by having at least 2 grub installs (on the
two mirrors).

Certainly, there is a solution to your problem, even if might not
exactly fulfill your premises.

Re: Where to look into when system crashes

[Max Nikulin]

On 22/02/2023 11:34, Qiming Ye wrote:


I have a Debian box running for 280+ days without rebooting, recently it 
crashes pretty much everyday.  Where should I look for the reason of 
crashing?


sudo journalctl

You may limit logs to specific boot by adding option like "--boot=-1". 
Scroll to end [G] or add "--end" flag to see last messages before crash, 
however it is better to pay some attention to all errors.

Whole-disk RAID and GPT/UEFI

[Nicolas George]

Hi.

Is there a solution to have a whole-disk RAID (software, mdadm) that is
also partitioned in GPT and bootable in UEFI?

What I imagine:

- RAID1, mirroring: if you ignore the RAID, the data is there.

- The GPT metadata is somewhere not too close to the beginning of the
  drive nor too close to the end, to not conflict with the GPT, but the
  space before / after the metadata is part of the RAID and synced.

- The firmware, not aware of RAID, sees a perfectly normal GPT partition
  scheme, just with some unallocated space before the first partition or
  after the last where the RAID metadata happen to reside.

- The kernel or a userspace tool like kpartx translates the offsets of
  the GPT partitions into offsets inside the RAID, skipping the
  metadata, and creates partitions inside the RAID device.

The benefit would be that the RAID would cover also the EFI partition
and the partition table itself. Since these are things that only change
at known times and are very small, the benefit is limited, but that
still would be nice.

At this time, as far as I can see: RAID metadata versions 1.0, 1.1 and
1.2 conflict with GPT because:

- 1.2 puts the superblock at sector 8;
- 1.1 puts the superblock at sector 0;
- 1.0 puts the superblock at sector end-16;
- GPT uses the sectors [0;34[ and [end-33;end[.

Metadata 0.9 uses the sectors [end-128;end-120[, not conflicting with
GPT and causing no offset for the partitions, but the data after that is
not part of the RAID, so the secondary GPT would not be synchronized.

Also, metadata 0.9 has limitations.

(I have not tested metadata ddf or imsm because they do not support
RAID1 on only one device, which is what I intend to do and what I was
testing on.)

Is there something I have missed?

Regards,

-- 
  Nicolas George

Re: Remove route '169.254.0.0/16 dev ovs-system'

[Max Nikulin]

On 22/02/2023 01:26, Christoph Brinkhaus wrote:

I have no idea if it is possible to estimate a DHCP response
time.


Since static IP address is assigned, it does not matter. I expected DHCP 
configuration and that delay may be noticed in `journalctl -b 0` logs.



[Unit]
Description=A remote mail retrieval and forwarding utility
After=network-online.target opensmtpd.service unbound.service
Requires=opensmtpd.service unbound.service

But fetchmail starts before the dependencies have been finished.


I can not say that I fully understand interaction of After and 
Requires/Wants options. I would try additional Wants=network-online.target



[Match]
Name=w*

[Network]
DHCP=no
Address=192.168.0.62/24
Gateway=192.168.0.32
DNS=127.0.0.1


There are options like RequiredForOnline, see systemd.network(5), but 
likely default value is yes. However avahi-autoipd should be started 
concurrently with network configuration to assign link-local address in 
the case of failure.

(deb-cat) WPS amb NetworkManager

[Narcis Garcia]

Faig servir un ordinador portàtil amb Debian GNU/Linux 11 (Stable) i 
escriptori Gnome.
De vegades vaig a llocs on tenen un router molt lligat, i es fa 
difícilcopiar la contrasenya Wifi; tot ho tenen pensat per al botonet 
«WPS» que facilita l'autoconfiguració.
Però no he trobat opció a l'entorn d'escriptori per a «prémer» 
l'equivalent al botonet.


Algú sap com fer servir el WPS?

Gràcies.

--


__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Re: Where to look into when system crashes

[Qiming Ye]

On 2023-02-22 03:21-0500, Felix Miata wrote:

Qiming Ye composed on 2023-02-22 15:30 (UTC+0800):


Actually /dev/sdb is an mSata drive.  Here's output of smartctl:

...

   9 Power_On_Hours  -O--C-   100   100   000-15975
  12 Power_Cycle_Count   -O--C-   100   100   000-69


Reasonably low use. I don't see a date of birth in the data.

The laptop is 10 years old. Its power supply could be getting tired. Are you
running it off house current when it crashes? Is the battery competent?

What's on the other drive? Is it something you can't get to crash?

Is the cooling path clean? Could something be overheating?


I see it crash when I issue command last:

$ last
...
qye  pts/0192.168.0.102Tue Feb 21 12:46 - 12:46  (00:00)
qye  pts/0192.168.0.102Tue Feb 21 12:47 - 18:06  (05:18)
qye  pts/1tmux(2515).%0Tue Feb 21 12:47 - crash  (19:53)
qye  pts/2tmux(2515).%1Tue Feb 21 13:56 - crash  (18:44)
 ^^^
reboot   system boot  5.10.0-21-amd64  Wed Feb 22 08:41   still running
...

And of course the power was off.

This mini PC is quite idle most of the time because it's just me and my friend 
using it mainly as a file server.  We do other experiments on it too sometimes.


We have another 2 disks attached to it using USB to SATA converters.  Both disks 
are healthy from what I see.


- Tim

Re: Evolution doesn't receive messages in Debian 11.

[didier gaumet]

Hello,

Le mardi 21 février 2023 à 12:09 -0800, Van Snyder a écrit :
> I just upgraded to Debian 11. I had been using Debian 10. I've used
> Evolution for many years. The version in Debian 11 is 3.48.

Evolution in Debian Stable (11, Bullseye) is 3.38

[...]
> But the messages don't appear in Evolution.
[...]
> When I installed Debian 11, I didn't destroy Debian 10.
[...]
> . Now, in
> Debian 10, there's a mish-mash of Debian 11 parts. Evolution is
> version 3.46.
[...]

Indeed, from the source of your e-mail, you are using Evolution 3.46.

That's probably your main problem: if I am not wrong, your Debian 
installation is neither plain Debian 10 (Oldstable) nor plain Debian 11 
(Stable) but partially or totally Debian Testing or Debian Unstable with 
scories of Debian 10 and 11.
Evolution 3.46 is not available from Stable or Oldstable repos, only 
from Testing and Unstable repos.


https://wiki.debian.org/DontBreakDebian

Then probably your best choice would be:
- riskier: to convert your installation to Testing or Unstable 
(depending on what is installed on your system)
- safer: to reinstall Debian 11 Stable properly, because trying to 
downgrade Debian form Testing or Unstable is not supported and even if 
you manage to do it, it is likely to cause later undesired side-effects

Re: Where to look into when system crashes

[Felix Miata]

Qiming Ye composed on 2023-02-22 15:30 (UTC+0800):

> Actually /dev/sdb is an mSata drive.  Here's output of smartctl:
...
>9 Power_On_Hours  -O--C-   100   100   000-15975
>   12 Power_Cycle_Count   -O--C-   100   100   000-69

Reasonably low use. I don't see a date of birth in the data.

The laptop is 10 years old. Its power supply could be getting tired. Are you
running it off house current when it crashes? Is the battery competent?

What's on the other drive? Is it something you can't get to crash?

Is the cooling path clean? Could something be overheating?
-- 
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