Utiliser une machine virtuelle pour tester un OS, c’est ne pas l’utiliser vraiment ?

Certaines personnes m’ont fait remarquer que je ne prenais pas la peine d’utiliser une partition réelle de mon disque dur pour tester les distributions Linux, les BSDs et autres OS qu’il m’arrive de présenter. Et que cela n’était pas bien

Ce qui m’a valu quelques gentillesses, comme celle d’être traité de demi-mots de mythomane sur identi.ca

Mais passons outre cette polémique de propos qui ressemble à ceux d’une époque digne d’Oncle Joe et venons en au coeur du problème : pourquoi utiliser une machine virtuelle plutôt qu’une partition en dur ?

Pour plusieurs raisons :

  1. Car c’est plus simple de créer une image disque que de partitionner un disque dur. En cas d’erreur, on efface le fichier et on recommence. Tandis qu’avec une partition…
  2. Car le matériel émulé depuis l’arrivée des instructions KVM (AMD-V, Intel VT) est aussi rapide que le matériel réel, au moins sur le plan puissance de calcul du microprocesseur).
  3. Bien que le matériel émulé ne puisse pas de manière simple accéder aux ressources poussées (comme les fonctionnalités 3D des circuits graphiques) cela permet toujours d’avoir un matériel classique et fonctionnel).
  4. Pas besoin de rajouter / sortir les os installés dans le gestionnaire de démarrage

En gros, c’est largement plus simple d’accès. Certains puristes hurlent à la mort – tel des loups devant la pleine lune – car j’ose utiliser un virtualiseur dans mes présentations… Et me font comprendre qu’en dur, le résultat serait différent.

Continuer la lecture de « Utiliser une machine virtuelle pour tester un OS, c’est ne pas l’utiliser vraiment ? »

Mon pari fou de fin 2010 : installer une LFS 6.7 dans une machine virtuelle kvm ;) – Partie 3…

Dans le précédent article de la série, j’étais resté bloqué car gcc était absent des programmes fournis sur le CD live utilisé.

J’ai donc récupéré le SystemRescueCD, et j’ai relancé l’installation dans la machine virtuelle dont j’avais conservé l’image disque, en recréant après le lancement les partitions par soucis de partir sur une base propre.

kvm64 -hda disk.img -cdrom systemrescuecd-x86-1.6.4.iso -boot d &

Tout s’est bien déroulé, sauf que cette fois, je suis bloqué et je n’arrive pas à trouver la solution. En effet, lors de la deuxième compilation des binutils, ceux-ci m’envoient paître, à cause de makeinfo manquant. Hors, ayant suivi au pied de la lettre les instructions, la première compilations des binutils – et de gcc et de la glibc – s’étaient très bien passé.

erreur de compilation des binutils

Ce qui est dommage. A croire que je ne dois pas avoir un bon « feeling » avec les distributions sources 🙁

Et j’ai la conscience tranquille, car au moins, j’ai essayé !

Mon pari fou de fin 2010 : installer une LFS 6.7 dans une machine virtuelle kvm ;) – Partie 2…

Dans le précédent article, j’avais récupéré les paquets sources.

Après avoir créé l’utilisateur lfs, j’ai demandé que les options de compilations soient :

export MAKEFLAGS='-s -j4'

  • -s = silencieux, c’est à dire uniquement le nom du fichier compilé
  • -j4 = 4 opérations en parallèle

Je suis ensuite allé dans $LFS/sources pour commencer la compilation des paquets.

Pour chaque paquet : tar xvfj (pour les tar.bz2), tar xfvz (pour les tar.gz). Et comme indiqué au point 5.3, j’ai enlevé le répertoire de compilation à chaque fois. Mais je ne suis pas allé très loin… J’avais oublié de vérifier la présence de gcc sur le système live…

Donc, je recommencerais plus tard. Si vous avez un liveCD avec gcc intégré à me proposer, je suis preneur !

Mon pari fou de fin 2010 : installer une LFS 6.7 dans une machine virtuelle kvm ;) – Partie 1…

J’aime par moment me lancer dans des paris un peu fou. Celui-ci ? Installer une distribution Linux From Scratch 6.7 dans une machine virtuelle KVM.

Si je parviens à finir la première étape – à savoir un système qui démarre – je passerais à la deuxième étape : installer Xorg 🙂

Mais commençons par créer un disque virtuel d’une taille de 32 GiO.


