Forum Flightgear France

Une communauté prend son envol

Vous n'êtes pas identifié(e).

Annonce

Futur nouvel inscrit, tu dois au préalable lire l'intégralité des 10 articles des règles, s'il te plaît. Tout nouveau compte qui ne respecte pas les règles sera supprimé par l'administration.

#176 22/05/2019 12:38:34

GR
Membre
Inscription : 28/01/2019
Messages : 173

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonjour,

Les 20 mn d'attente sont survenues lorsque j'ai voulu démarrer mint depuis la clé sur laquelle le système avait été installé (et j'avais eu le message "installation terminée") depuis la session live. Toutes les opérations de décompressions et autres avaient donc déjà été effectuées. Je n'étais plus dans une session live et la clé d'installation était débranchée. Donc pourquoi un temps si long ?

D'autre part j'ose espérer que les opérations complexes ci-dessus sont automatiquement réalisées lors de l'installation. Sinon ce n'est pas demain la veille que je pourrai utiliser FG sous linux.
Bien cordialement
GR


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#177 22/05/2019 14:22:28

rominet
Membre
Inscription : 23/03/2019
Messages : 61

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

1) Pour le délai, j'avais mal compris : je croyais que c'était au démarrage d'un système Live, mea culpa. Je ne sais l'expliquer. Il y avait peut-être un message d'erreur affiché en boucle mais caché parce que « plein de messages qui défilent, c'est pas user-friendly, vous comprenez ». Par exemple comme celui que tu as mentionné, où systemd voulait écrire son log sur un filesystem monté en lecture seule... C'est pas bien de cacher les messages de démarrage, mais ça se fait très souvent par défaut (comme sous Windows et MacOS). Quand il n'y a pas d'erreur, ça fait bien, c'est “slick”, mais quand il y a un problème, ça complique les choses ; il faut alors commencer par trouver comment faire  afficher les messages.

