Docker Bridge network hangs all network

[Dustin Jenkins]

I'm running Debian 12.5 on a Dell Optiplex 990 with UEFI and a fast NVMe
drive with 16Gb RAM.  I've installed the latest Docker version 25.  I have
the exact same installation on a basic SATA spinning disk on the same
machine as well.

By default, Docker uses the Bridge network when running containers.  I'm
trying to build a Jekyll site using Docker, which fetches many Gem files
from rubygems.org.  My "docker run" command runs successfully for a
short period of time, but then can no longer make network connections out.
Also, my entire desktop's network capabilities are halted (i.e. browser,
apt, etc.).  When the container dies eventually, all network is restored on
the machine.  This is on my NVMe drive.  If I specify the "--network host"
option, it succeeds.

With the SATA drive installation, this all succeeds as expected.  The only
difference between the two installations is that the 8021q module (VLAN) is
loaded by default in my NVMe install that might be getting in the way but I
can't disable it.

I tested this with the latest Ubuntu and it works fine on that same NVMe
disk.

Any thoughts on this?  I use Docker very regularly.
Thank you, community!

Re: very poor nfs performance

[Dan Ritter]

Mike Kupfer wrote: 
> Stefan K wrote:
> 
> > > Can you partition the files into 2 different shares?  Put the database
> > > files in one share and access them using "sync", and put the rest of the
> > > files in a different share, with no "sync"?
> > this could be a solution, but I want to understand why is it so slow and 
> > fix that
> 
> It's inherent in how sync works.  Over-the-wire calls are expensive.
> NFS implementations try to get acceptable performance by extensive
> caching, using asynchronous operations when possible, and by issuing a
> smaller number of large RPCs (rather than a larger number of small
> RPCs).  The sync option defeats all of those mechanisms.

It is also the case that databases absolutely need sync to work
properly, so running them over NFS is a bad idea. At most, a
sqlite DB can be OK -- because sqlite is single user.

-dsr-

Re: strange time problem with bullseye

[Roy J. Tellason, Sr.]

On Thursday 07 March 2024 02:44:42 pm Greg Wooledge wrote:
> On Thu, Mar 07, 2024 at 02:33:05PM -0500, Roy J. Tellason, Sr. wrote:
> > On Thursday 07 March 2024 09:02:44 am Teemu Likonen wrote:
> > > systemctl status systemd-timesyncd.service
> > 
> > This got me some interesting results:
> > 
> > ● systemd-timesyncd.service - Network Time Synchronization
> >Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
> > vendor preset: enabled)
> >   Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
> >└─disable-with-time-daemon.conf
> >Active: inactive (dead)
> > Condition: start condition failed at Wed 2024-02-14 16:17:31 EST; 3 weeks 0 
> > days ago
> >└─ ConditionFileIsExecutable=!/usr/sbin/VBoxService was not met
> >  Docs: man:systemd-timesyncd.service(8)
> > 
> > Hmm.
> 
> Are you running that on a virtualbox client, or a virtualbox host?

That was on the host.  The client is running an older version of Slackware.
 
> In any case, you might find it interesting to read the unit file in
> question ("systemctl cat systemd-timesyncd.service").  It looks like
> you've got one of the slightly older kind, where the service is always
> installed, but is prevented from running if any of several different
> programs is found.
 
Yes,  I'm running older software here.  I did that and see those listed near 
the end of it.  The system does seem to do okay with keeping the right time,  
though,  for the most part.  The only rough spot was the RTC was way off,  but 
that's now been fixed... 


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

Re: Aw: Re: Re: very poor nfs performance

[Mike Kupfer]

Stefan K wrote:

> > Can you partition the files into 2 different shares?  Put the database
> > files in one share and access them using "sync", and put the rest of the
> > files in a different share, with no "sync"?
> this could be a solution, but I want to understand why is it so slow and fix 
> that

It's inherent in how sync works.  Over-the-wire calls are expensive.
NFS implementations try to get acceptable performance by extensive
caching, using asynchronous operations when possible, and by issuing a
smaller number of large RPCs (rather than a larger number of small
RPCs).  The sync option defeats all of those mechanisms.

