J'ai cherché à réaliser une image disque usb bootable avec grub2. Ça a l'air simplement logique, les images disques USB bootables sont légions, grub2 est un très bon gestionnaire de démarrage, mettre les deux ensembles n'a rien d'incongru.
On peut bien sûr essayer de faire une iso hybride, mais là ce n'est pas le but. Le but est une simple image prête à copier sur une clef USB, le tout sous grub2.
Et bien cela semble très difficile. Tellement difficile qu'à cette question, google ne propose à peu près que des pages dans lesquelles il faut:
1. copier une image disque sur la clef
2. installer ensuite grub sur la-dite clé.
Quelque chose d'aussi simplement évident que d'installer grub2 directement sur l'image avant de copier sur la clé semble infaisable, ou très mal documenté. Voici donc la marche à suivre pour y parvenir.
La première partie (création de l'image) reprend les étapes live-build, le programme debian pour la création de version live, précisément du fichier lb_binary_usb).
Création de l'image
Ici une image de 2000*1024k, soit environ 2G.
dd if=/dev/zero of=binary.img bs=1024k count=0 seek=2000
Trouvons un périphérique loop:
losetup -f
Mettons que /dev/loop0 soit libre et attachons l'image dessus:
losetup /dev/loop0 binary.img
Création de la table des partitions et d'une partition:
parted -s /dev/loop0 mklabel msdos
parted -s /dev/loop0 mkpart primary fat32 50k 100%
La partition est créée avec un décalage de 50k qui va servir à placer grub. Pour attacher et formater cette partition il faut connaitre son décalage exact, que l'on va calculer. D'abord fdisk pour connaitre les infos:
fdisk -l -u /dev/loop0
La sortie ressemble à ceci:
> Disk /dev/loop0: 2 GB, 2097152000 bytes
> 4 heads, 32 sectors/track, 32000 cylinders, total 4096000 sectors
> Units = sectors of 1 * 512 = 512 bytes
>
> Device Boot Start End Blocks Id System
> /dev/loop0p1 97 4095999 2047984 c FAT32 LBA
On y apprend que la taille du secteur est de 512, et que le début de la partition est au 97ème secteur. Le produit 91512 donne le décalage voulu:
expr 97 '' 512
cela donne 49664. Montons cette partition en loop également (mettons que /dev/loop1 soit libre):
losetup -o 49664 /dev/loop1 binary.img
Formatons la partition:
mkfs.vfat -F 32 -n IMAGE_GRUB /dev/loop1
Nous pouvons maintenant libérer loop1:
losetup -d /dev/loop1
Fin de la création de l'image, cette partie là contient grosso-modo les commandes utilisées dans live-build. Rendons bootable cette image.
Installer grub2 sur l'image
Pour que la table des partitions sache que la partition est bootable:
parted -s /dev/loop0 set 1 boot on
Une deuxime commande est utilisée par debian-live, elle doit probablement servir à quelque chose:
parted -s /dev/loop0 set 1 lba off
Montons la partition pour pouvoir installer grub (l'image est toujours attachée à /dev/loop0, et on utilise le décalage calculé précédemment):
mount -o offset=49664 /dev/loop0 /mnt/
Installons grub:
grub-install --disk-module="part_msdos biosdisk" --no-floppy --root-directory=/mnt/ /dev/loop0
Commentaire
Il n'y a rien d'extraordinaire dans tout ça. La seule information difficile à trouver est la dernière commande, grub-install seul ne détecte pas que la partition est sur un périphérique avec une table des partitions msdos, et utilisé classiquement il ne précharge pas le bon module, ce qui fait que l'image est bootable mais que grub ne fonctionnne pas correctement. L'option --disk-module est détournée pour lui donner une liste de modules à ajouter.
Plus qu'à ajouter dans la partition ce qu'on veut booter (la partie live/ d'une debian live, des images iso...) et à créer un grub.cfg en conséquence.
# Plus rapide
Posté par zebra3 . Évalué à 2.
Plus rapide :
# losetup -f binary.img
Sinon, il y a un truc que je n'ai pas compris : pourquoi combiner GRUB2 et les images USB ? Tu as des images qui n'arrivent pas à booter ?
En plus, je me demande si Live Helper ne permet justement pas d'utiliser GRUB.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Plus rapide
Posté par fleny68 . Évalué à 1.
Oui mais pour la suite, il faut savoir quel périphérique loop a été utilisé. D'où le passage en deux étape.
Non, c'est juste que je me suis posé la question, parce que debian-live est cassé dans testing (il manque à isolinux un fichier pour démarrer le live). J'ai voulu installer ça derrière grub2 (en utilisant debian live qui permet de faire un tar.gz avec le contenu), et générer une image (qu'on peut tester dans kvm) me semblait une bonne solution. C'est en cherchant comment faire cette image que j'ai réalisé que cela ne marchait pas directement, et qu'on ne trouve pas vraiment d'information là-dessus.
grub-legacy, c'est à dire le premier. Pour grub2 il semble y avoir un début de travail, mais ce n'est pas encore fait.
[^] # Re: Plus rapide
Posté par zebra3 . Évalué à 2.
Live Helper sur testing, ça a toujours été une grande histoire d'amour. Pendant un moment, il fallait bidouiller les paquets pour générer une image avec le noyau de la testing (à cause de squashfs, si je me souviens bien), donc ça ne m'étonne pas qu'il y ait encore des problèmes, elle évolue trop vite pour l'outil.
Clairement, pour ne pas avoir de problème avec Live Helper, mieux vaut l'utiliser avec la stable.
Ben justement, ce que tu viens de faire ne pourrait-il pas être repris ? ;-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Problème
Posté par fleny68 . Évalué à 2.
Ah zut, il y a des caracères qui ont disparu
> Le produit 91512 donne le décalage voulu:
> expr 97 '' 512
Le produit 97 * 512 donne le décalage voulu:
expr 97 '*' 512
# Je confirme, c'est peu documenté
Posté par fred . Évalué à 2.
Merci pour ta doc !
Dans un même registre, j'avais cherché pour installer Grub2 sur une clé USB sans la reformater, et j'ai buté sur des erreurs d'install (dans grub-install) car Grub2 cherche à copier son MBR+la première partie du boot avant la première partition existante, et si cela ne pose pas de soucis sur un [grand] disque dur, sur une clé, il n'y avait pas assez de blocs disponibles (en gros la place que tu réserves pour ta partition IMAGE_GRUB).
J'avais dû retailler/déplacer la première partition pour pouvoir le faire (mais je n'ai pas le détail sous la main).
# Un script en cadeau bonus
Posté par fleny68 . Évalué à 3.
http://pastebin.com/X3siLpgX
Attention, c'est du bash qui doit pas être trop compatible avec autre chose.
Utilisation (sous le nom de make_image.sh) en root. Il faut que /mnt existe à la racine, et puis awk, fdisk, parted, grub-install, et j'en oublie surement.
Pour faire une image de 2000k appelée binary.img:
> make_image.sh binary.img 2048000
Pour faire une image de pile-poil la taille de /dev/sdb:
> make_image.sh binary.img /dev/sdb
L'image est bootable, grub est installé, sans grub.cfg (qu'on peut rajouter dedans sous /boot/grub)
Amusez-vous bien.
# Pourquoi faut-il préciser le décalage ?
Posté par gremous . Évalué à 2.
Ca c'est de la doc !
J'ai utilisé les périphériques loop plusieurs fois. Certaines fois il n'est pas utile de spécifier le décalage de la partition par rapport au début du fichier, d'autres fois oui.
Lorsque c'est un disque ou une clef USB il n'y a pas besoin d'indiquer ce décalage. Pourquoi faut-il le faire avec loop ? C'est vu comme n'importe quel périphérique donc je me dis que ça devrait réagir pareil.
Une piste ?
[^] # Re: Pourquoi faut-il préciser le décalage ?
Posté par fleny68 . Évalué à 4.
Probablement parce que dans le cas des périphérique loop, le noyau ne lit pas la table des partitions et ne crée pas les entrées dans /dev pour les partitions.
Quand tu mets une clef usb, le noyau:
- crée une entrée, par exemple /dev/sdb, pour l'ensemble de la clef
- crée des entrées pour chaque partition, quelque chose comme /dev/sdb1, /dev/sdb2...
Quand tu attaches un fichier sur un périphérique loop, le noyau ne fait rien de tout ça.
Tu n'a pas besoin de décalage quand le fichier est une seule partition qui commence au début du fichier. C'est la cas des fichiers dits iso (image de cdrom) en général.
# Une solution clé en main MultiSystem
Posté par Julien_J06 . Évalué à 1.
Salut,
J'utilise MultiSystem, qui install Grub et Grub2 sur clé ou disque USB, fonctionne très bien et me permet de au choix, booter sur des live USB (windows et linux) ou booter sur un ubuntu installée sur HDD USB au préalable.
J'ai installé Ubuntu sur un HDD externe que j'utilise au quotidien sur un pc au taf et ensuite j'ai installé MultiSystem. Pour booter sur mon ubuntu, je passe par Grub2 (mais il doit y avoir moyen de rajouter une entrée dans Grub directement)
Plus d'info et de doc ici : http://liveusb.info/dotclear/
Julien_c'est_bien (y'a pas que Seb)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.