Contenu | Rechercher | Menus

Annonce

Ubuntu-fr.org recrute toujours de nouveaux modérateurs, avec de l'expérience.

Ubuntu 16.04 LTS
Commandez vos DVD et clés USB Ubuntu-fr !

Si vous avez des soucis pour rester connecté, déconnectez vous et reconnectez vous depuis ce lien en cochant le case
Me connecter automatiquement lors de mes prochaines visites.

nombre réponses : 25

#0 -1 »  Empêcher le montage des partitions sur USB au démarrage » Hier à 09:45

Arbiel
Réponses : 3

Bonjour

Je constate que les partitions sur clés USB présentes au démarrage sont systématiquement montées. Je voudrais que tel ne soit pas le cas.

Merci de m'indiquer comment faire.

Arbiel

#1 Re : -1 »  Empêcher le montage des partitions sur USB au démarrage » Hier à 12:29

Arbiel
Réponses : 3

Bonjour

J'ai pu décocher l'option de montage automatique sur une seule des deux clés USB actuellement connectées. Pour la seconde, l'ensemble des actions est grisé.

En tout cas, merci pour ton aide.

Arbiel

#2 -1 »  Revenir à la version antérieure d'un paquet » Hier à 10:04

Arbiel
Réponses : 2

Bonjour

La 16.04 embarque la version 1.6.6 de cryptsetup qui, apparemment, ne traite pas correctement le fichier /etc/crypttab, ce qui n'était pas le cas de la 14.04ͺqui embarque la version 1.6.1. Aussi voudrais-je essayer de remplacer la 1.6.6 par la 1.6.1.

Merci à quiconque pourra m'indiquer comment faire.

Arbiel

#3 Re : -1 »  Revenir à la version antérieure d'un paquet » Hier à 12:44

Arbiel
Réponses : 2

Je te remercie pour le lien, que je n'ai pas encore eu le temps d'utiliser.

Je suis bien conscient du risque que la manipulation comporte. Un retour inopiné à la 1.6.6, qui donc me pose actuellement problème, empêcherait le démarrage du PC.

Je veux surtout vérifier que le problème est effectivement lié à la 1.6.6. J'utilise encore la 14.04, et j'envisage de ne plus chiffrer ma partition racine, ce qui ne poserait plus de problème, qui, apparemment est qu'une seule partition est déchiffrée pendant la phase de démarrage, alors que j'ai chiffré séparément la racine et /home. L'idée serait de déporter /var et /opt dans /home par un mount --bind, le reste de la racine n'ayant pas vraiment de caractère confidentiel.

Si cela t'intéresse, j'ai ouvert cette discussion sur mon problème, pour l'instant sans succès.

Merci encore pour ton aide.

Arbiel

#4 -1 »  crypttab semble ne pas être exploité lors du démarrage d'une 16.04 » Le 20/07/2016, à 23:49

Arbiel
Réponses : 2

Bonsoir

J'utilise la 14.04, /home est dans une partition différente de /, de même que /usr et /boot. / et /home sont chiffrées.

Je viens d'installer une 16.04 dans de nouvelles partitions, en visant la même organisation des partitions. Cependant, par mesure de précaution, j'ai laissé  /home dans la racine. Je veux maintenant reprendre mon /home réel, mais je n'y parviens pas, et ce, à mon avis, parce que crypttab n'est pas pris en compte au démarrage, du moins la ligne de crypttab relative à mon /home (la partition racine est correctement déchiffrée, mais cela ne tient-il pas à mon initrd.img ?)

J'écris ce message à partir de la 14.04. Voila les lignes significatives de mes fichiers

cat /etc/fstab | head -11 a écrit :

# /etc/fstab: static file system information.
#
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
#
###########################
# Arborescence standard du système
###########################
/dev/mapper/victor-root /               ext4    errors=remount-ro 0       1
tmpfs /tmp tmpfs defaults,size=512M 0 0
/dev/mapper/victor-home /home ext4 defaults 0 2

"cat /etc/crypttab | head -2 a écrit :

victor-root UUID=78576555-f0c2-4c80-af4f-d763cc7ae71d /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.victor-root:1 luks,keyscript=/lib/cryptsetup/scripts/passdev
victor-home UUID=37447a61-f946-4d38-a398-5a886c4e3f22 /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.victor-home:1 luks,keyscript=/lib/cryptsetup/scripts/passdev

Avant d'écrire ce message, j'ai exécuté les instructions ci-dessous dans la 16.04 dans laquelle je n'ai pas modifié le fichier /etc/fstab puisque le démarrage avec mon /home réel ne fonctionne pas.

