Bonjour, j'ai essayé de passer de Free5.1 à 5.2.
cvsup des sources et des ports,
make buildworld,
make buildkernel,
make installkernel,
make installworld;
et là, message d'erreur au sujet de libcom_err_p.a,
bon, je le cherche, ne trouve rien(enfin, si, mais sans Makefile).
re cvsup,
vérification de /etc/make.conf: il est plus là!!!
kézako?
tout foire? Ou est-il mon make.conf? Il n'est pas épargné par le
"installworld"? Pas pratique, qd même!
Petit jeu : reliez la liste des paragraphes à la liste que j'ai précédemment écrite.
21.4.3 Update the files in /etc mergemaster 21.4.4 Drop into the single user mode *Démarrage Mode Single User 21.4.6 Recompile the source make build world 21.4.7 Compile and install a New kernel make buildkernel 21.4.8 Reboot into Single User Mode make installkernel 21.4.9 Install the new system binaries *Démarrage Mode Single User 21.4.10 Update file not updated by make world make installworld mergemaster
Attention il y a un piège.
Selon Laurent Lefevre:
mergemaster
*Démarrage Mode Single User
Stupide.
Je vous retourne le compliment.
A quoi sert ce reboot ? Le mergemaster a ce niveau ? Si tu fait
l'effort de comprendre ce que tu écrit, cela ira peute être un peu
mieux.
Si vous faisiez l'effort d'expliquer vos assertions plutôt que d'étaler tant
de suffisance, je vous serais agréable.
Cette partie là est correcte, sauf que tu n'a pas compris le but du
mergemaster.
Je vous renvoie donc méditer sur le document officiel,
je vous le propose en couleur et en français, peut-être cela vous
aidera-t-il.
Petit jeu : reliez la liste des paragraphes à la liste que j'ai précédemment
écrite.
21.4.3 Update the files in /etc mergemaster
21.4.4 Drop into the single user mode *Démarrage Mode Single User
21.4.6 Recompile the source make build world
21.4.7 Compile and install a New kernel make buildkernel
21.4.8 Reboot into Single User Mode make installkernel
21.4.9 Install the new system binaries *Démarrage Mode Single User
21.4.10 Update file not updated by make world make installworld
mergemaster
Petit jeu : reliez la liste des paragraphes à la liste que j'ai précédemment écrite.
21.4.3 Update the files in /etc mergemaster 21.4.4 Drop into the single user mode *Démarrage Mode Single User 21.4.6 Recompile the source make build world 21.4.7 Compile and install a New kernel make buildkernel 21.4.8 Reboot into Single User Mode make installkernel 21.4.9 Install the new system binaries *Démarrage Mode Single User 21.4.10 Update file not updated by make world make installworld mergemaster
Attention il y a un piège.
Thierry Thomas
Mardi 27 janvier 2004 à 19:05 GMT, Michel Talon a écrit :
La seule phase emmerdante (au plus haut point) est mergemaster. C'est rééllement un outil de bouse. Il paraît qu'il y a un outil meilleur dans les ports.
sysutils/etcmerge. -- Th. Thomas.
Mardi 27 janvier 2004 à 19:05 GMT, Michel Talon a écrit :
La seule phase emmerdante (au plus haut point) est mergemaster. C'est
rééllement un outil de bouse. Il paraît qu'il y a un outil meilleur dans
les ports.
Mardi 27 janvier 2004 à 19:05 GMT, Michel Talon a écrit :
La seule phase emmerdante (au plus haut point) est mergemaster. C'est rééllement un outil de bouse. Il paraît qu'il y a un outil meilleur dans les ports.
sysutils/etcmerge. -- Th. Thomas.
talon
David MAREC wrote:
Je suis impatient de le connaître s'il existe.
/usr/ports/sysutils/etcmerge
etcmerge is a tool for keeping /etc up to date when updating. The primary difference from mergemaster is that etcmerge requires much less manual work than mergemaster, due to the use of a three way merge.
--
Michel TALON
David MAREC <dmarec.spam@spambox.invalid> wrote:
Je suis impatient de le connaître s'il existe.
/usr/ports/sysutils/etcmerge
etcmerge is a tool for keeping /etc up to date when updating.
The primary difference from mergemaster is that etcmerge
requires much less manual work than mergemaster, due to the
use of a three way merge.
etcmerge is a tool for keeping /etc up to date when updating. The primary difference from mergemaster is that etcmerge requires much less manual work than mergemaster, due to the use of a three way merge.
--
Michel TALON
talon
David MAREC wrote:
Je vous renvoie donc méditer sur le document officiel, je vous le propose en couleur et en français, peut-être cela vous aidera-t-il.
Il y a déjà longtemps que j'ai signalé sur le groupe anglais et la mailing list que le handbook était mal foutu sur ce sujet, la seule réponse a été que je pouvais soumettre un patch.
--
Michel TALON
David MAREC <dmarec.spam@spambox.invalid> wrote:
Je vous renvoie donc méditer sur le document officiel,
je vous le propose en couleur et en français, peut-être cela vous
aidera-t-il.
Il y a déjà longtemps que j'ai signalé sur le groupe anglais et la
mailing list que le handbook était mal foutu sur ce sujet, la seule
réponse a été que je pouvais soumettre un patch.
Il y a déjà longtemps que j'ai signalé sur le groupe anglais et la mailing list que le handbook était mal foutu sur ce sujet, la seule réponse a été que je pouvais soumettre un patch.
--
Michel TALON
espie
In article <bv5o7u$1ud3$, Thomas Pornin wrote:
PS1 : il y a quand même quelques trucs qui passent mal aux changements de noyau ; ce sont les échanges de données binaires structurées et complexes entre le noyau et quelques applications système très spécifiques. Typiquement, quand le noyau et le userland sont désynchronisés, "ps" (et autres "top") marchent mal, et NFS a un peu de mal aussi.
Les Net et Open recents, au moins, ont KERN_PROC2 dans sysctl pour eviter les problemes de synchronisation sur ps et top.
In article <bv5o7u$1ud3$1@biggoron.nerim.net>,
Thomas Pornin <pornin@nerim.net> wrote:
PS1 : il y a quand même quelques trucs qui passent mal aux changements
de noyau ; ce sont les échanges de données binaires structurées
et complexes entre le noyau et quelques applications système très
spécifiques. Typiquement, quand le noyau et le userland sont
désynchronisés, "ps" (et autres "top") marchent mal, et NFS a un peu de
mal aussi.
Les Net et Open recents, au moins, ont KERN_PROC2 dans sysctl pour eviter
les problemes de synchronisation sur ps et top.
PS1 : il y a quand même quelques trucs qui passent mal aux changements de noyau ; ce sont les échanges de données binaires structurées et complexes entre le noyau et quelques applications système très spécifiques. Typiquement, quand le noyau et le userland sont désynchronisés, "ps" (et autres "top") marchent mal, et NFS a un peu de mal aussi.
Les Net et Open recents, au moins, ont KERN_PROC2 dans sysctl pour eviter les problemes de synchronisation sur ps et top.
Marwan Burelle
On Tue, 27 Jan 2004 21:51:26 +0000 (UTC) (Michel Talon) wrote:
Je suis impatient de le connaître s'il existe.
/usr/ports/sysutils/etcmerge
etcmerge is a tool for keeping /etc up to date when updating. The primary difference from mergemaster is that etcmerge requires much less manual work than mergemaster, due to the use of a three way merge.
J'avais commencé une version un peu modifié de mergemaster, pour lui faire updater sans question un certain nombre de fichiers que l'on a rarement l'occasion de modifier (genre tout ce qu'il y a dans default, ou certains scripts.)
C'est de loin la partie la plus lourde mergemaster. D'autant plus que, en général, on utilise mergemaster surtout pour ces fichiers auquel on ne touche jamais.
Malheureusement, le code de mergemaster est assez "toufu", voire même pire, et j'ai pas franchement le temps (thèse, enseignements, papiers, confs, tout ça...) de tout réécrire... j'irais jetter un oeil dans etcmerge pour voir si c'est mieux (sinon, un jour où je craquerais, je ferais ça en ocaml ;)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On Tue, 27 Jan 2004 21:51:26 +0000 (UTC)
talon@lpthe.jussieu.fr (Michel Talon) wrote:
Je suis impatient de le connaître s'il existe.
/usr/ports/sysutils/etcmerge
etcmerge is a tool for keeping /etc up to date when updating.
The primary difference from mergemaster is that etcmerge
requires much less manual work than mergemaster, due to the
use of a three way merge.
J'avais commencé une version un peu modifié de mergemaster, pour lui
faire updater sans question un certain nombre de fichiers que l'on a
rarement l'occasion de modifier (genre tout ce qu'il y a dans default,
ou certains scripts.)
C'est de loin la partie la plus lourde mergemaster. D'autant plus que,
en général, on utilise mergemaster surtout pour ces fichiers auquel on
ne touche jamais.
Malheureusement, le code de mergemaster est assez "toufu", voire même
pire, et j'ai pas franchement le temps (thèse, enseignements, papiers,
confs, tout ça...) de tout réécrire... j'irais jetter un oeil dans
etcmerge pour voir si c'est mieux (sinon, un jour où je craquerais, je
ferais ça en ocaml ;)
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
On Tue, 27 Jan 2004 21:51:26 +0000 (UTC) (Michel Talon) wrote:
Je suis impatient de le connaître s'il existe.
/usr/ports/sysutils/etcmerge
etcmerge is a tool for keeping /etc up to date when updating. The primary difference from mergemaster is that etcmerge requires much less manual work than mergemaster, due to the use of a three way merge.
J'avais commencé une version un peu modifié de mergemaster, pour lui faire updater sans question un certain nombre de fichiers que l'on a rarement l'occasion de modifier (genre tout ce qu'il y a dans default, ou certains scripts.)
C'est de loin la partie la plus lourde mergemaster. D'autant plus que, en général, on utilise mergemaster surtout pour ces fichiers auquel on ne touche jamais.
Malheureusement, le code de mergemaster est assez "toufu", voire même pire, et j'ai pas franchement le temps (thèse, enseignements, papiers, confs, tout ça...) de tout réécrire... j'irais jetter un oeil dans etcmerge pour voir si c'est mieux (sinon, un jour où je craquerais, je ferais ça en ocaml ;)
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Marwan Burelle
On Tue, 27 Jan 2004 21:57:29 +0100 David MAREC wrote:
Je vous renvoie donc méditer sur le document officiel, je vous le propose en couleur et en français, peut-être cela vous aidera-t-il.
Cette doc est à lire plusieures fois. Ce n'est pas qu'elle n'est pas forcément clair, mais elle ne correspond pas forcément à une doc pas à pas. En gros pour comprendre certains points, il vaut mieux avoir déjà lu la fin de la doc avant ...
On y comprend, notamment, que le premier reboot en single est juste là pour les perfs (contrairement à celui avec le nouveau kernel), que l'update d'etc au début correspond surtout à l'ajout des groupes/users nécessaire à l'installation de certains binaires et n'est pas nécessaire à chaque fois (c'est en général expliqué dans updating.)
http://www.freebsd.org/doc/fr_FR.ISO8859-1/books/handbook/makeworld. html
La doc française est-elle à jour ? certaines parties ne sont pas toujours au point ...
Petit jeu : reliez la liste des paragraphes à la liste que j'ai précédemment écrite.
Le paragraphe 21.4.3 n'était pas là quand j'ai lu cette partie de la doc ... (c'était avant la 4.6 ... mais effectivement, depuis, il y a eu les histoires de sendmail et ssh qui ont récupéré leur propre user/group ... )
Par contre, il parle toujours de /etc/default/make.conf et ne parle plus de sauvegarder etc ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On Tue, 27 Jan 2004 21:57:29 +0100
David MAREC <dmarec.spam@spambox.invalid> wrote:
Je vous renvoie donc méditer sur le document officiel,
je vous le propose en couleur et en français, peut-être cela vous
aidera-t-il.
Cette doc est à lire plusieures fois. Ce n'est pas qu'elle n'est pas
forcément clair, mais elle ne correspond pas forcément à une doc pas à
pas. En gros pour comprendre certains points, il vaut mieux avoir déjà
lu la fin de la doc avant ...
On y comprend, notamment, que le premier reboot en single est juste là
pour les perfs (contrairement à celui avec le nouveau kernel), que
l'update d'etc au début correspond surtout à l'ajout des groupes/users
nécessaire à l'installation de certains binaires et n'est pas nécessaire
à chaque fois (c'est en général expliqué dans updating.)
http://www.freebsd.org/doc/fr_FR.ISO8859-1/books/handbook/makeworld.
html
La doc française est-elle à jour ? certaines parties ne sont pas
toujours au point ...
Petit jeu : reliez la liste des paragraphes à la liste que j'ai
précédemment écrite.
Le paragraphe 21.4.3 n'était pas là quand j'ai lu cette partie de la doc
... (c'était avant la 4.6 ... mais effectivement, depuis, il y a eu les
histoires de sendmail et ssh qui ont récupéré leur propre user/group ...
)
Par contre, il parle toujours de /etc/default/make.conf et ne parle plus
de sauvegarder etc ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
On Tue, 27 Jan 2004 21:57:29 +0100 David MAREC wrote:
Je vous renvoie donc méditer sur le document officiel, je vous le propose en couleur et en français, peut-être cela vous aidera-t-il.
Cette doc est à lire plusieures fois. Ce n'est pas qu'elle n'est pas forcément clair, mais elle ne correspond pas forcément à une doc pas à pas. En gros pour comprendre certains points, il vaut mieux avoir déjà lu la fin de la doc avant ...
On y comprend, notamment, que le premier reboot en single est juste là pour les perfs (contrairement à celui avec le nouveau kernel), que l'update d'etc au début correspond surtout à l'ajout des groupes/users nécessaire à l'installation de certains binaires et n'est pas nécessaire à chaque fois (c'est en général expliqué dans updating.)
http://www.freebsd.org/doc/fr_FR.ISO8859-1/books/handbook/makeworld. html
La doc française est-elle à jour ? certaines parties ne sont pas toujours au point ...
Petit jeu : reliez la liste des paragraphes à la liste que j'ai précédemment écrite.
Le paragraphe 21.4.3 n'était pas là quand j'ai lu cette partie de la doc ... (c'était avant la 4.6 ... mais effectivement, depuis, il y a eu les histoires de sendmail et ssh qui ont récupéré leur propre user/group ... )
Par contre, il parle toujours de /etc/default/make.conf et ne parle plus de sauvegarder etc ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Nicolas Le Scouarnec
Dans ton premier post, tu ne précisez pas si tu avais rebooter entre le installkernel et le installworld ? c'est à prioris nécessaire ... Qu'elle est la méthode alors ? Dans le manuel c'est make buildworld, make
buildkernel. Boot en mode mono utilisateur puis make installworld et installkernel. Avec un coup de mergemaster avant et après.
Hum... Dans le manuel FreeBSD, c'est plutot make buildworld make buildkernel make installkernel reboot (single) mergemaster -p make installworld mergemaster
Le InstallWorld se fait avec le nouveau kernel en place et après avoir booté dessus. Enfin, c'est comme ca que j'ai fait hier soir, si ca se trouve, j'ai eu de la chance :-)
De plus, il fortement conseillé d'utiliser un kernel générique avant pour faire la monter de version et de faire le nouveau kernel après ... Ah ?
Ah, oui, ca je ne savais pas...
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Dans ton premier post, tu ne précisez pas si tu avais rebooter entre le
installkernel et le installworld ? c'est à prioris nécessaire ...
Qu'elle est la méthode alors ? Dans le manuel c'est make buildworld, make
buildkernel. Boot en mode mono utilisateur puis make installworld et
installkernel. Avec un coup de mergemaster avant et après.
Hum... Dans le manuel FreeBSD, c'est plutot
make buildworld
make buildkernel
make installkernel
reboot (single)
mergemaster -p
make installworld
mergemaster
Le InstallWorld se fait avec le nouveau kernel en place et après avoir
booté dessus. Enfin, c'est comme ca que j'ai fait hier soir, si ca se
trouve, j'ai eu de la chance :-)
De plus, il fortement conseillé d'utiliser un kernel générique avant pour
faire la monter de version et de faire le nouveau kernel après ...
Ah ?
Ah, oui, ca je ne savais pas...
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Dans ton premier post, tu ne précisez pas si tu avais rebooter entre le installkernel et le installworld ? c'est à prioris nécessaire ... Qu'elle est la méthode alors ? Dans le manuel c'est make buildworld, make
buildkernel. Boot en mode mono utilisateur puis make installworld et installkernel. Avec un coup de mergemaster avant et après.
Hum... Dans le manuel FreeBSD, c'est plutot make buildworld make buildkernel make installkernel reboot (single) mergemaster -p make installworld mergemaster
Le InstallWorld se fait avec le nouveau kernel en place et après avoir booté dessus. Enfin, c'est comme ca que j'ai fait hier soir, si ca se trouve, j'ai eu de la chance :-)
De plus, il fortement conseillé d'utiliser un kernel générique avant pour faire la monter de version et de faire le nouveau kernel après ... Ah ?
Ah, oui, ca je ne savais pas...
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Nicolas Le Scouarnec
C'est pas possible! J'ai jamais vu cette question aussi mal comprise, il faut croire que le handbook est particulièrement merdique sur ce point, puisque la moitié des gens le comprennent de travers. C'est
Il est pas très clair (je l'ai lu hier soir), on a pas l'enchainement bien précisé, ils expliquent le reboot en single user au tout début, par contre, a la fin du UPDATING, il y a un "résumé" assez clair, qui explique bien l'ordre et affiche bien l'ordre.
Pour les petits malins qui croient qu'on peut se permettre le installworld sans rebooter avec le nouveau kernel, justement il paraît que ça ne marche pas dans le passage 5.1 -> 5.2 En plus c'est écrit en gros dans UPDATING.
Oui, en très gros :-) Ca marche bien en rebootant par contre.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
C'est pas possible! J'ai jamais vu cette question aussi mal comprise, il
faut croire que le handbook est particulièrement merdique sur ce point,
puisque la moitié des gens le comprennent de travers. C'est
Il est pas très clair (je l'ai lu hier soir), on a pas l'enchainement
bien précisé, ils expliquent le reboot en single user au tout début,
par contre, a la fin du UPDATING, il y a un "résumé" assez clair, qui
explique bien l'ordre et affiche bien l'ordre.
Pour les petits malins qui croient qu'on peut se permettre le
installworld sans rebooter avec le nouveau kernel, justement il paraît
que ça ne marche pas dans le passage 5.1 -> 5.2
En plus c'est écrit en gros dans UPDATING.
Oui, en très gros :-) Ca marche bien en rebootant par contre.
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
C'est pas possible! J'ai jamais vu cette question aussi mal comprise, il faut croire que le handbook est particulièrement merdique sur ce point, puisque la moitié des gens le comprennent de travers. C'est
Il est pas très clair (je l'ai lu hier soir), on a pas l'enchainement bien précisé, ils expliquent le reboot en single user au tout début, par contre, a la fin du UPDATING, il y a un "résumé" assez clair, qui explique bien l'ordre et affiche bien l'ordre.
Pour les petits malins qui croient qu'on peut se permettre le installworld sans rebooter avec le nouveau kernel, justement il paraît que ça ne marche pas dans le passage 5.1 -> 5.2 En plus c'est écrit en gros dans UPDATING.
Oui, en très gros :-) Ca marche bien en rebootant par contre.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Nicolas Le Scouarnec
de façon à faire le installworld avec le nouveau kernel. C'est pourtant assez évident que c'est ça qu'il faut, assez dit, répété, rabaché, trente six mille fois. Ben non ce n'est pas si évident. Si le nouveau noyau n'est pas
compatible avec l'ancien monde qu'est ce qui dit que ça marchera au reboot ?
Justement, il faut activer la compatibilité (compat_freebsd4 pour le passage de 5.1 --> 5.2) dans le noyau avant de rebooter. Ca on peut le faire, par contre, on ne peut pas activer et assurer la compatibilité du nouveau monde avec l'ancien noyau.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
de façon à faire le installworld avec le nouveau kernel. C'est
pourtant assez évident que c'est ça qu'il faut, assez dit, répété,
rabaché, trente six mille fois.
Ben non ce n'est pas si évident. Si le nouveau noyau n'est pas
compatible avec l'ancien monde qu'est ce qui dit que ça marchera au
reboot ?
Justement, il faut activer la compatibilité (compat_freebsd4 pour le
passage de 5.1 --> 5.2) dans le noyau avant de rebooter. Ca on peut le
faire, par contre, on ne peut pas activer et assurer la compatibilité
du nouveau monde avec l'ancien noyau.
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
de façon à faire le installworld avec le nouveau kernel. C'est pourtant assez évident que c'est ça qu'il faut, assez dit, répété, rabaché, trente six mille fois. Ben non ce n'est pas si évident. Si le nouveau noyau n'est pas
compatible avec l'ancien monde qu'est ce qui dit que ça marchera au reboot ?
Justement, il faut activer la compatibilité (compat_freebsd4 pour le passage de 5.1 --> 5.2) dans le noyau avant de rebooter. Ca on peut le faire, par contre, on ne peut pas activer et assurer la compatibilité du nouveau monde avec l'ancien noyau.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
