O
OmikronSoul

  • 7 déc. 2014
  • Inscrit 26 déc. 2012
  • 0 meilleure réponse
  • Petit nouveau
  • Bonjour ou bonsoir, en fonction de si vous avez ou non la chance d'avoir un cycle de sommeil correct.

    Je suis en train d'essayer de faire fonctionner Final Fantasy IX sous Fedora via l'émulateur PCSX-R. Je suis parvenu à configurer le driver OpenGL de manière à obtenir un résultat visuel correct, mais rencontre de sérieux problèmes au niveau du son. En effet, il a tendance à se bloquer durant les cinématiques et à boucler sur une mesure très courte, faisant saigner mes oreilles au passage. Apparemment, c'est un bug assez courant avec ce jeu et ce driver audio (le son SDL par défaut). Activer l'option "High compatibility mode" dans la config sonore règle le problème, mais le son a alors tendance à saccader durant tout le jeu.

    J'ai donc tenté d'installer d'autres plugins audio, mais l'émulateur refuse de les reconnaître et affiche ce message d'erreur quand lancé via un terminal :
    /home/Fedora/.pcsxr/plugins/libspuEternal.so.1.41: mauvaise classe ELF : ELFCLASS32
    
    De ce que j'ai compris en fouillant le net, il s'agirait d'une erreur due au fait que les plugins soient prévus pour une architecture 32 bits alors que mon système et la version de PCSXR est en 64 bits.

    Après avoir désinstallé PCSXR x86_64 et installé la version i686 (toutes deux en version 1.9.93), les plugins audio ne peuvent toujours pas être chargés. J'obtiens le message d'erreur suivant pour spuEternal :
    libstdc++-libc6.2-2.so.3: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou dossier de ce type
    

    ...et pour PE.Op.S (qui s'affiche désormais dans la liste des plugins disponibles) :
    ./cfgPeopsOSS: error while loading shared libraries: libgtk-1.2.so.0: cannot open shared object file: No such file or directory
    
    On dirait une erreur de dépendance, mais le paquet libstdc++ est pourtant installé. À ce stade j'avoue commencer à sécher et surtout à m'endormir. Aussi si quelqu'un a une idée pour résoudre ou faire avancer le problème, je suis preneur.
  • J'ai tenté un yum remove *nvidia* supplémentaire, mais tout ce qui concerne nvidia a bel et bien l'air d'avoir disparu.

    En revanche j'ai découvert un problème supplémentaire : Quand j'essaie de le rallumer après une mise en veille, le pc émet un son et reste sur un écran noir, forçant au reboot.
  • Bonjour à tous

    La joie de l'installation de drivers étant une des plus nobles traditions linuxienne, je suis ravi de voir que Heinsenbug me gâte plus que jamais.

    L'épisode précédent ayant été l'installation des pilotes propriétaires et sacrifice rituel de Plymouth, puis la révélation que les jeux que je souhaitais faire fonctionner grâce à ces nouveaux drivers fonctionnaient encore moins bien qu'auparavant, j'ai voulu tenter de rétablir ma configuration initiale et réinstaller Nouveau. J'ai pour cela suivi le même tutoriel que lors de l'installation, à savoir celui-ci.

    Sauf que.
    https://pbs.twimg.com/media/BlBa6O-CEAAhbug.png:large

    Voilà ce que j'obtiens en lançant Cinnamon. Pour ce qui est de GNOME, il semble encore plus buggé que d'habitude. Tant qu'à MATE, je ne l'ai pas utilisé suffisamment longtemps pour pouvoir noter une différence.

    La carte graphique est une Nvidia GeForce 410M. J'ai récupéré le log de Xorg si nécessaire (ou plutôt les trois logs, mais ne parvenant pas à savoir lequel était le bon j'ai uploadé les trois) : https://www.dropbox.com/sh/gzhci7x0jtrgmhs/V_Ack0hR7Y

    Quelqu'un aurait-il une solution au problème ?
  • J'ai finalement cédé à la tentation du gros copier-coller (Heureusement mon home n'était pas trop conséquent). J'ai créé un nouvel utilisateur et lui ai créé un répertoire dans lequel j'ai transféré le contenu déchiffré du /home. Merci beaucoup pour le coup de main !
  • L'utilisateur n'est toujours pas accessible hors terminal et ecryptfs-mount-private ne fonctionne plus (cf. message #17).
  • Le répertoire est bel et bien accessible. Pour ce qui est de /etc/fstab :
    # Created by anaconda on Fri Mar  7 17:52:01 2014
    #
    # Accessible filesystems, by reference, are maintained under '/dev/disk'
    # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
    #
    UUID=53401ef5-f72d-4633-9b6e-b0fd7a571494 /                       ext4    defaults        1 1
    UUID=c499e930-f8f7-4660-9921-72ee4f1cd3ee /home                   ext4    defaults        1 2
    
    crypttab semble vide.
  • Inserted auth tok with sig [tl;dc] into the user session keyring
    USEECRYPTFS est bien activé.
  • Aucun changement (d'ailleurs j'avais déjà ajouté l'utilisateur au groupe ecryptfs). Si je tente de me connecter en terminal, j'obtiens l'erreur suivante :
    change directory failed : Permission denied.
    Logging with home ="/".
    Tant qu'au raccourci, il semblait réclamer xTerm, mais ne fonctionne toujours pas une fois celui-ci installé.
  • Il s'est effectivement monté sur /tmp, mais sans passer par ecryptfs-mount-private (Encrypted private directory is not setup properly).
  • marc2006 wrote:Ok bon donc j'ai eu l'information que je voulais lol le ls -al /home était pas inutile donc :p

    Un
    ecryptfs-recover-private /home/.ecryptfs/user/.Private
    donne quoi ?
    Fichiers récupérés !

    À force de me battre avec chaque utilitaire j'avais fini par oublier celui-ci. En revanche, l'ancien utilisateur ne peut toujours pas se connecter normalement. Je vais voir s'il faut reconfigurer les permissions ou faire une manip pour monter automatiquement le dossier chiffré au démarrage du système. Quoi qu'il en soit la phase de panique est passée et je peux toujours copier le contenu du dossier chiffré dans le répertoire d'un nouvel utilisateur. Merci énormément !
  • Léger progrès en perspective : J'ai à nouveau tenté de monter l'ancien répertoire user, cette fois-ci dans celui de l'utilisateur que j'utilise en ce moment.

    Un ls -al affiche désormais les noms de mes fichiers chiffrés, mais ils sont illisibles. De plus, les permissions ne s'affichent pas. J'ai donc une longue liste semblable à cela :
    d??????????  ? ?       ?           ?            ? .adobe
    d??????????  ? ?       ?           ?            ? .android
    d??????????  ? ?       ?           ?            ? .aptitude
    d??????????  ? ?       ?           ?            ? Backup
    
  • Oh. Il semblerait que j'ai fait une erreur.

    Lorsque eOS a chiffré mon dossier personnel, il n'a en fait pas à proprement parler utilisé /home/user. Je viens de trouver les fichiers chiffrés dans /home/.ecryptfs/user/.Private. Le logiciel a donc bel et bien utilisé un dossier .Private, et a placé un lien symbolique dans /home/user.

    Malheureusement, cela ne change pas grand-chose. Déchiffrer le contenu de /home/.ecryptfs/user/.Private ne fonctionne pas mieux et j'imagine que c'était déjà ce que je faisait auparavant sans savoir que je passait par un lien symbolique.

    Concernant le nom d'utilisateur, j'en ai créé un nouveau que j'utilise en ce moment. L'ancien ne peut tout simplement pas se connecter. J'ignore si c'est dû au chiffrage de son répertoire personnel ou à une erreur de permissions, mais ce n'est pas la priorité.
  • Je ne pense pas que ce soit la partition entière qui ait été chiffrée, mais juste le répertoire personnel. Les deux fichiers lisibles de /home/user/ faisant référence à ecryptfs, c'est certainement cette méthode qui a été utilisée (d'autant plus que j'ai pu récupérer la clef de chiffrement avant le changement d'OS).

    Je suis presque certain de ne pas avoir eu besoin de mot de passe pour monter la partition /home lors de l'installation. Raison de plus de penser que seuls les fichiers ont été chiffrés.
  • La commande ecryptfs-mount-private concerne les dossiers .Private créés avec l'utilitaire ecryptfs-setup-private, ce qui n'est pas mon cas. L'installation d'Elementary OS m'ayant proposé de chiffrer mon /home, j'ai accepté à ce moment. De retour sur Fedora, je peux utiliser ma partition /home mais n'ai plus accès à mon ancien répertoire personnel (ici renommé en user).
  • J'ai tenté de monter le répertoire chiffré de cette manière :
    [root@localhost userBis]# mount -t ecryptfs /home/user /media/decrypted2
    Select key type to use for newly created files: 
     1) tspi
     2) openssl
     3) pkcs11-helper
     4) passphrase
    Selection: 4
    Passphrase: 
    Select cipher: 
     1) aes: blocksize = 16; min keysize = 16; max keysize = 32
     2) blowfish: blocksize = 8; min keysize = 16; max keysize = 56
     3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
     4) twofish: blocksize = 16; min keysize = 16; max keysize = 32
     5) cast6: blocksize = 16; min keysize = 16; max keysize = 32
     6) cast5: blocksize = 8; min keysize = 5; max keysize = 16
    Selection [aes]: 
    Select key bytes: 
     1) 16
     2) 32
     3) 24
    Selection [16]: 
    Enable plaintext passthrough (y/n) [n]: 
    Enable filename encryption (y/n) [n]: y
    Filename Encryption Key (FNEK) Signature [a0d2e00ecfbe29ac]: 
    Attempting to mount with the following options:
      ecryptfs_unlink_sigs
      ecryptfs_fnek_sig=a0d2e00ecfbe29ac
      ecryptfs_key_bytes=16
      ecryptfs_cipher=aes
      ecryptfs_sig=a0d2e00ecfbe29ac
    WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
    it looks like you have never mounted with this key 
    before. This could mean that you have typed your 
    passphrase wrong.
    
    Would you like to proceed with the mount (yes/no)? : yes
    Would you like to append sig [a0d2e00ecfbe29ac] to
    [/root/.ecryptfs/sig-cache.txt] 
    in order to avoid this warning in the future (yes/no)? : yes
    Successfully appended new sig to user sig cache file
    Mounted eCryptfs
    
    Après cette opération, le contenu de /media/decrypted2 est le même que celui de la tentative précédente (un fichier .desktop et un Readme). J'ai à nouveau essayé de le déchiffrer une seconde fois, et le message d'erreur fut exactement le même que celui du premier post. J'ai cependant fait un dmesg | tail comme suggéré :
    [  286.808034] One or more global auth toks could not properly register; rc = [-2]
    [  286.808036] Error parsing options; rc = [-2]
    [  335.987682] Could not find key with description: [a0d2e00ecfbe29ac]
    [  335.987687] process_request_key_err: No key
    [  335.987689] Could not find valid key in user session keyring for sig specified in mount option: [a0d2e00ecfbe29ac]
    [  335.987690] One or more global auth toks could not properly register; rc = [-2]
    [  335.987692] Error parsing options; rc = [-2]
    [  502.430841] SELinux: initialized (dev ecryptfs, type ecryptfs), uses genfs_contexts
    [  589.135953] Mount on filesystem of type eCryptfs explicitly disallowed due to known incompatibilities
    [  589.136021] Reading sb failed; rc = [-22]
    
    Pour ce qui est de mon mot de passe, il fonctionne correctement. La seule erreur possible viendrait de la phrase de passe qui est un code que je copie-colle.

    À défaut de pouvoir chercher ailleurs, je vais me renseigner à propos de ce bug de SELinux.
  • marc2006 wrote:Salut =)

    Et si tu faisais un simple ecryptfs-recover-private en root ? 🙂

    PS : on dit "chiffré" pas "crypté" 🙂
    Sans arguments ?
    [root@localhost ecryptfs.wRbss549]# ecryptfs-recover-private
    INFO: Searching for encrypted private directories (this might take a while)...
    find: ‘/run/user/1001/gvfs’: Permission non accordée
    
    Le résultat est le dossier Private de l'utilisateur 1001, créé en tâtonnant avec ecryptfs-setup-private. Visiblement la fonction ne recherche que ce genre de dossiers quand on ne lui passe pas d'argument.
  • Bonjour à tous.

    J'ai tout récemment voulu remplacer ma distribution Elementary OS (dérivée d'Ubuntu) pour un retour à Fedora. J'ai pour cela reformaté le système de fichier, à l'exception du /home qui était sur une partition à part.

    Je me doutais que le chiffrement du home pourrait poser problème, et ai donc récupéré la clef de chiffrement ecryptfs avant l'installation. L'utilisateur créé durant l'installation ayant le même login et mot de passe que sous Elementary, le /home de l'utilisateur lui a été correctement attribué. Malheureusement, impossible de l'utiliser (ni même de se connecter avec cet utilisateur puisque son répertoire n'est pas accessible).

    J'ai tenté de déchiffrer le dossier normalement grâce à ecryptfs-recover-private, mais le résultat obtenu est identique à celui d'un bête ls /home/user :
    [root@localhost ecryptfs.wRbss549]# ls
    Access-Your-Private-Data.desktop  README.txt
    
    Le fichier .desktop renvoie à un fichier ayant disparu lors du formatage, et README.txt ne fait que renvoyer vers ecryptfs-mount-private.

    Pensant que le dossier avait peut-être été re-chiffré par erreur lors de l'installation, j'ai tenté un second décodage. Sans succès :
    [root@localhost ecryptfs.wRbss549]# ecryptfs-recover-private /tmp/ecryptfs.wRbss549/
    INFO: Found [/tmp/ecryptfs.wRbss549/].
    Try to recover this directory? [Y/n]: 
    INFO: Could not find your wrapped passphrase file.
    INFO: To recover this directory, you MUST have your original MOUNT passphrase.
    INFO: When you first setup your encrypted private directory, you were told to record
    INFO: your MOUNT passphrase.
    INFO: It should be 32 characters long, consisting of [0-9] and [a-f].
    
    Enter your MOUNT passphrase: 
    mount: mauvais type de système de fichiers, option erronée, superbloc erroné
            sur /tmp/ecryptfs.wRbss549, page de code ou programme auxiliaire manquant, ou autre erreur
    
            Dans certains cas des renseignements utiles sont dans le journal
            système — essayez « dmesg | tail » ou quelque chose du genre.
    
    Je suis à court de solutions et Google semble l'être aussi.
  • Il y a un réel progrès, pusique l'installation s'est lancée. Mais crash à 82% :-? :
    Linking CXX executable recorditnow
    /bin/ld: CMakeFiles/recorditnow.dir/cursorwidget.o: référence au symbole non défini «XCreatePixmap»
    /bin/ld: note: «XCreatePixmap» est défini dans le DSO /lib64/libX11.so.6 donc essayez de l'ajouter à la ligne de commande du lieur
    /lib64/libX11.so.6: could not read symbols: Opération invalide
    collect2: erreur: ld a retourné 1 code d'état d'exécution
    make[2]: *** [src/recorditnow] Erreur 1
    make[1]: *** [src/CMakeFiles/recorditnow.dir/all] Erreur 2
    make: *** [all] Erreur 2
    
  • Aucun n'était installé, hormis gcc. Mais ça ne fonctionne malheureusement pas pour autant :-?
    -- The C compiler identification is GNU 4.7.2
    -- The CXX compiler identification is GNU 4.7.2
    -- Check for working C compiler: /bin/cc
    -- Check for working C compiler: /bin/cc -- works
    -- Detecting C compiler ABI info
    -- Detecting C compiler ABI info - done
    -- Check for working CXX compiler: /bin/c++
    -- Check for working CXX compiler: /bin/c++ -- works
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Looking for Q_WS_X11
    -- Looking for Q_WS_X11 - found
    -- Looking for Q_WS_WIN
    -- Looking for Q_WS_WIN - not found
    -- Looking for Q_WS_QWS
    -- Looking for Q_WS_QWS - not found
    -- Looking for Q_WS_MAC
    -- Looking for Q_WS_MAC - not found
    -- Found Qt4: /bin/qmake-qt4 (found version "4.8.4") 
    -- ----------------------
    -- LIBRARY_INSTALL_DIR=/usr/lib64
    -- PLUGIN_INSTALL_DIR=/usr/lib64/joschy
    -- INCLUDE_INSTALL_DIR=/usr/include/joschycore
    -- ----------------------
    CMake Error at /usr/share/cmake/Modules/FindKDE4.cmake:98 (message):
      ERROR: cmake/modules/FindKDE4Internal.cmake not found in
      /root/.kde/share/apps;/usr/share/kde-settings/kde-profile/default/share/apps;/usr/share/kde4/apps
    Call Stack (most recent call first):
      CMakeLists.txt:9 (find_package)
    
    
    CMake Warning (dev) in CMakeLists.txt:
      No cmake_minimum_required command is present.  A line of code such as
    
        cmake_minimum_required(VERSION 2.8)
    
      should be added at the top of the file.  The version specified may be lower
      if you wish to support older CMake versions for this project.  For more
      information run "cmake --help-policy CMP0000".
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    -- Configuring incomplete, errors occurred!
    
  • Bonjour à tous

    Je me démène actuellement pour trouver un logiciel de screencast permettant d'enregistrer mon écran ET l'audio interne (pas le micro, donc), ce que RecordMyDesktop n'a pas réussi à faire jusqu'à présent (il y a des dizaines de "solutions" à ce problème sur le net, toutes plus farfelues et impuissantes les unes que les autres).

    J'ai entendu parler de Recorditnow, mais pas moyen de trouver un rpm correct et comme je suis un vrai manchot pour compiler depuis les sources, j'ai suivi telle quelle la méthode donnée sur le site mentionné plus haut. Le résultat (après avoir installé cmake) fut le suivant :
    CMake Error: your C compiler: "CMAKE_C_COMPILER-NOTFOUND" was not found.   Please set CMAKE_C_COMPILER to a valid compiler path or name.
    CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found.   Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
    CMake Error: your C compiler: "CMAKE_C_COMPILER-NOTFOUND" was not found.   Please set CMAKE_C_COMPILER to a valid compiler path or name.
    CMake Error: your CXX compiler: "CMAKE_CXX_COMPILER-NOTFOUND" was not found.   Please set CMAKE_CXX_COMPILER to a valid compiler path or name.
    CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:97 (message):
      Could NOT find Qt4 (missing: QT_QMAKE_EXECUTABLE QT_MOC_EXECUTABLE
      QT_RCC_EXECUTABLE QT_UIC_EXECUTABLE QT_INCLUDE_DIR QT_LIBRARY_DIR
      QT_QTCORE_LIBRARY)
    Call Stack (most recent call first):
      /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:291 (_FPHSA_FAILURE_MESSAGE)
      /usr/share/cmake/Modules/FindQt4.cmake:1223 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
      joschy-snapshot-23-02-10/CMakeLists.txt:18 (find_package)
    
    
    CMake Warning (dev) in CMakeLists.txt:
      No cmake_minimum_required command is present.  A line of code such as
    
        cmake_minimum_required(VERSION 2.8)
    
      should be added at the top of the file.  The version specified may be lower
      if you wish to support older CMake versions for this project.  For more
      information run "cmake --help-policy CMP0000".
    This warning is for project developers.  Use -Wno-dev to suppress it.
    
    -- Configuring incomplete, errors occurred!
    
    Je précise que j'ai mis Qt à jour, mais rien n'y fait.

    Quelqu'un a une idée ?


    PS : Je suis sous Fedora 18 Openbox. Mais je dispose aussi de GNOME et Cinnamon.