Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
nombre réponses : 25

#0 Re : -1 »  Problème de Boot avec Ubuntu Gnome 14.10 » Le 24/02/2015, à 11:08

Arbiel
Réponses : 5

Bonjour

Il faudrait savoir ce que tu as sur ta clé USB. Elle a pu être altérée par une mauvaise manipulation. Mon conseil serait que tu produise un rapport soit avec boot-repair soit avec le script bootinfoscript.

Lorsque tu auras choisi laquelle de ces deux solutions tu veux utiliser, tu démarres ton PC et tu ne branches ta clé qu'après le démarrage, tu produis le rapport et tu le publies ou en publies l'adresse dans ta réponse.

Arbiel

#1 Re : -1 »  Problème de Boot avec Ubuntu Gnome 14.10 » Le 24/02/2015, à 14:44

Arbiel
Réponses : 5

Malheureusement, je ne connais absolument pas Syslinux, qui est le programme amorce de ta clé USB. Je fabrique mes clés d'une tout autre façon, et utilisant Grub2.

Si tu disposes de l'iso de la 14.10, tu peux éventuellement procéder, sans utiliser de clé, comme je l'explique ici.

Arbiel

#2 -1 »  Disparition d'un périphérique /dev/mapper à la sortie de la veille » Le 23/02/2015, à 23:00

Arbiel
Réponses : 0

Bonsoir

Au lancement d'une application, qui utilise une partition chiffrée, je déchiffre et monte cette partition par les deux commandes

sudo cryptdisks_start nom_déchiffré
mount /dev/mapper/nom_déchiffré

/dev/mapper/nom_déchiffré est décrit dans /etc/fstab avec l'option noauto et user.

Mon PC peut passer en veille alors que l'application est active. Au réveil, /dev/mapper/nom_déchiffré a disparu, mais la partition déchiffrée est présente dans le résultat de mount. L'application ne parvient évidemment pas à atteindre les fichiers qu'elle contient.

Mon premier souhait est que /dev/mapper/nom_déchiffré ne disparaisse pas.

Est-ce possible et dans l'affirmative, comment faire ?

Sinon, où dois-je placer un script pour remettre les choses en ordre ?

Au passage, pour que /dev/mapper/nom_déchiffré réapparaisse il faut au préalable l'arrêter par cryptdisks_stop avant de lancer cryptdisks_start.

Merci d'avance à quiconque pourra me venir en aide.

Arbiel

#3 Re : -1 »  Obtenir le nombre de caractères restants dans la ligne du terminal » Le 12/02/2015, à 21:49

Arbiel
Réponses : 7

Bonsoir

Je n'ai pas la formule en tête, mais tu peux faire quelque chose comme
1) initialiser ton message
2) lui adjoindre un nombre conséquent de " "
3) tronquer l'ensemble à la longueur voulue
4) lui adjoindre la coche ou le x

Arbiel

Edit

Voila un script qui fait ce que tu souhaites

tampon () {
	local lg_msg="${1}"
	local carac="${2}"
	for (( ;  $((${lg_msg})) ; )) ; do echo -n "${carac}" ; lg_msg=$((${lg_msg}-1)) ; done ;
}
echo_msg () {
	local msg="${1}"
	local bourrage="${2}"
	local marque="${3}"
	echo "${msg:0:${#bourrage}}${bourrage:${#msg}:${#bourrage}-${#msg}}${marque}" ;
}
	esp=$(tampon 20 " ")
# lignes de test
	echo_msg "Première ligne" "${esp}" "?"
	echo_msg "Seconde ligne" "${esp}" "!"
	echo_msg "Ligne beaucoup trop longue" "${esp}" "x"

#4 Re : -1 »  [Resolu] USB bootable de W7 » Le 15/02/2015, à 17:21

Arbiel
Réponses : 4

Bonjour

Je serais particulièrement surpris que tu puisses pirater Windows de cette manière.

Si tu veux Windows, tu achètes un support d'installation (CD ou DVD) et tu remercies Bill d'avoir eu l'obligeance de te permettre d'utiliser ce merveilleux logiciel.

