Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

Arbiel · Le 27/02/2016, à 13:39

Bonjour

Le 30 janvier, Gibi83 est venu solliciter le forum par cette discussion.

Nous n'avons à ce jour pas encore résolu son problème. Comme la discussion tire en longueur, près de 200 interventions en une dizaine de pages, j'ouvre la présente discussion pour obtenir de l'aide supplémentaire. Pour vous éviter la recherche dans ces 200 interventions d'informations significatives, je vais tout d'abord résumer la situation en essayant de ne rien omettre d'important.

Gibi83 dispose de plusieurs supports amovibles (deux disques et deux clés, si j'ai bonne mémoire) sur lesquels, ou sur l'un desquels, il veut installer une Ubuntu 15.10 64 bits. Il en a initialisé un en outil d'installation, donc motorisé par syslinux, dont il s'est servi pour en transformer un autre en disque système, motorisé pas grub. Ce disque système ne fonctionne pas. Il a fait plusieurs essais avec ses divers supports. Les outils d'installation fonctionnent, par contre

les disques systèmes aboutissent tous à un écran absolument noir, sans aucun signe sur l'écran.

Ses supports amovibles sont parfaitement visibles depuis Windows, comme depuis les systèmes d'installation.

Ces constats tendent à prouver qu'il n'y a pas incompatibilité entre les divers matériels.

Nous avons ensuite suspecté une incompatibilité entre le matériel et grub. D'où des tentatives, restées infructueuses, de passer grub en mode conversationnel. L'absence du fichier de configuration a abouti au même résultat : écran noir.

Le BIOS refuserait-il de passer le contrôle à grub, sous prétexte de contrôles qui ne le satisferaient pas ? C'est l'hypothèse sur laquelle nous travaillons actuellement.

Nous avons alors supposé que le problème pouvait venir de ce que Syslinux fonctionne avec des partitions connues de Microsoft, alors que grub fonctionne avec des partitions inconnues de Windows, partitions dont le BIOS peut prendre connaissance du type dans la table des partitions.

Sur son disque système parfaitement organisé d'après les divers rapports de démarrage produits par boot-repair, Gibi a créé une partition FAT32 et posté dessus le drapeau boot. Aucun effet. grub, normalement installé sur le disque (dans le MBR, et core.img entre ce premier secteur et la première partition) ne s'est pas manifesté.

Certains BIOS étant susceptibles de court-circuiter le MBR pour aller chercher le contenu de l'EBR (c'est bien le nom du premier secteur de la partition ?), Gibi83 a installé grub sur la partition FAT32 (grub-install --force). Aucun effet.

Voilà où nous en sommes actuellement.

Le dernier rapport de démarrage, dont je n'ai lu que les premiers éléments, montre la présence de grub dans le MBR du disque sdd et sur la partition sdd4. La partition / est en sdd1.

Quelles autres hypothèses ?

La partition sdd4 est-elle trop éloignée du début du disque ?
Mais surtout, quels autres contrôles le BIOS pourrait-il faire pour refuser de passer le contrôle à grub ?
Pour quelles raisons grub pourrait-il se planter au point de ne pas pouvoir afficher le moindre message ?

Arbiel

moko138 · Le 27/02/2016, à 15:48

. Idées en vrac :
1) Gibi83 a-t-il débranché son 2nd écran ?

2) Un écran noir ne provient pas nécessairement d'un problème de grub.
2.1 Quelles sont le nom complet et les caractéristiques de l'alienware M18 R1 de Gibi83 ?
- cartes graphiques
- bios

2.2 Les bips des grub n'ont pas été activés (cf. ./viewtopic.php?id=1958451 et en particulier l'astuce complémentaire en fin de #1.)
On ne risque rien à le faire.

2.3 Ctrl Alt F1, sauf erreur de ma part, n'a pas encore été employé.