remi@remi-Vostro-3550:~$ cat /etc/crypttab | grep victor-home
victor-home UUID=37447a61-f946-4d38-a398-5a886c4e3f22 /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.victor-home:1 luks,keyscript=/lib/cryptsetup/scripts/passdev
remi@remi-Vostro-3550:~$ sudo blkid | grep home
/dev/mapper/victor-home_l: UUID="37447a61-f946-4d38-a398-5a886c4e3f22" TYPE="crypto_LUKS"
remi@remi-Vostro-3550:~$ sudo cryptdisks_start victor-home
 * Starting crypto disk...                                                       * victor-home (starting)..
 * victor-home (started)...                                              [ OK ] 
remi@remi-Vostro-3550:~$ sudo blkid | grep home
/dev/mapper/victor-home_l: UUID="37447a61-f946-4d38-a398-5a886c4e3f22" TYPE="crypto_LUKS"
/dev/mapper/victor-home: LABEL="victor-home" UUID="c5faba25-bb99-4afd-84cc-575657c03fa5" TYPE="ext4"
remi@remi-Vostro-3550:~$ 

La ligne relative à mon /home (victor-home) est bien la même dans les deux fichiers.

A mon avis, si le fichier /etc/crypttab de la 16.04 était correctement traité, la commande blkid | grep home devrait lister également victor-home et pas uniquement victor-home_l.

La commande cryptdisks_start exploite le fichier /etc/crypttab, ce qui provoque le déchiffrement de victor-home_l, comme le montre la seconde commande blkid | grep home.

Dois-je faire quelque chose de particulier pour que crypttab soit effectivement pris en compte par la procédure de démarrage ?

Merci d'avance à quiconque pourra me mettre sur la voie.

Arbiel

#5 Re : -1 »  crypttab semble ne pas être exploité lors du démarrage d'une 16.04 » Hier à 00:12

Arbiel
Réponses : 2

Bonsoir

Le problème semble provenir du fait que la partition (sur support amovible) dans laquelle se trouve le fichier contenant la clé de chiffrement de mon volume logique victor-home est montée lorsque le script /etc/init.d/cryptdisks tente de le déchiffrer. Cette partition ayant été montée pour le déchiffrement de la racine victor-root_1604, et n'ayant probablement pas été démontée, cryptdisks_start ne parvient pas à se l'approprier, et n'arrive pas à lire le fichier contenant la clé de chiffrement de victor-home.

Ce problème ne se produit pas dans la 14.04.

Cependant, dans les deux distributions, dès la fin de la procédure de démarrage, la partition amovible est montée sur /media/… mais je ne sais pas si cela a un rapport, car lorsque /etc/init.d/cryptdisks s'exécute, ce répertoire n'a pas lieu d'être le point de montage de ma partition amovible.

Les versions de cryptsetup sont respectivement 1.6.1 dans la 14.04 et 1.6.6 dans 16.04.

Arbiel

Edit : j'ai recopié le fichier de déchiffrement de victor-home sur un second support amovible. Même résultat (la modification du fichier /etc/crypttab correspondante est correcte - je l'ai testé par une commande cryptdisks_start victor-home qui a parfaitement fonctionné)

#6 Re : -1 »  crypttab semble ne pas être exploité lors du démarrage d'une 16.04 » Hier à 03:14

Arbiel
Réponses : 2

J'ai extrait des journaux d'exploitation les erreurs relatives au déchiffrement lors du démarrage des volumes logiques définis dans le fichier /etc/crypttab

grep -v -e "noauto" /mnt/etc/crypttab | grep -v -e "^#"
victor-root_1604 UUID=22847149-1399-491b-b166-007a50938c5f /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.victor-root_1604:1 luks,keyscript=/lib/cryptsetup/scripts/passdev
victor-home UUID=37447a61-f946-4d38-a398-5a886c4e3f22 /dev/disk/by-uuid/e4fa73a6-92bc-4d1e-98b0-7b6d92661ae4:/.victor-home:1 luks,keyscript=/lib/cryptsetup/scripts/passdev
victor-root_alt UUID=bcc1027f-6078-449f-a26c-99706b5b59b4 /dev/disk/by-uuid/4146dfad-26f0-4aec-99c3-8ab00c3e4297:/.victor-root_alt:1 luks,keyscript=/lib/cryptsetup/scripts/passdev

Cela m'a donné les résultats suivants