mike

Re: very poor nfs performance

[debian-user]

Stefan K  wrote:
> > Run the database on the machine that stores the files and perform
> > database access remotely over the net instead. ?  
> 
> yes, but this doesn't resolve the performance issue with nfs

But it removes your issue that forces you to use the sync option.

Aw: Re: very poor nfs performance

[Stefan K]

> Run the database on the machine that stores the files and perform
> database access remotely over the net instead. ?

yes, but this doesn't resolve the performance issue with nfs

Aw: Re: Re: very poor nfs performance

[Stefan K]

> Can you partition the files into 2 different shares?  Put the database
> files in one share and access them using "sync", and put the rest of the
> files in a different share, with no "sync"?
this could be a solution, but I want to understand why is it so slow and fix 
that

Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

[Max Nikulin]

On 08/03/2024 12:35, hw wrote:

On Thu, 2024-03-07 at 23:15 -0500, Jeffrey Walton wrote:


I have a USB thermal printer for the shipping labels,
.


This printer has only 300dpi.  If you print QR-codes on it make sure
you can scan them: they have to be large enough or get you an
unscanable smear.


I believed that 300dpi is high enough resolution for QR-codes of 
reasonable size if source image has proper quality. On the other hand, 
if possible, it is better to scale QR-codes to match some whole factor 
of printer pixel size.

Re: strange time problem with bullseye/buster

[Max Nikulin]

On 08/03/2024 07:17, gene heskett wrote:

I have NDI how to extract chrony's logs from journalctl.


- man journalctl,
- docs listed on the systemd web site.

Re: very poor nfs performance

[debian-user]

Stefan K  wrote:
> > You could try removing the "sync" option, just as an experiment, to
> > see how much it is contributing to the slowdown.  
> 
> If I don't use sync I got around 300MB/s  (tested with 600MB-file) ..
> that's ok (far from great), but since there are database files on the
> nfs it can cause file/database corruption, so we would like to use
> sync option

Run the database on the machine that stores the files and perform
database access remotely over the net instead. ?

> best regards
> Stefan

Aw: Re: very poor nfs performance

[Stefan K]

> You could try removing the "sync" option, just as an experiment, to see
> how much it is contributing to the slowdown.

If I don't use sync I got around 300MB/s  (tested with 600MB-file) .. that's ok 
(far from great), but since there are database files on the nfs it can cause 
file/database corruption, so we would like to use sync option

best regards
Stefan

Aw: Re: very poor nfs performance

[Stefan K]

> You could test with noatime if you don't need access times.
> And perhaps with lazytime instead of relatime.
Mountoptions are:
type zfs (rw,xattr,noacl)
I get you point, but when you look at my fio output, the performance is quiet 
good

> Could you provide us
> nfsstat -v
server:
nfsstat -v
Server packet stats:
packetsudptcptcpconn
509979521   0  510004972   2

Server rpc stats:
calls  badcalls   badfmt badauthbadclnt
509971853   0  0  0  0

Server reply cache:
hits   misses nocache
0  0  509980028

Server io stats:
read   write
1587531840   3079615002

Server read ahead cache:
size   0-10%  10-20% 20-30% 30-40% 40-50% 50-60% 
60-70% 70-80% 80-90% 90-100%notfound
0  0  0  0  0  0  0  0  
0  0  0  0

Server file handle cache:
lookup anon   ncachedir  ncachenondir  stale
0  0  0  0  0

Server nfs v4:
null compound
2 0% 509976662 99%

