Reprise du message précédent :
J'ai un soucis avec log2ram sur une installation standard de Raspberry Pi OS via apt. Le système n'est pas opérationnel et un apt purge puis install ne résoud rien. Une idée ?
 

/var/hdd.log/ trop petit, non ? Cela doit être un répertoire ou un fichier ?

C'est un ramdisk compressé ou non ? Parce que pour la log, vaut mieux qu'il le soit, le ratio de compression est violent, tu peux facilement 4 ou 5GB avec une conso de 1GO de RAM.

Perso, je trouve que le zRAM marche bien sur RPI.

Ben j'arrive à lire mais je sais pas quoi faire

Non j'ai eu la flemme. Je sais pas où ça se configure

Ben pourtant l'erreur est claire: ERROR: RAM disk for "/var/hdd.log/" too small. Can't sync.
Il dit que le RAM disk est trop petit pour contenir /var/hdd.log/
 
https://github.com/azlux/log2ram/issues/90
 
--> Augmenter la taille du RAM disk en vérifiant la taille de /var/hdd.log/

Hello à tous,
 
Bon c'est d'un raspberry dont il est question ici, avec Raspbian, donc je présume que je suis au bon endroit pour vous narrer mon problème.
 
Je cherche à troubleshooter un soucis étrange, première fois que ça m'arrive après des années et des années dans l'informatique à bidouiller.
 
J'ai monté un raspberry pi 4 avec raspbian x64 et je fais tourner dessus des services web.
 
Mon besoin, accéder aux services depuis mon LAN mais aussi depuis internet via wireguard (la passerelle wireguard et sur un autre serveur du LAN).
 
En l'état, je peux me connecter chez moi via wireguard sans problème et accéder à mon NAS en https, à mon PC perso en RDP, mais pas au raspberry : ni à ses services http, ni en SSH, ni via VNC. Alors que tous ces services fonctionnent depuis le LAN.
 
ça ne semble pas être un problème de routage puisque j'accède à tous les appareils de mon LAN sur le même subnet que le raspberry. ça ne semble pas être un soucis de dispo car je peux accéder au raspberry depuis mon PC perso du LAN via wireguard depuis internet (donc en rebond).
 
Le raspberry filtrerait les requêtes qui n'émanent pas de son subnet
 
Si jamais vous avez des idées, ou bien des techniques de troubleshooting pour que j'y vois plus clair...
 
edit : un iptables -L donne
 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
 
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
 
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
 
Je ne sais pas si un autre firewall peut agir.
 
Ah et pour finir, le message d'erreur à chaque fois que ce soit lorsque je veux me connecter en http, ssh ou vnc : time out.

Il faudrait les IP et tables de routage de ton firewall, du raspi et d'un PC qui fonctionne. Et les règles de filtrage éventuelles de chacun d'eux.

Les services en question sont bien accessibles depuis la machine qui fait wireguard ?
Si oui, tcpdump sur la machine Wireguard et tcpdump sur le RPi pour voir si y a des trucs chelous

Ce serait con mais à tout hasard, ton client, quand il se connecte via wirehaurd, n'a pas la même IP fixe que ton raspberry ?

La machine qui fait wireguard est ma Freebox. J'avais dédié un raspberry à ça auparavant mais en passant chez free je ne voyais plus l'intérêt de garder un rasp allumé h24 juste pour ça, la freebox le fait très bien.

Nope, ça pose également soucis en 4G depuis mon téléphone.

Alors la Freebox me refile une IP en 192.168.27.0/24, là mon LAN est en 192.168.80.0/24
Sachant que l'IP du client à l'origine n'est ni en 27 ni en 80, donc pas de conflit possible.

Le routage est donc effectué par la freebox qui est le serveur wireguard également.

Sur le raspberry iptables est full open cf. mon post plus haut. Pas de trace d'ufw sur raspbian.

De quoi aurais-tu besoin exactement histoire que je fasse un export si c'est possible ?

Mais c'est quand même fou de pouvoir taper http://192.168.80.150 (mon NAS) et pas http://192.168.80.20 (le raspberry). Ou bien en SSH, pareil. ça sent pas le problème de routage pour moi.

Mais si je suis sur le LAN, je peux accéder aux 2 sans problème.

Avoir une vue globale des IP et subnets impliqués. Je ne comprends pas bien l'histoire de 192.168.27.0/24 et 192.168.80.0/24. Ce sont respectivement les subnets VPN et LAN?
 
Donc si je résume du client jusqu'au raspi:

 
Et version VPN:

 
Et si je comprends bien, depuis ton client tu pinges/atteins:
-la 27.x (port VPN de ton client)
-la 27.y (port VPN de ta box)
-la 80.1 (port LAN de ta box)
-la 80.150 (NAS dans ton LAN)
-mais pas la 80.20 du raspi ?
 
