Commentaire perso : ce n’est pas très sérieux de la part de 1&1 de proposer des distributions obsolètes (non maintenues) comme Debian etch alors que la version suivante lenny est sortie depuis plus d’un an…
Je ne connais pas les serveurs cloud dynamiques de 1&1, mais voici quelques raisons qui pourraient empêcher le redémarrage après la mise à niveau.
Si la nouvelle version du chargeur d’amorçage (grub) ne fonctionne pas correctement avec le serveur cloud ou n’a pas été installée correctement. J’ai vu qu’il était possible de charger et démarrer un noyau directement depuis Linux sans rebooter ni passer par le chargeur d’amorçage grâce à kexec du paquet kexec-tools. Ça peut permettre de tester le système en court-circuitant le chargeur d’amorçage.
Si le noyau n’a pas été mis à niveau et s’il est trop ancien et incompatible avec un composant de la nouvelle version, par exemple la libc (mais je pense que ça se verrait à l’usage même sans redémarrer) ou udev qui est chargé d’identifier le matériel et de charger les modules correspondants (et notamment le pilote de la carte réseau).
Si le noyau a été mis à niveau et :
si 1&1 avait fourni un noyau spécifique car le noyau générique fourni par Debian ne fonctionne pas sur un serveur cloud, par exemple il faut un patch spécifique ou des pilotes qui ne sont pas dans le noyau Debian.
Vérifier la version du noyau d’origine installé par 1&1 (uname -a) pour voir si c’est un noyau Debian standard ou un noyau spécifique, et regarder si un nouveau noyau a été installé pendant la mise à niveau (dans /boot/, /boot/grub/menu.lst).
ou si le changement de noyau a provoqué un changement de nom d’un périphérique (disque, interface réseau…) qui ne correspond plus à la configuration enregistrée (/etc/network/interfaces, /etc/fstab…)
(Pour illustrer, voici une mésaventure qui m’est arrivée. Je compile mes noyaux avec seulement les options nécessaires à mes machines et je n’utilise pas d’initramfs ni udev. J’avais une machine avec un noyau 2.4 et une carte ethernet utilisant le module tulip. En passant au noyau 2.6, j’ai laissé les mêmes options. Or dans le noyau 2.6, la carte ethernet n’est plus gérée par le module tulip mais par un autre que je n’avais pas activé, donc elle n’était plus utilisable. Une autre mésaventure commune aux utilisateurs d’udev est qu’après un changement de noyau l’interface eth0 devient eth1 mais c’est toujours eth0 qui est définie dans /etc/network/interfaces donc eth1 n’est pas configurée.)
Je suis un peu nouveau dans linux, donc si tu pouvais me dir si le problème vien de la et si y’a quelque chose a faire pour régler ça, je te serais reconnaissant
C’est normal que uname rapporte la même version de noyau actif tant que tu n’as pas redémarré puisqu’il faut redémarrer pour changer de noyau actif.
Apparemment le noyau initialement installé avec etch est un 2.6.24 etchnhalf standard de Debian, donc il ne devrait pas y avoir de besoin particulier. Par contre l’examen de menu.lst m’inspire quelques interrogations.
Avant la migration d’etch vers lenny, il ne liste que le noyau 2.6.24 etchnhalf. Après, il liste en plus un noyau 2.6.18 Xen d’etch et un noyau 2.6.26 Xen de lenny. D’où sort le noyau 2.6.18 qui n’est que dans etch et pas dans lenny ?
Pourquoi avoir installé un noyau Xen et pas un noyau normal, alors que le noyau actif jusqu’ici n’est pas Xen ? J’ai eu vent de problèmes avec les noyaux Xen.
Je vois dans les options de démarrage des noyaux des définitions de console sur le port série (ttyS0). 1&1 ne fournit pas un moyen d’accéder à cette console afin de visualiser les messages de démarrage ?
PS : Attention si tu veux tester kexec, il faut le configurer avec /etc/default/kexec avant de redémarrer. Une fois cela fait, la procédure de reboot (par reboot ou shutdown -r) se termine par l’activation directe du noyau spécifié au lieu du redémarrage normal via le BIOS.
Malheureusement il n’y a pas cette option dans le serveur cloud dynamique.
Mais en faisant une recherche a ce propos, j’ai trouvé ça (qui me semble être la réponse a mon problème malgrée que ça me pose un autre problème vu que je ne connais pas l’anglais ) donc si tu pouvais (ou quelqu’un d’autre) m’aider a traduire correctement ceci ça serait vraiment sympas:
Oui, ça y ressemble. Dommage que ce ne soit pas disponible avec ton serveur.
Voilà ce que dit en gros le billet que tu cites.
L’auteur a configuré l’interface réseau en statique. Je n’ai pas trop compris, il est question de mise à jour du client DHCP. Si l’interface réseau de ton serveur est configurée en statique (cf. /etc/network/interfaces), tu n’es pas concerné.
L’auteur a retiré apparmor (ça n’a pas l’air présent dans Debian), quitte à le réinstaller ultérieurement.
Le pilote IDE/ATA du nouveau noyau nomme les disque IDE sdX au lieu de hdX précédemment, il a dû modifier /etc/fstab et /boot/grub/menu.lst en conséquence. Mais que je sache (en tout cas chez moi), le noyau Debian de lenny ne change pas le nom des disques par rapport aux noyaux précédents d’etch.
Et concernant mes interrogations sur le noyau 2.6.18 et le 2.6.26 Xen ?
Hum comment je peux le voir s il est en statique ou non ?
du coup j’ai étais dans le fichier “/etc/network/interfaces” mais rien ne mentionne “statique”.
voila mon fichier (pas de différence entre avant et après la migration):
This file describes the network interfaces available on your system
and how to activate them. For more information, see interfaces(5).
The loopback network interface
auto lo eth0
iface lo inet loopback
The primary network interface
#allow-hotplug eth0
iface eth0 inet dhcp
Donc J’ai désactivé apparmor (moi il était installé je pense vu qu’il a pas dit comme quoi cette commande n’existe pas, il m’a écris plein de ligne après que j’ai écris “apt-get remove apparmor”…)
j’ai changé hdaX par sdaX (malgrée que avant les migration c’était hdaX par defaut)
Mais bon au final ça n’a rien changé
Je sais pas quoi dire, mais dans tout les cas ce n’es pas moi qui les ai installé…
Est-ce possible que ça viennent des dépôt ? car en fait j’ai remplacé les dépôt de ETCH 1&1 par les dépôt Lenny Debian Officiel (d’ailleur je me demande pourquoi ils ont changé ça…)
Bon maintenant je vais éssayer la manip pour voir si ça fonctionne avec Ubuntu même si j’aurais préféré Debian… (mais ce n’es pas pour autant que je vais arreter mes test sur debian ^^ je veux qu’il fonctionne !! )
D’après /etc/network/interfaces, eth0 est en DHCP.
Comme je l’ai écrit, je ne crois pas qu’il faille remplacer hda par sda avec le noyau de lenny. Dans le doute, il y a moyen de s’affranchir d’un éventuel changement de nom en désignant les partitions par leur label ou leur UUID qui est fixe.
C’est forcément toi qui a installé les noyaux Xen puisqu’ils n’y étaient pas au départ. Ça ne vient pas que des dépôts ; la présence d’un paquet dans un dépôt n’oblige pas son installation. Quelle procédure as-tu suivie pour la migration vers lenny ?
Qu’as-tu fait exactement pour qu’Ubuntu fonctionne ?
Qu’entends-tu par “garder l’ancien DHCP comme sur ubuntu” ? En fait je n’ai pas bien compris cette histoire de DHCP dont il est question sur le billet. Il y a aurait une option rfc3442-classless-static-routes qui pose problème au client DHCP et qu’il faudrait retirer ? Dans ce cas il faudrait essayer de faire la même chose sous Debian.
Actuellement je suis en train de réinstaller Debian, je répondrais a t’es questions juste après car en fait, je vien de m’apercevoir qu’il me propose aussi de garder l’ancien DHCP, je vais donc éssayer de faire la manip et je te tien au courant
Edit: bon j’ai voulu croire en ce que tu avais dis, comme quoi hdaX devrais fonctionner sur Debian, j’ai reboot, mais il ne reboot pas
Donc je vais recommencer mais cette fois en faisant exactement ce que dis le blog pour voir…
le noyau Debian et celui de Ubuntu ne sont pas les même ?
bah Tout ce que j’ai fais c’est :
A partir du site 1&1, j’installe Debian 4 Etch 64bits.
Une fois installé, je change les dépôt puis je fais directement la migration vers Lenny.
Pour la procédure :
Configuring libc6 ├───────────────────────────┐
│ Running services and programs that are using NSS need to be restarted, │
│ otherwise they might not be able to do lookup or authentication any more │
│ (for services such as ssh, this can affect your ability to login). │
│ Please review the following space-separated list of init.d scripts for │
│ services to be restarted now, and correct it if needed. │
│ │
│ Note: restarting sshd/telnetd should not affect any existing │
│ connections. │
│ │
│ Services to restart for GNU libc library upgrade:
ssh openbsd-inetd exim4 cron atd___
ok
Configuring libpam0g ├──────────────────────────┐
│ Most services that use PAM need to be restarted to use modules built for │
│ this new version of libpam. Please review the following space-separated │
│ list of init.d scripts for services to be restarted now, and correct it │
│ if needed. │
│ │
│ Services to restart for PAM library upgrade: │
│ │
│ exim4 cron atd___________________________________________________________ │
│ │
│
Configuration file `/etc/securetty’
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer’s version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** securetty (Y/I/N/O/D/Z) [default=N] ?
y
Configuration file `/etc/dhcp3/dhclient.conf’
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer’s version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** securetty (Y/I/N/O/D/Z) [default=N] ?
y (c’est ce que je mettais avant aujourd’hui)
n (ça c’est ce qu’on est sencé mettre pour l’astuce de ubuntu)
FIN
Pendant l’installation il faut répondre N ici :
Configuration file `/etc/dhcp3/dhclient.conf’
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer’s version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** securetty (Y/I/N/O/D/Z) [default=N] ?
J’écris dans le terminal :
apt-get remove apparmor
Dans /boot/grub/menu.lst je remplace cette ligne :
Configuration file `/etc/dhcp3/dhclient.conf’
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer’s version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : background this process to examine the situation
The default action is to keep your current version.
*** securetty (Y/I/N/O/D/Z) [default=N] ?
je garde l’ancienne version.
Après avoir bien fais attention, en effet, il n’y est pas sur Debian.
Mais n’y a t’il pas autre chose qui fait la même fonction ?
Et aussi, comment je fais pour désinstaller les noyau qu’il ne me servent pas (si j’ai bien compris…)
Non, les noyaux fournis par Debian et Ubuntu ne sont pas les mêmes. “uname -a” pour afficher le noyau actif, et
[code]ls /boot/vmlinuz*
ou
ls /lib/modules/
ou
dpkg -l | grep linux-image[/code]
pour voir les noyaux installés sur chaque distribution.
[quote=“zyef”]A partir du site 1&1, j’installe Debian 4 Etch 64bits.
Une fois installé, je change les dépôt puis je fais directement la migration vers Lenny.[/quote]
Donc directement modification de source.list et ensuite aptitude update && aptitude dist-upgrade ? (Ce n’est pas la procédure recommandée dans les notes de publication de lenny mais passons).
Dans ce cas le noyau 2.6.18 Xen n’a pas pu être installé lors de la migration puisqu’il n’est pas dans les dépôts de lenny. Il était installé au départ, mais pas listé dans /boot/grub/menu.lst bizarrement. Je suppose aussi qu’il était installé par dépendance d’un méta-paquet linux-image-xen-amd64 ou linux-image-2.6-xen-amd64, ce qui a provoqué l’installation du noyau 2.6.26 Xen lors de la migration vers lenny. Cela devrait se confirmer avec
Dans la description du noyau Xen de lenny, je lis : “This kernel only runs on a Xen hypervisor”, “ce noyau ne fonctionne que sur un hyperviseur Xen”. Or après la migration je vois que dans ton /boot/grub/menu.lst l’option default=0 indique que le noyau à amorcer par défaut est le premier dans la liste, et c’est le noyau 2.6.26 Xen. Si ton serveur n’a pas d’hyperviseur, cela peut expliquer pourquoi il ne redémarre pas correctement (accessoirement on peut se demander alors pourquoi le noyau Xen était installé, mais c’est un autre sujet).
Mes suggestions, au choix :
Après la migration avant de redémarrer, modifier la valeur de l’option default= dans menu.lst pour désigner le noyau 2.6.24 etchnhalf d’origine (qui devrait tourner avec lenny). 0 = 1e ligne title, 1 = 2e ligne title… donc d’après ton menu.lst cela devrait être default=2.
Avant la migration, désinstaller tous les paquets de noyau Xen affichés par la commande dpkg ci-dessus. Ainsi le nouveau noyau 2.6.26 Xen ne sera pas installé et le noyau 2.6.24 restera en première position dans menu.lst.
Dans les deux cas, le but est de redémarrer avec le noyau 2.6.24. Si ça marche, on verra pour la suite.
Voila ce que me fait la commande que tu m’a dis (avant la migration) :
dpkg -l | grep linux-image
ii linux-image-2.6-xen-amd64 2.6.18+6etch3 Li nux kernel 2.6 image on AMD64
ii linux-image-2.6.18-6-xen-amd64 2.6.18.dfsg.1-26etch1 Li nux 2.6.18 image on AMD64
ii linux-image-2.6.24-etchnhalf.1-amd64 2.6.24-6~etchnhalf.9etch1 Li nux 2.6.24 image on AMD64
ii linux-image-xen-amd64 2.6.18+6etch3 Li nux kernel image on AMD64
Maintenant je vais éssayer de faire ce que tu m’a dis
hum par contre si tu pouvais me dir la commande exacte pour désinstaller les paquet, ça m’aiderais beaucoup, car comme je l’ai déjà dis, j’ai pas énormément d’expérience sur linux
[size=150]EDIT[/size]
Après la migration :
ii linux-image-2.6-xen-amd64 2.6.26+17+lenny1 Linux 2.6 image on AMD64 , oldstyle Xen suppo
ii linux-image-2.6.18-6-xen-amd64 2.6.18.dfsg.1-26etch1 Linux 2.6.18 image on AM D64
ii linux-image-2.6.24-etchnhalf.1-amd64 2.6.24-6~etchnhalf.9etch1 Linux 2.6.24 image on AM D64
ii linux-image-2.6.26-2-xen-amd64 2.6.26-24lenny1 Linux 2.6.26 image on AM D64, oldstyle Xen su
ii linux-image-xen-amd64 2.6.26+17+lenny1 Linux image on AMD64, ol dstyle Xen support
On aurait gagné beaucoup de temps si j’avais su avant qu’un noyau Xen ne pouvait pas être démarré par grub mais seulement par un hyperviseur Xen… Tu pourras remercier 1&1 qui a mis un gros bazar en installant ce noyau par défaut.
Pour désinstaller des paquets dans Debian (et Ubuntu) :
apt-get remove <nom_du_paquet> <nom_du_paquet> <…>[/code]
Je suppose que tu as changé l’option default dans menu.lst ?
Maintenant tu peux désinstaller les paquets noyaux xen listés par dpkg (et libc6-xen qui ne sert à rien non plus) et lancer update-grub (ou grub-update, je sais plus). Attention à remettre default à 0 puisque le noyau 2.6.24 se retrouve à nouveau seul et donc premier.
Ensuite, comme le noyau 2.6.24 etchnhalf n’est plus maintenu et peut contenir des failles de sécurité connues et non corrigées, tu peux installer le noyau normal de lenny (non Xen), qui devrait marcher aussi
et redémarrer. Une fois que le noyau 2.6.26 est actif (vérifier avec uname -a) et que tout fonctionne normalement, le paquet linux-image-2.6.24-etchnhalf.1-amd64 peut être désinstallé et la migration sera terminée.
dist-upgrade en etch (sur une de mes machines en woody, il subsistait des paquets «slink!» d’où cette précaution)
mise à jour du sources.list
apt-get upgrade
vérification des principaux services.
Je regarde les paquets restés en etch et le cas échéant
apt-get install le_paquet_à_mettre_à_jour
puis si tout fonctionne bien, apt-get dist-upgrade si besoin est (mais c’est rare). L’intérêt est d’étaler les soucis. Souvent je commence par faire un pat-get install libc6 avant le «upgrade» mais là c’est vraiment un excès de précautions.
PS: full-upgrade c’est pour aptitude seulement je crois
ok je ferais ça cette nuit, j’ai voulu aller trop vite et j’ai oublié de faire “update-grub” du coup je dois tout refaire la je vais dormir lol
[size=150]
EDIT[/size]
moi j’ai juste fait apt-get update puis apt-get dist-upgrade
[size=150]EDIT 2 :[/size]
[quote=“PascalHambourg”]
EDIT : c’est si pourri que ça Ubuntu ?[/quote]
Et bien… (avec mon experience en linux en tout cas)
Quand on veut changer de langue, c’est vraiment pas au point, par exemple
chez Debian ça sera écris: Dépôt
Chez Ubuntu ça sera écris: D#~`p^&t (c’est un exemple car je ne me souvien pas exactement comment c’est écris… dur a se rappeler d’un mot pareil )
Et d’après ce que j’ai vu, Débian support mieux 1&1 par rapport a Ubuntu :
sur Debian y’a rien a modifier au niveau des hdaX (juste les paquet a désinstaller mais ça pourrait venir de comment je fais la migration d’après ce que j’ai compris)
Après bah c’est bien connu que Debian est plus stable que Ubuntu et donc bien mieux a mon gout car un serveur pas stable, c’est un serveur de hum hum… (tien on me chuchote que je suis banni de chez Ubuntu
) donc si tu pouvais (ou quelqu’un d’autre) m’aider a traduire correctement ceci ça serait vraiment sympas:
)
