Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
une fois la Debian lancée.
Je soupçonne quelque chose au niveau du fichier fstab dont je connais l'existence mais sans avoir d'autre connaissance à son propos.
Mon désir est de pouvoir au moins récupérer la possibilité de lancer Wind*** et pouvoir par la suite mettre toutes mes autres distrib' sur le SSD sans que tout se casse à la première mise à jour. Et si je peux comprendre ce qui se passe c'est le nirvana!
Quelqu'un aurait une idée?
C'est un peu long, merci de m'avoir lu.
Librement votre.
Ludovic.
Dernière modification par Ludox (22-01-2019 15:32:06)
"Mundi placet et spiritus minima", ça n'a aucun sens mais on pourrait très bien imaginer une traduction du type : "Le roseau plie, mais ne cède... qu'en cas de pépin" ce qui ne veut rien dire non plus. Roi Loth, François Rollin.
Hors ligne
Hors ligne
J'ai également lu qu'il existerait une liste des options que GRUB doit nous présenter, via /boot/grub/menu.lst, que je ne trouve pas :-(
"Mundi placet et spiritus minima", ça n'a aucun sens mais on pourrait très bien imaginer une traduction du type : "Le roseau plie, mais ne cède... qu'en cas de pépin" ce qui ne veut rien dire non plus. Roi Loth, François Rollin.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
me donne cela:
@ Raleur:
me donne:
J'y vois bien mes partitions mais ça s'arrête là dans mes compétences...
"Mundi placet et spiritus minima", ça n'a aucun sens mais on pourrait très bien imaginer une traduction du type : "Le roseau plie, mais ne cède... qu'en cas de pépin" ce qui ne veut rien dire non plus. Roi Loth, François Rollin.
Hors ligne
Dernière modification par empanada (17-01-2019 19:23:57)
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
Dernière modification par Debian Alain (17-01-2019 20:05:02)
Hors ligne
.Dernière modification par naguam (17-01-2019 22:08:32)
Unixien?
Compiler son kernel!
Hors ligne
"Mundi placet et spiritus minima", ça n'a aucun sens mais on pourrait très bien imaginer une traduction du type : "Le roseau plie, mais ne cède... qu'en cas de pépin" ce qui ne veut rien dire non plus. Roi Loth, François Rollin.
Hors ligne
Dernière modification par naguam (17-01-2019 22:27:28)
Unixien?
Compiler son kernel!
Hors ligne
Hors ligne
@ 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.
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
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.
Par contre le système Debian du disque dur va avoir un souci avec l'UUID du swap qui a changé suite à la seconde installation de Debian. Il faudra mettre à jour son fstab et son initramfs.
Il vaut mieux montrer que raconter.
Hors ligne
"Mundi placet et spiritus minima", ça n'a aucun sens mais on pourrait très bien imaginer une traduction du type : "Le roseau plie, mais ne cède... qu'en cas de pépin" ce qui ne veut rien dire non plus. Roi Loth, François Rollin.
Hors ligne
ce que tu décris Naguam c'est le chainloading? Où une partie de GRUB s'installe dans une partition /boot (?) (le stage 2) et une autre partie est dans le premier secteur de disque (stage 1)
Non, on parle de "chainloading" (ou chaînage) quand un chargeur d'amorçage lance un autre chargeur d'amorçage. Par exemple quand le programme d'amorce standard du MBR lance le secteur d'amorce de la partition active (schéma de Naguam), ou quand GRUB lance le GRUB d'un autre système, ou quand GRUB lance le chargeur d'amorçage de Windows (ntldr/bootmgr). Le chargement de l'étage suivant de GRUB par l'étage précédent de GRUB n'est pas du chaînage, c'est juste le processus de démarrage de GRUB.
Stage 1, 1.5 et 2 sont des notions propres à l'ancienne version GRUB 1/legacy. Dans la version actuelle GRUB 2 elles sont remplacées par la boot image (secteur d'amorce) et la core image. La boot image charge la core image qui charge les modules et la configuration installés dans /boot/grub.
La boot image et la core image sont obligatoirement sur le même disque, alors que /boot/grub peut être sur un disque différent. Cependant c'est une configuration à éviter car cela rend les deux disques dépendants l'un de l'autre, chacun contenant seulement une partie de GRUB.
La prochaine étape pour moi c'est d'utiliser le SSD pour y faire un dual boot, donc /boot, swap et / dessus. Installé en manuel de préférence pour me faire la main, mais proprement, et avec les /home sur le HDD.
Pas besoin de partition /boot séparée si la racine est dans une partition normale (sans chiffrement ni LVM) avec un système de fichiers supporté par GRUB.
Je ne vois pas l'intérêt de mettre /home sur le disque dur plutôt que sur le SSD, cela va dégrader les performances inutilement. Tu peux réserver le disque dur au stockage de gros fichiers si la capacité du SSD ne suffit pas.
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.
Il vaut mieux montrer que raconter.
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
Dernière modification par Ludox (19-01-2019 17:49:33)
"Mundi placet et spiritus minima", ça n'a aucun sens mais on pourrait très bien imaginer une traduction du type : "Le roseau plie, mais ne cède... qu'en cas de pépin" ce qui ne veut rien dire non plus. Roi Loth, François Rollin.
Hors ligne
Dernière modification par Croutons (19-01-2019 19:26:32)
-->les cahiers du debutant<-- WikiDF-->Découvrir les principales commandes Linux<--
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde
Hors ligne
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.
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
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
Dernière modification par empanada (19-01-2019 20:17:51)
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
3) créer une nouvelle sda3, en étendue, pour accueillir mes /home:
4) donc créer une nouvelle sda4 pour /home Fedora
Une partition logique ne peut pas avoir un numéro inférieur à 5. sda4 serait une partition primaire.
J'insiste : mettre tout /home sur le disque dur est une mauvaise idée, cela va dégrader les performances de la session lors de l'accès à tous les fichiers utilisateur par les programmes lancés dans la session (données, caches, configurations...).
A la demande de l'installateur, mettre Grub sur /boot de Fedora
Ça ne marche pas comme ça. Lors de l'installation de GRUB, il est demandé d'indiquer le périphérique (disque ou partition) dont le secteur d'amorce (MBR ou PBR) doit recevoir la boot image de GRUB. Tu ne pourras spécifier le MBR du SSD (sdb) que pour une seule installation, sinon la seconde écrasera la boot image du GRUB de la première. Et c'est seulement le GRUB qui est installé en dernier dans le MBR qui sera lancé au démarrage (si le SSD est prioritaire sur le disque dans le BIOS).
4) sdb4 pour sa swap.
Attention, par défaut l'installateur Debian sélectionne tous les swaps existants et les marques à formater. Si tu laisses faire, le reformatage du swap de Fedora changera son UUID qui ne sera plus reconnu par Fedora.
J'ai donc une partition /boot par distribution
Non, tu n'auras pas de partitions /boot. Tu auras des partitions / (racines) contenant /boot
.
Cependant, je n'ai pas bien compris si les mises à jour de noyaux devront se faire en manuel, à cause du dualboot?
Oui et non. Pour le système dont le GRUB est dans le MBR, il n'y aura rien de particulier à faire, le menu de démarrage sera mis à jour automatiquement. Pour l'autre, après une mise à jour qui change le nom du fichier /boot/vmlinuz-* ou l'ajout d'un nouveau noyau, il faudra redémarrer sur le système principal et exécuter update-grub (si Debian) ou update-grub2 (si Fedora) pour mettre à jour le menu de démarrage.
Pour éviter cette procédure fastidieuse, tu peux désactiver os-prober et chaîner les deux GRUB.
Je pense aussi créer une partition sdb5 pour y mettre mes fichiers les plus utilisés
Une table de partition DOS/MBR ne peut contenir que 4 partitions primaires. Une 5e partition serait obligatoirement une partition étendue, ce qui implique qu'une des partitions primaires serait une partition étendue. Les partitions logiques, ça pue. Pour éviter d'y avoir recours, tu peux créer une table de partition au format GPT qui permet de créer 128 partitions par défaut.
Attention cependant :
- Pour l'amorçage BIOS avec GRUB, il est recommandé de créer une partition de type "BIOS boot" de 1 Mo non formatée QUI N'EST PAS UNE PARTITION /boot.
- systemd active par défaut toutes les partitions de swap présentes sur un disque système au format GPT, même non déclarées dans /etc/fstab. Cela pose un problème pour l'hibernation "croisée" (mise en hibernation d'un système et redémarrage sur l'autre), de même qu'une partition partagée entre les deux systèmes.
Dernière modification par raleur (19-01-2019 21:12:31)
Il vaut mieux montrer que raconter.
Hors ligne
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.
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
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.
Il vaut mieux montrer que raconter.
Hors ligne
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
"blues are the roots and the other musics are the fruits" . Willie Dixon
Hors ligne
il n'y a peut-être un autre service qui active les swap sur des disques DOS/MBR?
Il y a les unités swap de systemd (cf. man systemd.swap) mais à ma connaissance Debian n'en crée pas implicitement excepté celles qui proviennent de fstab.
Il vaut mieux montrer que raconter.
Hors ligne