Jacq
@VINDICATORs:
Merci pour votre réponse.
En fait, les choses semblent pour moi un peu curieuses.
Après m'être connecté à mon compte d'administrateur, j'ai pu constater que le dossier "lib" contenait les fichiers "libudev.so" et "libudev.so.1" mais pas le fichier "libudev.so.0" !
Donc, déjà première curiosité.
Ensuite, tous les dossiers contenus dans le répertoire racine "/" ont pour propriétaire "root" et pas mon compte administrateur. Est-ce normal? Le mot de passe root est différent de celui de l'administrateur mais quand même ça bloque un peu fort peut-être.
Néanmoins, je peux rentrer dans ces répertoires en tant qu'administrateur et j'ai fait une copie du fichier "libudev.so" en "libudev.so.0" dans le répertoire "lib".
Après, j'ai redémmaré l'installation de mon logiciel SMART Notebook mais de nouveau il est requis le paquet "libudev.so.0" qui n'est donc pas trouvé. Donc, je cale.
De façon surprenante, dans le dossier "opt" il n'y a qu'un dossier au nom de "google".
Le dossier "root" est inaccessible à partir de mon compte d'administrateur.
Ca fait beaucoup.
Des idées?
Merci par avance
Jacq
chepioq
Qu'appelles-tu compte administrateur ?
Comment l'as-tu créé ?
Jacq
@chepioq:
Lors du processus d'installation de Fedora 20, deux mots de passe distincts sont demandés: l'un pour "root" et un autre pour un compte "administrateur" créé simultanément et de nom arbitraire choisi par celui qui fait l'installation. A noter que l'utilisation de l'applet "Utilisateurs et groupes" permet la création de compte selon deux types: administrateur ou standard, ce qui permet d'identifier le type du compte dans lequel on se trouve par ailleurs. Le type "root" n'y est pas; ce qui me paraît normal.
Jacq
nouvo09
Le compte root est LE compte administrateur. On peut ne pas l'activer ou plus exactement déléguer ses fonctions à un autre compte.
Il n'existe pas de type "root".
VINDICATORs
Suffit aussi de faire un lien symbolique avec 0.so au lieu de 1.so, ça fonctionne très souvent.
Heldwin
* Le choix du type Administrateur sur linux est pour ajouter l'utilisateur au groupe "wheel"
Les utilisateurs inclus dans le groupe wheel sont, en utilisant la commande "sudo", autorisé à pouvoir agir comme le compte root, en demandant le mot de passe utilisateur. Une des raisons du pourquoi il faut restreindre les droits dans sudo quand on délègue sa machine.
* Dans /opt, c'est un des emplacements pour y mettre des installations provenant d'installations non-packagées.
Le fait qu'il y ait un dossier "google" dedans, signifie que tu as dû utiliser un installeur ou autres qui a créé ce dossier dans /opt.
* Le dossier /root possède les droits: root:root , et on peut remarquer que le droit du groupe n'est pas wheel 🙂
Il ne se trouve pas dans /home, car sinon ça poserait un problème pour agir en mode rescue ou autres, et qu'on devait agir sur la partition /home.
Tu peux agir dedans en utilisant la commande sudo, avant la commande que tu veux utiliser (sudo cd /root)
* Par contre, ce que je trouve surprenant, c'est que tu aies pu renommer un fichier dans /lib, sans utiliser sudo, avec cet utilisateur définit en administrateur ?
Tu peux indiquer ce que tu as fait exactement pour renommer ce fichier ? D'après moi, il manque une étape dans ce que tu as dit.
Ca a demandé un mot de passe ?
Jacq
@Heldwin:
Merci beaucoup.
J'ai effectivement utilisé la commande sudo. Plus précisément, puisqu'il n'y avait pas dans le dossier /lib le fichier libudev.so.0 mais seulement les fichiers libudev.so et libudev.so.1, j'ai fait la commande dans le dossier /lib:
sudo cp libudev.so.1 libudev.so.0
Après vérification, libudev.so.0 est bien apparu dans /lib.
Puis, j'ai relancé l'installation. Mais apparement l'installateur n'a pas trouvé le fichier /lib/libudev.so.0 créé par la précédente commande car l'installation s'arrête juste avoir indiqué que le fichier libudev.so.0 est requis. Donc, peut-être que l'installateur cherche le fichier libudev.so.0 dans un autre dossier. Ou alors, il identifie correctement libudev.so.0 créé comme étant en fait libudev.so.1, et il s'arrête.
Comment comprendre ce qui se passe?
Merci encore.
Jacq
Heldwin
Tu as indiqué être en x86_64, donc essaye de faire ce lien symbolique dans /lib64 et non dans /lib
Jacq
Bonjour Heldwin,
Je vais essayer ce que tu m'indiques.
Accessoirement, j'ai envoyé une email au service d'assistance de la compagnie qui fournit le logiciel (Smarttech) et ils m'ont répondu qu'il ne fonctionne que sur des machines 32bits et que je dois utiliser de telles machines.
Je ne lui est pas demandé en réponse s'il pouvait m'en acheter une!
D'ailleurs, il ne doit plus y en avoir beaucoup de ces machines 32 bits maintenant.
Maintenant, autre problème. Ce matin en voulant me connecter à mes comptes Linux sur "ma machine 64bits", je n'y suis pas parvenu. Le démarrage se bloque et je n'ai que le logo bleu de Fedora à l'écran. En appuyant sur une touche F (par exemple) je passe en mode terminal et je constate que le dernier message indiqué est : "Reached target initrd Default Target" et plus rien; le noir complet...
Je constate que Linux ou Fedora 20 est beaucoup plus instable que je l'imaginais. C'est assez désappointant et très ennuyeux. Comment faire pour redémarrer sans tout ré-installer?
En tous les cas merci Haldwin pour ton suivi.
Amicalement
Jacq
nouvo09
Je constate que Linux ou Fedora 20 est beaucoup plus instable que je l'imaginais.
Tu vas peut-être un peu vite en besogne. Parce que c'est loin d'être l'avis général.
Cela dit je pense que l'éditeur en question a voulu parler de systèmes en 32 bits et non de machine.
Jacq
@nouvo09
En tous les cas je ne peux plus booter sur mon installation de Fedora.
Donc, le problème est résolu, système foutu...
J'ai beau regarder sur le forum des problèmes de démarrage; rien n'y fait, je ne parviens plus à booter sur ma partition linux.
Sujet non-résolu.
Je sors de Linux et parfaitement ecoeuré...
Bye
nouvo09
Bah dis, si tous ceux qui ont vu un Windows planter devaient le quitter, Bill Gates serait abonné aux restos du coeur !
Jacq
Je ne suis pas sur Windaube... mais sur OSX qui plante pratiquement jamais.
Le problème c'est la politique commerciale sur le hardware, SAV, etc..., qui devient une belle vacherie avec ces systèmes. Problème du client captif.
Maintenant, Linux risque aussi d'avoir un problème si les documentations (en ligne ou pas) ne suivent pas (l'actualisation de la doc ne suit pas celle de l'OS, et on ne peut pas sans arrêt passer par des bénévoles en ligne... le temps que j'ai perdu pour aboutir à un système qui ne fonctionne plus du tout et que je dois réinstaller en totalité, c'est pas possible...). Quand aux bugs, si des programmes stochastiques de débogages massifs ne sont pas mis en place, Linux risque d'avoir des problèmes.
Personnellement, je n'ai pas arrêté d'avoir des problèmes de bugs sur l'ordi où j'ai installé Linux.
Je reviendrai sur Linux peut-être plus tard, mais là je peut pas me permettre des pertes aussi importantes de temps. C'est trop dément. De plus, même si les bugs sont éliminés par le travail des développeurs, le problème d'une standardisation des procédures d'installations ou de diagnostics des problèmes risque d'être fatal car il n'y aura plus assez de bonnes âmes bénévoles pour résoudre tous les problèmes des utilisateurs; résolutions parfois trop hasardeuses. Les forums n'y suffiront pas.
Je le regrette beaucoup. Mais, là, Linux, c'est stop pour moi.
Le problème futur pour moi ça va être l'archivage des données personnelles sur des supports privés (genre NAS) indépendant de l'OS et du hardware, sans passer par des "clouds"... et c'est pas évident.
Linux est une alternative, mais il risque d'y avoir une complexité algorithmique de l'OS qui risque d'exploser la pérennité du système libre à mon avis vu l'expérience que je viens d'avoir.
Je clos le sujet.... NON RESOLU PLUS PLANTAGE DEFINITIF.
Dommage.
Edouard_le_homard
il faut choisir la distribution en fonction de tes besoins. Si tu veux une distro très stable, choisis plutôt CentOS ou Debian. On ne peut pas avoir un système à la pointe des derniers développements et très stable...
VINDICATORs
Autre alternative si t'en a besoin ponctuellement, c'est de virtualiser un os 32bits, c'est très simple et rapide.
Avec kvm/quemu et virt-manager c'est aussi simple et bien plus complet que virtualbox par exemple.
Mais bon là c'est sans doute plus dut à une version obsolète qu'à un souci avec la librairie 32 bits.
Perso Je préfère faire des liens que des copies, ça permet d'avoir la mise à jours sans devoir retoucher au fichier.
nouvo09
VINDICATORs
Dsl, les anglois me pervertisse!
BIBILIOTHEQUE (Homère Simpson)
mtirabo
Bonjour...si ta Fedora ne démarre plus c'est sans doute parce que tu as fait quelque chose qui fait que maintenant tu ne demarres plus....linux est ce qu'il y a de plus stable, sécurisé...
Essais de refaire à l'inverse ce que tu as fait...par exemple si tu as fait une copie d'un fichier et que tu l'as déplacé dans un dossier, supprimes la copie...
Personellement je pense que la solution d'un lien symbolique entre 2 versions d'un fichier peut fonctionner, je l'ai déjà fait...mais le seul responsable du plantage c'est toi...avant de faire n'importe quoi, renseignes toi, viens sur le forum et poses tes questions mais après avoir toi même créer le problème, ne t'en prends qu'à toi même...
VINDICATORs
Au passage, les systèmes de déboguage sont en place depuis longtemps, mais après si les éditeurs ne suivent pas le mouvement...
Et puis le SAV il y a des versions payantes qui le propose et ça fonctionne très bien, suffit de voir le CA de Redhat et d'autres pour s'en convaincre.
Après pourquoi faire l'impasse sur le 64bits? cela m'étonne encore de nos jours, mais encore une fois les histoires de compatibilité de ce genre existé lors du passage du 8 au 16 bits, du 16 au 32. Je peux en parler, j'y étais! Après je veux bien croire qu'il y ai un souci, mais là c'est parce que l'éditeur ne propose pas une version à jour pour la version d'udev actuel. Ils proposent une version rpm sans même savoir si ça fonctionne.
Après on te l'a dit, si tu veux une version ultra stable prend la CentOS, si tu veux du support prend du RedHat, mais le prix n'est pas le même. Cependant le passage vers le 64bits risque d'être encore plus obligatoire...
Après même sur un produit commercial avec du support derrière on est pas à l'abri de mettre à terre son système, j'ai eu le cas dernièrement où même le support hyper chère (vous n'imaginez pas le prix...) n'a pas été capable de trouver une solution. La solution fut trouvé en partie sur un site obscure que le système de sécurité en place ne voulait pas donner l'accès.
Donc non on est jamais à l'abri des problèmes, si en plus on fait n'importe quoi même le système le plus stable de l'univers n'est pas à l'abri.
Après tu peux forcer l'installation d'une ancienne version d'udev, il suffit de regarder du coté de la doc de rpm pour forcer cela. Mais bon on n'assure pas le bon fonctionnement par la suite.
Si les développeurs ne veulent pas mettre à jours leurs logiciels pour l'adapter à une version récente d'udev, on n'y peut rien, la philosophie de Fedora étant de toujours aller de l'avant! Il suffit de lire les conditions d'utilisations, Fedora est un "Laboratoire", on aime ou on aime pas. Comme on le dit il suffit de tourner sur CentOs pour enfin avoir du stable.
Après la nouvelle manière de faire de Fedora à partir de F21 semble calmer un peu les choses.
Enfin bref, là udev semble être plus critique à gérer quand même, mais ça ne me semble pas insurmontable d'avoir une mise à jour.
L'histoire du 32 pas 64 est une utopie pour ce genre de chose, sachant que l'on peut faire tourner du 32 sur une 64 bits! Non seule la version de la bibliothèque est en cause!
paradise
Parce qu'on ne trouve pas de solution avec une appli, c'est la faute au système, bien sûr...
Et l'éditeur, alors ?
J'adore cette façon de tout rejeter en bloc sans avoir identifié la source du problème, et pour à la finale porter un jugement global et définitif sur un système entier...
De toute façon, comme c'était parti, il y aurait eu certainement des critiques pour d'autres choses du même ordre, mieux vaut en effet que notre visiteur furtif revienne vers les autres OS.
Heureusement qu'il n'a pas testé BSD, Solaris...