Tu peux aussi lui acheter sa suite bureautique, son logiciel de messagerie et toutes les merveilles applications qu'il a eu la généreuse idée de mettre à la disposition du plus grand nombre.

Bien à toi

Arbiel

#5 Re : -1 »  [Résolu] GPG sur smartphone » Le 06/02/2015, à 16:08

Arbiel
Réponses : 7

Merci pour cette information.

Je peux difficilement demander à mes correspondants d'acheter un logiciel parce que je signe mes messages et que maints d'entre eux ne voient aucune utilité dans cette pratique.

Arbiel

#6 Re : -1 »  [Résolu] GPG sur smartphone » Le 15/02/2015, à 22:55

Arbiel
Réponses : 7

Je viens de réussir quelques tests avec le logiciel livré d'origine avec mon téléphone. Il apparaît avec une icône dont le libellé est "Email" sur un téléphone Samsung.

J'ai exporté ma clé publique depuis mon PC et je l'ai réintroduite dans le répertoire

openpgp/export

d'un autre téléphone Samsung. En allant dans les paramètres de Email sur ce second téléphone, et en appuyant à droite en bas d'écran, il apparaît la commande "importer des clés" avec la liste des fichiers contenus dans openpgp/export.

J'ai ensuite envoyé un message signé vers la messagerie du propriétaire du portable, qui a pu vérifier ma signature et m'a répondu par un message chiffré que j'ai pu lire avec ma phrase de chiffrement et ma clé privée.

Pour ma part, le problème est donc résolu.

Arbiel

#7 -1 »  [Résolu] /etc/rc.local non exécuté au démarrage ? » Le 03/02/2015, à 18:01

Arbiel
Réponses : 9

Bonsoir à tous

J'essaie, sans succès, de faire exécuter quelques scripts au démarrage.
Pour tester, j'ai inséré dans /etc/rc.local un script pour afficher le nom de l'utilisateur dans un dialogue zenity, et ceci se passe bien si je tape la commande

. /etc/rc.local

Le nom de l'utilisateur est effectivement affiché dans une fenêtre zenity.

Par contre, ce n'est pas le cas lorsque j'exécute ce fichier par le biais de /etc/init.d/rc.local :

cat /etc/rc.local && . /etc/init.d/rc.local start
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
function qui_suis_je () {
		ti="exécution de rc.local"; te=15; l=220; h=60
		ty="--info"
		zenity ${ty} --title="${ti}" --timeout=${te} --width=${l} --height=${h} --no-wrap --text=${USER} ;
}
qui_suis_je
exit 0
/etc/rc.local: 13: /etc/rc.local: Syntax error: "(" unexpected

En retirant les () de "function qui_suis_je () {"  (ligne 13), bash m'insulte différemment, mais m'insulte néanmoins

cat /etc/rc.local && . /etc/init.d/rc.local start
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
function qui_suis_je {
		ti="exécution de rc.local"; te=15; l=220; h=60
		ty="--info"
		zenity ${ty} --title="${ti}" --timeout=${te} --width=${l} --height=${h} --no-wrap --text=${USER} ;
}
qui_suis_je
exit 0
/etc/rc.local: 13: /etc/rc.local: function: not found

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

En attendant, je lance mes scripts par des lanceurs dans ~/.config/autostart avec l'inconvénient de devoir m'authentifier si nécessaire (sudo …)

Arbiel

#8 Re : -1 »  [Résolu] /etc/rc.local non exécuté au démarrage ? » Le 03/02/2015, à 19:27

Arbiel
Réponses : 9

Le problème vient de l'erreur que bash trouve dans mon fichier /etc/rc.local lorsqu'il est appelé par la ligne

/etc/rc.local

du fichier /etc/init.d/rc.local dont le contenu est le suivant

#! /bin/sh
### BEGIN INIT INFO
# Provides:          rc.local
# Required-Start:    $all
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: Run /etc/rc.local if it exist
### END INIT INFO


PATH=/sbin:/usr/sbin:/bin:/usr/bin

