Clef USB pour ISN dans les lycées

Résultat : je n’ai pas vu le menu GRUB
Le noyau a pris du temps à charger, l’initrd encore plus

Et tout s’arrête après ce message :

Bon on va essayer de lancer le noyau. Hasardeux encore. Soyez patient, tout va bien se passer (si)

Et j’ai été patient mais plus aucune tentative de lecture sur la clé

Ah, c’est mieux, ça progresse…

Bon, remplace l’initrd.img de la clef et le fichier boot.iso par

phare.normalesup.org/~boisson/boot.iso
et
phare.normalesup.org/~boisson/initrd.img

C’est la même chose mais avec des messages…

Je reprendrai mes essais demain soir. D’ici là je vais manquer de temps.

Bonjour,
configuration:
-Debian 3.80 modifié depuis le source Debian
-VirtualBox Oracle 4.2.x
-Windows 7 sous VB

LiLi s’installe parfaitement
au formatage pb vfat non implémenté dans le kernel Debian 3.8.x
donc également absent dans VB W7 Pro Sp1
j’ai plusieurs Linux sous VB, même pb

je contourne ce pb avec une autre machine Linux
A+
JB1
8) sous la pluie

Bon, visiblement le noyau est chargé ainsi que l’initrd mais rien ne se passe par la suite, le ramdisk n’est peut être correctement construit, je vais essayé de voir ça…

bonjour,
cela fonctionne je boote avec la clé sur ma machine 64 bits multicore
donc compatibilité 64/32 bits,
la clé a étè créé sur une Vista 32 bits
A+
JB1

Le problème ne se pose pas sous Windows mais sous MAC.

Je me suis aperçu que je n’ai pas mis la fonte unicode.pf2, peut être est ça qui bloquait. J’ai remis l’archive à jour.

Me revoilà, désolé pour ses qq jours sans retour.

Alors, déjà ça ne fonctionne toujours pas avec la nouvelle archive.

Entre temps j’ai potassé un peu la page de rEFInd : rodsbooks.com/refind/
Il y a plein d’infos, Roderick Smith a l’air de bien maitriser les arcanes de l’EFI et en plus il a mené pas mal de tests sur un Mac Mini (avec un EFI 32).

Le moins qu’on puisse dire c’est que ça n’a pas l’air simple du tout de trouver une solution : entre les soucis d’architecture, de noyau supportant tel ou tel truc, d’EFI ou d’UEFI, de spécificités Apple, de Grub patché et autres joyeusetés comme les infos pas à jour sur le net avec des évolutions rapides des outils … j’ai mal à la tête.

En résumé :
le noyau 3.6 a introduit l’EFI Handover protocol qui devrait simplifer le démarrage en EFI
le noyau 3.3 a introduit l’EFI Stub loader : wiki.archlinux.org/index.php/UEFI_Bootloaders
Fedora a sorti un GRUB Legacy patché lourdement pour supporter l’EFI … puis est passé à GRUB2
Apple a fait un EFI à sa sauce avec notamment des EFI 32bits sur des architectures 64bits
Syslinux 6 devrait permettre le boot EFI … mais pour le snoyaux supportant l’EFI Handover protocol seulement
Qui dit EFI dit plus de Bios, donc des choses étranges sur le support matériel

Outre les différentes versions de BootMac.tgz, boot.iso et initrd, j’ai fait des essais avec des fedora 16 et 18 en i686 et x86_64, des Aptosid, rEFInd, ELILO, efilinux, grub (1.99 ou 2) et au final, seul le LIVE USB Fedora 18 x86_64 a été fonctionnel sur mon MacBookPro 4.1 (EFI64 capable de booter un OS X 32 ou 64).

