Installation Debian Dual boot avec windows 10

Bonjour,

Il existe déjà plusieurs posts avec ce sujet mais aucun ne fait référence aux problèmes que je rencontre. Aussi, je me permets d’ouvrir un nouveau post sur le sujet du dualboot !

Mon objectif :

  • installer debian 11 en dual boot avec windows 10 (qui est déjà installé).

Caractéristiques pc :

  • Dell 5420 Rugged / 64 bits / 32Go RAM
  • HD SSD 1 To / Partition GUID (GPT)
  • Le bios et les drivers sont tous à jour
  • J’ai partitionné mon HD pour réserver une place de 50 Go à Debian

Symptôme / problème :

  • je dois passer le Bios en Legacy (vs initialement en UEFI) sinon, durant l’installation, les disques/partitions, ne sont pas détectés (en UEFI, seule la clef USB avec l’iso est détectée).
  • durant le processus d’installation, juste après avoir choisi Graphical Installation, j’ai le message d’erreur suivant :

Debian_screenshot-1_during-installation

  • une fois l’installation faite,
    • je repasse le bios en UEFI
    • j’ai les messages d’erreur suivants :

Debian_screenshot-2_after-installation

  • Sur la BusyBox

    (initramfs) ls
    $> bin conf dev etc init lib lib32 lib64 libx32 proc root run sbin scripts sys tmp usr var

Déjà, il manque des directories… Mauvais signe.

(initramfs) dmesg

Trop long pour être retranscrit ici.

(initramfs) dmesg > /tmp/outputdmesg.txt

Je branche une clef usb

(initramfs) mkdir -p /media/usb
(initramfs) chmod 777 /media/usb 
(initramfs) mount /dev/sda/ /media/usb
$> mount : mounting /dev/sda on /media/usb failed:No such file or directory

Du coup, je suis bloqué.

Je n’ai sais pas comment faire un diagnostic complet et sérieux ; les outils/commandes que je connais pour ça et qui fonctionnent habituellement, ne répondent pas dans le cas présent.

Ca vient très certainement de mon PC mais comme il est à jour, je ne sais plus quoi faire.

  • j’ai téléchargé 2 iso différents (debian-11.2.0-amd64-DVD-1.iso et firmware-11.2.0-amd64-netinst.iso), j’ai vérifié à chaque fois la sumsha256, j’ai utilisé Etcher et Rufus, j’ai utilisé 2 clefs USB différentes
  • J’ai recherché sur le Net, je n’ai trouvé aucune solution probante.
  • j’ai essayé avec la distribution kali, j’ai eu exactement les mêmes problèmes.

Avez-vous déjà rencontré ce type de problème ?
Merci de votre aide !

Salut,

Personnellement j’ai installé Debian en uefi mais ai désactivé le SecureBoot.
Legacy = table de partitions type ms-dos
Uefi = table de partitions en gpt
Normal que ça crée des problèmes

Dd fonctionne très bien pour coller une iso Debian sur une clé usb:

# dd if=/chemin/vers/ton/iso/debian of=/dev/sd[b/c/d... selon comment est détectée ta clé, pas de chiffre après] bs=4M;sync

Et écris ma poule (ben oui ça roule pas un pc ou alors pas longtemps :grinning_face_with_smiling_eyes: )

C’est pingre.

L’installation en mode legacy va affecter le dual boot : il ne sera pas possible de lancer Windows depuis GRUB, il faudra démarrer en mode EFI depuis le BIOS pour lancer Windows ou démarrer en mode legacy pour lancer GRUB/Debian.

Quel est le type de SSD : SATA/AHCI ou NVMe ?
Il peut y avoir une incompatibilité entre Linux et le mode RAID de certains contrôleurs SATA Intel (même pour un SSD NVMe qui n’a a priori rien à voir avec le SATA).

Les message d’erreur ACPI sont généralement sant gravité quand ils ne se répètent pas indéfiniment et ne bloquent pas le démarrage.