2) Oui, le programme d'installation que je connais (Debian) fait le partitionnement de manière plus ou moins autonome, selon le choix de l'utilisateur, à travers son système de menus. Je ne sais pas s'il respecte bien les contraintes d'alignement (je l'espère), car elles ne me sont apparues que dans les 4-6 dernières années à la louche, et la dernière installation “from scratch” que j'ai faite doit être plus ancienne (en général, les mises à jour sont suffisantes : pas besoin de réinstaller le système).

Les manips que j'ai citées ne sont pas si compliquées que ça, il suffit de s'y prendre calmement (hors problème bizarre comme celui de ton boot, il s'entend). 'info parted' pour la doc de parted qui est aussi disponible en ligne. Les commandes que j'ai indiquées permettent je crois de faire tout un partitionnement standard au format MBR, et il n'y en a pas pléthore. Passé le premier contact, l'utilisation directe de parted peut s'avérer plus pratique qu'un programme d'installation pas toujours ergonomique pour le partitionnement et qui dépend de la distribution. Mais bon, je comprends que cela rebute au début.

Mon exemple crée une table des partitions au format MBR, mais j'ai un Linux qui tourne sur Raspberry PI et qui accède à un disque (USB externe) partitionné au format GPT, ça fonctionne bien aussi. On est obligé d'utiliser le format GPT si l'on veut créer des partitions plus grandes que 2 Teraoctets.


Debian GNU/Linux, driver libre pour carte Radeon HD 4670, FG 'next', 8 Go de RAM

Hors ligne

#178 22/05/2019 17:00:55

GR
Membre
Inscription : 28/01/2019
Messages : 173

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonjour,
Mon DDE de 2 TB est arrivé. Il était déjà formaté en NTFS. J'ai créé un volume simple de 5OO GB et l'ai rendu "unallocated" par un delete dans "gestion des disques". Sous gparted (dans la session live) j'ai sdb divisé en sdb1 (/) et sdb2 (/home). Je ne sais où installer grub puisque maintenant le disque comporte aussi une partition W (dans mon test avec la clé je n'avais qu'une partition et je l'avais positionné en début de disque). Dans ce cas, puisque c'est la partition qui est 'bootable', il me faut mettre le lanceur grub au début de cette partition mais alors faut il créer une autre partition receptrice de quelques MB et de type /root (désolé mais je continue à pédaler).
Bien cordialement
GR


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#179 22/05/2019 22:32:08

ctesc356
Membre
Inscription : 18/05/2010
Messages : 2 795

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Grub s'installera tout seul sur /,(sdb1). Si la question est posée pendant l'installation, installer grub sur /
Il semble que chaque constructeur fait un efi à sa sauce, mais il sera toujours possible de rectifier si quelque chose clochait.

Important: avoir une clé ou dvd de réparation de w10 à jour
sauvegarde des données importantes.

ps: avant d'installer peut-être vérifier que tu peux bien monter sdb1/2

Dernière modification par ctesc356 (23/05/2019 9:09:36)


Intel i5 3570 3.4Mhz, Nvidia GTX 660, 8Go Ram, Linux Mint

Hors ligne

#180 23/05/2019 9:27:53

rominet
Membre
Inscription : 23/03/2019
Messages : 61

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

@GR

“Partition de type /root”, c'est un peu confus. Il faut une partition racine pour le système (root partition en anglais, mais pas /root : ça, c'est le répertoire home de l'utilisateur root !) ; le type de partition, c'est autre chose[1]. La partition racine peut être modérément petite mais ce n'est pas nécessaire. Si elle est trop petite, ça va poser problème lors des mises à jour noyau, car souvent, l'ancien est conservé. J'ai un ordi où elle fait environ 900 M et il faut que je fasse attention, sinon le problème arrive régulièrement. Donc sauf contrainte particulière, je pense que je ferais au moins 2 G aujourd'hui pour ne pas être trop embêté (il y a pratiquement tous les drivers de tous les périphériques supportés dans chaque noyau, ça prend de la place).

Je suppose que tu démarres en (U)EFI. Dans ce cas, la « petite » partition dont tu parles doit être la partition spéciale appelée ESP (EFI system partition). Je n'ai pas d'expérience avec EFI, mais je pense que si elle est a été créée, GRUB ou un programme d'installation EFI-aware doit la voir.

D'après le peu que j'ai lu, le bazar, c'est quand un système « met à jour » des fichiers dans une partition ESP qui normalement ne le regarde pas, ou qu'il se comporte comme s'il était tout seul. Voir par exemple dans cette doc Ubuntu en français l'encadré qui commence par « Attention. Depuis déjà avant 2017 une partition EFI (...) ». Il faut alors vérifier que le fichier /etc/fstab dit de monter la bonne partition ESP sur /boot/efi. Mais on n'y est pas encore...

[1] Il y a plusieurs acceptions pour ce terme : dans le système de partitionnement MBR, cela peut renvoyer soit à partition primaire ou étendue, soit à Linux [83h], Linux Swap [82h] ou plein d'autres types possibles, notamment pour les autres systèmes.

Dernière modification par rominet (23/05/2019 9:29:28)


Debian GNU/Linux, driver libre pour carte Radeon HD 4670, FG 'next', 8 Go de RAM

Hors ligne

#181 23/05/2019 11:39:17

GR
Membre
Inscription : 28/01/2019
Messages : 173

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonjour,

Je viens de faire un essai complet sur le DDE externe et j'ai noté tous les messages lors de l'installation. Tout est dans le fichier du lien

https://www.dropbox.com/s/92mxpvzr8n7d4 … e.pdf?dl=0

Cela devient décourageant.
Merci encore pour tous vos commentaires qui me seront bien utiles lorsque cela marchera (gardons espoir).
Bien cordialement
GR

PS dans mon mail précédent je voulais mettre "partition de type /boot"


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#182 23/05/2019 12:27:11

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 3 077

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Pour être concret... D'après mes notes de l'époque.

Je ne sais pas si ça peut aider (corrigez-moi SVP), mais voici mon organisation, sur les conseils de f-jjth (très avisé, malheureusement parti).

Situation de départ : Windows Vista (donc BIOS classique).

Deuxième disque dur, neuf, 1 TB en SATA (PC Tour).

A partir du DVD Linux Mint, je vois :
/dev/sda1, sda2, sda3 = disque N°1 Windows,
/dev/sdb = disque neuf.

1- Je sélectionne dev/sdb.

2- Le DVD Linux live me demande : Périphérique où sera installé le programme de démarrage : je mets dev/sdb (Attention !!)
(il n'y a pas encore de partition, et je suppose que Linux a détecté Windows).
==> "Nouvelle table de partition"
Vérification :
/dev/sdb sélectionné ==> donne sdb1, Étendue.
/dev/sdb pour le programme démarrage (GRUB).

Je n'ai donc pas eu de difficultés pour placer le GRUB.
Je ne sais pas si la détection de Windows sera aussi efficace en externe USB.

3- Guidé par l'installateur, j'ai ensuite créé mes 3 partitions sdb5 = swap, sdb6 = /home et sdb7 = racine (/)
(en fait 4 partitions, mais une est en réserve de secours, non allouée)

Sur ce deuxième disque, je me retrouve avec : "Partitionnement :  Zone amorce (MBR)"
- Une partition Étendue /dev/sdb1 (Amorçable) 1TB,
- Une partition d'échange (swap) sdb5,
- Système de fichiers dev/sda7 (Monté sur "Racine du système de fichiers"),
- Système de fichiers dev/sda6 (Monté sur /home)

[EDIT] je viens de voir ton message précédent : différemment de toi, je suis parti du disque dur neuf, non partitionné. Le GRUB a été installé avant mon partitionnement.
J'avoue ne pas trop comprendre où est le GRUB. Mais je fais confiance à nos amis pour répondre.

Dernière modification par dany93 (23/05/2019 12:33:31)


FG 2019.2.0, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB, OSG 3.4.2
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#183 23/05/2019 12:39:10

rominet
Membre
Inscription : 23/03/2019
Messages : 61

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

@GR

1) Je crois que qu'il faut que tu oublies /boot (c'était utile avec l'ancien système d'amorçage et d'anciennes versions de GRUB ou LILO, mais je crois que ça n'est plus trop d'actualité ; en tout cas, sans doute pas avec EFI). Ça va juste être un répertoire de ta partition racine une fois l'install terminée, et non une partition à part.

2) Truc bizarre : l'installateur te dit dès le départ « il semble exister d’autres systèmes d’exploitation installés qui utilisent le mode de compatibilité BIOS ». Gni ? Lesquels ? Reliquats d'installation échouée ?.. As-tu vérifié que ton Windows démarre bien en EFI ? (Google donne pas mal de méthodes)