Il faudrait donc confirmation des IP et des routes du raspi et si tu peux sortir les routes de la box.
Ah oui et vérifier le bordel IPv6 éventuel parce que tu bosses en IPv4 donc il ne fera que mettre la grouille.
 
Et si pas de filtrage sur le raspi, c'est forcément un problème de route ou d'ACL éventuellement en amont... ou alors ton raspi est mort mais ça ne semble pas être le cas.

tcpdump sur le rpi pour voir si des paquets arrivent.
ip route pour voir si y a bien une gateway par défaut (le truc con mais bon )

Alors le tcpdump -n net 192.168.27 m'indique que le raspberry reçoit bien les requêtes :
 
Client : 192.168.27.65 (IP donnée par Wireguard à mon client)
Raspberry : 192.168.85.10 (le service web que je cherche à joindre est sur le port 9999)
 
 

 
Je crois comprendre qu'il n'y a pas de réponse sinon on les verrait avec cette même commande.
 
Et j'ai bien une route par défaut qui semble correcte :
 

 
Je rappelle encore une fois que si je contacte ce même service depuis le LAN je n'ai aucun problème.

Tu as la table de routage complète?
Tu aurais celle de la box?
Et celle d'un PC joignable?
 
Que dit un ping du client vers le raspi? Et du raspi vers le client? Avec un tcpdump c'est mieux pour voir.

Aucun ping ne passe depuis le client MAIS, il ne passe pas non plus vers les devices que j'arrive à joindre en RDP/HTTP/SSH donc ça veut pas dire grand chose.

En tout cas le raspberry reçoit la requête ICMP :

Le soucis c'est que je pourrai pas sortir la table de la Freebox, j'ai pas l'impression qu'on ait accès à ça.

Pour ce qui est des routes sur le raspberry :

ip route

La table de routage du PC qui fonctionne (pas de VPN, directement sur le LAN) :

La table de routage du PC client VPN qui ne fonctionne pas :

Bon après le test ultime ce serait de remonter un serveur VPN sur un raspberry bis et voir si le soucis vient de la freebox.

Pas de ping ce n'est pas idéal mais on peut s'en passer.
 
Un service tourne sur ton PC client? Il faudrait essayer de voir si des paquets partent dans l'autre sens.
 
Tu as d'autres services sur ton raspi? Tous injoignables? Parce que le 9999 ce n'est pas banal et il faudrait aussi vérifier si avec un service sur un port plus conventionnel, ça ne fonctionne pas mieux.
 
En tout cas, pas de soucis visible dans ce que tu affiches. Pour moi c'est la box.
 
edit: si un soucis: le tcpdump devrait montrer la réponse sortante (quitte à ce qu'elle n'arrive nulle part) car il reçoit bien.
 
edit2: je pense que c'est toi qui a posé la question sur les forums raspi mais la réponse d'un filtre wireguard ne tient pas.

Oui enfin depuis le Lan, y a pas d'utilisation de la route/gateway par défaut hein, c'est le concept

T'as quoi d'autres comme routes sinon ?
T'es sûr que ton RPi utilise iptables et pas nftables ?

Moi ce qui m'interpelle c'est les "ARP, Request who-has 192.168.27.98 tell 192.168.27.99"
Ton RPi aurait pas lui même une interface WireGuard ?

Nouvelle version de Raspberry Pi OS:
https://www.raspberrypi.com/news/bo [...] rry-pi-os/

Purée mais c'est quoi cette histoire ?!? On peut pas juste faire un apt dist-upgrade ? Faut se retaper toute la configuration ?!

Ça suit Debian, what else ?

Bah Debian gère très bien les montées de versions sans reinstall

Ben sous Debian l'upgrade est facile. Là ils recommandent de tout réformater

Tu reformates quand ?

C'est assez foireux comme approche de devoir tout réinstaller...
Cela étant, je n'ai pas le souvenir que c'était des mises à jour en douceur pour les versions précédentes (64 bits mis à part).
 
Je vais tenter le dist upgrade quand même, je suis joueur...  

Tu comprends quoi dans « incremental updates » ?

Une suite de mises à jours où des choses sont ajoutées.

C'est pas le genre de message qu'ils mettent a chaque fois pour se couvrir en cas de soucis ?

Ben je sais pas moi, quand ils le disent ? Faut lire jusqu'au bout...

C’est sûrement à cause du passage de x11 vers Wayland.  
Enfin pour les desktop users.

Oui en headless il doit sûrement y avoir moins de risque à faire l’upgrade

