Re: Pb routage NAT suite update/reboot

[François TOURDE]

Le 19782ième jour après Epoch,
Erwann Le Bras écrivait:

> Je ne comprends pas comment ça fonctionnait avant, j'en déduis que
> cette config n'était pas active.

C'est probablement lié à la valeur de "metric", ton ancienne freebox ne
la mettait pas en place, alors que la nouvelle oui, donc la route étant
choisie avec comme objectif la métrique la plus petite, ça a pû marcher
avant, mais plus maintenant ;)

Re: Pb routage NAT suite update/reboot

[Erwann Le Bras]

bonsoir

Merci à vous deux pour le debug ; le pb venait bien de la passerelle 
déclarée au niveau eth0.


Je ne comprends pas comment ça fonctionnait avant, j'en déduis que cette 
config n'était pas active.


amitiés

Le 26/02/2024 à 18:11, Erwann Le Bras a écrit :


bonsoir la team!

j'ai un serveur Debian (version stable) qui sert de passerelle entre 
mon réseau interne et l'extérieur. Il est en route en permanence et 
s'installe les mises à jour de sécurité, sans rebooter.


  * eth0 est l'interface interne, IP statique.
  * eth1 est l'interface externe,connectée à une Freebox qui lui donne
l'IP.
  * tun0 est l'interface VPN

Sur la Freebox, une DMZ redirige les flux entrants vers mon serveur 
pour ouvrir mon serveur sur l'extérieur (SSH, WEB, VPN...).


IPTable fait le tri en entrée et assure le routage des paquets à 
l'extérieur et Fail2ban bannit les indésirables.


Tout cela fonctionne depuis plusieurs années sans pb malgré les 
changements d'opérateur et de version Debian.



Récemment, une maintenance matérielle (upgrade RAM) m'a contraint à le 
redémarrer après qq mois sans histoire.


Au démarrage, rien ne va plus : extérieur difficilement joignable, NAT 
inopérant, DMZ HS (services non joignables depuis l'extérieur).


Inversement, le serveur n'a plus accès à internet (ping HS)

J'ai pensé à une régression du au noyau, un redémarrage  en version 
6.1.0-15 n'a rien donné.


uname -a
Linux quietty 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 
(2024-02-01) x86_64 GNU/Linux



J'ai trouvé des IP martiennes dans la syslog, je ne sais pas si c'est 
lié :


2024-02-26T16:51:24.146290+01:00 quietty kernel: [ 1180.427493] IPv4: 
martian source *192.168.1.1* from 45.155.91.29, on dev *eth1*
2024-02-26T16:51:24.146322+01:00 quietty kernel: [ 1180.427508] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:33.478276+01:00 quietty kernel: [ 1189.762277] IPv4: 
martian source *192.168.1.1* from 43.133.145.230, on dev *eth1*
2024-02-26T16:51:33.478309+01:00 quietty kernel: [ 1189.762292] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:36.742277+01:00 quietty kernel: [ 1193.025728] IPv4: 
martian source 1*92.168.1.1* from 179.105.36.19, on dev *eth1*
2024-02-26T16:51:36.742306+01:00 quietty kernel: [ 1193.025742] ll 
header: : *8e a8 a4 c7 35 98 *70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:49.210275+01:00 quietty kernel: [ 1205.495322] IPv4: 
martian source *192.168.1.1* from 91.148.190.174, on dev *eth1*
2024-02-26T16:51:49.210305+01:00 quietty kernel: [ 1205.495335] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:58.990298+01:00 quietty kernel: [ 1215.272829] IPv4: 
martian source *192.168.1.1* from 176.111.174.29, on dev *eth1*
2024-02-26T16:51:58.990328+01:00 quietty kernel: [ 1215.272841] ll 
header: : *8e a8 a4 c7 35 9*8 70 fc 8f 5e 60 da 08 00


Je n'avais pas ça avant. Une recherche sur Internet ne m'a pas 
vraiment aidé.



Quelques éléments techniques :

* ip addr :*
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc fq_codel 
state UNKNOWN group default qlen 1000

    link/ether 00:50:bf:d8:b9:1f brd ff:ff:ff:ff:ff:ff
    altname enp5s3
    inet 192.168.2.1/24 brd 192.168.2.255 scope global eth0
   valid_lft forever preferred_lft forever
3: *eth1*:  mtu 1500 qdisc fq_codel 
state UP group default qlen 1000

    link/ether *8e:a8:a4:c7:35:98* brd ff:ff:ff:ff:ff:ff




    altname enp2s0
    inet *192.168.1.1*/24 metric 1024 brd 192.168.1.255 scope global 
dynamic eth1

   valid_lft 42186sec preferred_lft 42186sec
4: tun0:  mtu 1500 qdisc 
fq_codel state UNKNOWN group default qlen 500

    link/none
    inet 192.168.3.1/24 scope global tun0
   valid_lft forever preferred_lft forever


*configuration des interfaces :*

/etc/systemd/network/eth0.network
[Match]
Name=eth0
#MACAddress=Adresse MAC de l'interface

[Link]
#MACAddress=Changer l'adresse MAC
#MTUBytes=Changer la valeur du MTU

[Network]
Address=192.168.2.1/24
Gateway=192.168.2.1
DNS=192.168.2.1 127.0.0.1
Domains=vets.in
IPv6PrivacyExtensions=false


/etc/systemd/network/eth1.network

[Match]
Name=*eth1*

[Network]
DHCP=*ipv4*

*ip route*
default via 192.168.2.1 dev eth0 proto static
default via 192.168.1.254 dev eth1 proto dhcp src 192.168.1.1 metric 1024
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 metric 
1024

192.168.1.1 dev eth1 proto dhcp scope host src 192.168.1.1 metric 1024
192.168.1.254 dev eth1 proto dhcp scope link src 192.168.1.1 metric 1024
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.1
192.168.3.0/24 dev tun0 proto kernel scope link src 192.168.3.1

(192.168.1.254 : Freebox)


*iptables -L -v*
Chain INPUT (policy DROP 582 packets, 64731 bytes)
 pkts bytes target prot 

Re: Pb routage NAT suite update/reboot

[François TOURDE]

Bonjour,

Le 19779ième jour après Epoch,
Erwann Le Bras écrivait:

[...]
>  * eth0 est l'interface interne, IP statique.
>  * eth1 est l'interface externe,connectée à une Freebox qui lui donne l'IP.
>  * tun0 est l'interface VPN
[...]

> * ip addr :*
> 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>    valid_lft forever preferred_lft forever
> 2: eth0:  mtu 1500 qdisc fq_codel
> state UNKNOWN group default qlen 1000
>     link/ether 00:50:bf:d8:b9:1f brd ff:ff:ff:ff:ff:ff
>     altname enp5s3
>     inet 192.168.2.1/24 brd 192.168.2.255 scope global eth0
>    valid_lft forever preferred_lft forever
> 3: *eth1*:  mtu 1500 qdisc fq_codel
> state UP group default qlen 1000
>     link/ether *8e:a8:a4:c7:35:98* brd ff:ff:ff:ff:ff:ff
>     altname enp2s0
>     inet *192.168.1.1*/24 metric 1024 brd 192.168.1.255 scope global
> dynamic eth1
>    valid_lft 42186sec preferred_lft 42186sec
> 4: tun0:  mtu 1500 qdisc
> fq_codel state UNKNOWN group default qlen 500
>     link/none
>     inet 192.168.3.1/24 scope global tun0
>    valid_lft forever preferred_lft forever
>

Jusque là, rien de choquant :)

> /etc/systemd/network/eth0.network
> [Match]
> Name=eth0
> #MACAddress=Adresse MAC de l'interface
>
> [Link]
> #MACAddress=Changer l'adresse MAC
> #MTUBytes=Changer la valeur du MTU
>
> [Network]
> Address=192.168.2.1/24
> Gateway=192.168.2.1

Aïe ... Je pense que tu peux enlever 'Gateway' là, c'est probablement
pour ça que tu as des soucis. Explications plus bas.

[...]
> *ip route*
> default via 192.168.2.1 dev eth0 proto static
> default via 192.168.1.254 dev eth1 proto dhcp src 192.168.1.1 metric
> 1024

Voilà, tu as deux routes par défaut, la première (et probablement
prioritaire) ne vas pas vers ta box, donc l'accès internet n'est pas
opérationnel dans ce cas.

> 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 metric 1024
[...]
> 192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.1
> 192.168.3.0/24 dev tun0 proto kernel scope link src 192.168.3.1

Ces 3 infos dans le routage sont suffisantes pour router l'interne vers
eth0, le VPN vers tun0 et le réseau de la box par eth1.

C'est aussi probablement pourquoi tu as des IP martiennes (du
192.168.1.x qui essaye de sortir par eth0 à cause de la directive
gateway).

Mes 2¢

-- 
A gift of a flower will soon be made to you.

Re: Pb routage NAT suite update/reboot

[NoSpam]

Bonsoir


Le 26/02/2024 à 18:11, Erwann Le Bras a écrit :
[...]


*ip route*
default via 192.168.2.1 dev eth0 proto static
default via 192.168.1.254 dev eth1 proto dhcp src 192.168.1.1 metric 1024
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 metric 
1024

192.168.1.1 dev eth1 proto dhcp scope host src 192.168.1.1 metric 1024
192.168.1.254 dev eth1 proto dhcp scope link src 192.168.1.1 metric 1024
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.1
192.168.3.0/24 dev tun0 proto kernel scope link src 192.168.3.1

(192.168.1.254 : Freebox)


2 routes par défaut est une erreur. Supprime la première

Une fois réalisé, un ping vers la Frebox est OK ?


[...]

Les services fonctionnent bien, j'y ai accès depuis le réseau de la 
Freebox (192.168.1.0) mais pas depuis l'adresse externe (qui n'a pas 
changé).


Donc un ping depuis la Freebox vers le réseau 192.168.2.0 est 
fonctionnel ? As tu rajouté une route pour que cela fonctionne car de 
mémoire la route par défaut doit être l'interface WAN de la FB ?



J'exclus un dysfonctionnement de la Freebox, elle vient d'être changé.

De ce que tu écris, la Freebox est en mode routeur. Si elle a été 
remplacée, vérifie dans ses réglages que les règles auxquelles tu 
t'attends soient encore en place et que la topologie est bien celle que 
tu veux.

[...]

Pb routage NAT suite update/reboot

[Erwann Le Bras]

bonsoir la team!

j'ai un serveur Debian (version stable) qui sert de passerelle entre mon 
réseau interne et l'extérieur. Il est en route en permanence et 
s'installe les mises à jour de sécurité, sans rebooter.


 * eth0 est l'interface interne, IP statique.
 * eth1 est l'interface externe,connectée à une Freebox qui lui donne l'IP.
 * tun0 est l'interface VPN

Sur la Freebox, une DMZ redirige les flux entrants vers mon serveur pour 
ouvrir mon serveur sur l'extérieur (SSH, WEB, VPN...).


IPTable fait le tri en entrée et assure le routage des paquets à 
l'extérieur et Fail2ban bannit les indésirables.


Tout cela fonctionne depuis plusieurs années sans pb malgré les 
changements d'opérateur et de version Debian.



Récemment, une maintenance matérielle (upgrade RAM) m'a contraint à le 
redémarrer après qq mois sans histoire.