journalctl -x -p 0..3 | grep -e "dev-disk-by.* a échoué"
-- Subject: L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_1604:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_1604:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-4146dfad\x2d26f0\x2d4aec\x2d99c3\x2d8ab00c3e4297:-.victor\x2droot_alt:1.device a échoué, avec le résultat timeout.
-- Subject: L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué
-- L'unité (unit) dev-disk-by\x2duuid-e4fa73a6\x2d92bc\x2d4d1e\x2d98b0\x2d7b6d92661ae4:-.victor\x2dhome:1.device a échoué, avec le résultat timeout.

On peut y voir que le déchiffrement de victor-root_1604 a échoué 1 seule fois, alors que le déchiffrement des deux autres volumes logiques a échoué 3 fois, et que le déchiffrement de ces deux volumes a été essayé dans l'ordre inverse de leur apparition dans le fichier /etc/crypttab.

Il semble donc que le problème ne provienne pas, comme je l'ai supposé précédemment, du montage de la partition amovible qui contient les fichiers clés de chiffrement.

Malheureusement, je n'ai pas su comparer ces informations avec les informations correspondantes de la 14.04, la commande d'inspection des journaux d'exploitation (journalctl) n'étant pas disponible avec la 14.04.

#7 Re : -1 »  Icone de lanceur et Menu principal » Le 12/07/2016, à 18:24

Arbiel
Réponses : 2

Bonsoir

Je ne sais pas te dire comment résoudre ton problème avec alacart, mais sache que ton lanceur est un simple fichier texte dont l'extension est .desktop. Tu peux le modifier avec un éditeur de texte. Tu y trouveras une ligne

Icon=<chemin vers l'icône>

que tu peux modifier pour la faire pointer sur l'image de ton choix.

Exemple /usr/share/application/lanceur.desktop

[Desktop Entry]
Name=Disk Usage Analyzer
Comment=Check folder sizes and available disk space
Keywords=storage;space;cleanup;
TryExec=baobab
Exec=baobab
Icon=baobab
Terminal=false
Type=Application
StartupNotify=true
MimeType=inode/directory;
Categories=GTK;GNOME;System;Filesystem;
NotShowIn=KDE;
X-GNOME-Bugzilla-Bugzilla=GNOME
X-GNOME-Bugzilla-Product=gnome-utils
X-GNOME-Bugzilla-Component=baobab
X-GNOME-Bugzilla-Version=3.8.2
X-Ubuntu-Gettext-Domain=baobab

et tu y remplaces
Icon=baobab
par
Icon=/chemin absolu vers ton icone

Arbiel

#8 Re : -1 »  impossible de booter sur LiveUSB à partir d'un Toshiba Satellite U400 » Le 03/07/2016, à 17:41

Arbiel
Réponses : 17

Bonjour

A priori, c'est le BIOS qui ne trouve pas de système sur ta clé. Je suppose que ce BIOS ne sait pas scruter les périphériques pour y chercher un système, sinon il devrait trouver le système présent sur ton disque interne (si j'ai bien compris, tu as un système sur ce disque interne).

Une raison pourrait être l'absence du drapeau "boot" sur une des partitions principales, ou la partition étendue, de ta clé. Je suppose en effet que ta clé est "msdos" et non pas "GPT".

Le drapeau "boot", bien qu'inutilisé par grub, est utilisé par certains BIOS pour décider si oui ou non un périphérique peut contenir un système.

Arbiel

#9 Re : -1 »  impossible de booter sur LiveUSB à partir d'un Toshiba Satellite U400 » Le 04/07/2016, à 22:05

Arbiel
Réponses : 17

Bonsoir

Pour en revenir à ta question

yoon444 a écrit :

@arbiel : si votre hypothèse d'explication est la bonne, que dois/puis-je faire pour que le bios trouve le système sur la clé ? Merci.

Vérifie la présence du drapeau "boot" sur la ou une des partitions de ta clé en passant la commande

fdisk -lu

Donne le retour complet de cette commande. Tu vas obtenir, pour chaque périphérique de ta configuration, des informations comparables à ceci

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 têtes, 63 secteurs/piste, 60801 cylindres, total 976773168 secteurs
Unités = secteurs de 1 * 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0xf72a2344

Périphérique Amorçage  Début         Fin      Blocs    Id. Système
/dev/sda1   *        2048      628735      313344    7  HPFS/NTFS/exFAT
/dev/sda2          628736    42571775    20971520    7  HPFS/NTFS/exFAT
/dev/sda3        42571776    63543295    10485760    b  W95 FAT32
/dev/sda4        63543296   976773119   456614912   8e  LVM Linux