Server nfs v4 operations:
op0-unused   op1-unused   op2-future   access   close
0 0% 0 0% 0 0% 5015903   0% 3091693   0%
commit   create   delegpurge   delegreturn  getattr
3146340% 1498360% 0 0% 1615740   0% 390748077 
20%
getfhlink lock locktlocku
2573550   0% 0 0% 170% 0 0% 150%
lookup   lookup_root  nverify  open openattr
3931149   0% 0 0% 0 0% 3131045   0% 0 0%
open_confopen_dgrdputfhputpubfh putrootfh
0 0% 3 0% 510522216 26% 0 0% 4 
0%
read readdir  readlink remove   rename
59976532  3% 4217910% 0 0% 4299650% 2445640%
renewrestorefhsavefh   secinfo  setattr
0 0% 0 0% 5422310% 0 0% 8453240%
setcltid setcltidconf verify   writerellockowner
0 0% 0 0% 0 0% 404569758 21% 0 
0%
bc_ctl   bind_connexchange_id  create_ses   destroy_ses
0 0% 0 0% 4 0% 2 0% 1 0%
free_stateid getdirdeleg  getdevinfo   getdevlist   layoutcommit
150% 0 0% 0 0% 0 0% 0 0%
layoutgetlayoutreturn secinfononam sequence set_ssv
0 0% 0 0% 2 0% 509980018 26% 0 
0%
test_stateid want_deleg   destroy_clid reclaim_comp allocate
100% 0 0% 1 0% 2 0% 164   0%
copy copy_notify  deallocate   ioadvise layouterror
2976670% 0 0% 0 0% 0 0% 0 0%
layoutstats  offloadcanceloffloadstatusreadplus seek
0 0% 0 0% 0 0% 0 0% 0 0%
write_same
0 0%


client:
nfsstat -v
Client packet stats:
packetsudptcptcpconn
0  0  0  0

Client rpc stats:
calls  retransauthrefrsh
37415730   0  37425651

Client nfs v4:
null read writecommit   open
1 0% 4107833  10% 30388717 81% 2516  0% 55493 0%
open_confopen_noatopen_dgrdclosesetattr
0 0% 1942520% 0 0% 2473800% 75890 0%
fsinfo   renewsetclntidconfirm  lock
459   0% 0 0% 0 0% 0 0% 4 0%
locktlockuaccess   getattr  lookup
0 0% 2 0% 1315330% 1497029   4% 3180560%
lookup_root  remove   rename   link symlink
1 0% 31656 0% 15877 0% 0 0% 0 0%
create   pathconf statfs   readlink readdir
7019  0% 458   0% 1705220% 0 0% 30007 0%
server_caps  delegreturn  getacl   setacl   fs_locations
917   0% 1181090% 0 0% 0 0% 0 0%
rel_lkowner  secinfo  fsid_present exchange_id  
create_session
0 0% 0 0% 0 0% 2 0% 1 0%
destroy_session  sequence get_lease_time   reclaim_comp layoutget
0 0% 0 0% 0  

Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

[Jeffrey Walton]

On Fri, Mar 8, 2024 at 10:16 AM Charles Curley
 wrote:
>
> On Thu, 7 Mar 2024 23:15:13 -0500
> Jeffrey Walton  wrote:
>
> > I need to generate some shipping labels for drop-off at the USPS post
> > office using USPS Ground Advantage.
> >
> > I have a USB thermal printer for the shipping labels,
> > .
> >
> > I see Debian carries libbusiness-us-usps-webtools-perl. I visited the
> > module's GitHub at
> > , but the
> > examples are on the lite side. I don't see a workflow similar to
> > creating and printing a shipping label.
> >
> > My question is, can I use the module to create and print a shipping
> > label for a USPS Ground Advantage package?
>
> charles@jhegaala:~$ apt-cache show libbusiness-us-usps-webtools-perl
> Package: libbusiness-us-usps-webtools-perl
> Version: 1.125-2
> [...]
>
> So I would start at the web site for the Web Tools.
> http://www.usps.com/webtools/
>
> On a brief scan of that site, I think the answer is yes, but you have
> some software development ahead of you.

Yeah, I was thinking the perl package is not very useful. I don't need
a perl wrapper to make a web service call. I need the other value
added stuff, like printing a label once I receive a successful
response.

Thanks.

Jeff

Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

[Charles Curley]

On Thu, 7 Mar 2024 23:15:13 -0500
Jeffrey Walton  wrote:

> I need to generate some shipping labels for drop-off at the USPS post
> office using USPS Ground Advantage.
> 
> I have a USB thermal printer for the shipping labels,
> .
> 
> I see Debian carries libbusiness-us-usps-webtools-perl. I visited the
> module's GitHub at
> , but the
> examples are on the lite side. I don't see a workflow similar to
> creating and printing a shipping label.
> 
> My question is, can I use the module to create and print a shipping
> label for a USPS Ground Advantage package?

