Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Salut
empanada a écrit :Évidemment l’utilisateur dois appartenir déjà au groupe "disk" pour que ça marche, sinon, il faut l'ajouter.
Sûrement pas. Je n'en ai jamais eu besoin, et l'appartenance à ce groupe donnerait à l'utilisateur la permission de lire et écrire directement sur tous les disques et partitions, ce qui est une très mauvaise idée.
Complètement vrai. J'ai pris l'info des notes personnelles anciennes. Dans un autre fichier j'avais fait avec le group plugdev. En fait la configuration de mon ordi c'est celle corrigé dans le post antérieur: "Identity=unix-group:plugdev" pour "Action=org.freedesktop.udisks2.filesystem-mount" et pour Action=org.freedesktop.udisks2.eject-media, et je n'appartient pas au groupe disk.
Merci beaucoup de signaler ce grave erreur.
Évidemment l’utilisateur dois appartenir déjà au groupe "plugdev" pour que ça marche, sinon, il faut l'ajouter.
Après modifier les paramètres du *.pkla,
ou redémarrer (surtout si on a du ajouter l'utilisateur au groupe "plugdev", mais il devrait suffire fermer et réouvrir session)
Salut
.
et
ou rédemarrez.
Salut.
Mon soucis est toujours le même, je vois les dossiers paramétrés de mon ordi depuis mon smartphone, mais pas l’inverse, je sus toujours obligé de me service d'un cable USB
Donc le problème c'est la partie client d'Ubuntu avec la partie serveur du smartphone.
voici mon fichier smb.conf
client min protocol = NT1
server min protocol = NT1
Le protocol NT1 (SMB1) c'est fortement déconseillé dès WanaCry.
Je fonctionne avec samba depuis des années sans problème,
Depuis quelques jours et alors que je ne pense pas avoir fait queque chose, je n'arrive plus à capter mon smartphone avec mon ordinateur équipé de Xubuntu 20.04
Vous êtes sûr que votre smartphone n'a reçu aucune mise à jour ? La plus courante est l'installation automatique.
En revanche, je suis assez surpris que vous implémentiez un serveur SMB sur votre smartphone. Sur Android stock, les ports SMB par défaut sont bloqués. On peut encore tirer mais sur des ports plus hauts. Est-il rooté et/ou est-il un système non stocké (LineageOS, eOS, Fairphone...).
Il faudrait savoir aussi la configuration de le logiciel qui tire la partie serveur dans votre smartphone.
Je roule serveur SMB lecture/écriture dans les bécanes et dans les smartphones Android Samba Client vous permet ajouter les partages réseau SMB dans le gestionnaire des fichiers Android. C'est simple, et plus sûr qu'avoir un serveur SMB dans le téléphone.
Salut.
J'ai bien essayer avec l'Ubuntu original fournie et cela marche nickel,
Grace au pilote open-source Prime: http://doc.ubuntu-fr.org/prime
Ça devrait marcher sur debian...mais faire les manipulations nécessaires pour y arriver peut être une tache pas trop simple . Une petite recherche suggère que prime a besoin d'un xorg compilé et/ou patché spécifiquement : ça peut devenir en corvée....ou pas.
Quand on branche le pc sur un écran via HDMI avec nouveau sans bumblebee cela freeze et plante le pc, avec le pilote Nvidia sans bumblebee cela ne fait rien.
bumblebe , selon ce que j'ai lu, c'est pour les pilotes non-libres Nvidia, pas pour nouveau. Je suppose que t'as essayé nvidia + bumblebee.
Et aucun display port seulement une HDMI qui passe par la puce graphique Nvidia,
La station d'accueil Dell dont tu parles dans le premier message , je crois que fonctionne avec des sorties USB-C (qui peuvent donner sortie graphique). HDMI n'était même mentionné dans les readme des pilotes de la station d'accueil. Quand même à mon avis c'est pas admisible accepter que la sortie HDMI ne fonctionne pas.
merci a vous empanada pour votre aide,
Merci à vous: nous sommes içi pour apprendre. Au moins moi.
mais j'ai clairement lâcher l'affaire j' ai perdu bien trop d'heures dessus pour des résultat disons plus que médiocre avec cette dite technologie "Optimus"
Je n'aime pas donner ma langue au chat: Il semble qu'il y au moins une autre alternative à prime: vgaswitcheroo et elle semble très simple d'utiliser. Par exemple içi.
Comme dit, dommage que je n'ai aucun portable paréil pour tester.
Saluts.
Je viens de tester et malheureusement le pilote nvidia proprio coupler a bumblebee ne gère toujours pas l hdmi,
Pas moyen non plus de switch sur la puce intel du moins dans le panneau de conf nvidia, (pas disponible dans le bios non plus)
Avez-vous branché un moniteur à la sortie graphique? La sortie devrait s'activer automatiquement dès le moment qu'elle voit un moniteur connecté.
Parfois c'est nécessaire démarrer avec le moniteur déjà branché, c'est à dire, avant de démarrer la bécane.
Saluts
Supported O/S variants
=========================
This release has been prepared to be compatible with Ubuntu 20.04, 19.04 and 18.04. Other variants and editions may be compatible if they meet minimum O/S requirements, but are not supported by DisplayLink.
The Software contains binaries which work on Intel x86 platform (32 bit and 64 bit).
Supported Linux Kernel version range is from 4.15 to 5.5.
Minimum supported Xorg version is 1.16, minimum supported Mutter (Wayland) version is 3.32.
Ces conditions son très laxes, et à mon avis elles renforcent l'idée de que ce pilote peut fonctionner on presque quelconque système debian-like (ubuntu, debian, etc..) à condition qu'il ne soit pas trop vieux, et avec quelques petites modifications, surement dans presque tous les systèmes les plus courants (Suse, RedHat, Mandriva).
Saluts.
comme il s'agit d'une Freebox
J'avais lu trop rapidement et j'avais passé dessus.
Par contre, il y a plus simple que d'entrer à la main l'adresse du serveur. Il suffit d'activer l’affichage du signet "Réseau" (Édition > Préférences > Agencement). Et hop on a accès aux serveurs sur le réseau local. (C'est un drôle de choix que de le désactiver par défaut alors que l'équivalent est activé par défaut chez Nautilus ou Dolphin...)
Ce n'est pas que l'accès réseau soit "desactivé". Cette option que tu as "activé" c'est simplement ajouter la visualisation du réseau dans l'onglet gauche de pcmanfm. Mais le même endroit peut être ajouté aux signets et/ou acceder parmi "Aller -->réseau" et/ou en tapant
dans la barre d'adresses, et plus spécifiquement, smb:/// si on veux explorer le réseau samba (pareil pour FTP, ( ftp:///) , etc)
Si le protocole SMB1 est utilisé dans le serveur, l'exploration du réseau local samba devrait fonctionner bien, donc on devrait voir le serveur sous l'adresse smb:/// . Néanmoins SMB1 c'est désactivé par défaut en Windows ça fait longtemps (dès le WannaCry), et sur plusieurs *nix/Linux, aussi. Dans ce cas l'exploration des serveurs ne marche pas, et bien on utilise accès direct avec le nom/IP du serveur, bien on utilise avahi pour que les serveurs publient leurs services réseau (parmi eux samba).
Ici je disais que si le serveur n'a pas activé SMB1, le voisinage ce n'est pas disponible. Je suppose que la Freebox ait un firmware antérieur au WannaCry, alors, il a SMB1 activé encore, et c'est grâce à ça que tu peux explorer le réseau samba, mais c'est recommandable chercher une actualisation du firmware (bien que ça provoquera la perte du voisinage samba).
Par contre, à voir si c'est possible de faire un accès aussi simple pour toute la famille quand j'aurai monté un petit serveur de stockage (histoire de se Dégoogliser au maximum).
Je ne comprends pas cette phrase . Accès externe? Tu parles de substituer GoogleDrive? Avec Owncloud par exemple? Ou plutôt de simplifier l'accès aux ressources samba?
Salut
Je publierai la solution que j'ai retenue, si ça peut aider d'autres dans la même situation !
Merci à toi. Aider d'autres avec un problème pareil, partager la connaissance, c'est le but des logiciels libres, et de ce forum.
Salut
Vous avez déjà utiliser gitso ?
Non, je ne connaissais pas, mais parait pas recommandable : le développement c'est abandonnée :
This project is no longer active
Il y a peut-être mieux pour prendre la main sur une machine distante ?
Il y a pleine d'options.
Pour le protocole VNC, comme serveurs tu peux utiliser par, exemple, vino, x11vnc, vncserver... Et comme clients remmina, vinagre, xtightvncviewer...
Tu peux utiliser aussi le protocole RDP (plutôt pour combinaisons Windows serveur, Linux client, mais c'est aussi possible Linux serveur, Linux client). Si tu es intéressé , je peux te parler un peux plus, mais, comme dit, mieux pour Windows serveur , et Linux client, et il me semble que ce n'est pas ton cas.
À mon avis, x2go (protocole NoMachine NX 3) c'est la meilleure option: simple, sûr et rapide (surtout si c'est pour connecter dehors de réseau local, ou VNC galère un peu).
Pour strecth il faut utiliser les dépôts x2g0, mais en Buster c'est déjà sur les dépôts Debian donc pas besoin de rien ajouter aux sources.
Mais , il faudrait quand même avoir des détails de ce que tu veux faire: c'est pour une machine dehors le réseau local ou dans le même réseau local?
Salut
Vous feriez quoi vous ?
1er) Chercher le paquet pour debian Stretch. Que cette version ne soit pas sous les dépôts Debian officiels ne veut pas dire que le paquet ne soit pas déjà compilé pour des autres...normalement les codeurs responsables dur project.
Et c'est le cas:
How To Install R on Debian 9
Debian Packages of R Software: Supported Branches
2ème) Essayer de le compiler , mieux de manière élégante: HowTo Build a Package from Source the Smart Way
3ème) Si la compilation n'est pas possible, passer vers testing. Je ne recommande pas installer SID, sauf si on sait exactement pourquoi on le fait. Normalement , même si un paquet et seulement sur SID, installer testing et après installer le paquet de SID, marche parfaitement, sans besoin de tout mètre au jour sur SID.
À ce moment la, installer testing c'est une option pas folle puisque elle va passer à stable en quelques semaines (ben, peut-être mois, mais je ne crois pa que ça soit plus tard que le printemps), mais quand même, la première option je la trouve la meilleure.
Salut
Salut !
Toujours le même problème
Le mettre dans /root ne résout pas le problème de droits. Quand je souhaite accéder au disque, Pcmanfm m'affiche ce message :error 13 (Permission denied) opening credential file /root/cifs.credentials
Le fichier "credentials" c'est pour éviter avoir le mot de passe à la vue de tout le monde...mais utiliser ce fichier c'est réservé à root (ou avec sudo). Le chemin ou soit le fichier n'a pas d'importance, soit /root, /etc...
Plusieurs options:
1) Si tu changes noauto par auto, ou x-systemd.automount ou defaults, le répertoire distant sera monté dans de le démarrage, et il ne va pas avoir problème avec les permis de lecture sur le fichier credentials puisque ce root qui monte automatiquement, et il sera disponible dans pcmanfm. Je recommande ajouter aussi "nofail", pour ne pas attendre un minute et demi s'il y a échec du montage pendant l'amorçage,
Si le répertoire distant n'est pas disponible au démarrage du client, ou par des autres raisons (comme démontage à moitié session), il faut monter comme root
, mais pas possible dès pcmanfm et non plus comme utilisateur ordinaire.
Dans le cas des serveurs qui doivent être toujours accessibles, je trouve la solution la plus simple.
2) Utiliser une compte égale (nom/mot de passe) dans le serveur et le client. Deux façons de le faire, par exemple:
a) créer un utilisateur dans le serveur (adduser) avec le même nom, et le même mot de passe, l'ajouter à la basse de données de samba avec smbpasswd, et configurer les permis désirées dans les répertoires partagés, et aussi l'ajouter aux "valid users" dans les définitions des répertoires partagés.
b) Ou tu peux faire à l'inverse, et créer, dans le client un utilisateur (adduser), qui ait le même nom, et le même mot de passe.
Avec cette procédure,tu n'as pas besoin de fichier credentials, ni même pas indiquer username/password sur /etc/fstab. Pcmanfm , sinon explicité, fournisse le nom d'utilisateur en cours et son mot de passe...et il va réussir. Mais attention, il faut ajouter noauto aux paramètres, puisque sinon le montage automatique pendant le démarrage va échouer.
3) Si tu changes l'option "credentials" par "users, user, username=nom_utilisateur_distant" aux paramètres de la ligne du fstab, tu peux monter comme utilisateur, parmi ligne de commande, mais il va te demander mot de passe, mais pas possible dès pcmanfm ni montage automatique dans le démarrage. Comme dans "2)", il faut ajouter noauto. Je trouve la solution moins élégante, parce que cette ligne de fstab va indirectement ajouter un raccourci dans la liste de dispositifs de pcmanfm et pourtant si on clique dessus , le montage va échouer.
4) Tu peux toujours utiliser gvfs (intégré dans pcmanfm, et indépendant de les options qu'il y ait sur fstab), mais ce n'est pas exactement le même que parmi mount et/ou /etc/fstab (par exemple, il y a des associations des fichiers qui sont pas retenus. Ce problème c'est égal quand on monte des systèmes MTP, etc avec gvfs)
Tu peux accéder aux ressources distants avec ce chemin dans la barre d'adresses:
(nom_serveur peut être l'adresse IP aussi), et pcmanfm te demandera l'utilisateur et le mot de passe , et tu peux cocher la casse: "se souvenir du mot de passe jusqu'au la fin de session" ou même "se souvenir pour toujours"
Si le protocole SMB1 est utilisé dans le serveur, l'exploration du réseau local samba devrait fonctionner bien, donc on devrait voir le serveur sous l'adresse smb:/// . Néanmoins SMB1 c'est désactivé par défaut en Windows ça fait longtemps (dès le WannaCry), et sur plusieurs *nix/Linux, aussi. Dans ce cas l'exploration des serveurs ne marche pas, et bien on utilise accès direct avec le nom/IP du serveur, bien on utilise avahi pour que les serveurs publient leurs services réseau (parmi eux samba).
Évidement laisser le fichier credentials accessible aux utilisateurs, c'est une bêtise.
Salut
Je souhaite investir dans un boitier externe RAID 4 disques dur en USB 3.1
RAID via USB?
Moi je suis plutôt d'avoir la partie système la plus rapide posible, et après , une autre partie pour le stockage, qui n'a pas besoin d'être aussi rapide.
En general je ne trouve pas très intéressant avoir To "rapides" (dans une station de travail), si je peux avoir des Go ultrarapides, qui peuvent être"l'atelier", et quand finit le travail, stocker sur des To "lents" .
Est-ce que tu va acceder aux 6 To tous à la fois? Non. Un seule disque M2 peut être beaucoup plus rapide que ce boitier USB (et pas trop chère vu le devis total pour cette bécane).
À moins prix, au coût de perdre 1,5 To, j'achèterais un bon NVME M2 et trois disques durs. Au même plus au moins , un M2 et les trois disques en RAID 5 (carte PCI, pas USB ), et si tu peux casser le tirelire, des NVME en RAID, imagine: Asus HYPER M.2 X16 CARD (
Supports up to four PCIE® 3.0 M.2 drives, with transfer bandwidth up to 128Gbps
) Donc 128 fois la vitesse de USB 3.1.
Vu le devis totale de ta machine, lui mètre un cou de bouteille par USB, je ne vois pas trop le sens.
Salut
su et su - c'est pareil aujourd'hui apparemment.
Non sur Buster.
anonyme le 01-01-2019 03:52:42:
le message relatif a la modification sur Buster
util-linux (2.32-0.4) unstable; urgency=medium
The util-linux implementation of /bin/su is now used, replacing the
one previously supplied by src:shadow (shipped in login package), and
bringing Debian in line with other modern distributions. The two
implementations are very similar but have some minor differences (and
there might be more that was not yet noticed ofcourse), e.g.
- new 'su' (with no args, i.e. when preserving the environment) also
preserves PATH and IFS, while old su would always reset PATH and IFS
even in 'preserve environment' mode.
- su '' (empty user string) used to give root, but now returns an error.
- previously su only had one pam config, but now 'su -' is configured
separately in /etc/pam.d/su-l
The first difference is probably the most user visible one. Doing
plain 'su' is a really bad idea for many reasons, so using 'su -' is
strongly recommended to always get a newly set up environment similar
to a normal login. If you want to restore behaviour more similar to
the previous one you can add 'ALWAYS_SET_PATH yes' in /etc/login.defs.
-- Andreas Henriksson <andreas@fatal.se> Fri, 03 Aug 2018 10:52:22 +0200
Resumé:
Doing plain 'su' is a really bad idea for many reasons, so using 'su -' is strongly recommended to always get a newly set up environment similar to a normal login.
Traduction:
Faire un simple 'su' c'est une mauvaise idée par plusieurs raisons, alors utiliser 'su -' c'est fortement recommandé pour obtenir un environnement configuré pareil à ce-ci obtenu avec une identification normale.
Il me semble que ce changement va être un "hit-parade" sur ce forum et tout les autres liées à debian 
Salut
Je voudrais remercier les deux personnes qui ont répondu ... pour rien , merci
Ces TROIS personnes ont gaspillé SON temps avec toi.
Tout cela est très confus. Mets-toi un instant à la place des lecteurs qui essaient de comprendre ce que tu veux dire.
Tes messages sont confus. Personne peut t'aider si on ne te comprend pas. Et surtout, le plus intéressant des forums , c'est que tu le monde peut voir, lire, répondre..., bref: tous apprendre et tous ensemble, partagent leur connaissances. Si la question ce n'est pas compréhensible , le point de départ c'est raté, alors le reste...
Si ce que tu veux c'est quelqu'un qui résout TES problèmes, sans effort de ta parte, ça c'est un service dépannage, pas un forum sur la net.
Par curiosité...quelles sont tes motivations pour te rapprocher aux logiciels libres?
Salut
empanada a écrit :Une mise à jour plus tard: GRUB ne me présente plus que la Debian installée sur le SSD
Cette phrase me faisait penser qu'une actualisation du grub.cfg. surement fait par un update-grub fait suite à une mise à jour du noyau par exemple, exécuté dès le debian sur le SSD avait été la cause primaire du problème de Ludox (bon, pas primaire. La cause primaire c'était le fait de partager la partition /boot pour Fedora et le debian du SSD), donc je méfiait de que exécuter un update-grub pourrait résoudre ses problèmes.
D'après moi, le partage de /boot a entraîné le démarrage par défaut de Debian avec un noyau de Fedora. Les modules de ce noyau n'étant naturellement pas présents dans la racine de Debian (sauf les modules présents dans l'initramfs et déjà chargés), le noyau n'était pas pleinement fonctionnel et cela a entraîné le dysfonctionnement d'os-prober et update-grub qui n'ont pas détecté et inclus Fedora ni l'autre installation de Debian.
Logiquement, le redémarrage de Debian avec son noyau aurait permis de retrouver un fonctionnement normal d'os-prober et update-grub.
Oui, cette explication a beaucoup de sens. Elle était implicite dans tes messages antérieurs mais je voulais savoir ton avis avec certitude. Moi j'avais passé dessus du fait que debian démarrait avec un des noyaux Fedora. Merci.
empanada a écrit :Si on utilise hibernation oui, il faut créer un swap de la même taille ou supérieure de celle du RAM pour chaque système et empêcher systemd d'activer les deux swap
Comme je l'ai écrit, l'activation automatique de tous les swaps ne se produit qu'avec un disque système au format GPT. Si besoin, je connais 4 méthodes pour l'empêcher. Et ce n'est pas le seul problème posé à l'hibernation par le multiboot, il y a aussi les partitions partagées.
Intéressant, j'ignorais ce détail, mais...il n'y a peut-être un autre service qui active les swap sur des disques DOS/MBR? Il me semble d'avoir rencontré des swaps activés bien que pas déclarés dans le fstab ,dans des disques DOS/MBR. Je ne peux pas assurer car de plus en plus je ne crée pas de swap (à partir de 6 Go de RAM, et pour usage comme PC de bureau), et je ne me rappelle pas quand ou sur quel ordinateur.
Merci à nouveau, et salut
Salut,
je ne vais peut être pas me lancer tout de suite dans le rapatriement de /boot vers le ssd, avec purge de /boot de Fedora, que je ne sais pas gérer actuellement, et plutôt continuer dans ma lancée. Mon SSD ne fait "que" 110Gio.
Je pense faire ceci, avec l'aide de GParted:
A) sur le HDD:
1) éliminer sda3 et sda4 (donc sda5,6,7et 8)
2) laisser sda1 et sda2 pour Windows si remise en configuration d'origine
3) créer une nouvelle sda3, en étendue, pour accueillir mes /home:
4) donc créer une nouvelle sda4 pour /home Fedora
5) créer une nouvelle sda5 pour /home Debian
B) sur le SSD, tout en Partition primaire:
1) créer sdb1 pour accueillir /boot et / de Fedora
Indiquer que son /home sera sda4
A la demande de l'installateur, mettre Grub sur /boot de Fedora
2) créer sdb2 pour sa swap
3) créer sdb3 pour /boot et / de Debian
Indiquer que son /home sera sda5
A la demande de l'installateur, mettre Grub sur /boot de Debian
4) sdb4 pour sa swap.
J'ai donc une partition /boot par distribution, pour ne pas mélanger les noyaux et une swap par distribution comme conseillé par Empanada.
Cependant, je n'ai pas bien compris si les mises à jour de noyaux devront se faire en manuel, à cause du dualboot?
Je pense aussi créer une partition sdb5 pour y mettre mes fichiers les plus utilisés, et ainsi gagner en vitesse, simplement créer cette partition sur le SSD et la monter ensuite à partir de Debian suffira-t-il?
Alors maintenant je comprends mieux.
Comme dit avant, je ne croiserait pas des partitions /home entre différents disques. Je ne vois pas le gain.
Je propose beaucoup plus simple et costaud: virer sda4 (donc sda5 jusqu'au sda8), et créer une partition primaire ext4 dans ce espace libre pour stocker des données...mais pas comme des /home: une partition ext4 quelconque.
Après, dans la BIOS, configurer sdb comme disque d'amorçage par défaut.
Après, sur le SSD: une partition primaire sdb1 pour debian (tout inclue dedans: /boot, /home...), une autre sdb2 pour Fedora (tout inclue aussi), un autre primaire pour un swap...et ça y est. Installer en premier Fedora, et installer son GRUB sur sdb . Après installer debian et installer son grub sur sdb (donc écrase le grub de fedora).
De cette façon t'as un SSD qui ne nécessite pas des autres disques, et t'utilises le hdd pour stocker les données, lesquels tu peut accéder dès fedora et debian sans problème. C'est la meilleure façon de travailler avec des multiboot. Si tu veux accéder les données des Windows aussi, crée la partition NTFS au lieu de ext4.
Un swap pour les deux systèmes ce n'es pas problème si on n'utilise pas l'hibernation (par exemple en ajoutant le paramètre "noresume" dans la ligne GRUB_CMDLINE_LINUX_DEFAULT du /etc/default/grub des deux systèmes).
Si on utilise hibernation oui, il faut créer un swap de la même taille ou supérieure de celle du RAM poru chaque système et empêcher systemd d'activer les deux swap pendant l'amorçage, mais seulement son swap. Ceci dit, je n'ai jamais fait puisque je n'utilise jamais hibernation (je ne trouve pas trop de gain de vitesse dans le démarrage, et c'est source très fréquente des problèmes).
Cependant, je n'ai pas bien compris si les mises à jour de noyaux devront se faire en manuel, à cause du dualboot?
Non forcement mais il faudrait savoir comment les mises au jour d'un système peuvent affecter son amorçage. Par exemple, avec la config que je te propose, tu peux laisser debian avec mises au jour automatiques: aucun problème puisque le grub installé pointe vers son propre système, mais si Fedora fait un changement de noyau, il faut démarrer debian après, et fair un update-grub pour informer debian des changements chez Fedora.
Salut
Il y a plus simple que modifier l'entrée de menu avec l'éditeur de GRUB ou faire un chroot : sélectionner le noyau Debian (4.9.0) dans le sous-menu "options avancées". Une fois Debian démarré avec le bon noyau, update-grub devrait détecter au moins Windows et l'autre Debian sur le disque dur.
Une mise à jour plus tard: GRUB ne me présente plus que la Debian installée sur le SSD
Cette phrase me faisait penser qu'une actualisation du grub.cfg. surement fait par un update-grub fait suite à une mise à jour du noyau par exemple, exécuté dès le debian sur le SSD avait été la cause primaire du problème de Ludox (bon, pas primaire. La cause primaire c'était le fait de partager la partition /boot pour Fedora et le debian du SSD), donc je méfiait de que exécuter un update-grub pourrait résoudre ses problèmes.
Je ne comprenais du tout la cause du problème pour que le fichier /boot/grub/grub.cfg était un gros bor**, par exemple avec la même racine pour tous les options de démarrage bien qu'il a trois systèmes différents, mais je pensais que tout pourrait être à cause du partage de /boot.
Avec toute l'info qui avait donné boot-info-script, et le fait que la debian sda7 avair le répertoire /boot inclue sous sa racine, et son /boot/grub/grub.cfg était presque correct, sauf pour la debian du SSD, j'étais sûr que la procédure de réinstaller CE grub , réussirait restaurer la plupart des amorçages.
Alors, maintenant j'ai une question: c'était le fait d'amorcer avec un noyau Fedora ce que provoquait que update-grub ratait son travail? Et si oui, pourquoi exactement, parce qu'à ce noyau lui manquait leurs modules? (comme tu pointais ici
Du coup le noyau par défaut utilisé par Debian est un noyau de Fedora (car il a la version la plus haute), et forcément, ça ne marche pas bien puisque les modules de ce noyau ne sont pas présents sur la partition racine de Debian.
?)
Peut-être les modules du noyau fedora sur son initramfs suffisaient pour démarrer mais pas pour des autres tâches, comme par exemple un update-grub (ça pourrait expliquer des autres événements bizarres, comme
Petit bémol tout de même: mon disque dur externe en usb n'apparaissait nulle part, ainsi qu'une clé usb branchée
).
empanada a écrit :sda8 c'est le /home de la debian du SSD (/dev/sdb1) ..et j'ai peur que c'était aussi le /home de la debian du HDD (celle de sda7).
Apparemment non car le fstab de sda7 n'en fait pas mention.
Oui, ce fstab nous dit que le debian sur sda7 doit avoir le /home sous sa racine.
Je n'avais pas vu ce fichier dans toute l'info qui donne boot-info-script. Je ne connaissais pas ce petit script très intéressant. Merci.
@Ludox:
Mais je me demande comment refaire partir Windows si je retire tout le reste (sans GRUB)
Normalement grub ne touche pas aux bits d'amorçage, comme c'est le cas (partition avec la marque d'amorçage signalé avec *):
Donc il suffirait de réinstaller un code d'amorçage "standard" , au lieu du grub.
Ça peut être fait avec la commande install-mbr (paquet mbr), dès le propre debian (mais normalement ça le rendre pas amorçable(sauf si grub installé sur le boot sector), donc attention).
On peut réinstaller un MBR "standard" aussi avec un CD/DVD de secours Windows ou dès une invite des commandes de secours Windows (pas installé par défaut):
pour Windows XP, Server 2003...
Pour Windows Vista (ceci je ne suis pas sur), Windows 7, etc
La procédure pour laisser le hdd comme l'original, pourraient être faits dès un CD/DVD ou une clé USB live de gparted virer sda3, sda5, sda6, sda7, sda8, sda4 (dans ce ordre), agrandir sda2 pour utiliser tout l'espace libre laissé par les partitions virés, et finalement installer un mbr "standard". Je crois que les live de gparted n'incluent pas ce package, mais il peut être installé dès le propre live je crois. Sinon, il y a des autres live qui l'ont par défaut (clonezilla par exemple).
je ne vais peut être pas me lancer tout de suite dans le rapatriement de /boot vers le ssd, avec purge de /boot de Fedora et continuer dans ma lancée.
Je pense faire ceci:sur le HDD:
Je ne comprends pas très bien ce paragraphe, mais mon conseil ce le même de raleur:
Note que tu n'es pas obligé de refaire une nouvelle installation ; tu peux modifier celle-ci pour rapatrier le contenu de /boot sur la partition racine (et supprimer les fichiers de Debian dans la partition /boot de Fedora), installer GRUB dans le MBR du SSD, agrandir la partition racine pour y loger le contenu de /home ou créer une partition séparée pour /home sur le SSD.
En résumé : essayer de laisser tous les systèmes les plus indépendants possible: pas des systèmes avec des répertoires de système dans des disques ailleurs, pas des grub dans des disques ailleurs, pas des /boot dans des disques ailleurs, et tout ce qui peut rester sous la racine, tant mieux.
Si tu veux amorcer ce disque SSD comme sdb, faire le réglage sur la BIOS du PC ou si n'est pas possible(ça peut arriver avec des BIOS extrêmement simples), les échanger physiquement , ou bien enchaîner les amorçages, ou...
Moi, j'utilise normalement une partition ext4 "petite" pour tout le système , sans rien séparer, et le reste pour le données. Je laisse les programmes stocker leurs préférences sous /home, mais je ne l'utilise pas comme répertoire de stockage. Toutes mes données sont dans des partitions séparés du système.
Rappelle que tout système qui soit dans le SSD, normalement va être beaucoup plus rapide que ceux dans le hdd. En général, avec un SSD, et un HDD, la configuration qui a plus de sens c'est avoir tous les systèmes dans le SSD, et les données dans le HDD: le SSD plus rapide, donne de la performance aux systèmes, le HDD normalement plus grande, mieux pour stocker des données. Parfois, il faut bouger temporairement quelques données vers le SSD pour améliorer la performance: par exemple si on travaille avec des fichiers d'image, vidéo,des images de disque de machines virtuelles...Mais après, retour sur le hdd.
Salut.
@ Empanada:
Oui en effet j'ai utilisé la même partition boot, pensant que GRUB s'actualisait ou se ré-écrivait sur cette partition...mauvaise déduction.
Dans l'idéal j'aimerais bien avoir accès à nouveau à ma Debian sur /dev/sda4, et laisser Win... tel quel sur le HDD au cas où je le remettrais dans sa configuration d'origine pour quelqu'un d'autre.
Après cela, en effet je passerai à quelque chose de plus simple, peut être en dual, avec les "/" racines sur le SSD, les "/home" sur HDD
Beau bord** ...mais avec les logiciels libres ont à les plans, alors on peu presque toujours réparer.
Debian dans le disque dur c'est dans sda7:
sda4 c'est la partition étendue .
sda1 et sda2 sont à Windows.
sda3 c'est /boot partagé pour fedora et debian du SSD externe.
sda5 c'est la racine fedora
sda8 c'est le /home de la debian du SSD (/dev/sdb1) ..et j'ai peur que c'était aussi le /home de la debian du HDD (celle de sda7). Si oui, il y a deux options:
A) tu l'as formaté pendant l'installation, donc t'as perdu les données et les configurations à niveau utilisateur de ce debian sda7...
B) ou tu ne l'a pas formaté pendant l'installation, et tu n'as pas tout perdu mais certaines configurations peuvent avoir être écrasés suite à l'utilisation avec le debian SSD, mais, à priori, ça ne devrait poser pas trop problèmes.
Il me semble que la réponse va être B)....
J'ai seulement une doute: fedora avait son /home sous la racine ou séparé (peut-être le même, encore une fois, que le /home de debian sda7 et debian sdb1?)?
Quand à la configuration future, je vais donner mon avis après, maintenant on va essayer de réparer pour récuperer cette configuration:
"Dans l'idéal j'aimerais bien avoir accès à nouveau à ma Debian sur /dev/sda4, et laisser Win... tel quel sur le HDD au cas où je le remettrais dans sa configuration d'origine pour quelqu'un d'autre."
Je commencerai par utiliser la partition sda7 comme point de départ, puisqu'elle semble avoir le répertoire /boot intact (pas mélangé avec des autres systèmes), et à partir d'ici, continuer.
Pour récupérer l'amorçage de debian sur sda7, il y a plusieurs options.
1) Tu peux essayer de démarrer directement dès la ligne de commande de GRUB (il faut presser la touche "e" tout au début du lancement du GRUB, pour stopper le lancement de l'option par défaut, et aprés Ctrl+C ou F2).
Ces commandes devraient réussir amorcer debian sur sda7.
Une foi démarré debian sur sda7, je ferais un
mais pas un
. Pourquoi?, parce que le fichier /boot/grub/grub.cfg sur sda7 a une configuration "vieille", et il tient pas en compte les nouveaux fichiers mis sur /sda3 par la dernière installation de debian (celle du SSD) (mieux, pour essayer de ). Si tout va bien, après ça tu devrais être capable d'amorcer sans problème debian sda7, Fedora et Windows, mais pas debian sur du SSD
2)Une autre option c'est laisser démarrer avec le debian du SSD, et faire le même que dans l'option 1) , mais parmi un chroot (Cette procédure pourrait être faite en amorçant dès un live CD/USB "quelconque" (par exemple un live USB d'installation debian en mode "rescue")) les pas seraient:
- Laisser démarrer debian du SSD
- Vérifier si /dev/sda7 c'est déjà monté avec
- Si sda7 n'est pas montée (réponse vide), il faut la monter:
- À partir de ce moment-là on va supposer que /dev/sda7 c'est montée sur /mnt/sda7. Si c'est sur un autre emplacement, substituer par le répertoire de montage correct la chaîne /mnt/sda7:
- Rédémarrer et comme dans l'option 1) , tu devrais être capable d'amorcer sans problème debian sda7, Fedora et Windows, mais pas debian sur du SSD
Allez-y et tu nous racontes.
Après on peut continuer à réparer et/ou modifier, mais avant, réparer l'amorçage debian sda7, Windows, et Fedora.
Salut.
Edit à toto : Modif faite - Séparé les commandes les unes des autres pour que ce soit plus lisible par tous.