. /lib/init/vars.sh
. /lib/lsb/init-functions

do_start() {
	if [ -x /etc/rc.local ]; then
	        [ "$VERBOSE" != no ] && log_begin_msg "Running local boot scripts (/etc/rc.local)"
		/etc/rc.local
		ES=$?
		[ "$VERBOSE" != no ] && log_end_msg $ES
		return $ES
	fi
}

case "$1" in
    start)
	do_start
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop)
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac

alors que bash ne trouve pas d'erreur lorsque je lance le script depuis un terminal ou depuis un lanceur dans ~/.config/autostart

#9 Re : -1 »  [Résolu] /etc/rc.local non exécuté au démarrage ? » Le 03/02/2015, à 22:43

Arbiel
Réponses : 9

Merci à vous trois pour vos conseils et explications.

J'avais introduit un message zenity dans mon test parce que le script que je veux exécuter peut aussi être utilisé lorsque la session est ouverte et que dans ce cadre là le message me semble plus ergonomique. J'ai maintenant ajouté un paramètre qui conditionne cet affichage, mais je ne crois pas que cela ait beaucoup d'importance.

J'avais été surpris par la définition de do_start, mais sans vraiment me rendre compte de la différence entre cette définition et celle des fonctions de mes scripts.

J'avais également fini par essayer "/etc/rc.local" dans un terminal et constaté que cela provoquait les mêmes erreurs que l'exécution de /etc/init.d/rc.local. Mais, bien évidemment, je n'avais pas su interpréter ce constat.

tiramiseb a écrit :

Le fichier /etc/rc.local est lu par l'interpréteur sh par défaut, qui est Dash sur Ubuntu.

Est-ce la raison pour laquelle la première ligne de /etc/init.d/rc.local est

#! /bin/sh

