J'ai une poignée de serveurs Xeon, qui pour des raisons historiques ont
été installés en 32 bits.
Deux questions :
1- Est-il simple d'upgrader le noyau et le monde de 32 à 64 bits par
recompilation ? J'ai déja des make.conf pour archi amd64 (en fait Xeon =
nocona, sjnma) dans une VMWare.
2- Quel bénéfice ? A part la stabilité de zfs que je n'utilise de ttes
façons pas en prod.
Merci,
--
Xav
Disponible au 1/9/2009
<http://www.xavierhumbert.net/perso/CV2.html>
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Thierry Herbelot
Xavier wrote:
Bonjour,
J'ai une poignée de serveurs Xeon, qui pour des raisons historiques ont été installés en 32 bits.
Deux questions :
1- Est-il simple d'upgrader le noyau et le monde de 32 à 64 bits par recompilation ? J'ai déja des make.conf pour archi amd64 (en fait Xeon > nocona, sjnma) dans une VMWare.
j'ai la flemme de rechercher dans les archives, mais j'avais gardé en mémoire que c'est catégoriquement non : il vaut mieux réinstaller à neuf.
2- Quel bénéfice ? A part la stabilité de zfs que je n'utilise de ttes façons pas en prod.
avec une machine récente, on peut installer plus de RAM et l'utiliser (comme cache). si le swap n'est pas utilisé, pas d'amélioration à attendre.
(le gcc est peut-être mieux maintenu pour x86 ?)
par ailleurs, Zfs, c'est bien mangez-en !
dans certains conditions, les machines doivent être plus rapides en x64 (plus de registres) ou plus lentes (taille du code binaire plus importante) ....
TfH
Merci,
Xavier wrote:
Bonjour,
J'ai une poignée de serveurs Xeon, qui pour des raisons historiques ont
été installés en 32 bits.
Deux questions :
1- Est-il simple d'upgrader le noyau et le monde de 32 à 64 bits par
recompilation ? J'ai déja des make.conf pour archi amd64 (en fait Xeon > nocona, sjnma) dans une VMWare.
j'ai la flemme de rechercher dans les archives, mais j'avais gardé en
mémoire que c'est catégoriquement non : il vaut mieux réinstaller à neuf.
2- Quel bénéfice ? A part la stabilité de zfs que je n'utilise de ttes
façons pas en prod.
avec une machine récente, on peut installer plus de RAM et l'utiliser (comme
cache). si le swap n'est pas utilisé, pas d'amélioration à attendre.
(le gcc est peut-être mieux maintenu pour x86 ?)
par ailleurs, Zfs, c'est bien mangez-en !
dans certains conditions, les machines doivent être plus rapides en x64
(plus de registres) ou plus lentes (taille du code binaire plus
importante) ....
J'ai une poignée de serveurs Xeon, qui pour des raisons historiques ont été installés en 32 bits.
Deux questions :
1- Est-il simple d'upgrader le noyau et le monde de 32 à 64 bits par recompilation ? J'ai déja des make.conf pour archi amd64 (en fait Xeon > nocona, sjnma) dans une VMWare.
j'ai la flemme de rechercher dans les archives, mais j'avais gardé en mémoire que c'est catégoriquement non : il vaut mieux réinstaller à neuf.
2- Quel bénéfice ? A part la stabilité de zfs que je n'utilise de ttes façons pas en prod.
avec une machine récente, on peut installer plus de RAM et l'utiliser (comme cache). si le swap n'est pas utilisé, pas d'amélioration à attendre.
(le gcc est peut-être mieux maintenu pour x86 ?)
par ailleurs, Zfs, c'est bien mangez-en !
dans certains conditions, les machines doivent être plus rapides en x64 (plus de registres) ou plus lentes (taille du code binaire plus importante) ....
TfH
Merci,
xavier
Thierry Herbelot wrote:
j'ai la flemme de rechercher dans les archives, mais j'avais gardé en mémoire que c'est catégoriquement non : il vaut mieux réinstaller à neuf.
Bon, comme la réinstall est hors de question, on va rester comme ça. If ain't broken, don't fix it :-)
Dans l'article <1irso24.1ciw99h1kvoixsN%, Xavier disait :
Bon, comme la réinstall est hors de question, on va rester comme ça. If ain't broken, don't fix it :-)
Tu peux faire, même avec les sources. Le moment le plus critique est qu'il faut installer ld.so à la main sinon y a un risque qu'il ne prenne pas le bon...
Je regarde dans developers@, un howto avait été envoyé. La situation a du s'améliorer mais je ne sais plus si c'est dans 7.1 ou juste dans 8-current.
----- From: Yar Tikhiy ... The exact procedure I used was as follows:
mv /rescue /rescue.sav cd /usr/src make installkernel TARGET_ARCH=amd64 DESTDIR=/ make -DNO_RTLD installworld TARGET_ARCH=amd64 DESTDIR=/ PATH=/rescue.sav exec sh cd /libexec chflags noschg ld-elf.so.1 mv ld-elf.so.1 ld-elf.so.1.old cp /usr/obj/amd64/usr/src/libexec/rtld-elf/ld-elf.so.1 . chmod 555 ld-elf.so.1 chflags schg ld-elf.so.1 reboot
Notes:
`cp -R /rescue /rescue.sav' would create a separate file for each link to rescue(8), so mv is much better.
DESTDIR=/ is there to convince our build subsystem that you do know what you're doing. It won't let you install for a different arch unless DESTDIR is set.
`exec sh' switches to /rescue.sav/sh, thus releasing the old ld-elf.so if the shell was the only user process using it. If you dare follow the procedure from multi-user mode, you'll still need to mv the old ld-elf.so out of the way, as attempts to overwrite it will fail with ETXTBSY.
The 32-bit loader ld-eld32.so is installed for amd64 via a special target in src/Makefile.inc1 and it isn't affected by -DNO_RTLD, so you don't have to copy it manually when 'sidegrading' to amd64, it'll be there just after installworld. ----- -- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <1irso24.1ciw99h1kvoixsN%xavier@groumpf.org>,
Xavier <xavier@groumpf.org> disait :
Bon, comme la réinstall est hors de question, on va rester comme ça.
If ain't broken, don't fix it :-)
Tu peux faire, même avec les sources. Le moment le plus critique est qu'il
faut installer ld.so à la main sinon y a un risque qu'il ne prenne pas le
bon...
Je regarde dans developers@, un howto avait été envoyé. La situation a du
s'améliorer mais je ne sais plus si c'est dans 7.1 ou juste dans 8-current.
-----
From: Yar Tikhiy <yar@comp.chem.msu.su>
...
The exact procedure I used was as follows:
mv /rescue /rescue.sav
cd /usr/src
make installkernel TARGET_ARCH=amd64 DESTDIR=/
make -DNO_RTLD installworld TARGET_ARCH=amd64 DESTDIR=/
PATH=/rescue.sav
exec sh
cd /libexec
chflags noschg ld-elf.so.1
mv ld-elf.so.1 ld-elf.so.1.old
cp /usr/obj/amd64/usr/src/libexec/rtld-elf/ld-elf.so.1 .
chmod 555 ld-elf.so.1
chflags schg ld-elf.so.1
reboot
Notes:
`cp -R /rescue /rescue.sav' would create a separate file for each
link to rescue(8), so mv is much better.
DESTDIR=/ is there to convince our build subsystem that you do know
what you're doing. It won't let you install for a different arch
unless DESTDIR is set.
`exec sh' switches to /rescue.sav/sh, thus releasing the old ld-elf.so
if the shell was the only user process using it. If you dare
follow the procedure from multi-user mode, you'll still need to mv
the old ld-elf.so out of the way, as attempts to overwrite it will
fail with ETXTBSY.
The 32-bit loader ld-eld32.so is installed for amd64 via a special
target in src/Makefile.inc1 and it isn't affected by -DNO_RTLD, so
you don't have to copy it manually when 'sidegrading' to amd64,
it'll be there just after installworld.
-----
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- roberto@FreeBSD.org
Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
Dans l'article <1irso24.1ciw99h1kvoixsN%, Xavier disait :
Bon, comme la réinstall est hors de question, on va rester comme ça. If ain't broken, don't fix it :-)
Tu peux faire, même avec les sources. Le moment le plus critique est qu'il faut installer ld.so à la main sinon y a un risque qu'il ne prenne pas le bon...
Je regarde dans developers@, un howto avait été envoyé. La situation a du s'améliorer mais je ne sais plus si c'est dans 7.1 ou juste dans 8-current.
----- From: Yar Tikhiy ... The exact procedure I used was as follows:
mv /rescue /rescue.sav cd /usr/src make installkernel TARGET_ARCH=amd64 DESTDIR=/ make -DNO_RTLD installworld TARGET_ARCH=amd64 DESTDIR=/ PATH=/rescue.sav exec sh cd /libexec chflags noschg ld-elf.so.1 mv ld-elf.so.1 ld-elf.so.1.old cp /usr/obj/amd64/usr/src/libexec/rtld-elf/ld-elf.so.1 . chmod 555 ld-elf.so.1 chflags schg ld-elf.so.1 reboot
Notes:
`cp -R /rescue /rescue.sav' would create a separate file for each link to rescue(8), so mv is much better.
DESTDIR=/ is there to convince our build subsystem that you do know what you're doing. It won't let you install for a different arch unless DESTDIR is set.
`exec sh' switches to /rescue.sav/sh, thus releasing the old ld-elf.so if the shell was the only user process using it. If you dare follow the procedure from multi-user mode, you'll still need to mv the old ld-elf.so out of the way, as attempts to overwrite it will fail with ETXTBSY.
The 32-bit loader ld-eld32.so is installed for amd64 via a special target in src/Makefile.inc1 and it isn't affected by -DNO_RTLD, so you don't have to copy it manually when 'sidegrading' to amd64, it'll be there just after installworld. ----- -- Ollivier ROBERT -=- FreeBSD: The Power to Serve -=- Soutenez les UNIX libres ! FreeBSD Linux NetBSD OpenBSD !
xavier
Ollivier Robert wrote:
Tu peux faire, même avec les sources. Le moment le plus critique est qu'il faut installer ld.so à la main sinon y a un risque qu'il ne prenne pas le bon...
[...snip...]
Merci, je vais tester ça dans un VMWare avant de casser les seveurs en prod :-)
Ollivier Robert <roberto@REMOVETHIS.eu.org> wrote:
Tu peux faire, même avec les sources. Le moment le plus critique est qu'il
faut installer ld.so à la main sinon y a un risque qu'il ne prenne pas le
bon...
[...snip...]
Merci, je vais tester ça dans un VMWare avant de casser les seveurs en
prod :-)
--
XAv
Disponible au 1/9/2009
<http://www.xavierhumbert.net/perso/CV2.html>
Tu peux faire, même avec les sources. Le moment le plus critique est qu'il faut installer ld.so à la main sinon y a un risque qu'il ne prenne pas le bon...
[...snip...]
Merci, je vais tester ça dans un VMWare avant de casser les seveurs en prod :-)