3) Erreur probable : d'après la doc Ubuntu que j'ai déjà citée, en français, la partition spéciale EFI, appelée ESP, doit être entièrement incluse dans les 100 premiers Go du disque, or la tienne vient après sdb3 qui fait 500 Go. Ceci peut expliquer l'impossibilité d'installer GRUB dans sdb4.

4) Sur la taille de la partition, la doc Ubuntu dit :

Taille : entre 35 Mo et 250Mo mais une taille de 5 Mo est suffisante si vous n'installez pas windows mais impossible à faire accepter par gparted.

Cela ne correspond pas non plus à ta partition de 2 Mo (je sais que tu as respecté la contrainte de taille minimale de 1 Mo donnée par ton installateur...).


Debian GNU/Linux, driver libre pour carte Radeon HD 4670, FG 'next', 8 Go de RAM

Hors ligne

#184 23/05/2019 13:06:47

rominet
Membre
Inscription : 23/03/2019
Messages : 61

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

@dany93

Ton système démarre en mode BIOS, pas EFI, ça a l'air assez différent. Et puis c'est la première fois que je vois un flag 'bootable' mis sur la partition étendue ! Linux se fiche de ce flag, il n'y a que Windows qui s'en sert. Linux avec GRUB, utilise la config GRUB.

Quant à la question « où est ton GRUB », il peut être à pas mal d'endroits, d'autant plus que tu as deux disques et que GRUB peut être installé sur chacun d'entre eux. Attention, je parle ici du système d'amorçage BIOS, pas EFI : si on boote vraiment avec GRUB, alors une partie de GRUB est sur le MBR du disque sur lequel on boote, mais ça ne suffit pas car le MBR est minuscule (512 octets dont la table des partitions). Il faut qu'il charge d'autres fichiers depuis d'autres partitions. Souvent, c'est directement dans la partition / du Linux concerné, mais c'est pas obligé ; je crois qu'il peut stocker et utiliser des fichiers dans des endroits plus « sioux » (partition Windows, voire espace entre deux partitions...). Il est également possible, sauf erreur, que le bootloader de Windows (menu Microsoft au tout début du démarrage) charge GRUB (il faut sans doute le paramétrer spécialement pour ça).