?
Que dois-je en conclure pour mon script ? Pour l'instant c'est un script bash (#! /bin/bash)

Pour l'instant, j'ai la certitude qu'il n'est pas exécuté par /etc/init.d/rc.local, où je l'appelle pourtant par

.  <chemin_accès> <paramètres>

J'en ai la certitude car j'ai laissé l'appel par le lanceur de ~/.config/autostart et que cet appel m'affiche le message zenity du déchiffrement, alors que si le déchiffrement avait été fait par rc.local, le message aurait été différent.

Arbiel

Edit

Plus de problème, avec

bash  <chemin_accès> <paramètres>

#10 Re : -1 »  [Résolu] /etc/rc.local non exécuté au démarrage ? » Le 06/02/2015, à 01:02

Arbiel
Réponses : 9

Bonsoir

Le script que j'ai affiché dans cette discussion était destiné à des tests et n'a presque rien à voir avec les deux scripts que je veux insérer dans /etc/rc.local, ou là où je dois les mettre pour les exécuter à bon escient. Le seul rapport consiste en l'avertissement que je veux afficher à l'utilisateur en cas de problème et c'est la raison pour laquelle j'ai utilisé zenity dans le script de test.

Le premier script a comme effet d'inhiber le pavé tactile lorsque la souris est raccordée, et de le réactiver au débranchement de la souris. Je veux l'exécuter au démarrage, et au réveil puisque je suppose que l'hibernation et le passage en veille l'arrêtent probablement.

Le second script a pour but de déchiffrer automatiquement une partition chiffrée et de la monter. Je veux l'exécuter au démarrage, en dehors de tout contexte utilisateur, pour une partition nécessaire au bon fonctionnement de mon système (archives), mais aussi à l'intérieur d'un script pour atteindre des fichiers sur une partition chiffrée d'un disque externe (comptes). Dans cette seconde situation, il s'exécute dans un contexte utilisateur.

Les effets du script lancé au démarrage pour archives n'étant probablement pas affectés par le passage en veille, il est vraisemblablement suffisant de le lancer au démarrage seulement. Cependant, pour éviter l'occurrence d'erreurs, j'évite, dans ma dernière version, de déchiffrer une partition lorsqu'elle l'a déjà été, ou de la monter lorsqu'elle est déjà montée.

Ce script s'appuie sur le contenu des fichiers crypttab et fstab et invoque les commandes cryptdisks_start et mount. Les lignes de crypttab pour déchiffrement au démarrage permettent, par leur troisième champ, de désigner un fichier contenant la phrase de chiffrement. Pour éviter de saisir autant de phrases de chiffrement que de partitions concernées, j'ai initialement voulu utiliser ce troisième champ, mais je n'ai pas réussi à le faire, l'arborescence des fichiers n'étant pas encore constituée lors du traitement de crypttab ; je me suis ainsi heurté à la manière de référencer ce fichier, ce qui m'a conduit à demander de l'aide.

C'est pour ce script que je veux présenter à l'utilisateur la sortie de ces deux commandes. La sortie de cryptdisks_start dépend de "l'état" de la partition chiffrée, et c'est de ce message dont je parlais en disant

Arbiel a écrit :

J'en ai la certitude car j'ai laissé l'appel par le lanceur de ~/.config/autostart et que cet appel m'affiche le message zenity du déchiffrement, alors que si le déchiffrement avait été fait par rc.local, le message aurait été différent.

La sortie de cryptdisks_start, lors de la première exécution est la suivante

cryptdisks_start a écrit :

* Starting crypto disk...
* archives: INSECURE OWNER FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives: INSECURE OWNER GROUP FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives: INSECURE MODE FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives (starting)..
* archives (started)...
   ...done.

et mount n'émet aucun commentaire.
Par contre, les sorties de cryptdisks_start et de mount, lorsque le script s'exécute ultérieurement sont

cryptdisks_start a écrit :

* Starting crypto disk...
* archives: INSECURE OWNER FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives: INSECURE OWNER GROUP FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives: INSECURE MODE FOR /home/.archives, see /usr/share/doc/cryptsetup/README.Debian.
* archives (running)...
   ...done.

mount a écrit :

mount : /dev/mapper/archives est déjà monté ou /home/archives est occupé
mount : selon mtab, /dev/mapper/archives est déjà monté sur /home/archives

Bien évidemment rien n'est affiché lorsque le script est lancé par /rc.local, mais ce qui apparaît lors de l'exécution par le lanceur de .config/autostart permet de savoir si le premier appel s'est bien déroulé ou non.

Mon problème, à savoir comment faire exécuter un script par /rc.local, est maintenant résolu.

Merci encore.

Arbiel

#11 Re : -1 »  [Résolu] /etc/rc.local non exécuté au démarrage ? » Le 06/02/2015, à 23:04

Arbiel
Réponses : 9

Je crois que tout te paraîtra clair à la lecture de mes fichiers /etc/crypttab et /etc/fstab.

Mon fichier /etc/crypttab contient les lignes suivantes

hm UUID=9c21b407-620d-4511-8e5f-41b621d57505 none luks,retry=3
archives UUID=6800b9e6-5907-4589-b658-4d5796536daf /home/.archives luks,noauto
comptes UUID=8357f4d4-7d39-4c35-8497-117bc0e007a7 /home/.comptes luks,noauto

et mon fichier /etc/fstab contient, entre autres, les lignes suivantes

/dev/mapper/hm /home ext4 defaults 0 2
/dev/mapper/archives /home/archives ext4 defaults,noauto,user 0 2
/dev/mapper/comptes /media/Données ext4 defaults,noauto,owner 0 0

Les fichiers qui contiennent les phrases de chiffrement sont dans /home. Celle-ci, chiffrée, est déchiffrée avec saisie de la phrase de chiffrement pendant la phase de démarrage, alors que les deux autres sont déchiffrées après que fstab a été exploitée, et donc quand les chemins /home/.archives et /home/.comptes ont été résolus.

Comme les commandes cryptdisks_start et mount de mon script nécessitent le passage en mode superutilisateur, j'ai également enregistré mon mot de passe de session dans un fichier de /home. J'ai dû retenir une solution de cette nature car ma partition / n'est pas chiffrée. J'ai comme objectif de la chiffrer dans le futur, et peut-être choisirai-je alors une autre solution.

Arbiel

#12 Re : -1 »  Pas de menu grub lors d'un redémarrage après installation et m.à.j. » Le 02/02/2015, à 14:08

Arbiel
Réponses : 7

Bonjour

Defa a écrit :

j'ai déjà essayé de démarrer avec le live cd plusieurs fois, mais ça ne change rien.

Ça ne change rien à quoi ?
Le PC démarre-t-il ou ne démarre-t-il pas ?
Ordre de priorité des périphériques au démarrage ?

Defa a écrit :

Ou il me faut vraiment un DVD-R ou DVD-RW ?

Ça ne dépend que de la taille du fichier.

Arbiel

#13 Re : -1 »  Pas de menu grub lors d'un redémarrage après installation et m.à.j. » Le 06/02/2015, à 16:05

Arbiel
Réponses : 7

Bonjour

Je n'arrive pas à comprendre la situation dans laquelle tu te trouves et en particulier pourquoi tu n'arrives pas à démarrer ton PC comme tu l'as fait pour l'installation de la 14.04.

Si tu réussis à démarrer ton PC de la même manière que lorsque tu as installé, tu dois pouvoir charger boot-repair. Je viens d'enregistrer le script bootinfo que tu trouveras à cette adresse.. Ce script produit une partie du rapport produit par le programme boot-repair, la plus intéressante pour te venir en aide. Tu peux publier ce rapport en te rendant à cette adresse..

Les diverses commandes que tu essaies de passer ne sont disponibles que lorsqu'un système GNU/Linux est opérationnel, ce qui n'est pas ton cas puisque tu es bloquée au démarrage.

Arbiel

#14 Re : -1 »  [Contournement] Comment indiquer le chemin vers key-file dans crypttab » Le 27/01/2015, à 14:57

Arbiel
Réponses : 5

Bonjour sirius007

Je comprends parfaitement ton argument. Désireux de chiffrer mon système, je me suis intéressé à LVM avec comme idée de construire un LVM sur une partition chiffrée pour n'avoir à saisir qu'une seule phrase de chiffrement tout en conservant des partitions distinctes en fonction de l'usage que j'en fais.

J'ai fait un certain nombre de tests sur des disques externes, qui n'ont pas abouti à des résultats positifs. En attendant, j'ai entrepris de chiffrer mes partitions existantes, d'où la question posée dans le titre de ma demande d'assistance.

Arbiel

#15 Re : -1 »  [Contournement] Comment indiquer le chemin vers key-file dans crypttab » Le 04/02/2015, à 22:52

Arbiel
Réponses : 5

Bonsoir

J'ai finalement écrit un script.

Je n'ai laissé comme déchiffrement automatique dans crypttab que la ligne de ma partition principale, /home, dans laquelle j'ai défini des fichiers qui contiennent les phrases de chiffrement des autres partitions. J'ai introduit l'option noauto dans les autres lignes dans lesquelles j'ai indiqué le chemin d'accès à ces fichiers dans le système opérationnel, cad après traitement de fstab.

hm UUID=9c21b407-620d-4511-8e5f-41b621d57505 none luks,retry=3
archives UUID=6800b9e6-5907-4589-b658-4d5796536daf /home/.archives luks,noauto
comptes UUID=8357f4d4-7d39-4c35-8497-117bc0e007a7 /home/.comptes luks,noauto

Dans fstab j'ai bien entendu utilisé l'option noauto sur les lignes correspondantes

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda12 during installation
UUID=f9efb22d-3fdb-4abb-9348-76bca44ed710 /               ext4    errors=remount-ro 0       1
/dev/mapper/hm /home ext4 defaults 0 2
# /boot/grub was on /dev/sda1 during installation
UUID=367C9BBD7C9B75F9 /boot/grub      ntfs    defaults,umask=007,gid=46 0       0
# /usr was on /dev/sda13 during installation
UUID=cbe8a864-9c76-4afe-96b3-a8a109e45a71 /usr            ext4    defaults        0       2
LABEL=multimedia    /media/multimedia ext4     defaults,noauto,owner    0      0
#UUID=102d6406-6d50-4aa4-9735-4e8ceef5d918 none            swap    sw              0       0
#/dev/mapper/cryptswap1 none swap sw 0 0
/dev/mapper/archives /home/archives ext4 defaults,noauto,user 0 2
/dev/mapper/comptes /media/Données ext4 defaults,noauto,owner 0 0

Mon script enchaîne les deux commandes
sudo cryptdisks_start et sudo mount pour déchiffrer et monter les partitions.

Comme j'ai eu des difficultés pour lancer ce script au démarrage du système, et que je ne veux pas saisir une seconde fois mon mot de passe (saisi une première fois pour le déchiffrement de ma partition /home) j'ai créé un fichier contenant mon mot de passe dans mon /home et j'ai eu recours à
cat <chemin accès motpasse> | sudo -Sv cryptdisks_start
Le script est lancé par un lanceur dans .config/autostart

#16 -1 »  [Résolu] geany ne veut plus se lancer » Le 03/02/2015, à 21:41

Arbiel
Réponses : 4

Bonsoir

Je viens de faire involontairement une manipulation malencontreuse qui a déstabilisé geany. À la suite de cette bévue, je  l'ai désinstallé complètement, arrêté mon PC avant de le réinstaller. Rien n'y fait.

Il me répète inlassablement

geany a écrit :

Geany a essayé d'accéder au socket de domaine Unix d'une autre instance d'un autre utilisateur.
Ceci est une erreur fatale et Geany va maintenant fermer.

Dois-je aller jusqu'à une réinstallation complète de mon système ?

Merci d'avance pour vos conseils

Arbiel

#17 Re : -1 »  [Résolu] geany ne veut plus se lancer » Le 04/02/2015, à 12:14

Arbiel
Réponses : 4

Bonjour tiramiseb

J'éprouve toujours un soulagement lorsque je vois que tu es l'auteur des réponses qui me sont faites car elles m'apportent des explications claires et me mettent sur la bonne voix pour la résolution de mes problèmes.

Je t'en remercie chaleureusement.

Oui, j'ai lancé geany par sudo. J'ai effectivement voulu modifier le fichier /etc/init.d/rc.local, ce qui est bien sûr une idée incongrue pour ne pas dire stupide. Sur ce sujet, j'en suis arrivé à me demander pourquoi nous écrivons du bash et non pas du sh tout court. Mais c'est là un autre sujet.

Voila le résultat de la commande

ls -lh .config/geany
total 28K
drwx------ 2 remi remi 4,0K mars   4  2014 colorschemes
drwx------ 2 remi remi 4,0K mars   4  2014 filedefs
-rw-rw-r-- 1 remi remi 5,8K févr.  3 18:00 geany.conf
lrwxrwxrwx 1 root root   26 févr.  3 18:46 geany_socket_remi-Vostro-3550__0 -> /tmp/geany_socket.2404ed19
-rw-rw-r-- 1 remi remi  157 juin   2  2014 keybindings.conf
drwx------ 2 remi remi 4,0K mars   4  2014 tags
drwx------ 3 remi remi 4,0K mars   4  2014 templates

Avec tous mes remerciements

Arbiel

Edit : ce répertoire n'aurait-il pas dû être supprimé lorsque j'ai "complètement" désinstallé geany ?

#18 Re : -1 »  [Résolu] geany ne veut plus se lancer » Le 04/02/2015, à 14:26

Arbiel
Réponses : 4

Merci beaucoup

Arbiel

#19 Re : -1 »  le disque dur /home n'est pas encore prêt ou présent 14.04 LTS » Le 28/01/2015, à 16:20

Arbiel
Réponses : 14

Bonjour

Pour pouvoir te venir en aide, il nous faut plus de détail sur ta configuration. Sans entrer dans le détail, peux-tu, en démarrant ton PC à partir d'un support externe, par exemple celui avec lequel tu as installé ton système, produire un rapport bootinfo (voir pour cela le logiciel boot-repair) et nous en communiquer l'adresse.

Ce rapport contient beaucoup d'informations, plus que nécessaire, mais il me semble plus facile à produire que l'exécution d'une liste de commandes.

Arbiel

#20 Re : -1 »  le disque dur /home n'est pas encore prêt ou présent 14.04 LTS » Le 01/02/2015, à 23:42

Arbiel
Réponses : 14

Bonsoir

Pourquoi ne produis-tu pas un rapport avec boot-repair, qui contiendra alors toutes les informations que te demandent les uns et les autres ? Ils pourront beaucoup plus rapidement diagnostiquer ce qui ne va pas et te mettre sur la voie.

Arbiel

#21 Re : -1 »  [Script/Tuto] Amorcer une image iso sans clé USB ni lecteur de CD-ROM » Le 30/01/2015, à 19:50

Arbiel
Réponses : 57

Bonsoir Laërte

Pour ma part, je n'ai pas testé ton script. Je le testerai peut-être si j'en trouve le temps et en ai l'occasion, mais j'attends plutôt l'interface graphique car c'est vraiment cette interface qui lui donnera toute sa valeur.

C'est bien sûr à toi qu'il revient de définir l'organisation de tes fichiers et j'ai compris que tu as l'intention de les distribuer sous la forme d'une archive avec un script pour les copier à leur place. C'est effectivement une solution intéressante.

J'ai néanmoins quelques remarques à formuler sur ce que tu as présenté

1) le contrôle de l'exécution en mode root : à mon avis, elle dépend de ton application car si l'on veut envisager de la lancer à partir d'un lanceur ou par un élément de menu contextuel, c'est bien ton application qui doit gérer le dialogue

