[RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

Kid1412 · Le 01/10/2017, à 14:36

Bonjour,
j'ai exactement eu le même problème avec mon Thinkpad T440p en voulant installer Ubuntu 16.04 sur un petit SSD M.2 de 64Gb, je vous donne donc ce que j'ai fait pour régler mon problème :
J'ai désactiver le secure boot dans mon BIOS et j'ai sélectionner UEFI Online (UEFI uniquement).

Car avant j’étais a mode "compatibilité" UEFI/Legacy, le problème c'est que Windows est installé en mode "UEFI", mais quand vous lancez l'installation de Ubuntu, vous pouvez très bien être sur l’installation en mode "UEFI" comme celle "Legacy" lorsque vous voulez booter.
Du coup, cela provoque une incompatibilité sur la partition de démarrage une fois installer (GRUB comme Windows), quand j’étaie en mode UEFI/Legacy ou UEFI Online je pouvais lancer Windows, mais pas Ubuntu, par contre en mode Legacy je pouvais plus lancer Windows, mais je pouvais lancer Ubuntu (c'est la que j'ai compris).
J'ai donc mis mon BIOS sur UEFI Online (UEFI uniquement) et j'ai redémarrer avec un live d'Ubuntu, j'ai ensuite fait une "restauration" de Grub et la il m'a changer le système de boot habituel (MBR) par celui de l'UEFI.

Si votre Ubuntu est vide, vous pouvez simplement relancer l'installation de Ubuntu et remettre a zéro le SSD en question, mais en étant en mode UEFI "online".

En espérant que cela vous aide un peut.

Dernière modification par Kid1412 (Le 01/10/2017, à 14:40)

Satire · Le 01/10/2017, à 15:44

Bonjour Babdu89,
Merci beaucoup pour cette pédagogique explication, ce fut d'une très grande aide.

J'ai donc bien démarré l'ordinateur en mode "recovery" tel qu'expliqué, et par la suite accédé à Ubuntu après avoir entré mon mot de passe. J'ai accepté une demande de mise à jour par la suite. Cependant, lors du redémarrage, j'ai eu exactement le même problème, avec l'écran qui se fige et son blocage...

Il semble que l'on y est presque ! mais que faire maintenant pour que je puisse redémarrer normalement sur mon Ubuntu ?

Babdu89 · Le 01/10/2017, à 16:51

Il semble que l'on y est presque ! mais que faire maintenant pour que je puisse redémarrer normalement sur mon Ubuntu ?

On va essayer de passer une options au noyau pour démarrer.

https://doc.ubuntu-fr.org/kernel#modifi … ssion-live

Comme tu as redémarré en mode recovery; l'option "nomodeset" est passée au noyau.
On voit çà dans le boot info.
Dans les options avancées, ligne 348 et suivantes, on lit ceci;

menuentry 'Ubuntu, with Linux 4.10.0-22-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.10.0-22-generic-recovery-1da45db3-0327-473f-b917-9c0cbce90a4e' {
recordfail
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos6'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6 1da45db3-0327-473f-b917-9c0cbce90a4e
else
search --no-floppy --fs-uuid --set=root 1da45db3-0327-473f-b917-9c0cbce90a4e
fi
echo 'Chargement de Linux 4.10.0-22-generic…'
linux /boot/vmlinuz-4.10.0-22-generic root=UUID=1da45db3-0327-473f-b917-9c0cbce90a4e ro recovery nomodeset
echo 'Chargement du disque mémoire initial…'
initrd /boot/initrd.img-4.10.0-22-generic
}

Je pense que c'est avec cette ligne recovery que tu as pu démarrer.

Donc on va faire une chose que l'on ne doit pas faire, modifier le fichier de configuration grub.cfg de ton Ubuntu manuellement, pour ajouter cette option dans l'entrée (menuentry) ; Ubuntu , qui s'affiche au menu Grub.

On ne doit pas modifier manuellement le contenu du fichier grub.cfg, car il est auto-généré à chaque mise à jour de Grub. Mais bon, il faut bien que l'on puisse démarrer, pour ensuite pérenniser la modif.

Alors redémarrage en mode Bios_Legacy, en passant par les Options avancées pour Ubuntu.
Choisir la ligne du noyau qui démarre en mode recovery, et lancer un session de Ubuntu.

Ouvrir en admin le fichier grub.cfg de ton Ubuntu;

sudo gedit /boot/grub/grub.cfg

Regarder dans la rubrique;

### BEGIN /etc/grub.d/10_linux ###

Et aller jusque la première entrée (menuentry)

export linux_gfx_mode
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-1da45db3-0327-473f-b917-9c0cbce90a4e' {
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos6'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6 1da45db3-0327-473f-b917-9c0cbce90a4e
else
search --no-floppy --fs-uuid --set=root 1da45db3-0327-473f-b917-9c0cbce90a4e
fi
linux /boot/vmlinuz-4.10.0-22-generic root=UUID=1da45db3-0327-473f-b917-9c0cbce90a4e ro quiet splash $vt_handoff
initrd /boot/initrd.img-4.10.0-22-generic
}

