Re: système qui ne démarre plus

[Pascal Hambourg]

Le 28/02/2018 à 07:43, Jean-Marc a écrit :

Pascal Hambourg  écrivait :


Tu peux essayer de créer une copie de GRUB dans le chemin de support
amovible du disque depuis un shell dans le système installé (via chroot
ou l'installateur Debian en mode rescue) avec


Tu peux préciser un peu ?
En mode rescue (comme lors d'une install d’ailleurs), le ou  les FS sont montés 
sur /target.
Le mode rescue te permet de démarrer un shell dans son root ou en chroot 
/target.


En chroot target.


Que veux-tu dire par créer une copie de GRUB dans le chemin de support amovible 
du disque ?


grub-install --removable


man dit :
--removable
the installation device is removable.

Hum.  Ça signale juste que le périphérique est amovible, quoi.


Mais non. C'est juste une expression pour désigner l'emplacement du 
chargeur par défaut, qui est la seule façon d'amorcer un support 
amovible (mais pas seulement).

Re: système qui ne démarre plus

[Jean-Marc]

Wed, 28 Feb 2018 07:25:39 +0100
Pascal Hambourg  écrivait :

> Non, efibootmgr ne "voit" jamais les disques. Il n'affiche que les 
> variables de boot EFI correspondant aux systèmes d'exploitations 
> enregistrés (aucun ici) et aux chargeurs présents dans le chemin de 
> support amovible des disques (ici celui de la clé USB Kingston).

OK.

> 
> Il arrive que le firmware UEFI se détraque, perde les entrées 
> entregistrées et/ou n'accepte plus d'en enregistrer.

Apparemment, c'est le cas.

> 
> Tu peux essayer de créer une copie de GRUB dans le chemin de support 
> amovible du disque depuis un shell dans le système installé (via chroot 
> ou l'installateur Debian en mode rescue) avec

Tu peux préciser un peu ?
En mode rescue (comme lors d'une install d’ailleurs), le ou  les FS sont montés 
sur /target.
Le mode rescue te permet de démarrer un shell dans son root ou en chroot 
/target.

Que veux-tu dire par créer une copie de GRUB dans le chemin de support amovible 
du disque ?

> grub-install --removable

man dit :
--removable
   the installation device is removable.

Hum.  Ça signale juste que le périphérique est amovible, quoi.

Merci pour le coup de main.

Jean-Marc 


pgpjPrvT3cLUl.pgp
Description: PGP signature

Re: système qui ne démarre plus

[Pascal Hambourg]

Le 28/02/2018 à 00:29, Jean-Marc a écrit :

Pascal Hambourg  écrivait :


Qu'affiche "efibootmgr -v" ?


BootCurrent: 
Timeout: 0 seconds
BootOrder: 2001,2002,2003
Boot* USB HDD: KingstonDataTraveler
Boot2001* EFI USB DeviceRC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

Bizarre, on dirait qu'il ne voit pas mon disque interne.


Non, efibootmgr ne "voit" jamais les disques. Il n'affiche que les 
variables de boot EFI correspondant aux systèmes d'exploitations 
enregistrés (aucun ici) et aux chargeurs présents dans le chemin de 
support amovible des disques (ici celui de la clé USB Kingston).


Il arrive que le firmware UEFI se détraque, perde les entrées 
entregistrées et/ou n'accepte plus d'en enregistrer.


Tu peux essayer de créer une copie de GRUB dans le chemin de support 
amovible du disque depuis un shell dans le système installé (via chroot 
ou l'installateur Debian en mode rescue) avec


grub-install --removable

Re: système qui ne démarre plus

[Jean-Marc]

Tue, 27 Feb 2018 23:28:55 +0100
Pascal Hambourg  écrivait :

> Qu'affiche "efibootmgr -v" ?

BootCurrent: 
Timeout: 0 seconds
BootOrder: 2001,2002,2003
Boot* USB HDD: KingstonDataTraveler
Boot2001* EFI USB DeviceRC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

Bizarre, on dirait qu'il ne voit pas mon disque interne.


Jean-Marc 


pgpeaOcIinNtT.pgp
Description: PGP signature

Re: debian et le français

[Jean-Michel OLTRA]

Bonjour,


Le mardi 27 février 2018, G2PC a écrit...


> >> Sur mes autres machines, il n'y a que LANG=fr_FR.UTF-8 et j'ai ces
> >> applications en français. Ce qui ne m'empêche pas d'essayer.
> > Autre idée : lancer l'appli sous `strace` pour voir quels fichiers sont
> > recherchés, et ce qui pourrait coincer.

> Qui pour rajouter un complément de 2 lignes sur " strace " svp ?

Je peux le faire !

strace -f -o strace.log la-commande-que-je-veux-tracer
Avec la ligne précédente, tu enregistres tout, ça peut faire beaucoup.

Tu peux rajouter un filtre pour les appels système :
strace -f -o strace.log -eopen la-commande-que-je-veux-tracer

Tu peux rajouter -eread pour les appels en lecture.

Ensuite tu lis strace.log avec un pager (less, more…).

Sur un processus déjà en route, tu peux utiliser l'option
`-p pid-du-processus` pour rattacher strace au processus.

Je me sers de strace plutôt basiquement. La page de man pourra t'en dire
plus.

-- 
jm

Re: système qui ne démarre plus

[Pascal Hambourg]

Le 27/02/2018 à 23:03, Jean-Marc a écrit :


J'ai un portable Debian/buster+sid qui ne démarre plus.
Quand je l'allume, il m'indique qu'il ne trouve pas de périphérique bootable.

(...)

Mais quand j'essaie un grub-install, j'ai une erreur :
Could not prepare Boot variable: No such file or directory
grub-install: error: efibootmgr failed to register the boot entry: input/output 
error.


Qu'affiche "efibootmgr -v" ?


Ce serait pas lier avec le correctif Meltdown qui a laissé des PCs impossible à 
démarrer ?


Quel correctif ?

Re: debian et le français

[G2PC]

Le 27/02/2018 à 07:16, Jean-Michel OLTRA a écrit :
>> Sur mes autres machines, il n'y a que LANG=fr_FR.UTF-8 et j'ai ces
>> applications en français. Ce qui ne m'empêche pas d'essayer.
> Autre idée : lancer l'appli sous `strace` pour voir quels fichiers sont
> recherchés, et ce qui pourrait coincer.

Qui pour rajouter un complément de 2 lignes sur " strace " svp ?

système qui ne démarre plus

[Jean-Marc]

salut la liste,

J'ai un portable Debian/buster+sid qui ne démarre plus.
Quand je l'allume, il m'indique qu'il ne trouve pas de périphérique bootable.

Je suis donc passé sur une clé d'install en mode rescue.
J'ai vérifié tous les filesystems.  Tout a l'air bien.

Le système de rescue me permet même de tout monter et de mettre le sytème à 
jour.

J'ai d'abord pensé à un soucis de disque mais smartctl me dit que tout va bien.

Mais quand j'essaie un grub-install, j'ai une erreur :
Could not prepare Boot variable: No such file or directory
grub-install: error: efibootmgr failed to register the boot entry: input/output 
error.

Ce serait pas lier avec le correctif Meltdown qui a laissé des PCs impossible à 
démarrer ?


Jean-Marc 


pgpF32_p_XnO6.pgp
Description: PGP signature

Re: [testing] Firefox 58 et problème avec certains sites

[G2PC]

Le 27/02/2018 à 00:51, Gaëtan Perrier a écrit :
> Bonjour,
>
> Je suis sous tesitng avec Firefox 58 (paquet debain) et je rencontre un
> problème avec le site crucial.fr qui est très très lent à s'afficher et encore
> pas complètement. Par exemple sur cette page:
> http://www.crucial.fr/fra/fr/aide-ssd 
> Tous n'est pas chargé et impossible de sélectionner un modèle.
>
> Par contre aucun problème avec Chromium.
>
> Pouvez-vous me dire si c'est pareil pour vous ?
>
> Gaëtan
Moi ça passe.

58.0.2 (64 bits)

Moi par contre, depuis la mise à jour de firefox certains onglets
plantent, ok je sort, je me trompe de distribution à nouveau, je suis
sous mint stable.



signature.asc
Description: OpenPGP digital signature

Re: blocage installeur debian : "please insert the disc"

[G2PC]

Le 26/02/2018 à 23:24, kevin a écrit :
> Bonsoir,
>
>
> tentative d'install de stretch sur un machine pas récente, un portable ACER 
> Aspire 1641WLMi.
>
> Install par cdrom netinst (le bios de cette machine ne propose pas d'option 
> de boot sur USB).
>
>
> Début d'install normal, accès au dhcp, accès à internet pour le serveur de 
> temps ; vers la fin de l'étape « installer le système de base », alors que 
> 72% de cette phase se sont déroulés sans pb (récupération, décompression, 
> configuration de tout un tas de paquets), blocage sur le message :
>  -
> [!!] Installer le système de base
> /media/cdrom: Please insert the dis labeled 'Debian GNU/Linux 9.3.0 -Stretch- 
> -Official i386 NETINSNT 20171209-13:03' in the drive '/media/cdrom' ans press 
> [Enter].
> Media change
>    
> -
>
>
>
> Appuyer sur l'un ou l'autre des boutons ne change rien. 
> Le cdrom est bien dans son lecteur depuis le début de l'install.
>
> Même comportement avec des cd « netinst » pour buster, jessie, wheezy (gravés 
> à vitesse lente) ; idem avec wheezy cd1 d'installation sans réseau
>
> Sortir le cdrom du lecteur avec un trombone (pas possible autrement), puis le 
> réinsérer ne change rien.
>
> Changer de schéma de partitionnement ne change rien donc il semble que ce ne 
> soit pas un problème de partition saturée.
>
>
> Juste avant tentatives de réinstall, la machine tournait très bien sous 
> wheezy. Un vieux cdrom netinst de squeeze installe sans problème (tout en 
> i386 si précision utile).
>
> Une idée de l'origine de ce blocage ?

Aucune idée, désolé.
Quand je lis ton message, ça me rappel à un autre problème que j'ai
rencontré, ça me semble très proche, mais, en fait, ça n'a peut être
rien à voir.

Survole quand même les mots clés et propositions faites :
https://www.visionduweb.eu/forum/os-gnu-linux/1236-installeur-cle-usb-debian-ne-monte-pas-le-lecteur-cd#1710

Re: SoS Grub - Windows m'a tué - Ou bien un noyau en forme de pépin

[G2PC]

Le 27/02/2018 à 22:09, G2PC a écrit :
>
> Bonjour les gens doués, je cherche de l'aide pour Grub, actuellement,
> mes systèmes ne démarrent plus " normalement ".
>
> Déjà, beaucoup de courage à celui, ou à celle, qui prendra le temps de
> lire mon poste, j'ai tenté d'être précis dans ce qui m'arrive, et
> d'expliquer l'objectif à atteindre.
> Si mes explications sont trops longues, peut être que le pastebin en
> dira directement plus, à ceux qui savent le comprendre :
>
> https://pastebin.com/6px5X85a
>
>
>
> Hier encore, j'avais un grub "je pense" placé sur mon 3ème disque, qui
> me proposait de charger linux mint / linux mint / windows 10.
> ( J'avais aussi un grub, sur mon disque 2, 1 dédié à linux, le second
> à windows, plusieurs partitions sur le disque 2, 2 systèmes. )
> C'est d'ailleurs l'installation du 3eme disque et de mint, qui m'avait
> enfin permis d'avoir mon multiboot windows fonctionnel.
> Ça a presque tenu 1 an ...
>
> Voilà que Windows, je pense, vient de gacher mon plaisir. La mise à
> jour a redémarrée plusieurs fois, et, j'ai raté le coche pour le choix
> du menu windows.
> ( j'ai rebotté sur un linux par défaut. )
>
> Je suis actuellement repassé en legacy, il me semblait d'ailleurs être
> resté à legacy toute l'année passée.
> Je crois qu'il est possible que la mise à jour de windows m'ait fait
> repasser en UEFI (?) Voir mon test avec boot repair.
>
> Bref, depuis celle mise à jour Windows, j'ai eu un écran noir et tiret
> blanc statique.
> J'ai lu que ça pouvait aussi être un soucis de kernel, et, je me suis
> empressé de revenir en arrire de 2 kernel, sur mon 3eme disque, mais
> rien n'a changé.
> ( Je venais aussi de faire la mise à jour des kernel .. c'était la
> journée mises à jour. )
>
> Au menu de démarrage, j'avais alors toujours l'écran noir au tiret
> blanc statique.
>
> Pressé de me dépatouiller en faisant n'importe quoi, j'ai installé
> boot-repair, d'abord sur l'os du disque 3, puis, sur l'os du disque 2.
> Une fois, deux fois, trois fois, mes tests n'ont rien changés, écran
> noir tiret blanc, et, quatre fois, j'empire la situation, en le
> testant sur mon linux disque 3 puis encore sur mon linux disque 2 (
> dont le disque est partagé avec windows 10 ) ( je crois voir
> d'ailleurs que les partitions sont en gpt ici, il me semble. )
>
>
> Le disque 1 est un disque de stockage. J'avais choisi d'installer le
> systeme sur le SSD, le disque 2. De réserver le disque 1 plus
> important au stockage, et, j'ai pris un 3eme disque, pour me servir
> d'os de secours si jamais.
>
>
> Bon, actuellement, dans le bios, en legacy, je ne peux pas mettre mon
> disque 3 en choix de démarrage numéro 1. ... Ceci explique peut etre
> le message d'erreur grub rescue.
> Ah oui, entre temps, ce n'est plus l'écran noir au tiret blanc, mais,
> un grub rescue. ( Merci à boot-repair, je crois avoir cocher /
> décocher des options EFI )
> ( plouf plouf, ah mince, fallait peut être pas... )
>
> Si je passe en UEFI, je peux choisir le grub de windows ( d'ailleurs,
> j'ai intallé aussi grub2 pour windows pour tenter de récupérer un
> multiboot j'ai donc 2 choix de grub windows, grub2win et grub manager
> windows, carrément deux ... ^ alors que ceux de windows, je n'en veux
> pas plus que ça ... )
> Si je choisi le grub de windows, pas de soucis, je boot direct sur
> windows, tout ça tout ça ^ ... sans avoir de dual ou triple choix de
> boot ( pouasse )
>
> Si je choisi le grub de ubuntu proposé, je " crois " que je retombe
> actuellement sur une erreur de grub rescue.
> J'ai tenté de lire le man, mais, les quelques tests effectués avec ls
> ne me semble pas du tout concluants.
>
> La seule façon pour moi, actuellement, de lancer mon dualboot ( sans
> avoir le choix d'option de windows ) ( donc, de choisir entre linux et
> linux ) est de faire f12 au démarrage et de choisir le disque 3 du
> mode legacy. ( il démarre, et, me propose le choix entre linux du
> disque 3 et le linux du disque 2, je rappel que le disque 2 est
> partagé avec windows. )
>
>
> J'aimerais bien ne plus avoir de message d'erreur ( grub rescue ou
> avant ça, écran noire tiret blanc ), quand j'allume ma machine, et,
> pouvoir choisir un boot linux sans avoir besoin de faire f12 ...
> Et, si j'avais les choix pour linux linux windows, ce serait encore
> mieux, pour revenir à la situation fonctionnelle.
>
>
> En attend, je nage, avec ma bouée en forme de f12, pour avoir mon grub
> de linux et pouvoir accéder à mon système de travail.
> Le Windows, lui, je me moque qu'il soit placé dans le 1er choix de
> boot en UEFI, je ne le démarre presque plus, juste, pour faire sa mise
> à jour ( et voir mon grub mourir. )
> Toute fois, j'aimerais toujous encore le garder, ce windows ...
>
> Voilà, toi qui a lu le message jusqu'au bout, tu es sacrément
> courageux. Le pastebin en début de message doit racconter la même chose.
> C'est pas trop grâve j'espère.
>
>
> Solution potentielle pour résoudre ce problème, je me suis dit que je
> peux insta

SoS Grub - Windows m'a tué - Ou bien un noyau en forme de pépin

[G2PC]

Bonjour les gens doués, je cherche de l'aide pour Grub, actuellement,
mes systèmes ne démarrent plus " normalement ".

Déjà, beaucoup de courage à celui, ou à celle, qui prendra le temps de
lire mon poste, j'ai tenté d'être précis dans ce qui m'arrive, et
d'expliquer l'objectif à atteindre.
Si mes explications sont trops longues, peut être que le pastebin en
dira directement plus, à ceux qui savent le comprendre :

https://pastebin.com/6px5X85a



Hier encore, j'avais un grub "je pense" placé sur mon 3ème disque, qui
me proposait de charger linux mint / linux mint / windows 10.
( J'avais aussi un grub, sur mon disque 2, 1 dédié à linux, le second à
windows, plusieurs partitions sur le disque 2, 2 systèmes. )
C'est d'ailleurs l'installation du 3eme disque et de mint, qui m'avait
enfin permis d'avoir mon multiboot windows fonctionnel.
Ça a presque tenu 1 an ...

Voilà que Windows, je pense, vient de gacher mon plaisir. La mise à jour
a redémarrée plusieurs fois, et, j'ai raté le coche pour le choix du
menu windows.
( j'ai rebotté sur un linux par défaut. )

Je suis actuellement repassé en legacy, il me semblait d'ailleurs être
resté à legacy toute l'année passée.
Je crois qu'il est possible que la mise à jour de windows m'ait fait
repasser en UEFI (?) Voir mon test avec boot repair.

Bref, depuis celle mise à jour Windows, j'ai eu un écran noir et tiret
blanc statique.
J'ai lu que ça pouvait aussi être un soucis de kernel, et, je me suis
empressé de revenir en arrire de 2 kernel, sur mon 3eme disque, mais
rien n'a changé.
( Je venais aussi de faire la mise à jour des kernel .. c'était la
journée mises à jour. )

Au menu de démarrage, j'avais alors toujours l'écran noir au tiret blanc
statique.

Pressé de me dépatouiller en faisant n'importe quoi, j'ai installé
boot-repair, d'abord sur l'os du disque 3, puis, sur l'os du disque 2.
Une fois, deux fois, trois fois, mes tests n'ont rien changés, écran
noir tiret blanc, et, quatre fois, j'empire la situation, en le testant
sur mon linux disque 3 puis encore sur mon linux disque 2 ( dont le
disque est partagé avec windows 10 ) ( je crois voir d'ailleurs que les
partitions sont en gpt ici, il me semble. )


Le disque 1 est un disque de stockage. J'avais choisi d'installer le
systeme sur le SSD, le disque 2. De réserver le disque 1 plus important
au stockage, et, j'ai pris un 3eme disque, pour me servir d'os de
secours si jamais.


Bon, actuellement, dans le bios, en legacy, je ne peux pas mettre mon
disque 3 en choix de démarrage numéro 1. ... Ceci explique peut etre le
message d'erreur grub rescue.
Ah oui, entre temps, ce n'est plus l'écran noir au tiret blanc, mais, un
grub rescue. ( Merci à boot-repair, je crois avoir cocher / décocher des
options EFI )
( plouf plouf, ah mince, fallait peut être pas... )

Si je passe en UEFI, je peux choisir le grub de windows ( d'ailleurs,
j'ai intallé aussi grub2 pour windows pour tenter de récupérer un
multiboot j'ai donc 2 choix de grub windows, grub2win et grub manager
windows, carrément deux ... ^ alors que ceux de windows, je n'en veux
pas plus que ça ... )
Si je choisi le grub de windows, pas de soucis, je boot direct sur
windows, tout ça tout ça ^ ... sans avoir de dual ou triple choix de
boot ( pouasse )

Si je choisi le grub de ubuntu proposé, je " crois " que je retombe
actuellement sur une erreur de grub rescue.
J'ai tenté de lire le man, mais, les quelques tests effectués avec ls ne
me semble pas du tout concluants.

La seule façon pour moi, actuellement, de lancer mon dualboot ( sans
avoir le choix d'option de windows ) ( donc, de choisir entre linux et
linux ) est de faire f12 au démarrage et de choisir le disque 3 du mode
legacy. ( il démarre, et, me propose le choix entre linux du disque 3 et
le linux du disque 2, je rappel que le disque 2 est partagé avec windows. )


J'aimerais bien ne plus avoir de message d'erreur ( grub rescue ou avant
ça, écran noire tiret blanc ), quand j'allume ma machine, et, pouvoir
choisir un boot linux sans avoir besoin de faire f12 ...
Et, si j'avais les choix pour linux linux windows, ce serait encore
mieux, pour revenir à la situation fonctionnelle.


En attend, je nage, avec ma bouée en forme de f12, pour avoir mon grub
de linux et pouvoir accéder à mon système de travail.
Le Windows, lui, je me moque qu'il soit placé dans le 1er choix de boot
en UEFI, je ne le démarre presque plus, juste, pour faire sa mise à jour
( et voir mon grub mourir. )
Toute fois, j'aimerais toujous encore le garder, ce windows ...

Voilà, toi qui a lu le message jusqu'au bout, tu es sacrément courageux.
Le pastebin en début de message doit racconter la même chose.
C'est pas trop grâve j'espère.


Solution potentielle pour résoudre ce problème, je me suis dit que je
peux installer debian, sur le disque 1 ( ou il n'y a aucun OS. )
Et, compter sur lui, pour recréer un grub fonctionnel ... Mais, saura
t'il trouver Windows également, automatiquement ?
Cela me ferait 4 Os.
Disque 1 debian
Disque 2 Mint / Wind

Re: Tuer un script après une durée fixe

[Francois Lafont]

Bonsoir,

On 02/27/2018 05:38 PM, steve wrote:

> C'est en tout cas intéressant et je n'y avais pas du tout pensé. Il
> faudrait pour cela écrire un fichier /etc/systemd/system/macamera.service
> contenant quelque chose comme
> 
> [Unit]
> Description=Mise en marche de la caméra
> 
> [Service]
> Type=idle
> ExecStart=$HOME/bin/script.sh
> RuntimeMaxSec=15 # en secondes
> 
> [Install]
> WantedBy=multi-user.target
> 
> avec un fichier correspondant /etc/systemd/system/macamera.timer
> 
> [Unit]
> Description=Heure de lancement
> 
> [Timer]
> OnCalendar=10:00:00 # à 10h le matin
>    [Install]
> WantedBy=timers.target

Faire du script un daemon me semble aussi une très bonne idée.
Et pour le coup, on peut sans doute dire beaucoup de choses sur
systemd, mais faire d'un petit script (qui ne forke pas) un
daemon est vraiment très simple.

Personnellement, je laisserais de côté les RuntimeMaxSec and
co pour faire au plus simple (ie un daemon qui doit être UP
H24) et je gérerais la plage d'exécution de la commande directement
dans le script shell avec un truc dans ce genre là (non testé hein) :

---%<---%<---%<---%<---%<---%<---
#!/bin/sh

# Imaginons qu'on veuille que le « machin » tourne
# entre 17h30 et 18h30 (choix au pif).
start_time=1730
stop_time=1830

while true
do
# Petite pause de 30 secondes...
sleep 30

now=$(date +"%H%M")

# On teste si on a : 17h30 =< now < 18h30. Si c'est le cas, alors
# il faut lancer la commande.
if [ "$now" -ge "$start_time" ] && [ "$now" -lt "$stop_time" ]
then
delta=$((stop_time - now))
# Ici on met la commande qui-va-bien avec le timeout.
raspivid [options] | timeout -s KILL "${delta}m" ffmpeg [autres 
options] 
fi
done
---%<---%<---%<---%<---%<---%<---

À+

-- 
François Lafont

Re: Tuer un script après une durée fixe

[yahoo]

Oui je ferais comme cela.

Pour le Timer,

en fait tu peux utiliser un système d'événement de calendrier,

qui permet de configurer un ou plusieurs appel dans le temps.

je ne l'utilise pas tout les jours donc je peux faire une erreur mais ça
ressemble a cela:

10:*:* -> tous les jours à 10h00

Mon,Tue *-*-* 10:*:* -> tous les Lundi et Mardi à 10h00

la doc l'explique plutôt bien :
https://www.freedesktop.org/software/systemd/man/systemd.time.html


Le 27/02/2018 à 17:38, steve a écrit :
> Salut,
>
> Le 27-02-2018, à 14:48:14 +0100, yahoo a écrit :
>
>>   Salut,
>>
>>   pour ma part j’exécute mes script avec systemd avec l'option
>> RuntimeMaxSec
>>   qui permet de définir un temps d’exécution du script avant de la
>> tuer (et
>>   mit en état d’échec).
>>
>>   Si cela peut être une solution ?
>
> C'est en tout cas intéressant et je n'y avais pas du tout pensé. Il
> faudrait pour cela écrire un fichier /etc/systemd/system/macamera.service
> contenant quelque chose comme
>
> [Unit]
> Description=Mise en marche de la caméra
>
> [Service]
> Type=idle
> ExecStart=$HOME/bin/script.sh
> RuntimeMaxSec=15 # en secondes
>
> [Install]
> WantedBy=multi-user.target
>
> avec un fichier correspondant /etc/systemd/system/macamera.timer
>
> [Unit]
> Description=Heure de lancement
>
> [Timer]
> OnCalendar=10:00:00 # à 10h le matin
>    [Install]
> WantedBy=timers.target
>
>
> Est-ce qu'on peut mettre plusieurs OnCalendar à la suite ?
>
>
> Je n'ai jamais écrit de tels fichiers, donc pas du tout sûr que ça soit
> juste. Mais je vais essayer, ça va me permettre de mettre vraiment les
> mains dans le système systemd.
>
> Merci pour la suggestion et sur d'éventuelles autres sur l'écriture des
> deux fichiers ci-dessus.
>
> S
>

Re: Tuer un script après une durée fixe

[steve]

Salut,

Le 27-02-2018, à 14:48:14 +0100, yahoo a écrit :


  Salut,

  pour ma part j’exécute mes script avec systemd avec l'option RuntimeMaxSec
  qui permet de définir un temps d’exécution du script avant de la tuer (et
  mit en état d’échec).

  Si cela peut être une solution ?


C'est en tout cas intéressant et je n'y avais pas du tout pensé. Il
faudrait pour cela écrire un fichier /etc/systemd/system/macamera.service
contenant quelque chose comme

[Unit]
Description=Mise en marche de la caméra

[Service]
Type=idle
ExecStart=$HOME/bin/script.sh
RuntimeMaxSec=15 # en secondes

[Install]
WantedBy=multi-user.target

avec un fichier correspondant /etc/systemd/system/macamera.timer

[Unit]
Description=Heure de lancement

[Timer]
OnCalendar=10:00:00 # à 10h le matin
   
[Install]

WantedBy=timers.target


Est-ce qu'on peut mettre plusieurs OnCalendar à la suite ?


Je n'ai jamais écrit de tels fichiers, donc pas du tout sûr que ça soit
juste. Mais je vais essayer, ça va me permettre de mettre vraiment les
mains dans le système systemd.

Merci pour la suggestion et sur d'éventuelles autres sur l'écriture des
deux fichiers ci-dessus.

S

Re: Tuer un script après une durée fixe

[steve]

Le 27-02-2018, à 14:24:35 +0100, Francois Lafont a écrit :


Idées, suggestions ?


Je pense que tu devrais mettre le timeout sur la commande à droite
du pipe uniquement (ie ffmpeg). Normalement, la commande à gauche
du pipe (raspivid) devrait se stopper d'elle-même car elle recevra
le signal SIGPIPE.


Et ça marche, hip hip hip hourra !

La bonne ligne est donc:

raspivid [options] | timeout -s KILL 15s ffmpeg [autres options]

(le -s KILL semble optionnel et inoffensif).

Pour répondre à Jean-Marc, la solution

timeout 15s bash -c " raspivid [options] | ffmpeg [autres options] "

tue bien raspivid, mais pas ffmpeg.


Merci à vous tous.

S

Re: Gnome 3.22 avec Stretch : icônes sur le bureau ?

[Frédéric MASSOT]

Le 27/02/2018 à 13:26, Bernard a écrit :
> Bonjour à tous,
> 
> Contrairement à ma vieille installation (Lenny), je ne puis mettre
> d'icônes sur le bureau de Gnome 3.22. Une recherche m'a enseigné qu'il
> existait des moyens d'activer les icônes sur le bureau... mais c'est
> pour Ubuntu. Il semble que pour Debian il y ait des verrous, et l'outil
> GnomeTweakTool que j'ai téléchargé n'offre pas toutes les possibilités
> détaillées par la notice de Ubuntu: on ne peut mettre sur le bureau que
> 2 icônes : Home et la corbeille, rien d'autre, le menu de l'outil ne
> propose pas autre chose.
> 
> Et maintenant, je vois que, dans les futurs développements de Gnome, il
> est question de carrément supprimer cette possibilité. Quelqu'un a-t-il
> lu le document ci-attaché ?  (je n'en ai pris que les extraits
> pertinents, l'url est affiché en tête du texte)
> 
> Que penser de la suggestion suivante :
> 
> ‘GNOME’s recommended alternative for users who want desktop icons is to
> install and use Nemo, a Nautilus fork’
> 
> Quelqu'un ici a-t-il installé Nemo à cette fin ?  Quels sont les
> problèmes à prévoir ?
> 
> Merci d'avance pour vos avis et suggestions.

Si tu n'es pas contre un changement de bureau et si tu souhaites
retrouver les fonctionnalités de Gnome 2, tu peux utiliser MATE.

-> Paquet mate-desktop-environment


-- 
==
|  FRÉDÉRIC MASSOT   |
| http://www.juliana-multimedia.com  |
|   mailto:frede...@juliana-multimedia.com   |
| +33.(0)2.97.54.77.94  +33.(0)6.67.19.95.69 |
===Debian=GNU/Linux===

Re: Tuer un script après une durée fixe

[Francois Lafont]

On 02/27/2018 03:26 PM, Vincent Lefevre wrote:

> Mais seulement si elle écrit des données, au cas où elle ne le ferait
> pas en permanence.

Ah oui exact. Merci pour cette précision importante en effet.

-- 
François Lafont

Re: Thunderbird et noyau 4.15

[David BERCOT]

Bonjour,

J'ai en effet créé un lien du fichier usr.bin.thunderbird dans
/etc/apparmor.d/disable/ et ça semble OK.

Bon, j'ai à nouveau mon problème bluetooth mais j'espère réussir à le
résoudre ;-)

Merci.

David.

Le 26/02/2018 à 11:35, Pierre Malard a écrit :
> Salut,
> 
> « AppArmor » est un outil libre de sécurisation des applications
> déployées sur un système. Il restreint les fichiers et répertoires que
> l’application qui le supporte peuvent accéder. C’est un peut le portage
> du « SandBox » d’Apple sur ses OS et c’est installé par défaut avec
> Firefox et Thunderbird.
> Cela peut effectivement expliquer tes problèmes. Par exemple, j’avais
> rencontré ça parce que j’avais modifié la racine des répertoires des
> utilisateurs locaux en « /homeL » car « /home » était référencé pour les
> utilisateurs LDAP. Du coup, les utilisateurs locaux ne pouvaient plus
> utiliser les produits « Mozilla ».
> 
> On peut voir et modifier cette configuration dans le répertoire
> « /etc/apparmor.d ». Jette un œil sur la documentation Ubuntu
> (https://doc.ubuntu-fr.org/apparmor).
> 
> Cordialement
> 
>> Le 26 févr. 2018 à 10:16, David BERCOT > > a écrit :
>>
>> Bonjour,
>>
>> En effet, AppArmor est installé.
>> J'avoue ne pas connaître ce produit et son impact potentiel sur mon
>> problème...
>>
>> Des infos complémentaires peut-être (même si je vais chercher de mon
>> côté ;-)) ?
>>
>> Merci.
>>
>> David.
>>
>> Le 26/02/2018 à 09:23, Pascal Legrand a écrit :
>>> apparmor est installé ?
>>
> 
> -- 
> Pierre Malard
> 
>    « /Tous les Français ambitionnent pour la France un grand rôle/
> /   dans le monde. Ce n'est point par des aventures guerrières qu'elle/
> /   le trouvera, c'est en donnant aux peuples l'exemple et le signal/
> /   de justice. /»
>                                             Jean Jaures - "L'idéal de
> justice" - 1889
>    |\      _,,,---,,_
>    /,`.-'`'    -.  ;-;;,_
>   |,4-  ) )-,_. ,\ (  `'-'
>  '---''(_/--'  `-'\_)   πr
> 
> perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-.  ;-;;,_:  |,A-  )
> )-,_. ,\ (  `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"'  `-'"'"'\_):
> 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
> - --> Ce message n’engage que son auteur <--
> 

Re: Tuer un script après une durée fixe

[Vincent Lefevre]

On 2018-02-27 14:24:35 +0100, Francois Lafont wrote:
> Je pense que tu devrais mettre le timeout sur la commande à droite
> du pipe uniquement (ie ffmpeg). Normalement, la commande à gauche
> du pipe (raspivid) devrait se stopper d'elle-même car elle recevra
> le signal SIGPIPE.

Mais seulement si elle écrit des données, au cas où elle ne le ferait
pas en permanence.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Tuer un script après une durée fixe

[yahoo]

Salut,

pour ma part j’exécute mes script avec systemd avec l'option
|RuntimeMaxSec| qui permet de définir un temps d’exécution du script
avant de la tuer (et mit en état d’échec).

Si cela peut être une solution ?


Le 27/02/2018 à 10:21, steve a écrit :
> Salut,
>
> Sur un Raspberry tournant sous raspbian, j'ai un script du genre
>
> #!/bin/sh
>
> raspivid [des option] | ffmpeg [d'autres options]
>
>
> (raspivid permet de contrôler une caméra)
>
> Le script tourne à l'infini (il permet de streamer une vidéo)
>
> Je lance ce script via une tâche cron.
>
> J'aimerais arrêter ce script après 30 minutes. Pour cela, j'ai trouvé la
> commande timeout du paquet coreutils. J'ai donc modifié le script ainsi:
>
> timeout 30m raspivid [des options] | ffmpeg [d'autres options]
>
> En testant cette solution, je m'aperçois que la commande raspivid est
> bien tuée après 30 minutes (j'ai pris des secondes pour mes tests), mais
> pas la commande ffmpeg, qui est pipée. J'ai donc rajouté un autre
> timeout devant ffmpeg comme ceci:
>
> timeout 30m raspivid [des options] | timeout 30m ffmpeg [d'autres option]
>
> Cette solution fait le job, mais je ne trouve pas très élégant
> d'utiliser deux timeout. Ce serait mieux de tuer le script lui-même que
> chaque commande à l'intérieur du script. Mais je ne vois pas comment
> faire.
>
> Idées, suggestions ?
>
> Merci
> S
>

Re: Tuer un script après une durée fixe

[Francois Lafont]

Bonjour,

On 02/27/2018 10:21 AM, steve wrote:

> J'aimerais arrêter ce script après 30 minutes. Pour cela, j'ai trouvé la
> commande timeout du paquet coreutils. J'ai donc modifié le script ainsi:
> 
> timeout 30m raspivid [des options] | ffmpeg [d'autres options]
> 
> En testant cette solution, je m'aperçois que la commande raspivid est
> bien tuée après 30 minutes (j'ai pris des secondes pour mes tests), mais
> pas la commande ffmpeg, qui est pipée. J'ai donc rajouté un autre
> timeout devant ffmpeg comme ceci:
> 
> timeout 30m raspivid [des options] | timeout 30m ffmpeg [d'autres option]
> 
> Cette solution fait le job, mais je ne trouve pas très élégant
> d'utiliser deux timeout. Ce serait mieux de tuer le script lui-même que
> chaque commande à l'intérieur du script. Mais je ne vois pas comment
> faire.
> 
> Idées, suggestions ?

Je pense que tu devrais mettre le timeout sur la commande à droite
du pipe uniquement (ie ffmpeg). Normalement, la commande à gauche
du pipe (raspivid) devrait se stopper d'elle-même car elle recevra
le signal SIGPIPE.

-- 
François Lafont

Re: Tuer un script après une durée fixe

[Jean-Marc]

Tue, 27 Feb 2018 13:36:33 +0100
steve  écrivait :

> Le 27-02-2018, à 11:18:02 +0100, Jean-Marc a écrit :
> 
> >> [...]
> >> Idées, suggestions ?
> >
> >timeout { mes_commandes; }
> 

apparemment, timeout ne prend comme paramètre qu'une commande, pas un bloc de 
commande.

Autre solution, démarrer un bash:

timeout bash -c " tes_commandes "

Les guillements sont importants, derrière le -c, bash s'attend à une chaîne de 
caractères qu'il interprètera comme étant des commandes.

Jean-Marc 


pgpVLZU4ohmkr.pgp
Description: PGP signature

Re: Tuer un script après une durée fixe

[daniel huhardeaux]

Le 27/02/2018 à 10:21, steve a écrit :

Salut,


Bonjour



Sur un Raspberry tournant sous raspbian, j'ai un script du genre

#!/bin/sh

raspivid [des option] | ffmpeg [d'autres options]


(raspivid permet de contrôler une caméra)

Le script tourne à l'infini (il permet de streamer une vidéo)

Je lance ce script via une tâche cron.

J'aimerais arrêter ce script après 30 minutes. Pour cela, j'ai trouvé la
commande timeout du paquet coreutils. J'ai donc modifié le script ainsi:

timeout 30m raspivid [des options] | ffmpeg [d'autres options]

En testant cette solution, je m'aperçois que la commande raspivid est
bien tuée après 30 minutes (j'ai pris des secondes pour mes tests), mais
pas la commande ffmpeg, qui est pipée. J'ai donc rajouté un autre
timeout devant ffmpeg comme ceci:

timeout 30m raspivid [des options] | timeout 30m ffmpeg [d'autres option]

Cette solution fait le job, mais je ne trouve pas très élégant
d'utiliser deux timeout. Ce serait mieux de tuer le script lui-même que
chaque commande à l'intérieur du script. Mais je ne vois pas comment
faire.

Idées, suggestions ?


timeout 30 sh -c 'raspivid [des options] | ffmpeg [d'autres options]' ?

--
Daniel

Re: Tuer un script après une durée fixe

[steve]

Le 27-02-2018, à 11:18:02 +0100, Jean-Marc a écrit :


[...]
Idées, suggestions ?


timeout { mes_commandes; }


timeout: impossible d'exécuter la commande « { »: Aucun fichier ou dossier de 
ce type



Attention de bien terminer les commandes  par des ";" et de laisser un
espace entre le dernier ";" et l'accolade fermante.


Ne marche pas, le script continue de tourner. J'ai essayé de mettre un
 ; juste avant le pipe, et ça ne marche pas non plus.

Gnome 3.22 avec Stretch : icônes sur le bureau ?

[Bernard]

Bonjour à tous,

Contrairement à ma vieille installation (Lenny), je ne puis mettre 
d'icônes sur le bureau de Gnome 3.22. Une recherche m'a enseigné qu'il 
existait des moyens d'activer les icônes sur le bureau... mais c'est 
pour Ubuntu. Il semble que pour Debian il y ait des verrous, et l'outil 
GnomeTweakTool que j'ai téléchargé n'offre pas toutes les possibilités 
détaillées par la notice de Ubuntu: on ne peut mettre sur le bureau que 
2 icônes : Home et la corbeille, rien d'autre, le menu de l'outil ne 
propose pas autre chose.


Et maintenant, je vois que, dans les futurs développements de Gnome, il 
est question de carrément supprimer cette possibilité. Quelqu'un a-t-il 
lu le document ci-attaché ?  (je n'en ai pris que les extraits 
pertinents, l'url est affiché en tête du texte)


Que penser de la suggestion suivante :

‘GNOME’s recommended alternative for users who want desktop icons is to 
install and use Nemo, a Nautilus fork’


Quelqu'un ici a-t-il installé Nemo à cette fin ?  Quels sont les 
problèmes à prévoir ?


Merci d'avance pour vos avis et suggestions.

Bernard


GnomeNoMoreDesktopIcons.odt
Description: application/vnd.oasis.opendocument.text

Re: Tuer un script après une durée fixe

[Jean-Marc]

Tue, 27 Feb 2018 10:21:52 +0100
steve  écrivait :

> Salut,

salut Steve,

> [...]
> Idées, suggestions ?

timeout { mes_commandes; }

Attention de bien terminer les commandes  par des ";" et de laisser un espace 
entre le dernier ";" et l'accolade fermante.

> 
> Merci 

Dis-nous si ça fonctionne.

> 
> S
> 


Jean-Marc 


pgpmYb9gae_IE.pgp
Description: PGP signature

Tuer un script après une durée fixe

[steve]

Salut,

Sur un Raspberry tournant sous raspbian, j'ai un script du genre

#!/bin/sh

raspivid [des option] | ffmpeg [d'autres options]


(raspivid permet de contrôler une caméra)

Le script tourne à l'infini (il permet de streamer une vidéo)

Je lance ce script via une tâche cron.

J'aimerais arrêter ce script après 30 minutes. Pour cela, j'ai trouvé la
commande timeout du paquet coreutils. J'ai donc modifié le script ainsi:

timeout 30m raspivid [des options] | ffmpeg [d'autres options]

En testant cette solution, je m'aperçois que la commande raspivid est
bien tuée après 30 minutes (j'ai pris des secondes pour mes tests), mais
pas la commande ffmpeg, qui est pipée. J'ai donc rajouté un autre
timeout devant ffmpeg comme ceci:

timeout 30m raspivid [des options] | timeout 30m ffmpeg [d'autres option]

Cette solution fait le job, mais je ne trouve pas très élégant
d'utiliser deux timeout. Ce serait mieux de tuer le script lui-même que
chaque commande à l'intérieur du script. Mais je ne vois pas comment
faire.

Idées, suggestions ?

Merci 


S

Re: HS: Virtualisation côté serveur

[Christophe De Natale]

Le 26/02/2018 à 22:08, Raphaël POITEVIN a écrit :

Olivier Bitsch  writes:

Si ça peut t'aider, j'avais écrit un tuto sur comment installer KVM,
LXC et Libvirt sur un Debian. C'est dispo ici :


https://crouc.net/debian/tutos/linux/kvm/lxc/2016/02/09/debian-as-hypervisor-with-kvm.html

Très instructif. dommage, le partitionnement est expliqué sous forme
d’image, je ne peux donc la lire, ça m’aurait intéressé justement d’en
avoir le détail.


Bonjour Raphaël,

Le partitionnement proposé par Olivier est le suivant :
* une partition swap égale à la même quantité de mémoire
* une partition "boot" de 300 Mo
* le reste du disque en lvm nommé "lvm-pool"dans lequel on met :
  # 20 Go pour la racine
  # le reste pour "home"
  # 5 Go libre pour d'éventuels snapshot

--
Christophe de Natale