Je me trompe peut être mais la fondation n'est pas énorme. Développer des cartes et des extensions en mode startup c'est une chose, véritablement gérer seul un OS complet en est une autre. Je pense qu'ils reposent largement sur Debian surtout depuis RaspiOS et la version 64 bits.
 
Cet été, j'ai par erreur basculé en Bookworm un de mes raspis de test en 64bits avant de me rendre compte qu'elle n'existait pas officiellement.
Et mis à part les extensions raspberry qui n'ont pas été mises à jour, quasiment tous les packages venaient de Debian. Je n'ai pas le souvenir d'avoir eu des soucis au reboot mais comme j'ai fait ça un peu à l'arrache et que je m'en foutais,  possible que ma mémoire me joue des tours...

Je vais tenter avec ça:
deb http://deb.debian.org/debian bookworm main contrib non-free
deb http://security.debian.org/debian-security bookworm-security main contrib non-free
deb http://deb.debian.org/debian bookworm-updates main contrib non-free
deb http://archive.raspberrypi.org/debian/ bookworm main
 
Sinon, une discussion sur le sujet:
https://gist.github.com/jauderho/6b [...] c0ba521bd8
 
Et au passage, pas mal de changements noyau et bascule sur NetworkManager...

 
Pas convaincu !
 
Les 2 peuvent cohabiter et ce sont juste des nouveaux paquets. Pas de raisons de formater pour ça.
 
La seule raison d'un formatage, selon moi, c'est parce que le kernel ne prend plus en charge tel ou tel type de FS.
 
J'attends de voir comment ça va être géré du côté d'Octoprint (c'est le seul Pi qu'il me reste en activité   (

Je crois que je vais pas tenter le diable. J'ai Docker, log2ram et PiHole qui rajoutent chacune leur source apt ou un truc comme ça. On va attendre quelques semaines que tout ça soit stabilisé.

Apparemment le kernel est changé et déplacé avec tout ce que ça implique. Si j'en crois les échanges, il faut virer les anciens noyaux, démonter /boot et le remonter dans /boot/firmware puis installer les nouveaux. La procédure sera sans doute à vérifier et affiner parce que ça me semble potentiellement casse gueule et celui qui en cause semble ne pas avoir expérimenté...

Tenté sur un raspi qui gère un ssh, un apache, un AP wifi et un DLNA, i.e. pas très lourd.
 
Remplacement bullseye par bookworm dans les sources.list, apt update, apt dist-upgrade... et tout se déroule sans accroc. Je n'ai pas tenté de reboot mais jusque là tout va bien.
Après reboot... tadam... bin ça fonctionne toujours.    
edit: apt autoremove et nettoyage post mise à jour, tout est toujours ok.
 
Par contre, ancien kernel et évidemment, pas de nouveau qui soit installé.
 
edit: Pour le noyau, la suite.
Chez moi ça s'est bien passé mais évidemment, je ne suis pas en train de dire vous pouvez foncer les yeux fermés.
 
Nettoyage de l'existant (sans purge):
dpkg --force-all -r raspberrypi-kernel raspberrypi-bootloader
 
Il reste des fichiers .txt dans /boot .
 
umount /boot
mkdir /boot/firmware
 
Modification fstab pour que la partition actuellement montée dans /boot soit montée dans /boot/firmware
 
systemctl daemon-reload
mount /boot/firmware
apt install raspi-firmware linux-image-rpi-v8
 
Il rale parfois (lors des désinstallations forcées) mais exécute tout et le répertoire /boot/firmware contient bien tout y compris les fichiers .txt seuls rescapés de l'ancien noyau.
 
reboot... là je suis moins tranquille... ... ... ... et on dirait que c'est bon. Comme dit au début, sans garantie mais chez moi ça marche.
 
Par contre, depuis le nouveau noyau, j'ai des déconnexion wifi (et réseau car mode bridge) et des problèmes avec hostapd donc on dirait que j'ai gardé l'essentiel mais qu'il y a un soucis à ce niveau quand même.
Après un second reboot, ça s'est résolu tout seul. WTF... Investigations à prévoir certainement mais disons que globalement ça fonctionne.
 
Je comparerai avec une install bookworm from scratch.

Je suis en train d'expérimenter buildroot pour avoir des performances décentes sur PI 1 / Pi Zéro, ça marche bien pour booter vite, par contre j'arrive pas à faire marcher fbtft pour l'instant

Bon j'ai trouvé la solution, par défaut la configuration de gestion des périphériques pour le PI 1 est en Dynamic using devtmpfs only, faut passer en Dynamic using devtmpfs + mdev pour avoir les overlays.
 
Du coup en 21 secondes de boot j'ai la console sans optimisation, je trouve ça correct pour un Pi 1 tête de série avec une SD lambda