Gentoo, le retour… de la malchance chronique ?

Après avoir tenté une funtoo (qui reprend les mêmes base de la Gentoo) en octobre 2011, j’ai voulu retenter l’expérience, mais en partant d’une Gentoo, cette fois-ci.

Malgré un bug connu qui plante les ISOs hebdomadaires depuis en gros juin ou juillet dernier, empéchant une connexion réseau automatique, et que la solution est d’utiliser SystemRescueCD (basée sur Gentoo), j’ai voulu essayer une nouvelle fois d’installer une Gentoo avec Xfce dessus. Histoire d’en apprendre un peu plus sur les tripes gnu/linuxiennes.

J’ai donc créé une machine virtuelle pour lancer l’installation de la Gentoo dedans, en suivant le guide d’installation.


[fred@fredo-arch ISO à tester]$ qemu-img create -f qed disk-gentoo.img 128G
Formatting 'disk-gentoo.img', fmt=qed size=137438953472 cluster_size=65536 table_size=0
[fred@fredo-arch ISO à tester]$ kvm64 -hda disk-gentoo.img -cdrom systemrescuecd-x86-3.0.0.iso -boot order=cd &

Comme partitionnement ? Le suivant.

  • /dev/sda1 ; /boot ; 512 Mo en ext2
  • /dev/sda2 ; swap ; 4 Go
  • /dev/sda3 ; / ; 16 Go en ext4
  • /dev/sda4 ; /home ; le reste en ext4

Coté paquets précompilés et ports, c’est assez frais, même si on peut rafraîchir la liste des ports par la suite.

L’outil de gestion des miroirs est toujours aussi pratique à l’utilisation.

Le profil de compilation ? Le premier « desktop ». Et coté fraicheur logiciel, c’est pas franchement ça. Je comprends aisément le choix d’un noyau « support long terme », sauf qu’il y a au moins 4 versions depuis qui sont sorties 🙁

Et pour éviter de faire une fausse manipulation au niveau des options à activer, j’ai utiliser genkernel.

A moins que ce ne soit une numération revue et corrigée par l’équipe de la Gentoo ?

En tout, je ne saurais jamais, la compilation se plante dans un module, me laissant avec quelque chose d’inutilisable sur les bras 🙁

A chaque fois que j’essaye de virtualiser une gentoo ou une funtoo, il y a toujours quelque chose qui finit par me bloquer. Et avant que certaines personnes me fasse une remarque assassine du genre : « Une gentoo, ça ne s’utilise que sur du matériel réel », expliquez celà à l’équipe de VirtualBox qui propose des profils adaptée à la Gentoo.

8 réflexions sur « Gentoo, le retour… de la malchance chronique ? »

  1. Je viens de faire récemment une installation de Gentoo, et je n’ai rien remarqué d’anormal (je suis en x86, i486). En ce qui concerne la connexion réseau, `dhcpcd eth0′ fonctionne non ?

    Pour la compilation du noyau, même avec genkernel, tu peux « charger » une configuration prédéfinie en faisant `make x86_64_defconfig’ (dans ton cas), suivi de `genkernel all’.

    Une autre solution, consiste à charger la configuration du noyau du liveCD avec la commande `make localmodconfig’ puis `genkernel all’.

    Une dernière remarque, avant de compiler son noyau, il vaut mieux vérifier que le fichier /etc/fstab soit correct. La partition de boot doit avoir le bon « flag » sinon GRUB risque de se plaindre (j’oublie régulièrement ceci).

    Voilà s’était juste quelques points que je tenais à apporter, n’étant pas moi-même un spécialiste de Gentoo.

    1. Non, le dhcpcd répond aux abonnés absents. Cf le rapport de bug cité dans l’article.

      Merci pour les « tips » concernant le noyau. Quand j’aurais le temps, je réessayerais. La compilation plantait au niveau des modules. Je ne pense pas qu’il y a un lien quelconque avec l’existence ou pas du /etc/fstab, non ? 😉

      Encore une fois, merci pour les infos.

  2. Perso genkernel c’est de la daube, il vaut mieux mettre ses main dans le cambouis au moins on comprend ce que l’on fait, et il suffit juste de connaître son métériel.

    1. Quant il y aura une autodétection ce sera plus simple. Et puis, un noyau 3.4.9, bof quoi, surtout que le dernier 3.4, c’est le 3.4.15 actuellement. Pas que je sois un super fan du noyau LTS 3.4, mais fournir une version plus récente ne serait pas un mal.

  3. Salut Frédéric, j’ai vu que tu as installé une Gentoo stable.

    C’est normal, que ça soit un peu en retard, car une Gentoo Testing c’est vraiment très très à jour. À propos de l’installation en virtuelle, je ne vois pas le problème, c’est clair que tout fonctionne à 100%, sauf les effets 3D, car c’est soit virtualbox ou kvm qui vont te bloquer cette fonctionnalité.

    Enfin, attend encore quelques temps pour retenter une installation, nous allons produire un handbook d’installation simple et très complet chez gentooquebec.

    Dès que c’est prêt, je vais te faire signe.

    Dernière chose, on installe une Gentoo avec amour 😛 Et pour ma part, si quelqu’un bidouille avec une Gentoo, c’est une Gentoo Testing, sinon c’est rien du tout.

    A+

    1. Testing, très à jour ? Du genre noyau 3.6.x ? Et j’ai tenté d’installer, ça a planté au niveau de la compilation des modules du noyau 🙁

      Et retenter une installation, pas avant quelques temps. Je dois dire que j’attends un manuel plus simple que l’officiel qui est assez ennuyeux à suivre par moment 🙁

  4. Testing, non je parle du noyau 3.7 et de GCC 4.7.

    Tu peux essayer le noyau 3.6 avec les vanilla-sources, par contre si tu prend les git sources, c’est carrément le dépôt de Linus, donc 3.7-rc quelque chose.

    Pour Gentoo, il y a en fait, 3 dépôts, Stable,Testing,Live/Overlay.

    Les dépôts Live/Overlay, on les gère avec Layman et tu peux tester des trucs très très récents, genre KDE en version Live-Build(code source provenant des dépôts de KDE). Sinon, il y a des overlays qui sont très expérimentals, genre GCC-Overlay qui rend disponible GCC 4.7.x.

    Pour le manuel, le notre va vraiment être mieux. On va support les disques durs MBR,GPT, le démarrage legacy et UEFI. Enfin, on va supporter les SSD et Btrfs.

    Bref, tous des trucs que Gentoo supporte mais qui n’a pas encore de documentation.

    1. Gcc 4.7 ?

      [fred@fredo-arch ~]$ gcc -v
      Utilisation des specs internes.
      COLLECT_GCC=gcc
      COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
      Target: x86_64-unknown-linux-gnu
      Configuré avec: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id --with-ppl --enable-cloog-backend=isl --disable-ppl-version-check --disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu --disable-multilib --disable-libssp --disable-build-with-cxx --disable-build-poststage1-with-cxx --enable-checking=release
      Modèle de thread: posix
      gcc version 4.7.2 (GCC)

      Et un noyau stable me convient parfaitement. D’ailleurs, c’est toujours la compilation du noyau qui m’a posé des problèmes. Soit il se compile impeccablement et plante au démarrage, soit il ne se compile pas 🙁

      Et je dois avouer que les histoires d’overlay, j’y ai jamais rien pigé 🙁

      Merci pour les éclaircissements.

Les commentaires sont fermés.