2) le passage de paramètres au lancement du noyau : il me semblerait préférable de les mémoriser dans une variable et ce qui te permettra de tester beaucoup plus facilement s'il faut l'insérer ou si elle est déjà présente sur la ligne linux

3) pour ce qui est de la langue et du clavier, je crois qu'il est nécessaire de les prévoir dans les paramètres, et dans ton interface graphique.

Arbiel

#22 Re : -1 »  Grub rescue... » Le 27/01/2015, à 17:09

Arbiel
Réponses : 26

Me voila de retour.

Apparemment, compte tenu de ce que tu affiches au point #18, ton problème est résolu puisque tu as obtenu le menu de démarrage de grub. J'imagine, mais sans certitude, que tu as obtenu ce résultat en redémarrant après avoir retiré le périphérique amovible (clé USB ou CD d'installation). Vérifie cependant que le démarrage se passe correctement lorsque tu démarres avec ton seul disque dur.

Tu n'as donc plus rien à faire, si ce n'est de marquer cette discussion comme résolue.

Ce  qui suit peut éventuellement ne pas te paraître limpide. Je l'écris pour ceux qui serait intéressés par l'explication que je vais tenter de présenter.

Tout d'abord, je me permets d'insister sur le fait que, malgré les apparences, ce n'est pas le fait d'avoir modifié la position du drapeau boot qui a résolu le problème. Comme je l'ai affirmé plus haut, grub n'en tient absolument pas compte. Le drapeau boot n'est utilisé que par le BIOS (UEFI ?) pour décider si le périphérique en question est un candidat ou non au démarrage et par les logiciels Microsoft pour savoir sur quelle partition aller chercher le lanceur. Sans pouvoir être totalement affirmatif, puisqu'il existe potentiellement autant de versions de BIOS que de machines, dans une configuration avec le seul disque interne, pour les machines fonctionnant avec grub, le drapeau boot est absolument inutile. Il est tout aussi inutile de l'enlever.

