wiki:Blog/MaJGentoo20070OVH

Mise à jour d'une Gentoo 2007.0 OVH en ~x86 avec Paludis !

Salutations! Dans ce mini-HOWTO, je vais relater mes tribulations lors de la mise à jour d'une distribution Gentoo 2007.0 x86 (32b) installée par OVH sur leurs offres de serveur dédiés. Le but étant de tourner sous une Gentoo ~x86 à jour, avec le dernier profil disponible actuellement (2008.0/server), et en utilisant paludis à la place de portage.

1 - Partitionnement

Dans un premier temps, nous allons commencer par réinstaller la distribution via le manager OVH, afin d'utiliser une table de partition moins ridicule…

Dans mon cas, j'utilise la disposition suivante, mais comme à l'accoutumée, selon votre utilisation, vous avez peut-être l'habitude d'organiser cela différemment. Si vous savez à peu près ce que vous faites, ce n'est donc pas strictement à suivre au pied de la lettre.

/dev/sda1128M/bootext3
/dev/sda215G (15360M)/ext3
/dev/sda37.5G (7680M)/usr/portagereiserfs

À partir de la, on ne fait plus que des partitions logiques. Donc sda4 saute, vu que c'est la partition étendue.

/dev/sda510G (10240M)/var/tmpreiserfs
/dev/sda62G (2048M)/tmpreiserfs
/dev/sda72G (2048M)swap
/dev/sda8*/homereiserfs

Une fois la réinstallation terminée, on peut enfin commencer les choses sérieuses!

1.5 - Systèmes de fichiers & tweaks

Histoire d'améliorer un peu les performances, il peut être appréciable de passer les partoches ext3 en mode full journaling et dir_index.

Pour cela, il va nous falloir passer par un coup de recovery via le manager ovh…

Une fois passé en NetBoot? "rescue-pro" via le manager, on fait un petit "reboot" soft, et on attend le mail d'OVH contenant le mot de passe root du rescue…

Oui, on a besoin de passer en rescue, vu que ces modifications ne peuvent être effectuées que sur une partition NON montée… Or, comme la partition que l'on souhaite modifier et la partoche /, on n'a pas d'autres choix… (Si c'était autre chose que /, non critique, genre /home, on aurait pu effectuer la modification depuis le système réel, en la démontant à chaud avant).

NB: À la reconnexion, SSH va crier que le REMOTE HOST IDENTIFICATION HAS CHANGED, c'est normal avec une configuration SSH classique… Il suffit d'aller éditer ~/.ssh/known_hosts pour dégager le fingerprint correspondant à votre machine. Ça sera à refaire à la sortie du mode rescue.

On va donc aller activer tout ce petit monde sur chaque partoche ext3 (dans mon cas, sda2, pas la peine de trafiquer le /boot) ;).

tune2fs -o journal_data -O has_journal,dir_index /dev/sda2
e2fsck -fD /dev/sda2 

Et voilà, c'est tout :).

On repasse en boot "hd" dans le manager, et on "reboot" ;).

En passant, pensez à éditer le fichier /etc/fstab pour ajouter l'option noatime à tous les systèmes de fichiers ext3, et notail,noatime à toutes les partoches reiserfs.

Une fois notre affaire terminée, on peut sortir du recovery en rebootant sur notre système tout propre!

2 - Configuration de Portage

Oui, je sais, j'ai dit qu'on allait utiliser paludis à la place de portage, mais il nous faut quand même une configuration minimale ;).

Notament passer en ~x86, et configurer quelques USE flags.

Prenez exemple sur mes configs.

À noter que pour le moment, la version de GCC installée ne supporte pas le flag -march=native, remplacez donc le par "prescott" (ou autre, selon votre machine) en attendant de mettre à jour le toolchain.

2b - Installation de quelques paquets…

C'est une étape relativement personnelle, j'ai besoin de certains paquets pas encore installés (notamment subversion) afin de faire fonctionner correctement certains de mes scripts bash.

(D'où la config subversion dans le package.use, pour éviter d'avoir une caisse de dépendances à installer).

On commence tout d'abord par mettre à jour notre arbre Portage…

emerge --sync

Et ensuite nos petits programmes…

emerge -av htop subversion

3 - Installation de Paludis

Rien de bien sorcier pour l'instant…

emerge -av paludis

4 - Configuration de Paludis

C'est la que ça devient plus rigolo. Pour ceux qui ne connaissent pas paludis, je vous invite à aller faire un tour sur le site officiel.

Dans mon cas, je fais toujours une configuration manuelle à partir de 0.

J'importe donc mes configs ;).