Dans cet exemple, l'astérisque de ligne /dev/sda1 indique la présence du drapeau boot. Dans ton cas, si aucune ligne du bloc décrivant ta clé USB ne contient un tel astérisque, utilise par exemple gparted pour l'inscrire sur ta partition ou l'une de tes partitions de ta clé USB.

Si tu ne sais pas faire, au vu du retour que je t'ai demandé de publier, quelqu'un t'indiquera quelle commande exécuter pour obtenir le même résultat.

Arbiel

#10 -1 »  Demande d'éclaircissement sur option --rbind de "mount" » Le 03/07/2016, à 18:12

Arbiel
Réponses : 0

J'ai longtemps considéré l'option --bind de la commande "mount" comme une manière de renommer un répertoire. Ainsi

sudo mount --bind /rep1 /rep2

permet de référencer /rep1/sous-répertoires/fichier par /rep2/sous-répertoires/fichier.
J'utilise cette possibilité pour adapter à un ordinateur cible un développement réalisé sur un ordinateur de développement, l'arborescence des fichiers de ces deux PC n'étant pas la même.

Je constate que ma vision est erronée puisque s'il existe dans /rep1 un point de montage de quoi que ce soit, résultant par exemple d'une commande telle que

sudo mount /dev/… /rep1/partition

alors /rep2/partition n'est pas un point de montage, et continue de référencer le répertoire /rep1/partition sous-jacent au point de montage /rep1/partition.

Pour reconduire le point de montage vers /rep2/partition, j'ai utilisé l'option rbind

sudo mount --rbind /rep1 /rep2

qui répond bien à mon besoin.

Cependant, j'ai également monté encore autre chose sur /rep1/partition/dossier. Si /rep2/partition est maintenant bien un point de montage de /dev/…, tel n'est pas le cas de rep2/partition/dossier qui reste le répertoire /rep1/partition/dossier et ne référence absolument pas ce que j'ai monté sur /rep1/partition/dossier.

Tout ceci peut paraître un peu compliqué, et je peux éventuellement modifier mon application ou mes fichiers fstab.

Mais j'aimerais bien comprendre les mécanismes mis en œuvre par mount, et savoir quelle erreur j'ai bien pu faire, car je suppose que "mount --rbind" fonctionne parfaitement.

D'avance merci à quiconque voudra bien éclairer ma chandelle.

#11 -1 »  Affichage du contenu de ~/Bureau par Nautilus très lent » Le 03/07/2016, à 17:27

Arbiel
Réponses : 0

Bonjour à tous

Depuis quelque temps et à la suite d'essais de montage et de démontage de répertoires sur mon bureau par des commandes telles que

sudo mount --bind /chemin/répertoire ~/Bureau