charles@jhegaala:~$ apt-cache show libbusiness-us-usps-webtools-perl
Package: libbusiness-us-usps-webtools-perl
Version: 1.125-2
Installed-Size: 74
Maintainer: Debian Perl Group 
Architecture: all
Depends: perl:any, libhash-asobject-perl, liburi-perl, libwww-perl
Description-en: Perl module enabling use of USPS Web Tools services
 Business::US::USPS::WebTools provides a Perl interface to the US
 Postal Service's Web Tools service. You need a UserID and Password
 to use these services. See the Web Tools site at
 http://www.usps.com/webtools/ for details.
Description-md5: 9c76d38752bb4c43151a4c8fe5224e7e
Homepage: https://github.com/ssimms/business-us-usps-webtools
Tag: devel::lang:perl, devel::library, implemented-in::perl
Section: perl
Priority: optional
Filename: 
pool/main/libb/libbusiness-us-usps-webtools-perl/libbusiness-us-usps-webtools-perl_1.125-2_all.deb
Size: 26856
MD5sum: 2323b592f161074380195b80880115e3
SHA256: 8341a6417ce7017af88cba6185042911c88d9024a2b886428ba0803946085c73

charles@jhegaala:~$ 

So I would start at the web site for the Web Tools.
http://www.usps.com/webtools/

On a brief scan of that site, I think the answer is yes, but you have
some software development ahead of you.
-- 
Does anybody read signatures any more?

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

Re: Installer le noyau 6.6 sur Bookworm

[Patrick ZAJDA]

Bonjour,


Peut-on penser qu'il dépendra un jour d'un paquet
linux-image-6.6.X-Y.deb12.Z-amd64 ou bien cette dépendance est figée
pour tout le cycle d'utilisation de Bookworm ?


ça dépend si un backport est fait, pour ce qui est du kernel ça suit 
généralement la version de testing avec un décalage le temps que ça soit 
éprouvé dans testing et en suite après l'upload c'est assez long le 
temps du build et ça passe généralement par une validation des ftp masters.


En résumé la réponse est oui, c'est fort probable. Il faut patienter...


Le 08/03/2024 à 09:28, Olivier a écrit :

1. À Michel:
Je ne vois moi aussi que les paquets:
linux-image-6.6.13+bpo-amd64-dbg
linux-image-6.6.13+bpo-amd64-unsigned


2. Il y a quelques semaines, j'ai installé le noyau 6.5 avec la commande:
apt -y install linux-image-amd64 -t bookworm-backports

Ce paquet linux-image-amd64 du repo backports dépend du seul paquet
linux-image-6.5.0-0.deb12.4-amd64
Peut-on penser qu'il dépendra un jour d'un paquet
linux-image-6.6.X-Y.deb12.Z-amd64 ou bien cette dépendance est figée
pour tout le cycle d'utilisation de Bookworm ?

3. Au quotidien, comment met-on à jour un paquet linux-image-amd64 ou
linux-image-6.6.X-Y.deb12.Z-amd64 ?
Une commande apt upgrade ou apt dist-upgrade suffit-elle ?

Le jeu. 7 mars 2024 à 17:57, Michel Verdier  a écrit :

Le 7 mars 2024 Olivier a écrit :


J'ai une machine UN305 (processeur Intel Alder lake) sur laquelle j'ai
installé Bookworm puis le noyau 6.5.
J'ai besoin d'y installer le noyau 6.6 (pour corriger un problème graphique).

En backport tu as la 6.6.13 disponible. Bizarrement il n'y a que la
unsigned ou alors j'ai mal regardé :
linux-image-6.6.13+bpo-amd64-unsigned
Les sources sont aussi dispo si tu compile ton kernel.
Et les headers si tu as des drivers à compiler :
linux-headers-6.6.13+bpo-amd64



--
Patrick ZAJDA

Re: Spam from the list?

[Thomas Schmitt]

Hi,