Selon moi, tu as un peu gaspillé tes partitions primaires. Je m'explique : le MBR est tellement petit qu'il ne peut stocker, en plus de la partie initiale du code d'amorçage, que les infos relatives à 4 partitions, d'où la fameuse limitation et le fait que lorsqu'on crée une partition étendue, elle compte pour une primaire (parmi les 4 dont les infos sont sur le MBR). Les infos des partitions logiques à l'intérieur de la partition étendue (type, adresse début, adresse fin) ne sont donc pas stockées dans le MBR. La partition étendue pointe vers la première partition logique, qui pointe vers la seconde, etc.

Conséquence : si une corruption affecte l'endroit où une partition logique contient le pointeur vers la suivante, c'est mort pour toutes celles qui viennent après (après, on peut peut-être scanner le disque en cherchant des motifs, mais ça devient plus hasardeux). D'où la recommandation que j'ai lue : toujours utiliser à fond les partitions primaires pour les choses les plus précieuses, donc au plus 3 « vraies primaires » et une étendue. Leurs infos sont sur le premier secteur du disque, indépendantes les unes des autres. On peut même sauver le MBR avec dd...


Debian GNU/Linux, driver libre pour carte Radeon HD 4670, FG 'next', 8 Go de RAM

Hors ligne

#185 23/05/2019 13:12:57

GR
Membre
Inscription : 28/01/2019
Messages : 173

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonjour,
Dans les paramètres système il y a UEFI en face de BIOS mode.
Je peux remettre tout le DDE en "unallocated" et essayer de suivre le cheminement qui a marché pour Dany93, mais cela ne garantit pas forcément que l'installateur actuel réagira favorablement. Si OK je pourrai alors réduire la partition /home pour créer une autre partition NTFS Windows ?
Bien cordialement
GR


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#186 23/05/2019 13:24:56

rominet
Membre
Inscription : 23/03/2019
Messages : 61

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Je crois que le cheminement de dany93 s'applique au mode BIOS (ancien) et non à UEFI. D'après la page Ubuntu que j'ai citée :

si les autres systèmes (Windows Vista/7/8, GNU/Linux…) de votre ordinateur sont installés en mode EFI, alors il faut installer Ubuntu en mode EFI.

Cela ne laisserait donc pas le choix. Je n'ai jamais utilisé (U)EFI moi-même, j'ai juste un peu lu dessus.


Debian GNU/Linux, driver libre pour carte Radeon HD 4670, FG 'next', 8 Go de RAM

Hors ligne

#187 23/05/2019 13:33:21

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 3 077

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

@rominet,

Merci pour tes explications (que je ne suis capable de digérer que partiellement).

Pour limiter les hypothèses possibles, mon GRUB est forcément sur le deuxième disque (Linux). Ceci correspond à ce que j'ai demandé et vu à l'installation. Et, surtout, mon disque initial Windows est débranché depuis longtemps, et je vois passer le GRUB au démarrage PC.