On ajoute l'option nomodeset en gras comme ci-dessous;

export linux_gfx_mode
menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-1da45db3-0327-473f-b917-9c0cbce90a4e' {
recordfail
load_video
gfxmode $linux_gfx_mode
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_msdos
insmod ext2
set root='hd0,msdos6'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos6 --hint-efi=hd0,msdos6 --hint-baremetal=ahci0,msdos6 1da45db3-0327-473f-b917-9c0cbce90a4e
else
search --no-floppy --fs-uuid --set=root 1da45db3-0327-473f-b917-9c0cbce90a4e
fi
linux /boot/vmlinuz-4.10.0-22-generic root=UUID=1da45db3-0327-473f-b917-9c0cbce90a4e ro nomodeset quiet splash $vt_handoff
initrd /boot/initrd.img-4.10.0-22-generic
}

Enregistrer, et redémarrer pour dire si ton Ubuntu démarre sans bidouiller.

Si c'est le cas, on va pérenniser la manip.

@+. Babdu89 .

Babdu89 · Le 01/10/2017, à 17:09

Pérenniser la manip.

Ton Ubuntu démarre. On Va ajouter l'option "nomodeset" dans un fichier de configuration de Grub.
Puis faire une mise à jour de Grub.

Ouverture du fichier de configuration de Grub (/etc/default/grub) en admin.

sudo gedit /etc/default/grub

On va modifier la ligne;

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

en gras;

GRUB_CMDLINE_LINUX_DEFAULT="nomodeset"

Enregistrer, fermer. Puis on fait la mise à jour de Grub, pour que la modif soit prise en compte définitivement dans le fichier grub.cfg ;

sudo update-grub

Bon, je pense que voila un Ubuntu qui démarre enfin normalment.

Il n'y a pas de magie la dedans, c'est expliqué ici.

https://doc.ubuntu-fr.org/kernel#modifi … sur_disque

Alors si çà marche, on va voir pour la sauvegarde du /home de ton Ubuntu sur le hdd externe.

@+. Babdu89 .

Satire · Le 01/10/2017, à 19:13

Bonsoir Babdu89,
J'ai tenté la manipulation. Si cela permet effectivement de démarrer directement sur Ubuntu, sans le blocage avec l'écran qui se fige, cela ralenti à l'extrême l'ordinateur, le curseur, l'ouverture des fenêtres, les clics... je suis donc revenu à l'état initial.
Y-aurait-il une solution alternative ?
Merci.

Dernière modification par Satire (Le 01/10/2017, à 19:36)

Babdu89 · Le 01/10/2017, à 20:24

Bonsoir.

Tu as fais les manips des posts#28 et 29?.

@+. Babdu89 .

Satire · Le 01/10/2017, à 22:11

Bonsoir Babdu89,
Oui, tout à fait, j'ai fait les manipulations des posts#28 et 29. J'ai d'ailleurs remarqué que je n'avais pas exactement les lignes dans mon fichier grub.

