Malheureusement, le site de ta distribution manque cruellement de documentation (et le lien pour installer redirige vers une page qui se contente d'afficher de la pub…) donc ça va être compliqué de taper dans le mille :)
Si ta distribution te permets, lors de l'installation, d'avoir un accès à une ligne de commande, essaies de lancer la commande efibootmgr avec l'utilisateur root.
Si le système te réponds, comme je le soupçonne fortement: «EFI variables are not supported on this system.» ou pire, s'il ne connaît même pas la commande, c'est simple: le démarrage UEFI n'est peut-être pas supporté out-of-the-box.
Un UEFI (successeur du BIOS) ne détecteras que les OS enregistrés correctement. S'il n'en trouve pas, il n'indiqueras aucun «disque» de démarrage.
Du coup, je suis quasi sûr que ton UEFI démarre en mode «moderne» (le mode «legacy» permettant la compatibilité avec les anciens mécanismes d'amorçage), donc nécessite une partition de démarrage en FATxx (souvent du FAT32, mais d'autres FAT marchent aussi) préparée pour un démarrage par UEFI, que ta distribution ne fait peut-être pas correctement.
La doc pour installer syslinux du wiki d'archilinux contiens une section qui indique ce qu'un démarrage UEFI va chercher par défaut, quand on n'a pas encore eu la possibilité de démarrer en mode UEFI:
When booted in BIOS mode, efibootmgr will not be able to set EFI nvram entry for /EFI/syslinux/syslinux.efi. To work around, place resources at the default EFI location: esp/EFI/syslinux/* -> esp/EFI/BOOT/* and esp/EFI/syslinux/syslinux.efi -> esp/EFI/BOOT/bootx64.efi
Donc, si je résume un peu tout en français, pour préparer un système qui sera visible par un UEFI (sans secure boot, je précise, je ne connais pas du tout ce qu'il faut pour secure boot) il te faut:
un disque utilisant une table de partition de type GPT (toutes les distributions ne font pas nécessairement ça par défaut!);
une partition formatée en FAT32;
mettre le drapeau «ESP» sur cette partition;
qu'il y ait dans cette partition un fichier à l'emplacement suivant: EFI/BOOT/ (*) nommé bootx64.efi qui contiens le programme d'amorçage de ton système.
Normalement, à partir de là, tu devrais voir ton système dans le BIOS.
Si, comme supposé par d'autres, c'est un problème de 64 bits vs 32 bits, tu dois probablement utiliser un fichier nommé bootx32.efi (j'en ai vus dans ma debian, même si je n'y ai jamais eu recours). Au pire, rien n'empêche d'avoir les 2 côte à côte.
Dernier point: personnellement, j'utilise syslinux, mais il en existe d'autres qui ont moins d'inconvénients (qui requièrent moins de manipulations lors de mise à jour de noyau, en fait).
Ceci dit, l'avantage de syslinux, c'est sa simplicité de configuration, et comme il ne fait rien automatiquement, il est pratique pour diagnostiquer.
*: à partir du point de montage de la-dite partition, c'est à dire si elle se situe dans /dev/sdc10, il te faut par exemple faire en root: mount /dev/sdc10 /tmp; mkdir -p /tmp/EFI/BOOT et mettre un fichier bootx64.efi ici.
Oui, mais la 3ème (hd0,msdos5) est une partition étendue, donc, une «fausse» partition (de 1 à 4, ce sont les partitions primaires d'un disque formaté en ms-dos, la 5 c'est l'éventuelle partition étendue, au-dessus ce sont les partitions virtuelles. Bon, c'est juste ce que j'ai déduit de tous les disques que j'ai manipulés, je peux me tromper et je n'ai pas de source officielle sur le sujet). Ce qui me surprend, c'est que justement, il n'y ait pas de partition au-dessus.
Ta machine à déjà démarré en dual boot?
Tu as fait des mises à jour sur un des systèmes entre le moment ou il démarrait et celui ou il ne démarre plus?
Ensuite, une suggestion:
Si tes données utilisateur (ton /home) sont situées sur une partition dédiée, je te suggère fortement de les récupérer à l'aide d'une clé USB ou d'un CD de récupération avant toute manipulation. Même chose pour celles que tu utilises sous Windows (reste à savoir comment tu as fait tes partitions, mais ça, il n'y a que toi qui le sait).
Si tu ne peux récupérer tes données de cette façon et qu'elles sont importantes à tes yeux, alors fait une copie complète du disque dur, afin de pouvoir travailler dessus par la suite une fois ton système à nouveau fonctionnel.
Ensuite, une fois ceci fait, je te suggère de réinstaller grub directement, ça sera probablement le plus simple pour avoir un système à nouveau fonctionnel, en espérant que je ne me trompe pas sur mon analyse qui suit).
Si jamais ce n'est pas possible, je te suggère, si tu as les moyens de réinstaller ton windows, de changer le format de ta table de partition en GPT (qui permettra notamment d'installer grub sans que cet outil ne dissimule son obésité dans des secteurs théoriquement non accessibles), puis de réinstaller windows et enfin de réinstaller Mint. Et de réserver 2 partitions pour tes données utilisateur, cette fois-ci: une pour linux, et une pour windows, sachant que depuis linux tu seras capable d'utiliser une partition de type NTFS (le format de windows), l'inverse n'étant pas nécessairement vrai (il existe des outils pour accéder à du ext3 sous windows, mais la dernière fois que j'ai essayé, c'était pas terrible du tout).
Pour ce qui est de ce que je suppose de ta situation:
Pour vous donner de l'info, j'ai tapé la commande ls. Cela a donné :
À vue de nez, on dirait que la partition secondaire numéro 6, celle qui contiens probablement la partition système de ton linux Mint, à été détruite (en tout cas, grub ne semble pas la trouver). Il faudrait idéalement vérifier de l'extérieur (en démarrant un système complet sur un CD ou une clé usb) si c'est bien le cas.
Ce qui m'intrigue, c'est que normalement grub devrait toujours te proposer de sélectionner un système avant ça. Du coup, je me demande si ce n'est pas un peu plus grave.
Vu que tu utilises une table de partition de type MS-DOS, et que grub utilise une astuce sur ce format pour stocker ses données de démarrage, je pense que j'irai creuser du côté d'une table de partition endommagée: ça expliquerait qu'une partition ait disparu et que tu n'arrives pas sur le menu de démarrage standard de grub, ce qui me fait penser fort à une mise à jour qui se serait mal passée.
Ça ne te seras peut-être pas très utile, mais sait-on jamais…
Chez moi, il faut double-tabuler en cas d'ambiguité et c'est pas spécialement lent (il me sort quasi-instantanément Display all 10244 possibilities? (y or n)).
Chez moi, il faut double tabuler à chaque fois que l'on veut afficher une liste avec bash, par exemple, avec zsh:
mkdir /tmp/foobar /tmp/foorab
cd /tmo/foo<tab>
affiche la liste. Avec bash, il faut le faire 2 fois. Donc, quand on veut d'une part compléter jusqu'à l'ambiguïté, et d'autre part afficher la liste, il faut tabuler un total de 3 fois avec bash, 2 fois avez zsh (chez moi, et avec mes config, qui est custo uniquement pour zsh). Notes que je me dis que ça serait sympa que, dans le cas ou /tmp/foo n'existe pas, une seule tabulation affiche la liste. Ça serait probablement le plus intéressant, et aucun des deux ne semble le faire ici.
À mon avis tu as un truc cassé dans ta config.
Pas impossible, sauf que je ne modifie plus ma config bash depuis que j'utilise zsh.
J'aime bien zsh, mais de là à prétendre que la complétion intelligente de bash est incomparablement moins bonne, c'est peut-être pousser le bouchon un peu loin quand même.
J'ai pourtant lourdement insisté que c'est le comportement ici, que j'ai, et que ça peut varier en fonction de systèmes.
Notamment, j'utilise Debian stable avec certains paquets rétroportés, le tout sur un système minimaliste.
Ce que ça implique:
déjà, si tu utilises un autre distro, tu as probablement des versions des softs plus récents;
ensuite, il n'est pas impossible que Debian ait des patchs qui affectent l'auto-complétion;
il est probable que certains paquets ne soient pas installés (le paquet bash-autocompletion l'a été quand j'ai testé, ceci dit) soit parce que pas listés dans les dépendances (depends, recommends ou suggests… j'ai déjà eu le cas sur des depends sur certains paquets debian) soit parce que je les considère inutiles dans mon usage (plus probable).
Ce que j'ai dit, c'est qu'à l'époque ou j'ai lâché bash, sur les systèmes que j'utilisais c'était clairement le cas. J'ai aussi mentionné le fait que depuis au moins un comportement de bash s'est amélioré de ce point de vue.
Si jamais je voulais mentionner un shell interactif de mauvaise qualité, ce n'est pas bash que je citerais, d'autant qu'il est largement suffisant pour la plupart des usages et plus simple à configurer que zsh.
A supposer que Ubuntu puisse se passer de Debian, pourquoi le fait il sans le faire vraiment? :))
Parce que tous les forks ne sont pas agressifs, et qu'il est plus simple de maintenir un fork qui reste le plus proche de l'upstream possible tout en gardant les spécificités sous forme de patchs, ce que le système de paquets de Debian permets relativement aisément.
À noter que c'est ce que fait Devuan également :)
A lire quelques lignes au hasard, il semble que ma réponse soit un bon résumé :)
Mais je pense que pour répondre à la question «Ubuntu est-elle un fork de Debian?» il faut déjà définir ce qu'est un fork. Pour moi, un fork, c'est partir d'une base (de code source, de configurations, de documentation, peu importe) déjà existante et la modifier pour aller dans une direction qui n'est pas celle voulue par la base.
Ensuite, un fork peut devenir totalement décorellé de l'original, ou rester proche, re-fusionner ou contribuer, ce n'est pas important.
Du coup, selon ma définition, Ubuntu est totalement un fork de Debian, mais ce n'est pas un fork qui s'est fait dans le conflit, contrairement à Devuan. Iceweasel était un fork de Firefox, également, même si le code restait très proche de l'original et si je suis persuadé qu'ils ont reversé des patchs acceptés par l'upstream.
Chez moi (j'insiste, chez moi), bash ne semble pas pouvoir auto-compléter efficacement un script ./configure, zsh si. Idem pour make et cmake. Je n'ai jamais essayé ninja, donc…
Sur les manpages également, il me semblait qu'il ne le faisait pas, mais apparemment ça a été ajouté. Par contre, dieux que c'est lent, et il faut double-tabuler…
Ceci dit, il me semble qu'il y avait des trucs que je préférais sur l'auto-complétion de bash comparés à celle de zsh, mais je suis incapable de m'en souvenir.
Et pour finir, ce genre de trucs doit sûrement être vachement modifié sur certaines distros, notamment Debian, vu que je doute que les chemins d'install soient uniformes en fonction des manpages et de la source des données (par exemples, j'en ai quelques unes dans /usr/local/… en plus de celles du système). Donc, ça peut être très différent chez toi ou d'autres.
En quoi?
À mon sens, ils s'en passent plutôt pas mal pour bien des briques du système, et depuis quelques temps déjà. À minima, ils ont changé le système d'init par défaut par upstart bien avant que Debian ne considère même de changer ça, ils ont eu leur propre DE installé par défaut, et il me semble me souvenir de problèmes de symboles dans quelques libs, d'une époque ou je m'étais amusé à installer un paquet Ubuntu sur ma Debian (me demandez pas pourquoi, je m'en souviens plus… probablement un ppa?).
Les attributs des fichiers et dossiers sont des fonctionnalités qui dépendent du système de fichier employé, et les droits d'accès font partie de ces attributs.
Donc, avant qu'on ne puisse te répondre, il faudrait nous donner cette information, par exemple en nous montrant la sortie de la commande df -T.
M'est avis que le format utilisé sera l'un des format de la famille FAT, qui ne supporte pas les droits d'accès, et il est donc normal de ne pas pouvoir les modifier, à mon sens.
Ceci dit, bash a aussi une complétion intelligente, et elle est activée
Exact, mais franchement, elle n'a rien a voir avec celle de zsh niveau puissance… Ceci dit, celle de bash à le mérite de ne pas avoir besoin de relancer le shell pour prendre en compte l'installation d'un logiciel, contrairement à celle de zsh (ou du moins, je n'ai pas réussi à configurer zsh pour que ça fonctionne).
et n’ont souvent pas les moyens d’imposer leurs solutions,
Encore faudrait-il qu'elles aient envie d'imposer leurs solutions ET que ces solutions soient supérieures à l'existant. Une piste: ce n'est le cas ni de mir, ni de upstart.
Les autres sont libres… de profiter des contributions des employés de Red Hat
C'est ça, lesautres sont libres, d'utiliser ou non tout ou partie des contributions de RH. Et pourquoi pas, d'ailleurs?
Pour l'info, j'utilise à titre personnel les 2 distributions que pour lesquelles j'ai mis des liens. Je n'utilise aucun soft qui ait besoin de PA. Les systèmes bootent très bien (dans le cas de void, la vitesse de démarrage est d'ailleurs bluffante) et le son marche à la perfection.
Pour en finir avec ce post: je remercie Lennart Poettering d'avoir fait systemd. Parce que sans ça, je n'aurais jamais étudié le sujet des systèmes d'initialisation, je serais resté avec l'infâme et ingérable sysVinit version Debian. Grâce à systemd, j'ai découvert runit (entres autres outils).
Ouaaaaaa, Red Hat a menacé tout le monde tu crois ? Les débats pour les adoptions ont rarement étaient longues en fait… Et rappel, PulseAudio a été développé sur une base d'Ubuntu avant que Fedora ne l'adopte. Donc bon le complot de Red Hat pour s'imposer on va arrêter ici.
D'autant que toutes les distributions n'ont pas adopté ces outils, pas plus qu'ils ne sont imposés sur toutes les distributions qui les installent par défaut.
En tout cas, personnellement, je n'ai jamais eu besoin de PA, et ne l'installe donc pas. Je préfère runit à systemd, et ma Debian marche très bien sans systemd.
Par contre, c'est vrai, je n'utilise pas gnome et n'ai pas de périphérique bluetooth (j'ai cru lire que slackware installe PA parce que bluez ont droppé la compat alsa… mais bon, je m'en fout un peu, j'ai pas besoin de bluez moi).
Cela n'avançait pas assez vite et trop de problèmes restaient en suspend.
Je viens de faire une recherche pour trouver le fichier ~/.bashrc qui n'est pas à sa place :
[root@slackbox:/] # find -name bashrc
find: "./home/lea/.gvfs": Permission non accordée
Il est dit ici plusieurs choses:
il existe un dossier .gvfs pour lequel tu n'as pas le droit d'exécution, qui servent en fait à «ouvrir» les dossiers. La commande find ne peux donc pas aller voir dedans.
la commande find ne trouve pas le fichier bashrc, elle ne dit ici rien au sujet d'un fichier .bashrc. Le nom des différent.
Si tu veux trouver le fichier .bashrc qui se trouve dans un dossier précis et pas dans les dossiers enfant, il faut utiliser la commande suivante: find $MON_DOSSIER -maxdepth 1 -name "$MON_FICHIER". $MON_DOSSIER est facultative, en cas d'absence, c'est le dossier courant qui est utilisé. $MON_FICHIER est le nom exact et complet du fichier, ce nom pouvant comporter des joker: '?' signifie n'importe quel caractère, '*' signifie n'importe quel nombre de n'importe quels caractères.
Sinon, tu peux aussi ne pas utiliser find, et au pire créer ce fichier directement s'il n'existe pas: c'est un script d'initialisation, tout le monde peut créer ou modifier le sien à sa guise.
Et vu que j'utilise toujours le terminal en root, si je mets un alias dans un fichier qui n'appartient pas à root, je me demande si ça va fonctionner…
Ici aussi, plusieurs choses à dire:
je te conseille chaudement de limiter l'usage de root au maximum. Quitte à utiliser la commande su pour changer d'identité ponctuellement quand tu en as besoin (d'autres préféreraient sudo qui a quelques avantages, notamment le fait de pouvoir limiter les commandes utilisées à un jeu précis, mais bon sur un système mono-utilisateur je ne suis pas persuadé que ce soit utile).
si tu veux configurer au niveau du système, les fichiers de configuration à modifier appartiennent à root, affecteront la totalité des utilisateurs du système, et se situent dans /etc.
si tu veux modifier uniquement la configuration utilisée par l'utilisateur root, ce sont les «mêmes» fichiers de configuration que pour n'importe quel utilisateur: "$HOME/$FILE", ou "~$USER/$FILE". Dans le cas du fichier .bashrc, ce sera donc ~root/.bashrc qui sera probablement résolu par le shell comme étant /root/.bashrc. Je dis probablement, parce que je pense que c'est standard, mais ça peut se modifier: l'information du dossier $HOME de chaque utilisateur peut se trouver dans le fichier /etc/passwd, au 6ème champ (les ':' sont des séparateurs de champs). Ce fichier contiens la configuration du programme login pour chaque utilisateur, les mots de passe étant normallement chiffrés dans le fichier /etc/shadow.
Enfin, si ton but est de faire un alias système, tu peux aussi regarder le contenu de la variable $PATH.
Chez moi, ça donne ceci: /home/freem/.bin:/home/freem/.bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games. Quand le shell cherche à trouver une commande (qui ne soit pas «builtin», c'est à dire implémentée dans le shell lui-même), il cherche d'abord dans le 1er dossier, puis le 2nd, jusqu'a ce qu'il trouve ou qu'il n'y ait plus d'entrées. Donc, dans mon cas, je peux mettre mes scripts utilisateur dans ~freem/.bin, et mes scripts systèmes dans /usr/local/bin, /usr/local servant à mettre les binaires qui ne sont pas installés par le système de paquet de ma distribution.
Bon, ça fait déjà un petit pavé, mais un certain nombre de mes explications peuvent varier d'une distribution à l'autre, c'est pour ça que j'ai essayé d'être exhaustif… ceci dit, je serais surpris de n'avoir rien oublié.
Dans mon cas, j'utilise Debian, qui modifie un certain nombre de choses et dont la philosophie est à priori très différente de celle de slackware (qu'il faudrait que j'essaie, un jour, d'ailleurs).
C'est clair qu'il faut le configurer le bouzin, mais normalement, en 1er lancement, tu as un outil qui te pose les questions pour configurer l'auto-complétion déjà.
Le reste, il faut fouiller la doc, mais perso je reste à un usage relativement simple, tout ce que je demande, c'est une complétion propre, un prompt qui change de couleur selon la machine sur laquelle je suis et l'utilisateur (rouge et rouge quand je suis root sur une machine distante notamment, histoire de me rappeler de finir ma session ASAP et sans faire de connerie) et de pas mettre le boxon dans mon $HOME.
Du coup, c'est assez trivial, mais impossible avec bash (sauf pour les couleurs, bien sûr).
Le fait est que, pour config bash correctement, c'est pareil mais en pire, ne serait-ce que parce que la manpage est d'une qualité bien différente.
Le problème avec zsh, c'est que la touche tab est usée plus vite, vu qu'elle sert réellement à quelque chose… enfin, le fait que l'on n'en aie besoin qu'une fois pour traverser une arborescence complète compense un peu le problème (ça me fait penser, il faudrait que je voie pourquoi ma complétion pour les pages de manuel est cassée… alors que je m'en servait encore il y a quelques semaines pour avoir la doc de la lib standard de C++. Peut-être un problème lié à stdman?).
Plus sérieusement, je trouve que d'une part zsh à une bien meilleure auto-complétion, mais je le trouve aussi plus réactif (je n'ai pas fait de mesures, c'est juste un ressenti) et cerise sur le gâteau, il ne fout pas tous ses fichiers en vrac dans le $HOME! Enfin, si, mais on peut le configurer pour qu'il soit propre, contrairement à bash.
[^] # Re: Vidéo d'installation openelec sur levono flex 10
Posté par freem . En réponse au message Linux sur Lenovo Flex 10. Évalué à 3.
Malheureusement, le site de ta distribution manque cruellement de documentation (et le lien pour installer redirige vers une page qui se contente d'afficher de la pub…) donc ça va être compliqué de taper dans le mille :)
Si ta distribution te permets, lors de l'installation, d'avoir un accès à une ligne de commande, essaies de lancer la commande
efibootmgravec l'utilisateur root.Si le système te réponds, comme je le soupçonne fortement: «EFI variables are not supported on this system.» ou pire, s'il ne connaît même pas la commande, c'est simple: le démarrage UEFI n'est peut-être pas supporté out-of-the-box.
Un UEFI (successeur du BIOS) ne détecteras que les OS enregistrés correctement. S'il n'en trouve pas, il n'indiqueras aucun «disque» de démarrage.
Du coup, je suis quasi sûr que ton UEFI démarre en mode «moderne» (le mode «legacy» permettant la compatibilité avec les anciens mécanismes d'amorçage), donc nécessite une partition de démarrage en FATxx (souvent du FAT32, mais d'autres FAT marchent aussi) préparée pour un démarrage par UEFI, que ta distribution ne fait peut-être pas correctement.
La doc pour installer syslinux du wiki d'archilinux contiens une section qui indique ce qu'un démarrage UEFI va chercher par défaut, quand on n'a pas encore eu la possibilité de démarrer en mode UEFI:
Donc, si je résume un peu tout en français, pour préparer un système qui sera visible par un UEFI (sans secure boot, je précise, je ne connais pas du tout ce qu'il faut pour secure boot) il te faut:
EFI/BOOT/(*) nommébootx64.efiqui contiens le programme d'amorçage de ton système.Normalement, à partir de là, tu devrais voir ton système dans le BIOS.
Si, comme supposé par d'autres, c'est un problème de 64 bits vs 32 bits, tu dois probablement utiliser un fichier nommé
bootx32.efi(j'en ai vus dans ma debian, même si je n'y ai jamais eu recours). Au pire, rien n'empêche d'avoir les 2 côte à côte.Dernier point: personnellement, j'utilise syslinux, mais il en existe d'autres qui ont moins d'inconvénients (qui requièrent moins de manipulations lors de mise à jour de noyau, en fait).
Ceci dit, l'avantage de syslinux, c'est sa simplicité de configuration, et comme il ne fait rien automatiquement, il est pratique pour diagnostiquer.
*: à partir du point de montage de la-dite partition, c'est à dire si elle se situe dans
/dev/sdc10, il te faut par exemple faire en root:mount /dev/sdc10 /tmp; mkdir -p /tmp/EFI/BOOTet mettre un fichier bootx64.efi ici.[^] # Re: GRUB
Posté par freem . En réponse au message Plus de boot. grub rescue ?. Évalué à 2.
Oui, mais la 3ème (hd0,msdos5) est une partition étendue, donc, une «fausse» partition (de 1 à 4, ce sont les partitions primaires d'un disque formaté en ms-dos, la 5 c'est l'éventuelle partition étendue, au-dessus ce sont les partitions virtuelles. Bon, c'est juste ce que j'ai déduit de tous les disques que j'ai manipulés, je peux me tromper et je n'ai pas de source officielle sur le sujet). Ce qui me surprend, c'est que justement, il n'y ait pas de partition au-dessus.
# Ordre d'amorçage?
Posté par freem . En réponse au message Linux sur Lenovo Flex 10. Évalué à 2.
Peut-être un problème lié à l'ordre d'amorçage (sur quel périphérique chercher l'OS)?
Sinon, tu démarres en mode BIOS ou UEFI?
# Soudain, mais après quels évènements?
Posté par freem . En réponse au message Plus de boot. grub rescue ?. Évalué à 2.
Déjà, quelques questions:
Ta machine à déjà démarré en dual boot?
Tu as fait des mises à jour sur un des systèmes entre le moment ou il démarrait et celui ou il ne démarre plus?
Ensuite, une suggestion:
Si tes données utilisateur (ton /home) sont situées sur une partition dédiée, je te suggère fortement de les récupérer à l'aide d'une clé USB ou d'un CD de récupération avant toute manipulation. Même chose pour celles que tu utilises sous Windows (reste à savoir comment tu as fait tes partitions, mais ça, il n'y a que toi qui le sait).
Si tu ne peux récupérer tes données de cette façon et qu'elles sont importantes à tes yeux, alors fait une copie complète du disque dur, afin de pouvoir travailler dessus par la suite une fois ton système à nouveau fonctionnel.
Ensuite, une fois ceci fait, je te suggère de réinstaller grub directement, ça sera probablement le plus simple pour avoir un système à nouveau fonctionnel, en espérant que je ne me trompe pas sur mon analyse qui suit).
Si jamais ce n'est pas possible, je te suggère, si tu as les moyens de réinstaller ton windows, de changer le format de ta table de partition en GPT (qui permettra notamment d'installer grub sans que cet outil ne dissimule son obésité dans des secteurs théoriquement non accessibles), puis de réinstaller windows et enfin de réinstaller Mint. Et de réserver 2 partitions pour tes données utilisateur, cette fois-ci: une pour linux, et une pour windows, sachant que depuis linux tu seras capable d'utiliser une partition de type NTFS (le format de windows), l'inverse n'étant pas nécessairement vrai (il existe des outils pour accéder à du ext3 sous windows, mais la dernière fois que j'ai essayé, c'était pas terrible du tout).
Pour ce qui est de ce que je suppose de ta situation:
À vue de nez, on dirait que la partition secondaire numéro 6, celle qui contiens probablement la partition système de ton linux Mint, à été détruite (en tout cas, grub ne semble pas la trouver). Il faudrait idéalement vérifier de l'extérieur (en démarrant un système complet sur un CD ou une clé usb) si c'est bien le cas.
Ce qui m'intrigue, c'est que normalement grub devrait toujours te proposer de sélectionner un système avant ça. Du coup, je me demande si ce n'est pas un peu plus grave.
Vu que tu utilises une table de partition de type MS-DOS, et que grub utilise une astuce sur ce format pour stocker ses données de démarrage, je pense que j'irai creuser du côté d'une table de partition endommagée: ça expliquerait qu'une partition ait disparu et que tu n'arrives pas sur le menu de démarrage standard de grub, ce qui me fait penser fort à une mise à jour qui se serait mal passée.
Ça ne te seras peut-être pas très utile, mais sait-on jamais…
[^] # Re: bash parce bash
Posté par freem . En réponse au sondage Dans quel shell tapez-vous vos lignes de commandes ?. Évalué à 3.
Pas faux.
# oubli très important
Posté par freem . En réponse au journal [bookmark] terminaux et protection contre la copie. Évalué à 3.
Je suis tombé sur cette information en lisant ceci: https://lwn.net/Articles/749992/
[^] # Re: bash parce bash
Posté par freem . En réponse au sondage Dans quel shell tapez-vous vos lignes de commandes ?. Évalué à 2. Dernière modification le 17 avril 2018 à 10:40.
[edit]
Zut, bug de connexion qui à causé un double post… à supprimer?
[^] # Re: bash parce bash
Posté par freem . En réponse au sondage Dans quel shell tapez-vous vos lignes de commandes ?. Évalué à 2.
Chez moi, il faut double tabuler à chaque fois que l'on veut afficher une liste avec bash, par exemple, avec zsh:
affiche la liste. Avec bash, il faut le faire 2 fois. Donc, quand on veut d'une part compléter jusqu'à l'ambiguïté, et d'autre part afficher la liste, il faut tabuler un total de 3 fois avec bash, 2 fois avez zsh (chez moi, et avec mes config, qui est custo uniquement pour zsh). Notes que je me dis que ça serait sympa que, dans le cas ou /tmp/foo n'existe pas, une seule tabulation affiche la liste. Ça serait probablement le plus intéressant, et aucun des deux ne semble le faire ici.
Pas impossible, sauf que je ne modifie plus ma config bash depuis que j'utilise zsh.
J'ai pourtant lourdement insisté que c'est le comportement ici, que j'ai, et que ça peut varier en fonction de systèmes.
Notamment, j'utilise Debian stable avec certains paquets rétroportés, le tout sur un système minimaliste.
Ce que ça implique:
Ce que j'ai dit, c'est qu'à l'époque ou j'ai lâché bash, sur les systèmes que j'utilisais c'était clairement le cas. J'ai aussi mentionné le fait que depuis au moins un comportement de bash s'est amélioré de ce point de vue.
Si jamais je voulais mentionner un shell interactif de mauvaise qualité, ce n'est pas bash que je citerais, d'autant qu'il est largement suffisant pour la plupart des usages et plus simple à configurer que zsh.
[^] # Re: Finalement adoptée
Posté par freem . En réponse à la dépêche Sortie de Fedora 28 bêta. Évalué à 3.
Parce que tous les forks ne sont pas agressifs, et qu'il est plus simple de maintenir un fork qui reste le plus proche de l'upstream possible tout en gardant les spécificités sous forme de patchs, ce que le système de paquets de Debian permets relativement aisément.
À noter que c'est ce que fait Devuan également :)
A lire quelques lignes au hasard, il semble que ma réponse soit un bon résumé :)
Mais je pense que pour répondre à la question «Ubuntu est-elle un fork de Debian?» il faut déjà définir ce qu'est un fork. Pour moi, un fork, c'est partir d'une base (de code source, de configurations, de documentation, peu importe) déjà existante et la modifier pour aller dans une direction qui n'est pas celle voulue par la base.
Ensuite, un fork peut devenir totalement décorellé de l'original, ou rester proche, re-fusionner ou contribuer, ce n'est pas important.
Du coup, selon ma définition, Ubuntu est totalement un fork de Debian, mais ce n'est pas un fork qui s'est fait dans le conflit, contrairement à Devuan. Iceweasel était un fork de Firefox, également, même si le code restait très proche de l'original et si je suis persuadé qu'ils ont reversé des patchs acceptés par l'upstream.
[^] # Re: Xkcd
Posté par freem . En réponse au sondage Dans quel shell tapez-vous vos lignes de commandes ?. Évalué à 2. Dernière modification le 16 avril 2018 à 14:25.
T'abuses, t'aurais pu mettre le lien qui va bien quand même.
À moins que ça ne soit un usage détourné du SOI pour faire auto-compléter par un autre de linuxfr?
[^] # Re: Dash
Posté par freem . En réponse au sondage Dans quel shell tapez-vous vos lignes de commandes ?. Évalué à 2.
Non, puisque ce ne sont pas des terminaux :)
[^] # Re: bash parce bash
Posté par freem . En réponse au sondage Dans quel shell tapez-vous vos lignes de commandes ?. Évalué à 2. Dernière modification le 16 avril 2018 à 14:20.
Chez moi (j'insiste, chez moi), bash ne semble pas pouvoir auto-compléter efficacement un script
./configure, zsh si. Idem pour make et cmake. Je n'ai jamais essayé ninja, donc…Sur les manpages également, il me semblait qu'il ne le faisait pas, mais apparemment ça a été ajouté. Par contre, dieux que c'est lent, et il faut double-tabuler…
Ceci dit, il me semble qu'il y avait des trucs que je préférais sur l'auto-complétion de bash comparés à celle de zsh, mais je suis incapable de m'en souvenir.
Et pour finir, ce genre de trucs doit sûrement être vachement modifié sur certaines distros, notamment Debian, vu que je doute que les chemins d'install soient uniformes en fonction des manpages et de la source des données (par exemples, j'en ai quelques unes dans /usr/local/… en plus de celles du système). Donc, ça peut être très différent chez toi ou d'autres.
[^] # Re: Finalement adoptée
Posté par freem . En réponse à la dépêche Sortie de Fedora 28 bêta. Évalué à 3.
En quoi?
À mon sens, ils s'en passent plutôt pas mal pour bien des briques du système, et depuis quelques temps déjà. À minima, ils ont changé le système d'init par défaut par upstart bien avant que Debian ne considère même de changer ça, ils ont eu leur propre DE installé par défaut, et il me semble me souvenir de problèmes de symboles dans quelques libs, d'une époque ou je m'étais amusé à installer un paquet Ubuntu sur ma Debian (me demandez pas pourquoi, je m'en souviens plus… probablement un ppa?).
[^] # Re: Pourquoi t’acharner à vouloir en faire partie ?
Posté par freem . En réponse au journal Proposition révolutionnaire pour linuxfr. Évalué à 3.
Parce-qu'il le demande régulièrement, du coup, ça deviens un réflexe pour lui faire plaisir.
[^] # Re: Heu...
Posté par freem . En réponse au journal Proposition révolutionnaire pour linuxfr. Évalué à 5.
Tiens, t'as encore changé de pseudo? Me rappelle plus c'était celui d'encore avant, mais, t'en as pas marre?
# quel format de partition?
Posté par freem . En réponse au message droits et autorisations sur répertoires et fichiers extérieurs. Évalué à 4.
Les attributs des fichiers et dossiers sont des fonctionnalités qui dépendent du système de fichier employé, et les droits d'accès font partie de ces attributs.
Donc, avant qu'on ne puisse te répondre, il faudrait nous donner cette information, par exemple en nous montrant la sortie de la commande
df -T.M'est avis que le format utilisé sera l'un des format de la famille FAT, qui ne supporte pas les droits d'accès, et il est donc normal de ne pas pouvoir les modifier, à mon sens.
[^] # Re: ça va encore faire débat.
Posté par freem . En réponse au journal «Votre avis nous intéresse !» − Cette fois, je crame mon banquier…. Évalué à 3.
C'est une question de bourses?
[^] # Re: bash parce bash
Posté par freem . En réponse au sondage Dans quel shell tapez-vous vos lignes de commandes ?. Évalué à 3.
Exact, mais franchement, elle n'a rien a voir avec celle de zsh niveau puissance… Ceci dit, celle de bash à le mérite de ne pas avoir besoin de relancer le shell pour prendre en compte l'installation d'un logiciel, contrairement à celle de zsh (ou du moins, je n'ai pas réussi à configurer zsh pour que ça fonctionne).
[^] # Re: Red Hat
Posté par freem . En réponse à la dépêche Sortie de Fedora 28 bêta. Évalué à 2.
Encore faudrait-il qu'elles aient envie d'imposer leurs solutions ET que ces solutions soient supérieures à l'existant. Une piste: ce n'est le cas ni de mir, ni de upstart.
C'est ça, les autres sont libres, d'utiliser ou non tout ou partie des contributions de RH. Et pourquoi pas, d'ailleurs?
Pour l'info, j'utilise à titre personnel les 2 distributions que pour lesquelles j'ai mis des liens. Je n'utilise aucun soft qui ait besoin de PA. Les systèmes bootent très bien (dans le cas de void, la vitesse de démarrage est d'ailleurs bluffante) et le son marche à la perfection.
Pour en finir avec ce post: je remercie Lennart Poettering d'avoir fait systemd. Parce que sans ça, je n'aurais jamais étudié le sujet des systèmes d'initialisation, je serais resté avec l'infâme et ingérable sysVinit version Debian. Grâce à systemd, j'ai découvert runit (entres autres outils).
[^] # Re: Red Hat
Posté par freem . En réponse à la dépêche Sortie de Fedora 28 bêta. Évalué à 3.
D'autant que toutes les distributions n'ont pas adopté ces outils, pas plus qu'ils ne sont imposés sur toutes les distributions qui les installent par défaut.
En tout cas, personnellement, je n'ai jamais eu besoin de PA, et ne l'installe donc pas. Je préfère runit à systemd, et ma Debian marche très bien sans systemd.
Par contre, c'est vrai, je n'utilise pas gnome et n'ai pas de périphérique bluetooth (j'ai cru lire que slackware installe PA parce que bluez ont droppé la compat alsa… mais bon, je m'en fout un peu, j'ai pas besoin de bluez moi).
C'est un nouveau composant de systemd?
Bon ok, je sors…
[^] # Re: :help quoteplus
Posté par freem . En réponse au message [RESOLU] copier depuis Vim vers Writer. Évalué à 2.
Il est dit ici plusieurs choses:
findne peux donc pas aller voir dedans.findne trouve pas le fichierbashrc, elle ne dit ici rien au sujet d'un fichier.bashrc. Le nom des différent.Si tu veux trouver le fichier
.bashrcqui se trouve dans un dossier précis et pas dans les dossiers enfant, il faut utiliser la commande suivante:find $MON_DOSSIER -maxdepth 1 -name "$MON_FICHIER". $MON_DOSSIER est facultative, en cas d'absence, c'est le dossier courant qui est utilisé. $MON_FICHIER est le nom exact et complet du fichier, ce nom pouvant comporter des joker: '?' signifie n'importe quel caractère, '*' signifie n'importe quel nombre de n'importe quels caractères.Sinon, tu peux aussi ne pas utiliser find, et au pire créer ce fichier directement s'il n'existe pas: c'est un script d'initialisation, tout le monde peut créer ou modifier le sien à sa guise.
Ici aussi, plusieurs choses à dire:
supour changer d'identité ponctuellement quand tu en as besoin (d'autres préféreraientsudoqui a quelques avantages, notamment le fait de pouvoir limiter les commandes utilisées à un jeu précis, mais bon sur un système mono-utilisateur je ne suis pas persuadé que ce soit utile)..bashrc, ce sera donc~root/.bashrcqui sera probablement résolu par le shell comme étant/root/.bashrc. Je dis probablement, parce que je pense que c'est standard, mais ça peut se modifier: l'information du dossier $HOME de chaque utilisateur peut se trouver dans le fichier /etc/passwd, au 6ème champ (les ':' sont des séparateurs de champs). Ce fichier contiens la configuration du programme login pour chaque utilisateur, les mots de passe étant normallement chiffrés dans le fichier/etc/shadow.Enfin, si ton but est de faire un alias système, tu peux aussi regarder le contenu de la variable
$PATH.Chez moi, ça donne ceci:
/home/freem/.bin:/home/freem/.bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games. Quand le shell cherche à trouver une commande (qui ne soit pas «builtin», c'est à dire implémentée dans le shell lui-même), il cherche d'abord dans le 1er dossier, puis le 2nd, jusqu'a ce qu'il trouve ou qu'il n'y ait plus d'entrées. Donc, dans mon cas, je peux mettre mes scripts utilisateur dans~freem/.bin, et mes scripts systèmes dans/usr/local/bin,/usr/localservant à mettre les binaires qui ne sont pas installés par le système de paquet de ma distribution.Bon, ça fait déjà un petit pavé, mais un certain nombre de mes explications peuvent varier d'une distribution à l'autre, c'est pour ça que j'ai essayé d'être exhaustif… ceci dit, je serais surpris de n'avoir rien oublié.
Dans mon cas, j'utilise Debian, qui modifie un certain nombre de choses et dont la philosophie est à priori très différente de celle de slackware (qu'il faudrait que j'essaie, un jour, d'ailleurs).
[^] # Re: inutile de cramer le banquier
Posté par freem . En réponse au journal «Votre avis nous intéresse !» − Cette fois, je crame mon banquier…. Évalué à 3.
Il y en a d'autres que pole emploi qui font ça?
[^] # Re: Fish parce que recherche dans l'historique
Posté par freem . En réponse au sondage Dans quel shell tapez-vous vos lignes de commandes ?. Évalué à 3. Dernière modification le 12 avril 2018 à 16:17.
.
Parce que le caviar c'est meilleur que les chatons?
[^] # Re: bash parce bash
Posté par freem . En réponse au sondage Dans quel shell tapez-vous vos lignes de commandes ?. Évalué à 3.
C'est clair qu'il faut le configurer le bouzin, mais normalement, en 1er lancement, tu as un outil qui te pose les questions pour configurer l'auto-complétion déjà.
Le reste, il faut fouiller la doc, mais perso je reste à un usage relativement simple, tout ce que je demande, c'est une complétion propre, un prompt qui change de couleur selon la machine sur laquelle je suis et l'utilisateur (rouge et rouge quand je suis root sur une machine distante notamment, histoire de me rappeler de finir ma session ASAP et sans faire de connerie) et de pas mettre le boxon dans mon $HOME.
Du coup, c'est assez trivial, mais impossible avec bash (sauf pour les couleurs, bien sûr).
Le fait est que, pour config bash correctement, c'est pareil mais en pire, ne serait-ce que parce que la manpage est d'une qualité bien différente.
[^] # Re: bash parce bash
Posté par freem . En réponse au sondage Dans quel shell tapez-vous vos lignes de commandes ?. Évalué à 7.
Le problème avec zsh, c'est que la touche tab est usée plus vite, vu qu'elle sert réellement à quelque chose… enfin, le fait que l'on n'en aie besoin qu'une fois pour traverser une arborescence complète compense un peu le problème (ça me fait penser, il faudrait que je voie pourquoi ma complétion pour les pages de manuel est cassée… alors que je m'en servait encore il y a quelques semaines pour avoir la doc de la lib standard de C++. Peut-être un problème lié à stdman?).
Plus sérieusement, je trouve que d'une part zsh à une bien meilleure auto-complétion, mais je le trouve aussi plus réactif (je n'ai pas fait de mesures, c'est juste un ressenti) et cerise sur le gâteau, il ne fout pas tous ses fichiers en vrac dans le $HOME! Enfin, si, mais on peut le configurer pour qu'il soit propre, contrairement à bash.