J’ai aussi un live usb Fedora 16 i686 qui boot en mode BIOS et en EFI sur mon Asus P52J (avec un noyau 3.2.6 et un grub 0.97 patché à mort comme indiqué sur le site de R. Smith) … mais il ne veut rien savoir sur le mac. À mon avis c’est à lier avec un souci d’architecture du noyau. Et sur le Pc en démarrant via l’EFI j’ai des problèmes de matériel (trackpad non fonctionnel au moins).
ELILO sur le Mac m’informe gentiment qu’il ne trouve pas de carte graphique.
J’ai presque réussi à lancé l’AptoSid 64 mais là aussi un souci de matériel (et peut-être aussi de version de GRUB)
rEFIt et rEFInd parviennent peut-être à lancer des linux installés mais je n’ai rien pu en sortir pour des live usb … même lorsqu’ils font apparaitre une entrée détectée.

Le MacBookPro sur lequel je fais mes tests est en dual-boot OS X Mountain Lion (64bits) et LMDE (3.2.0-4 64bits) via rEFIt qui passe le relais à GRUB2 pour LMDE. Et même là pour que ça fonctionne il a fallu que je mette en place une partition avec un flag bios_grub et que j’installe le chargeur un peu partout.

Mais je n’abandonnerai pas !!!

Merci de ce rapport, je vais étudier tout ça…

J’ai poursuivi mes tests avec rEFInd :

  • j’arrive à démarrer sur une Fedora x86_64 en créant une entrée dans rEFInd
  • la méthode ne fonctionne pas avec une aptosid amd64
  • ni avec une xubuntu 12.10 amd64

Mais j’ai presque réussi à démarrer l’aptosid en utilisant le bootx64.efi fourni.
Presque parce que j’ai du blacklister le driver nouveau de la carte nVidia du Mac et que je n’ai pu démarrer qu’en init3

J’ai laissé de coté les tests sur des noyaux i586/i686 parce qu’à part les distros basées sur du RH je n’ai jamais vu le moindre début de dossier EFI sur les LiveCD, au contraire des arch amd64.

J’ai encore des essais à faire avec des LiveCD Archlinux et SysRescueCD (base Gentoo) puis à doubler tous les essais sur mon portable qui a un firmware UEFI 64bits, un vrai !
Ah, les joies d’Apple et de ses mélanges d’EFI, d’UEFI et de petits trucs vicieux !!! c’est une des raisons qui me poussent à continuer dans la direction de rEFInd puisque ce dernier est sensé fonctionner sur Mac.

Bientôt les prochains épisodes.

[quote=“fran.b”]Oui, tu as déjà une preversion 8.0 qui est en fait la ClefISN qui va servir de bases aux deux concours 2013 (le premier s’est achevé Samedi). Du coup la mise au point prend un peu de temps. Si tu as des suggestions c’est le moment.

Note que tu as une liste d’extensions assez importantes désormais:
[/quote]
Je suggère que l’on mette un numéro sur les extensions (et clé isn) correspondant au numéro de debian.
ainsi on notera par exemple extension_R_7.sqh l’extension R pour la version ISN basé sur debian7.

En fait, j’ai essayé de tout unifié; une base (actuellement fondée sur wheezy) et des extensions permettant d’obtenir les différentes déclinaisons (la clef sert même pour des préparations CAPES…). Je vais affiné ce dernier point. Ce n’est pas idiot de se baser sur la version de debian correspondante mais dans ce cas, ça va être N+1. La version 7 était fondée sur squeeze, la 6 sur lenny et la version actuelle (ISN=8.0) wheezy.

alors je te suggère de faire une version isn=7b pour 7bis et après tu te cales sur la version debian utilisé.
maintenant si c’est n+1, ca sera n+1 mais je trouve plus logique de faire n.

Hum, je vais faire une version 8.1 avec la version testing, ce sera une façon de se recadrer…

Rq: Ce serait peut être bien que ce fil aille dans suppport debian, plusieurs personnes m’ont contacté en me demandant pourquoi le fil avait disparu (on leur avait indiqué)…

test de SD

Impeccable, merci

Mon avis est que dans sd le fil se perd très vite.

