Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
Pardon, c'est effectivement lspci qu'il faut utiliser. Le 17/06/2023 à 17:34, didier gaumet a écrit : Le 17/06/2023 à 16:31, Romain P. a écrit : Le 16/06/2023 à 16:30, NoSpam a écrit : Bonjour. Pour gérer le RAID il faut savoir quel est est le contrôleur de la machine: sudo lpci|grep RAID puis chercher quel est le module chargé de sa gestion et le charger. Bonjour , Je n'arrive pas à utiliser la commande : " romain@Debian-11-MSI-MPG:~$ sudo lpci|grep Usage : grep [OPTION]... MOTIFS [FICHIER]... Exécutez « grep --help » pour obtenir des renseignements complémentaires. [sudo] Mot de passe de romain : sudo: lpci : commande introuvable romain@Debian-11-MSI-MPG:~$ sudo aptitude show lpci E: Paquet lpci introuvable " Merci, Romain 1) NoSpam a simplement fait une faute de frappe et ne s'est pas relu :-) donc il faut lire lspci et non pas lpci (lspci pour ls pci, soit listage des périphériques PCI 2) ce n'est pas sudo lscpi|grep qu'il faut écrire. C'est bien la commande entière qu'il (NoSpam) t'a donnée: sudo lspci|grep RAID qui signifie: en tant que root (sudo), parmi les périphériques PCI (lspci), cherche le mot RAID en respectant la casse. En fait cette commande va te donner un truc du style: 02:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) tu prends la référence du début (ici: 02:00.0) et tu fais une recherche du module noyau utilisé en remplaçant la référence par la tienne (par exemple 01:23.4: lspci -vvv -s 01:23.4 | grep -i module le résultat est: Kernel modules: iwlwifi là je t'ai mis l'exemple de ma carte wifi (je n'ai pas de matériel RAID)
Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
On Saturday 17 June 2023 17:34:06 didier gaumet wrote: > Le 17/06/2023 à 16:31, Romain P. a écrit : > > Je n'arrive pas à utiliser la commande : > > romain@Debian-11-MSI-MPG:~$ sudo lpci|grep > > Usage : grep [OPTION]... MOTIFS [FICHIER]... > > Exécutez « grep --help » pour obtenir des renseignements complémentaires. > > [sudo] Mot de passe de romain : > > sudo: lpci : commande introuvable > > romain@Debian-11-MSI-MPG:~$ sudo aptitude show lpci > > E: Paquet lpci introuvable > 1) NoSpam a simplement fait une faute de frappe et ne s'est pas relu :-) > donc il faut lire lspci et non pas lpci (lspci pour ls pci, soit listage > des périphériques PCI Pas toujours facile de détecter les "fautes de frappe". > 2) ce n'est pas sudo lscpi|grep > qu'il faut écrire. C'est bien la commande entière qu'il (NoSpam) t'a donnée: > sudo lspci|grep RAID : Pas reçu cette info de NoSpam (qu'il ne m'a pas donnée). > qui signifie: en tant que root (sudo), parmi les périphériques PCI > (lspci), cherche le mot RAID en respectant la casse. Je pense que la majorité avait compris la réponse de "lspci|grep RAID"
Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
Le 17/06/2023 à 16:31, Romain P. a écrit : Le 16/06/2023 à 16:30, NoSpam a écrit : Bonjour. Pour gérer le RAID il faut savoir quel est est le contrôleur de la machine: sudo lpci|grep RAID puis chercher quel est le module chargé de sa gestion et le charger. Bonjour , Je n'arrive pas à utiliser la commande : " romain@Debian-11-MSI-MPG:~$ sudo lpci|grep Usage : grep [OPTION]... MOTIFS [FICHIER]... Exécutez « grep --help » pour obtenir des renseignements complémentaires. [sudo] Mot de passe de romain : sudo: lpci : commande introuvable romain@Debian-11-MSI-MPG:~$ sudo aptitude show lpci E: Paquet lpci introuvable " Merci, Romain 1) NoSpam a simplement fait une faute de frappe et ne s'est pas relu :-) donc il faut lire lspci et non pas lpci (lspci pour ls pci, soit listage des périphériques PCI 2) ce n'est pas sudo lscpi|grep qu'il faut écrire. C'est bien la commande entière qu'il (NoSpam) t'a donnée: sudo lspci|grep RAID qui signifie: en tant que root (sudo), parmi les périphériques PCI (lspci), cherche le mot RAID en respectant la casse. En fait cette commande va te donner un truc du style: 02:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) tu prends la référence du début (ici: 02:00.0) et tu fais une recherche du module noyau utilisé en remplaçant la référence par la tienne (par exemple 01:23.4: lspci -vvv -s 01:23.4 | grep -i module le résultat est: Kernel modules: iwlwifi là je t'ai mis l'exemple de ma carte wifi (je n'ai pas de matériel RAID)
Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
Le 17/06/2023 à 16:09, Romain P. a écrit : [...] Oui, ça serait du RAID5 pseudo matériel géré par la carte mère. Sous Debian 10 ça fonctionnait avec Mdadm. [...] Donc ce serait normalement à gérer par dmraid. Mais je vois qu'il est possible de forcer l'utilisation de mdadm (paramètre Grub au démarrage). c'est peut-être ce que tu avais fait par le passé pour que ça fonctionne. La page du wiki Debian pour l'installation sur du FakeRAID : https://wiki.debian.org/DebianInstaller/SataRaid
Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
On Saturday 17 June 2023 16:31:01 Romain P. wrote: > Je n'arrive pas à utiliser la commande : > romain@Debian-11-MSI-MPG:~$ sudo lpci|grep > Usage : grep [OPTION]... MOTIFS [FICHIER]... > Exécutez « grep --help » pour obtenir des renseignements complémentaires. > [sudo] Mot de passe de romain : > sudo: lpci : commande introuvable > romain@Debian-11-MSI-MPG:~$ sudo aptitude show lpci > E: Paquet lpci introuvable Il faudrait voir la totalité de la commande avec grep. # apt-cache search lpci lpctools - interface to NXP LPC Microcontrollers ISP serial interface
Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
Le 16/06/2023 à 16:30, NoSpam a écrit : Bonjour. Pour gérer le RAID il faut savoir quel est est le contrôleur de la machine: sudo lpci|grep RAID puis chercher quel est le module chargé de sa gestion et le charger. Bonjour , Je n'arrive pas à utiliser la commande : " romain@Debian-11-MSI-MPG:~$ sudo lpci|grep Usage : grep [OPTION]... MOTIFS [FICHIER]... Exécutez « grep --help » pour obtenir des renseignements complémentaires. [sudo] Mot de passe de romain : sudo: lpci : commande introuvable romain@Debian-11-MSI-MPG:~$ sudo aptitude show lpci E: Paquet lpci introuvable " Merci, Romain
Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
Le 17/06/2023 à 10:30, didier gaumet a écrit : Bonjour, avertissement préalable: je n'ai jamais pratiqué le RAID et on peut raisonnablement dire que je n'y connais quasiment rien Soit je n'ai rien compris au RAID (c'est assez vraisemblable) soit tu confonds différents types de RAID (ça m'a l'air possible aussi). L'impression (sans creuser) que j'ai est que tu disposes d'une carte qui n'est pas (matériellement) une vraie carte RAID mais propose des fonctions RAID au niveau de l'UEFI? Si c'est le cas ça semblerait être pouvoir être géré sous linux de deux manières: - en pur logiciel (via mdadm) à condition de désactiver dans ton UEFI les fonctions RAID de ta carte - en FakeRAID (pseudo-matériel)(via dmraid) à condition d'activer dans ton UEFI les fonctions RAID de ta carte le wiki d'Archlinux est assez bien documenté sur le RAID, je pense que la majorité du contenu de cette page est transposable sans grosse différence: https://wiki.archlinux.org/title/RAID Encore une fois, ne pas prendre ce que je dis pour argent comptant et se faire sa propre opinion argumentée: j'y connais rien :-) Bonjour Didier Oui, ça serait du RAID5 pseudo matériel géré par la carte mère. Sous Debian 10 ça fonctionnait avec Mdadm. Ci-joint image. Merci Romain
Re: pilote nvidia propriétaire et noyau 6.3
Le 17/06/2023 à 08:53, Pierre Tomon a écrit : Il y a un rapport de bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038004 Ok merci, j'avais pas regardé sur le pilote, vu que c'est une maj du noyau qui a tout cassé...
Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage
le truc c’est de relancer le service qui écrit dans les logs, probablement rsyslog : le processus en cours est terminé, et les fichiers supprimés sont alors réellement libérés… Merci. - Mail original - De: "Frédéric BOITEUX" À: "Liste Debian" Envoyé: Vendredi 16 Juin 2023 14:02:07 Objet: RE: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage Bonjour, > Quand /var/log/ se remplit de messages d'erreur (messages syslog et > user.messages), ça sonne puisque plus rien qui utilise /var ne peut > fonctionner ! > Si root supprime les fichiers remplis de la même alerte, /var reste rempli à > 100%. Oui, c’est un classique ! Tant que le [gros] fichier est ouvert par un processus, il existe encore et sa place n’est pas libérée. Ici, le truc c’est de relancer le service qui écrit dans les logs, probablement rsyslog : le processus en cours est terminé, et les fichiers supprimés sont alors réellement libérés… Cdlt, Fred (pas trop barbu :-)
Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage
De: "NoSpam" À: "Liste Debian" Envoyé: Vendredi 16 Juin 2023 12:07:44 Objet: Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage Bonjour Le 16/06/2023 à 11:46, [ mailto:roger.tar...@free.fr | roger.tar...@free.fr ] a écrit : Bonjour, Quand /var/log/ se remplit de messages d'erreur (messages syslog et user.messages), ça sonne puisque plus rien qui utilise /var ne peut fonctionner ! Si root supprime les fichiers remplis de la même alerte, /var reste rempli à 100%. ??? Jamais vu cela en ext2/3/4 ou xfs Quel fs ? Réponse : ext4 BQ_BEGIN Il y aurait bien un lsof puis un kill de tout ce qui est "deleted". Comment faire pour libérer l'espace sans devoir redémarrer la machine ? Fiablement, sans effet boomerang. Egalement, comment éviter que /var ( partition dédiée) bloque la machine quand il est plein ? BQ_END var est nécessaire. Il existe des outils comme librenms/munin/cacti/zabbix/... qui alertent -> j'ai lu une réponse ultérieure qui parle de systemd : [ https://manpages.debian.org/bookworm/systemd/tmpfiles.d.5.en.html | https://manpages.debian.org/bookworm/systemd/tmpfiles.d.5.en.html ] ? systemd me prend inutilement ma tête avec sa logique qui oblige à décortiquer la doc et à pratiquer pour identifier ses (vils) pièges (par exemple il faut écrire une valeur nulle avant d'écrire la valeur souhaitée; timer, etc.) Mais une fois que c'est maîtrisé, c'est fiable et ça permet de se passer de pleins d'autres services (ex : crontab). BQ_BEGIN Je pensais à un script qui surveille les logs et tronçonne les messages répétés pour maintenir. Un service du système ou un paquet gère-t-il ça ? ça doit arriver tellement souvent... BQ_END Cela a du m'arriver à mes débuts avec Linux. Depuis, je surveille les serveurs comme le lait sur le feu ... [...] -> je m'efforce de mettre en place le thermomètre et le contrôle automatique du gaz pour ne plus me trouver en urgence !
Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage
J'utilise LVM. J'ai une partition dédiée à /var. Comment ta solution empêche-t-elle de bloquer les services qui ont besoin de place dans /var s'il est plein ? - Mail original - De: "Alain Vaugham" À: "Liste Debian" Envoyé: Vendredi 16 Juin 2023 12:58:54 Objet: Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage Le Fri, 16 Jun 2023 11:46:49 +0200 (CEST), roger.tar...@free.fr a écrit : > Egalement, comment éviter que /var ( partition dédiée ) bloque la > machine quand il est plein ? Pour éviter de remplir /var à cause de la pollution des logs, je créé une partition dédiée /var/log. -- Alain Vaugham Clef GPG : 0xDB77E054673ECFD2
Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage
Simple et efficace. Comment peut-on oublier une si bonne recette ?! Merci. De: "plapla" À: "Liste Debian" Envoyé: Vendredi 16 Juin 2023 12:47:42 Objet: Re: Libérer l'espace après suppression de fichiers de log énormes dans /var + éviter d'atteindre le blocage Le 16/06/2023 à 11:46, [ mailto:roger.tar...@free.fr | roger.tar...@free.fr ] a écrit : Bonjour, Quand /var/log/ se remplit de messages d'erreur (messages syslog et user.messages), ça sonne puisque plus rien qui utilise /var ne peut fonctionner ! Si root supprime les fichiers remplis de la même alerte, /var reste rempli à 100%. Il y aurait bien un lsof puis un kill de tout ce qui est "deleted". Comment faire pour libérer l'espace sans devoir redémarrer la machine ? Fiablement, sans effet boomerang. Salut, j'ai eu ce problème une fois, et un barbu m'a filé ce truc. En fait tant que le fichier est en écriture par le système, il ne s'efface pas vraiment. Il faut l'effacer sur place avec un : echo 0>/var/log/le_log.log Ça efface tout le texte, qu'on perd donc ! Il faut être sûr qu'on ne veut pas étudier le fichier ensuite. mes 0.02 c.
Re: RAID5 (Mdadm) non fonctionnel sous Debian 11
Bonjour, avertissement préalable: je n'ai jamais pratiqué le RAID et on peut raisonnablement dire que je n'y connais quasiment rien Soit je n'ai rien compris au RAID (c'est assez vraisemblable) soit tu confonds différents types de RAID (ça m'a l'air possible aussi). L'impression (sans creuser) que j'ai est que tu disposes d'une carte qui n'est pas (matériellement) une vraie carte RAID mais propose des fonctions RAID au niveau de l'UEFI? Si c'est le cas ça semblerait être pouvoir être géré sous linux de deux manières: - en pur logiciel (via mdadm) à condition de désactiver dans ton UEFI les fonctions RAID de ta carte - en FakeRAID (pseudo-matériel)(via dmraid) à condition d'activer dans ton UEFI les fonctions RAID de ta carte le wiki d'Archlinux est assez bien documenté sur le RAID, je pense que la majorité du contenu de cette page est transposable sans grosse différence: https://wiki.archlinux.org/title/RAID Encore une fois, ne pas prendre ce que je dis pour argent comptant et se faire sa propre opinion argumentée: j'y connais rien :-)
Re: pilote nvidia propriétaire et noyau 6.3
Il y a un rapport de bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038004
