Re: @^\[@^#{[ de systemd !
Hugues Larrive a écrit : > --- Original Message --- Le jeudi 30 juin 2022 à 08:55, > BERTRAND Joël a écrit : > > >> > >> > >> Bonjour à tous, >> > > Bonjour, Bonjour, >> J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne >> bien, > > Moi aussi, il a une bonne portée. > >> mais depuis la dernière mise à jour de Debian, il y a comme un >> problème lors du démarrage et je suis contraint de démarrer les >> services à la main. Ça m'amuse cinq minutes, pas plus... :-( >> > > Pour en revenir à systemd, c'est bien pour les stations de > travail, beaucoup moins pour les serveurs ou l'embarqué. Mon pi3 > est en Debian Systemd/Linux (buster), mais maintenant je préfère > Devuan pour ce genre d'application. C'est un fork de Debian qui > offre le choix entre 3 systèmes d'init : - le traditionnel sysvinit > ; - openrc (Gentoo) ; - runit (void linux). Oui, moi aussi, je vire de plus en plus Debian pour autre chose (Devuan, mais pas uniquement). > Il est possible de migrer une debian vers devuan, la procédure est > sur le site. Il y a un moment ou apt "couine" un peu, mais ça passe > en insistant un chouya, je l'ai déjà fait trois fois, dont 2 > directement de debian 9 vers devuan chimaera (debian 11). > > Les avantages sont : - un démarrage séquentiel (clarté de la > console et des journaux) ; - une description claire du démarrage > dans /etc/rc* ; - pas de "merged /usr" ; - pas de renommage des > interfaces réseau. On est parfaitement d'accord, ce ne sont que des avantages, mais là n'est pas la question. > L’inconvénient c'est que l'absence de systemd pose des problèmes > pour les softs qui en dépendent plus ou moins comme lxc... NetBSD se démerde très bien avec un systemd-fake. Je n'ai jamais regardé plus que cela, mais j'ai vu passer quelques liens sur les listes officielles. >> Jusqu'ici, ces machines utilisaient un script rc.local qui n'est >> plus appelé. Ce script se terminait pas : >> > > Je crois que la commande magique pour qu'il soit de nouveau appelé > c'est : systemctl unmask rc.local.service Ne fonctionne pas. Ce n'est pas reproductible d'un démarrage à un autre, j'ai essayé. > C'est pas dit que ça fonctionne, il me semble que dans sysvinit, > rc.local est exécuté tout à la fin donc après networking mais > qu'avec systemd la cible multi utilisateur qui le déclenche est > atteinte avant la cible network... Voilà. Et comme le truc ne démarre pas les daemons dans un ordre établi... > De toute façon rc.local n'est pas fait pour ça, voir : > https://arkit.co.in/using-rc-local-file-execute-commands/ > > Il y a trois façons de configurer le réseau sous debian : - > /etc/network/interfaces (historique mais pas encore obsolète) ; - > systemd (moderne...) ; - network-manager (pour les ordinateurs de > bureau / portable). > > > Je pense que la méthode la mieux adaptée pour un point d'accès > sous debian est /etc/network/interfaces, surtout quand on ne s'en > sort pas avec systemd. C'est la plus éprouvée et la mieux > documentée sous debian. C'est exactement ce que j'utilise. Mais systemd passe par dessus avec des ifup@.service et autres joyeusetés. Jusqu'à Debian 10, ça passait, mais aujourd'hui, systemd est le plus fort et laisse les interfaces radio 'down' en raison de cette dépendance à rfkill. Si je retire rfkill de l'équation, les interfaces radio sont toujours bloquées par défaut (c'est un comportement nouveau). >> rfkill unblock 0 ifup wlan0 iptables-legacy -t nat -A POSTROUTING >> -s 192.168.11.0/24 -j MASQUERADE dhcpd exit 0 >> > > > Si rfkill est nuisible, autant le supprimer (apt remove rfkill). > Je n'en vois pas l'utilité sur un point d'accès. > Il faut néanmoins activer l'interface wlan0 qui est désactivée par défaut depuis la dernière mise à jour du système. > Pourquoi ne pas avoir utilisé /etc/network/interfaces ? Est-il > nécessaire de faire du routage ? Personnellement j'ai préféré > utiliser un pont : > > # /etc/network/interfaces auto lo br0 iface lo inet loopback > > iface br0 inet static address 192.168.1.253/24 gateway 192.168.1.1 > pre-up iw dev wlan0 set type __ap up /etc/nftables.conf # > > # dans /etc/hostapd/hostapd.conf : bridge=br0 Je ne veux pas un pont parce qu'il y a du filtrage et que je tiens absolument à isoler les réseaux pour des raisons de sécurité. Quant au réseau, il est géré par /etc/network/interfaces, exclusivement. JKB
Changelog unavailable / This change is not coming from a source that supports changelogs
= Using: Debian GNU/Linux 11 (bullseye) I've begun to see the following error messages whenever I try to upgrade new packages. I wait a few days but they don't go away. No changelog is available. It's not limited to the following attempt at upgrading openssl but now happens to all new packages available. Is this some sort of Man in The Middle attack or is there an easy explanation and a simple way to fix? I had no problems when I used Sid, I never received an error message for changelogs. But now, on a Stable install, after having it installed for awhile and every package upgrade worked, just suddenly I have these warnings and I'm afraid to update before asking here. My apt sources list isn't bizarre, using official Debian repositories. If this doesn't stop I'll have no choice but to return to using Sid, which I would rather not do at the moment. >> Here's what I see, using "openssl" as an example: << ** In Terminal ** # apt changelog openssl Err:1 https://metadata.ftp-master.debian.org openssl 1.1.1n-0+deb11u3 Changelog Changelog unavailable for openssl=1.1.1n-0+deb11u3 (404 Not Found [IP: 146.75.94.132 443]) E: Failed to fetch https://metadata.ftp-master.debian.org/changelogs/main/o/openssl/openssl_1.1.1n-0%2bdeb11u3_changelog Changelog unavailable for openssl=1.1.1n-0+deb11u3 (404 Not Found [IP: 146.75.94.132 443]) ** In Synaptic ** This change is not coming from a source that supports changelogs. Failed to fetch the changelog for openssl URI was: https://metadata.ftp-master.debian.org/changelogs/main/o/openssl/openssl_1.1.1n-0%2bdeb11u3_changelog
Re: @^\[@^#{[ de systemd !
--- Original Message ---
Le jeudi 30 juin 2022 à 08:55, BERTRAND Joël a
écrit :
>
>
> Bonjour à tous,
>
Bonjour,
> J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne bien,
Moi aussi, il a une bonne portée.
> mais depuis la dernière mise à jour de Debian, il y a comme un problème
> lors du démarrage et je suis contraint de démarrer les services à la
> main. Ça m'amuse cinq minutes, pas plus... :-(
>
Pour en revenir à systemd, c'est bien pour les stations de travail,
beaucoup moins pour les serveurs ou l'embarqué. Mon pi3 est en
Debian Systemd/Linux (buster), mais maintenant je préfère Devuan pour
ce genre d'application. C'est un fork de Debian qui offre le choix
entre 3 systèmes d'init :
- le traditionnel sysvinit ;
- openrc (Gentoo) ;
- runit (void linux).
Il est possible de migrer une debian vers devuan, la procédure est sur
le site. Il y a un moment ou apt "couine" un peu, mais ça passe en
insistant un chouya, je l'ai déjà fait trois fois, dont 2 directement
de debian 9 vers devuan chimaera (debian 11).
Les avantages sont :
- un démarrage séquentiel (clarté de la console et des journaux) ;
- une description claire du démarrage dans /etc/rc* ;
- pas de "merged /usr" ;
- pas de renommage des interfaces réseau.
L’inconvénient c'est que l'absence de systemd pose des problèmes pour
les softs qui en dépendent plus ou moins comme lxc...
> Jusqu'ici, ces machines utilisaient un script rc.local qui n'est plus
> appelé. Ce script se terminait pas :
>
Je crois que la commande magique pour qu'il soit de nouveau appelé c'est :
systemctl unmask rc.local.service
C'est pas dit que ça fonctionne, il me semble que dans sysvinit, rc.local
est exécuté tout à la fin donc après networking mais qu'avec systemd
la cible multi utilisateur qui le déclenche est atteinte avant la cible
network...
De toute façon rc.local n'est pas fait pour ça, voir :
https://arkit.co.in/using-rc-local-file-execute-commands/
Il y a trois façons de configurer le réseau sous debian :
- /etc/network/interfaces (historique mais pas encore obsolète) ;
- systemd (moderne...) ;
- network-manager (pour les ordinateurs de bureau / portable).
Je pense que la méthode la mieux adaptée pour un point d'accès sous
debian est /etc/network/interfaces, surtout quand on ne s'en sort
pas avec systemd. C'est la plus éprouvée et la mieux documentée sous
debian.
> rfkill unblock 0
> ifup wlan0
> iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE
> dhcpd
> exit 0
>
Si rfkill est nuisible, autant le supprimer (apt remove rfkill). Je
n'en vois pas l'utilité sur un point d'accès.
Pourquoi ne pas avoir utilisé /etc/network/interfaces ? Est-il
nécessaire de faire du routage ? Personnellement j'ai préféré
utiliser un pont :
# /etc/network/interfaces
auto lo br0
iface lo inet loopback
iface br0 inet static
address 192.168.1.253/24
gateway 192.168.1.1
pre-up iw dev wlan0 set type __ap
up /etc/nftables.conf
#
# dans /etc/hostapd/hostapd.conf :
bridge=br0
Avec cette configuration on obtient un point d'accès "transparent"
au niveau IP : les périphériques wifi sont sur le même sous-réseau
que l'ethernet, il peuvent recevoir une adresse du DHCP de la
passerelle ou d'un serveur, le point d'accès n'a qu'une seul IP
sur br0. Il n'est pas nécessaire d'activer l'IP forwarding ou de
faire du masquerading avec nftables, il faut juste installer
bridge-utils.
Si on préfère isoler le wifi :
# /etc/network/interfaces
auto lo eth0 wlan0
iface lo inet loopback
iface eth0 inet dhcp
iface wlan0 inet static
address 192.168.11.254/24
pre-up iw dev wlan0 set type __ap
bridge_ports eth0 wlan0
#
Le script (mode 755) /etc/nftables.conf que j'utiliserais :
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0;
}
chain forward {
type filter hook forward priority 0;
}
chain output {
type filter hook output priority 0;
}
chain postrouting {
type nat hook postrouting priority 100; policy accept;
ip saddr 192.168.11.0/24 oifname eth0 masquerade
}
}
#
J'aime bien les scripts nft probablement à cause des accolades
et de l'indentation. Je les trouves plus lisibles que les
scripts iptables qui m'avaient toujours rebuté.
Avec du filtrage et du NAT/PAT (soyez indulgent, je débute en
nft) ça donnerait ce genre de chose :
#!/usr/sbin/nft -f
#
# nettoyage des règles existantes
flush ruleset
define LAN_IF = eth0
define WLAN_IF = wlan0
define WLAN_NET = 192.168.11.0/24
# un serveur en wifi
define WSRV_IP = 192.168.11.1
# table de filtrage ipv4
table inet filter {
chain output {
# le trafic sortant est autorisé par défaut
type filter hook output priority 0; policy accept;
}
chain inbound {
# le trafic entrant est rejeté par défaut
type filter hook input priority 0; policy drop;
# accepter les
Re: Lost internet access after "# apt update"
On Thu, Jun 30, 2022 at 15:35 riveravaldez wrote: > On 6/30/22, Tom Browder wrote: > > (...) Thanks for your suggestions. I was able to briefly look at the responses but I will have to give exact details tomorrow. I was not able to ping google.com: no dns address found so it just hung. I was able to get a response from “ip route” which showed my wired and wireless nics. I did see the same ip4 address for the wired and wireless upon first attempt but dropped the wireless ip and still no change. I’ll give more details tomorrow. Best regards, -Tom
Re: Synaptic missing in "Bookworm"
On 1/07/22 12:08, Peter Hillier-Brook wrote: anyone with thoughts, or info about Synaptic missing in "Bookworm"? https://tracker.debian.org/pkg/synaptic Richard
Synaptic missing in "Bookworm"
anyone with thoughts, or info about Synaptic missing in "Bookworm"?
Nettoyage du spam : juin 2022
Bonjour, Comme nous sommes en juillet, il est désormais possible de traiter les archives du mois de juin 2022 des listes francophones. N'oubliez bien sûr pas d'ajouter votre nom à la liste des relecteurs pour que nous sachions où nous en sommes. Détails du processus de nettoyage du spam sur : https://wiki.debian.org/I18n/FrenchSpamClean OpenPGP_signature Description: OpenPGP digital signature
Re: Lost internet access after "# apt update"
On 6/30/22, Tom Browder wrote: > (...) > > Note I had just updated and upgraded three Deb 11 servers in the cloud and > was lulled into thinking my home laptop should update just as flawlessly. > But I was sorely mistaken! Now, while on the laptop, I can see that I > appear to be connected to my LAN, but I cannot access the internet. Other > devices (two iPhones, two iPads, and a Windows box) can access the network > and the internet. From my router I can see the laptop is connected to it. Hi, what's the output of `ip route` ? Can you ping to something like google.com ? If the laptop is connected to the LAN (I suppose through Wi-Fi) maybe the DHCP assigned the same local IP-address to more than one device (I'm just guessing), and sometimes that blocks the Internet access. Hope you had luck with the issue. Kind regards!
Lost internet access after "# apt update"
I came home after being away for over a week, logged in to my home server (Debian 11 on a laptop) remotely through a terminix app on my iPad, checked for updates, accepted all and started the update. (I stupidly did not use an open terminal on the laptop screen and watch as I normally do.) Note I had just updated and upgraded three Deb 11 servers in the cloud and was lulled into thinking my home laptop should update just as flawlessly. But I was sorely mistaken! Now, while on the laptop, I can see that I appear to be connected to my LAN, but I cannot access the internet. Other devices (two iPhones, two iPads, and a Windows box) can access the network and the internet. From my router I can see the laptop is connected to it. I suspect a firewall problem but I'm too ignorant to prove it. (See a previous problem I had with a new Digital Ocean (DO) server that was being blocked by DO from ports 80 and 443.) I checked: UFW is installed but not active, firewalld is installed, and /etc/alternatives/iptables is a link to iptables-legacy. Other data points: (1) When I do a login, it takes *four* minutes for the system to get where my default desktop has two open terminal windows. (2) I have searched kern and user logs but haven't seen any clues meaningful to me. Ideas are very welcome. Thanks. -Tom
Re: how find name of terminal emulator?
On 2022-06-28, Vincent Lefevre wrote: > On 2022-06-28 10:14:48 -0400, Greg Wooledge wrote: >> On Tue, Jun 28, 2022 at 01:53:17PM +, visqa...@yahoo.com wrote: >> > so if i start uxterm or xterm, how do i find name using command? >> >> ps -p "$PPID" > > But note that you won't be able to tell the difference between > xterm and uxterm like that, since uxterm is just xterm using a > different resource class. "xprop -id $WINDOWID" gives additional > information, in particular WM_CLASS. > This seems to work (without all the superfluous output of xprop ...) ps -p $(ps -p $$ -o ppid=) o args= curty@einstein:~$ ps -p $(ps -p $$ -o ppid=) o args= xterm -class UXTerm -title uxterm -u8 curty@einstein:~$ ps -p $(ps -p $$ -o ppid=) o args= xterm
Re: Disable systemd script just by removing execute permission?
On Thu, Jun 30, 2022 at 11:30:25AM +0100, Ottavio Caruso wrote: > $ cat /usr/lib/systemd/system-sleep/tlp > #!/bin/sh > > # tlp - systemd suspend/resume hook > # > # Copyright (c) 2022 Thomas Koch and others. > # This software is licensed under the GPL v2 or later. > > case $1 in > pre) tlp suspend ;; > post) tlp resume ;; > esac > > I don't want to uninstall tlp altogether, so I have removed execute > permission from this script: > > $ ls -l /usr/lib/systemd/system-sleep/tlp > -rw-r--r-- 1 root root 239 Feb 3 15:04 /usr/lib/systemd/system-sleep/tlp > > Is this enough, or do I have to remove it altogether from > /usr/lib/systemd/system-sleep/ ? Try It And See? If it doesn't work out, you could insert "exit 0" right under the shebang, and restore the execute perms. That's the normal way one tells a shell script to do nothing, and stop complaining about it.
Re: @^\[@^#{[ de systemd !
didier gaumet a écrit :
>
>
> Bonjour,
Bonjour,
> Si je ne comprends pas de travers (c'est toujous possible, hein...), je
> pense qu'il s'agit potentiellement d'une caractéristique de Systemd qui
> requiert des instructions assez explicites:
> - tu spécifies que ton service rfkill doit tourner après ("After=") le
> service systemd-rfkill.
> - Mais ce faisant, littéralement, tu ne spécifies pas que pour toi
> systemd-rfkill *doit* être lancé, donc il ne l'est pas car la clause
> "After=" ne l'implique pas.
> - En plus de la clause "After=" pour le séquencement, il faudrait
> spécifier une clause "Requires=" pour indiquer que tu veux que le
> service ssytemd-rfkill soit lancé
>
> cf https://wiki.archlinux.org/title/Systemd#Handling_dependencies
Exact. J'ai fait simple parce que systemd-rfkill est lancé sur le
système (et est lancé avant rfkill, je le vois sur la console). Je vais
rajouter cette clause, mais ce n'est pas la bonne réponse ;-)
Bien cordialement,
JKB
Re: @^\[@^#{[ de systemd !
Bonjour,
Si je ne comprends pas de travers (c'est toujous possible, hein...), je
pense qu'il s'agit potentiellement d'une caractéristique de Systemd qui
requiert des instructions assez explicites:
- tu spécifies que ton service rfkill doit tourner après ("After=") le
service systemd-rfkill.
- Mais ce faisant, littéralement, tu ne spécifies pas que pour toi
systemd-rfkill *doit* être lancé, donc il ne l'est pas car la clause
"After=" ne l'implique pas.
- En plus de la clause "After=" pour le séquencement, il faudrait
spécifier une clause "Requires=" pour indiquer que tu veux que le
service ssytemd-rfkill soit lancé
cf https://wiki.archlinux.org/title/Systemd#Handling_dependencies
Re: @^\[@^#{[ de systemd !
Bonjour, pas de réponse, j'ai abandonné depuis longtemps. Je fais dans crontab root @reboot /usr/local/bin/aafterReboot.sh et le script #!/bin/bash debug=false second=0 max_time=10 while [ "$second" -lt "$max_time" ]; do sleep 1 second=$((second+1)) [ $debug = true ] && echo $second case $second in 1) ;; 2) ;; 3) ;; 4) ;; 5) ;; 6) ;; 7) ;; 8) ;; 9) ;; 10) ;; *) ;; esac done exit 0 et je suis heureux :) Le 30/06/2022 à 08:55, BERTRAND Joël a écrit : Bonjour à tous, J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne bien, mais depuis la dernière mise à jour de Debian, il y a comme un problème lors du démarrage et je suis contraint de démarrer les services à la main. Ça m'amuse cinq minutes, pas plus... :-( Jusqu'ici, ces machines utilisaient un script rc.local qui n'est plus appelé. Ce script se terminait pas : rfkill unblock 0 ifup wlan0 iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE dhcpd exit 0 Aujourd'hui, lorsque je démarre un rPI, je me retrouve avec une interface wlan0 qui est bloquée par défaut (soft) : root@abel:~# rfkill ID TYPE DEVICESOFT HARD 0 wlan phy0 blocked unblocked 1 bluetooth hci0 blocked unblocked root@abel:~# Là, je ne comprends pas. L'interface est _toujours_ active lors de l'extinction et systemd.restore_state vaut par défaut 1. Si je lance successivement : rfkill unblock 0 ifup wlan0 hostapd -B -P /run/hostapd.pid /etc/hostapd/hostapd.conf dhcpd je récupère une borne WiFi fonctionnelle. J'ai donc écrit dans /etc/systemd/system les choses suivantes : root@abel:/etc/systemd/system# cat rfkill.service [Unit] Description=rfkill Before=ifup@wlan0.service After=systemd-rfkill [Service] Type=oneshot ExecStart=/usr/sbin/rfkill unblock 0 [Install] WantedBy=network.target root@abel:/etc/systemd/system# cat route.service [Unit] Description=Wlan route After=networking.service [Service] Type=oneshot ExecStart=/usr/sbin/iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE [Install] WantedBy=network.target root@abel:/etc/systemd/system# cat dhcpd.service [Unit] Description=dhcpd After=route.service [Service] Type=forking ExecStart=/usr/sbin/dhcpd [Install] WantedBy=network.target Si route.service et dhcpd.service sont appelés, pas moyen que rfkill.service soit appelé au bon moment. Il faut pourtant qu'il soit appelé _après_ systemd-rfkill (qui merdoie) et avant que l'interface wlan0 soit montée par ifup.service. Lors du démarrage, systemd provoque un timeout sur rfkill.service et merdoie sur hostapd.service (là, ce n'est pas un timeout, mais des lancements de hostapd en boucle parce que wlan0 n'existe pas). Une idée pour corriger la chose, parce que je ne comprends pas trop. Bien cordialement, JKB
problems with cbl.abuseat.org
I'm using postfix as my MTA and lately I've been missing a significant fraction from my usual mail e.g. email from linkedin and spamassassin list. Tracking it down I see they are all getting rejected by abuseat. e.g. Jun 30 14:20:09 egde postfix/25pass/smtpd[21040]: NOQUEUE: reject: RCPT from mail.openbsd.org[199.185.178.25]: 554 5.7.1 Service unavailable; Client host [199.185.178.25] blocked using cbl.abuseat.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/172.68.1.20; from= to= proto=ESMTP helo= I've removed that from my postfix filters, but is there a current best practice set of rbl filters? -- Jeremy OpenPGP_signature Description: OpenPGP digital signature
@^\[@^#{[ de systemd !
Bonjour à tous, J'utilise des rPI 3 comme point d'accès WiFi. Cela fonctionne bien, mais depuis la dernière mise à jour de Debian, il y a comme un problème lors du démarrage et je suis contraint de démarrer les services à la main. Ça m'amuse cinq minutes, pas plus... :-( Jusqu'ici, ces machines utilisaient un script rc.local qui n'est plus appelé. Ce script se terminait pas : rfkill unblock 0 ifup wlan0 iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE dhcpd exit 0 Aujourd'hui, lorsque je démarre un rPI, je me retrouve avec une interface wlan0 qui est bloquée par défaut (soft) : root@abel:~# rfkill ID TYPE DEVICESOFT HARD 0 wlan phy0 blocked unblocked 1 bluetooth hci0 blocked unblocked root@abel:~# Là, je ne comprends pas. L'interface est _toujours_ active lors de l'extinction et systemd.restore_state vaut par défaut 1. Si je lance successivement : rfkill unblock 0 ifup wlan0 hostapd -B -P /run/hostapd.pid /etc/hostapd/hostapd.conf dhcpd je récupère une borne WiFi fonctionnelle. J'ai donc écrit dans /etc/systemd/system les choses suivantes : root@abel:/etc/systemd/system# cat rfkill.service [Unit] Description=rfkill Before=ifup@wlan0.service After=systemd-rfkill [Service] Type=oneshot ExecStart=/usr/sbin/rfkill unblock 0 [Install] WantedBy=network.target root@abel:/etc/systemd/system# cat route.service [Unit] Description=Wlan route After=networking.service [Service] Type=oneshot ExecStart=/usr/sbin/iptables-legacy -t nat -A POSTROUTING -s 192.168.11.0/24 -j MASQUERADE [Install] WantedBy=network.target root@abel:/etc/systemd/system# cat dhcpd.service [Unit] Description=dhcpd After=route.service [Service] Type=forking ExecStart=/usr/sbin/dhcpd [Install] WantedBy=network.target Si route.service et dhcpd.service sont appelés, pas moyen que rfkill.service soit appelé au bon moment. Il faut pourtant qu'il soit appelé _après_ systemd-rfkill (qui merdoie) et avant que l'interface wlan0 soit montée par ifup.service. Lors du démarrage, systemd provoque un timeout sur rfkill.service et merdoie sur hostapd.service (là, ce n'est pas un timeout, mais des lancements de hostapd en boucle parce que wlan0 n'existe pas). Une idée pour corriger la chose, parce que je ne comprends pas trop. Bien cordialement, JKB