L’entrée dans le shell de l’initramfs est du au fait que l’initramfs n’a pas trouvé la racine du système (après ne pas avoir trouvé le swap pour l’hibernation, qui n’est pas bloquant). On peut soupçonner que c’est le SSD entier qui n’est pas correctement détecté.

L’initramfs n’est pas le système complet, c’est un système mininmal qui a pour fonction de faire la reprise après hibernation ou monter la racine qui contient le système complet. Les répertoires manquants comme /boot, /home, /media, /mnt ou /srv n’y ont aucune utilité.

Inutile. Les permissions d’un point de montage ne comptent pas. Ce sont les permissions de la racine du système de fichiers monté qui comptent.

  1. Il faut vérifier que la clé USB est bien détectée comme /dev/sda et pas autre chose.
  2. Si la clé USB a une table de partition (ce qui est fréquent), il faut monter la partition, pas la clé entière.
  3. Quel est le système de fichiers de la clé USB ? L’initramfs ne supporte pas les systèmes de fichiers FAT ou exFAT par défaut. On peut supposer que son but étant de monter la racine et une racine ne pouvant pas être en FAT, il n’y a pas lieu de supporter ce format. Bizarrement il support NTFS. Pour information par défaut il supporte Btrfs, Ext*, JFS, UDF, F2F2, UFS, ReiserFS et XFS.
  4. La commande mount de busybox ne sait pas toujours détecter le type de système de fichiers, il faut le spécifier avec l’option -t.

Dans un premier temps tu peux filtrer la sortie de dmesg pour ne retenir que les messages contenant nvme (si SSD NVMe), scsi|sd|ata|ahci (si SSD SATA/AHCI).

La sortie de la commande lspci -k est aussi utile pour voir comment le contrôleur SATA et/ou le SSD NVMe sont détectés et gérés. Ça vaudrait aussi le coupe de faire ces actions dans l’installateur en mode EFI et en mode legacy (et lui supporte FAT).

En fait, je passe en Legacy seulement pour l’installation. Sinon, les partitions ne sont pas détectées.
Ensuite, je repasse en UEFI. J’ai précisé ce point dans le post d’origine.

NVMe. Plus précisément, c’est un PM981 NVMe Samsung 1024 GB.
Je vais préciser ce point dans le post d’origine.

Je viens de monter à 150.

J’ai reformaté l’usb en ntfs et j’ai forcé un systeme de partition GPT (vs MBR).
Ca fonctionne !

Un grand grand merci ! J’ai pu récupérer le contenu de dmesg !*
J’essaye de regarder ça tout seul dans un premier temps. Je reviendrais éventuellement vers vous le cas échéant.

ça ne fonctionne pas. J’ia le message d’erreur suivant :
$> sh: lspci: not found

Voilà. Encore merci. Je vais bosser cette nuit !

Non. Les spécifications UEFI supportent explicitement le format MS-DOS et les spécifications du BIOS se fichent éperdument du type de table de partition du moment que le format du MBR est respecté (ce qui est le cas du MBR protecteur de GPT).

Non, ce n’est pas normal que ça crée des problèmes. Cela ne crée des problèmes qu’avec les firmwares BIOS/UEFI déficients (qui sont certes nombreux).

Sauf que tu ne peux pas passer en legacy « juste pour l’installation » car cela affecte la façon dont le chargeur d’amorçage GRUB est installé et devra être amorcé.

Un système installé en mode legacy ne peut pas booter en mode EFI.

Au temps pour moi, lspci n’est pas inclus par défaut dans l’initramfs. En revanche il l’est dans l’installateur.

Pour le problème, je souçonne que ça vient du mode du contrôleur SATA configuré dans le BIOS, qui doit être en AHCI pour être compatible avec Linux. C’est bizarre mais apparemment ça peut affecter Linux différemment selon qu’on amorce en mode EFI ou legacy.

1 J'aime

