Debian Squeeze : dernière ligne droite ? ;)

Alors que l’équipe de développement a fait le point le 13 décembre sur Squeeze qui est dans sa phase terminale de finalisation, uniquement des corrections de bugs liés aux releases candidates et la deuxième béta du Debian Installer, j’ai voulu, 14 mois après un premier article sur Squeeze montrer la version de Debian GNU / Linux presque finie.

J’ai donc récupéré une image DVD de Debian testing récente (histoire d’avoir une installation aussi rapide que possible), et j’ai lancé la machine virtuelle habituelle, en demandant une installation graphique.

[fred@fredo-arch ISO à tester]$ 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, 547,947 s, 62,7 MB/s
[fred@fredo-arch ISO à tester]$ kvm64 -hda disk.img -cdrom debian-testing-amd64-DVD-1.iso -boot cd &

J’ai suivi les options de base, mis à part que j’ai demandé un partitionnement avec une partition /home séparée.

Et j’ai utilisé uniquement le DVD comme source de paquets.

Continuer la lecture de « Debian Squeeze : dernière ligne droite ? 😉 »

PCLinuxOS Gnome 2010.2 Gnome : une introduction en douceur au monde des distributions rolling release.

En mars dernier, j’avais présenté la PCLinuxOS 2010 beta1, à l’époque avec l’environnement KDE. La sortie de la 2010.2 avec un environnement Gnome m’a donné envie de voir la progression en 9 mois. Surtout que c’est une distribution en rolling release, comme ArchLinux, Frugalware ou encore Linux Mint Debian Edition. Dixit PetitBob.

J’ai donc récupéré la distribution, et configurer mon environnement habituel de test. Sauf qu’au lieu d’utiliser la commande kvm64, j’ai utilisé la commande kvm32, car la distribution n’existe qu’en 32 bits – dommage !, qui est un raccourci pour :


qemu -enable-kvm -localtime -soundhw all -k fr -m 1500 -net user -net nic,model=rtl8139

Continuer la lecture de « PCLinuxOS Gnome 2010.2 Gnome : une introduction en douceur au monde des distributions rolling release. »

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 ? »

OpenIndiana révision 148 : un bon cru qui annonce une suite encore meilleure ?

J’avais déjà parlé de la sortie de la sortie de la première version officielle de développement d’OpenIndiana, successeur d’OpenSolaris en septembre dernier.

La révision 148 est sortie très récemment, et j’ai eu envie de la tester et de faire un rapide tour basé sur l’impression générale ressentie. Je l’ai donc récupéré avec wget.

[fred@fredo-arch ISO à tester]$ wget -c http://dlc.openindiana.org/isos/148/oi-dev-148-x86-20101216.iso
–2010-12-18 10:50:27– http://dlc.openindiana.org/isos/148/oi-dev-148-x86-20101216.iso
Résolution de dlc.openindiana.org… 93.188.131.173, 93.188.131.131
Connexion vers dlc.openindiana.org|93.188.131.173|:80…connecté.
requête HTTP transmise, en attente de la réponse…200 OK
Longueur: 918431744 (876M) [application/octet-stream]
Sauvegarde en : «oi-dev-148-x86-20101216.iso»

100%[======================================>] 918 431 744 1,09M/s ds 14m 6s

2010-12-18 11:04:33 (1,04 MB/s) – «oi-dev-148-x86-20101216.iso» sauvegardé [918431744/918431744]

Pour me simplifier la tache, j’ai récupéré l’image disque que j’avais utilisé pour essayer d’installer une Linux From Scratch. J’ai ensuite lancé ma machine virtuelle habituelle :

kvm64 -hda disk.img -cdrom oi-dev-148-x86-20101216.iso -boot d &

Lors du démarrage, je demande à avoir le clavier et la langue française activée dès le chargement.

Au démarrage, on s’aperçoit que la reconnaissance matérielle s’est amélioré, car tout le matériel émulé par la machine virtuelle kvm est reconnu. Ce qui est déjà un progrès énorme par rapport au test que j’avais jadis effectué à l’époque d’OpenSolaris 2009.06, dernière version officielle d’OpenSolaris.

Continuer la lecture de « OpenIndiana révision 148 : un bon cru qui annonce une suite encore meilleure ? »

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é !