Andy Smith wrote:
> [...] I argue that at present it
> isn't a good idea to just reject all DKIM failures like OP's mailbox
> provider appears to be doing.

Just for the records:
The mails in question don't get rejected but rather marked as spam
and then get delivered.

The currently best theory is that megamailservers.eu adds a header
  X-Spam-Flag: YES
if it perceives DKIM problems, and that the local anti-spam software
of the receiver takes this header as reason to alter the subject by
the prefix "*SPAM*".

Whether it is a good idea to map DKIM failure to a spam marking header
is another interesting topic.

Original post of this thread with an example of all headers of a mail:
  https://lists.debian.org/msgid-search/3371640.PXJkl210th@protheus2


Have a nice day :)

Thomas

Re: Spam from the list?

[Andy Smith]

Hello,

On Fri, Mar 08, 2024 at 02:16:07AM +, Tim Woodall wrote:
> And some dkim seems setup with the intention that it should not be used
> for mailinglusts:
> 
> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
> d=dow.land;
> s=20210720;
> h=From:In-Reply-To:References:Subject:To:Message-Id:Date:
> Content-Type:Content-Transfer-Encoding:Mime-Version:Sender:Reply-To:Cc:
> Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
> Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
> List-Subscribe:List-Post:List-Owner:List-Archive;

So the thing is that the RFC for DKIM specifies a list of headers to
sign and those include ones commonly used by mailing list software
so as soon as one of those mails goes through list software, the DKIM
signatures get broken. And sadly because that is what is suggested
in the RFC, that is also the default setting of Exim in Debian.

As a result heaps of messages don't make it through mailing lists
with DKIM intact even when the list operator makes some effort to
allow it to work (e.g. avoids adding footers or subject tags, just
passes the mail through, like debian-user does).

> AFAICT, it's a problem at the originator causing failures, either
> something wrong with dkim setup or too strict set of headers.

Yes. But I think a person whose receiving system outright rejects on
DKIM failure might spend their whole lives tracking down and
contacting the operators of sending systems to educate them about
DKIM, only to be mostly met with disagreement, lack of
understanding, or silence. Which is why I argue that at present it
isn't a good idea to just reject all DKIM failures like OP's mailbox
provider appears to be doing.

That sort of setup would only be suitable for someone who doesn't
really use email, except for "transactional" mails (password
reminders, OTP, etc.) and one-way newsletters. Which admittedly is
probably the majority of users - but not OP!

> I shall be checking what this does when it gets back to me. One of the
> problems with dkim is that you assume it still works, it's hard to know
> what others actually see...

Adding DMARC and a reporting address gets you far more unwelcome
insight into what others do. 

Thanks,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: Installer le noyau 6.6 sur Bookworm

[Michel Verdier]

Le 8 mars 2024 Olivier a écrit :

> Ce paquet linux-image-amd64 du repo backports dépend du seul paquet
> linux-image-6.5.0-0.deb12.4-amd64
> Peut-on penser qu'il dépendra un jour d'un paquet
> linux-image-6.6.X-Y.deb12.Z-amd64 ou bien cette dépendance est figée
> pour tout le cycle d'utilisation de Bookworm ?

Je ne suis pas sûr mais c'est ce qui se passe pour bookworm.
Comme tu peux avoir plusieurs kernels dans /boot et que tu veux une
version précise, tu as peut-être intérêt à l'installer explicitement en
plus du metapaquet.

> 3. Au quotidien, comment met-on à jour un paquet linux-image-amd64 ou
> linux-image-6.6.X-Y.deb12.Z-amd64 ?
> Une commande apt upgrade ou apt dist-upgrade suffit-elle ?

Oui apt upgrade fait le boulot. dist-upgrade n'est utile que pour les
montées de version majeure (quand on passera à trixie).

Re: very poor nfs performance

[Michel Verdier]

On 2024-03-07, Stefan K wrote:

> I hope someone can help me with my problem.
> Our NFS performance ist very bad, like ~20MB/s, mountoption looks like that:
> rw,relatime,sync,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,local_lock=none

What are the mount options for your zfs filesystem ?

You could test with noatime if you don't need access times.
And perhaps with lazytime instead of relatime.

Could you provide us
nfsstat -v