Pour une raison que j'ignore totalement, core.img a initialisé $prefix en le faisant pointer sur le périphérique amovible au lieu du disque interne. Or il n'y a aucune partition 6 sur ce périphérique, ce qui fait que la ligne "if [ -s $prefix/grubenv ]; then" du fichier grub.chg envoie grub dans l'inconnu, ce qu'il traduit par
grub rescue (je suis perdu)

Cela peut paraître bizarre car très rare, mais quelqu'un aurait-il une meilleur explication, avant que je ne fasse un rapport d'anomalie à l'équipe de développement ?

Arbiel

#23 Re : -1 »  Grub rescue... » Le 29/01/2015, à 00:04

Arbiel
Réponses : 26

Bonsoir

@Medux90

Tout cela n'est pas très clair. Nous te venons en aide bénévolement. Il faudrait que de ton côté tu joues le jeu, c'est-à-dire que tu lises ce que nous écrivons et que tu répondes à nos interrogations, qu'elles soient directes ou indirectes.

Il me semble t'avoir demandé si ton PC démarre correctement lorsque tu retires tous les supports amovibles, clé USB et CD/DVD. La manipulation que tu présentes au point 25 semble correspondre à une configuration dans laquelle il y a au moins deux supports susceptibles de servir au démarrage. Si l'écran que tu as présenté au point 6 est correct, de tels périphériques sont
1) le lecteur de disquettes : je doute fort que tu aies une disquette dont le 1er secteur contienne grub. Alors quel est ce mystérieux périphérique de plus haute priorité ?
2) le disque dur : pour l'utiliser en priorité, il a fallu que tu entres dans le BIOS pour modifier l'ordre de démarrage. Quel était alors le périphérique de plus haute priorité (c'est en fait la même question).

Retire tous les périphériques amovibles et redémarre. Que se passe-t-il ?

Deux autres points

grub n'a que faire du drapeau boot. Mais tel n'est pas le cas de Windows. Si tu veux conserver ton système Windows, mets le drapeau boot sur sda1, ou laisse-le sur sda1 si tu ne l'as pas déplacé. Windows cherche BOOTMGR sur la partition qui porte le drapeau boot. S'il ne le trouve pas, il affiche le message "BOOTMGR is missing" et le démarrage échoue. Or ce fichier est sur sda1. Si tu tardes à remettre en bonne place ce drapeau boot, tu risques, dans six mois, un an, ou que sais-je, lorsque tu voudras pour une fois démarrer avec Windows, tomber sur le problème et, compte tenu du temps écoulé depuis aujourd'hui, ne plus avoir en mémoire ce que je viens de te dire et te trouver désappointé.

la commande que kalunux te demande d'exécuter ne peut pas faire de mal car l'option --recheck a comme effet de réinitialiser une table utilisée pour calculer $prefix, table qui peut avoir été corrompue et avoir ainsi conduit grub à initialiser cette variable avec une valeur erronée. Par contre je crains fort que l'option "--force-file-id" n'ait aucun effet. En effet, elle sert à insérer deux commandes dans core.img qui consistent à calculer la variable $prefix à partir du résultat de la recherche d'un fichier particulier que grub-install crée dans le répertoire grub/uuid, mais uniquement lorsque ce répertoire grub et le MBR utilisé au démarrage ne sont pas sur le même support. Pour que cette option fonctionne, qui est une excellente idée, il faudrait que tu installes grub sur /dev/sda1 et que tu définisses le répertoire grub sur un support externe avec l'option --boot-directory, puis que tu définisses à la main dans ton répertoire grub de sda6 un "sous-répertoire" nommé uuid dans lequel il te faudrait créer le fameux fichier que recherche une des deux lignes insérées dans core.img pour calculer $prefix.
Mais ceci est peut-être un peu nébuleux puisque tu ne maîtrises pas encore les procédures de démarrage.

Arbiel

#24 Re : -1 »  résolu Dossier personnel:"Certains contenus sont impossible à lire" » Le 28/01/2015, à 16:27

Arbiel
Réponses : 3

Bonjour

Ce doit être un problème de droits d'accès.

Les répertoires et les fichiers dont le nom commence par un "." sont des fichiers cachés, en général liés à une application ou à un paquet. C'est le cas pour  .gvfs.

Tout devrait être normal et tu n'as pas lieu de t'inquiéter outre mesure.

As-tu détecté des comportements inquiétants ?

Arbiel