Super ! Bravo ! Un grand grand merci ! C’était ça !

Windows était mal installé depuis le début. Du coup, par défaut, j’avais le controleur SATA en « Raid on » par défaut.
Je suis reparti de zéro, j’ai tout réinstallé proprement et 1) par défaut le contrôleur est désormais en AHCI 2) j’ai pu installer debian avec le bios en UEFI, mes partitions étaient parfaitement détectées !

Je vais potasser ces aspects sans tarder ! On apprend toujours de ses erreurs, encore faut-il les étudier !

Merci !

Pas de mérite, j’ai été confronté plusieurs fois au problème (pas directement mais dans les forums où je sévis).

Il était possible de faire fonctionner Windows en mode AHCI sans le réinstaller, la manip (que je n’ai jamais appliquée personnellement) se trouve assez facilement sur le web. Mais s’il était « mal » installé, pourquoi pas…

Pour information, visiblement, windows n’a pas du tout aimé mon installation de debian en dual boot : carte Ethernet cramée !

Comment ça, « cramée » ?

Plus de carte Ethernet. Ce n’est pas une carte physique mais un chipset… Et bien… à l’issue de l’installation elle n’était plus là, disparue… même dans le bios !

Je ne vois pas comment une installation logicielle quelconque pourrait être responsable de ça. Et pourquoi incriminer Windows en particulier ?

Il y a une raison de vouloir faire un dual-boot plutôt que d’installer Windows en VM ?

Il y aurait une doc claire et complète quelque part ?
Je sais ce que sont le MBR et le GPT mais je n’ai jamais compris pourquoi cela affecte l’installation.

Spécification UEFI et GPT : https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf

C’est le mode d’amorçage BIOS ou UEFI qui affecte l’installation de Debian, pas le format de table de partition DOS/MBR ou GPT.

Merci, cependant quand je disais « claire » c’était pour moi sous-entendu « en moins de 2500 pages ».

Et donc, il y aurait une explication claire et (relativement) complète, en quelques pages maximum, d’en quoi le mode d’amorçage BIOS ou UEFI affecte l’installation de Debian ?

Il y a peut-être quelques informations dans le manuel d’installation de Debian, mais je ne suis pas sûr. Ce que je sais vient principalement de mes observations lors d’essais avec l’installateur Debian (classique, pas Calamares en session live que je n’ai jamais utilisé).
En résumé :

Amorçage en mode EFI :

  • création d’une table de partition au format GPT par défaut
  • création/nécessité d’une partition système EFI (drapeau boot,efi)
  • possibilité de créer une partition d’amorçage BIOS (mais non utilisée)
  • installation de grub-efi-amd64 (si firmware UEFI 64 bits) ou grub-efi-ia32 (si firmware UEFI 32 bits, rare), le chargeur GRUB est installé dans la partition système EFI

Amorçage en mode BIOS/legacy :

  • création d’une table de partition au format DOS/MBR par défaut si taille disque < 2 Tio, GPT sinon
  • en GPT, création/éventuelle nécessité pour GRUB d’une partition d’amorçage BIOS (drapeau bios_grub)
  • pas de possibilité de créer une partition système EFI
  • installation de grub-pc, le chargeur GRUB doit être installé dans le MBR d’un disque ou le secteur d’amorce d’une partition de type compatible

Les images d’installation amd64 peuvent être amorcées en mode BIOS et EFI 64 bits.
Les images d’installation i386 peuvent être amorcées en mode BIOS et EFI 32 bits.
L’image d’installation netinst multiarch amd64+i386 peut être amorcée en mode BIOS, EFI 32 et 64 bits. Elle permet d’installer un système 32 ou 64 bits (sur un processeur 64 bits), mais un noyau 32 bits ne peut pas utiliser les services EFI 64 bits (notamment pour enregistrer le chargeur d’amorçage dans les variables de boot EFI) alors qu’un noyau 64 bits peut utiliser les services EFI 32 bits.