Ma partition étendue de 1 TB /dev/sdb1 (sda1 aujourd'hui après débranchement du disque initial Windows) est notée " Partitionnement Zone amorce (MBR)". "Type de partition Étendue (Amorçable)".
Vu qu'aucune partition n'était encore faite quand l'installeur m'a demandé "Périphérique où sera  installé le programme de démarrage", il me semble que la seule possibilité est que le GRUB soit là. Mais je ne sais pas comment on peut le voir.

J'ai lu plusieurs fois que le GRUB sur le disque Windows pouvait être source d’ennuis.

Dernière modification par dany93 (23/05/2019 14:56:46)


FG 2019.2.0, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB, OSG 3.4.2
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#188 23/05/2019 14:57:31

GR
Membre
Inscription : 28/01/2019
Messages : 173

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonjour,
Donc si je comprends bien (mais est ce possible ?) la manipulation à partir d'un disque complètement "unallocated" ne pourrait marcher que si je force l'installation UEFI, ce qui n'est guère rassurant compte tenu du message de l'installateur. Il faudrait alors qu'il n'y ait plus de Windows du tout ce qui non envisageable pour moi : parmi les simulateurs du marché il n'y a que FG et XP pouvant être utilisés sur les deux systèmes. Je ne sais pas ce que ma configuration a de si particulier car sur le net tout semble marcher en quelques minutes et après quelques clics seulement : une malédiction doit planer sur ma campagne.
Bien cordialement
GR


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#189 23/05/2019 15:21:00

dany93
Administrateur
Lieu : Région Parisienne
Inscription : 5/07/2009
Messages : 3 077

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Il y encore quelque chose que je ne comprends pas ou mal (comme toi, c'est possible hmm ).

Le GRUB et Linux, si installés, sont sur le disque externe USB qui, pour moi, est complètement indépendant de Windows (sauf éventuellement lancé par l'intermédiaire du GRUB). En tous cas, on écrit ce qu'on veut sur l'un sans détruire l'autre.

Je suppose aussi que le BIOS ou UEFI n'est pas modifié par l'installation de GRUB + Linux sur le disque USB. Là, je suis moins sûr...
Je comprendrais qu'une configuration mal adaptée, UEFI ou pas, du disque USB (avec GRUB) empêche alors de lancer Windows par le GRUB. Mais alors, qu'est-ce qui empêcherait de lancer Windows avec le disque USB débranché ??

Et, si Linux fonctionne avec ou sans GRUB, UEFI ou non, il devrait pouvoir être lancé en configurant manuellement l'ordre du boot dans l'UEFI ou ce qui reste du BIOS pour le disque USB en premier. Pas pratique, certes (encore que.. si l'USB n'est pas branché, il devrait chercher le suivant). Mais au moins pour la compréhension et se décontracter un peu, oser faire des essais sur le disque USB ?

Où est la faille dans mon raisonnement ?

Le microcode de ce système a démarré l’installateur en mode UEFI mais il semble exister d’autres systèmes d’exploitation installés qui utilisent le mode de compatibilité BIOS.

Les "autres systèmes d'exploitation BIOS" qu'il croyait voir ne seraient-ils pas ta "sous-partition sdb1 (1.33 GB sous NTFS)" ??

Si OK je pourrai alors réduire la partition /home pour créer une autre partition NTFS Windows ?

Pour quoi faire ?


FG 2019.2.0, Linux Mint 18 (64b), Quad Q6600 (2.4 GHz), RAM 8Go DDR2, GEFORCE GTX 650 1GB, OSG 3.4.2
Boeing 787-8 (YASim, avec nickyivyca, aco)
DR400 JSBSim (PAF)
DC3 JSBSim (PAF)

Hors ligne

#190 23/05/2019 17:05:47

GR
Membre
Inscription : 28/01/2019
Messages : 173

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonjour,

Le OK fait référence à une installation mint réussie mais utilisant tout le DDE, ce qui est trop car je veux garder sur ce DDE une partition NTFS pour W10, mais cela est il possible ? Sinon on en revient au dual boot qui devrait ne pas poser de problème (quoique !) ou à l'achat d'un DDE de bureau de 500 GB seulement (ce qui n'est pas sûr de fonctionner non plus compte tenu des déboires précédents).
Bien cordialement
GR


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#191 23/05/2019 20:39:40

rominet
Membre
Inscription : 23/03/2019
Messages : 61

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

GR a écrit :

Il faudrait alors qu'il n'y ait plus de Windows du tout ce qui non envisageable pour moi

Je ne crois pas avoir dit ça. Tu as dit que ton Windows boote en UEFI, donc installer un GRUB qui démarre en UEFI ne devrait pas empêcher de démarrer Windows.

dany93 a écrit :

Et, si Linux fonctionne avec ou sans GRUB, UEFI ou non, il devrait pouvoir être lancé en configurant manuellement l'ordre du boot dans l'UEFI ou ce qui reste du BIOS pour le disque USB en premier. Pas pratique, certes (encore que.. si l'USB n'est pas branché, il devrait chercher le suivant). Mais au moins pour la compréhension et se décontracter un peu, oser faire des essais sur le disque USB ?

Où est la faille dans mon raisonnement ?

Je crois que c'est OK en théorie. Ce qui peut contredire la théorie sont les bugs dans la prise en charge d'UEFI :
  - dans le firmware de l'ordi (bugs grossiers fréquents, semble-t-il) ;
  - dans les logiciels de la distro.

Par exemple, la page du wiki Ubuntu que j'ai indiquée dit que, si l'on a plusieurs disques avec Linux et chacun une partition ESP, il se peut qu'en procédant à une installation sur le deuxième, l'installeur mettent dans /etc/fstab une référence à la partition ESP du disque 1 (montée sur /boot/efi), avec pour conséquence qu'une mise à jour de GRUB dans le second système affecte la config GRUB stockée sur la mauvaise partition ESP (disque 1), config qui va pointer vers le disque 2, et donc foirer si celui-ci est retiré. C'est peut-être déjà corrigé, et a priori ce type d'erreur ne devrait pas empêcher Windows de démarrer, mais voici une complication qui peut éventuellement se produire quand il y a plusieurs partitions ESP dans l'ensemble du sytème.

C'est sans doute pour éviter ce genre de confusion que le wiki Debian dit que l'installeur utilise une partition ESP existante s'il en trouve une. La spec. UEFI est conçue pour que tout cohabite bien, même avec une seule partition ESP ; apparemment, une grosse partie des problèmes vient de ce que certains firmwares ont de gros bugs, n'ont été testés qu'avec un single boot Windows, et que Microsoft en a rajouté en violant la spec. pour que ça marche bien pour son OS même sur les systèmes qui ne devraient pas booter en raison des bugs du firmware. lls se donnent le beau rôle (« Windows se lance sans problème, vous voyez... »), mais en fait, en faisant ça, ils foutent bien la merde. Ça a toujours été comme ça avec eux (écrasement du bootloader MBR sans rien demander... on a ça depuis que Windows existe).

En conclusion, il semble y avoir au moins deux possibilités (autres que la solution de f-toro, qui gagne sans doute la palme de la simplicité) : ou bien une seule partition ESP en tout, ou bien une sur chacun des deux disques. Dans les deux cas, quelques inconnues que l'on ne peut sans doute déterminer que par l'expérience.

GR a écrit :

Le OK fait référence à une installation mint réussie mais utilisant tout le DDE, ce qui est trop car je veux garder sur ce DDE une partition NTFS pour W10, mais cela est il possible ?

Je ne vois pas pourquoi ça ne le serait pas, du moment qu'on respecte les contraintes liées à la ou les partition(s) ESP (cf. lien Ubuntu ci-dessus).

Après, il va y avoir le coup du SecureBoot. Est-il actif chez GR ? Est-ce que le mode lockdown qu'il entraîne va poser problème (apparemment, ça peut se désactiver...) ?

Dernière modification par rominet (23/05/2019 20:42:29)


Debian GNU/Linux, driver libre pour carte Radeon HD 4670, FG 'next', 8 Go de RAM

Hors ligne

#192 23/05/2019 21:03:48

rominet
Membre
Inscription : 23/03/2019
Messages : 61

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Petit complément :

1) Le wiki archLinux (très sérieux en général) suggère pour la partition ESP une taille de l'ordre de 260 MiB (260×2^20 octets). On est loin des 2 MB.

2) Chez Arch Linux, la partition ESP est apparemment montée sur /boot ou /efi, mais chez Debian, c'est /boot/efi comme je l'ai indiqué dans mon message précédent. Comme la disposition selon le standard UEFI des bootloaders situés dans cette partition veut qu'ils soient sous le répertoire \EFI de la partition (par exemple, \EFI\debian\grubx64.efi avec les \ de Windows comme séparateurs [la partition doit être de type FAT32...]), cela donne des chemins du genre /boot/efi/EFI/debian/grubx64.efi une fois la partition montée à l'endroit prévu, comme on le voit ici. C'est sans doute pareil sous Ubuntu et Mint.


Debian GNU/Linux, driver libre pour carte Radeon HD 4670, FG 'next', 8 Go de RAM

Hors ligne

#193 23/05/2019 21:59:18

GR
Membre
Inscription : 28/01/2019
Messages : 173

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonsoir,
Chez moi le Secure Boot est "disabled". Cela devrait donc aider ....

Les prochains tests que j'envisage :
1) Installation mint sur le DDE vierge et ensuite création d'une partition NTFS pour W;
2) Installation mint en dual boot avec W sur un espace "non alloué" de 200 GB crée sur le disque D:\