au début de chaque session, le premier affichage par nautilus du contenu du bureau dans une fenêtre de type "répertoire" (je veux dire par là, une fenêtre en tous points comparable à celles dans lesquelles nautilus présente le contenu d'un répertoire) est extrêmement lent. Les affichages ultérieurs ne sont pas affectés et s'effectuent en un temps de réponse raisonnable. De même, au démarrage, le bureau s'affiche, en tant que bureau et non pas en tant que répertoire, en un temps de réponse raisonnable.

J'ai réinstallé nautilus, sans résultat.

Merci d'avance à quiconque pourra m'indiquer ce que je peux faire pour résoudre cette difficulté.

Arbiel

#12 Re : -1 »  partition racine pleine » Le 22/06/2016, à 23:39

Arbiel
Réponses : 35

Bonsoir

On pourrait peut-être commencer par supprimer les anciens noyaux, par exemple avec Ubuntu Tweak disponible dans la logithèque.

Lancer Ubuntu Tweak, cliquer sur "Nettoyage" puis cocher dans le panneau de gauche, soit uniquement "Anciens noyaux", soit éventuellement les trois groupes "Applis", "Personnel" et "Système", puis dans le panneau de droite tout ce qu'Ubuntu Tweak propose, et en bas à droite, cliquer sur "Nettoyer".

Arbiel

#13 Re : -1 »  partition racine pleine » Le 23/06/2016, à 12:43

Arbiel
Réponses : 35

Bonjour

cqfd93 a écrit :

mais une connerie de trop m'en a guérie

Pour ma gouverne, peux-tu être plus précise et indiquer ce qui t'est arrivé ? Et, éventuellement, pourquoi ta bévue ne serait pas survenue avec autoremove ou kclean ?

Arbiel

#14 Re : -1 »  partition racine pleine » Le 23/06/2016, à 23:02

Arbiel
Réponses : 35

Bonsoir

@ cqfd et xubu1957

Merci pour les explications et les informations.

#15 -1 »  Tester en bash si une touche est enfoncée » Le 23/06/2016, à 00:01

Arbiel
Réponses : 3

Bonsoir à tous

Est-il possible en bash de tester si une touche, par exemple Ctrl, Alt, Maj, est enfoncée ?

Merci d'avance à quiconque pourra m'apporter des éléments de réponse, et m'indiquer comment faire.

Arbiel

#16 Re : -1 »  Tester en bash si une touche est enfoncée » Le 23/06/2016, à 23:16

Arbiel
Réponses : 3

Bonsoir

et merci pour l'information.

Mais xset ne permet apparemment pas de tester si telle ou telle touche du clavier est appuyée lors du lancement de mon script. Sur mon portable, je ne dispose que de la touche "Verrouillage majuscule" et l'utiliser pour entrer une option qui n'a rien à voir ne me paraît pas une bonne idée.

Je vais changer mon fusil d'épaule et créer une nouvelle entrée dans le lanceur de mon script. Le choix entre les (deux) options correspondantes sera ainsi  beaucoup plus clair que la pression sur une touche.

Merci encore, et désolé de t'avoir, à mauvais escient, incité à intervenir.

Arbiel

#17 -1 »  [Résolu] Touche de fonction F5 : comment en bash ? » Le 02/06/2016, à 16:32

Arbiel
Réponses : 8

Bonjour à tous

Je voudrais introduire dans un script bash une commande pour rafraîchir le bureau, comme le fait la touche de fonction F5.

Merci à quiconque pourra me l'indiquer.

Arbiel

N.B ; unity --replace fait un peu la même chose, mais ferme la session puis présente l'écran d'ouverture de session avec nouvelle saisie du mot de passe, ce que je veux éviter.

#18 Re : -1 »  [Résolu] Touche de fonction F5 : comment en bash ? » Le 02/06/2016, à 23:15

Arbiel
Réponses : 8

Bonsoir Erresse

Merci beaucoup pour cette information qui, même si elle ne fonctionne pas telle quelle, m'a mis sur la voie.

Je pense en effet d'après

man xdotool a écrit :

KEYBOARD COMMANDS
       key [options] keystroke [keystroke ...]
           Options:

que F5 n'est pas la bonne valeur à utiliser, puisque c'est un symbole de touche. Je vais chercher quel code "matériel" la touche F5 envoie lorsqu'elle est enfoncée.

Je te tiens informé dans quelques jours lorsque j'aurai résolu mon problème.

Arbiel

#19 Re : -1 »  [Résolu] Touche de fonction F5 : comment en bash ? » Le 03/06/2016, à 19:11

Arbiel
Réponses : 8

Bonjour

L'utilisation des symboles ne fonctionne pas sur mon PC. Par contre, l'utilisation des codes de touche fonctionne parfaitement.

Ainsi

xdotool key $(sed -n /FK05/{"s|^[^=]*=[^[[:digit:]]]*\([^;]*\).*$|\1|"p} /usr/share/X11/xkb/keycodes/xfree86) ;

ou plus simplement

xdotool key 71 ;

rafraîchit le bureau.


De même

for touche in "LALT" "FK02" "LCTL" ; do sed -n /${touche}/{"s|^[^=]*=[^[[:digit:]]]*\([^;]*\).*$|\1|"p} /usr/share/X11/xkb/keycodes/xfree86; done;
 64
 68
 37
xdotool key 64 68 37

ouvre effectivement la fenêtre du lanceur d'applications.

Arbiel

#20 Re : -1 »  [Résolu] Touche de fonction F5 : comment en bash ? » Le 04/06/2016, à 23:35

Arbiel
Réponses : 8

Bonsoir

Je n'ai pas pu utiliser les symboles car ils ne correspondent pas à ce que j'attendais. Par exemple

xdotool key Ctrl+Alt+F2

me présente le dialogue de login en mode terminal.

xdotool key Super

me présente la feuille application de tableau de bord, comme lorsque j'appuie simultanément sur les touches Super et A.

xdotool key Super+A

me renvoie A.

En utilisant les codes dont j'ai trouvé la valeur dans /usr/share/X11/xkb/keycodes/xfree86, la réponse est ce que j'attends.

J'ai fait tous mes essais dans un terminal, de sorte que la différence dans le comportement peut provenir de ce que j'utilise un clavier bépo (je veux dire un clavier logique, et non pas un clavier physique avec la disposition bépo).

Mon script fonctionne parfaitement en utilisant les valeurs. Je ne l'ai pas essayé avec les symboles, mais il serait bon que je le fasse.

En tous cas, je te remercie car tu m'as permis de résoudre mon problème.

Arbiel

#21 Re : -1 »  [Résolu] Touche de fonction F5 : comment en bash ? » Le 05/06/2016, à 22:56

Arbiel
Réponses : 8

L'utilisation des symboles fonctionne depuis le terminal lorsque je reviens à la disposition "azerty" et dans le script, de même que dans les lanceurs, quelle que soit la disposition du clavier actif.

Il n'en est pas moins surprenant qu'elle ne fonctionne pas à partir d'un terminal lorsque la disposition "bépo" est active.

Arbiel

#22 -1 »  Rafraîchir le "Bureau" par ligne de commande » Le 30/05/2016, à 18:13

Arbiel
Réponses : 1

Bonjour

J'ai écrit et mis au point une petite application en bash à l'usage d'adultes handicapés mentaux dans le cadre d'un club informatique de loisirs. Il s'agit essentiellement de faire tourner des jeux Windows avec VirtualBox. Je désire maintenant modifier l'organisation de cette application.

Pour diverses raisons qui ne me paraissent pas nécessaires d'expliciter ici, j'ai maintenu les PC sous Windows. Le démarrage avec Ubuntu est déclenché par la présence, à la mise sous tension, d'une quelconque des clés USB sur lesquelles j'ai installé grub, et qui, au démarrage, est bien sûr prioritaire par rapport au disque dur. Les fichiers nécessaires aux activités de chacun (la machine virtuelle et quelques autres fichiers) sont mémorisés sur le bureau, dossier situé sur la clé. Chaque adulte dispose d'une clé qui lui est propre, ce qui lui permet d'utiliser l'un quelconque des ordinateurs en retrouvant son contexte d'une séance à la suivante. L'utilisation de clés USB comme support de bureau n'offre cependant pas de bonnes performances et j'envisage un retour en arrière en ramenant le bureau sur le disque dur, d'autant plus que certains utilisateurs sont réticents à changer de place d'une séance à la suivante, ce qui limite l'intérêt de la portabilité du bureau d'une machine à l'autre.

La manière la plus simple d'effectuer la modification que j'envisage est de passer à des systèmes multi-utilisateurs. Je me heurte cependant au manque de rigueur que j'ai eu lors de l'écriture de mon application, tant par rapport à la gestion des droits d'accès qu'à celui des références aux fichiers.

Une seconde solution qui me paraît en fait plus adaptée à notre contexte est de modifier dynamiquement la localisation du bureau par un montage "bind" sur /home/mono-utilisateur/Bureau du dossier que je créerais pour chacun. Cette solution me permettrait également de présenter au démarrage un écran avec la photographie de chacun, permettant à ceux qui ne savent pas lire de cliquer sur la bonne image sans ressentir la moindre gêne due à leur déficience. Ceci me semble facile à réaliser, mais je ne sais pas mettre à jour le bureau après ce "sudo mount --bind /home/utilisateur /home/mono-utilisateur/Bureau".

Merci à quiconque qui pourra me venir en aide.

Arbiel

#23 Re : -1 »  Rafraîchir le "Bureau" par ligne de commande » Le 31/05/2016, à 09:41

Arbiel
Réponses : 1

Bonjour

AskUbuntu m'a apporté une première réponse

unity --replace

Cependant

man unity a écrit :

       --replace
              Deprecated option for backwards compatibility.  Has no effect.

Et cette commande ferme la session et présente l'écran de connexion avec entrée du mot de passe, même dans un système mono-utilisateur dans lequel le profil de l'utilisateur indique "connexion automatique".

Deux questions découlent de ce constat

1) existe-t-il une solution pérenne à mon problème ?
2) comment éviter la fermeture et la réouverture de la session, ou, pour le moins, la saisie du mot de passe ?

Merci d'avance pour votre aide.

Arbiel

#24 Re : -1 »  [Résolu] Ubuntu 16.04 - Problème de paquets » Le 25/05/2016, à 10:42

Arbiel
Réponses : 9

Bonjour

Utilise Synaptic ou PPA Manager pour rajouter les ppa dans les sources de logiciels. À défaut, regarde dans la documentation comment ajouter des ppa