3) Tout réinstaller (windows compris) en UEFI ? (Oui, c'est plus lourd que le projet initial de Gibi83...)

Gibi83 · Le 27/02/2016, à 17:55

Bonjour et merci de vous pencher sur mon cas .

Je me garde bien d'intervenir sur le plan technique, mais je donne la réponse à la première question posée, pour mettre toutes les chances de notre côté je me suis mis en mono-écran celui du portable.
Le nom complet est Alienware M18R1, en plus du processeur vidéo de la carte mère il est équipé de deux cartes Nvidia GTX 580 M, Bios A05 du 29/11/2009 8Go de mémoire par contre HWiNFO64 me donne à ma grande surprise
UEFI Boot. Je crains que cela change pas mal de choses....

Dernière modification par Gibi83 (Le 27/02/2016, à 18:10)

Rufus T. Firefly · Le 27/02/2016, à 18:53

/dev/sdd4  *    227203072 259971071  32768000  15.6G  b W95 FAT32

C'est quoi cette partiition et elle est censée servir à quoi ?
Parce qu'en plus, elle a grub, ou quelque chose qui y ressemble mais qui n'est peut-être pas bon, sur son boot record et le flag boot... Cf lignes 953 et suivantes

PPdM · Le 27/02/2016, à 19:35

Salut
as tu essayer de contacter le SAV de Dell? ils font le support Linux.
Ensuite, mets a jour le bios il me parait bien .
Peux tu me donner son asset tag (dessous)
ça ressemble a ça

Dernière modification par PPdM (Le 27/02/2016, à 19:43)

Babdu89 · Le 27/02/2016, à 19:45

Bonjour.

Rufus T. Firefly a écrit :

/dev/sdd4  *    227203072 259971071  32768000  15.6G  b W95 FAT32
C'est quoi cette partiition et elle est censée servir à quoi ?
Parce qu'en plus, elle a grub, ou quelque chose qui y ressemble mais qui n'est peut-être pas bon, sur son boot record et le flag boot... Cf lignes 953 et suivantes

Çà va servir à tester ce qui est prévu là, et suivants ...

https://forum.ubuntu-fr.org/viewtopic.p … #p21466142

Mais pour comprendre, je pense qu'il va falloir lire le sujet en entier...

Édit. Ne pas se décourager, on a besoin d'aide.

@+. Babdu89 .

Dernière modification par Babdu89 (Le 27/02/2016, à 19:47)

Babdu89 · Le 27/02/2016, à 20:02

Je vais résumer ici le souci.

La machine semble ne pas aimer Grub.
Gibi83 essaye d'utiliser un Ubuntu installé sur un hdd de récupération dans un boîtier usb.
Mais çà ne marche pas.
Au démarrage, sans aucun affichage. Çà semble travailler (charger quelque chose) ,puis plus rien!.

On a mis en doute que la machine sache booter sur l'usb. et le hdd de récupération aussi.
Il n'en est rien.
Une clé live Ubuntu fonctionne
Une installation en live sur le hdd de récupération fonctionne.
Le hdd est reconnu par Windows et Ubuntu en utilisation stockage de données.
Une installation réelle (partition ext4 et swap) sur clé usb de 64 Go, ne fonctionne pas.

ÉDIT.
J'ajoute ce que l'on ne sait pas.
On ne sait pas si une installation sur un disque dur interne fonctionnerait, il n'y a pas de test fait.

On voudrait bien savoir pourquoi l'installation correcte (voir les rapports boot info) ne marche pas.

@+. Babdu89 .

Dernière modification par Babdu89 (Le 27/02/2016, à 23:13)

PPdM · Le 27/02/2016, à 20:09

Il faudrait essayer avec un autre disque dans le même boitier.
J'ai déjà eu un souci du genre avec un disque de recup qui avait un MBR foireux, genre tatouage, j'ai jamais pu résoudre, mais le disque fonctionnait en stockage.

Rufus T. Firefly · Le 27/02/2016, à 20:09

en plus du processeur vidéo de la carte mère il est équipé de deux cartes Nvidia GTX 580 M

Je parie que c'est ça ! Comme il n'y a pas de linux installé, à part celui du disque externe, on s'imagine que c'est bios/grub... Quant au live, il utilise sûrement du vga standard (sans driver vidéo particuliier).

PPdM · Le 27/02/2016, à 20:11

Au fait, c'est un disque 2.5 ou 3.5" ?

Babdu89 · Le 27/02/2016, à 22:23

@PPdM

Un MBR foireux, il fonctionnerait avec Syslinux dedans en live, son disque marche en live.

@Rufus T. Firefly.

J'ai pensé qu'il utilisait un SLI, mais non Gibi83 vient de préciser qu'il n'utilise qu'une seule carte.

@+. Babdu89 .

Babdu89 · Le 27/02/2016, à 23:08

PPdM a écrit :

Au fait, c'est un disque 2.5 ou 3.5" ?

Gibi83 a dit

Comme ma machine boote sans problème sur clef USB je pense qu'il manque quelque chose au niveau du boitier "Advance Steel Disk" dans lequel j'ai installé un disque SATA récupéré sur un portable.

Un peu plus d'info là

https://forum.ubuntu-fr.org/viewtopic.p … #p21459455

@+. Babdu89 .

Dernière modification par Babdu89 (Le 27/02/2016, à 23:12)

PPdM · Le 27/02/2016, à 23:12

donc alimenté par le port usb, hors l'alim du port usb est désactivé lors du chargement sauf erreur de ma part, il faudrait essayer avec une alim externe

Babdu89 · Le 27/02/2016, à 23:16

Gibi83 dit que sans affichage, çà semble charger quelque chose, mais que çà n’aboutit pas .

@+. Babdu89 .

Rufus T. Firefly · Le 28/02/2016, à 00:21

Babdu89 a écrit :

Gibi83 dit que sans affichage, çà semble charger quelque chose, mais que çà n’aboutit pas .
@+. Babdu89 .

Ça tend à montrer que le bios passe bien la main, mais que ça s'arrête après.
Parece que si le bios ne trouvait rien d'amorçable sur ce disque, il testerait normalement le périphérique suivant... et démarrerait sur w$.

moko138 · Le 28/02/2016, à 08:46

Gibi83 a écrit :

Le nom complet est Alienware M18R1,

Non, car il existe plusieurs "M18 R1".
Le nom complet est habituellement écrit sous les portables

Dernière modification par moko138 (Le 28/02/2016, à 08:47)

PPdM · Le 28/02/2016, à 09:39

Cela serait intéressant d'avoir les réponses a nos question.

maxire · Le 28/02/2016, à 10:19

Salut,

Arbiel a écrit :

L'absence du fichier de configuration a abouti au même résultat : écran noir.

De quel fichier de configuration parles-tu?

Si l'objectif est de tomber en mode Grub Rescue, il suffit de renommer /boot/grub par exemple en /boot/grub-inactif pour y arriver.

Si alors tu obtiens la ligne de commande de Grub c'est que celui-ci est bien lancé et que le problème apparaît ensuite lors de l'affichage du menu ou bien au lancement de Ubuntu (problème de serveur X possible ou Plymouth qui nous fait des misères).

Si tu n'obtiens rien, oublier Grub.

En mode Grub-rescue, il suffira de passer cette série de commandes Grub pour afficher le menu Grub:

set prefix=($root)/boot/grub
insmod normal
normal

Si le menu se plante, il faudra essayer de le passer en mode texte, ou du moins essayer de comprendre pourquoi.

Une remarque, je n'ai pas lu tout le fil de discussion que tu pointes et je ne le lirai pas, je vois que avec toute votre bonne volonté à aider Gibi83 vous partez un peu dans tous les sens et que bien que possédant une réelle pratique de Ubuntu vous ne dominez ni Grub ni Syslinux (normal, les documentations disponibles sont plutôt confuses).

- Une mise au point au sujet de Syslinux: Syslinux reconnaît parfaitement les systèmes de fichiers fat32, extn et btrfs, plus d'information ici et là

- Dans les derniers messages vous vous focalisez sur core.img (au moins Babdu89), une fois installé entre le 2ème secteur du disque et le début de la première partition (cas BIOS mbr) ou dans la partition bios-boot (cas Bios GPT) il ne sert plus à rien vous pouvez le supprimer de /boot/grub/i386-pc. En fait /boot/grub ne sert qu'à fournir des modules à Grub, ces modules étant non intégés dans core.img et donc non disponibles en mode Grub rescue.

Babdu89 · Le 28/02/2016, à 10:35

Bonjour.
maxire adit;

- Dans les derniers messages vous vous focalisez sur core.img (au moins Babdu89),

Je ne fais que confirmer que core.img est bien dans la partition système, et non dans la partition de /boot séparée.

Depuis le début de cette histoire, j'ai l'impression que; il faudrait passer une option au noyau pour faire démarrer la machine. Et pas forcément nomodeset.
Mais sans affichage de Grub; messages d'erreur....
Pas facile de savoir laquelle. D’où mon idée de forcer le démarrage de la machine en mode recovery, pour voir si çà affiche quelque chose au démarrage, et avoir des indications.
Si toute foi çà veut bien afficher quelque chose, en démarrant en recovery.

@+. Babdu89 .

Arbiel · Le 28/02/2016, à 11:28

Bonjour

@maxire

Comme tu as pu t'en apercevoir, nous sommes dans le flou le plus total et nous partons effectivement tous azimuts, chacun poursuivant en quelque sorte son chemin dans le noir.

Le problème auquel est confronté Gibi83 est que son écran reste désespérément noir lorsqu'il démarre son PC à partir des supports amovibles sur lesquels il a installé Ubuntu en utilisant d'autres supports préparés, je suppose, avec Unetbootin et donc démarrés avec syslinux.

Les premiers soupçons ont porté sur grub. Mauvaise installation, erreurs dans grub.cfg.

Cela nous a conduit à essayer de passer grub en mode conversationnel pour essayer d'y voir un peu plus clair. Le renommage de grub.cfg, et dont la disparition de grub.cfg, n'a rien donné.

Dans un autre test, nous avons introduit une commande play par le biais de la variable adéquate, et aucun bip n'a été émis (panne du biper ?)

Nous en sommes arrivés ainsi à l'hypothèse que le BIOS de son PC avait quelque chose contre les systèmes de fichiers ext et nous avons alors essayé de le tromper en lui faisant croire que le système était installé sur une partition FAT32.

Sans succès.

D'où probablement problème de video et la nécessité d'installer grub en mentionnant la liste des modules à inclure dans core.img. J'ai demandé ce matin de l'aide à help-grub à cette fin.

Qu'en penses-tu ? Peut-être insérer une commande savenv prefix au tout début de grub.cfg pour déterminer si oui ou non grub est lancé ?

Arbiel

Dernière modification par Arbiel (Le 28/02/2016, à 12:11)

maxire · Le 28/02/2016, à 13:35

Effectivement, si en supprimant grub.cfg la ligne de commande Grub ne s'affiche pas, il y a un gros problème.
Je ne sais pas si, dans la configuration standard de Ubuntu, cette ligne de commande est supposée s'afficher en mode graphique ou en mode texte même en Grub Rescue.

Pour passer en mode texte, ajouter ou décommenter ces 2 lignes dans /etc/default/grub:

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
GRUB_TERMINAL_OUTPUT=console

+

GRUB_DEFAULT=0
GRUB_TIMEOUT=5

Peut-être aussi commenter toutes les lignes commençant par GRUB_GFX...
GRUB_DEFAULT et GRUB_TIMEOUT permettent une temporisation de 5 secondes pour arrêter le lancement et afficher le menu GRUB en pressant la touche Maj-droite ou Echap, pour Ubuntu je ne sais plus, le lancement de mes machines passe systématiquement par Archlinux le Grub de mes Ubuntu est désactivé.

Je n'ai pas vérifié ce qu'indique le boot-info au sujet de /etc/default/grub, il faudrait le faire.

Passer en mode chroot et grub-install puis update-grub (en live-usb bien sûr).

Je pense que l'idée d'utiliser syslinux est correcte, c'est juste un peu compliqué à mettre en œuvre avec Ubuntu, il faudra reconfigurer le paquet de Grub pour qu'il n'installe rien dans le mbr, ni dans le vbr (volume boot record) de la partition racine puisque ce paquet est quasi impossible à supprimer.

Vous pouvez vous inspirer de la recette donnée dans le wiki Archlinux, elle est plus claire que celles données dans la documentation Ubuntu-fr.
Il est possible de réaliser toute l'installation à partir de la Live-USB, sans installer le moindre paquet sur le disque cible.

Le problème c'est qu'il faut travailler en mode expert ou en tout cas en mode utilisateur averti, j'ignore si Gibi83 s'en sent capable.

Les firmwares BIOS sont des programmes très bêtes qui ne reconnaissent aucun système de fichiers (heureusement ils sont trop nombreux!), ils se contentent de charger le programme localisé dans les 440 premiers octets (ou 446/448 je ne sais plus).
Si ce programme en mbr est syslinux celui-ci en fonctionnement de base utilise la notion de drapeau de démarrage pour déterminer quel vbr utiliser en espérant que ce vbr abrite un lanceur.
Si ce programme est grub la notion de drapeau de démarrage n'est pas utilisée, Grub se débrouille avec son fichier de configuration à condition de le trouver.

Sur ce je vous laisse, je n'ai pas trop de loisir à vous consacrer, en espérant que ces quelques piste vous soient utiles

maxire · Le 28/02/2016, à 15:11

Maxire a écrit :

Je ne sais pas si, dans la configuration standard de Ubuntu, cette ligne de commande est supposée s'afficher en mode graphique ou en mode texte même en Grub Rescue.

Je viens de vérifier rapidement, l'affichage de la ligne de commande se fait en mode texte ===> pas de problème graphique.

L'hypothèse Grub qui ne veut pas fonctionner du tout (pourquoi?) tient la route, laissez tomber Grub.

MicP · Le 03/03/2016, à 10:58

Peut-être une autre piste …
J'ai cru comprendre que la machine de Gibi83 était équipée de plusieurs cartes graphiques, et je me suis souvenu d'une mésaventure qui m'était arrivé il y a … trop longtemps avec ma tour carte mère ASUS :
J'avais deux écrans chacun connecté sur une sortie DVI de chaque carte graphique, mais lors du boot, c'était une des sortie SVGA (DB15) d'une des cartes graphique qui était active : Le mode graphique lors du boot et de GRUB est un mode compatible VESA.

Sur mon G53SW avec GTX460M, si je connecte un écran par DVI, je n'ai pas d'affichage des messages du BIOS, mais le menu de grub s'affiche.
Si je dé-connecte l'écran externe, j'ai tout qui s'affiche correctement sur l'écran interne : BIOS + Grub + graphique
Si je connecte l'écran externe par un cordon SVGA (DB15), j'ai tout, mais évidement, le mode graphique est affreux.

Mais il faut redémarrer plusieurs fois pour confirmer les tests, car entre la carte qui détecte ou pas les écrans qui répondent ou pas et le pilote qui fait ce qu'il peut, le BIOS, l'UEFI, etc. …

Dernière modification par MicP (Le 03/03/2016, à 12:23)

maxire · Le 03/03/2016, à 12:02

@MicP, c'est une possibilité, ce qui est étrange c'est que d'après ce que j'ai compris syslinux fonctionne car les clefs USB d'installation de Ubuntu démarrent (je ne me souviens plus si c'est isolinux ou syslinux qui gère alors le démarrage, tout dépend de la méthode utilisée pour créer la clef USB, mais bon ces deux programmes appartiennent à la mêmesuite logicielle).