J'ai d'abord rajouter "nomodeset" ici :

linux	/boot/vmlinuz-4.10.0-35-generic root=UUID=1da45db3-0327-473f-b917-9c0cbce90a4e ro  quiet splash $vt_handoff

Dans ce cas, Ubuntu a effectivement redémarré, mais avec le problème expliqué dans le post #30.

Puis, ici :

linux	/boot/vmlinuz-4.10.0-22-generic root=UUID=1da45db3-0327-473f-b917-9c0cbce90a4e ro  quiet splash $vt_handoff

Dans ce cas, Ubuntu n'a pas redémarré, et l'écran s'est figé comme décrit précédemment...

Est-ce que c'est bizarre ?

Babdu89 · Le 01/10/2017, à 23:28

Alors, lorsque tu as redémarré en mode recovery, je suppose sur le noyau 4.10.0-22, qui t'a permis de faire les mises à jour système. Ubuntu fonctionnait normalement?

Dans les options avancées pour Ubuntu. Teste ceci pour voir, démarre en mode recovery sur le noyau 4.10.0-35, et dis ce qu'il se passe.

Tu peux aussi si çà fonctionne normalement. Installer Boot-Repair dans ton Ubuntu, réinstaller Grub en passant par les "Options avancées" dans l'onglet "Options de Grub dans "Ajouter une option au noyau" indiquer ; nomodeset

https://doc.ubuntu-fr.org/kernel#modifi … sur_disque

@+. Babdu89 .

Dernière modification par Babdu89 (Le 01/10/2017, à 23:30)

Satire · Le 03/10/2017, à 17:48

Bonjour Babdu89,
Désolé de ce retard, dû à un petit contre-temps...

Alors, j'ai en réalité toujours démarré sur le noyau 4.10.0-35. Et effectivement, Ubuntu a toujours fonctionné normalement dans ce cas.

Je n'ai pas encore tenté la suggestion relative à l'installation du Boot-Repair, mais entre-temps, j'ai copié les fichiers de mon disque SSD Ubuntu vers deux clés usb (je me suis rendu compte, par la suite, qu'en fait mon disque dur externe était déjà plein...).

Penses-tu que l'on puisse tenter la manipulation pour le dual boot Windows / Ubuntu maintenant ?

PS: je suppose que tu as pris connaissance du post #26 de Kid1412 (que je remercie au passage de sa contribution et de son aide, et m'excuse de ne pas l'avoir fait précédemment), et dont je ne suis pas sûr d'avoir bien compris la totalité de la procédure décrite...

Kid1412 · Le 03/10/2017, à 21:08

Bonjour Satire,
en effet, ce que je cite peut être un peut compliquer, en gros, a l'heure actuel, sur PC, on est en période de "transition", avant les PC possédais un BIOS ( https://fr.wikipedia.org/wiki/Basic_Input_Output_System ) et maintenant les PC on un UEFI ( https://fr.wikipedia.org/wiki/Unified_E … _Interface ), je te laisse lire les pages Wiki si sa t'intéresse.