Au démarrage, rien ne va plus : extérieur difficilement joignable, NAT 
inopérant, DMZ HS (services non joignables depuis l'extérieur).


Inversement, le serveur n'a plus accès à internet (ping HS)

J'ai pensé à une régression du au noyau, un redémarrage  en version 
6.1.0-15 n'a rien donné.


uname -a
Linux quietty 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 
(2024-02-01) x86_64 GNU/Linux



J'ai trouvé des IP martiennes dans la syslog, je ne sais pas si c'est lié :

2024-02-26T16:51:24.146290+01:00 quietty kernel: [ 1180.427493] IPv4: 
martian source *192.168.1.1* from 45.155.91.29, on dev *eth1*
2024-02-26T16:51:24.146322+01:00 quietty kernel: [ 1180.427508] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:33.478276+01:00 quietty kernel: [ 1189.762277] IPv4: 
martian source *192.168.1.1* from 43.133.145.230, on dev *eth1*
2024-02-26T16:51:33.478309+01:00 quietty kernel: [ 1189.762292] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:36.742277+01:00 quietty kernel: [ 1193.025728] IPv4: 
martian source 1*92.168.1.1* from 179.105.36.19, on dev *eth1*
2024-02-26T16:51:36.742306+01:00 quietty kernel: [ 1193.025742] ll 
header: : *8e a8 a4 c7 35 98 *70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:49.210275+01:00 quietty kernel: [ 1205.495322] IPv4: 
martian source *192.168.1.1* from 91.148.190.174, on dev *eth1*
2024-02-26T16:51:49.210305+01:00 quietty kernel: [ 1205.495335] ll 
header: : *8e a8 a4 c7 35 98* 70 fc 8f 5e 60 da 08 00
2024-02-26T16:51:58.990298+01:00 quietty kernel: [ 1215.272829] IPv4: 
martian source *192.168.1.1* from 176.111.174.29, on dev *eth1*
2024-02-26T16:51:58.990328+01:00 quietty kernel: [ 1215.272841] ll 
header: : *8e a8 a4 c7 35 9*8 70 fc 8f 5e 60 da 08 00


Je n'avais pas ça avant. Une recherche sur Internet ne m'a pas vraiment 
aidé.



Quelques éléments techniques :

* ip addr :*
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN 
group default qlen 1000

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc fq_codel state 
UNKNOWN group default qlen 1000

    link/ether 00:50:bf:d8:b9:1f brd ff:ff:ff:ff:ff:ff
    altname enp5s3
    inet 192.168.2.1/24 brd 192.168.2.255 scope global eth0
   valid_lft forever preferred_lft forever
3: *eth1*:  mtu 1500 qdisc fq_codel 
state UP group default qlen 1000

    link/ether *8e:a8:a4:c7:35:98* brd ff:ff:ff:ff:ff:ff
    altname enp2s0
    inet *192.168.1.1*/24 metric 1024 brd 192.168.1.255 scope global 
dynamic eth1

   valid_lft 42186sec preferred_lft 42186sec
4: tun0:  mtu 1500 qdisc 
fq_codel state UNKNOWN group default qlen 500

    link/none
    inet 192.168.3.1/24 scope global tun0
   valid_lft forever preferred_lft forever


*configuration des interfaces :*

/etc/systemd/network/eth0.network
[Match]
Name=eth0
#MACAddress=Adresse MAC de l'interface

[Link]
#MACAddress=Changer l'adresse MAC
#MTUBytes=Changer la valeur du MTU

[Network]
Address=192.168.2.1/24
Gateway=192.168.2.1
DNS=192.168.2.1 127.0.0.1
Domains=vets.in
IPv6PrivacyExtensions=false


/etc/systemd/network/eth1.network

[Match]
Name=*eth1*

[Network]
DHCP=*ipv4*

*ip route*
default via 192.168.2.1 dev eth0 proto static
default via 192.168.1.254 dev eth1 proto dhcp src 192.168.1.1 metric 1024
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.1 metric 1024
192.168.1.1 dev eth1 proto dhcp scope host src 192.168.1.1 metric 1024
192.168.1.254 dev eth1 proto dhcp scope link src 192.168.1.1 metric 1024
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.1
192.168.3.0/24 dev tun0 proto kernel scope link src 192.168.3.1

(192.168.1.254 : Freebox)


*iptables -L -v*
Chain INPUT (policy DROP 582 packets, 64731 bytes)
 pkts bytes target prot opt in out source   
destination

30176 2346K ACCEPT all  --  lo any anywhere anywhere
 3225  522K ACCEPT all  --  eth0   any anywhere anywhere
 820K 1189M ACCEPT all  --  any    any anywhere 
anywhere 

Re: Migration Bullseye vers Bookworm : échec lors du reboot

[ajh-valmer]

On Thursday 13 July 2023 08:54:54 Sébastien NOBILI wrote:
> Le 2023-07-13 01:03, Jean-Michel OLTRA a écrit :
> > Regarder les logs /var/log/Xorg.0.log ?
> > Vérifier que la version de Trinity est correcte pour Bookworm ?
> En plus de tout ça, vérifier si ça démarre avec un des bureaux fournis
> par Debian (Gnome par exemple).

J'ai résolu les problèmes lors du boot,exceptée la carte graphique,
qui maintenant n'est plus reconnue par bookworm, noyau 6.10.
Avec le noyau 5.22, ça marche mais sans souris ni clavier.

Quasi à chaque nouvelle version de Debian, le X graphique ne fonctionne plus.
Je dois souvent racheter une autre carte vidéo...
"nvidia-detect" a répondu que le pilote à installer 
est "nvidia-driver-370-tesla",
mais niet, refusé par le système au reboot.

Je cherche la méthode didactique avec "xserver-org-nouveau",
merci.

A. Valmer

Re: Migration Bullseye vers Bookworm : échec lors du reboot

[Sébastien NOBILI]

Bonjour,

Le 2023-07-13 01:03, Jean-Michel OLTRA a écrit :

Regarder les logs /var/log/Xorg.0.log ?
Vérifier que la version de Trinity est correcte pour Bookworm ?
https://wiki.trinitydesktop.org/Debian_Trinity_Repository_Installation_Instructions
Lancer un `startx` à la main pour voir ce que ça raconte ?


En plus de tout ça, vérifier si ça démarre avec un des bureaux fournis
par Debian (Gnome par exemple).

Sébastien

Re: Migration Bullseye vers Bookworm : échec lors du reboot

[Jean-Michel OLTRA]

Bonjour,


Le jeudi 13 juillet 2023, ajh-valmer a écrit...


> Au reboot de la migration, je me retrouve sur une
> page graphique inconnue, ingérable, même pas
> possible de rebooter ou éteindre l'ordinateur.
> Seul CTRL-ALT-F2 permet de passer en mode single,
> pas en tapant ctrl-alt-f1.
> Mon bureau est TDE-Trinity qui n'apparait donc pas.
> Comment avoir le boot graphique trinity sur ce bureau ? :
> je ne vois pas comment faire pour sortir de cette ornière...
> Pourtant la migration s'est passée sans aucun incident.
> 
> Merci d'une aide, d'une piste.

Regarder les logs /var/log/Xorg.0.log ?
Vérifier que la version de Trinity est correcte pour Bookworm ?
https://wiki.trinitydesktop.org/Debian_Trinity_Repository_Installation_Instructions
Lancer un `startx` à la main pour voir ce que ça raconte ?

-- 
jm

Migration Bullseye vers Bookworm : échec lors du reboot

[ajh-valmer]

Bonsoir,

J'ai bien fait de garder bullseye sur ma sauvegarde.

Au reboot de la migration, je me retrouve sur une
page graphique inconnue, ingérable, même pas
possible de rebooter ou éteindre l'ordinateur.
Seul CTRL-ALT-F2 permet de passer en mode single,
pas en tapant ctrl-alt-f1.
Mon bureau est TDE-Trinity qui n'apparait donc pas.
Comment avoir le boot graphique trinity sur ce bureau ? :
je ne vois pas comment faire pour sortir de cette ornière...
Pourtant la migration s'est passée sans aucun incident.

Merci d'une aide, d'une piste.
Bonne nuit.

A. Valmer

Re: kexec : reboot bluffant

[andre_debian]

On Tuesday 12 June 2018 18:12:57 Damien Berry wrote:
> # 
kexec -l /boot/vmlinuz-$(uname -r) --initrd=/boot/initrd.img-$(uname -r) 
--reuse-cmdline
> # kexec -e

Je viens de tester :
#kexec -l /boot/vmlinuz-$(uname -r) --initrd=/boot/initrd.img-$(uname -r) 
--reuse-cmdline
puis
# kexec -e

Et plantage total, plus de clavier, ni souris, hard reboot...

André

Re: Reboot électrique distant

[Marc Jean]

Il existe des boitiers de télécommande de chauffage, qui se branchent 
entre la prise murale et le cordon de ton appareil, qui fonctionnent 
avec une carte SIM (faut un abonnement minimum, genre à 2€ par mois). 
Certains peuvent avoir un ou deux adaptateurs satellites.


On envoie un code de commande par sms. J'en ai un qui envoie un sms en 
cas de coupure de courant. En prime j'ai en retour température ambiante.


Si ton bios est paramétré pour que l'ordinateur démarre au retour du 
courant, ça permet le hard reboot brutal.


Aucune programmation nécessaire.

Le 07/05/2018 à 23:15, kaliderus a écrit :

Je cherche une solution pour rebooter électriquement (comme dans
l'ancien temps) quelques équipements à distance (une box et 2 ou 3
autres bricoles).

Re: Reboot électrique distant

[Daniel Huhardeaux]

Le 07/05/2018 à 23:15, kaliderus a écrit :

Bonsoir,
Bonjour,


Bonjour



Je cherche une solution pour rebooter électriquement (comme dans
l'ancien temps) quelques équipements à distance (une box et 2 ou 3
autres bricoles).

Avec ceci par exemple ?
https://support.usr.com/products/remotemanagement/console-server-product.asp?sku=USR4204#

Mais avec ce truc (je ne sais même pas comment l'appeler en Français),
est-ce que je vais pouvoir établir une communication analogique (comme
dans l'ancien temps) avec le modem qui lui sera collé au derrière,
sachant que je suis avec Free en dégroupé.

Ou un switch administrable, et dans ce cas, je suis tributaire de la
présence d'un réseau ip bien accessible et adéquatement configuré.

Je me tâte, si vous avez d'autres
pistes/conseils/tuyaux/infos/idées/ou/que/sais/je j'en serai
heureux...

Il existe des boitiers de reboot à distance via carte SIM. Les ordres 
sont transmis via SMS. Attention: tous les opérateurs grand public 
n'autorisent pas l'usage de leurs cartes à de telles fins.


--
Daniel

Re: Reboot électrique distant

[Yann Serre]

Le 08/05/2018 à 12:24, chris navas a écrit :

Bonjour,

y a très longtemps j'utiliser la detection de sonnerie pour piloter un 
relais j'ai plus le montage

mais un truc du genre pourrait tres bien faire l'affaire

http://www.sonelec-musique.com/electronique_realisations_ligne_tel_detection_sonnerie.html
et/ou
http://www.sonelec-musique.com/electronique_realisations_ligne_tel_repetiteur_sonnerie_001.html

Belle journée,
Chris.


Avec quand-même quelques conditions :
- avoir une ligne analogique :)
- avoir un dispositif qui est capable de reconnaitre un code (on ne va 
pas rebooter la box + le serveur à chaque appel téléphonique)


Si le code est un nombre de sonneries, ce n'est pas très fiable.
Si le code c'est plusieurs appels successifs avec un nombre de sonneries 
(combinaison), ça devient un peu lourd comme principe !
Si le dispositif implique un décrochage et l'analyse de signaux DTMF, on 
se prive de répondeur et c'est une technique en voie de disparition...


Comme on a une Freebox et qu'on peut déjà la rebooter à distance, on va 
plutôt passer par internet pour rebooter le serveur qui est derrière ?
Parce que si on n'a plus de liaison internet, on a plus besoin de 
rebooter un serveur ;)

Re: Reboot électrique distant

[Yann Serre]

Bonjour

As-tu cherché du côté d'Arduino ?

Le plus simple est de lire une information dans un fichier hébergé sur 
un site web (l'Arduino utilise la box pour lire ce fichier, toutes les 
5mn par exemple)


http://www.devsector.ch/cavimaster/2014/04/prise-230v-commandee-par-internet-arduino-relais/

Le principe est d'envoyer un ordre. Mais sans confirmation de réception 
et de bonne exécution en retour !


Le pilotage le plus rustique est de déposer le fichier contenant l'ordre 
de reboot via ftp, attendre entre 10mn, puis le remplacer par le fichier 
sans ordre de reboot.


L'Arduino, s'il ne trouve pas de fichier (ou s'il trouve le fichier sans 
ordre de reboot) ne fait rien.

Si l'Arduino trouve l'ordre de reboot :
- il actionne son relais (position "arret du courant")
- attend 3 secondes
- replace le relais en position "marche"
- attend 15mn avant de se remettre lire à nouveau le fichier distant 
toutes les 5mn.


Adaptation hardware pour minimiser la consommation : utiliser la broche 
"repos" du relais pour établir le courant et laisser la broche "travail" 
déconnectée.


C'est une des solutions les moins coûteuses.
Comme ce besoin de reboot est rare, le principe d'attendre 10mn ne me 
semble pas pénalisant.


***

Plus coûteux (en énergie électrique aussi -> 1A) serait de faire tourner 
un serveur web sur un Raspberry (Raspbian) et utiliser la redirection de 
port de la Freebox pour accéder à une page de commande depuis l'extérieur.


On se connecte à distance (login/mot de passe/fail2ban).
(http://ip.de.ma.freebox:port/dossier_reboot...)
On commande un relais connecté au Raspberry
(3,3V => transitor => relais).

Dans ce cas on peut aussi ajouter en entrée des capteurs qui permettent 
de vérifier l'état des appareils connectés (détection de courant, 
température,...) et on a donc des informations en retour sur l'état de 
son installation.


***

Bonne journée




Le 07/05/2018 à 23:15, kaliderus a écrit :

Bonsoir,
Bonjour,

Je cherche une solution pour rebooter électriquement (comme dans
l'ancien temps) quelques équipements à distance (une box et 2 ou 3
autres bricoles).

Avec ceci par exemple ?
https://support.usr.com/products/remotemanagement/console-server-product.asp?sku=USR4204#

Mais avec ce truc (je ne sais même pas comment l'appeler en Français),
est-ce que je vais pouvoir établir une communication analogique (comme
dans l'ancien temps) avec le modem qui lui sera collé au derrière,
sachant que je suis avec Free en dégroupé.

Ou un switch administrable, et dans ce cas, je suis tributaire de la
présence d'un réseau ip bien accessible et adéquatement configuré.

Je me tâte, si vous avez d'autres
pistes/conseils/tuyaux/infos/idées/ou/que/sais/je j'en serai
heureux...

Merci.

Reboot électrique distant

[kaliderus]

Bonsoir,
Bonjour,

Je cherche une solution pour rebooter électriquement (comme dans
l'ancien temps) quelques équipements à distance (une box et 2 ou 3
autres bricoles).

Avec ceci par exemple ?
https://support.usr.com/products/remotemanagement/console-server-product.asp?sku=USR4204#

Mais avec ce truc (je ne sais même pas comment l'appeler en Français),
est-ce que je vais pouvoir établir une communication analogique (comme
dans l'ancien temps) avec le modem qui lui sera collé au derrière,
sachant que je suis avec Free en dégroupé.

Ou un switch administrable, et dans ce cas, je suis tributaire de la
présence d'un réseau ip bien accessible et adéquatement configuré.

Je me tâte, si vous avez d'autres
pistes/conseils/tuyaux/infos/idées/ou/que/sais/je j'en serai
heureux...

Merci.

Re: problème avec opendmarc après reboot

[Pierre L.]

Bonjour,

As-tu tenté cette commande, en remplaçant "nom_du_service" par le nom du
service opendmarc, via le compte root :
update-rc.d nom_du_service defaults

Petites infos...
https://manpages.debian.org/stretch/manpages-fr-extra/update-rc.d.8

Si ca peut aider ;)


Le 05/10/2017 à 10:35, bernard.schoenac...@free.fr a écrit :
> comment faire pour pour redémarrer automatiquement ?




signature.asc
Description: OpenPGP digital signature

problème avec opendmarc après reboot

[bernard . schoenacker]

bonjour,

lorsque je redémarre mon serveur opendmarc ne se relance pas ...

comment faire pour pour redémarrer automatiquement ?

apt-cache policy opendmarc
opendmarc:
  Installé : 1.3.2-2
  Candidat : 1.3.2-2
 Table de version :
 *** 1.3.2-2 500
500 http://httpredir.debian.org/debian sid/main amd64 Packages
500 http://httpredir.debian.org/debian buster/main amd64 Packages
500 http://httpredir.debian.org/debian stretch/main amd64 Packages


slt
bernard

Re:[RESOLU] [stretch]Apache2 ne démarre pas après reboot

[Christophe De Natale]

Le 13/04/2017 à 19:20, Thierry Bugier Pineau a écrit :


Bonjour

Bonjour,


/var/log ou /var ne serait pas le point de montage d'un volume 
volatile ? (Genre tmpfs). Il me semble que c'est le genre de conseil 
qu'on donnait (ou donne encore) pour réduire les écritures sur un SSD.
Bien vu mais comment est-ce arrivé là ? Je n'ai jamais eu de ssd dans 
cette machine :D
Enfin si c'est dans mon fstab, c'est bien que je l'ai renseigné à moment 
donné mais pourquoi, je ne me rappelle pas ?


# tmpfs RAM disk
tmpfs /tmp tmpfs defaults,noatime,size=512M 00
tmpfs /var/log tmpfs defaults,noatime,size=256M00

Toujours est-il qu'après suppression de ces deux lignes, une purge et 
une ré-installation de apache, le problème est résolu.


Encore merci et bonne soirée,



Le 13 avril 2017 17:38:50 GMT+02:00, Christophe De Natale 
<christophedenat...@orange.fr> a écrit :


Bonjour à vous,

Sur mon pc de la maison fraîchement upgradé en stretch, je rencontre un
problème avec apache2 qui n'est plus fonctionnel après reboot de la machine.

Les logs ? Et bien ils ne sont pas consultables tout simplement parce
que le répertoire /var/log/apache2 n'existe pas. Voici ce que donne
journalctl -xe :

root@G41MDEB:/home/kristof# systemctl status apache2.service
● apache2.service - The Apache HTTP Server
 Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor
preset: enabled)
 Active: failed (Result: exit-code) since Thu 2017-04-13 17:05:32
CEST; 14min ago

avril 13 17:05:27 G41MDEB systemd[1]: Starting The Apache HTTP Server...
avril 13 17:05:32 G41MDEB apachectl[661]: (2)No such file or directory:
AH02291: Cannot access directory '/var/log/apache2/' for main error log
avril 13 17:05:32 G41MDEB apachectl[661]: (2)No such file or directory:
AH02291: Cannot access directory '/var/log/apache2/' for error log of vhost
avril 13 17:05:32 G41MDEB apachectl[661]: AH00014: Configuration check
failed
avril 13 17:05:32 G41MDEB apachectl[661]: Action 'start' failed.
avril 13 17:05:32 G41MDEB apachectl[661]: The Apache error log may have
more information.
avril 13 17:05:32 G41MDEB systemd[1]: apache2.service: Control process
exited, code=exited status=1
avril 13 17:05:32 G41MDEB systemd[1]: Failed to start The Apache HTTP
Server.
avril 13 17:05:32 G41MDEB systemd[1]: apache2.service: Unit entered
failed state.
avril 13 17:05:32 G41MDEB systemd[1]: apache2.service: Failed with
result 'exit-code'.

Si je créé le répertoire manuellement ou que je ré-installe et que je
relance apache2, cela fonctionne mais après le reboot, le répertoire de
log n'existe plus.

Quelqu'un aurait une idée de ce qui peut se passer svp ?

Sincèrement,

Christophe De Natale


--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez 
excuser ma brièveté. 

Re: [stretch]Apache2 ne démarre pas après reboot

[Thierry Bugier Pineau]

Bonjour

/var/log ou /var ne serait pas le point de montage d'un volume volatile ? 
(Genre tmpfs). Il me semble que c'est le genre de conseil qu'on donnait (ou 
donne encore) pour réduire les écritures sur un SSD.

Je ne vois guère autre chose qui expliquerait la disparition de 
/var/log/apache2 .

Quelles sont les particularités du système par rapport à une installation "bête 
et méchante" ?

Le 13 avril 2017 17:38:50 GMT+02:00, Christophe De Natale 
<christophedenat...@orange.fr> a écrit :
>Bonjour à vous,
>
>Sur mon pc de la maison fraîchement upgradé en stretch, je rencontre un
>
>problème avec apache2 qui n'est plus fonctionnel après reboot de la
>machine.
>
>Les logs ? Et bien ils ne sont pas consultables tout simplement parce 
>que le répertoire /var/log/apache2 n'existe pas. Voici ce que donne 
>journalctl -xe :
>
>root@G41MDEB:/home/kristof# systemctl status apache2.service
>● apache2.service - The Apache HTTP Server
>  Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor 
>preset: enabled)
>Active: failed (Result: exit-code) since Thu 2017-04-13 17:05:32 
>CEST; 14min ago
>
>avril 13 17:05:27 G41MDEB systemd[1]: Starting The Apache HTTP
>Server...
>avril 13 17:05:32 G41MDEB apachectl[661]: (2)No such file or directory:
>
>AH02291: Cannot access directory '/var/log/apache2/' for main error log
>avril 13 17:05:32 G41MDEB apachectl[661]: (2)No such file or directory:
>
>AH02291: Cannot access directory '/var/log/apache2/' for error log of
>vhost
>avril 13 17:05:32 G41MDEB apachectl[661]: AH00014: Configuration check 
>failed
>avril 13 17:05:32 G41MDEB apachectl[661]: Action 'start' failed.
>avril 13 17:05:32 G41MDEB apachectl[661]: The Apache error log may have
>
>more information.
>avril 13 17:05:32 G41MDEB systemd[1]: apache2.service: Control process 
>exited, code=exited status=1
>avril 13 17:05:32 G41MDEB systemd[1]: Failed to start The Apache HTTP 
>Server.
>avril 13 17:05:32 G41MDEB systemd[1]: apache2.service: Unit entered 
>failed state.
>avril 13 17:05:32 G41MDEB systemd[1]: apache2.service: Failed with 
>result 'exit-code'.
>
>Si je créé le répertoire manuellement ou que je ré-installe et que je 
>relance apache2, cela fonctionne mais après le reboot, le répertoire de
>
>log n'existe plus.
>
>Quelqu'un aurait une idée de ce qui peut se passer svp ?
>
>Sincèrement,
>
>Christophe De Natale

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

[stretch]Apache2 ne démarre pas après reboot

[Christophe De Natale]

Bonjour à vous,

Sur mon pc de la maison fraîchement upgradé en stretch, je rencontre un 
problème avec apache2 qui n'est plus fonctionnel après reboot de la machine.


Les logs ? Et bien ils ne sont pas consultables tout simplement parce 
que le répertoire /var/log/apache2 n'existe pas. Voici ce que donne 
journalctl -xe :


root@G41MDEB:/home/kristof# systemctl status apache2.service
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Thu 2017-04-13 17:05:32 
CEST; 14min ago


avril 13 17:05:27 G41MDEB systemd[1]: Starting The Apache HTTP Server...
avril 13 17:05:32 G41MDEB apachectl[661]: (2)No such file or directory: 
AH02291: Cannot access directory '/var/log/apache2/' for main error log
avril 13 17:05:32 G41MDEB apachectl[661]: (2)No such file or directory: 
AH02291: Cannot access directory '/var/log/apache2/' for error log of vhost
avril 13 17:05:32 G41MDEB apachectl[661]: AH00014: Configuration check 
failed

avril 13 17:05:32 G41MDEB apachectl[661]: Action 'start' failed.
avril 13 17:05:32 G41MDEB apachectl[661]: The Apache error log may have 
more information.
avril 13 17:05:32 G41MDEB systemd[1]: apache2.service: Control process 
exited, code=exited status=1
avril 13 17:05:32 G41MDEB systemd[1]: Failed to start The Apache HTTP 
Server.
avril 13 17:05:32 G41MDEB systemd[1]: apache2.service: Unit entered 
failed state.
avril 13 17:05:32 G41MDEB systemd[1]: apache2.service: Failed with 
result 'exit-code'.


Si je créé le répertoire manuellement ou que je ré-installe et que je 
relance apache2, cela fonctionne mais après le reboot, le répertoire de 
log n'existe plus.


Quelqu'un aurait une idée de ce qui peut se passer svp ?

Sincèrement,

Christophe De Natale

Re: [testing] reboot intempestif

[maderios]

On 10/30/2015 08:32 PM, Pascal Hambourg wrote:

maderios a écrit :

On 10/30/2015 07:30 PM, Gaëtan PERRIER wrote:


Par contre maintenant j'ai un problème avec l'EFI. Pour booter je suis obligé
de booter sur une clé refind. Pas top ...


Si à la place de grub tu vois 'invalid signature detected Check secure
boot...' etc...,

il faut désactiver efi dans le bios et ensuite ça roule...


Plutôt le secure boot.


Merci d'avoir rectifié cette épouvantable approximation.


Et ce n'est plus un BIOS puisque c'est un firmware UEFI, usine à gaz qui
ne mérite plus le qualificatif de "BIOS" dont la première lettre
signifie "basic".

Même avec UEFI, c'est quand même le programme le plus 'basique' du PC. 
Sans lui, rien ne marche.


--
Maderios

Re: [testing] reboot intempestif

[maderios]

On 10/30/2015 12:37 AM, Gaëtan PERRIER wrote:

Le Thu, 29 Oct 2015 09:53:26 +0100
maderios <mader...@gmail.com> a écrit:


On 10/29/2015 02:22 AM, Gaëtan PERRIER wrote:


J'ai changé l'alim mais depuis le système ne boote plus ...
Une idée d'où ça peut venir ?



J'arrive à booter en passant par une clé refind mais finalement ce n'est
pas l'alim. J'ai de nouveau eu un reboot :(
Je ne comprends pas pourquoi le boot ne fonctionne plus ?


Es tu certain que tes alim sont stables? Pour la petite histoire, le SAV
enermax m'a remplacé deux fois de suite une alim neuve soit-disant haut
de gamme "gold". J'ai finalement laissé tomber pour acheter une autre
marque. Trois alim neuves de suite qui étaient instables...


Je ne sais pas trop, comment fais-tu pour vérifier la stabilité des alims ?
L'alim est une LDLC QS-550+ qui a très bonne réputation.

J'avais vérifié avec un voltmètre/multimètre (skytronic 600) mais il 
existe des testeurs d'alimentation numériques plus précis et moins cher.

Gougueuler "testeur d'alimentation ATX"
 En ce qui concerne la "bonne réputation", aucun matériel, aussi réputé 
soit-il, n'est à l'abri d'une défaillance.
Autre piste: un mauvais contact (cela m'est arrivé, même symptômes). As 
tu vérifié que toutes les prises sont vraiment bien enfoncées?


--
Maderios

Re: [testing] reboot intempestif

[maderios]

On 10/30/2015 07:30 PM, Gaëtan PERRIER wrote:


Par contre maintenant j'ai un problème avec l'EFI. Pour booter je suis obligé
de booter sur une clé refind. Pas top ...

Si à la place de grub tu vois 'invalid signature detected Check secure 
boot...' etc...,


il faut désactiver efi dans le bios et ensuite ça roule...
--
Maderios

Re: [testing] reboot intempestif

[Gaëtan PERRIER]

Le Fri, 30 Oct 2015 20:25:56 +0100
maderios  a écrit:

> On 10/30/2015 07:30 PM, Gaëtan PERRIER wrote:
> 
> > Par contre maintenant j'ai un problème avec l'EFI. Pour booter je suis
> > obligé de booter sur une clé refind. Pas top ...
> >
> Si à la place de grub tu vois 'invalid signature detected Check secure 
> boot...' etc...,
> 
> il faut désactiver efi dans le bios et ensuite ça roule...

Non il dit juste qu'il ne trouve rien de bootable.

Avant que je démonte tout ça fonctionnait parfaitement ...

Gaëtan

Re: [testing] reboot intempestif

[Pascal Hambourg]

maderios a écrit :
> On 10/30/2015 07:30 PM, Gaëtan PERRIER wrote:
> 
>> Par contre maintenant j'ai un problème avec l'EFI. Pour booter je suis obligé
>> de booter sur une clé refind. Pas top ...
>>
> Si à la place de grub tu vois 'invalid signature detected Check secure 
> boot...' etc...,
> 
> il faut désactiver efi dans le bios et ensuite ça roule...

Plutôt le secure boot.
Et ce n'est plus un BIOS puisque c'est un firmware UEFI, usine à gaz qui
ne mérite plus le qualificatif de "BIOS" dont la première lettre
signifie "basic".

Re: [testing] reboot intempestif

[Gaëtan PERRIER]

Le Fri, 30 Oct 2015 11:08:33 +0100
maderios <mader...@gmail.com> a écrit:

> On 10/30/2015 12:37 AM, Gaëtan PERRIER wrote:
> > Le Thu, 29 Oct 2015 09:53:26 +0100
> > maderios <mader...@gmail.com> a écrit:
> >
> >> On 10/29/2015 02:22 AM, Gaëtan PERRIER wrote:
> >>
> >>>> J'ai changé l'alim mais depuis le système ne boote plus ...
> >>>> Une idée d'où ça peut venir ?
> >>>>
> >>>
> >>> J'arrive à booter en passant par une clé refind mais finalement ce n'est
> >>> pas l'alim. J'ai de nouveau eu un reboot :(
> >>> Je ne comprends pas pourquoi le boot ne fonctionne plus ?
> >>>
> >> Es tu certain que tes alim sont stables? Pour la petite histoire, le SAV
> >> enermax m'a remplacé deux fois de suite une alim neuve soit-disant haut
> >> de gamme "gold". J'ai finalement laissé tomber pour acheter une autre
> >> marque. Trois alim neuves de suite qui étaient instables...
> >
> > Je ne sais pas trop, comment fais-tu pour vérifier la stabilité des alims ?
> > L'alim est une LDLC QS-550+ qui a très bonne réputation.
> >
> J'avais vérifié avec un voltmètre/multimètre (skytronic 600) mais il 
> existe des testeurs d'alimentation numériques plus précis et moins cher.
> Gougueuler "testeur d'alimentation ATX"

C'est ce qu'ils ont fait au SAV sans rien voir. Ils m'en ont donc redonné une
autre dans le doute après un test sur une machine de la mienne.

>   En ce qui concerne la "bonne réputation", aucun matériel, aussi réputé 
> soit-il, n'est à l'abri d'une défaillance.

Certes.

> Autre piste: un mauvais contact (cela m'est arrivé, même symptômes). As 
> tu vérifié que toutes les prises sont vraiment bien enfoncées?

Effectivement ça semble être la piste probable car hier soir j'ai démonté
toute la machine et tout remonté et depuis (je croise les doigts) ça semble
être stable ...
En cherchant dans les archives de la liste je me suis aperçu que j'avais déjà
eu le même problème il y a 3 ans et demi et que ça c'était résolu de la même
façon suite à un démontage/remontage pour l'emmener au SAV ...

Par contre maintenant j'ai un problème avec l'EFI. Pour booter je suis obligé
de booter sur une clé refind. Pas top ...

Gaëtan

Re: [resolu] Re: [testing] reboot intempestif

[Gaëtan PERRIER]

Les symptômes ne sont pas les mêmes. Chez moi le système démarre correctement.

A+

Gaëtan

Le Thu, 29 Oct 2015 09:26:27 +0100
Pierre TOUZEAU <pierre.touz...@basse-normandie.pref.gouv.fr> a écrit:

> Vérifier la pile bouton 3v CMOS, j'avais changé inutilement une Alim à
> cause d'aléa de la pile en fin de vie qui devait être en deça d'un
> certain seuil...
> Les symptômes étaient les mêmes, pas de démarrage du système, alim
> arrêtée et même pas de signal sonore de CM en rade !
> 
> Pierre
> 
> 
> Le 29/10/2015 00:39, Gaëtan PERRIER a écrit :
> > Le Wed, 28 Oct 2015 01:27:08 +0100
> > Gaëtan PERRIER <gaetan.perr...@neuf.fr> a écrit:
> >
> >> Le Sun, 25 Oct 2015 22:21:27 +0100
> >> maderios <mader...@gmail.com> a écrit:
> >>
> >>> On 10/25/2015 09:44 PM, Gaëtan PERRIER wrote:
> >>>> Bonjour,
> >>>>
> >>> Bonjour
> >>>> Je viens de faire les mises à jours de testing correspondant à
> >>>> vendredi, samedi et dimanche et depuis la machine reboot toute
> >>>> seule quelques minutes après le boot. J'ai essayé de démarrer en
> >>>> recovery mais c'est la même chose ...
> >>>> Bref je ne sais pas comment diagnostiquer cela et le résoudre.
> >>> Cela m'est déjà arrivé il y a un certain temps. C'était une
> >>> alimentation défectueuse qui provoquait des redémarrages.
> >>> Tu peux démarrer depuis un live-cd et essayer de regarder les logs.
> >>> Si ton PC ne reboute pas, c'est bien un pb logiciel.
> >>> -- 
> >> Bien vu c'est bien l'alim qui est défectueuse. J'ai essayé avec une
> >> autre alim et plus de problème.
> >>
> > J'ai changé l'alim mais depuis le système ne boote plus ...
> > Une idée d'où ça peut venir ?
> >
> > Gaëtan
> >
> >
> 
> -- 
> Pro. Signature
> 
> Pierre Touzeau
> 
> ---
> Chargé de mission  Préfecture de region Basse-Normandie
> SGAR, rue Daniel HUET 14038 CAEN CEDEX  +33 231 306 306
> pierre.touz...@basse-normandie.pref.gouv.fr +33 608 968 574
> ---

Re: [testing] reboot intempestif

[Gaëtan PERRIER]

Le Thu, 29 Oct 2015 09:53:26 +0100
maderios <mader...@gmail.com> a écrit:

> On 10/29/2015 02:22 AM, Gaëtan PERRIER wrote:
> 
> >> J'ai changé l'alim mais depuis le système ne boote plus ...
> >> Une idée d'où ça peut venir ?
> >>
> >
> > J'arrive à booter en passant par une clé refind mais finalement ce n'est
> > pas l'alim. J'ai de nouveau eu un reboot :(
> > Je ne comprends pas pourquoi le boot ne fonctionne plus ?
> >
> Es tu certain que tes alim sont stables? Pour la petite histoire, le SAV 
> enermax m'a remplacé deux fois de suite une alim neuve soit-disant haut 
> de gamme "gold". J'ai finalement laissé tomber pour acheter une autre 
> marque. Trois alim neuves de suite qui étaient instables...

Je ne sais pas trop, comment fais-tu pour vérifier la stabilité des alims ?
L'alim est une LDLC QS-550+ qui a très bonne réputation. 

A+

Gaëtan

Re: Re: [resolu] Re: [testing] reboot intempestif

[Pierre TOUZEAU]

Vérifier la pile bouton 3v CMOS, j'avais changé inutilement une Alim à
cause d'aléa de la pile en fin de vie qui devait être en deça d'un
certain seuil...
Les symptômes étaient les mêmes, pas de démarrage du système, alim
arrêtée et même pas de signal sonore de CM en rade !

Pierre


Le 29/10/2015 00:39, Gaëtan PERRIER a écrit :
> Le Wed, 28 Oct 2015 01:27:08 +0100
> Gaëtan PERRIER <gaetan.perr...@neuf.fr> a écrit:
>
>> Le Sun, 25 Oct 2015 22:21:27 +0100
>> maderios <mader...@gmail.com> a écrit:
>>
>>> On 10/25/2015 09:44 PM, Gaëtan PERRIER wrote:
>>>> Bonjour,
>>>>
>>> Bonjour
>>>> Je viens de faire les mises à jours de testing correspondant à
>>>> vendredi, samedi et dimanche et depuis la machine reboot toute
>>>> seule quelques minutes après le boot. J'ai essayé de démarrer en
>>>> recovery mais c'est la même chose ...
>>>> Bref je ne sais pas comment diagnostiquer cela et le résoudre.
>>> Cela m'est déjà arrivé il y a un certain temps. C'était une
>>> alimentation défectueuse qui provoquait des redémarrages.
>>> Tu peux démarrer depuis un live-cd et essayer de regarder les logs.
>>> Si ton PC ne reboute pas, c'est bien un pb logiciel.
>>> -- 
>> Bien vu c'est bien l'alim qui est défectueuse. J'ai essayé avec une
>> autre alim et plus de problème.
>>
> J'ai changé l'alim mais depuis le système ne boote plus ...
> Une idée d'où ça peut venir ?
>
> Gaëtan
>
>

-- 
Pro. Signature

Pierre Touzeau

---
Chargé de mission  Préfecture de region Basse-Normandie
SGAR, rue Daniel HUET 14038 CAEN CEDEX  +33 231 306 306
pierre.touz...@basse-normandie.pref.gouv.fr +33 608 968 574
---

Re: [testing] reboot intempestif

[maderios]

On 10/29/2015 02:22 AM, Gaëtan PERRIER wrote:


J'ai changé l'alim mais depuis le système ne boote plus ...
Une idée d'où ça peut venir ?



J'arrive à booter en passant par une clé refind mais finalement ce n'est pas
l'alim. J'ai de nouveau eu un reboot :(
Je ne comprends pas pourquoi le boot ne fonctionne plus ?

Es tu certain que tes alim sont stables? Pour la petite histoire, le SAV 
enermax m'a remplacé deux fois de suite une alim neuve soit-disant haut 
de gamme "gold". J'ai finalement laissé tomber pour acheter une autre 
marque. Trois alim neuves de suite qui étaient instables...


--
Maderios

Re: [resolu] Re: [testing] reboot intempestif

[Gaëtan PERRIER]

Le Wed, 28 Oct 2015 01:27:08 +0100
Gaëtan PERRIER <gaetan.perr...@neuf.fr> a écrit:

> Le Sun, 25 Oct 2015 22:21:27 +0100
> maderios <mader...@gmail.com> a écrit:
> 
> > On 10/25/2015 09:44 PM, Gaëtan PERRIER wrote:
> > > Bonjour,
> > >
> > Bonjour
> > > Je viens de faire les mises à jours de testing correspondant à
> > > vendredi, samedi et dimanche et depuis la machine reboot toute
> > > seule quelques minutes après le boot. J'ai essayé de démarrer en
> > > recovery mais c'est la même chose ...
> > > Bref je ne sais pas comment diagnostiquer cela et le résoudre.
> > Cela m'est déjà arrivé il y a un certain temps. C'était une
> > alimentation défectueuse qui provoquait des redémarrages.
> > Tu peux démarrer depuis un live-cd et essayer de regarder les logs.
> > Si ton PC ne reboute pas, c'est bien un pb logiciel.
> > -- 
> 
> Bien vu c'est bien l'alim qui est défectueuse. J'ai essayé avec une
> autre alim et plus de problème.
> 

J'ai changé l'alim mais depuis le système ne boote plus ...
Une idée d'où ça peut venir ?

Gaëtan

Re: [testing] reboot intempestif

[Gaëtan PERRIER]

Le Thu, 29 Oct 2015 00:39:58 +0100
Gaëtan PERRIER <gaetan.perr...@neuf.fr> a écrit:

> Le Wed, 28 Oct 2015 01:27:08 +0100
> Gaëtan PERRIER <gaetan.perr...@neuf.fr> a écrit:
> 
> > Le Sun, 25 Oct 2015 22:21:27 +0100
> > maderios <mader...@gmail.com> a écrit:
> > 
> > > On 10/25/2015 09:44 PM, Gaëtan PERRIER wrote:
> > > > Bonjour,
> > > >
> > > Bonjour
> > > > Je viens de faire les mises à jours de testing correspondant à
> > > > vendredi, samedi et dimanche et depuis la machine reboot toute
> > > > seule quelques minutes après le boot. J'ai essayé de démarrer en
> > > > recovery mais c'est la même chose ...
> > > > Bref je ne sais pas comment diagnostiquer cela et le résoudre.
> > > Cela m'est déjà arrivé il y a un certain temps. C'était une
> > > alimentation défectueuse qui provoquait des redémarrages.
> > > Tu peux démarrer depuis un live-cd et essayer de regarder les logs.
> > > Si ton PC ne reboute pas, c'est bien un pb logiciel.
> > > -- 
> > 
> > Bien vu c'est bien l'alim qui est défectueuse. J'ai essayé avec une
> > autre alim et plus de problème.
> > 
> 
> J'ai changé l'alim mais depuis le système ne boote plus ...
> Une idée d'où ça peut venir ?
> 

J'arrive à booter en passant par une clé refind mais finalement ce n'est pas
l'alim. J'ai de nouveau eu un reboot :(
Je ne comprends pas pourquoi le boot ne fonctionne plus ?

Gaëtan

[resolu] Re: [testing] reboot intempestif

[Gaëtan PERRIER]

Le Sun, 25 Oct 2015 22:21:27 +0100
maderios <mader...@gmail.com> a écrit:

> On 10/25/2015 09:44 PM, Gaëtan PERRIER wrote:
> > Bonjour,
> >
> Bonjour
> > Je viens de faire les mises à jours de testing correspondant à
> > vendredi, samedi et dimanche et depuis la machine reboot toute seule
> > quelques minutes après le boot. J'ai essayé de démarrer en recovery
> > mais c'est la même chose ...
> > Bref je ne sais pas comment diagnostiquer cela et le résoudre.
> Cela m'est déjà arrivé il y a un certain temps. C'était une
> alimentation défectueuse qui provoquait des redémarrages.
> Tu peux démarrer depuis un live-cd et essayer de regarder les logs.
> Si ton PC ne reboute pas, c'est bien un pb logiciel.
> -- 

Bien vu c'est bien l'alim qui est défectueuse. J'ai essayé avec une
autre alim et plus de problème.

Gaëtan

Re: [testing] reboot intempestif

[maderios]

On 10/25/2015 11:44 PM, Gaëtan PERRIER wrote:


Ça m'est arrivé sur un problème de barrette mémoire. Essaie un boot
sur memtest.



Je n'arrive pas à le lancer ...


Tu le lances avec un livecd? Quel livecd?
--
Maderios

Re: [testing] reboot intempestif

[Jean-Michel OLTRA]

Bonjour,


Le dimanche 25 octobre 2015, Gaëtan PERRIER a écrit...


> Je viens de faire les mises à jours de testing correspondant à
> vendredi, samedi et dimanche et depuis la machine reboot toute seule
> quelques minutes après le boot. J'ai essayé de démarrer en recovery
> mais c'est la même chose ...
> Bref je ne sais pas comment diagnostiquer cela et le résoudre.
> Est-ce que quelqu'un d'autre rencontre ce problème ?

Ça m'est arrivé sur un problème de barrette mémoire. Essaie un boot sur
memtest.

-- 
jm

Re: [testing] reboot intempestif

[Gaëtan PERRIER]

Le Sun, 25 Oct 2015 22:21:27 +0100
maderios <mader...@gmail.com> a écrit:

> On 10/25/2015 09:44 PM, Gaëtan PERRIER wrote:
> > Bonjour,
> >
> Bonjour
> > Je viens de faire les mises à jours de testing correspondant à
> > vendredi, samedi et dimanche et depuis la machine reboot toute seule
> > quelques minutes après le boot. J'ai essayé de démarrer en recovery
> > mais c'est la même chose ...
> > Bref je ne sais pas comment diagnostiquer cela et le résoudre.
> Cela m'est déjà arrivé il y a un certain temps. C'était une
> alimentation défectueuse qui provoquait des redémarrages.
> Tu peux démarrer depuis un live-cd et essayer de regarder les logs.
> Si ton PC ne reboute pas, c'est bien un pb logiciel.

Pas de soucis avec un livecd.

Je vous joins les extraits de messages et syslog correspondant au boot
jusqu'au reboot.
Moi je ne vois rien d'anormal dedans ...


Gaëtan



messages.tar.bz2
Description: Binary data


syslog.tar.bz2
Description: Binary data

Re: [testing] reboot intempestif

[Gaëtan PERRIER]

Le Sun, 25 Oct 2015 23:31:50 +0100
Jean-Michel OLTRA <jm.oltra.antis...@espinasse.net> a écrit:

> 
> Bonjour,
> 
> 
> Le dimanche 25 octobre 2015, Gaëtan PERRIER a écrit...
> 
> 
> > Je viens de faire les mises à jours de testing correspondant à
> > vendredi, samedi et dimanche et depuis la machine reboot toute seule
> > quelques minutes après le boot. J'ai essayé de démarrer en recovery
> > mais c'est la même chose ...
> > Bref je ne sais pas comment diagnostiquer cela et le résoudre.
> > Est-ce que quelqu'un d'autre rencontre ce problème ?
> 
> Ça m'est arrivé sur un problème de barrette mémoire. Essaie un boot
> sur memtest.
> 

Je n'arrive pas à le lancer ...

Gaëtan

[testing] reboot intempestif

[Gaëtan PERRIER]

Bonjour,

Je viens de faire les mises à jours de testing correspondant à
vendredi, samedi et dimanche et depuis la machine reboot toute seule
quelques minutes après le boot. J'ai essayé de démarrer en recovery
mais c'est la même chose ...
Bref je ne sais pas comment diagnostiquer cela et le résoudre.
Est-ce que quelqu'un d'autre rencontre ce problème ?

Gaëtan

Re: [testing] reboot intempestif

[maderios]

On 10/25/2015 09:44 PM, Gaëtan PERRIER wrote:

Bonjour,


Bonjour

Je viens de faire les mises à jours de testing correspondant à
vendredi, samedi et dimanche et depuis la machine reboot toute seule
quelques minutes après le boot. J'ai essayé de démarrer en recovery
mais c'est la même chose ...
Bref je ne sais pas comment diagnostiquer cela et le résoudre.
Cela m'est déjà arrivé il y a un certain temps. C'était une alimentation 
défectueuse qui provoquait des redémarrages.

Tu peux démarrer depuis un live-cd et essayer de regarder les logs.
Si ton PC ne reboute pas, c'est bien un pb logiciel.
--
Maderios

Xen 4.1, PyGrub et reboot impossible

[Guillaume]

Bonjour,

J'ai un soucis avec Xen 4.1 présent dans les dépots de Wheezy.

infos:
j'utilise xl comme toolstack et PyGrub comme bootloader.

soucis:
Il m'est impossible de reboot un DomU via les commandes
* reboot
* shutdown -r now

le log sur le Dom0 :
$ cat /var/log/xen/xl-vm1.log
Waiting for domain vm1 (domid 20) to die [pid 7584]
Domain 20 is dead
Action for shutdown reason code 1 is restart
Domain 20 needs to be cleaned up: destroying the domain
Done. Rebooting now
failed to run bootloader: -3

--
Guillaume

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54da02f5.4090...@gwilhom.fr

pb courier-authlib suite à reboot

[Grégoire COUTANT]

Bonjour à tous,
Sur une debian 6, j'utilise depuis longtemps Qmail avec courier-imap 
compilé à la main pour l'imap.


Suite à un reboot ce w-e sur un disque RAID dégradé, courier-authlib ne 
fonctionne plus.


J'utilise une authentification basé sur vpopmail :
# grep authmodulelist= /usr/local/etc/authlib/authdaemonrc
authmodulelist=authvchkpw

Mais en essayant de me connecter en IMAP j'obtiens cette erreur :

Feb  9 12:01:32 ns3 imapd-ssl: Connection, ip=[:::80.15.XXX.XXX]
Feb  9 12:01:32 ns3 authdaemond: received auth request, service=imap, 
authtype=login

Feb  9 12:01:32 ns3 authdaemond: FAIL, all modules rejected
Feb  9 12:01:32 ns3 imapd-ssl: LOGIN FAILED, 
user=gregoire.cout...@xxx.com, ip=[:::80.15.XXX.XXX]


courier n'arrive pas à charger les modules d'authentification, ça fait 
un jour que je suis dessus et je commence à sécher sérieusement

Je suis preneur de toute idée pour me sortir de cette galère ;-)

Greg

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54d89847.1070...@gmail.com

Re: pb courier-authlib suite à reboot

[pmenier]

Le 09/02/2015 12:21, Grégoire COUTANT a écrit :

Bonjour à tous,
Sur une debian 6, j'utilise depuis longtemps Qmail avec courier-imap
compilé à la main pour l'imap.

Suite à un reboot ce w-e sur un disque RAID dégradé, courier-authlib ne
fonctionne plus.

J'utilise une authentification basé sur vpopmail :
# grep authmodulelist= /usr/local/etc/authlib/authdaemonrc
authmodulelist=authvchkpw

Mais en essayant de me connecter en IMAP j'obtiens cette erreur :

Feb  9 12:01:32 ns3 imapd-ssl: Connection, ip=[:::80.15.XXX.XXX]
Feb  9 12:01:32 ns3 authdaemond: received auth request, service=imap,
authtype=login
Feb  9 12:01:32 ns3 authdaemond: FAIL, all modules rejected
Feb  9 12:01:32 ns3 imapd-ssl: LOGIN FAILED,
user=gregoire.cout...@xxx.com, ip=[:::80.15.XXX.XXX]

courier n'arrive pas à charger les modules d'authentification, ça fait
un jour que je suis dessus et je commence à sécher sérieusement
Je suis preneur de toute idée pour me sortir de cette galère ;-)

Greg


Salut

Dans la mesure où tu n'as pas touché à ta config, à part un fichier 
corrompu je vois pas.


De tête ça m'était arrivé il y a 2/3 ans avec qmail, authlib et cie... 
Pareil à cause d'un disque foireux.


Il m semble que j'avais dû réinstaller la libc6 (???) ... entre autres ...

Patrick

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/mbaaht$l4u$4...@ger.gmane.org

Re: pb courier-authlib suite à reboot

[Grégoire COUTANT]

Salut,


Dans la mesure où tu n'as pas touché à ta config, à part un fichier
corrompu je vois pas.
De tête ça m'était arrivé il y a 2/3 ans avec qmail, authlib et cie...
Pareil à cause d'un disque foireux.
Il m semble que j'avais dû réinstaller la libc6 (???) ... entre autres ...


Bon et bien j'ai réinstallé courier-imap et tout roule à nouveau...

$ wget -q http://www.pc-freak.net/files/courier-authlib.0.59.1.tar.gz
$ tar zxvf courier-authlib.0.59.1.tar.gz
$ cd courier-authlib-0.59.1/
$ ./configure --prefix=/usr/local --exec-prefix=/usr/local 
--with-authvchkpw --without-authldap --without-authmysql 
--disable-root-check --with-ssl 
--with-authchangepwdir=/usr/local/libexec/authlib

$ make  make install  make install-strip  make install-configure
$ /etc/init.d/courier-authdaemon restart  /etc/init.d/courier-authlib 
restart  /etc/init.d/courier-imap restart  
/etc/init.d/courier-imap-ssl restart  /etc/init.d/courier-pop restart 
 /etc/init.d/courier-pop-ssl restart


Comme quoi, il suffit de poster un message sur la liste pour que ça se 
débloque !


Merci

Greg

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/54d8afc5.9040...@gmail.com

Re: lenteur du reboot

[maderios]

On 06/14/2014 07:16 PM, sTriX wrote:

le samedi 14 juin 2014 à 16:15 (+0200), maderios a écrit:

La première chose à faire est de regarder les log de bootlog et syslog.
Un boot peut être lent à cause de services qui prennent du temps à
démarrer (suite à des erreurs).


Oui, je vais tenter une expédition dans le monde des logs. Mes
connaissances informatiques étant assez limitées, et ne sachant pas
exactement ce qu'il me faut chercher, il va me falloir une âme de
Thésée entrant dans le labyrinthe... Je te tiendrais au courant si
j'en ressort un jour sans m'être faits bouffer par le Minotaure. ;-)

Dans cette situation, il faut au minimum lire la documentation de base 
sur Linux/Debian abondamment disponible sur le net. Cela évite de 
chercher au hasard...


--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/539ec26b.2050...@gmail.com

Re: lenteur du reboot

[honeyshell]

http://doc.ubuntu-fr.org/bootchart

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cajehwdb03kvdl2c-48yuudgjpaghz_sld9bbdxfwunuzyhx...@mail.gmail.com

Re: lenteur du reboot

[Fabien R]

On 14/06/2014 16:14, sTriX wrote:
 ça ne semble pas convenir au cas de ma machine.
 Je continue les recherches. Merci pour votre réponse.


De quel bios/machine s'agit-il ?

-
Fabien


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/539d57ac.8080...@free.fr

Re: lenteur du reboot

[sTriX]

le dimanche 15 juin 2014 à 10:22 (+0200), Fabien R a écrit:
 De quel bios/machine s'agit-il ?

Il s'agit d'une machine que j'ai monté moi-même, fin octobre 2011 :
* carte mère ITX : Asus AT5NM10T-I (Atom D525 CPU onboard, chipset Intel NM10, 
BIOS AMI)
* 2 barrettes Corsair SO-DIMM DDR3 PC3-8500 - 2 Go 1066 MHz, 
* 1 disque dur Interne 2,5 Samsung HM500JJ- Spinpoint MP4 - SATA 3.0 - 500 Go
* Graveur dvd interne slim Samsung-SN-208BB/BEBE
-- 
Gérard 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20140615100639.GA2934@crunchbang

Re: lenteur du reboot

[sTriX]

le dimanche 15 juin 2014 à 10:22 (+0200), Fabien R a écrit:
 De quel bios/machine s'agit-il ?

BIOS Information
  Vendor: American Megatrends Inc.
  Version: 0306   
  Release Date: 02/23/2011
  Runtime Size: 64 kB
  ROM Size: 1024 kB 
-- 
Gérard 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20140615103000.GA3226@crunchbang

Re: lenteur du reboot

[sTriX]

le jeudi 12 juin 2014 à 10:47 (+0200), Sébastien NOBILI a écrit:

Bonjour Seb,

 Certains BIOS ont une option de configuration du test de mémoire (RAM) pour
 permettre un test rapide au démarrage.
 
 Est-ce que ton BIOS ne lancerait pas un test complet (avec les capacités
 actuelles ça peut durer) quand tu rebootes ?

Le BIOS a la fonction Quick Boot activée qui omet de faire des test
pour accélérer le boot.
 
 Ton BIOS peut également te proposer de masquer (ou non) ses messages, en les
 affichant tu trouveras peut-être des informations intéressantes.

Je n'ai pas trouvé ce genre de fonction.

Comme le boot se fait correctement lors d'un démarrage à froid, je me
demande si le problème ne viendrait pas d'informations résiduelles en
RAM qui perturberaient le BIOS lors d'un reboot ?

Merci pour ta réponse  tes remarques utiles.
--
Gérard 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20140614140415.GA2986@crunchbang

Re: lenteur du reboot

[sTriX]

le mercredi 11 juin 2014 à 19:51 (+0200), Raph a écrit:
 Bonjour Ralph,
 ça m'est arrivé sur un serveur HP proliant dL120 G5.
 Manifestement, nous avons une incompatibilité entre le BIOS ou le
 chipset du serveur et le grub-pc.
 Une solution au problème : http://ubuntuforums.org/showthread.php?t=942541
 
 voir si avec votre modèle, il n'y a pas des cas similaires.

D'après ce que j'ai pu lire dans la page Grub hanging booting
Proliant DL120 G5, ça ne semble pas convenir au cas de ma machine.
Je continue les recherches. Merci pour votre réponse.
-- 
Gérard 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20140614141402.GB2986@crunchbang

Re: lenteur du reboot

[maderios]

On 06/14/2014 04:04 PM, sTriX wrote:

le jeudi 12 juin 2014 à 10:47 (+0200), Sébastien NOBILI a écrit:

Bonjour Seb,


Certains BIOS ont une option de configuration du test de mémoire (RAM) pour
permettre un test rapide au démarrage.

Est-ce que ton BIOS ne lancerait pas un test complet (avec les capacités
actuelles ça peut durer) quand tu rebootes ?


Le BIOS a la fonction Quick Boot activée qui omet de faire des test
pour accélérer le boot.


Ton BIOS peut également te proposer de masquer (ou non) ses messages, en les
affichant tu trouveras peut-être des informations intéressantes.


Je n'ai pas trouvé ce genre de fonction.

Comme le boot se fait correctement lors d'un démarrage à froid, je me
demande si le problème ne viendrait pas d'informations résiduelles en
RAM qui perturberaient le BIOS lors d'un reboot ?


Bonjour
La première chose à faire est de regarder les log de bootlog et syslog.
Un boot peut être lent à cause de services qui prennent du temps à 
démarrer (suite à des erreurs).

--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/539c5915.1050...@gmail.com

Re: lenteur du reboot

[sTriX]

le mercredi 11 juin 2014 à 21:25 (+0200), Louis Wiart a écrit:
Bonjour Louis,
 
 Je dis peut être une bêtise, mais ça ne peut pas être une histoire de pile
 sur la carte mère ?

La réponse n'était pas bête ; j'ai vérifié et ce n'est pas çà.
Merci.
-- 
Gérard 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20140614142108.GC2986@crunchbang

Re: lenteur du reboot

[Diogene Laerce]

On 06/14/2014 04:15 PM, maderios wrote:
 On 06/14/2014 04:04 PM, sTriX wrote:
 le jeudi 12 juin 2014 à 10:47 (+0200), Sébastien NOBILI a écrit:

 Bonjour Seb,

 Certains BIOS ont une option de configuration du test de mémoire
 (RAM) pour
 permettre un test rapide au démarrage.

 Est-ce que ton BIOS ne lancerait pas un test complet (avec les capacités
 actuelles ça peut durer) quand tu rebootes ?

 Le BIOS a la fonction Quick Boot activée qui omet de faire des test
 pour accélérer le boot.

 Ton BIOS peut également te proposer de masquer (ou non) ses messages,
 en les
 affichant tu trouveras peut-être des informations intéressantes.

 Je n'ai pas trouvé ce genre de fonction.

 Comme le boot se fait correctement lors d'un démarrage à froid, je me
 demande si le problème ne viendrait pas d'informations résiduelles en
 RAM qui perturberaient le BIOS lors d'un reboot ?

 Bonjour
 La première chose à faire est de regarder les log de bootlog et syslog.
 Un boot peut être lent à cause de services qui prennent du temps à
 démarrer (suite à des erreurs).

Si je me rappelle bien ton premier message, le BIOS prend 3 mn avant de
passer a GRUB : dans ce cas, c'est d'abord du cote matériel que je
regarderais.

Le fait que ce ne soit qu'en cas de redémarrage peut venir du fait que
l'ordinateur/certaines pièces hardware ont deja chauffe et ne sont plus
reconnus aussi facilement que froid(es).

Es-tu sur de la fiabilité de toutes tes pièces hardware - RAM,
disques,.. - Une carte graphique défectueuse m'avait donne le même genre
de problème une fois ? Et surtout depuis quand/quel événement tu
constates le problème ?

-- 
“One original thought is worth a thousand mindless quotings.”
“Le vrai n'est pas plus sûr que le probable.”

  Diogene Laerce



signature.asc
Description: OpenPGP digital signature

Re: lenteur du reboot

[sTriX]

le samedi 14 juin 2014 à 16:15 (+0200), maderios a écrit:
 La première chose à faire est de regarder les log de bootlog et syslog.
 Un boot peut être lent à cause de services qui prennent du temps à
 démarrer (suite à des erreurs).

Oui, je vais tenter une expédition dans le monde des logs. Mes
connaissances informatiques étant assez limitées, et ne sachant pas
exactement ce qu'il me faut chercher, il va me falloir une âme de
Thésée entrant dans le labyrinthe... Je te tiendrais au courant si 
j'en ressort un jour sans m'être faits bouffer par le Minotaure. ;-)
-- 
Gérard 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20140614171634.GA2692@crunchbang

Re: lenteur du reboot

[sTriX]

le samedi 14 juin 2014 à 16:28 (+0200), Diogene Laerce a écrit:

Bonjour,

 Si je me rappelle bien ton premier message, le BIOS prend 3 mn avant de
 passer a GRUB : dans ce cas, c'est d'abord du cote matériel que je
 regarderais.
 
 Le fait que ce ne soit qu'en cas de redémarrage peut venir du fait que
 l'ordinateur/certaines pièces hardware ont deja chauffe et ne sont plus
 reconnus aussi facilement que froid(es).
 
La piste du matériel et des composants chauds est en effet intéressante.
J'ai fait un test simple : Ma machine étant en fonction depuis plus de
5 heures, je l'ai arrêté par un shutdown -halt now et dès son
extinction je l'ai rallumé en moins d'une seconde pour ne pas laisser
le temps aux divers composant de se refroidir. Résultat : le boot
s'est comporté normalement, l'affichage de Grub est apparu en
10 secondes après le bip de boot. 
 
 Es-tu sur de la fiabilité de toutes tes pièces hardware - RAM,
 disques,.. - Une carte graphique défectueuse m'avait donne le même genre
 de problème une fois ? Et surtout depuis quand/quel événement tu
 constates le problème ?

Voilà un certain nombre d'années que je ne suis plus sûr de rien.
Je dirais même que le sûr est aussi improbable que le vrai. ;-)
Alors, pour ce qui est de la fiabilité matérielle...
Ta remarque m'incite néanmoins à étudier cette piste.

 Et surtout depuis quand/quel événement tu constates le problème ? 

Quand ? Je ne sais pas précisément. Le système Debian étant un système 
informatique de réputation robuste  stable, la pratique du reboot n'est
pas chose courante. Par contre je m'en suis aperçu en m'essayant à la 
configuration d'openbox en avril dernier.

Merci pour ta contribution.
-- 
Gérard 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20140614211947.GB2692@crunchbang

Re: lenteur du reboot

[Haricophile]

Le samedi 14 juin 2014 à 19:16 +0200, sTriX a écrit :
 le samedi 14 juin 2014 à 16:15 (+0200), maderios a écrit:
  La première chose à faire est de regarder les log de bootlog et syslog.
  Un boot peut être lent à cause de services qui prennent du temps à
  démarrer (suite à des erreurs).
 
 Oui, je vais tenter une expédition dans le monde des logs. Mes
 connaissances informatiques étant assez limitées, et ne sachant pas
 exactement ce qu'il me faut chercher, il va me falloir une âme de
 Thésée entrant dans le labyrinthe... Je te tiendrais au courant si 
 j'en ressort un jour sans m'être faits bouffer par le Minotaure. ;-)
 -- 
 Gérard 
 

Tu as essayé de croiser l'alim avec une autre, ou au minimum de vérifier
les tensions des fois qu'il y ait un composant en train de dériver ?

[Troll inside] Ton bios a bien été contrôlé par la NSA au moment de sa
livraison ? [/Troll]

[Troll inside] La télécommande de ton bios serait-elle foireuse ou
incompatible ?
https://korben.info/computrace-lojack-absolute.html[/Troll]

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/1402782009.8247.5.camel@azuki.jisui

Re: lenteur du reboot

[Sébastien NOBILI]

Bonjour,

Certains BIOS ont une option de configuration du test de mémoire (RAM) pour
permettre un test rapide au démarrage.

Est-ce que ton BIOS ne lancerait pas un test complet (avec les capacités
actuelles ça peut durer) quand tu rebootes ?

Ton BIOS peut également te proposer de masquer (ou non) ses messages, en les
affichant tu trouveras peut-être des informations intéressantes.

Seb

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140612084714.gb15...@sebian.nob900.homeip.net

lenteur du reboot

[sTriX]

Bonjour,
Au démarrage à froid de ma machine ou au redémarrage après extinction,
le lancement est normal ; le BIOS met 10 secondes pour passer à
l'affichage de GRUB et 1 minute après le système est installé. Jusque
là, ça va.
Mais lorsque je fais un reboot par le menu openbox (exit ou restart),
ou avec la commande shutdown -r now, l'ordinateur quitte la session
courante puis relance le BIOS (bip de démarrage), mais l'affichage de
l'écran BIOS reste figé pendant 3mn 1/2, avant de passer à un écran
noir avec un index clignotant (dans l'angle gauche de l'écran) pendant
2mn, lorsque enfin l'écran de GRUB s'affiche, puis le système se lance
normalement en 1mn. Il faut en tout 6mn 30s pour rebooter le système
(!?).

note : pendant la période où l'écran du BIOS est figé, le clavier
semble inactif. Pourtant si j'appuie sur la touche 'del' pour entrer 
dans le BIOS, le menu principal du BIOS s'ouvre au bout de 3 minutes... 
Ça fonctionne, mais ça prend son temps.

Mes diverses recherches pour régler ce problème sont, à ce jour, 
restées vaines. 
Mes connaissances en informatiques sont limitées et une idée serait le
bienvenue. Merci.
-- 
Gérard 

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/20140611143030.GA2695@crunchbang

Re: lenteur du reboot

[Raph]

Le 11/06/2014 16:30, sTriX a écrit :

Bonjour,
Au démarrage à froid de ma machine ou au redémarrage après extinction,
le lancement est normal ; le BIOS met 10 secondes pour passer à
l'affichage de GRUB et 1 minute après le système est installé. Jusque
là, ça va.
Mais lorsque je fais un reboot par le menu openbox (exit ou restart),
ou avec la commande shutdown -r now, l'ordinateur quitte la session
courante puis relance le BIOS (bip de démarrage), mais l'affichage de
l'écran BIOS reste figé pendant 3mn 1/2, avant de passer à un écran
noir avec un index clignotant (dans l'angle gauche de l'écran) pendant
2mn, lorsque enfin l'écran de GRUB s'affiche, puis le système se lance
normalement en 1mn. Il faut en tout 6mn 30s pour rebooter le système
(!?).

note : pendant la période où l'écran du BIOS est figé, le clavier
semble inactif. Pourtant si j'appuie sur la touche 'del' pour entrer
dans le BIOS, le menu principal du BIOS s'ouvre au bout de 3 minutes...
Ça fonctionne, mais ça prend son temps.

Mes diverses recherches pour régler ce problème sont, à ce jour,
restées vaines.
Mes connaissances en informatiques sont limitées et une idée serait le
bienvenue. Merci.

Bonjour,
ça m'est arrivé sur un serveur HP proliant dL120 G5.
Manifestement, nous avons une incompatibilité entre le BIOS ou le 
chipset du serveur et le grub-pc.

Une solution au problème : http://ubuntuforums.org/showthread.php?t=942541

voir si avec votre modèle, il n'y a pas des cas similaires.

Raphaël

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/53989739.7090...@rignier.com

Re: lenteur du reboot

[Louis Wiart]

Bonjour,

Je dis peut être une bêtise, mais ça ne peut pas être une histoire de pile
sur la carte mère ?

Bises,
Louis.


2014-06-11 19:51 GMT+02:00 Raph raph...@rignier.com:

 Le 11/06/2014 16:30, sTriX a écrit :

  Bonjour,
 Au démarrage à froid de ma machine ou au redémarrage après extinction,
 le lancement est normal ; le BIOS met 10 secondes pour passer à
 l'affichage de GRUB et 1 minute après le système est installé. Jusque
 là, ça va.
 Mais lorsque je fais un reboot par le menu openbox (exit ou restart),
 ou avec la commande shutdown -r now, l'ordinateur quitte la session
 courante puis relance le BIOS (bip de démarrage), mais l'affichage de
 l'écran BIOS reste figé pendant 3mn 1/2, avant de passer à un écran
 noir avec un index clignotant (dans l'angle gauche de l'écran) pendant
 2mn, lorsque enfin l'écran de GRUB s'affiche, puis le système se lance
 normalement en 1mn. Il faut en tout 6mn 30s pour rebooter le système
 (!?).

 note : pendant la période où l'écran du BIOS est figé, le clavier
 semble inactif. Pourtant si j'appuie sur la touche 'del' pour entrer
 dans le BIOS, le menu principal du BIOS s'ouvre au bout de 3 minutes...
 Ça fonctionne, mais ça prend son temps.

 Mes diverses recherches pour régler ce problème sont, à ce jour,
 restées vaines.
 Mes connaissances en informatiques sont limitées et une idée serait le
 bienvenue. Merci.

 Bonjour,
 ça m'est arrivé sur un serveur HP proliant dL120 G5.
 Manifestement, nous avons une incompatibilité entre le BIOS ou le chipset
 du serveur et le grub-pc.
 Une solution au problème : http://ubuntuforums.org/showthread.php?t=942541

 voir si avec votre modèle, il n'y a pas des cas similaires.

 Raphaël


 --
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists

 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: https://lists.debian.org/53989739.7090...@rignier.com

Re: Nvidia : mode 1920*1080 changé à chaque reboot

[Nicolas FRANCOIS]

Le Fri, 3 Jan 2014 20:16:02 +0100,
Bzzz lazyvi...@gmx.com a écrit :

 On Fri, 3 Jan 2014 20:11:30 +0100
 Nicolas FRANCOIS nicolas.franc...@free.fr wrote:
 
  Fais suer, toutes ces surcouches au système de base :-( Le Linux
  moderne n'est pas pour les vieux de la vieille :-P
 
 C'est justement parce que tu vieillis qu'il te faut une
 sur-couche ;-P
 

Ah, c'est malin !!!

\bye

-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20140107202224.07972...@gaston.baronie.vez

Re: Nvidia : mode 1920*1080 changé à chaque reboot

[Bzzz]

On Fri, 3 Jan 2014 20:11:30 +0100
Nicolas FRANCOIS nicolas.franc...@free.fr wrote:

 Fais suer, toutes ces surcouches au système de base :-( Le Linux
 moderne n'est pas pour les vieux de la vieille :-P

C'est justement parce que tu vieillis qu'il te faut une
sur-couche ;-P

-- 
Certains hommes n'ont que ce qu'ils méritent, les autres sont célibataires.
-- Sacha GUITRY

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20140103201602.6853b456@anubis.defcon1

Re: Nvidia : mode 1920*1080 changé à chaque reboot

[Nicolas FRANCOIS]

Le Sun, 10 Nov 2013 20:56:13 +0100,
Nicolas FRANCOIS nicolas.franc...@free.fr a écrit :

 Salut.
 
 J'ai réglé avec nvidia-settings le mode par défaut au mode optimal de
 mon écran, soit 1920*1080*60Hz. Lorsque je boote, l'écran de connexion
 est dans le bon mode. Mais quand je me loggue, l'écran s'éteint, et se
 rallume en 1680*1050. Et ça m'énerve...
 
 J'ai cherché dans mon répertoire perso, et ai vu deux choses : un
 fichier .nvidia-settings-rc, qui ne contient pas de résolution par
 défaut, et un répertoire .nv, qui ne contient qu'un sous-répertoire
 GLCache avec deux sous-répertoires aux noms idiots et des trucs
 bizarres dedans.
 
 Comment faire pour ne pas modifier les réglages du
 fichier /etc/X11/xorg.conf ?

J'ai trouvé : dans les paramètres de XFCE, l'écran est réglé sur
1680*1050, et ce paramètre était lu APRÈS le lancement de Xorg.

J'ai remis la résolution par défaut à 1920*1080, et tout est OK
maintenant.

Fais suer, toutes ces surcouches au système de base :-( Le Linux
moderne n'est pas pour les vieux de la vieille :-P

\bye

-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20140103201130.19d63...@gaston.baronie.vez

Re: Problème de reboot sur portable Asus

[Basile Starynkevitch]

On Wed, 2013-11-20 at 17:42 +, Nicolas wrote:
 Bonjour à tous,
 
 Depuis quelques temps, quand je reboote mon portable (Asus core i7), la 
 machine se relance mais me donne un bel écran noir.
 Impossible d'accéder à une quelconque console, les touches ALT-F1...F12 
 ( ou CTRL-ALT-F1) ne donnent rien.
 Je dois, à chaque fois, éteindre le portable avec (appui court sur le 
 bouton power), choisir le mode de dépannage dans Grub, rebooter avec la 
 commande reboot pour retrouver ma machine fonctionnelle.
 Je ne trouve rien dans /var/log/syslog qui puisse m'indiquer d'où vient 
 le problème.
 Auriez-vous déjà rencontré ce problème ou auriez-vous une piste à 
 exploiter pour diagnostiquer d'où peut venir ce comportement étrange ?

Je n'ai aucune idée, mais si il y a GPU dans ce portable, ça vaudrait le
coût de recompiler un noyau récent (3.12) depuis kernel.org (avec
make-kpkg). Le DRM dans le noyau a progressé récemment (aussi bien coté
AMD/ATI que coté Nvidia).

Mais je dis peut-être des bêtises, et le problème pourrait être
matériel.

Librement
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***


-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/1384973394.4840.2.camel@glinka.lesours

Re: Problème de reboot sur portable Asus

[Nicolas]

Le 20-11-2013 18:49, Basile Starynkevitch a écrit :

On Wed, 2013-11-20 at 17:42 +, Nicolas wrote:

Bonjour à tous,

Depuis quelques temps, quand je reboote mon portable (Asus core i7), 
la

machine se relance mais me donne un bel écran noir.
Impossible d'accéder à une quelconque console, les touches 
ALT-F1...F12

( ou CTRL-ALT-F1) ne donnent rien.
Je dois, à chaque fois, éteindre le portable avec (appui court sur le
bouton power), choisir le mode de dépannage dans Grub, rebooter avec 
la

commande reboot pour retrouver ma machine fonctionnelle.
Je ne trouve rien dans /var/log/syslog qui puisse m'indiquer d'où 
vient

le problème.
Auriez-vous déjà rencontré ce problème ou auriez-vous une piste à
exploiter pour diagnostiquer d'où peut venir ce comportement étrange ?


Je n'ai aucune idée, mais si il y a GPU dans ce portable, ça vaudrait 
le

coût de recompiler un noyau récent (3.12) depuis kernel.org (avec
make-kpkg). Le DRM dans le noyau a progressé récemment (aussi bien coté
AMD/ATI que coté Nvidia).


Ce portable dispose de deux cartes graphiques : une intégrée à la carte 
mère (intel) et une nvidia Geforce.
Le soucis c'est que je n'ai aucune envie de recompiler le kernel et 
surtout que ce portable fonctionnait très bien avant ce 
dysfonctionnement...




Mais je dis peut-être des bêtises, et le problème pourrait être
matériel.

Librement
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/f5af619a959af04751d8f33d3d520...@tycho.fr

Re: Problème de reboot sur portable Asus

[maderios]

On 11/20/2013 06:42 PM, Nicolas wrote:

Bonjour à tous,

Depuis quelques temps, quand je reboote mon portable (Asus core i7), la
machine se relance mais me donne un bel écran noir.
Impossible d'accéder à une quelconque console, les touches ALT-F1...F12
( ou CTRL-ALT-F1) ne donnent rien.
Je dois, à chaque fois, éteindre le portable avec (appui court sur le
bouton power), choisir le mode de dépannage dans Grub, rebooter avec la
commande reboot pour retrouver ma machine fonctionnelle.
Je ne trouve rien dans /var/log/syslog qui puisse m'indiquer d'où vient
le problème.
Auriez-vous déjà rencontré ce problème ou auriez-vous une piste à
exploiter pour diagnostiquer d'où peut venir ce comportement étrange ?

Machine K53S, kernel 3.10-3-amd64, gnome3, debian stable/testing


Bonjour
J'ai un problème similaire en testing mais avec un noyau compilé maison. 
Par contre le kernel .deb officiel marche bien. Tjrs pas trouvé la cause 
de cet écran noir qui n’apparait qu'avec testing. Le même noyau compilé 
maison en stable est OK.  La compil d'un noyau ne résoudra rien, il me 
semble.
Il faudrait remonter le temps dans tes mises à jour pour trouver quel 
paquet/conf  ont été changés.
' *Ce portable dispose de deux cartes graphiques : une intégrée à la 
carte mère (intel) et une nvidia Geforce.*  '

Egalement, savoir quelle CG est utilisée serait déjà un début.
--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/528d17d6.3020...@gmail.com

Re: Problème de reboot sur portable Asus

[Christophe]

Bonsoir,

Le 20/11/2013 21:13, maderios a écrit :
 Egalement, savoir quelle CG est utilisée serait déjà un début.

Peut être les deux , si Optimus est activé dans le Bios.
J'ai eu de gros soucis avec cette techno sur mon PC portable quand
c'était activé.

A tester en le désactivant .

@+
Christophe.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/528d3713.8010...@stuxnet.org

Re: Nvidia : mode 1920*1080 changé à chaque reboot

[Nicolas FRANCOIS]

Le Mon, 11 Nov 2013 11:24:34 +0100,
François Patte francois.pa...@mi.parisdescartes.fr a écrit :

 Le 10/11/2013 20:56, Nicolas FRANCOIS a écrit :
  Salut.
  
  J'ai réglé avec nvidia-settings le mode par défaut au mode optimal
  de mon écran, soit 1920*1080*60Hz. Lorsque je boote, l'écran de
  connexion est dans le bon mode. Mais quand je me loggue, l'écran
  s'éteint, et se rallume en 1680*1050. Et ça m'énerve...
  
  J'ai cherché dans mon répertoire perso, et ai vu deux choses : un
  fichier .nvidia-settings-rc, qui ne contient pas de résolution par
  défaut, et un répertoire .nv, qui ne contient qu'un sous-répertoire
  GLCache avec deux sous-répertoires aux noms idiots et des trucs
  bizarres dedans.
 
 Que se passe-t-il si on vire ces deux trucs (mv de façon à revenir
 s'il y a un pb)?

Les virer ne change rien (ce qui est plutôt rassurant !)

  Comment faire pour ne pas modifier les réglages du
  fichier /etc/X11/xorg.conf ?
 
 Que contient la section Screen?

Ça :

Section Screen
Identifier Screen0
Device Device0
MonitorMonitor0
DefaultDepth24
Option Stereo 0
Option nvidiaXineramaInfoOrder DFP-0
Option metamodes 1920x1080_60 +0+0
SubSection Display
Depth   24
EndSubSection
EndSection

D'autre part, le fichier Xorg.log.0 contient des choses bizarres. Je le
joins en pièce jointe. Plein de sections qui se répètent, et UNE
mention d'un passage en 1680*1050...

\bye

-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin
[124958.246] 
X.Org X Server 1.12.4
Release Date: 2012-08-27
[124958.246] X Protocol Version 11, Revision 0
[124958.246] Build Operating System: Linux 3.10-3-amd64 x86_64 Debian
[124958.246] Current Operating System: Linux gaston 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64
[124958.247] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-amd64 root=UUID=8394e6cf-aeb2-4fbb-bc58-1b58608120b5 ro vga=773 quiet
[124958.247] Build Date: 21 October 2013  04:49:48PM
[124958.247] xorg-server 2:1.12.4-6+deb7u1 (Moritz Muehlenhoff j...@debian.org) 
[124958.247] Current version of pixman: 0.26.0
[124958.247] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[124958.247] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[124958.247] (==) Log file: /var/log/Xorg.0.log, Time: Tue Nov 12 07:26:38 2013
[124958.250] (==) Using config file: /etc/X11/xorg.conf
[124958.250] (==) Using system config directory /usr/share/X11/xorg.conf.d
[124958.252] (==) ServerLayout Layout0
[124958.252] (**) |--Screen Screen0 (0)
[124958.252] (**) |   |--Monitor Monitor0
[124958.252] (**) |   |--Device Device0
[124958.252] (**) |--Input Device Keyboard0
[124958.252] (**) |--Input Device Mouse0
[124958.252] (**) Option Xinerama 0
[124958.252] (==) Automatically adding devices
[124958.252] (==) Automatically enabling devices
[124958.252] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist.
[124958.252] 	Entry deleted from font path.
[124958.252] (WW) The directory /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType does not exist.
[124958.252] 	Entry deleted from font path.
[124958.252] (==) FontPath set to:
	/usr/share/fonts/X11/misc,
	/usr/share/fonts/X11/100dpi/:unscaled,
	/usr/share/fonts/X11/75dpi/:unscaled,
	/usr/share/fonts/X11/Type1,
	/usr/share/fonts/X11/100dpi,
	/usr/share/fonts/X11/75dpi,
	built-ins
[124958.252] (==) ModulePath set to /usr/lib/xorg/modules
[124958.252] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[124958.252] (WW) Disabling Keyboard0
[124958.252] (WW) Disabling Mouse0
[124958.253] (II) Loader magic: 0x7fdb4da17ae0
[124958.253] (II) Module ABI versions:
[124958.253] 	X.Org ANSI C Emulation: 0.4
[124958.253] 	X.Org Video Driver: 12.1
[124958.253] 	X.Org XInput driver : 16.0
[124958.253] 	X.Org Server Extension : 6.0
[124958.253] (--) PCI:*(0:1:0:0) 10de:1040:10de:0915 rev 161, Mem @ 0xfd00/16777216, 0xf000/134217728, 0xf800/33554432, I/O @ 0xbc00/128, BIOS @ 0x/524288
[124958.253] (II) Open ACPI successful (/var/run/acpid.socket)
[124958.253] (II) LoadModule: extmod
[124958.274] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so
[124958.275] (II) Module extmod: vendor=X.Org Foundation
[124958.275] 	compiled for 1.12.4, module version = 1.0.0
[124958.275] 	Module class: X.Org Server Extension
[124958.275] 	ABI class: X.Org Server Extension, version 6.0
[124958.275] (II) Loading extension SELinux
[124958.275] (II) Loading extension MIT-SCREEN-SAVER
[124958.275] (II) Loading extension XFree86-VidModeExtension

Re: Nvidia : mode 1920*1080 changé à chaque reboot

[maderios]

On 11/12/2013 09:58 AM, Nicolas FRANCOIS wrote:

Le Mon, 11 Nov 2013 11:24:34 +0100,
François Patte francois.pa...@mi.parisdescartes.fr a écrit :


Le 10/11/2013 20:56, Nicolas FRANCOIS a écrit :

Salut.

J'ai réglé avec nvidia-settings le mode par défaut au mode optimal
de mon écran, soit 1920*1080*60Hz. Lorsque je boote, l'écran de
connexion est dans le bon mode. Mais quand je me loggue, l'écran
s'éteint, et se rallume en 1680*1050. Et ça m'énerve...

J'ai cherché dans mon répertoire perso, et ai vu deux choses : un
fichier .nvidia-settings-rc, qui ne contient pas de résolution par
défaut, et un répertoire .nv, qui ne contient qu'un sous-répertoire
GLCache avec deux sous-répertoires aux noms idiots et des trucs
bizarres dedans.


Que se passe-t-il si on vire ces deux trucs (mv de façon à revenir
s'il y a un pb)?


Les virer ne change rien (ce qui est plutôt rassurant !)


Comment faire pour ne pas modifier les réglages du
fichier /etc/X11/xorg.conf ?


Que contient la section Screen?


Ça :

Section Screen
 Identifier Screen0
 Device Device0
 MonitorMonitor0
 DefaultDepth24
 Option Stereo 0
 Option nvidiaXineramaInfoOrder DFP-0
 Option metamodes 1920x1080_60 +0+0
 SubSection Display
 Depth   24
 EndSubSection
EndSection

D'autre part, le fichier Xorg.log.0 contient des choses bizarres. Je le
joins en pièce jointe. Plein de sections qui se répètent, et UNE
mention d'un passage en 1680*1050...


Bonjour
L'utilitaire nvidia-settings permet de générer un fichier ok.
Mon xorg.conf qui marche normalement. Tu peux supprimer la 2° section 
screen screen1 si tu ne veux pas démarrer 2 sessions X en même temps:


xorg.conf pour nvidia à adapter:

# nvidia-settings: X configuration file generated by nvidia-settings
Section ServerLayout
Identifier Layout0
Screen  0  Screen0 0 0
InputDeviceKeyboard0 CoreKeyboard
InputDeviceMouse0 CorePointer
Option Xinerama 0
EndSection

Section Files
EndSection

Section InputDevice

# generated from default
Identifier Mouse0
Driver mouse
Option Protocol auto
Option Device /dev/psaux
Option Emulate3Buttons no
Option ZAxisMapping 4 5
EndSection

Section InputDevice

# generated from default
Identifier Keyboard0
Driver kbd
EndSection

Section InputDevice
Identifier stylus
Driver wacom
Option Device /dev/input/wacom# USB ONLY
Option Type stylus
Option USB on  # USB ONLY
EndSection

Section InputDevice
Identifier eraser
Driver wacom
Option Device /dev/input/wacom# USB ONLY
Option Type eraser
Option USB on  # USB ONLY
EndSection

Section InputDevice
Identifier cursor
Driver wacom
Option Device /dev/input/wacom# USB ONLY
Option Type cursor
Option USB on  # USB ONLY
EndSection

Section InputDevice
Identifier pad
Driver wacom
Option Device /dev/input/wacom# USB ONLY
Option Type pad
Option USB on  # USB ONLY
EndSection

Section InputDevice
Identifier touch
Driver wacom
Option Device /dev/input/wacom# USB ONLY
Option Type touch
Option USB on  # USB ONLY
EndSection

Section Monitor
Identifier Monitor0
VendorName Unknown
ModelName  Eizo SX2462W
HorizSync   31.0 - 76.0
VertRefresh 59.0 - 61.0
#Option DPMS
EndSection

Section Monitor
Identifier Monitor1
VendorName Unknown
ModelName  Eizo SX2462W
HorizSync   31.0 - 76.0
VertRefresh 59.0 - 61.0
EndSection

Section Device
Identifier Device0
Driver nvidia
VendorName NVIDIA Corporation
BoardName  Quadro 600
EndSection

Section Device
Identifier Device1
Driver nvidia
VendorName NVIDIA Corporation
BoardName  Quadro 600
BusID  PCI:1:0:0
Screen  1
EndSection

Section Screen
Identifier Screen0
Device Device0
MonitorMonitor0
DefaultDepth24
Option Stereo 0
Option metamodes DFP-0: nvidia-auto-select +0+0
SubSection Display
Depth   24
#Modes 1920x1200
EndSubSection
EndSection

#FACULTATIF
Section Screen
Identifier Screen1
Device Device1
MonitorMonitor1
DefaultDepth24
Option Stereo 0
Option metamodes DFP-1: nvidia-auto-select +0+0
SubSection Display
Depth   24
#Modes 1920x1200
EndSubSection
EndSection



--
Maderios


--
Lisez la FAQ de la liste avant de poser une question :

Re: Nvidia : mode 1920*1080 changé à chaque reboot

[François Patte]

Le 10/11/2013 20:56, Nicolas FRANCOIS a écrit :
 Salut.
 
 J'ai réglé avec nvidia-settings le mode par défaut au mode optimal de
 mon écran, soit 1920*1080*60Hz. Lorsque je boote, l'écran de connexion
 est dans le bon mode. Mais quand je me loggue, l'écran s'éteint, et se
 rallume en 1680*1050. Et ça m'énerve...
 
 J'ai cherché dans mon répertoire perso, et ai vu deux choses : un
 fichier .nvidia-settings-rc, qui ne contient pas de résolution par
 défaut, et un répertoire .nv, qui ne contient qu'un sous-répertoire
 GLCache avec deux sous-répertoires aux noms idiots et des trucs
 bizarres dedans.

Que se passe-t-il si on vire ces deux trucs (mv de façon à revenir
s'il y a un pb)?

 
 Comment faire pour ne pas modifier les réglages du
 fichier /etc/X11/xorg.conf ?

Que contient la section Screen?



-- 
François Patte
UFR de mathématiques et informatique
Laboratoire CNRS MAP5, UMR 8145
Université Paris Descartes
45, rue des Saints Pères
F-75270 Paris Cedex 06
Tél. +33 (0)1 8394 5849
http://www.math-info.univ-paris5.fr/~patte



signature.asc
Description: OpenPGP digital signature

Re: Nvidia : mode 1920*1080 changé à chaque reboot

[Haricophile]

Le dimanche 10 novembre 2013 20:56:13 Nicolas FRANCOIS a écrit :
 Comment faire pour ne pas modifier les réglages du
 fichier /etc/X11/xorg.conf ?

déjà en transférant la conf dans /etc/X11/xorg.conf.d/

Visite le dossier /usr/share/X11/xorg.conf.d tu verra la conf par défaut 
du packager et ça te donnera un modèle. L'avantage c'est que le 
contenu de ce dossier gère dynamiquement la conf en s'appuyant sur 
UDEV, alors que /etc/X11/xorg.conf est statique. 

Ça ne résoudra peut-être pas ton problème, mais en tout cas ça te 
permet de configurer différents écrans (souris/tablette) en plug'n 
play. C'est la manière moderne de configurer.

-- 
Haricophile - haricoph...@aranha.fr

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/3642566.U7iQDpkr5r@azuki

Nvidia : mode 1920*1080 changé à chaque reboot

[Nicolas FRANCOIS]

Salut.

J'ai réglé avec nvidia-settings le mode par défaut au mode optimal de
mon écran, soit 1920*1080*60Hz. Lorsque je boote, l'écran de connexion
est dans le bon mode. Mais quand je me loggue, l'écran s'éteint, et se
rallume en 1680*1050. Et ça m'énerve...

J'ai cherché dans mon répertoire perso, et ai vu deux choses : un
fichier .nvidia-settings-rc, qui ne contient pas de résolution par
défaut, et un répertoire .nv, qui ne contient qu'un sous-répertoire
GLCache avec deux sous-répertoires aux noms idiots et des trucs
bizarres dedans.

Comment faire pour ne pas modifier les réglages du
fichier /etc/X11/xorg.conf ?

D'avance merci.

\bye

-- 

Nicolas FRANCOIS  |  /\ 
http://nicolas.francois.free.fr   | |__|
  X--/\\
We are the Micro$oft.   _\_V
Resistance is futile.   
You will be assimilated. darthvader penguin

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20131110205613.682d4...@gaston.baronie.vez

Grappe Raid 1 ne se reconstruit plus au reboot

[steve]

Salut,

Hier j'ai dû changer un des deux disques de ma grappe Raid 1, qui avait cramé.
Après cela, j'ai reconstruit ma grappe avec la commande:

mdadm --manage /dev/md0 -add /dev/sdb1

et pareil pour tous les autres /dev/md*. Puis j'ai fait un

mdadm --scan --examine  /etc/mdadm/mdadm.conf

pour mettre à jour ce fichier.

Jusque là, tout s'est passé correctement (un 'cat /proc/mdstat' confirme que la
grappe est bien recréée avec les deux disques). Une heure plus tard, j'insère
une clef usb, la monte, fais mon travail puis la démonte. Soudain, je reçois un
mail d'avertissement de mdadm qui dit que les grappes sont dégradées. Un 'cat
/proc/mdstat' le confirme, seul le disque sda fait encore partie de la grappe.
Après une courte investigation, je m'aperçois que le disque sdb est subitement
devenue sdh ! Étonné, je reconstruit la grappe avec cette nouvelle donnée,
comme ci-dessus. Aujourd'hui je tente un redémarrage de la machine afin de voir
si mon Raid 1 tient après le redémarrage. Résultat négatif, sdh n'est pas pris
en compte, alors même que le nouveau disque est bien vu comme sdh (pas de
changement de lettre comme précédemment). Et là je ne comprends plus. 

J'ai beau avoir fouillé le Net pour une piste mais rien de concluant.

Une idée ? 


Merci d'avance,
s.


Système : Debian wheezy à jour avec noyau 3.2.0-4-amd64

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20130225154026.GA10094@localhost

RE: Reboot

[Boiteux Frederic]

Bonjour Gérald,

  Tu pourrais regarder du coté des touches « SysRq » (voir /proc/sysrq-trigger 
ou la page http://en.wikipedia.org/wiki/Magic_SysRq_key).

   Cdlt,
Fred.
 
-Message d'origine-
De : Gerald [mailto:gerald.ra...@gmail.com] 
Envoyé : lundi 17 septembre 2012 15:28
À : debian-user-french@lists.debian.org
Objet : Reboot

Bonjour,

Le redémarrage d'une debian squeeze ne se fait pas correctement : la machine 
bloque.

Or je n'ai accès à cette machine que par ssh.

Y-a-t-il un moyen de forcer a tout pris le redemerrage en utilisant une 
fonction autre que reboot ou y-a-t-il moyen de voir le problème à la manière 
d'un dmesg ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50572575.8000...@gmail.com

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/C352174B6B58ED4FBA07CFB13C9DAC693327A336@cadine.france.prosodie.local

Fwd: Re: Reboot

[Gerald]

Et sinon un reboot -f m'assure-t-il à 100% un reboot ?

Le 19/09/2012 10:14, Boiteux Frederic a écrit :

Bonjour Gérald,

Tu pourrais regarder du coté des touches « SysRq » (voir 
/proc/sysrq-trigger ou la page http://en.wikipedia.org/wiki/Magic_SysRq_key).

 Cdlt,
Fred.

 -Message d'origine-
 De : Gerald [mailto:gerald.ra...@gmail.com]
 Envoyé : lundi 17 septembre 2012 15:28
 À : debian-user-french@lists.debian.org
 Objet : Reboot

 Bonjour,

 Le redémarrage d'une debian squeeze ne se fait pas correctement : la machine 
bloque.

 Or je n'ai accès à cette machine que par ssh.

 Y-a-t-il un moyen de forcer a tout pris le redemerrage en utilisant une 
fonction autre que reboot ou y-a-t-il moyen de voir le problème à la manière 
d'un dmesg ?

 --
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists

 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: http://lists.debian.org/50572575.8000...@gmail.com





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/505981c7.5060...@gmail.com

Reboot

[Gerald]

Bonjour,

Le redémarrage d'une debian squeeze ne se fait pas correctement : la 
machine bloque.


Or je n'ai accès à cette machine que par ssh.

Y-a-t-il un moyen de forcer a tout pris le redemerrage en utilisant une 
fonction autre que reboot

ou y-a-t-il moyen de voir le problème à la manière d'un dmesg ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/50572575.8000...@gmail.com

Re: Reboot

[Bzzz]

On Mon, 17 Sep 2012 15:28:21 +0200
Gerald gerald.ra...@gmail.com wrote:

 
 Le redémarrage d'une debian squeeze ne se fait pas correctement :
 la machine bloque.
 
 Or je n'ai accès à cette machine que par ssh.

T'es coincé parce que SSH ne se met en branle qu'à la fin du boot
et que de toute façon la policy Debian interdit toute connection
avant la fin effective dudit boot.

-- 
NNawâK: NOUS SOMME UNE GENERATION PERVERTIE PAR LA TELEVISION,
L'ALCOOL, LA DROGUE ET INTERNET !
NawâK: Mais on s'en plaint pas !

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120917154426.35abf111@anubis.defcon1

Re: [testing] reboot brutal

[Gaëtan PERRIER]

Le Thu, 19 Jul 2012 21:20:12 +0200
Gaëtan PERRIER gaetan.perr...@neuf.fr a écrit:

 Salut,
 
 Remontage après retour du SAV et pour l'instant le problème semble avoir
 disparu ...
 
 Gaëtan
 

Après quelques jours sans problème j'ai eu de nouveau un reboot hier soir.
Mon alim faisant du bruit (ventilo à priori) depuis 2 jours je suis allé
l'échanger sous garantie ce midi. Pour l'instant tout fonctionne correctement.
Si ça recommence je sais au moins que ce n'est pas l'alim.

A+

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724224539.22813fa169f9a801a539b...@neuf.fr

Re: [testing] reboot brutal

[Bzzz]

On Tue, 24 Jul 2012 22:45:39 +0200
Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:

 jours je suis allé l'échanger sous garantie ce midi. Pour
 l'instant tout fonctionne correctement. Si ça recommence je sais
 au moins que ce n'est pas l'alim.

Courage, plus que la CM, la CG, la RAM, le CPU et les HDz
à échanger; ça devrait le faire d'ici noël ;-)

-- 
Sinker deux secondes ça sonne
Sinker re
MrBig t'as fait vite
Sinker j'ai pas ouvert c'était juste du spam
MrBig hein ? 
Sinker des témoins de jéhovah
MrBig ha

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724230609.2cd7fe0d@anubis.defcon1

Re: [testing] reboot brutal

[Gaëtan PERRIER]

Le Tue, 24 Jul 2012 23:06:09 +0200
Bzzz lazyvi...@gmx.com a écrit:

 On Tue, 24 Jul 2012 22:45:39 +0200
 Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:
 
  jours je suis allé l'échanger sous garantie ce midi. Pour
  l'instant tout fonctionne correctement. Si ça recommence je sais
  au moins que ce n'est pas l'alim.
 
 Courage, plus que la CM, la CG, la RAM, le CPU et les HDz
 à échanger; ça devrait le faire d'ici noël ;-)

:)

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120724230830.521e6fa426f988def7f7f...@neuf.fr

Re: [testing] reboot brutal

[Gaëtan PERRIER]

Salut,

Remontage après retour du SAV et pour l'instant le problème semble avoir
disparu ...

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120719212012.fa4750232d61c64e5cc22...@neuf.fr

Re: [testing] reboot brutal

[Bzzz]

On Thu, 19 Jul 2012 21:20:12 +0200
Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:

 Remontage après retour du SAV et pour l'instant le problème semble
 avoir disparu ...

Heuu, c'est un peu cavalier de te réparer un micro
sans te dire pourquoi il merdouillait, non?

-- 
printk(ufs_read_super: fucking Sun blows me\n);
-- /usr/src/linux/fs/ufs/ufs_super.c

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120719212944.78a74192@anubis.defcon1

Re: [testing] reboot brutal

[Gaëtan PERRIER]

Le Thu, 19 Jul 2012 21:29:44 +0200
Bzzz lazyvi...@gmx.com a écrit:

 On Thu, 19 Jul 2012 21:20:12 +0200
 Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:
 
  Remontage après retour du SAV et pour l'instant le problème semble
  avoir disparu ...
 
 Heuu, c'est un peu cavalier de te réparer un micro
 sans te dire pourquoi il merdouillait, non?
 

Pour eux il n'y avait pas de problème tout fonctionnait correctement. Ils ont
passé tout un tas de test (install d'un OS, test de stabilité, etc.) sans rien
constater de problématique.
Manifestement le fait de démonter et remonter à changer quelque chose ...

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120719214121.73f6a18562e99ab7bb6eb...@neuf.fr

Re: [testing] reboot brutal

[Bzzz]

On Thu, 19 Jul 2012 21:41:21 +0200
Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:

 Pour eux il n'y avait pas de problème tout fonctionnait
 correctement. Ils ont passé tout un tas de test (install d'un OS,
 test de stabilité, etc.) sans rien constater de problématique.
 Manifestement le fait de démonter et remonter à changer quelque
 chose ...

Cédja+clair; ptêt un soucis de masse avec les entretoises alors...
(ou un exorcisme sauvage en loucédé dans l'arrière-boutique).

-- 
Omane Les hommes, les femmes, quelle différence?
on est tous les mêmes
Neph Voila une réflexion très Bi, Omane
Neph \o/

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120719214814.6162b618@anubis.defcon1

Re: [testing] reboot brutal

[andre_debian]

 On Thu, 19 Jul 2012 21:20:12 +0200
 Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:
  Remontage après retour du SAV et pour l'instant le problème semble
  avoir disparu ...
On Thursday 19 July 2012 21:29:44 Bzzz wrote:
 Heuu, c'est un peu cavalier de te réparer un micro
 sans te dire pourquoi il merdouillait, non?

La boutique : GrosBill ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201207192207.41810.andre_deb...@numericable.fr

Re: [testing] reboot brutal

[Gaëtan PERRIER]

Le Thu, 19 Jul 2012 22:07:41 +0200
andre_deb...@numericable.fr a écrit:

  On Thu, 19 Jul 2012 21:20:12 +0200
  Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:
   Remontage après retour du SAV et pour l'instant le problème semble
   avoir disparu ...
 On Thursday 19 July 2012 21:29:44 Bzzz wrote:
  Heuu, c'est un peu cavalier de te réparer un micro
  sans te dire pourquoi il merdouillait, non?
 
 La boutique : GrosBill ?
 

Non LDLC, Paris 15e.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120719222851.7d310ec83183e148a5f09...@neuf.fr

Re: [testing] reboot brutal

[andre_debian]

On Tuesday 10 July 2012 21:58:57 Gaëtan PERRIER wrote:
 le matos (CM, RAM, alim, proc) est parti au SAV qui lui ne voit pas de
 problème et trouve que tout fonctionne normalement. Le tout a 8 mois.
 La différence entre eux et moi c'est la carte graphique, les disques
 durs et les périphs.

Je ne vois plus que le bouton marche/arrêt ou reset (faux contact),
ou le câble marche/arrêt sur la carte mère.
Retires le et démarres le PC en faisant contact sur les 2 broches
avec un fil ou un petit élément conducteur.

De mon côté, j'ai un reboot mais après l'arrêt du PC.
Lorsque je l'éteins, au bout de quelques minutes aléatoires,
il redémarre sans raison.
Je dois fermer le bouton M/A derrière sur l'alim. pou qu'il ne
redémarre plus.

andré

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201207131233.25883.andre_deb...@numericable.fr

Re: [testing] reboot brutal

[Gaëtan PERRIER]

Le SAV me dit que pour eux tout est ok. 
Est-ce que ça pourrait être ma carte graphique ?

Gaëtan 

Gaëtan PERRIER gaetan.perr...@neuf.fr a écrit :

Le Sat, 30 Jun 2012 11:32:46 +0200
maderios mader...@gmail.com a écrit:

 On 06/27/2012 10:37 PM, Gaëtan PERRIER wrote:
  Salut,
 
  Ce soir j'ai subit 3 reboot brutaux de mon système, successivement,
  sans cause apparente ni aucun message dans les logs
 
 Expérience pouvant être utile.
 J'ai rencontré un problème similaire il y a quelques mois. C'était 
 l'alimentation (Enermax très chère certifiée Gold  et heureusement 
 garantie) qui était défaillante : tensions instables. Problème résolu 
 par le remplacement de cette alimentation.
 M
 

J'ai ramené la CM, l'alim, le CPU et la RAM au SAV. On va voir ce
qu'ils vont dire.

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120630172727.4f8c403b48b5c7f2e98a1...@neuf.fr

Re: [testing] reboot brutal

[Bzzz]

On Tue, 10 Jul 2012 11:34:55 +0200
Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:

 Le SAV me dit que pour eux tout est ok. 
 Est-ce que ça pourrait être ma carte graphique ?

C'est possible, mais peu probable.

Dans l'ordre d'importance, 'gade:

* La RAM (re-teste qd même! + reboot après les tests et
  vérifie de suite les températures CM, CPU, RAM, HDz -
  lm-sensors  hddtemp),

* Les logs et/ou ton mod'op juste avant que ça plante;
  il est possible qu'un exécutable soit abîmé et effectue
  une violation de privilèges | segfault qui plante tout,

* La mécanique: j'ai un vieux celeron 333 monté dans un
  boîtier pourri qui me soulève les cartes addons d'au moins
  4mm; pour éviter des plantages dûs à la mobilité des cartes
  il a fallu mettre des rondelles sous les vis de maintient
  (trop souké/enfoncé c'est aussi mauvais que pas assez) et
  un câble d'acier tendu qui les maintient enfoncées 
  correctement du côté libre...

* Vérifier dans les logs s'il ne se passe rien du côté des HDz
  là encore, j'ai un ch'tit svr qui a nécessité de *souder* les
  fils d'alim à cause du desserrement des MOLEX dû aux vibrations
  hautes fréquences (pas conseillé du tout, mais bon, ça roule
  comme ça) - smart et ses utilitaires + test long + logs
  conventionnels (apparition d'erreurs concernant les HDz).
  Un bon témoin de tels PBs est un claquement et/ou un bruit
  comme au démarrage parce que le HD a temporairement perdu
  son alim est ré-entame le processus de démarrage comme au boot,

* Vérifier sur le web si qqun n'a pas les mêmes PBs avec le
  *même* équipement - il peut arriver que des incompatibilités
  (notamment CM-CG) provoquent de tels PBs,

* ET ça peut aussi venir d'une claque électrique ayant
  individuellement affectée chaque composant sensible;
  et que le fait de les réunir additionne les problèmes
  dans le même sens:(

JY
-- 
Woman is generally so bad that the difference between a good and a
bad woman scarcely exists.
-- Tolstoy

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120710184755.7daf803e@anubis.defcon1

Re: [testing] reboot brutal

[Gaëtan PERRIER]

Le Tue, 10 Jul 2012 18:47:55 +0200
Bzzz lazyvi...@gmx.com a écrit:

 On Tue, 10 Jul 2012 11:34:55 +0200
 Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:
 
  Le SAV me dit que pour eux tout est ok. 
  Est-ce que ça pourrait être ma carte graphique ?
 
 C'est possible, mais peu probable.
 
 Dans l'ordre d'importance, 'gade:
 
 * La RAM (re-teste qd même! + reboot après les tests et
   vérifie de suite les températures CM, CPU, RAM, HDz -
   lm-sensors  hddtemp),
 
 * Les logs et/ou ton mod'op juste avant que ça plante;
   il est possible qu'un exécutable soit abîmé et effectue
   une violation de privilèges | segfault qui plante tout,

Non même en étant dans le BIOS ça reboote pareil. Ce n'est pas lié à
Linux.

 
 * La mécanique: j'ai un vieux celeron 333 monté dans un
   boîtier pourri qui me soulève les cartes addons d'au moins
   4mm; pour éviter des plantages dûs à la mobilité des cartes
   il a fallu mettre des rondelles sous les vis de maintient
   (trop souké/enfoncé c'est aussi mauvais que pas assez) et
   un câble d'acier tendu qui les maintient enfoncées 
   correctement du côté libre...

Je re-regarderai mais tout me semblait ok quand j'ai regardé l'autre
fois.

 
 * Vérifier dans les logs s'il ne se passe rien du côté des HDz
   là encore, j'ai un ch'tit svr qui a nécessité de *souder* les
   fils d'alim à cause du desserrement des MOLEX dû aux vibrations
   hautes fréquences (pas conseillé du tout, mais bon, ça roule
   comme ça) - smart et ses utilitaires + test long + logs
   conventionnels (apparition d'erreurs concernant les HDz).
   Un bon témoin de tels PBs est un claquement et/ou un bruit
   comme au démarrage parce que le HD a temporairement perdu
   son alim est ré-entame le processus de démarrage comme au boot,

Non plus, sinon dans le BIOS je n'aurai pas de problème.

 
 * Vérifier sur le web si qqun n'a pas les mêmes PBs avec le
   *même* équipement - il peut arriver que des incompatibilités
   (notamment CM-CG) provoquent de tels PBs,

Oui je vais essayer de chercher, on ne sait jamais effectivement.

 
 * ET ça peut aussi venir d'une claque électrique ayant
   individuellement affectée chaque composant sensible;
   et que le fait de les réunir additionne les problèmes
   dans le même sens:(

Mouais j'y crois autant qu'au bombardement neutronique...

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120710202820.661cb72ebb361fc44884f...@neuf.fr

Re: [testing] reboot brutal

[Bzzz]

On Tue, 10 Jul 2012 20:28:20 +0200
Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:

 
 Non même en étant dans le BIOS ça reboote pareil. Ce n'est pas lié
 à Linux.

Ah, on avance, donc on se dirige vers le matériel.

  * La mécanique: j'ai un vieux celeron 333 monté dans un
boîtier pourri qui me soulève les cartes addons d'au moins
4mm; pour éviter des plantages dûs à la mobilité des cartes
il a fallu mettre des rondelles sous les vis de maintient
(trop souké/enfoncé c'est aussi mauvais que pas assez) et
un câble d'acier tendu qui les maintient enfoncées 
correctement du côté libre...
 
 Je re-regarderai mais tout me semblait ok quand j'ai regardé
 l'autre fois.

Ça peut-être very sneaky (les vibrations coupent ou établissent le
contact qu'il ne faut pas).  Titille les cartes (2-3 mm de jeu
transversal et qq poils de cul en vertical) pour voir.

Et pour commencer: vire-les toutes (sauf la CG, œuf corse) et
re-teste.

  * Vérifier dans les logs s'il ne se passe rien du côté des HDz
là encore, j'ai un ch'tit svr qui a nécessité de *souder* les
fils d'alim à cause du desserrement des MOLEX dû aux vibrations
hautes fréquences (pas conseillé du tout, mais bon, ça roule
comme ça) - smart et ses utilitaires + test long + logs
conventionnels (apparition d'erreurs concernant les HDz).
Un bon témoin de tels PBs est un claquement et/ou un bruit
comme au démarrage parce que le HD a temporairement perdu
son alim est ré-entame le processus de démarrage comme au boot,
 
 Non plus, sinon dans le BIOS je n'aurai pas de problème.

Faux, ça peut tout à fait faire rebooter la machine parce que le
BIOS n'a que cette option de failsafe en cas de coupure des liaisons
ATA/SATA au mauvais moment; à moins qu'il ne supporte (réellement!)
le hot plug, et encore.
Attention aussi aux rallonges d'alim de mauvaise qualité et aux
vibrations transmises via les câbles en contact avec ce qui vibre.

  * Vérifier sur le web si qqun n'a pas les mêmes PBs avec le
*même* équipement - il peut arriver que des incompatibilités
(notamment CM-CG) provoquent de tels PBs,
 
 Oui je vais essayer de chercher, on ne sait jamais effectivement.

Pour ça, laisse tomber le français; le parc n'est pas assez étendu
pour tomber sur la même config ici:(

  * ET ça peut aussi venir d'une claque électrique ayant
individuellement affectée chaque composant sensible;
et que le fait de les réunir additionne les problèmes
dans le même sens:(
 
 Mouais j'y crois autant qu'au bombardement neutronique...

Tout dépend d'où tu es (ville/campagne/grotte/Hte
altitude/sous-marin) ET de la protection de ta maison/appart.
Un jour, j'ai trouvé un excellent article sur les prises de
terre fait par un électronicien qui démontrait simplement 
pourquoi on ne peut pas juger de la qualité d'une terre
sans équipement spécifique à haute impédance d'entrée.

Quand au bombardement neutronique, c'est peu plausible: ça aurait
_aussi_ fait des dégâts dans le cerveau de l'OP (quoique...),
mais des particules à haute énergie c'est bleu-suppo: c'est la
bonne année pour ça;)

-- 
Chocolate chip.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120710205325.657b67cc@anubis.defcon1

Re: [testing] reboot brutal

[Jérôme]

Le mardi 10 juillet 2012 à 20:28 +0200, Gaëtan PERRIER a écrit :
 Non même en étant dans le BIOS ça reboote pareil. Ce n'est pas lié à
 Linux. 

Si ça reboot même dans le bios, c'est clairement matériel. 

- Croise l'alim avec une autre

- vérifie les masses tant côté isolation (manque d'une rondelle...) que
de la bonne mise à la masse de ce qui doit l'être (ça peut faire des
trucs zarbi).

- Vérifie que tu n'ai pas un connecteur oxydé en particulier du côté des
connecteurs d'alim (ça peut s'oxyder assez rapidement en cas de contact
de mauvaise qualité) voire un fil mal sertis.

-Vérifie que tu n'ai pas une pine tordue dans un connecteur.

- Jette un œil sur la qualité des soudures, surtout côté de ce qui tire
du jus, et contrôle qu'il n'y ait pas une piste coupé à cause d'une
contrainte mécanique (fréquent sur les alim de portable, mais ça peut
aussi faire court-jus s'il y a un truc qui bouge sur un connecteur
quelconque).

- Vérifie que les processeurs et composants fixés mécaniquement, si la
carte est un peu ancienne, vérifie si la pâte thermique est bonne, et si
elle est neuve qu'elle soit bien répartie sans déborder.

etc. etc. etc. 

Bref, la maintenance c'est comme la médecine, le plus dur est le
diagnostic, un peu de matos comme un oscilloscope aide parfois...



-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/1341946588.13885.18.camel@jisui.aranha

Re: [testing] reboot brutal

[Gaëtan PERRIER]

Pour éviter de se répéter un petit résumer :

le matos (CM, RAM, alim, proc) est parti au SAV qui lui ne voit pas de
problème et trouve que tout fonctionne normalement. Le tout a 8 mois.
La différence entre eux et moi c'est la carte graphique, les disques
durs et les périphs.

La suite est insérée ci dessous.

Le Tue, 10 Jul 2012 20:56:28 +0200
Jérôme jer...@aranha.fr a écrit:

 Le mardi 10 juillet 2012 à 20:28 +0200, Gaëtan PERRIER a écrit :
  Non même en étant dans le BIOS ça reboote pareil. Ce n'est pas lié à
  Linux. 
 
 Si ça reboot même dans le bios, c'est clairement matériel. 
 
 - Croise l'alim avec une autre

Pour le SAV elle est ok et je n'en ai pas d'autre.

 
 - vérifie les masses tant côté isolation (manque d'une rondelle...)
 que de la bonne mise à la masse de ce qui doit l'être (ça peut faire
 des trucs zarbi).

Tu vérifies ça comment ?

 
 - Vérifie que tu n'ai pas un connecteur oxydé en particulier du côté
 des connecteurs d'alim (ça peut s'oxyder assez rapidement en cas de
 contact de mauvaise qualité) voire un fil mal sertis.

Je regarderai quand je récupérerai le matos.

 
 -Vérifie que tu n'ai pas une pine tordue dans un connecteur.

Vu que j'ai branché le tout il y a 8 mois et que ça a fonctionné
parfaitement pendant 8 mois moins 4 jours ...

 
 - Jette un œil sur la qualité des soudures, surtout côté de ce qui
 tire du jus, et contrôle qu'il n'y ait pas une piste coupé à cause
 d'une contrainte mécanique (fréquent sur les alim de portable, mais
 ça peut aussi faire court-jus s'il y a un truc qui bouge sur un
 connecteur quelconque).

Ce n'est pas un portable.

 
 - Vérifie que les processeurs et composants fixés mécaniquement, si la
 carte est un peu ancienne, vérifie si la pâte thermique est bonne, et
 si elle est neuve qu'elle soit bien répartie sans déborder.

T'arrives un peu après la guerre, ça a été fait avant l'envoi au
SAV. ;)


Gaëtan

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120710215857.80471067b2c35640343e8...@neuf.fr

Re: [testing] reboot brutal

[Bzzz]

On Tue, 10 Jul 2012 21:58:57 +0200
Gaëtan PERRIER gaetan.perr...@neuf.fr wrote:

  - Croise l'alim avec une autre
 
 Pour le SAV elle est ok et je n'en ai pas d'autre.

Mais surveille-les, dès fois qu'elle fasse des petits...

  - vérifie les masses tant côté isolation (manque d'une
  rondelle...) que de la bonne mise à la masse de ce qui doit
  l'être (ça peut faire des trucs zarbi).
 
 Tu vérifies ça comment ?

Tu ne vérifies rien du tout: SI le point d'ancrage est destiné à
être hors masse, le dégagement nécessaire est prévu pour éviter
tout contact électrique avec l'entretoise, SI c'est le contraire,
c'est... le contraire :-)
En Gal la CM est prévue pour avoir des points de masse un peu partout
pour éviter les pompages et autres latchups.

  - Vérifie que tu n'ai pas un connecteur oxydé en particulier du
  côté des connecteurs d'alim (ça peut s'oxyder assez rapidement
  en cas de contact de mauvaise qualité) voire un fil mal sertis.
 
 Je regarderai quand je récupérerai le matos.

À part si tu habites outremer (et au bord de la mer) yapeudchances
(surtout avec des connecteurs dorés ou en laiton...)

  -Vérifie que tu n'ai pas une pine tordue dans un connecteur.
 
 Vu que j'ai branché le tout il y a 8 mois et que ça a fonctionné
 parfaitement pendant 8 mois moins 4 jours ...

Ceci est du ressort de ta vie sexuelle privée (déviante,
oléagineuse et superfétatoire), et ne nous... regarde pas. ];-)

-- 
I am a deeply superficial person. -Andy Warhol

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120710221924.7f1a2ba7@anubis.defcon1

Re: [testing] reboot brutal

[luc schimpf]

Passionnant débat, mais en pratique, comment le béotien fait pour 
choisir son alim ?




Le 01/07/2012 00:12, Gaëtan PERRIER a écrit :

Le Sat, 30 Jun 2012 22:48:03 +0200
Bzzzlazyvi...@gmx.com  a écrit:



Bcp plus technicien qu'audiophile; et pour ce qui est de l'allusion,
c'est simplement parce qu'un bon ampli c'est avant toute chose une
excellente alimentation - j'ai un super 2x400WRMS sous le coude,
l'électronique ne coûte pas très cher (mais nécessite un appariement
précis des MOS-FET); le PB c'est qu'il y en a pour plus de €1,500
rien qu'en chimiques haute température, faible DV/DT).


Ce qui nous amène bien loin d'une alim à découpage. On est plutôt dans
les transfos en tout genre, non ?

Gaëtan




--

Luc Schimpf
www.au-ptit-bon-air.eu

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4ff00f51.30...@free.fr

Re: [testing] reboot brutal

[Gaëtan PERRIER]

Et bien c'est la loterie !

Gaëtan

Le Sun, 01 Jul 2012 10:50:25 +0200
luc schimpf luc...@free.fr a écrit:

 Passionnant débat, mais en pratique, comment le béotien fait pour 
 choisir son alim ?
 
 
 
 Le 01/07/2012 00:12, Gaëtan PERRIER a écrit :
  Le Sat, 30 Jun 2012 22:48:03 +0200
  Bzzzlazyvi...@gmx.com  a écrit:
 
 
  Bcp plus technicien qu'audiophile; et pour ce qui est de
  l'allusion, c'est simplement parce qu'un bon ampli c'est avant
  toute chose une excellente alimentation - j'ai un super 2x400WRMS
  sous le coude, l'électronique ne coûte pas très cher (mais
  nécessite un appariement précis des MOS-FET); le PB c'est qu'il y
  en a pour plus de €1,500 rien qu'en chimiques haute température,
  faible DV/DT).
 
  Ce qui nous amène bien loin d'une alim à découpage. On est plutôt
  dans les transfos en tout genre, non ?
 
  Gaëtan
 
 
 
 -- 
 
 Luc Schimpf
 www.au-ptit-bon-air.eu
 
 -- 
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists
 
 Pour vous DESABONNER, envoyez un message avec comme objet
 unsubscribe vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: http://lists.debian.org/4ff00f51.30...@free.fr


-- 
Gaëtan PERRIER gaetan.perr...@neuf.fr

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701125353.7ec5dbb9bbef5f51b9a0c...@neuf.fr

Re: [testing] reboot brutal

[Bzzz]

On Sun, 01 Jul 2012 10:50:25 +0200
luc schimpf luc...@free.fr wrote:

 Passionnant débat, mais en pratique, comment le béotien fait pour 
 choisir son alim ?

Le mieux c'est de privilégier la proximité et d'aller voir ton
vendeur en ville; ça n'est pas son intérêt de te refiler de la
camelote, et s'il est sérieux non-seulement il te conseillera
correctement mais il te fera aussi un échange standard s/s
garantie en cas de pépin (toujours possible).

Évidemment, si tu n'y va QUE pour ça et qu'il s'en aperçoit, ne
t'étonnes pas qu'il évite de perdre son temps avec toi - les 
commerces de proximité sont certes plus chers, mais c'est le jour
où ils auront presque disparus que tu comprendras ta douleur…

-- 
ju le seigneur ne touche plus grand monde ...
fab les pretres s'occupent de ca pour lui

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701135820.2cd40267@anubis.defcon1

Re: [testing] reboot brutal___Vraiment HS

[andre_debian]

On Saturday 30 June 2012 21:24:42 Yves Rutschle wrote:
 On Sat, Jun 30, 2012 at 08:00:47PM +0200, andre_deb...@numericable.fr wrote:
  Il est préférable de ne pas acheter une Alim à prix inférieur,
  si vous voulez éviter une panne rapide ou ... l'incendie.

 Il suffit d'installer un pare-feu, tel que OpenOffice :

Je suis pas Christine Albanel ...

On Sunday 01 July 2012 10:50:25 luc schimpf wrote:
 Passionnant débat, mais en pratique, comment le béotien fait pour
 choisir son alim ?

Toutes alims de marque, qui supportent les pics de tension,
puissance (Watt) adaptée à l'ordinateur, 
avec surtout la mention : Certification 80 PLUS.

Le must : 
alimentation - 80+Platinum, 1200W,
Condensateurs électrolytiques japonais,
SafeGuard protection des circuits à multiples niveaux :
314 Euro

andré

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/201207011729.07220.andre_deb...@numericable.fr

Re: [testing] reboot brutal___Vraiment HS

[Bzzz]

On Sun, 1 Jul 2012 17:29:07 +0200
andre_deb...@numericable.fr wrote:

 avec surtout la mention : Certification 80 PLUS.

On devrait aussi créer une mention Gogo Plus tiens.
 
 Le must : 
 alimentation - 80+Platinum, 1200W,
 Condensateurs électrolytiques japonais,

Faut espérer que c'est pas du sony...
Et pour les autres fabricants, ils ne sont nippons ni mauvais.

 SafeGuard protection des circuits à multiples niveaux :

Jamais encore vu une quelconque alim gd-public résister à un 
transitoire  100KV (une paille par rapport à un choc
fulgurant).

 314 Euro

A ce prix là j'en prend une grosse (12 12aines).

-- 
ptinou: non moi le seul truc qui m'a surpris avec vista
ptinou: c'est quand il m'a dit qu'il allait désactiver 
mon clavier pour la stabilité de mon système

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701175517.2203d60d@anubis.defcon1

Re: [testing] reboot brutal___Vraiment HS

[Gaëtan PERRIER]

Le Sun, 1 Jul 2012 17:29:07 +0200
andre_deb...@numericable.fr a écrit:


 Toutes alims de marque, qui supportent les pics de tension,
 puissance (Watt) adaptée à l'ordinateur, 
 avec surtout la mention : Certification 80 PLUS.
 
 Le must : 
 alimentation - 80+Platinum, 1200W,

1200W, c'est quoi ton PC ? Pour 99% des machines 400 à 500W suffisent
amplement ...

Gaëtan

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701192651.7f06281c0def06e4624bf...@neuf.fr