• [supprimé]

Salut,
j'ai tenté de faire la mise à niveau de mon Fedora 16 vers Fedora 17 tout à l'heure, mais il y a un (gros?) problème. Ma partition / est cryptée avec luks, et j'ai par conséquent une deuxième partition /boot qui me demandait jusqu'à présent au démarrage le mot de passe. Après le PreUpgrade, je reboote, et j'ai un écran noir. À mon avis c'est pas un problème de driver graphique, car c'est déjà pas normal qu'il ne me demande pas de mot de passe pour déverouiller /.

Après un petit tour dans /boot/grub2/grub.cfg, j'ai édité quelques lignes pour lui dire qu'il faut déverouiller /, sans quoi ça ne démarrera pas (logique). Sauf que maintenant, au démarrage, il me dit que /dev/mapper/luks-e5d5ff1e-78e8-47c9-8ed0-6e10a0ea5e80 n'existe pas. Pourtant, lorsque je démarre sur un vieux noyau de Fedora 16, tout marche sans problème. J'ai donc connement regardé le contenu du dossier /dev/mapper avec dracut, et il n'apparaît qu'un fichier "control", alors qu'avec le noyau Fedora 16, il y a bien le luks-e5d....

Peut-être que je suis vraiment con et que la réponse l'est encore plus, mais je ne vois pas où est le problème, alors si une âme charitable pouvait m'éviter d'abîmer ma splendide cuirasse dans un sanglant combat contre mon linux, je lui en serais reconnaissant.

Librement.

Voilà l'entrée du vieux noyau, qui fonctionne :
menuentry 'Fedora Linux, with Linux 3.3.5-2.fc16.x86_64' --class fedora --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos1)'
	search --no-floppy --fs-uuid --set=root 01618a19-5cb5-403a-8b96-405cbfae3bfd
	echo	'Loading Linux 3.3.5-2.fc16.x86_64 ...'
	linux	/vmlinuz-3.3.5-2.fc16.x86_64 root=/dev/mapper/luks-e5d5ff1e-78e8-47c9-8ed0-6e10a0ea5e80 ro rd.md=0 rd.lvm=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb  KEYTABLE=fr rd.luks.uuid=luks-e5d5ff1e-78e8-47c9-8ed0-6e10a0ea5e80 LANG=en_US.UTF-8 
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-3.3.5-2.fc16.x86_64.img
}
Et celle qui a été ajoutée après le PreUpgrade :
menuentry 'Mise à niveau vers Fedora 17 (Beefy Miracle)' --class gnu-linux --class gnu --class os {
	linux /upgrade/vmlinuz preupgrade repo=hd::/var/cache/yum/preupgrade ks=hd:UUID=01618a19-5cb5-403a-8b96-405cbfae3bfd:/upgrade/ks.cfg stage2=hd:UUID=01618a19-5cb5-403a-8b96-405cbfae3bfd:/upgrade/squashfs.img
	initrd /upgrade/initrd.img

Et la modif que j'ai faite (pas sûr qu'elle soit correcte, mais j'ai essayé plusieurs choses, en vain) :
menuentry 'Mise à niveau vers Fedora 17 (Beefy Miracle)' --class gnu-linux --class gnu --class os {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	set root='(hd0,msdos1)'
	search --no-floppy --fs-uuid --set=root 01618a19-5cb5-403a-8b96-405cbfae3bfd
	echo	'Loading Linux 3.3.7-1.fc16.x86_64 ...'
	linux	/upgrade/vmlinuz root=/dev/mapper/luks-e5d5ff1e-78e8-47c9-8ed0-6e10a0ea5e80 ro rd.md=0 rd.lvm=0 rd.dm=0 quiet SYSFONT=latarcyrheb-sun16 rhgb  KEYTABLE=fr rd.luks.uuid=luks-e5d5ff1e-78e8-47c9-8ed0-6e10a0ea5e80 LANG=en_US.UTF-8 preupgrade repo=hd::/var/cache/yum/preupgrade ks=hd:UUID=01618a19-5cb5-403a-8b96-405cbfae3bfd:/upgrade/ks.cfg stage2=hd:UUID=01618a19-5cb5-403a-8b96-405cbfae3bfd:/upgrade/squashfs.img
	echo	'Loading initial ramdisk ...'
	initrd /upgrade/initrd.img
}
Merci bien
Hello,

ben moi pas vraiment le même pb, mais quand je mets la passphrase qui fonctionne sur le précédent noyau, ça ne marche pas, elle n'est pas reconnue! je ne peux donc pas continuer l'installation de beefy miracle après le reboot...
greg911 j'ai eu exactement le même problème que toi.
Pour le corriger j'ai modifié une ligne dans /etc/grub2.cfg, j'ai rajouté l'UUID de ma racine:
repo=hd::/var/cache/yum/preupgrade
est devenu (en reprenant l'exemple de rusty), c'est la même UUID que le champ ks= et stage2= :
repo=hd:UUID=01618a19-5cb5-403a-8b96-405cbfae3bfd:/var/cache/yum/preupgrade

La mise à jour est en train de se faire, je fais un retour si j'ai un nouveau soucis lors du redémarrage après la MAJ 🙂
merci ArthurC 🙂
mais chez moi ça change pas grand chose, la passphrase n'est tjs pas reconnue.
ArthurC wrote:Pour le corriger j'ai modifié une ligne dans /etc/grub2.cfg
ça c'est un lien vers /boot/grub2/grub.cfg , donc si il y'a qqch à modifier, c'est plutôt ce dernier qu'il faut modifier

juste avant l'écran pour mettre la passphrase, des tas de choses défilent à l'écran, j'ai noté qu'apparemment le chargement de qqch échouait, ça s'appelle "Plymouth Boot Screen" .. un rapport ? :-?
Tu as fait attention au langage du clavier ? Car chez moi c'était en qwerty.
exact ! en qwerty ça marche mieux :hammer:

merci du conseil!
6 jours plus tard
Je suis bien content d'être passé ici avant de faire la mise à jour, car j'ai eu le même soucis.
Pas facile d'entrer sa passphrase quand on a des caractères spéciaux...

Je ne sais pas si c'est lié a LUKS, mais au redemarrage après preupgrade, je n'avais pas de ligne pour f17 dans grub. /etc/grub2.cfg était ok mais pas la version dans /boot. J'ai du copié le fichier à la mano.

cryptsetup 1.4.2, je devrais pouvoir activer le TRIM sur mon SSD 🙂