Je penses que tes personnes n’étaient pas connectée donc pas de fil.

On verra…

Petit résumé des essais du jour.
Distribution testée : System Rescue CD donc base Gentoo

  • noyaux 32 et 64
  • version standard : noyau 3.4.4 (rescue64)
  • version alternative : noyau 3.9 et des poussières (altker64)
    L’iso a un dossier efi et un dossier /boot/grub.
    Premier constat : isolinux/syslinux permet de lancer au choix le noyau 32 ou 64
    Deuxième constat : pas l’efi ! seul les noyaux 64 sont présents dans les fichiers de conf

Les essais :

  • En utilisant Grub2 inclus dans l’iso (il s’agit d’une version 2.00 pas 1.99)
    rescue64 par défaut : freeze apparent sur "loading kernel modules"
    rescue64 avec nomodeset : boot en init3 mais impossible de lancer X "no screen found"
    altker64 par défaut : comme rescue64
    alterker64 avec nomodeset : comme rescue64 nomodeset

J’ai réitéré les essais en incluant l’option setkmap=fr pour éviter l’invite au démarrage. J’ai pu alors constaté qu’en fait le freeze précédent n’en n’est pas un, c’est uniquement l’affichage qui coince. La preuve en est que j’ai pu arrêté proprement l’OS avec un Ctrl-Alt-Backspace

J’ai donc refait les essais en passant l’option forcevesa au lancement. Ça n’a rien apporté, certainement parce que qui dit VESA dit BIOS, chose dont sont dépourvus les Mac.

  • En utilisant les possibilités de boot EFI direct de rEFInd (en paramétrant refind.conf avec les mêmes options que grub2)
    rescue64 par défaut : comme grub2 ci-dessus mais sans aucun autre affichage que l’écran de lancement de rEFInd
    resccue64 avec nomodeset : idem, la clé est sollicitée mais l’affichage reste sur l’écran de lancement de rEFInd
    altker64 avec ou sans nomodeset : comme les deux précédents, mais comme je voyais des chargements à partir de la clé, c’est là que j’ai eu l’idée de taper la keymap souhaitée en aveugle => d’où l’option setkmap=fr essayée ci-dessus

J’ai bien sûr refait mes essais en ajoutant un setkmap=fr et la conclusion est la suivante : le système est bien lancé mais aucun affichage n’est géré.
Mon MacBookPro possède une carte graphique nVidia GeForce 8600M et le driver nouveau à l’air de poser quelques soucis avec le KMS (d’où l’option nomodeset).

Il faudrait pouvoir réitérer les essais sur un Mac avec une puce Radeon ou Intel mais je n’ai pas ça sous la main.
Pour cibler le cas des Mac Mini de françois : suivant le modèle exact, ils peuvent être équipés de puce Radeon (jusqu’à fin 2005 puis à partir de jullet 2011), de puce Intel (2006-2007) ou de puce nVidia (début 2009 à milieu 2010).
On n’est pas dans la m***e !

Au passage, j’ai pu voir sur le site de SysRescue CD qu’ils patchent leurs noyaux avec des trucs en provenance de Fedora 16 et 18. Je n’ai pas regardé en détail si c’était lié à l’EFI.

Là, ça va faire 4 heures que je m’agace dessus donc je vais faire une pause sinon mon Mac va apprendre à voler.
J’essaierai de me connecter par SSH à une session sans aucun affichage pour voir si j’ai des messages d’erreur parlants.

Concernant mon Mac de test, je précise que même si j’ai toujours galéré pour le faire démarrer sous Linux (obligé d’installer rEFIt et poser Grub un peu partout voire créer des partitions particulières), je n’ai jamais eu de souci d’affichage sur les diverses install en dur que j’ai pu faire: Debian (Lenny ou Squeeze, me rappelle plus), OpenSuse, Fedora ou LMDE.

À plus tard pour de nouvelles aventures …

1 J'aime

Je vais retravaillé sur ce sujet dans les deux semaines qui viennent