Effectivement, l'affichage de Grub est en VESA comme Syslinux, je note que 3 gestionnaires vidéo sont disponibles sous Grub, vga.mod, vga_text.mod et video.mod (+ quelques modules préfixés video).

Des informations sur le matériel de Gibi83: Dell Alienware M18,
1 GPU Radeon + 1 carte NVIDIA

Rufus T. Firefly · Le 03/03/2016, à 13:34

Je propose d'essayer autre chose que ubuntu. Par exemple Debian jessie : http://cdimage.debian.org/cdimage/relea … esktop.iso
Ici la lxde, histoire d'avoir le plus simple, donc le plus rapide...
Parce que chez Debian, dans grub.cfg, on trouve ceci :

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 --hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1  7978a964-623b-44a8-b649-e29d7bad9f0b
else
  search --no-floppy --fs-uuid --set=root 7978a964-623b-44a8-b649-e29d7bad9f0b
fi
insmod png
if background_image /usr/share/images/desktop-base/lines-grub.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
	set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode

Alors que chez ubuntu (voir boot-info) il y a cela :

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
if background_color 44,0,30,0; then
  clear
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
	set gfxpayload="${1}"
	if [ "${1}" = "keep" ]; then
		set vt_handoff=vt.handoff=7
	else
		set vt_handoff=
	fi
}
if [ "${recordfail}" != 1 ]; then
  if [ -e ${prefix}/gfxblacklist.txt ]; then
    if hwmatch ${prefix}/gfxblacklist.txt 3; then
      if [ ${match} = 0 ]; then
        set linux_gfx_mode=keep
      else
        set linux_gfx_mode=text
      fi
    else
      set linux_gfx_mode=text
    fi
  else
    set linux_gfx_mode=keep
  fi