En plus des fichiers en eux-mêmes, on va avoir besoin de créer quelques répertoires, et corriger quelques permissions…

mkdir -p /etc/paludis
chown -cvR paludisbuild:paludisbuild /usr/portage
mkdir -p /var/tmp/paludis
chown -cvR paludisbuild:paludisbuild /var/tmp/paludis/
chmod -cvR ug+rwX /var/tmp/paludis/
mkdir -p /usr/local/overlays
chown -cvR paludisbuild:paludisbuild /usr/local/overlays/
mkdir -p /var/cache/paludis/metadata

On importe ensuite nos configs dans /etc/paludis…

Attention, n'oubliez pas d'éditer le fichier /etc/paludis/bashrc pour que la variable NPTL_KERN_VER (en fin de fichier) soit réglée sur la version du noyau livrée par défaut avec votre machine, le tout au format à 3 chiffres, ie. 2.6.24, sous peine de gros, gros, gros soucis!

Un petit coup d'uname -a pour vérifier ça ;).

uname -a
vim /etc/paludis/bashrc

Et on peut attaquer la double synchro initiale… (Double pour que paludis reconnaisse correctement le nom de nos overlays personnalisés).

paludis -s
paludis -s
paludis --regenerate-installed-cache
paludis --regenerate-installable-cache

Et on s'occupe de lire les news (qui datent un peu… :P).

eselect news read 2007-05-04-paludis-0.24

5 - Mise à jour initiale du système de base… Et correction des différents blockers rencontrés…

C'est la que ça va devenir sportif! En raisons de l'âge du ghost installé par OVH, la procédure de mise à jour ne va pas être aussi simple que l'on aurait voulu…

Mais rassurez vous, ce ne sont pas quelques blockers dans l'arbre de dépendance qui vont nous arrêter ;).

Dans un premier temps, c'est le paquet coreutils qui va bloquer avec mktemp… On corrige ça!

paludis -i1 --dl-blocks discard --dl-upgrade as-needed coreutils

Ensuite, il ne nous reste plus qu'à tenter de désinstaller mktemp

paludis -pu mktemp

Et l'on se rend compte que nos amis baselayout & debianutils dépendent de mktemp… On va donc devoir les mettre à jour!

Et évidemment, en passant, on va se manger la migration du système d'init baselayout 1 à la v2 sous OpenRC

On va donc en profiter pour installer un petit gestionnaire de mise à jour des fichiers de configs un chouilla plus utilisable que l'outil etc-update de base…

paludis -i --dl-upgrade as-needed cfg-update imediff2

En passant, on se mange une migration de Python 2.4 à 2.5, donc histoire de faire ça proprement, on va devoir utiliser python-updater comme demandé, mais pour éviter les soucis, on va attendre d'avoir résolu tous nos blocs…

Mais avant tout, on va configurer cfg-update pour utiliser imediff2, de loin l'outil CLI le plus simple pour gérer les conflits de merge de fichiers texte…

vim /etc/cfg-update.conf

Remplacez la valeur de MERGE_TOOL vers /usr/bin/imediff2 et c'est bon :).

On peut lancer notre première update :). Il va crier un peu à propos du bashrc de base, c'est normal.

cfg-update -u
source /root/.bashrc
cfg-update -u

Petite explication rapide du fonctionnement d'imediff2.

Lors d'un conflit, les deux côtés (votre fichier actuel (A) et le fichier mis à jour (B)) sont affichés l'un en dessous de l'autre. Comme vous vous en doutez, à chaque conflit (Utiliser N/P pour passer au conflit Suivant/Précédent), tapez sur A ou B selon le côté que vous voulez conserver.

Une fois tous les conflits résolus, on tape sur S pour sauvegarder, et zou ;).

cfg-update apprendra petit à petit vos modifications personnelles, et ne vous redemandera pas d'intervention manuelle si elles n'entrent plus en conflit avec les prochaines màj. Ça vous fera gagner un temps fou :).

Une fois que c'est fait, on peut revenir à notre bloc initial de coreutils en mettant à jour baselayout et debianutils pour pouvoir supprimer mktemp

paludis -i1 --dl-blocks discard --dl-upgrade as-needed baselayout debianutils

On va donc ensuite se taper la migration vers OpenRC… Je vous invite donc à lire la documentation dédiée

En gros, perso j'édite tout ça:

nano -w /etc/rc.conf
rm /etc/conf.d/rc
nano -w /etc/conf.d/hostname
nano -w /etc/hosts
nano -w /etc/conf.d/hwclock
nano -w /etc/conf.d/keymaps
nano -w /etc/conf.d/net
nano -w /etc/timezone

