Bonjour

Sur mon ordi j'ai installé F18 et F19 rawhide, et j'utilise les drivers nvidia pour ma carte graphique (avec akmod-nvidia)

Lors de mise à jour de kernel de F19 rawhide, je suis obligé, pour avoir cette nouvelle entrée sur le grub de ma F18, de lancer en root la commande 
grub2-mkconfig -o /boot/grub2/grub.cfg
.
Cette commande fonctionne et me détecte bien le nouveau kernel de F19 rawhide.

Le soucis est que lorsque que je veux démarrer sur le kernel courant de ma F18, je me retrouve avec un écran noir, si je démarre en init3, l'erreur est "no screen found" et "no nvidia.ko found"

Pour m'en sortir, je suis obligé de démarrer en init 3, désinstaller les driver nvidia avec "yum remove *nvidia*", puis redémarrer (je me retrouve avec les drivers nouveau) et ensuite ré-installer akmod-nvidia.
Au redémarrage, je me retrouve bien avec les drivers nvidia fonctionnels.

Quelqu'un aurait une idée pour éviter tout ce mic-mac ?
re,
tu as un kernel 18 et 19 sur la meme installation ?
si oui faut pas s'etonner du probleme
a+
Non je n'ai pas de kernel 18 et 19 sur la même installation.
J'ai F18 sur une partition et F19 rawhide sur une deuxième (pour tester), j'ai donc deux installation de Fedora différentes, et le boot général se fait sur F18.
Et ce souci ne se produit que lorsque tu lances la commande mkconfig ? Si c'est ça, c'est très étonnant, il n'y a aucun rapport de cause à effet.
nouvo09 wrote:Et ce souci ne se produit que lorsque tu lances la commande mkconfig ? Si c'est ça, c'est très étonnant, il n'y a aucun rapport de cause à effet.
c'est tout à fait cela, mais si je ne fais pas de mkconfig, je n'ai pas accès au dernier kernel que j'installe sur la rawhide

Je te donne le résultat de fdisk -l 
[root@chepioq ~]# fdisk -l

Disque /dev/sda : 120.0 Go, 120034123776 octets, 234441648 secteurs
Unités = secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Identifiant de disque : 0x000e3a1e

Périphérique Amorce  Début        Fin      Blocs     Id  Système
/dev/sda1            2048     2050047     1024000   83  Linux
/dev/sda2   *     2050048     4098047     1024000   83  Linux
/dev/sda3         4098048     8194047     2048000   82  partition d'échange Linux / Solaris
/dev/sda4         8194048   234441647   113123800    5  Étendue
/dev/sda5         8196096    38916095    15360000   83  Linux
/dev/sda6        38918144    69638143    15360000   83  Linux
/dev/sda7        69640192   161800191    46080000   83  Linux
/dev/sda8       161802240   234441647    36319704   83  Linux
[root@chepioq ~]#
/dev/sda1= partition boot de F18
/dev/sda2= partition boot de F19 rawhide
/dev/sda3= swap
/dev/sda5= / de F18
/dev/sda6= /de F19 rawhide
/dev/sda7= /home de F18
/dev/sda8= /home de F19 rawhide
Je ne comprends déjà pas l'intérêt de partitions /boot séparées dans un multiboot. Cela dit

Tente le diable, à partir de F 19, essaie un grub2-install /dev/sda2 et fais un chainloader depuis celui de F 18.
Pour les /boot séparées, j'ai toujours fais comme cela, pensant que cela est plus clair (une installation, un /boot).