Dans les deux cas cela devrait coincer quelque part.
Bien cordialement
GR


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#194 23/05/2019 22:08:33

rominet
Membre
Inscription : 23/03/2019
Messages : 61

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

L'idéal pour 1) serait de pouvoir débrancher ton disque Windows le temps de l'installation, mais j'ai cru comprendre que c'est un ordi portable et que ce n'est (donc ?) pas possible ?

Pour SecureBoot : tant mieux, un souci de moins.


Debian GNU/Linux, driver libre pour carte Radeon HD 4670, FG 'next', 8 Go de RAM

Hors ligne

#195 23/05/2019 22:58:01

f-toro
Administrateur
Lieu : LFLA
Inscription : 16/12/2007
Messages : 2 536

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

rominet a écrit :

L'idéal --- serait...

Un poste dédié, sans aucun doute !


André. anciennement taureau89_9
Debian Testing Amd64. CM Sabertooth 990FX, FX8350, 32 Go Ram DDR3 1866 Mhz, GTX 750ti 2Go, DD 2To Sata 3, THRUSTMASTER T.Flight StickX, FG 2019.2.0 Git.

Hors ligne

#196 23/05/2019 23:10:02

GR
Membre
Inscription : 28/01/2019
Messages : 173

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonsoir,
Un détail probablement normal : gparted en session live ne fait pas mention du disque Windows C:\. Le premier disque qu'il mentionne sous /dev/sda est le disque D;\ et ensuite il y a la clé mint et le DDE. Cela m'a un un peu surpris ...
Bien cordialement
GR


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