Oui, faites TRÈS ATTENTION à la mise à jour de /etc/conf.d/net, vu que le format à changé, et si par malheur vous vous plantez, c'est passage en mode recovery pour corriger ça… Le nouveau devrait ressembler à ça chez OVH (en remplaçant les A/B/C/D par l'IP qui va bien évidemment):

config_eth0="A.B.C.D/24"
routes_eth0="default gw A.B.C.254"

Une fois cette épine retirée de notre pied, on peut continuer notre petit bonhomme de chemin… On va enfin pouvoir dégager mktemp!

paludis --permit-unsafe-uninstalls -u mktemp

Et on finit d'éliminer un autre petit bloc avec la dernière version de baselayout et util-linux

paludis -i1 --dl-upgrade as-needed debianutils util-linux

Au cas où, on va updater le profil pour portage… (C'est déjà fait pour paludis via le fichier de config du repo gentoo).

eselect profile list
eselect profile set 11

(Modifier le "11" selon votre choix, dans mon cas à l'heure ou j'écris cela, ça correspond au profile x86 2008.0/server).

On va ensuite enchaîner en dégageant le joyeux bordel de monitoring d'OVH, vu que je ne m'en sers pas, et que je n'utilise pas l'overlay OVH… De même pour le gestionnaire d'overlay Portage, vu qu'on utilise Paludis.

paludis -u rtm
paludis -u layman

Ensuite, on va utiliser mon petit script de gestion des mises à jour pour voir si on a bien résolu tout nos blocs…

wget http://svn.ak-team.com/svn/Bash/trunk/paludis-upd
chmod -cvR a+x paludis-upd
./paludis-upd
./paludis-upd
./paludis-upd world p

Selon vos USE flags, il se peut que vous tapiez dans une dépendance circulaire insolvable sur glib/gamin. Afin de résoudre l'histoire, on va temporairement désactiver le flag USE fam sur dev-libs/glib via le fichier /etc/paludis/use.conf (Cf. mon fichier).

paludis -i1 --dl-upgrade as-needed glib gamin

Une fois que c'est fait, on peut dégager l'override d'USE sur glib ;).

Un autre block que vous risquez de rencontrer, c'est celui de la mise à jour de syslog-ng, qui déprécie le paquet libol. On attaque donc ça…

paludis -i --dl-upgrade as-needed syslog-ng
paludis -u libol

Et on enchaîne avec le prochain block, la mise à jour d'e2fsprogs qui déprécie sys-libs/ss et sys-libs/com_err. On va donc s'en occuper…

paludis -u --permit-unsafe-uninstalls sys-libs/ss sys-libs/com_err
paludis -i --dl-upgrade as-needed e2fsprogs

Évidemment, je ne le précise pas forcément à chaque fois, mais n'oubliez pas de relancer un petit cfg-update -u à chaque fois que c'est nécessaire. (paludis vous l'annonce à la fin de chaque exécution si des mises à jours de fichiers de configs sont disponibles).

La fin est proche! On va s'occuper de régler encore quelques blocs, en commençant par baselayout 2 en s'assurant d'avoir un udev récent… Ça peut aider si on veut booter correctement :p…

paludis -i --dl-upgrade as-needed udev

Vient ensuite le tour de portage qui nécessite une version récente de bash

paludis -i1 --dl-upgrade as-needed portage bash

On va ensuite s'occuper de notre mise à jour python de tout à l'heure…

paludis -i --dl-upgrade as-needed python-updater

Pour éviter le bordel, on va ruser un peu au niveau des arguments que python-updater passe à paludis, histoire d'éviter de se taper toutes les mises à jours tout de suite, vu qu'on s'en occupera nous même plus tard ;).

Du coup, même si python-updater gère déjà paludis via le switch -P paludis, on va gérer tout ça nous même en rusant un peu…

python-updater -i -c 'xargs paludis -i1 --dl-upgrade as-needed'

Et voilà! On va pouvoir attaquer la maj initiale du toolchain!

6 - Mise à jour initiale du toolchain

Pour ceux qui ne suiveraient pas trop dans le fond, on rappelle rapidement en quoi consiste le toolchain… C'est tout simplement, comme son nom l'indique, la chaîne d'outil de base du système… À savoir: les headers kernel Linux et la glibc (bibliothèque standard C), binutils (le linker ELF) et enfin GCC (le compilateur C/C++, et la bibliothèque standard C++).

Afin de me sentir plus à l'aise, je choisis en général ce moment la pour passer sous un shell de qualité, j'ai nommé zsh… Si vous n'avez jamais essayé, je vous y invite ;). On va donc l'installer, puis utiliser ma super config personnalisée ;).

paludis -i --dl-upgrade as-needed zsh screen most colordiff
wget http://svn.ak-team.com/svn/Configs/trunk/DotFiles/dot.zshrc -O ~/.zshrc
exec zsh

Une fois sous zsh, et une fois vos soupirs d'admiration passés, on va commencer par utiliser mes configs personnalisées pour zsh/screen/vim/nano…

syncfg

Et on va enfin pouvoir attaquer la màj du toolchain à proprement parler… (Attention, cela nécessite d'utiliser ma config de set "toolchain" pour Paludis! Cf. toolchain.conf).

Cette étape va prendre une petite heure, selon le CPU, vous voilà prévenus… ;).

pal -i --dl-reinstall-targets always --dl-upgrade as-needed toolchain

S'ensuit un petit cfg-upate -u, et le passage à GCC 4.3 via l'outil gcc-config!

gcc-config -l
gcc-config 2
envup

(En remplaçant le "2" par l'option qui correspond au GCC le plus récent disponible ;)).

On va donc profiter de notre nouveau GCC tout beau pour utiliser le flag -march=native dans nos CFLAGS Paludis!

(Et créer un petit répertoire bidon pour faire plaisir au profil shell de base).

vim /etc/paludis/bashrc
mkdir /etc/profile.d
touch /etc/profile.d/foo.sh
envup

On recompile ensuite notre TC avec GCC 4.3 et nos nouveaux CFLAGS

pal -i --dl-reinstall-targets always --dl-upgrade as-needed toolchain

On va ensuite configurer les locales à générer pour notre machine…

vim /etc/locale.gen
locale-gen

Personnellement, je ne génère que celles-ci:

en_US ISO-8859-1
en_US.UTF-8 UTF-8
fr_FR ISO-8859-1
fr_FR@euro ISO-8859-15
fr_FR.UTF-8 UTF-8

7 - Mise à jour du système

On va enchaîner avec la mise à jour des paquets installés… En commençant par installer les sources d'un noyau récent, dont on s'occupera un peu plus tard…

pal -i --dl-upgrade as-needed gentoo-sources

Et on peut lancer la mise à jour globale du système! (Via mon petit script paludis-upd).

./paludis-upd world i
cfg-update -u

(NB: J'ai rencontré divers soucis d'USE flag, ou d'échec de compilation parallèles au cours de cette étape, mais si vous utilisez ma config Paludis, tout devrait passer sans aucun soucis ;)).

Juste pour être sûr, on va relancer lilo un coup… (En démontant/remontant /boot avant, pour éviter d'éventuels délire si la partoche est montée en lecture seule…).

umount /boot
mount /boot
lilo

Et dans la série on corrige les setups rigolos d'OVH, on va faire un peu de ménage dans le bordel préinstallé par OVH afin de ne pas avoir de soucis avec OpenRC

rm /etc/init.d/net.eth1
rm /etc/runlevels/default/net.eth1
rm /etc/init.d/runscript.sh
rm /etc/init.d/depscan.sh
rm /etc/init.d/open-iscsi
/lib/rc/bin/rc-depend -u

Ça devrait nous donner la voie libre pour effectuer notre premier reboot, afin de vérifier si tout fonctionne encore correctement avant de nous configurer un noyau au petits oignons…

Croisez donc les doigts un bon coup, et lancez le "reboot" fatidique! (Rassurez vous, si tout s'est déroulé correctement, tout devrait passer sans problème!).

NB: Vous voudrez peut-être mettre en place vos clés SSH publiques et changer le mot de passe root avant le reboot. (Et éventuellement déactiver complètement les logins par MDP et/ou root via SSH, selon vos habitudes). Je vous laisse le soin de gérer tout ça comme vous avez l'habitude de le faire :).

reboot

8 - Mise à jour du Noyau

Hop! La machine a rebooté sans soucis, on peut attaquer notre config noyau

Pour les plus frileux d'entre vous, ma config est dispo ici.

N'oubliez pas de vérifier le CPU, le contrôleur SATA/PATA, la carte réseau, et éventuellement les systèmes de fichiers. Ça devrait passer sur la plupart des dédiés OVH. (Possesseurs de RPS, passez votre chemin, je n'en ai pas à ma disposition, et du fait de nature même du RPS, cette config à approximativement 242% de chances d'empêcher votre RPS de booter. :p).

Comme à l'habitude, dans tous les cas, lspci est votre ami, on va donc l'utiliser pour examiner le matos avant toute chose…

update-pciids
lspci

Et on peut attaquer la config du noyau (via mon fichier de config).

cd /usr/src/linux
wget http://svn.ak-team.com/svn/Configs/trunk/Kernel/kconf-echo -O .config
make oldconfig
make menuconfig

Pour les autres, je vous laisse le soin de configurer la bête…

cd /usr/src/linux
make allnoconfig
make menuconfig

Une fois la configuration effectuée, on compile et on installe la bête!

make -j2
make install
cd /boot
ln -s vmlinuz-2.6.26.2-niluje-r1 vmlinuz
ln -s config-2.6.26.2-niluje-r1 config
ln -s System.map-2.6.26.2-niluje-r1 System.map
cd -
make install

Notez les symlinks faits manuellement… Le make install s'occupera seul de régénérer ces symlinks à chaque nouveau kernel, ça nous permet de ne pas avoir à éditer le lilo.conf à chaque mise à jour de noyau ;).

En parlant de lilo, on va évidemment le configurer pour utiliser ce système de symlink!

vim /etc/lilo.conf

Pour vous donner une idée, le mien ressemble à ça:

prompt
timeout=50
default=gentoo
boot=/dev/sda
map=/boot/map
install=/boot/boot.b
lba32
append=""
#serial=0,9600n8

image=/boot/vmlinuz
        label=gentoo
        read-only
        root=/dev/sda2

image=/boot/vmlinuz.old
        label=gentoo-old
        read-only
        root=/dev/sda2

image=/boot/bzImage-2.6.24.5-xxxx-grs-ipv4-32
        label=linux
        read-only
        root=/dev/sda2

Les modifications consistant à rajouter les image pointant vers /boot/vmlinuz & /boot/vmlinuz.old, et passer l'image pointant vers vmlinuz en default :). (Gaffe, ne faites pas un copier/collé brut de cette config, il y a de fortes chances que votre partoche / ne soit pas montée sur /dev/sda2 comme moi…).

Une fois que c'est fait, on est prêt à relancer lilo, et à rebooter sur notre noyau tout propre… (Vous êtes tout à fait excusés pour les éventuels croisement de doigts de pieds intempestifs durant cette étape :p).

lilo

Si tout est bon côté lilo, on peut reboot

reboot

9 - Rebuild du système

Et hop, votre jolie machine à booté avec succès sur notre noyau tout propre, on va pouvoir attaquer la phase finale, j'ai nommée la recompilation complète de notre système!

Comme vous vous en doutez, cette étape va prendre un certain temps, mais nécessite en contrepartie relativement peu d'interaction humaine, vous pouvez donc relativement sans soucis enchaîner les commandes de build, même si elles sont spécifiés une par une ici ;).

On va commencer par aller éditer notre bashrc paludis pour régler la variable NPTL_KERN_VER vers le numéro de version de notre kernel tout neuf, comme on l'avait fait au début de notre installation pour le noyau OVH.

(Pour ceux que ça intéresse, cela fixe le noyau minimum cible sur lequel notre glibc peut fonctionner… Ça permet de compiler uniquement le code ciblé pour notre noyau, mais on ne peut du coup plus utiliser de noyaux plus vieux… D'où le soucis initial si vous compiliez une glibc avec un NPTL_KERN_VER supérieur au noyau de base OVH… La machine refuserait de booter, ne vous laissant plus comme possibilité que de prier pour qu'il y ait un kernel assez récent disponible en netboot chez OVH… :). C'est aussi valable en cas de chroot via le recovery… Mais AFAIK, le kernel du recovery OVH est relativement à jour ;)).

vim /etc/paludis/bashrc

On recompile ensuite notre toolchain contre ce noyau minimum…

./paludis-upd toolchain i

Puis le système de base…

paludis -i --dl-reinstall-targets always system

Puis le système complet

paludis -i --dl-reinstall-targets always everything

(Oui, c'est un poil abusif, je vous l'accorde, on recompile un peu beaucoup de monde plusieurs fois pour pas grand chose, voire rien du tout, maaais bon :p).

<TODO: Install eix>

<TODO: Purge GCC/Python/Slots>

paludis --permit-unsafe-uninstalls -u dev-lang/python:2.4
paludis --permit-unsafe-uninstalls -u =virtual/c++-tr1-type-traits-0 =virtual/c++-tr1-memory-0 =virtual/c++-tr1-functional-0 sys-devel/gcc:4.1
paludis --report

<TODO: Petits trucs utiles... NTP + hwclock local/systohc, lm_sensors, microcode-ctl, opcode cacher PHP (xcache/eac/apc)>

Last modified 10 years ago Last modified on Feb 24, 2009, 1:13:12 PM