Pour ta deuxième suggestion, je me demande si grub2-install /dev/sda2 est nécessaire, vu que sda2 est déjà marquée comme amorçable (* semble l'indiquer...)
Et alors ? le fait qu'elle soit marquée comme amorçable , outre le fait que cette indication est complètement ignorée par grub, n'implique pas que le code nécessaire soit implanté dans le bootsector de sda2.
Tu as raison, comme souvent, d'autant plus que cette F19 est une F18 bêta que j'ai installé avant d'installer la F18 finale, et qui a donc installé le chargeur de démarrage sur le mbr du disque, ce chargeur ayant été remplacé par celui de la F18 finale...
Bon , jai tenté ce que tu suggères depuis F19 : 
[root@host ~]# grub2-install /dev/sda2
/usr/sbin/grub2-bios-setup : attention : Le système de fichiers « ext2 » ne prend pas en charge l'embarquage.
/usr/sbin/grub2-bios-setup : attention : L'embarquage est impossible. GRUB ne peut être installé sur cette configuration qu'en utilisant les listes de blocs. Cependant, les listes de blocs ne sont PAS fiables et leur utilisation est déconseillée..
/usr/sbin/grub2-bios-setup : erreur : refus de continuer avec les listes de blocs.
[root@host ~]#
Cela ne semble pas top...
Ok la partition /boot F 19 serait en ext2.

Et la partition sda6, c'est à dire la / de F 19 elle est dans quel format ? ext3 ? ext4 ?

Si c'est le cas je tenterais de
- recopier la totalité du /boot de F19 dans sda6
- tenter grub2-install /dev/sda6

Je sais que cette configuration n'est pas recommandée mais comme il s'agit d'une installation de test, il faut oser.

Tu te sens d'humeur aventurière ? alors essaie à la place: grub2-install /dev/sda6 --force
c'est cela qui est bizarre, sda2 n'est pas en ext2 mais en ext4... 
[root@chepioq ~]# parted -l
Modèle: ATA OCZ-VERTEX3 (scsi)
Disque /dev/sda : 120GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : msdos
Disk Flags: 

Numéro  Début   Fin     Taille  Type      Système de fichiers  Fanions
 1      1049kB  1050MB  1049MB  primary   ext4
 2      1050MB  2098MB  1049MB  primary   ext4                 démarrage
 3      2098MB  4195MB  2097MB  primary   linux-swap(v1)
 4      4195MB  120GB   116GB   extended
 5      4196MB  19,9GB  15,7GB  logical   ext4
 6      19,9GB  35,7GB  15,7GB  logical   ext4
 7      35,7GB  82,8GB  47,2GB  logical   ext4
 8      82,8GB  120GB   37,2GB  logical   ext4
Bizarre, ça. Je fais du multi depuis un bail, et je ne garde qu'un boot, celui de la distro principale avec son Grub ou son Lilo. Sinon, ça risque de se mélanger les pinceaux, ce qui semble être ton cas.

Les partitions amorçables n'ont en effet pas d'importance.

Surtout que Fedora avec Grub2 gère nickel les autres distros sans rien avoir à faire, les chainloaders sont créés automatiquement, pourquoi s'embêter ?

J'ai regardé ton installe, pas facile de revenir en arrière en fait, perso je n'ai eu aucun souci avec le multi avec ma méthode simple.
Je pense que l'on s'éloigne du problème principal : pourquoi, lorsque que je fais un "grub2-mkconfig -o /boot/grub2/grub.cfg" sur ma F18, je me retrouve avec un écran noir, alors que tout fonctionne avant avec les drivers nvidia ???
À tout hasard, "nouveau" est bien blacklisté sur la 18 comme sur la 19 ?
Oui, nouveau est bien blacklisté sur F18 et F19.
Certes on s'éloigne de la question principale. Il n'en est pas mois vrai qu'il y a forcément une interaction entre les deux, raison pour laquelle je suggérais de séparer les frères siamois.

Chepioq je suppose que tu es déjà allé chercher partout dans les dmesg , var/log/messages et autres Xorg.0.log .?
En effet, j'ai regardé les logs, mais les seules erreurs sont celles indiquées sur le premier post...
Bon, aujourd'hui il y a eu une mise à jour kernel sur la F19.

J'ai fais comme d'habitude un mkconfig sur ma F18, pour avoir ce kernel au démarrage, et je m'attendais à devoir supprimer et réinstaller les drivers nvidia sur ma F18...

Et bien non, au redémarrage de ma F18, pas de soucis, ça roule...
Je passe en résolu, mais je ne sais pas vraiment pourquoi...
mais je ne sais pas vraiment pourquoi...
Tu copies Einstein ! "La pratique c'est quand tout fonctionne et qu'on ne sait pas pourquoi".