#197 24/05/2019 0:23:37

ctesc356
Membre
Inscription : 18/05/2010
Messages : 2 795

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonsoir,
https://askubuntu.com/questions/989071/ … -partition
Mais si tu modifies windaube ne boote plus, il aurait fallu le faire avant l'install de win roll

La solution figure dans le lien en rouge, mais ça semble un peu confus. Pas compris... il passe en "legacy bios"? Y compris windows??

Il semblerait que le "Intel RST mode" soit LE must en vitesse d'accès au ssd, assez logique qu'il soit sélectionné. Mais là apparemment il emm... de wink

La rançon du progrès?
Il y a des trucs qu'on ne verra pas sur ma tour no-name wink


Intel i5 3570 3.4Mhz, Nvidia GTX 660, 8Go Ram, Linux Mint

Hors ligne

#198 24/05/2019 0:26:15

rominet
Membre
Inscription : 23/03/2019
Messages : 61

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

J'avais répondu un truc mais je crois que ctesc356 a eu l'œil plus perçant que moi ! roll

Dernière modification par rominet (24/05/2019 0:29:12)


Debian GNU/Linux, driver libre pour carte Radeon HD 4670, FG 'next', 8 Go de RAM

Hors ligne

#199 24/05/2019 7:57:44

ctesc356
Membre
Inscription : 18/05/2010
Messages : 2 795

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonjour,
il serait intérressant de voir si c'est gparted qui est aveugle, ou linux en général.Vois-tu le ssd dans "Disk/Disques" ou dans "Nemo" (gestionnaire de fichiers)
Quel retour de

lsblk -f


Intel i5 3570 3.4Mhz, Nvidia GTX 660, 8Go Ram, Linux Mint

Hors ligne

#200 24/05/2019 8:14:55

GR
Membre
Inscription : 28/01/2019
Messages : 173

Re : [RESOLU]Retour sur le problème d'asymétrie des réponses gouvernes

Bonjour,
Tout ceci me dépasse de plus en plus. Il n'est d'ailleurs même pas sûr que la solution proposée dans le lien de ctesc356 et validée sur un lenovo marche sur mon Alienware, d'autant (dixit ctesc356) qu'elle ne semble pas très claire.

Je sens que mon utilisation de FG se fera avec mon antidiluvien SideWinder ce qui est vraiment dommage et incompréhensible quant on sait que FG est le seul à ne pas accepter le couple (T.16000M TWCS). Je suis primaire et vais donc me repeter : une solution à ce problème est forcément dans FG.

Bien cordialement
GR


Alienware 15R3, W10 Home et lmint 19.2, core i7 6700hq, 32 GB RAM, SSD 512 GB, HDD 1 TB, Nvidia GTX 1060, T16000M et TWCS
FlightGear 2018.3.2 (W10) , 2019.2.0 (lmint) (+ autres simulateurs)

Hors ligne

Pied de page des forums