Comme nous somme en période de transition, les systèmes d’exploitation, aussi bien Linux comme Windows, peuvent être installer avec le nouveau "mode" ou avec l'ancien "mode" (c'est pas vraiment un mode, mais plutôt une manière de comment le système est démarré/géré en gros), mais ces 2 "mode" ne son pas "compatible entre eux" et comme les PC peuvent géré les 2 "mode" pour être compatible (vue qu'on est en période de transition), sa fout un peut le chantier.

Je te passe 2 capture d’écran que j'ai trouver sur Google image, cela peut te permettre de te repéré plus facilement pour savoir si tu lance ton cd/dvd (ou cle usb) en mode "Lagency", ou en mode UEFI.
Si tu a cette page de démarrage, cela veux dire que tu est en mode Lagency (BIOS) : https://doc.ubuntu-fr.org/_media/instal … tok=2d76f9
Par contre, si tu a cette page : https://doc.ubuntu-fr.org/lib/exe/fetch … 270133.png
cela veux dire que Ubuntu est lancé en mode UEFI.

Pour ma part, cela a été facile pour moi, même si au début je ne comprenais pas pourquoi cela ne fonctionnais pas, car j'ai pour habitude de prendre mes "précautions", du coup, lorsque j'ai installer Ubuntu, j'avais retirer mon SSD primaire ou j'avais Win10 pour pouvoir installer Ubuntu sans craindre quoique ce soit, ensuite, lorsque j'ai remis mon disque primaire, j'ai démarrer depuis mon 2eme SSD (celui ou j'ai installé Ubuntu), Ubuntu a directement détecter mon Win10.

Voici aussi comment j'ai "réparer/convertie" mon installation d'Ubuntu qui s’était installer en Lagency, alors que je devais l'installer en UEFI pour être compatible avec mon Windows : https://doc.ubuntu-fr.org/boot-repair
En espérant ne pas dire de choses trop vulgariser.

Babdu89 · Le 03/10/2017, à 23:12

Bonsoir.

PS: je suppose que tu as pris connaissance du post #26 de Kid1412 (que je remercie au passage de sa contribution et de son aide, et m'excuse de ne pas l'avoir fait précédemment), et dont je ne suis pas sûr d'avoir bien compris la totalité de la procédure décrite...

Kid1412 ne fait autre qu'expliquer ce qu'il a fait, et qui correspond à ce que je dit post#9 de ce sujet. Il a tout réinstallé en UEFI.

@+. Babdu89 .

Babdu89 · Le 03/10/2017, à 23:48

Penses-tu que l'on puisse tenter la manipulation pour le dual boot Windows / Ubuntu maintenant ?

Ce qui me gène, c'est le fait que le deuxième disque ne soit pas vu, lorsque la machine démarre en mode UEFI.

La manip va consister, à démarrer la machine en session live avec une clé live contenant l'iso du système que tu veux réinstaller en mode UEFI. Et si le disque n'est pas encore vu, on fait quoi?.

Normalement voila ce qu'il faudrait faire.
Les deux disques branchés.
Démarrer en session live en mode UEFI, SecureBoot désactivé.
Sur le deuxième SSD, si il est vu.
Avec Gparted. Suppression de toutes les partitions.
Réécriture d'une table de partition de type GPT.
Préparation des partitions d'installation;
Minimum; Une partition format ext4 pour le système + Une partition swap.
L'installation de Grub-efi devra se faire sur la partition Boot-efi du disque où est Windows. (/dev/nvme0n1p1: LABEL="ESP").
La machine devra redémarre sur le disque où est Windows.

Démarrer la machine en mode UEFI, SecureBoot désactivé. Démarrer en session live.
Sur le deuxième SSD, si il est vu.

Si il n'est pas vu, on peut démarrer en session live en mode Bios_Legacy, pour utiliser Gparted pour la préparation du disque.
Redémarrage en mode UEFI SecureBoot désactivé. Le disque sera vu, ou pas???.
Si il l'est. On continue.
Si il n'est pas vu, on est coincé, on ne peut pas réinstaller en UEFI...

Alors avant de te faire faire des bêtises (perte de ton Ubuntu installé) J'aimerai bien avoir l'avis de contributeurs qui suivent le sujet...

@+. Babdu89 .

Satire · Le 04/10/2017, à 21:05

Bonjour Babdu89,
Merci de cette schématique explication. Cela semble effectivement assez délicat comme manipulation. J'espère que d'autres contributeurs vont en effet pouvoir venir apporter leur savoir à ce propos...

Merci pour l'éclaircissement par rapport à ce qu'a pu poster Kid1412, j'étais effectivement loin de m'en avoir aperçu...

Et merci Kid1412 pour l'explication pédagogique, c'est effectivement un peu plus clair maintenant, notamment par rapport à cette période de transition qui permet de comprendre pas mal de choses. Les captures d'écran sont à ce propos assez efficace pour visualiser concrêtement les différences graphiques...

En espérant que l'aide ne s'arrêtera pas en si bon chemin...

Merci d'avance.

Dernière modification par Satire (Le 04/10/2017, à 21:06)

Babdu89 · Le 04/10/2017, à 21:38

Bonsoir.

Oui, ce qui me gène beaucoup c'est que le SSD où est Ubuntu ne soit pas vu en démarrant en live, en mode UEFI.
Ce disque avec table de partition de type MSDos, Un Ubuntu installé en mode Bios_Legacy.

Je réponds depuis une machine avec une installation en UEFI de tests sur clé USB avec table de partition de type GPT.
Le disque interne de la machine est avec une table de partition de type MSDos, Un Windows et un Ubuntu sont installés en mode Bios_Legacy.
Depuis la session UEFI, je vois le disque interne, le Windows et le Ubuntu, installé en Bios_Legacy. j'ai accès aux données. Bon, normal, ces systèmes ne démarrent pas en UEFI, bien que présents au menu Grub à jour, de l'installation de tests démarrée en UEFI.

Le souci chez toi; Il faut arriver à déterminer si çà vient de la machine, ou du disque ?.
Et là de l'aide serait la bien venue...

@+. Babdu89 .

Dernière modification par Babdu89 (Le 05/10/2017, à 08:24)

Kid1412 · Le 05/10/2017, à 21:37

Bonjour,
d’après vos posts, le SSD ou Ubuntu est installé n'est pas détecter quand il est en "mode" UEFI ?
Si je me souviens bien, les disques avec une partition de démarrage "Legacy" (MBR) ne sont pas détecter car l'UEFI cherche uniquement les partitions qu'il peut amorcé (GPT si je me dit pas de bêtise), par contre, cela n’affecte pas la lecture des données, je parle bien que quand on doit démarrer un système d'exploitation.

(Pour bien comprendre la "gestion démarrage" Ubuntu/Windows en multi boot j'avais utiliser ce lien : https://doc.ubuntu-fr.org/tutoriel/comm … ropre_2_dd
Du coup on vois que si je retire mon SSD ou Ubuntu est installer, la partition de démarrage de Windows est de nouveau utiliser.
Le schéma montre bien pourquoi les 2 disques/OS doivent etre MBR ou GPT tout les 2, pour pouvoir communiquer ensemble.)

Je viens de regarder sur la doc Ubuntu a propos des partions GPT ( https://doc.ubuntu-fr.org/gpt ) et voici quelque choses d'intéressant :

Si votre disque GPT ne possède pas de partition UEFI et que vous bootez en UEFI pour installer ubuntu, à l'issue de l'installation vous devrez modifier le bios pour booter en legacy car une installation legacy aura été faite.

Le plus simple sinon serais de faire comme j'ai fait :
Es que vous vous trouvez dans le même cas que moi ? :
-mon Ubuntu ne possédé aucune donnée car il viens juste d’être installer
-J'ai Windows d'installer sur un SSD ou un HDD
-J'ai Ubuntu d'installer sur un 2eme SSD ou 2eme HDD

Si c'est le cas, ne vous embêtez pas, faite comme moi :
1 - Retiré le Disque Windows du pc
2 - Configurer le BIOS/UEFI en UEFI Online
3 - Lancer l'installation d'Ubuntu en mode UEFI et remplacer tout simplement le système déjà installer

Une fois installer, démarrez 2-3 fois le pc tel quel pour voir si tout fonctionne comme il faut, si c'est le cas, remettre le disque ou Windows est installé dessus et bien démarrer sur le 2eme disque, celui ou Ubuntu est installé.
Si tout ce passe bien, après 1 ou 2 redémarrage, Ubuntu détectera Windows et le proposera au démarrage.

Dernière modification par Kid1412 (Le 05/10/2017, à 21:38)

Babdu89 · Le 05/10/2017, à 22:37

Bonsoir.

Kid1412 a écrit;

d’après vos posts, le SSD ou Ubuntu est installé n'est pas détecter quand il est en "mode" UEFI ?
Si je me souviens bien, les disques avec une partition de démarrage "Legacy" (MBR) ne sont pas détecter car l'UEFI cherche uniquement les partitions qu'il peut amorcé (GPT si je me dit pas de bêtise), par contre, cela n’affecte pas la lecture des données, je parle bien que quand on doit démarrer un système d'exploitation.

Non,non!.
On voit souvent le type d'installation comme ceci.
Machine démarrant en mode UEFI
Un disque GPT avec un Windows ou Ubuntu (ou les deux) installé en UEFI.
Un disque MSDos avec un Ubuntu installé en Bios_Legacy.

La machine démarrant en mode UEFI. Le disque MSDos et le Ubuntu installé dedans sont vu par l'Os Linux installé en UEFI sur le disque GPT. Mais il ne démarre pas en mode UEFI. Il ne peut démarrer qu'en mode Bios Legacy.
Pour le Ubuntu du disque en MSDos. Être vu en mode UEFI, permet depuis une session live de refaire l'installation d'un Ubuntu en mode UEFI.

Chez moi.
Un SSD en MSDos avec un Ubuntu en Bios_Legacy /dev/sda2 ('hd0,msdo2')
Un hdd GPT avec un Ubuntu en UEFI en /dev/sdb3 ('hd0,gpt3')

Machine démarrée en UEFI. sur le Ubuntu en UEFI /dev/sdb3

=================== UEFI/Legacy mode:
BIOS is EFI-compatible, and is setup in EFI-mode for this installed-session.
SecureBoot enabled.

Extrai du fichier grub.cfg /dev/sdb3 , grub à jour.
Le Ubuntu en UEFI en /sdb3 ('hd2,gpt3')

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-72a66c99-76c9-420b-b133-77d8811a67f5' {
	recordfail
	load_video
	gfxmode $linux_gfx_mode
	insmod gzio
	insmod part_gpt
	insmod ext2
	set root='hd2,gpt3'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt3 --hint-efi=hd2,gpt3 --hint-baremetal=ahci2,gpt3  72a66c99-76c9-420b-b133-77d8811a67f5
	else
	  search --no-floppy --fs-uuid --set=root 72a66c99-76c9-420b-b133-77d8811a67f5
	fi
	linux	/boot/vmlinuz-3.13.0-117-generic.efi.signed root=UUID=72a66c99-76c9-420b-b133-77d8811a67f5 ro  quiet splash $vt_handoff
	initrd	/boot/initrd.img-3.13.0-117-generic
}

Le Ubuntu du SSD en MSDos en /sda2 ('hd0,msdos2')

### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Ubuntu 14.04.5 LTS (14.04) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-5fd212d2-52f8-4db7-9b9f-3bdda68eb53b' {
	insmod part_msdos
	insmod ext2
	set root='hd0,msdos2'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2  5fd212d2-52f8-4db7-9b9f-3bdda68eb53b
	else
	  search --no-floppy --fs-uuid --set=root 5fd212d2-52f8-4db7-9b9f-3bdda68eb53b
	fi
	linux /boot/vmlinuz-3.13.0-119-generic root=UUID=5fd212d2-52f8-4db7-9b9f-3bdda68eb53b ro quiet splash $vt_handoff
	initrd /boot/initrd.img-3.13.0-119-generic
}

Donc en UEFI, un disque MSDos dans la config, est vu depuis un Os installé en UEFI, machine lancée en mode UEFI.

Le Ubuntu en /dev/sda2 ne peut démarrer qu'en mode Bios_Legacy, bien qu'il soit vu en mode UEFI.

Le souci de Satire, c'est que son disque MSDos n'est pas vu, la machine démarrant en session live en mode UEFI. On ne peut donc pas refaire l'installation, en mode UEFI.

@+. Babdu89 .

Dernière modification par Babdu89 (Le 05/10/2017, à 23:53)

Babdu89 · Le 05/10/2017, à 22:46

Kid1412 a écrit;

Le plus simple sinon serais de faire comme j'ai fait :
Es que vous vous trouvez dans le même cas que moi ? :
-mon Ubuntu ne possédé aucune donnée car il viens juste d’être installer
-J'ai Windows d'installer sur un SSD ou un HDD
-J'ai Ubuntu d'installer sur un 2eme SSD ou 2eme HDD
Si c'est le cas, ne vous embêtez pas, faite comme moi :
1 - Retiré le Disque Windows du pc
2 - Configurer le BIOS/UEFI en UEFI Online
3 - Lancer l'installation d'Ubuntu en mode UEFI et remplacer tout simplement le système déjà installer

Tu viens de me donner une idée...

@Satire.

Machine à l'arrêt, débrancher la connectique (alim + connecteur SATA) du SSD Où est Windows.
Le SSD où est Ubuntu doit resté branché et connecté.
Démarrer la machine en mode UEFI, SecureBoot désactivé, en session live Ubuntu.
Faire un Boot-info pour que l'on sache si le disque où est le Ubuntu est vu.

@. Babdu89 .

Dernière modification par Babdu89 (Le 05/10/2017, à 23:54)

Kid1412 · Le 06/10/2017, à 18:15

Babdu89, ok, je vois le problème.

Je me souviens que c’était infernal avec ces pb de partition MBR/GTP UEFI ect !
la dernière fois je ne me suis pas embêter, j'ai utiliser dban (Darik's Boot and Nuke) pour remettre a zéro le disque (juste le fait de lancé et d'atteindre les 0,1% devrais suffire), cela permet en gros de supprimer que la table des partitions/secteur d’amorçage et ainsi, lorsque l'on relance l'installation, le disque est détecter comme "neuf", du coup il est prêt a être de nouveau installer, que ce soit en UEFI ou pas.

Es une solution a envisager dans son cas ? (pas de pertes de donnée ect)

Dernière modification par Kid1412 (Le 06/10/2017, à 18:18)

Babdu89 · Le 06/10/2017, à 20:32

Bonsoir.

Kid1412aécrit.

Es une solution a envisager dans son cas ? (pas de pertes de donnée ect)

Attendons une réponse au post#42...

@+. Babdu89 .

Satire · Le 07/10/2017, à 00:57

Bonsoir Babdu89 et Kid1412,
Je suis désolé de ce message tardif, mais je fus en pleine préparation d'un voyage qui va durer trois semaines et dont le départ est demain...

Par conséquent, je n'ai pas encore eu le temps de réaliser la manipulation mentionnée au post #42. Je vais avoir un accès internet limité et par intermittance, mais je vais tout faire pour l'effectuer à la première occasion... d'autant plus que cette situation est elle-même handicapante pour moi... au plus tard, ce serait fait à mon retour...

Un GRAND merci pour votre précieuse aide et soutien,

A très vite le retour !

Satire · Le 08/11/2017, à 22:50

Bonsoir Babdu89 et Kid1412,
Je suis de retour ! je suis désolé de cette étendue absence... plus longue que prévue...

Alors, depuis la dernière fois, j'ai mis à niveau mon ubuntu et suis passé à la version Ubuntu 17.10.

Changemnet intéressant, c'est que désormais, mon Ubuntu démarre automatiquement, sans aucun bug et donc sans avoir besoin de démarrer en mode sans échec comme j'en avais pris l'habitude de faire auparavant.

Cependant, depuis le passage à Ubuntu 17.10, impossible d'éteindre mon ordinateur normalement en cliquant sur "éteindre", je suis obligé de le forcer à s'éteindre avec un appui prolongé sur le bouton démarrer/éteindre de mon ordinateur...

J'ai voulu vous rendre compte de cela avant de procéder à la manipulation du post #42.

Merci d'avance pour vos précieux conseils.

Satire · Le 11/11/2017, à 13:22

Bonjour à toutes et à tous,
Dans la continuation de la précieuse aide et du support apporté par Babdu89 et Kid1412, je souhaitais ici récapituler la situation, dans le but de clarifier l'état dans lequel mon ordinateur se trouve.

Alors, mon ordiniteur Dell XPS 15 (9950) possède à l'origine un SSD avec le système d'exploitation Windows 10. J'ai profité de ce modèle d'ordinateur pour pouvoir ajouter un second disque dur interne SSD sur lequel j'ai Ubuntu.

Mon but c'est d'une part pouvoir avoir un dual boot Ubuntu/Windows 10, à partir de ces deux disques durs, et d'autre part pouvoir accéder à mon SSD Ubuntu à partir de Windows 10.

Grace à l'aide et aux conseils de Babdu89, j'ai pu faire démarrer mon ordinateur automatiquement sur mon SSD Ubuntu en modifiant mon mode de démarrage en sélectionnant Bios_Legacy.

En raison d'un voyage, je n'ai pas pu procéder à la manipulation de Babdu89 mentionné au post #42. Et entretemps, j'ai mis à niveau mon Ubuntu 17.04 vers Ubuntu 17.10, ce qui a permit à Ubuntu de démarrer normalement, sans devoir passer par le mode sans échèc (tel qu'expliqué au post #46).

Par avance, un immense merci pour toute personne qui serait susceptible de pouvoir m'aider.

Dernière modification par Satire (Le 11/11/2017, à 13:23)

Babdu89 · Le 11/11/2017, à 13:45

Bonjour.
Satir a écrit;

Cependant, depuis le passage à Ubuntu 17.10, impossible d'éteindre mon ordinateur normalement en cliquant sur "éteindre", je suis obligé de le forcer à s'éteindre avec un appui prolongé sur le bouton démarrer/éteindre de mon ordinateur...

Alors, maintenant si la machine démarre sur l'Os Linux sans avoir recours aux "artifices" expliqués plus-haut. Mais qu'elle ne veut plus s'arrêter autrement qu'avec le bouton marche/arrêt.
Veut tu bien ouvrir un nouveau sujet pour ce nouveau problème, en donnant un lien vers celui-ci.

@+. Babdu89 .

Satire · Le 11/11/2017, à 14:02

Salut Babdu89,
Ravi de te retrouver !

Le sujet vient juste d'être créé ici : https://forum.ubuntu-fr.org/viewtopic.p … #p21823805

Merci beaucoup.

Satire · Le 13/11/2017, à 20:18

Bonsoir Babdu89,
Je voulais savoir, ce problème de ne plus pouvoir éteindre normalement mon ordinateur, est-il vraiment nécessaire de le résoudre avant de s'attaquer au problème principal du dual boot Ubuntu/Windows ?

Je pose cette question, car il me semblait que cela n'était pas très grave et n'entraverait pas les manipulations liées à la mise en place du dual boot Ubuntu/Windows ?

Mais comme tu le sais, mes connaissances informatiques sont tellement basiques, que je pose cette question en simple novice...

Merci encore.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 01/10/2017, à 14:36

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#27 Le 01/10/2017, à 15:44

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#28 Le 01/10/2017, à 16:51

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#29 Le 01/10/2017, à 17:09

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#30 Le 01/10/2017, à 19:13

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#31 Le 01/10/2017, à 20:24

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#32 Le 01/10/2017, à 22:11

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#33 Le 01/10/2017, à 23:28

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#34 Le 03/10/2017, à 17:48

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#35 Le 03/10/2017, à 21:08

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#36 Le 03/10/2017, à 23:12

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#37 Le 03/10/2017, à 23:48

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#38 Le 04/10/2017, à 21:05

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#39 Le 04/10/2017, à 21:38

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#40 Le 05/10/2017, à 21:37

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#41 Le 05/10/2017, à 22:37

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#42 Le 05/10/2017, à 22:46

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#43 Le 06/10/2017, à 18:15

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#44 Le 06/10/2017, à 20:32

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#45 Le 07/10/2017, à 00:57

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#46 Le 08/11/2017, à 22:50

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#47 Le 11/11/2017, à 13:22

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#48 Le 11/11/2017, à 13:45

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#49 Le 11/11/2017, à 14:02

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

#50 Le 13/11/2017, à 20:18

Re : [RésoIu] Installer un Dual boot Windows10/Ubuntu sur un XPS 15 à 2 SSD

Pied de page des forums