else
  set linux_gfx_mode=text
fi
export linux_gfx_mode

Je ne comprends pas le détail, mais comme ça a manifestement trait à l'affichage et que c'est différent... En outre, chez Debian, il n'y a pas de splash ni de variable vt_handoff (je ne sais pas à quoi ça correspond)...
Il y a des choses à ce propos ici : http://byobu.info/articles/Changing_Ply … buntu.html
(y compris un bug !)

Dernière modification par Rufus T. Firefly (Le 03/03/2016, à 13:53)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 27/02/2016, à 13:39

Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#2 Le 27/02/2016, à 15:48

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#3 Le 27/02/2016, à 17:55

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#4 Le 27/02/2016, à 18:53

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#5 Le 27/02/2016, à 19:35

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#6 Le 27/02/2016, à 19:45

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#7 Le 27/02/2016, à 20:02

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#8 Le 27/02/2016, à 20:09

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#9 Le 27/02/2016, à 20:09

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#10 Le 27/02/2016, à 20:11

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#11 Le 27/02/2016, à 22:23

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#12 Le 27/02/2016, à 23:08

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#13 Le 27/02/2016, à 23:12

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#14 Le 27/02/2016, à 23:16

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#15 Le 28/02/2016, à 00:21

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#16 Le 28/02/2016, à 08:46

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#17 Le 28/02/2016, à 09:39

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#18 Le 28/02/2016, à 10:19

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#19 Le 28/02/2016, à 10:35

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#20 Le 28/02/2016, à 11:28

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#21 Le 28/02/2016, à 13:35

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#22 Le 28/02/2016, à 15:11

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#23 Le 03/03/2016, à 10:58

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#24 Le 03/03/2016, à 12:02

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

#25 Le 03/03/2016, à 13:34

Re : Un BIOS qui n'aime pas grub mais aime néanmoins syslinux

Pied de page des forums