Je vais peut-être dire une ânerie mais tes PC ne sont-ils pas encore équipés d'un port parallèle ? S'il y a du RS/232 (port série) alors le port imprimante est en général disponible. Le RS/232 a été le premier à disparaître pour promouvoir l'USB dans le courant des années 2000 mais l'autre avait eu un sursis.
Dans l'affirmative, alors le port parallèle est à la fois ce qu'il y a de plus simple à programmer, de plus simple à bricoler et pas loin d'être le plus robuste également. Tous les geeks des années 1980 à 2010 qui ont fait un peu d'électronique se sont un jour amusés à brancher une LED dessus et à essayer de la piloter.
C'est vraiment étrange. Comme dit juste au dessus, on ne peut pas écarter totalement la défectuosité de ton câble même si, comme tu l'as indiqué, ça fonctionne sous Windows. Mais je pense plutôt qu'il s'agit de deux systèmes mal configurés qui entrent en concurrence.
systemctl stop NetworkManager.service
systemctl: command not found
Ok, ta distrib n'utilise pas encore systemd. Ça fera un troll de moins. :-)
ifconfig eth0 192.168.1.200 netmask 255.255.255.0 up
pas de rep
Le fait de ne pas avoir de réponse est bon signe avec une commande DOS ou UNIX. Ça indique qu'elle s'est exécutée correctement, sauf si on attend d'elle qu'elle nous renvoie justement quelque chose à l'écran ou qu'elle est conçue (ou configurée) pour rester muette.
Il est possible que ta box y mette de la mauvaise volonté également.
En principe, ça se dépanne assez facilement mais par forum interposé, en étant débutant et sans avoir accès au Net, ça risque effectivement de prendre du temps. Il faut savoir également que, comme tous les systèmes, ton Ubuntu fait l'objet de mises à jour qui sont téléchargées d'un coup après son installation initiale et qui, en principe, résolvent toutes ces coquilles.
Si tu réinstalles, je te conseille de le faire en laissant ton câble Ethernet branché dès le départ. Le système te demandera peut-être de configurer le réseau juste avant de lancer l'installation mais il sera alors en mesure d'aller directement chercher ce qui lui manque.
Dernière question : tu es dans quelle région ? Peut-être existe-t-il un LUG à proximité de chez toi avec des gens prêts à t'aider physiquement.
Ne vaut-il mieux pas que je désinstalle et réinstalle ubuntu sur mon ordinateur? J'ai peut être fait une fausse manip, qu'en pensez vous?
Non, c'est quelque chose qu'on ne fait pour ainsi dire jamais avec des distributions de Linux. Ce n'est pas de chance mais normalement, ça se dépanne. :-)
Avec ifconfig -a, il voit bien mon câble ethernet…
En fait, NetworkManager n'est pas le sous-système réseau proprement dit mais une application de plus haut niveau qui se charge de faire toutes les manips que l'on fait ici à la main quand ça commence à devenir compliqué.
« ifconfig » est la commande historique de gestion des interfaces elles-mêmes sur tous les UNIX ou presque depuis longtemps. L'option « -a » veut dire « all » et lui demande de présenter toutes les interfaces connues ou déclarées auprès du noyau… même si elles ne sont pas montées. Quand tu tapes « ifconfig » seul, la commande t'affiche uniquement les interfaces actives (« up »).
Cette commande te permet donc d'attribuer une (voire plusieurs) adresses à ton interface réseau, de l'activer ou la désactiver, de lui attribuer un masque réseau, et de faire quelques réglages qui lui sont propres. Pour avoir une connexion pleinement active quand on monte tout à la main, il faut également ajouter une passerelle par défaut vers ta box avec « route » et ajouter les DNS dans « /etc/resolv.conf ». Tu peux également utiliser la commande « ip » qui essaie de tout rassembler sous une même banière.
NetworkManager est très appréciable quand il marche correctement mais quand il pose problème, il devient pénible parce qu'il a tendance à redescendre les cartes réseau qu'on a monté soi-même s'il ne les connaît pas. :-( Il peut donc être utile de l'éteindre complètement le temps de faire tes manipulations. Je ne sais pas si ta distribution est déjà sous SystemD ou pas encore (il me semble que non) mais tu peux essayer ceci (en root)
Ces commandes servent à faire à la main ce que tu configures en principe dans les panneaux de NetworkManager qui, lui ensuite, se chargent de passer les mêmes appels directement au système. Tu peux refaire le ping
ping -c4 linuxfr.org
Si ça passe, essaie de voir si tu peux surfer avec ton navigateur.
Évidemment, tout ce que l'on a saisi ci-dessus disparaîtra au redémarrage. D'où l'importance d'avoir un gestionnaire qui fonctionne.
Merci encore de votre aide, je commence vraiment a désespérer et sans vous je ne serais plus quoi faire..
Et bravo à toi pour ta persévérance ! En principe, les Ubuntu et autres distribs sont au point côté réseau depuis longtemps. Ça fait bien longtemps que je n'avais plus rencontré ce genre de bug technique lors d'une installation initiale. Ça vaut le coup de ne pas abandonner maintenant car lorsque ce sera réglé, ton système restera stable pendant de nombreuses années. Tu auras l'occasion de bien en profiter, au point de ne plus pouvoir t'en passer. :-)
Posté par Obsidian .
En réponse au message Pas internet sur Linux.
Évalué à 3.
Dernière modification le 13 décembre 2014 à 00:41.
À ce stade, il peut même directement ouvrir son navigateur Internet puisque les temps de réponse des pings sont cohérents et que les DNS fonctionnent correctement (l'adresse de DLFP est la bonne). Par contre, il est possible que le Network Manager lui fasse croire qu'il est toujours en mode hors-connexion. Si c'est le cas, il faudra peut-être décocher l'option « Fichiers → Travailler en mode hors connexion » (en faisant apparaître le menu en appuyant une fois sur Alt si nécessaire).
Désolé, mais quand je vois ça :
Linux est un système formidable […]
Ça me donne des boutons… Linux n’est pas un « système » c’est un noyau.
. « système » ne veut pas forcément dire « système d'exploitation ». C'est un terme générique ;
. Quand je dis Linux, on peut se référer soit au seul noyau, soit à GNU/Linux et à tout ce qui l'entoure. Ça va sans dire ;
. Le mot « système d'exploitation » PEUT désigner le seul noyau, dès lors que c'est un logiciel en place qui permet à un logiciel d'exploiter les ressources de sa machine. C'est d'ailleurs comme ça que Linux est défini dans le README à la racine de ses sources :
WHAT IS LINUX?
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
It has all the features you would expect in a modern fully-fledged Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.
C'est un peu comme les termes « unité centrale ». En principe, ça désigne le CPU. C'est par extension qu'on a utilisé la même terminologie pour désigner la machine qui le contient et sur laquelle viennent se brancher les périphériques.
Alors, oui Linux est un noyau, et oui il est formidable parce qu’il intègre énormément de choses.
Le noyau de Windows (NT de souvenir) n’en fait pas autant, mais c’est totalement normal.
La différence se situe au niveau de l’architecture kernel, Linux est monolityque et le kernel de Windows est un hybrid-kernel modulaire.
Ce n'est pas la question. Que les pilotes soient intégrés à l'intérieur ou à l'extérieur du noyau importe peu. La question était « pourquoi mon matériel pose-t-il des problèmes alors qu'il fonctionne sans problème sous Windows ? ». La réponse est : « parce que quelqu'un a fait le même travail en amont ».
Et en ce sens, il est remarquable de voir comment le noyau Linux est capable de prendre directement et silencieusement en charge le matériel qu'il connaît. Je suis toujours impressionné par le pouvoir de détection des Knoppix, par exemple, qui recommence le tout à chaque session.
Avant toute chose j'ai relevé un message d'erreur il me semble. Il y est écrit exactement:
12.617750 nouveau E[ DEVICE] [0000:04:00.0] unknown chipset, 0x118010a2
12.617785 nouveau E[ DRM] failed to create 0x80000060, -22
Rien d'alarmant de ce côté. « nouveau » est le pilote libre visant à prendre en charge les cartes graphiques nVidia pour ceux qui ne veulent pas installer le pilote propriétaire. Comme il n'est probablement pas à jour concernant ton matériel, il faudra peut-être le remplacer par celui du fabricant. Ce n'est pas difficile, mais on verra ça quand ta connexion fonctionnera.
De plus en ce qui concerne ma "version" je ne sais pas trop, en gros quand je lance linux il est écrit:
GNU GRUB version 2.02~beta2-9ubuntu1
Tu travailles donc avec une Ubuntu. Tu peux essayer « lsb_release -a » pour avoir plus de détails
ifconfig -a
eth0 Link encap:Ethernet HWaddr 78:24:af:ab:78:86
…
lo Link encap:Local Loopback
…
Bonne nouvelle : ton système voit ton port Ethernet (c'est le contraire qui aurait été surprenant) ;
Mauvaise nouvelle : le même système n'a absolument pas reconnu ton adaptateur WiFi. C'est un problème fréquent quand le matériel est trop récent, ou quand il nécessite un firmware non libre.
Linux est un système formidable dans le sens où il prend directement en charge la plupart du matériel existant sans que l'utilisateur ait à faire quoi que ce soit. Windows en fait beaucoup moins mais comme les gens ne font pratiquement jamais d'installation initiale (le système est presque toujours pré-installé) et parce que le distributeur fait l'effort d'installer lui-même les pilotes sur les machines qu'il veut vendre, on a l'impression que ça marche tout seul.
Branche ton câble Ethernet et essaie la commande de Marc Quinton plus haut : « sudo dhclient eth0 » pour réclamer manuellement l'attribution d'une adresse à ta machine (ce qui devrait en principe fonctionner tout seul). Ensuite, lance ton navigateur et vois si tu peux aller sur le web.
Ce sont ces lignes-là qui nous intéressent. La première est celle de ta puce Wifi, la seconde celle du port Ethernet. Ce qui est intéressant, c'est le couple vendor:product en bout de ligne qui identifie de manière déterministe (enfin, en principe, parce qu'on trouve parfois des clones) l'interface reliée à ton port PCI.
Il faudrait voir chez Broadcom s'ils fournissent des pilotes officiels mais une brève recherche nous montre que quelqu'un a eu le même problème que toi avec une Ubuntu 13.01 :
La commande proposée dans la réponse installe le package « bcmwl-kernel-source ». Tu auras peut-être besoin de « linux-firmware-nonfree » s'il n'est pas automatiquement inclus dans les dépendances.
Et également « ifconfig -a » pour voir s'il reconnaît la carte réseau sans l'avoir configurée.
Peut-on également avoir le résultat de la commande « lspci -nn » et celle de « lsmod » pour voir si ton noyau a bien réussi à charger les pilotes concernés ?
Non, mais il faut connaître le mot de passe de B (su c'est pour switch user) et la commande c'est plutôt
« su » veut dire initialement « Substitute User », ce qui est effectivement une définition plus correcte (« se substituer à… »).
« Switch User » a plutôt l'air d'être une définition « rétro-inventée » à partir d'une commande déjà en place depuis longtemps, et qu'a retrouvé un peu partout au point de trouver maintenant les deux définitions dans les différents manuels pour mettre tout le monde d'accord. Mais « switch » n'est pas réellement exact puisqu'il n'y a ni permutation d'utilisateur, ni changement de session.
Je crois que c'est, au contraire, une bonne idée. Après tout, le nom de l'utilisateur est la moitié des informations nécessaires pour accéder un à système.
Bien que je ne changerai pas, de moi-même, le nom de l'uid0 sur une machine qui ne contiens que des informations de faible importance, je pense que je serais fortement tenté de le faire si je sais que la machine en question contiens des informations de haute sécurité. Après… j'avoue, je n'y connais rien en sécurité, je ne suis pas admin.
En fait, ça se fait effectivement parfois, mais c'est de la même façon que tu peux remonter /dev ou /proc sur les répertoires de ton choix, et mettre les bibliothèques où tu veux pourvu que tu règles correctement LD_LIBRARY_PATH et ld.so.conf sous Linux. C'est possible mais c'est aller au devant d'ennuis pour rien.
Certes, changer le nom du root te permet éventuellement de te protéger contre les scripts automatiques les plus simples, mais la liste des utilisateurs est visible à travers /etc/passwd, même si c'est en lecture seule. Donc, c'est une protection qui ne sert à rien contre les attaques en local. Contre les attaques à distance, le plus sage est tout simplement d'interdire à root de se connecter directement.
D'autre part, on ne fait pas de sécurité par l'obscurantisme. Si tu as besoin de t'y connecter à distance pour pouvoir faire du dépannage éventuel, le mieux (à mon avis) est d'utiliser un certificat en plus d'une liaison chiffrée et d'un mot de passe fort.
Justement, c'est cela qui m'intrigue. Linux est considéré comme un fils spirituel d'UNIX (mais moins que les BSD je crois?)
Il y a eu originellement un grand schisme dans le monde UNIX à l'époque où c'était encore le système de quelques grandes compagnies et d'universités prestigieuses, en substance celle de Berkeley. Tu peux visiter SysV sur Wikipédia et la frise d'É. Lévénez qu'on ne présente plus, mais quoi qu'il en soit, deux grandes tendances se sont dessinées : les UNIX basés sur SysV, plus ou moins issu de la lignée originale, et ceux basés sur les travaux de BSD. Il s'est passé en gros la même chose qu'avec Red Hat et Debian dans le monde Linux, ce qui avait donné lieu à une réflexion dans la communauté pour éviter que Linux se scinde lui-même en deux projets.
J'évite d'aller plus loin parce que le fil va se transformer en troll systemd (on est vendredi mais il est encore un peu tôt).
on constate une vérification hard-codée dans mount?
En fait, il y a une raison à cela : si tu écris « ls -l $(which mount) », tu t'apercevras que mount a le bit setuid. Ça veut donc dire qu'il sera automatiquement lancé en root, même si l'utilisateur ne fait rien de spécial. Ceci lui permet d'offrir la possibilité à l'utilisateur de monter ce qui se trouve déjà dans /etc/fstab, si les lignes concernées possèdent l'attribut « user », ou « users » (le premier impose que ce soit l'utilisateur ayant monté le volume qui le démonte, tandis que le second permet à n'importe qui de le faire). Mais évidemment, lancé en tant que root par un admin ou par un utilisateur ordinaire sous son identité, le programme sera donc root dans les deux cas. C'est donc à lui qu'il appartient de vérifier sous quelle identité il a été réellement lancé pour savoir s'il doit honorer n'importe quelle requête ou s'il doit se cantonner à ce qui est déjà dans /etc/fstab. C'est aussi ce qui va introduire les notions d'identité réelle et d'identité effective (getuid() et geteuid()).
Le problème est le même avec la commande « passwd ». Si elle est officiellement lancée en tant que root, elle peut modifier le mot de passe de n'importe qui (utile pour l'administrateur) mais si elle est lancée en tant qu'utilisateur ordinaire, elle ne devra modifier que le mot de passe de cet utilisateur en particulier. Il en reste que, dans les deux cas, le processus doit être privilégié pour modifier le fichier principal des mots de passe.
et le doute m'entraîne à poser des questions, pour comprendre pourquoi les choses que je crois être des erreurs en sont vraiment.
C'est exactement ce qu'il faut faire, mais attention au biais de conformité.
Tu serais donc encore plus horrifié que moi en voyans la façon de… hum… travailler…. de la boîte pour laquelle je bosse. Déjà, on demande à des dev d'être admin de serveurs critiques, en plus, on nous demande de déployer des cibles de test sur les serveurs de prod, et, je te le promets à ma grande honte, il n'y à qu'un seul compte sur ces machines: root. J'y suis depuis presque un an, j'ai toujours râlé et gueulé contre cet état de fait (je ne te parle même pas de l'architecture… ou du manque de… des… logiciels… pissés!
Si tout le monde a le mot de passe root de la machine, profites-en pour te créer un compte à toi, le mettre dans les sudoers, et travailler normalement même si tous tes collègues utilisent tes serveurs comme des bacs à sable. Au moins sur les machines de développement (les prods ont peut-être un master à respecter mais étant donné la ligne directrice, j'en doute un peu).
Si tu as besoin d'une autre analogie : tu peux comparer ça à l'userland et au mode noyau : tout ce qui est dans le noyau (en ring 0 sur Intel) peut écrire partout et accéder aux ports d'entrées-sorties. Tout ce qui est en user (en ring 3), en revanche, ne peut agir que dans son espace et ne peut acquérir des privilèges qu'en faisant un appel système, qui va le faire entrer dans le noyau et exécuter uniquement ce qui s'y trouve déjà.
« root » est le même principe appliqué aux utilisateurs. Le root est omnipotent et lève par nature toutes les restrictions du système. Tous les autres utilisateurs, eux, sont les mêmes a priori. Comme, sous Unix, tout est censé être fichier, on est théoriquement en mesure de donner des droits d'accès à n'importe quoi. C'est aussi pour cela que ça devient pénible quand certains projets (notamment des environnements de bureau) s'éloignent de ce principe pour réinventer ensuite leurs propres méthodes de contrôle.
Le principal danger à travailler sous root ne vient pas des attaques potentielles de l'extérieur : ça lève tous les garde-fous légitimement mis en place. Par exemple, quand on formate une partition et que l'on monte un volume sous Unix, le système a le bon goût de réserver cinq pourcents (par défaut) de cet espace et de le considérer comme plein quand un utilisateur atteint cette limite. Si c'est la partition système qui est concernée (probable s'il n'y en a qu'une seule sur le disque), ça empêche ton système de démarrer correctement, comme partout. Mais le fait d'avoir cette réserve te permet justement de te connecter en root (en mode dégradé ou mono-utilisateur), de faire le ménage et de relancer le système proprement. Si tu travailles tout le temps en root, tu blindes ta partition et le seul moyen de s'en sortir est d'utiliser un LiveCD pour aller le réparer depuis l'extérieur. Et ceci n'est qu'un exemple. Voir également ce journal et les commentaires qu'il a suscité : http://linuxfr.org/users/faya/journaux/contre-la-phobie-du-root
erk… ceci dit, j'essaie de réduire la cata… utiliser un CVS et un bugtracker, monter un serveur avec des VM pour le test, et je n'ose imaginer faire un buildbot avec tests unitaires, j'ai déjà assez de résistance au changement comme ça!)
Aujourd'hui, tu as le droit d'utiliser git ou mercurial. CVS est vénérable et le plus répandu parce que le plus ancien (probablement). Il a inspiré tous les suivants mais désormais, il a le droit à une retraite bien méritée. Je n'aime pas beaucoup le changement non plus mais essayer l'un ou l'autre pendant un après-midi suffit à être convaincu et à ne plus revenir en arrière.
Je crois que c'est cette partie là que je ne comprend pas, en fait. Je pense qu'il me faut étudier les effets exacts de ce flag, il n'y à qu'ainsi que je pourrais comprendre pourquoi on teste si le lanceur à l'uid 0 dans mount pour certaines conditions.
« ls -l » permet de voir instantanément les neufs bits des droits d'accès habituels des fichiers : « rwxrwxrwx », soit les droits en lecture, écriture et exécution (ou parcours s'il s'agit d'un répertoire) pour, respectivement, le propriétaire du fichier, les membres du groupe auquel appartient ce fichier, et tous les autres.
Mais il en existe trois autres : setuid, setgid, et le sticky bit. Les deux premiers sont nommés ainsi relativement à la fonction qu'ils semblent appeler. Concrètement, si un utilisateur quel qu'il soit a le droit d'exécuter le fichier (binaire exécutable) et le fait, alors si le bit setuid est posé, le programme sera lancé avec l'UID du propriétaire du fichier et pas celui de la personne qui l'a lancé. Même chose avec setgid() : le processus appartiendra au groupe dans lequel est placé le fichier. Il est important de noter que ce propriétaire (et donc l'UID effective du processus) n'est pas forcément root, mais c'est utilisé à cette fin dans neuf cas sur dix.
Le sticky bit, lui, quand il est placé sur un répertoire, sert à permettre aux utilisateurs de modifier un fichier qui n'est pas le leur si ils en le droit (« w ») mais leur interdire de le supprimer, réservant ce droit au propriétaire du fichier ou du répertoire qui le contient.
Au fait, j'ai soudain un doute en te relisant : On rappelle que l'utilisateur ayant l'ID 0 est le root, tout simplement.
Dans l'absolu, on pourrait aussi changer le nom de login du root même si c'est une mauvaise idée, mais l'utilisateur ayant l'identifiant nul reste la définition du super-utilisateur, à tous les niveaux du noyau.
Il est utile de rappeler également que — en principe — la philosophie UNIX est « tout est fichier ». Il y a donc d'un côté le super-utilisateur qui a tous les pouvoirs (Dieu sur Terre) et, de l'autre, les utilisateurs ordinaires. Par le biais des bits setuid dans un certaine mesure et surtout des différents droits d'accès, notamment sur les fichiers spéciaux, on peut gérer les privilèges accordés aux différents utilisateurs de façon simple et unifiée, sans que cela fasse l'objet de niveaux prédéterminés comme on en trouvait sous Windows à l'époque (avec les powerusers, admin, etc.).
Ça veut dire que d'une part, tout ce qui peut tourner dans l'espace d'un processus sans avoir la possibilité de perturber ceux des autres utilisateurs peut s'exécuter en mode non privilégié. Autrement, il faudra avoir le droit de le faire.
Ça signifie aussi que « root » n'est pas un utilisateur ordinaire : même l'administrateur d'un site ou celui de sa propre machine ne travaille jamais en root. Il utilise un compte ordinaire auquel il accorde quelques droits pour le travail au quotidien et ne passe root que ponctuellement lorsque c'est nécessaire.
Le bit setuid est également un bon moyen de faire passer automatiquement un processus en root (ou autre identité) tout en limitant ce privilège à l'exécutable de la commande lancée : ça va être le cas de passwd, par exemple, puisque c'est nécessaire pour pouvoir modifier le fichier central lorsque l'on change de mot de passe. C'est également le cas de mount, qui permet à tout un chacun de monter à loisir ce qui se trouve déjà dans /etc/fstab, pourvu que la ligne concernée soit munie de l'attribut "user" ou "users".
cela ne changerait pas le fait que l'accès au montage serait sécurisé (seuls les utilisateurs appartenant au groupe disk peuvent monter un périphérique)
Ce n'est pas une constante gravée dans le marbre : un simple chgrp/chmod suffit à changer cet état de fait et il faut vérfier cela pour chacun des périphériques spéciaux, un par un.
avec en plus le bénéfice pour un utilisateur d'être capable de monter ses iso (chose que l'on peut faire en utilisant fuse, je sais) car étant propriétaire de ses fichiers sans devoir passer par su ou sudo (que je considère comme un workaround, personnellement)
N'oublie pas qu'UNIX est un système multi-utilisateurs : « mount » ne fait pas simplement qu'accéder au périphérique concerné, il construit également un morceau du système de fichiers entier avec. Un fois une partition montée, elle est visible par tout le système et par tous les utilisateurs, même si sa consultation peut être restreinte par des droits d'accès.
Imagine que quelqu'un ait la bonne idée de faire un mount sur /usr/bin (ce qui est parfaitement légal) par exemple : ceci masquerait la quasi-totalité des binaires du système, qui deviendrait automatiquement inutilisable, à moins d'avoir pensé à garder « umount » sur une partie visible du FS.
Tu as l'air d'avoir suffisamment d'expérience pour franchir les premières difficultés qui se présenteront à toi et profiter pleinement du système, mais c'est effectivement beaucoup plus confortable si quelqu'un te prend la main pour te guider.
Il faut aussi savoir qu'en 23 ans, le système a beaucoup évolué. Originellement, c'est un unixoïde mais les nombreux frameworks qu'il fait fonctionner ont suivi une voie propre. Si possible, essaie de te faire présenter les bases du système et la prise en main de la ligne de commande, puis de voir ce qui est proposé individuellement par les différents projets (par exemple, GNOME). Si tu te lances seul, tu risques de te cantonner à ce qui est visible à travers l'interface graphique et rater ce qui fait l'intérêt du système dans sa majeure partie.
Impossible de t'en dire plus avec si peu d'informations mais la meilleure chose à faire dans un premier temps est d'ouvrir un terminal et d'essayer de le lancer depuis là. Au moins, tu auras des messages d'erreur.
Elle a quand même eu le méridien de Paris pendant un temps, ce qui en faisait la moitié du centre du monde si l'on considère que les longitudes s'étendent de -180° à +180°… :-)
Soit ta partition système est vide parce que l'installation s'est mal déroulée, soit le kernel essaie de booter sur la mauvaise partition (possible si l'installation utilise des UUID pour les reconnaître et que ceux-ci ont changé entre temps). « init ».
Un kernel panic, c'est une situation dans laquelle le noyau lui-même ne peut plus continuer à travailler. C'est un peu l'équivalent d'un écran bleu sous Windows, à ceci près que le message d'erreur est généralement plus explicite. Ça peut être dû à des choses sérieuses comme des défaillances matérielles mais en l'occurrence, ça veut juste dire qu'une fois qu'il a démarré complètement, il ne trouve pas le programme « init », qui est en fait le premier des programmes fonctionnant normalement et qui est chargé de lancer proprement tout le reste ensuite.
Appuie sur « e » au démarrage à la place d'entrée en face de « Ubuntu with linux 3.13.0-24-generic » pour voir quelles sont les options passées au noyau. Il faudra peut-être ensuite démarrer avec un LiveCD pour voir si l'installation sur le disque a vraiment échoué ou s'il s'agit d'autre chose.
Il se peut enfin que tu aies des problèmes avec l'UEFI mais je n'ai aucune expérience de ce côté.
Et surtout, quel âge a le portable ? Il a fallu que je recoure à « forcepae » pour pouvoir prolonger la vie d'un Presario X1000 en lui installant une Lubuntu remplaçant une Hardy Heron hors d'âge.
ça revient au même ? La commande cp est plus sexy !
Oui, puisque les fichiers spéciaux /dev/sdxx (et tous les périphériques disque en général) servent à présenter le contenu du disque entier, secteur par secteur et du premier au dernier, comme une grosse image linéaire. C'est l'interface privilégiée entre le kernel, le hardware du disque et l'utilisateur. Ça fonctionne aussi en faisant « cat image.iso > /dev/sd… » mais c'est un UUOC.
Jusqu'à une époque récente, les 512 premiers octets de l'image d'un noyau fraîchement compilé contenaient systématiquement une amorce (au moins sur PC), tant et si bien qu'un « cat bzImage > /dev/fd0 » donnait automatiquement une disquette bootable. En fait, seul le noyau démarrait mais on le configurait pour qu'il embraye de lui-même vers le disque approprié. C'était pratique avec les BIOS un peu capricieux qui ne voulaient pas démarrer sur les disques secondaires, et lorsque l'on écrasait accidentellement le MBR (par exemple, à la suite de l'installation d'un autre système) avant que les LiveCD se généralisent.
« dd » signifie « Disk Dub », et sert donc littéralement à dupliquer les disques. Formellement, il va faire la même chose qu'un « cp », à savoir écrire le contenu d'un fichier dans un autre, mais avec des options supplémentaires comme la possibilité de spécifier des offsets, d'indiquer où il en est, et éventuellement de continuer son travail même s'il rencontre des secteurs défectueux. Mais sa principale raison d'être reste la possibilité de faire des accès calibrés, c'est-à-dire de taille fixe et alignés sur des adresses multiples d'un certain facteur, en principe la taille d'un secteur ou d'un bloc. Normalement, c'est la couche « périphérique bloc » du noyau qui s'occupe de ce travail, mais ça devenait nécessaire quand on utilisait des raw devices.
# v6
Posté par Obsidian . En réponse au journal Mon réseau à moi. Évalué à 6.
« M.L.J.4. » … Qu'est-ce ça peut bien vouloir dire ?
# Port Parallèle ?
Posté par Obsidian . En réponse au message Mise en place d'un watchdog par microcontroleur . Évalué à 2.
Je vais peut-être dire une ânerie mais tes PC ne sont-ils pas encore équipés d'un port parallèle ? S'il y a du RS/232 (port série) alors le port imprimante est en général disponible. Le RS/232 a été le premier à disparaître pour promouvoir l'USB dans le courant des années 2000 mais l'autre avait eu un sursis.
Dans l'affirmative, alors le port parallèle est à la fois ce qu'il y a de plus simple à programmer, de plus simple à bricoler et pas loin d'être le plus robuste également. Tous les geeks des années 1980 à 2010 qui ont fait un peu d'électronique se sont un jour amusés à brancher une LED dessus et à essayer de la piloter.
[^] # Re: De pire en pire; problème sur problème
Posté par Obsidian . En réponse au message Pas internet sur Linux. Évalué à 2.
Hmm. Les messages privés ne sont plus disponibles. :-(
Merci d'avoir laissé une adresse. L'e-mail est parti. :-)
[^] # Re: De pire en pire; problème sur problème
Posté par Obsidian . En réponse au message Pas internet sur Linux. Évalué à 2.
Je n'ose y croire. J'habite Évry également. Je t'envoie un message privé.
[^] # Re: De pire en pire; problème sur problème
Posté par Obsidian . En réponse au message Pas internet sur Linux. Évalué à 2.
C'est vraiment étrange. Comme dit juste au dessus, on ne peut pas écarter totalement la défectuosité de ton câble même si, comme tu l'as indiqué, ça fonctionne sous Windows. Mais je pense plutôt qu'il s'agit de deux systèmes mal configurés qui entrent en concurrence.
Ok, ta distrib n'utilise pas encore systemd. Ça fera un troll de moins. :-)
Le fait de ne pas avoir de réponse est bon signe avec une commande DOS ou UNIX. Ça indique qu'elle s'est exécutée correctement, sauf si on attend d'elle qu'elle nous renvoie justement quelque chose à l'écran ou qu'elle est conçue (ou configurée) pour rester muette.
Il est possible que ta box y mette de la mauvaise volonté également.
En principe, ça se dépanne assez facilement mais par forum interposé, en étant débutant et sans avoir accès au Net, ça risque effectivement de prendre du temps. Il faut savoir également que, comme tous les systèmes, ton Ubuntu fait l'objet de mises à jour qui sont téléchargées d'un coup après son installation initiale et qui, en principe, résolvent toutes ces coquilles.
Si tu réinstalles, je te conseille de le faire en laissant ton câble Ethernet branché dès le départ. Le système te demandera peut-être de configurer le réseau juste avant de lancer l'installation mais il sera alors en mesure d'aller directement chercher ce qui lui manque.
Dernière question : tu es dans quelle région ? Peut-être existe-t-il un LUG à proximité de chez toi avec des gens prêts à t'aider physiquement.
[^] # Re: De pire en pire; problème sur problème
Posté par Obsidian . En réponse au message Pas internet sur Linux. Évalué à 3.
Non, c'est quelque chose qu'on ne fait pour ainsi dire jamais avec des distributions de Linux. Ce n'est pas de chance mais normalement, ça se dépanne. :-)
En fait, NetworkManager n'est pas le sous-système réseau proprement dit mais une application de plus haut niveau qui se charge de faire toutes les manips que l'on fait ici à la main quand ça commence à devenir compliqué.
« ifconfig » est la commande historique de gestion des interfaces elles-mêmes sur tous les UNIX ou presque depuis longtemps. L'option « -a » veut dire « all » et lui demande de présenter toutes les interfaces connues ou déclarées auprès du noyau… même si elles ne sont pas montées. Quand tu tapes « ifconfig » seul, la commande t'affiche uniquement les interfaces actives (« up »).
Cette commande te permet donc d'attribuer une (voire plusieurs) adresses à ton interface réseau, de l'activer ou la désactiver, de lui attribuer un masque réseau, et de faire quelques réglages qui lui sont propres. Pour avoir une connexion pleinement active quand on monte tout à la main, il faut également ajouter une passerelle par défaut vers ta box avec « route » et ajouter les DNS dans « /etc/resolv.conf ». Tu peux également utiliser la commande « ip » qui essaie de tout rassembler sous une même banière.
NetworkManager est très appréciable quand il marche correctement mais quand il pose problème, il devient pénible parce qu'il a tendance à redescendre les cartes réseau qu'on a monté soi-même s'il ne les connaît pas. :-( Il peut donc être utile de l'éteindre complètement le temps de faire tes manipulations. Je ne sais pas si ta distribution est déjà sous SystemD ou pas encore (il me semble que non) mais tu peux essayer ceci (en root)
Ces commandes servent à faire à la main ce que tu configures en principe dans les panneaux de NetworkManager qui, lui ensuite, se chargent de passer les mêmes appels directement au système. Tu peux refaire le ping
Si ça passe, essaie de voir si tu peux surfer avec ton navigateur.
Évidemment, tout ce que l'on a saisi ci-dessus disparaîtra au redémarrage. D'où l'importance d'avoir un gestionnaire qui fonctionne.
Et bravo à toi pour ta persévérance ! En principe, les Ubuntu et autres distribs sont au point côté réseau depuis longtemps. Ça fait bien longtemps que je n'avais plus rencontré ce genre de bug technique lors d'une installation initiale. Ça vaut le coup de ne pas abandonner maintenant car lorsque ce sera réglé, ton système restera stable pendant de nombreuses années. Tu auras l'occasion de bien en profiter, au point de ne plus pouvoir t'en passer. :-)
[^] # Re: des pistes
Posté par Obsidian . En réponse au message Pas internet sur Linux. Évalué à 3. Dernière modification le 13 décembre 2014 à 00:41.
À ce stade, il peut même directement ouvrir son navigateur Internet puisque les temps de réponse des pings sont cohérents et que les DNS fonctionnent correctement (l'adresse de DLFP est la bonne). Par contre, il est possible que le Network Manager lui fasse croire qu'il est toujours en mode hors-connexion. Si c'est le cas, il faudra peut-être décocher l'option « Fichiers → Travailler en mode hors connexion » (en faisant apparaître le menu en appuyant une fois sur Alt si nécessaire).
[^] # Re: Static IP
Posté par Obsidian . En réponse au message Pas internet sur Linux. Évalué à 1.
. « système » ne veut pas forcément dire « système d'exploitation ». C'est un terme générique ;
. Quand je dis Linux, on peut se référer soit au seul noyau, soit à GNU/Linux et à tout ce qui l'entoure. Ça va sans dire ;
. Le mot « système d'exploitation » PEUT désigner le seul noyau, dès lors que c'est un logiciel en place qui permet à un logiciel d'exploiter les ressources de sa machine. C'est d'ailleurs comme ça que Linux est défini dans le README à la racine de ses sources :
WHAT IS LINUX?
Linux is a clone of the operating system Unix, written from scratch by
Linus Torvalds with assistance from a loosely-knit team of hackers across
the Net. It aims towards POSIX and Single UNIX Specification compliance.
It has all the features you would expect in a modern fully-fledged Unix,
including true multitasking, virtual memory, shared libraries, demand
loading, shared copy-on-write executables, proper memory management,
and multistack networking including IPv4 and IPv6.
C'est un peu comme les termes « unité centrale ». En principe, ça désigne le CPU. C'est par extension qu'on a utilisé la même terminologie pour désigner la machine qui le contient et sur laquelle viennent se brancher les périphériques.
Ce n'est pas la question. Que les pilotes soient intégrés à l'intérieur ou à l'extérieur du noyau importe peu. La question était « pourquoi mon matériel pose-t-il des problèmes alors qu'il fonctionne sans problème sous Windows ? ». La réponse est : « parce que quelqu'un a fait le même travail en amont ».
Et en ce sens, il est remarquable de voir comment le noyau Linux est capable de prendre directement et silencieusement en charge le matériel qu'il connaît. Je suis toujours impressionné par le pouvoir de détection des Knoppix, par exemple, qui recommence le tout à chaque session.
[^] # Re: réponse
Posté par Obsidian . En réponse au message Pas internet sur Linux. Évalué à 6.
Rien d'alarmant de ce côté. « nouveau » est le pilote libre visant à prendre en charge les cartes graphiques nVidia pour ceux qui ne veulent pas installer le pilote propriétaire. Comme il n'est probablement pas à jour concernant ton matériel, il faudra peut-être le remplacer par celui du fabricant. Ce n'est pas difficile, mais on verra ça quand ta connexion fonctionnera.
Tu travailles donc avec une Ubuntu. Tu peux essayer « lsb_release -a » pour avoir plus de détails
Bonne nouvelle : ton système voit ton port Ethernet (c'est le contraire qui aurait été surprenant) ;
Mauvaise nouvelle : le même système n'a absolument pas reconnu ton adaptateur WiFi. C'est un problème fréquent quand le matériel est trop récent, ou quand il nécessite un firmware non libre.
Linux est un système formidable dans le sens où il prend directement en charge la plupart du matériel existant sans que l'utilisateur ait à faire quoi que ce soit. Windows en fait beaucoup moins mais comme les gens ne font pratiquement jamais d'installation initiale (le système est presque toujours pré-installé) et parce que le distributeur fait l'effort d'installer lui-même les pilotes sur les machines qu'il veut vendre, on a l'impression que ça marche tout seul.
Branche ton câble Ethernet et essaie la commande de Marc Quinton plus haut : « sudo dhclient eth0 » pour réclamer manuellement l'attribution d'une adresse à ta machine (ce qui devrait en principe fonctionner tout seul). Ensuite, lance ton navigateur et vois si tu peux aller sur le web.
Ce sont ces lignes-là qui nous intéressent. La première est celle de ta puce Wifi, la seconde celle du port Ethernet. Ce qui est intéressant, c'est le couple vendor:product en bout de ligne qui identifie de manière déterministe (enfin, en principe, parce qu'on trouve parfois des clones) l'interface reliée à ton port PCI.
Il faudrait voir chez Broadcom s'ils fournissent des pilotes officiels mais une brève recherche nous montre que quelqu'un a eu le même problème que toi avec une Ubuntu 13.01 :
http://askubuntu.com/questions/334268/ubuntu-13-04-does-not-recognize-wireless-adapter-14e44365
La commande proposée dans la réponse installe le package « bcmwl-kernel-source ». Tu auras peut-être besoin de « linux-firmware-nonfree » s'il n'est pas automatiquement inclus dans les dépendances.
Voir aussi (plus vieux) : http://askubuntu.com/questions/55868/installing-broadcom-wireless-drivers
[^] # Re: reseau
Posté par Obsidian . En réponse au message Pas internet sur Linux. Évalué à 4.
Et également « ifconfig -a » pour voir s'il reconnaît la carte réseau sans l'avoir configurée.
Peut-on également avoir le résultat de la commande « lspci -nn » et celle de « lsmod » pour voir si ton noyau a bien réussi à charger les pilotes concernés ?
[^] # Re: su -c
Posté par Obsidian . En réponse au message lancer un script en tant qu'un autre utilisateur. Évalué à 4.
« su » veut dire initialement « Substitute User », ce qui est effectivement une définition plus correcte (« se substituer à… »).
« Switch User » a plutôt l'air d'être une définition « rétro-inventée » à partir d'une commande déjà en place depuis longtemps, et qu'a retrouvé un peu partout au point de trouver maintenant les deux définitions dans les différents manuels pour mettre tout le monde d'accord. Mais « switch » n'est pas réellement exact puisqu'il n'y a ni permutation d'utilisateur, ni changement de session.
[^] # Re: su -c
Posté par Obsidian . En réponse au message lancer un script en tant qu'un autre utilisateur. Évalué à 2.
Sinon, « sudo -u B script.sh », ça marche aussi, avec son propre mot de passe, à condition d'avoir les bons privilèges.
[^] # Re: Pas tout seul
Posté par Obsidian . En réponse au message Pourquoi mount nécessite-t-elle d'être lancée avec l'uid 0?. Évalué à 5.
En fait, ça se fait effectivement parfois, mais c'est de la même façon que tu peux remonter /dev ou /proc sur les répertoires de ton choix, et mettre les bibliothèques où tu veux pourvu que tu règles correctement LD_LIBRARY_PATH et ld.so.conf sous Linux. C'est possible mais c'est aller au devant d'ennuis pour rien.
Certes, changer le nom du root te permet éventuellement de te protéger contre les scripts automatiques les plus simples, mais la liste des utilisateurs est visible à travers /etc/passwd, même si c'est en lecture seule. Donc, c'est une protection qui ne sert à rien contre les attaques en local. Contre les attaques à distance, le plus sage est tout simplement d'interdire à root de se connecter directement.
D'autre part, on ne fait pas de sécurité par l'obscurantisme. Si tu as besoin de t'y connecter à distance pour pouvoir faire du dépannage éventuel, le mieux (à mon avis) est d'utiliser un certificat en plus d'une liaison chiffrée et d'un mot de passe fort.
Il y a eu originellement un grand schisme dans le monde UNIX à l'époque où c'était encore le système de quelques grandes compagnies et d'universités prestigieuses, en substance celle de Berkeley. Tu peux visiter SysV sur Wikipédia et la frise d'É. Lévénez qu'on ne présente plus, mais quoi qu'il en soit, deux grandes tendances se sont dessinées : les UNIX basés sur SysV, plus ou moins issu de la lignée originale, et ceux basés sur les travaux de BSD. Il s'est passé en gros la même chose qu'avec Red Hat et Debian dans le monde Linux, ce qui avait donné lieu à une réflexion dans la communauté pour éviter que Linux se scinde lui-même en deux projets.
J'évite d'aller plus loin parce que le fil va se transformer en troll systemd (on est vendredi mais il est encore un peu tôt).
En fait, il y a une raison à cela : si tu écris «
ls -l $(which mount)», tu t'apercevras quemounta le bit setuid. Ça veut donc dire qu'il sera automatiquement lancé en root, même si l'utilisateur ne fait rien de spécial. Ceci lui permet d'offrir la possibilité à l'utilisateur de monter ce qui se trouve déjà dans /etc/fstab, si les lignes concernées possèdent l'attribut « user », ou « users » (le premier impose que ce soit l'utilisateur ayant monté le volume qui le démonte, tandis que le second permet à n'importe qui de le faire). Mais évidemment, lancé en tant que root par un admin ou par un utilisateur ordinaire sous son identité, le programme sera donc root dans les deux cas. C'est donc à lui qu'il appartient de vérifier sous quelle identité il a été réellement lancé pour savoir s'il doit honorer n'importe quelle requête ou s'il doit se cantonner à ce qui est déjà dans /etc/fstab. C'est aussi ce qui va introduire les notions d'identité réelle et d'identité effective (getuid() et geteuid()).Le problème est le même avec la commande « passwd ». Si elle est officiellement lancée en tant que root, elle peut modifier le mot de passe de n'importe qui (utile pour l'administrateur) mais si elle est lancée en tant qu'utilisateur ordinaire, elle ne devra modifier que le mot de passe de cet utilisateur en particulier. Il en reste que, dans les deux cas, le processus doit être privilégié pour modifier le fichier principal des mots de passe.
C'est exactement ce qu'il faut faire, mais attention au biais de conformité.
Si tout le monde a le mot de passe root de la machine, profites-en pour te créer un compte à toi, le mettre dans les sudoers, et travailler normalement même si tous tes collègues utilisent tes serveurs comme des bacs à sable. Au moins sur les machines de développement (les prods ont peut-être un master à respecter mais étant donné la ligne directrice, j'en doute un peu).
Si tu as besoin d'une autre analogie : tu peux comparer ça à l'userland et au mode noyau : tout ce qui est dans le noyau (en ring 0 sur Intel) peut écrire partout et accéder aux ports d'entrées-sorties. Tout ce qui est en user (en ring 3), en revanche, ne peut agir que dans son espace et ne peut acquérir des privilèges qu'en faisant un appel système, qui va le faire entrer dans le noyau et exécuter uniquement ce qui s'y trouve déjà.
« root » est le même principe appliqué aux utilisateurs. Le root est omnipotent et lève par nature toutes les restrictions du système. Tous les autres utilisateurs, eux, sont les mêmes a priori. Comme, sous Unix, tout est censé être fichier, on est théoriquement en mesure de donner des droits d'accès à n'importe quoi. C'est aussi pour cela que ça devient pénible quand certains projets (notamment des environnements de bureau) s'éloignent de ce principe pour réinventer ensuite leurs propres méthodes de contrôle.
Le principal danger à travailler sous root ne vient pas des attaques potentielles de l'extérieur : ça lève tous les garde-fous légitimement mis en place. Par exemple, quand on formate une partition et que l'on monte un volume sous Unix, le système a le bon goût de réserver cinq pourcents (par défaut) de cet espace et de le considérer comme plein quand un utilisateur atteint cette limite. Si c'est la partition système qui est concernée (probable s'il n'y en a qu'une seule sur le disque), ça empêche ton système de démarrer correctement, comme partout. Mais le fait d'avoir cette réserve te permet justement de te connecter en root (en mode dégradé ou mono-utilisateur), de faire le ménage et de relancer le système proprement. Si tu travailles tout le temps en root, tu blindes ta partition et le seul moyen de s'en sortir est d'utiliser un LiveCD pour aller le réparer depuis l'extérieur. Et ceci n'est qu'un exemple. Voir également ce journal et les commentaires qu'il a suscité : http://linuxfr.org/users/faya/journaux/contre-la-phobie-du-root
Aujourd'hui, tu as le droit d'utiliser git ou mercurial. CVS est vénérable et le plus répandu parce que le plus ancien (probablement). Il a inspiré tous les suivants mais désormais, il a le droit à une retraite bien méritée. Je n'aime pas beaucoup le changement non plus mais essayer l'un ou l'autre pendant un après-midi suffit à être convaincu et à ne plus revenir en arrière.
« ls -l » permet de voir instantanément les neufs bits des droits d'accès habituels des fichiers : « rwxrwxrwx », soit les droits en lecture, écriture et exécution (ou parcours s'il s'agit d'un répertoire) pour, respectivement, le propriétaire du fichier, les membres du groupe auquel appartient ce fichier, et tous les autres.
Mais il en existe trois autres : setuid, setgid, et le sticky bit. Les deux premiers sont nommés ainsi relativement à la fonction qu'ils semblent appeler. Concrètement, si un utilisateur quel qu'il soit a le droit d'exécuter le fichier (binaire exécutable) et le fait, alors si le bit setuid est posé, le programme sera lancé avec l'UID du propriétaire du fichier et pas celui de la personne qui l'a lancé. Même chose avec setgid() : le processus appartiendra au groupe dans lequel est placé le fichier. Il est important de noter que ce propriétaire (et donc l'UID effective du processus) n'est pas forcément root, mais c'est utilisé à cette fin dans neuf cas sur dix.
Le sticky bit, lui, quand il est placé sur un répertoire, sert à permettre aux utilisateurs de modifier un fichier qui n'est pas le leur si ils en le droit (« w ») mais leur interdire de le supprimer, réservant ce droit au propriétaire du fichier ou du répertoire qui le contient.
[^] # Re: Pas tout seul
Posté par Obsidian . En réponse au message Pourquoi mount nécessite-t-elle d'être lancée avec l'uid 0?. Évalué à 4.
Au fait, j'ai soudain un doute en te relisant : On rappelle que l'utilisateur ayant l'ID 0 est le root, tout simplement.
Dans l'absolu, on pourrait aussi changer le nom de login du root même si c'est une mauvaise idée, mais l'utilisateur ayant l'identifiant nul reste la définition du super-utilisateur, à tous les niveaux du noyau.
Il est utile de rappeler également que — en principe — la philosophie UNIX est « tout est fichier ». Il y a donc d'un côté le super-utilisateur qui a tous les pouvoirs (Dieu sur Terre) et, de l'autre, les utilisateurs ordinaires. Par le biais des bits setuid dans un certaine mesure et surtout des différents droits d'accès, notamment sur les fichiers spéciaux, on peut gérer les privilèges accordés aux différents utilisateurs de façon simple et unifiée, sans que cela fasse l'objet de niveaux prédéterminés comme on en trouvait sous Windows à l'époque (avec les powerusers, admin, etc.).
Ça veut dire que d'une part, tout ce qui peut tourner dans l'espace d'un processus sans avoir la possibilité de perturber ceux des autres utilisateurs peut s'exécuter en mode non privilégié. Autrement, il faudra avoir le droit de le faire.
Ça signifie aussi que « root » n'est pas un utilisateur ordinaire : même l'administrateur d'un site ou celui de sa propre machine ne travaille jamais en root. Il utilise un compte ordinaire auquel il accorde quelques droits pour le travail au quotidien et ne passe root que ponctuellement lorsque c'est nécessaire.
Le bit setuid est également un bon moyen de faire passer automatiquement un processus en root (ou autre identité) tout en limitant ce privilège à l'exécutable de la commande lancée : ça va être le cas de passwd, par exemple, puisque c'est nécessaire pour pouvoir modifier le fichier central lorsque l'on change de mot de passe. C'est également le cas de mount, qui permet à tout un chacun de monter à loisir ce qui se trouve déjà dans /etc/fstab, pourvu que la ligne concernée soit munie de l'attribut "user" ou "users".
# Pas tout seul
Posté par Obsidian . En réponse au message Pourquoi mount nécessite-t-elle d'être lancée avec l'uid 0?. Évalué à 3.
Ce n'est pas une constante gravée dans le marbre : un simple chgrp/chmod suffit à changer cet état de fait et il faut vérfier cela pour chacun des périphériques spéciaux, un par un.
N'oublie pas qu'UNIX est un système multi-utilisateurs : « mount » ne fait pas simplement qu'accéder au périphérique concerné, il construit également un morceau du système de fichiers entier avec. Un fois une partition montée, elle est visible par tout le système et par tous les utilisateurs, même si sa consultation peut être restreinte par des droits d'accès.
Imagine que quelqu'un ait la bonne idée de faire un mount sur /usr/bin (ce qui est parfaitement légal) par exemple : ceci masquerait la quasi-totalité des binaires du système, qui deviendrait automatiquement inutilisable, à moins d'avoir pensé à garder « umount » sur une partie visible du FS.
[^] # Re: En ligne de commande
Posté par Obsidian . En réponse au message Identification port USB. Évalué à 2.
Tu peux aussi essayer « lsusb » et voir s'il apparaît dans la liste.
[^] # Re: prendre les choses dans l'ordre
Posté par Obsidian . En réponse au message Comment installer Linux sur mon ordinateur? . Évalué à 3.
Tu peux également essayer le Linux Distribution Chooser pour te faire une première idée :
http://www.zegeniestudios.net/ldc/index.php?lang=fr
Tu as l'air d'avoir suffisamment d'expérience pour franchir les premières difficultés qui se présenteront à toi et profiter pleinement du système, mais c'est effectivement beaucoup plus confortable si quelqu'un te prend la main pour te guider.
Il faut aussi savoir qu'en 23 ans, le système a beaucoup évolué. Originellement, c'est un unixoïde mais les nombreux frameworks qu'il fait fonctionner ont suivi une voie propre. Si possible, essaie de te faire présenter les bases du système et la prise en main de la ligne de commande, puis de voir ce qui est proposé individuellement par les différents projets (par exemple, GNOME). Si tu te lances seul, tu risques de te cantonner à ce qui est visible à travers l'interface graphique et rater ce qui fait l'intérêt du système dans sa majeure partie.
[^] # Re: arg bash
Posté par Obsidian . En réponse au journal Edition simple de fichiers TS sous Linux. Évalué à 3.
Pour l'affection ? :-)
# Le terminal
Posté par Obsidian . En réponse au message chromium s'ouvre plus. Évalué à 3.
Bonjour,
Impossible de t'en dire plus avec si peu d'informations mais la meilleure chose à faire dans un premier temps est d'ouvrir un terminal et d'essayer de le lancer depuis là. Au moins, tu auras des messages d'erreur.
[^] # Re: erreur de site ?
Posté par Obsidian . En réponse au message Re-compilation carte PCI Altera ADP6x01. Évalué à 2.
Il a surtout ajouté : « Je sais que c'est une carte qui doit être configurée sous linux. Est-ce que quelqu'un pourrait m'aider s'il vous plait. »
La question est : est-ce réellement le cas ? mais il faudra creuser un peu pour le savoir quand même…
[^] # Re: Moi qui croyais suivre un site en français...
Posté par Obsidian . En réponse au journal Lennart Poettering trouve la communauté Linux désagréable. Évalué à 5.
Elle a quand même eu le méridien de Paris pendant un temps, ce qui en faisait la moitié du centre du monde si l'on considère que les longitudes s'étendent de -180° à +180°… :-)
[^] # Re: suite pb kernel
Posté par Obsidian . En réponse au message pb "Kernel panic". Évalué à 2.
Réponse courte :
Soit ta partition système est vide parce que l'installation s'est mal déroulée, soit le kernel essaie de booter sur la mauvaise partition (possible si l'installation utilise des UUID pour les reconnaître et que ceux-ci ont changé entre temps). « init ».
Un kernel panic, c'est une situation dans laquelle le noyau lui-même ne peut plus continuer à travailler. C'est un peu l'équivalent d'un écran bleu sous Windows, à ceci près que le message d'erreur est généralement plus explicite. Ça peut être dû à des choses sérieuses comme des défaillances matérielles mais en l'occurrence, ça veut juste dire qu'une fois qu'il a démarré complètement, il ne trouve pas le programme « init », qui est en fait le premier des programmes fonctionnant normalement et qui est chargé de lancer proprement tout le reste ensuite.
Appuie sur « e » au démarrage à la place d'entrée en face de « Ubuntu with linux 3.13.0-24-generic » pour voir quelles sont les options passées au noyau. Il faudra peut-être ensuite démarrer avec un LiveCD pour voir si l'installation sur le disque a vraiment échoué ou s'il s'agit d'autre chose.
Il se peut enfin que tu aies des problèmes avec l'UEFI mais je n'ai aucune expérience de ce côté.
[^] # Re: suite pb kernel
Posté par Obsidian . En réponse au message pb "Kernel panic". Évalué à 2.
Et surtout, quel âge a le portable ? Il a fallu que je recoure à « forcepae » pour pouvoir prolonger la vie d'un Presario X1000 en lui installant une Lubuntu remplaçant une Hardy Heron hors d'âge.
[^] # Re: Clé bootable
Posté par Obsidian . En réponse au message comment formater une clé usb en ext2?. Évalué à 8.
Oui, puisque les fichiers spéciaux /dev/sdxx (et tous les périphériques disque en général) servent à présenter le contenu du disque entier, secteur par secteur et du premier au dernier, comme une grosse image linéaire. C'est l'interface privilégiée entre le kernel, le hardware du disque et l'utilisateur. Ça fonctionne aussi en faisant « cat image.iso > /dev/sd… » mais c'est un UUOC.
Jusqu'à une époque récente, les 512 premiers octets de l'image d'un noyau fraîchement compilé contenaient systématiquement une amorce (au moins sur PC), tant et si bien qu'un « cat bzImage > /dev/fd0 » donnait automatiquement une disquette bootable. En fait, seul le noyau démarrait mais on le configurait pour qu'il embraye de lui-même vers le disque approprié. C'était pratique avec les BIOS un peu capricieux qui ne voulaient pas démarrer sur les disques secondaires, et lorsque l'on écrasait accidentellement le MBR (par exemple, à la suite de l'installation d'un autre système) avant que les LiveCD se généralisent.
« dd » signifie « Disk Dub », et sert donc littéralement à dupliquer les disques. Formellement, il va faire la même chose qu'un « cp », à savoir écrire le contenu d'un fichier dans un autre, mais avec des options supplémentaires comme la possibilité de spécifier des offsets, d'indiquer où il en est, et éventuellement de continuer son travail même s'il rencontre des secteurs défectueux. Mais sa principale raison d'être reste la possibilité de faire des accès calibrés, c'est-à-dire de taille fixe et alignés sur des adresses multiples d'un certain facteur, en principe la taille d'un secteur ou d'un bloc. Normalement, c'est la couche « périphérique bloc » du noyau qui s'occupe de ce travail, mais ça devenait nécessaire quand on utilisait des raw devices.
[^] # Re: Fourmi au rapport (de bug) !
Posté par Obsidian . En réponse au message le partitionnement de mon ordinateur. Évalué à 6.
« … mais il en occupe 3000 fois l'espace disque. »