Re: souci imprimante usb (fdisk -l , hddtemp )

[Pascal Hambourg]

Le 19/12/2018 à 07:03, steve a écrit :

Le 17-12-2018, à 21:34:02 +0100, Pascal Hambourg a écrit :

Certains périphériques comme les lecteurs de carte mémoire peuvent 
aussi être nommés /dev/sd*. Ou un problème lors de l'initialisation 
d'un disque peut le faire détecter plusieurs fois, avec un nom 
différent chaque fois.


Oui, tout à fait d'accord. Mais comme il ne parlait que d'un seul disque
(sans préciser l'existence d'autres types de cartes mémoire), je ne
voyais pas vraiment comment c'était possible.


Pas besoin qu'une carte mémoire soit insérée, il suffit que le lecteur 
soit présent, comme les lecteurs intégrés aux ordinateurs connectés via 
un port USB interne.

Re: souci imprimante usb (fdisk -l , hddtemp )

[steve]

Le 17-12-2018, à 21:34:02 +0100, Pascal Hambourg a écrit :


Le 17/12/2018 à 15:47, steve a écrit :

Le 17-12-2018, à 15:01:42 +0100, infos SX a écrit :


Lorsque je fais un reboot, une fois sur deux il devient /dev/sdc
et l'autre fois, /dev/sda.


Difficile de croire que ça soit possible vu qu'il n'y a qu'un seul
disque.


Certains périphériques comme les lecteurs de carte mémoire peuvent 
aussi être nommés /dev/sd*. Ou un problème lors de l'initialisation 
d'un disque peut le faire détecter plusieurs fois, avec un nom 
différent chaque fois.



Oui, tout à fait d'accord. Mais comme il ne parlait que d'un seul disque
(sans préciser l'existence d'autres types de cartes mémoire), je ne
voyais pas vraiment comment c'était possible.

Re: souci imprimante usb (fdisk -l , hddtemp )

[steve]

Le 17-12-2018, à 21:53:19 +0100, Pascal Hambourg a écrit :


Le 17/12/2018 à 17:25, steve a écrit :

Le 17-12-2018, à 17:16:35 +0100, ajh-valmer a écrit :


/dev/disk# ls -l by-label/
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda1 -> ../../sda1
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda2 -> ../../sda2
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda5 -> ../../sda5
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda6 -> ../../sda6
lrwxrwxrwx 1 root root 10 déc.  15 00:45 sda7 -> ../../sda7
lrwxrwxrwx 1 root root 10 déc.  15 00:45 swap -> ../../sda3


C'est une très mauvaise idée de donner des noms de périphériques non 
persistants comme étiquettes de système de fichiers. Quand ça ne se 
passe pas comme tu veux, l'étiquette "sda1" se retrouve sur /dev/sdc1. 
Pas génial pour la clarté. Une étiquette devrait être représentative 
du contenu, pas de la position du contenant. Comme le titre d'un livre 
: aurait-on l'idée de nommer un livre à partir de sa position sur 
l'étagère et de la position de l'étagère dans la bibliothèque ?


Tout à fait d'accord. J'ai fait un mauvais copié-collé dans ce message.

Correct est:

$ pwd
/dev/disk/by-label
$ ll -l
total 0
lrwxrwxrwx 1 root root 10 déc 14 21:40 BOOT -> ../../sda1
lrwxrwxrwx 1 root root  9 déc 14 21:40 HOME -> ../../md1
lrwxrwxrwx 1 root root 10 déc 14 21:40 RACINE -> ../../sda5
lrwxrwxrwx 1 root root 10 déc 14 21:40 TMP -> ../../sda7
lrwxrwxrwx 1 root root 10 déc 14 21:40 USR -> ../../sda6
lrwxrwxrwx 1 root root  9 déc 14 21:40 VAR -> ../../md0



D'accord, l'UUID ne change pas, donc pas bien grave,
ça n'empêche pas le système de bien fonctionner,
mais je préférerais que le DD = /dev/sda et s'y tienne.


