Kernel debian et driver e1000e sur kimsufi 16G
Par Dju » 17 septembre 2011 (13:28) - Serveur
Lorsque le kimsufi 16G est livré, est installé dessus un kernel made in ovh. Ce kernel interdit entre autre la gestion classique/manuelle des modules avec lsmod et modprobe, et peut également avoir du retard lors des mises à jour pour les diverses failles de sécurité.
Voici un petit mode d'emploi pour revenir au kernel debian "standard", ainsi que pour installer le module e1000e de la carte réseau, non supporté par le kernel debian.
En court:
- redémarrage en rescue
- installation du kernel debian (à l'heure actuelle le 2.6.32-5-amd64)
- récuperation et compilation du module e1000e
- reboot
On commence donc par aller se logger sur le manger OVH puis on va dans services >netboot et on choisit rescue-pro (et eventuellement le champs en dessous pour son adresse email).
Sur le serveur, un simple /sbin/reboot pour relancer la machine.
2 minutes après, réception d'un mail de ovh avec les identifiants pour se connecter en ssh. c'est la que les choses intéressantes comment
on commence par monter la partition / et les proc/sys/dev pour se chrooter
mount -t ext4 /dev/sda1 /mnt
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
mount -o bind /dev /mnt/dev
chroot /mnt
maintenant qu'on est dans notre environnement habituel, on install le kernel debian, ses headers, et le necessaire pour compiler
aptitude update
aptitude install linux-image-amd64
aptitude install linux-headers-2.6-amd64
aptitude install build-essential
on récupère le driver intel pour la carte réseau e1000e (page officielle sur le site intel ici)
cd /opt
wget http://downloadmirror.intel.com/15817/eng/e1000e-1.5.1.tar.gz
tar xvzf e1000e-1.5.1.tar.gz
cd e1000e-1.5.1/src
ici, bien qu'on soit chrooté, il faut indiquer pour quel kernel on souhaite compiler, car en mode rescue, on tourne sur un kernel ovh, et non le debian standard
export BUILD_KERNEL=2.6.32-5-amd64
et on compile le module
make
make install
NOTE: sur une debian recente, il est possible que vous obteniez une erreur lors de ces 2 commandes. dans ce cas la, compilez en utilisant cette commande :
make CFLAGS_EXTRA=-DDISABLE_PM
make CFLAGS_EXTRA=-DDISABLE_PM install
On n'oublie surtout pas de mettre le module dans la liste des modules à charger au démarrage
echo e1000e >> /etc/modules
Et on vire le kernel ovh, sinon il sera toujours en premier dans grub
cd /etc/grub.d
rm 06_OVHkernel
cd /boot/
rm System.map-2.6.38.2-xxxx-grs-ipv6-64
rm bzImage-2.6.38.2-xxxx-grs-ipv6-64
Et on dit à grub de rescanner les kernels
update-grub
enfin, on démonte le chroot,
exit
umount /mnt/proc
umount /mnt/dev
umount /mnt/sys
umount /mnt
puis on n'oublie pas non plus de retourner sur le manager OVH, dans services > netboot et de choisir HD (sinon ,ça rebootera à nouveau en rescue)
enfin, on redémarre et on croise les doigts :p
/sbin/reboot
Bonjour,
Je suis tombé sur votre article en faisant une recherche sur les serveurs kimsufi. Je vous remercie pour ces explications détaillées.
J'aimerai vous poser une question : j'envisage d'installer un kimsufi 16 avec une distrib CentOS, pour y installer un serveur openvpn. D'après ce que je peux voir, il y a aussi un kernel OVH. Pensez-vous qu'il soit possible de recompiler un kernel original, comme vous l'avez fait pour votre Debian ?
Encore merci pour vos articles.
Bonjour,
pour ce qui est du spécifique à centos, je ne pourrais vous répondre, ne l'ayant jamais utilisé.
Néanmoins, la démarche serait effectivement la même
Accessoirement, il ne s'agit meme pas de recompiler le noyau, puisque c'est le "standard" de la distribution qui est utilisé. Il faut juste y intégrer le driver de la carte réseau.
Pour debian, c'est très axé "libre" donc par défaut il n'y a pas de drivers propriétaires.
Pour ce qui est de Centos, peut être le driver est il il deja inclus dans le kernel "standard" ?
je crois que son kernel est un 2.6.32, donc relativement récent.
Actuellement, sur un Kimsufi 16G, lspci indique ceci pour la carte réseau :
"Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04)"
Eventuellement, la meilleure chose à faire serait, une fois le serveur livré, d'installer via le manager de packages (yum je crois) le kernel "standard" pour centos puis redémarrer dessus afin de voir si le serveur répond
Fil des commentaires de ce billet
URL de rétrolien : https://blog.crifo.org/trackback/85