[fred@fredo-arch download]$ dd if=/dev/zero of=disk.img count=32768 bs=1M
32768+0 enregistrements lus
32768+0 enregistrements écrits
34359738368 octets (34 GB) copiés, 411,05 s, 83,6 MB/s

Pour avoir un LiveCD léger et fonctionnel, j’ai utilisé un LiveCD Gentoo datant du 9 décembre… Pour la première partie, j’ai fait chargé le noyau gentoo-nofb.


[fred@fredo-arch download]$ kvm64 -hda disk.img -cdrom lfslivecd-x86_64-6.3-r2145-min.iso -boot d &

20 h 20 : le live a démarré. Début de la première partie de l’installation 😉

Je lance le partitionnement : cfdisk /dev/sda

Pour aller au plus simple, j’ai pris deux partitions : / de 30 Go, en ext3, 2 GiO pour swap.

Je sais, j’aurais pu créer des partitions pour /boot et /home, mais j’ai eu la flemme… Et comme c’est une de mes premières tentatives avec une LFS, j’ai eu envie de me simplifier la tache au maximum… Même si c’est très mal de ne pas avoir de /boot et /home séparé. Le ferais plus, promis, juré, craché ! 😉

Pour le formatage :


mke2fs -jv /dev/sda1
mkswap /dev/sda2
swapon /dev/sda2

Pour récupérer les paquets, j’ai utilisé la liste pour wget, en la copiant dans $LFS/sources, puis avec un petit :


wget -i wget-list

Récupération des paquets pour installer une LFS 6.7

Début à 20 h 33, fini vers 20 h 50.

Ce sera tout pour ce soir, je continuerais le lendemain avec la compilation des outils. J’ai pu vérifier que le montage de la partition avec les codes sources se fait bien. Donc, la suite au petit matin, histoire d’être complètement attentif 😉

Quand maître Cyrille décide de tailler une croupière aux distributions rolling release…

Dans son article du samedi 4 décembre, notre bon maître hulk Cyrille Borne, après avoir rebondi sur mon article parlant du dépot rolling release d’OpenSuSE, et après avoir fusillé les dépots backports, a décidé de descendre en flamme les rolling releases.

Je crois qu’on fait une confusion entre la mise à jour de chaque paquet et la mise à jour des applications majeures,

Le terme d’application majeure est relative à l’utilisateur. Pour certains, une mise à jour de leur shell sera une application majeure. Pour d’autre, ce sera le compilateur, voire même le lecteur de musique…

je pense que le grand public veut les grandes applications sans réellement se poser de questions sur le reste.

Soit. Le grand public, ce qui est inexistant pour linux ? 😉

Le même Frédéric s’est retrouvé planté plusieurs fois sur Arch (les prétentieux) ou Frugalware (copains !!!)

Il est vrai que les utilisateurs d’ArchLinux se prennent pour le centre du monde linuxien… A moins que ce ne soit les utilisateurs d’une distribution qui signifie en zoulou : « je ne sais pas configurer Debian » ? 😉

Cependant, mis à part ma crise concernant Python 3, je n’ai jamais été planté très longtemps. Et ce sont de nos échecs que l’on progresse le plus, pas de nos réussites.

parce qu’on a fait monter dans des versions supérieures des paquets qui n’étaient peut être pas réellement nécessaires pour monsieur tout le monde.

Parfois même un correctif de bug peut avoir des conséquences inattendues. Je me souviens d’un bug qui tuait X.org à l’époque de la ubuntu 6.06… Après la sortie de la version finale, soit dit en passant.

Quand on voit parfois le manque de réactivité au niveau d’Ubuntu pour corriger un bug majeur alors que le planning de sortie de tous les 6 mois est déjà considéré comme serré, on peut facilement imaginer ce qui peut se produire quand on va accélérer la cadence, je peux déjà vous donner le prochain nom de la distribution phare « The Millenium Vista Edition ».

Le problème d’ubuntu, c’est une trop grande modification des logiciels d’origine. Il suffit de comparer un gnome installé sur une archlinux ou une debian et la version pour ubuntu… Des distributions qui restent plus proche du code source d’origine seront plus réactives, et s’adapteront mieux au rolling.

Alors que Linux évolue encore et encore pour preuve l’abandon de X par Fedora et Ubuntu, la production d’instabilité du moment n’est pas nécessairement rassurante.

Xorg est encore loin d’être moribond… Attendons déjà une version stable de Wayland et on verra !

Allez, c’est pour quand ton prochain round de « après avoir cassé mandriva, je casse du rolling release » ? 😉