Pas sûr que ça soit possible, mais clairement non recommendable.
Peut-être qu'avec une règle udev tu pourrais y parvenir.


Non, pas possible. On ne peut renommer que les interfaces réseau. Si 
les labels et UUID ne conviennent pas, au mieux on peut créer des 
liens symboliques (alias) persistants qui pointent vers les noms de 
périphériques canoniques. C'est ce que fait implicitement LVM avec les 
noms de volumes logiques.


Merci pour la précision.

Re: k3b refuse le wav

[F. Dubois]

Le 18/12/2018 à 10:42, Stephane Ascoet a écrit :
Bonjour, vive le progres... dire que le Super Audio CD a ete invente 
il y a vingt ans pour qu'on ne tombe pas dans ce genre d'absurdite...


Et sinon tout ce fil est assez HS :-/


Bonsoir, le sujet est peut-être selon vous HS, pour ma part j'ai un 
souci avec k3b utilisé "dans" debian qui refuse un fichier wav qui par 
ailleurs fonctionne très bien, donc je ne suis pas si HS que cela il me 
semble. D'ailleurs il n'est à aucun moment fait mention de SACD puisque 
j'ai obtenu ces wav depuis le fabricant du vinyle, donc votre remarque 
pourrait aussi paraître HS.


J'ai eu ma réponse de toute façon, bonne soirée à vous.

Fabien

Re: Problème carte réseau sur serveur dédié

[Yahoo]

Bonjour,

je n'avais pas encore vue cette erreur, mais en modifiant le gso 
(generic-segmentation-offload) gro (generic-receive-offload) et tso 
(tcp-segmentation-offload:),


tu n'as pas touché a (ufo) udp-fragmentation-offload settings

Tu peux quand même vérifier si les options sont bien à off avec ethtool 
-K  .


Sinon, pour info, mais c'est sûrement déjà fait, il faut bien inscrire 
les modifications au démarrage du serveur, sinon les modifications 
seront perdus après "reboot",


pour ma part je les ajoute en post-up dans le fichiers des interfaces.

Tiens nous au courant si cela à fonctionné.

Loïc

Le 18/12/2018 à 10:26, JUPIN Alain a écrit :

Bonjour,

Merci pour le retour, j'avais effectivement lu sur des forums la même 
chose (chez un autre hébergeur).

Et en effet, les gro et gso sont gérés par la carte NIC
Features for eno1:
Cannot get device udp-fragmentation-offload settings: Operation not 
supported

tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

L'opération a été effectuée cette nuit, je vais voir si cela est 
efficace ou pas dans le temps (çà plantait ou bout de 2 ou 3 jours) !
Pour info, j'ai quand même eu le retour suivant à la commande ethtool 
-K eno1 gso off gro off tso off
Cannot get device udp-fragmentation-offload settings: Operation not 
supported
Cannot get device udp-fragmentation-offload settings: Operation not 
supported


Alain JUPIN

Le 17/12/2018 à 16:42, Yahoo a écrit :


Bonjour,

Il semble que la carte réseau à du mal à gérer la segmentation des 
paquets,


dans ce cas là, il peux être bien de décharger cette opération au CPU.

d'après les logs ton serveur hébergé, tu est sur une carte NIC intel 
(e1000e), qui as du mal a décharger.


Vérifie si ta carte NIC gère le déchargement de la segmentation de 
paquets :


/ethtool -k /

pour le savoir vérifier les ligne (gso et gro) :

/tcp-segmentation-offload: on
/

/generic-segmentation-offload: on
generic-receive-offload: on/

si elles sont à on c'est que c'est la carte NIC qui le gére,

essaye de les passer à off pour que ce soit le CPU qui le gérent

|ethtool -K  gso off gro off tso off|

(attention cela peux engendre une perte de connexion, à faire en KVM)

J'ai dèjà eu le soucis sur des serveurs, mais avec l'utilisation de QoS.

En espérant pouvoir aider

Loïc

Le 17/12/2018 à 14:26, JUPIN Alain a écrit :

Bonjour,