Re: libbusiness-us-usps-webtools-perl and USPS Ground Advantage shipping

[gene heskett]

On 3/7/24 23:15, Jeffrey Walton wrote:

Hi Everyone,

I need to generate some shipping labels for drop-off at the USPS post
office using USPS Ground Advantage.

I have a USB thermal printer for the shipping labels,
.

I see Debian carries libbusiness-us-usps-webtools-perl. I visited the
module's GitHub at
, but the
examples are on the lite side. I don't see a workflow similar to
creating and printing a shipping label.

My question is, can I use the module to create and print a shipping
label for a USPS Ground Advantage package?

Thanks in advance.


Probably not Jeffery. the thermal printers output fades quickly in 
bright light or turns black in higher summer heat.  A laser printer 
using carbon toner is 10,000% more permanent. That and the shipping 
materials for labels are slowly going paperless, instead using a 
recyclable plastic label material, you should probably be asking for 
something compatible with the plastic paper labels.

.


Cheers, Gene Heskett, CET.
--
"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: OpenLDAP, refuerzo de la política de contraseñas no recomendado

[RLL]

El 2/3/24 a las 17:39, Camaleón escribió:

El 2024-03-02 a las 13:51 +0100, RLL escribió:


Leyendo la documentación en páginas man sobre el overlay ppolicy,
https://manpages.debian.org/bookworm/slapd/slapo-ppolicy.5.en.html,  hay un
punto en el que puedes enlazar OpenLDAP con una aplicación externa que se
encarga de comprobar si la clave que introduce un usuario es fácil de
averiguar entre otras cosas:

pwdCheckModule is a non-standard extension to the LDAP password policy
proposal.

¿Alguien aconseja otra solución?


Por aquí se hacen la misma pregunta... sin respuesta :-(

OpenLDAP password quality control
https://stackoverflow.com/questions/77570271/openldap-password-quality-control
  
Saludos,



Y en el mundo FreeBSD si ojeo el Handbook tampoco se meten en esto.

El proyecto OpenLDAP es el mínimo común denominador... y luego hay 
muchas variantes que incluyen sus propias extensiones que tienen que 
mantener ellos mismos.


Siempre prefiero mantenerme dentro del juego que sé que seguirá ahí 
dentro de unos años.


Hay soluciones openSource de Directorio pero requieren algo más complejo 
de mantener.

Re: Installer le noyau 6.6 sur Bookworm

[Olivier]

1. À Michel:
Je ne vois moi aussi que les paquets:
linux-image-6.6.13+bpo-amd64-dbg
linux-image-6.6.13+bpo-amd64-unsigned


2. Il y a quelques semaines, j'ai installé le noyau 6.5 avec la commande:
apt -y install linux-image-amd64 -t bookworm-backports

Ce paquet linux-image-amd64 du repo backports dépend du seul paquet
linux-image-6.5.0-0.deb12.4-amd64
Peut-on penser qu'il dépendra un jour d'un paquet
linux-image-6.6.X-Y.deb12.Z-amd64 ou bien cette dépendance est figée
pour tout le cycle d'utilisation de Bookworm ?

3. Au quotidien, comment met-on à jour un paquet linux-image-amd64 ou
linux-image-6.6.X-Y.deb12.Z-amd64 ?
Une commande apt upgrade ou apt dist-upgrade suffit-elle ?

Le jeu. 7 mars 2024 à 17:57, Michel Verdier  a écrit :
>
> Le 7 mars 2024 Olivier a écrit :
>
> > J'ai une machine UN305 (processeur Intel Alder lake) sur laquelle j'ai
> > installé Bookworm puis le noyau 6.5.
> > J'ai besoin d'y installer le noyau 6.6 (pour corriger un problème 
> > graphique).
>
> En backport tu as la 6.6.13 disponible. Bizarrement il n'y a que la
> unsigned ou alors j'ai mal regardé :
> linux-image-6.6.13+bpo-amd64-unsigned
> Les sources sont aussi dispo si tu compile ton kernel.
> Et les headers si tu as des drivers à compiler :
> linux-headers-6.6.13+bpo-amd64
>