Sur un serveur dédié chez OVH, sous Debian 9.4 qui fait tourner 
Proxmox 5.2-5 qui héberge 4 VM (toutes sous Linux aussi).
Régulièrement (au bout de quelques jours), le serveur plante, plus 
de réponse au ping sur l'IP principale du serveur, d'où le 
déclenchement d'un reset "Hard".


Évidemment j'essaye de trouver la cause de ce plantage.
Je n'ai rien trouvé du coté du disque dur (via smartctl).

Mais j'ai ceci dans le log "syslog". Lors du plantage, cette 
séquence a débuté à 10h57 (heure du serveur qui est en UTC), à 11h03 
j'ai perdu le ping, elle a perdurée jusqu'à 11h08, heure du reboot 
par OVH.


Dec 17 11:02:33 cygnus kernel: [408638.686407] e1000e :00:19.0 
eno1: Detected Hardware Unit Hang:

Dec 17 11:02:33 cygnus kernel: [408638.686407] TDH  <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] TDT  <2>
Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_use  <2>
Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_clean    <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] 
buffer_info[next_to_clean]:
Dec 17 11:02:33 cygnus kernel: [408638.686407] time_stamp   
<10615a7a6>

Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_watch    <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] jiffies  
<10615b058>

Dec 17 11:02:33 cygnus kernel: [408638.686407] next_to_watch.status <0>
Dec 17 11:02:33 cygnus kernel: [408638.686407] MAC 
Status <40080083>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY 
Status <796d>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY 1000BASE-T 
Status  <3800>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Extended 
Status    <3000>
Dec 17 11:02:33 cygnus kernel: [408638.686407] PCI 
Status <10>

Dec 17 11:02:33 cygnus systemd-networkd[924]: eno1: Lost carrier
Dec 17 11:02:33 cygnus kernel: [408638.849717] e1000e :00:19.0 
eno1: Reset adapter unexpectedly
Dec 17 11:02:33 cygnus kernel: [408638.849756] vmbr0: port 1(eno1) 
entered disabled state

Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: Gained carrier
Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: could not set 
address: Permission denied
Dec 17 11:02:37 cygnus kernel: [408642.507741] e1000e: eno1 NIC Link 
is Up 1000 Mbps Full Duplex, Flow Control: None
Dec 17 11:02:37 cygnus kernel: [408642.507786] vmbr0: port 1(eno1) 
entered blocking state
Dec 17 11:02:37 cygnus kernel: [408642.507791] vmbr0: port 1(eno1) 
entered forwarding state


Par contre, bien que je sois en train d'investiguer, j'ai bien 
compris qu'un problème ce produit sur 

Re: k3b refuse le wav

[Stephane Ascoet]

Le 15/12/2018 à 12:01, F. Dubois a écrit :

Bonjour, suite à l'achat d'un vinyle j'ai téléchargé sur le site de
mcommusique.com la version digitale pour graver un CD audio. J'ai en ma
possession deux fichiers wav estampillés master, un par face.


Bonjour, vive le progres... dire que le Super Audio CD a ete invente il 
y a vingt ans pour qu'on ne tombe pas dans ce genre d'absurdite...


Et sinon tout ce fil est assez HS :-/
--
Cordialement, Stephane Ascoet

Re: Problème carte réseau sur serveur dédié

[JUPIN Alain]

Bonjour,

Merci pour le retour, j'avais effectivement lu sur des forums la même
chose (chez un autre hébergeur).
Et en effet, les gro et gso sont gérés par la carte NIC
Features for eno1:
Cannot get device udp-fragmentation-offload settings: Operation not
supported
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

L'opération a été effectuée cette nuit, je vais voir si cela est
efficace ou pas dans le temps (çà plantait ou bout de 2 ou 3 jours) !
Pour info, j'ai quand même eu le retour suivant à la commande  ethtool
-K eno1 gso off gro off tso off
Cannot get device udp-fragmentation-offload settings: Operation not
supported
Cannot get device udp-fragmentation-offload settings: Operation not
supported

Alain JUPIN

Le 17/12/2018 à 16:42, Yahoo a écrit :
>
> Bonjour,
>
> Il semble que la carte réseau à du mal à gérer la segmentation des
> paquets,
>
> dans ce cas là, il peux être bien de décharger cette opération au CPU.
>
> d'après les logs ton serveur hébergé, tu est sur une carte NIC intel
> (e1000e), qui as du mal a décharger.
>
> Vérifie si ta carte NIC gère le déchargement de la segmentation de
> paquets :
>
> /ethtool -k /
>
> pour le savoir vérifier les ligne (gso et gro) :
>
> /tcp-segmentation-offload: on
> /
>
> /generic-segmentation-offload: on
> generic-receive-offload: on/
>
> si elles sont à on c'est que c'est la carte NIC qui le gére,
>
> essaye de les passer à off pour que ce soit le CPU qui le gérent
>
> |ethtool -K  gso off gro off tso off|
>
> (attention cela peux engendre une perte de connexion, à faire en KVM)
>
> J'ai dèjà eu le soucis sur des serveurs, mais avec l'utilisation de QoS.
>
> En espérant pouvoir aider
>
> Loïc
>
> Le 17/12/2018 à 14:26, JUPIN Alain a écrit :
>> Bonjour,
>>
>> Sur un serveur dédié chez OVH, sous Debian 9.4 qui fait tourner
>> Proxmox 5.2-5 qui héberge 4 VM (toutes sous Linux aussi).
>> Régulièrement (au bout de quelques jours), le serveur plante, plus de
>> réponse au ping sur l'IP principale du serveur, d'où le déclenchement
>> d'un reset "Hard".
>>
>> Évidemment j'essaye de trouver la cause de ce plantage.
>> Je n'ai rien trouvé du coté du disque dur (via smartctl).
>>
>> Mais j'ai ceci dans le log "syslog". Lors du plantage, cette séquence
>> a débuté à 10h57 (heure du serveur qui est en UTC), à 11h03 j'ai
>> perdu le ping, elle a perdurée jusqu'à 11h08, heure du reboot par OVH.
>>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] e1000e :00:19.0
>> eno1: Detected Hardware Unit Hang:
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   TDH  <0>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   TDT  <2>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_use  <2>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_clean    <0>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]
>> buffer_info[next_to_clean]:
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   time_stamp  
>> <10615a7a6>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_watch    <0>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   jiffies 
>> <10615b058>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407]   next_to_watch.status <0>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] MAC Status
>> <40080083>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Status
>> <796d>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY 1000BASE-T Status 
>> <3800>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] PHY Extended Status   
>> <3000>
>> Dec 17 11:02:33 cygnus kernel: [408638.686407] PCI Status
>> <10>
>> Dec 17 11:02:33 cygnus systemd-networkd[924]: eno1: Lost carrier
>> Dec 17 11:02:33 cygnus kernel: [408638.849717] e1000e :00:19.0
>> eno1: Reset adapter unexpectedly
>> Dec 17 11:02:33 cygnus kernel: [408638.849756] vmbr0: port 1(eno1)
>> entered disabled state
>> Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: Gained carrier
>> Dec 17 11:02:37 cygnus systemd-networkd[924]: eno1: could not set
>> address: Permission denied
>> Dec 17 11:02:37 cygnus kernel: [408642.507741] e1000e: eno1 NIC Link
>> is Up 1000 Mbps Full Duplex, Flow Control: None
>> Dec 17 11:02:37 cygnus kernel: [408642.507786] vmbr0: port 1(eno1)
>> entered blocking state
>> Dec 17 11:02:37 cygnus kernel: [408642.507791] vmbr0: port 1(eno1)
>> entered forwarding state
>>
>> Par contre, bien que je sois en train d'investiguer, j'ai bien
>> compris qu'un problème ce produit sur l'interface Ethernet, mais je
>> ne sais pas quoi précisément.
>> Avez vous une idée sur ce qui peut être à l'origine de ceci ?
>>
>> PS : J'attends aussi une réponse d'OVH sur la question.
>>
>> -- 
>> Alain JUPIN
>> Lumières d'Ici ... et d'Ailleurs