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!
[Noyau incompatible avec l'ancien monde] Tu pourrais réparer le problème avec un CD de rescue, facilement.
Ce n'est pas une situation que j'apprécie particulièrement.
Le vrai problème de cette histoire c'est que le handbook est trés mal rédigé sur ce sujet, et, bien qu'il ne dise pas de chose fausse, je crois, une lecture inattentive laisse penser qu'il dit le contraire de ce qu'il faut.
Et, le make buildworld est décrit _avant_ la compilation et l'installation du noyau. Ce qui est logique, si l'on suit le raisonnement de Thomas. Les compilations doit donc se dérouler sous l'ancien noyau puisqu'elle utilise l'ancien monde pour ce faire ?
En résumé, c'est d'après ce que j'ai sous les yeux : (ce n'est pas la dernière version, je l'ai imprimée il y a plus de 6 mois)
*Démarrage Mode Single User make build world make buildkernel make installkernel
Selon Michel Talon:
[Noyau incompatible avec l'ancien monde]
Tu pourrais réparer le problème avec un CD de rescue, facilement.
Ce n'est pas une situation que j'apprécie particulièrement.
Le vrai problème de cette histoire c'est que le handbook est trés mal
rédigé sur ce sujet, et, bien qu'il ne dise pas de chose fausse, je
crois, une lecture inattentive laisse penser qu'il dit le contraire de
ce qu'il faut.
Et, le make buildworld est décrit _avant_ la compilation et l'installation
du noyau.
Ce qui est logique, si l'on suit le raisonnement de Thomas.
Les compilations doit donc se dérouler sous l'ancien noyau puisqu'elle
utilise l'ancien monde pour ce faire ?
En résumé, c'est d'après ce que j'ai sous les yeux :
(ce n'est pas la dernière version, je l'ai imprimée il y a plus de 6 mois)
*Démarrage Mode Single User
make build world
make buildkernel
make installkernel
[Noyau incompatible avec l'ancien monde] Tu pourrais réparer le problème avec un CD de rescue, facilement.
Ce n'est pas une situation que j'apprécie particulièrement.
Le vrai problème de cette histoire c'est que le handbook est trés mal rédigé sur ce sujet, et, bien qu'il ne dise pas de chose fausse, je crois, une lecture inattentive laisse penser qu'il dit le contraire de ce qu'il faut.
Et, le make buildworld est décrit _avant_ la compilation et l'installation du noyau. Ce qui est logique, si l'on suit le raisonnement de Thomas. Les compilations doit donc se dérouler sous l'ancien noyau puisqu'elle utilise l'ancien monde pour ce faire ?
En résumé, c'est d'après ce que j'ai sous les yeux : (ce n'est pas la dernière version, je l'ai imprimée il y a plus de 6 mois)
*Démarrage Mode Single User make build world make buildkernel make installkernel
David MAREC
[Supersedes, problème de doigts]
Selon Michel Talon:
[Noyau incompatible avec l'ancien monde] Tu pourrais réparer le problème avec un CD de rescue, facilement.
Ce n'est pas une situation que j'apprécie particulièrement.
Le vrai problème de cette histoire c'est que le handbook est trés mal rédigé sur ce sujet, et, bien qu'il ne dise pas de chose fausse, je crois, une lecture inattentive laisse penser qu'il dit le contraire de ce qu'il faut.
Et, le make buildworld est décrit _avant_ la compilation et l'installation du noyau. Ce qui serait logique, si l'on suit le raisonnement de Thomas: Les compilations doivent donc se dérouler sous l'ancien noyau puisqu'elle utilise l'ancien monde pour ce faire ?
En résumé, c'est d'après ce que j'ai sous les yeux : (ce n'est pas la dernière version, je l'ai imprimée il y a plus de 6 mois)
mergemaster *Démarrage Mode Single User make build world make buildkernel make installkernel *Démarrage Mode Single User make installworld mergemaster
-- 'Manque un bon schéma, là.
[Supersedes, problème de doigts]
Selon Michel Talon:
[Noyau incompatible avec l'ancien monde]
Tu pourrais réparer le problème avec un CD de rescue, facilement.
Ce n'est pas une situation que j'apprécie particulièrement.
Le vrai problème de cette histoire c'est que le handbook est trés mal
rédigé sur ce sujet, et, bien qu'il ne dise pas de chose fausse, je
crois, une lecture inattentive laisse penser qu'il dit le contraire de
ce qu'il faut.
Et, le make buildworld est décrit _avant_ la compilation et l'installation
du noyau.
Ce qui serait logique, si l'on suit le raisonnement de Thomas:
Les compilations doivent donc se dérouler sous l'ancien noyau puisqu'elle
utilise l'ancien monde pour ce faire ?
En résumé, c'est d'après ce que j'ai sous les yeux :
(ce n'est pas la dernière version, je l'ai imprimée il y a plus de 6 mois)
mergemaster
*Démarrage Mode Single User
make build world
make buildkernel
make installkernel
*Démarrage Mode Single User
make installworld
mergemaster
[Noyau incompatible avec l'ancien monde] Tu pourrais réparer le problème avec un CD de rescue, facilement.
Ce n'est pas une situation que j'apprécie particulièrement.
Le vrai problème de cette histoire c'est que le handbook est trés mal rédigé sur ce sujet, et, bien qu'il ne dise pas de chose fausse, je crois, une lecture inattentive laisse penser qu'il dit le contraire de ce qu'il faut.
Et, le make buildworld est décrit _avant_ la compilation et l'installation du noyau. Ce qui serait logique, si l'on suit le raisonnement de Thomas: Les compilations doivent donc se dérouler sous l'ancien noyau puisqu'elle utilise l'ancien monde pour ce faire ?
En résumé, c'est d'après ce que j'ai sous les yeux : (ce n'est pas la dernière version, je l'ai imprimée il y a plus de 6 mois)
mergemaster *Démarrage Mode Single User make build world make buildkernel make installkernel *Démarrage Mode Single User make installworld mergemaster
-- 'Manque un bon schéma, là.
Marwan Burelle
On Tue, 27 Jan 2004 19:12:57 +0100 David MAREC wrote:
En résumé, c'est d'après ce que j'ai sous les yeux : (ce n'est pas la dernière version, je l'ai imprimée il y a plus de 6 mois)
mergemaster
Avec l'option pour la "préinstall" et nécessaire seulement s'il y a des changements dans master.passwd. D'ailleurs je me demande, si ce n'est pas à faire après le buildworld plutôt ...
*Démarrage Mode Single User
Pas nécessaire, c'est surtout pour accélerer le truc ...
make build world make buildkernel make installkernel *Démarrage Mode Single User make installworld mergemaster
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On Tue, 27 Jan 2004 19:12:57 +0100
David MAREC <dmarec.spam@spambox.invalid> wrote:
En résumé, c'est d'après ce que j'ai sous les yeux :
(ce n'est pas la dernière version, je l'ai imprimée il y a plus de 6
mois)
mergemaster
Avec l'option pour la "préinstall" et nécessaire seulement s'il y a des
changements dans master.passwd. D'ailleurs je me demande, si ce n'est
pas à faire après le buildworld plutôt ...
*Démarrage Mode Single User
Pas nécessaire, c'est surtout pour accélerer le truc ...
make build world
make buildkernel
make installkernel
*Démarrage Mode Single User
make installworld
mergemaster
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
On Tue, 27 Jan 2004 19:12:57 +0100 David MAREC wrote:
En résumé, c'est d'après ce que j'ai sous les yeux : (ce n'est pas la dernière version, je l'ai imprimée il y a plus de 6 mois)
mergemaster
Avec l'option pour la "préinstall" et nécessaire seulement s'il y a des changements dans master.passwd. D'ailleurs je me demande, si ce n'est pas à faire après le buildworld plutôt ...
*Démarrage Mode Single User
Pas nécessaire, c'est surtout pour accélerer le truc ...
make build world make buildkernel make installkernel *Démarrage Mode Single User make installworld mergemaster
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
David MAREC
Selon David MAREC:
Et, le make buildworld est décrit _avant_ la compilation et l'installation du noyau.
Et j'étais persuadé d'avoir lu l'inverse dans ce fil. Comme quoi, on s'embrouille facilement.
Selon David MAREC:
Et, le make buildworld est décrit _avant_ la compilation et l'installation
du noyau.
Et j'étais persuadé d'avoir lu l'inverse dans ce fil.
Comme quoi, on s'embrouille facilement.
Stupide. 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.
make build world make buildkernel make installkernel *Démarrage Mode Single User make installworld mergemaster
Cette partie là est correcte, sauf que tu n'a pas compris le but du mergemaster.
-- Laurent
talon
David MAREC wrote:
Et, le make buildworld est décrit _avant_ la compilation et l'installation du noyau. Ce qui serait logique, si l'on suit le raisonnement de Thomas: Les compilations doivent donc se dérouler sous l'ancien noyau puisqu'elle utilise l'ancien monde pour ce faire ?
Oui. A vrai dire le make buildworld compile une première fois à partir
de l'ancien userland, puis une nouvelle fois, à partir des utilitaires déjà compilés, de façon que tout se passe comme si on avait compilé dans le nouveau monde.
--
Michel TALON
David MAREC <dmarec.spam@spambox.invalid> wrote:
Et, le make buildworld est décrit _avant_ la compilation et l'installation
du noyau.
Ce qui serait logique, si l'on suit le raisonnement de Thomas:
Les compilations doivent donc se dérouler sous l'ancien noyau puisqu'elle
utilise l'ancien monde pour ce faire ?
Oui. A vrai dire le make buildworld compile une première fois à partir
de l'ancien userland, puis une nouvelle fois, à partir des utilitaires
déjà compilés, de façon que tout se passe comme si on avait compilé dans
le nouveau monde.
Et, le make buildworld est décrit _avant_ la compilation et l'installation du noyau. Ce qui serait logique, si l'on suit le raisonnement de Thomas: Les compilations doivent donc se dérouler sous l'ancien noyau puisqu'elle utilise l'ancien monde pour ce faire ?
Oui. A vrai dire le make buildworld compile une première fois à partir
de l'ancien userland, puis une nouvelle fois, à partir des utilitaires déjà compilés, de façon que tout se passe comme si on avait compilé dans le nouveau monde.
--
Michel TALON
talon
David MAREC wrote:
Selon David MAREC:
Et, le make buildworld est décrit _avant_ la compilation et l'installation du noyau.
Et j'étais persuadé d'avoir lu l'inverse dans ce fil. Comme quoi, on s'embrouille facilement.
Non j'ai pas vu l'inverse. Le make buildworld prépare des outils qui
permettent de faire le make buildkernel avec le *nouvel* userland caché sous /usr/obj.
Donc en résumé, comme ça a toujours été dit, sauf dans le charabia du Handbook:
mount -a pour pouvoir écrire!!! (*) installworld mergemaster
multiuser ...
A vrai dire je n'ai pas eu d'ennui à faire mergemaster en multiuser sous X, ce qui est plus confortable.
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. Pour mergemaster il faut se souvenir quand on veut faire un merge que:
Il vaut mieux que EDITOR=vi !!! dés le départ
on peut choisir 'l' pour la gauche, 'r' pour la droite et 'e b' pour éditer l'ensemble du diff sous vi. Evidemment il faut repérer si c'est l'ancien ou le nouveau à gauche ou à droite, donc largement de quoi se mettre dedans.
(*) Cas particulier installation en réseau par NFS. Dans cette étape, il faut démarrer le réseau (/etc/netstart) monter /usr/src et /usr/obj pour pouvoir faire l'install.
--
Michel TALON
David MAREC <dmarec.spam@spambox.invalid> wrote:
Selon David MAREC:
Et, le make buildworld est décrit _avant_ la compilation et l'installation
du noyau.
Et j'étais persuadé d'avoir lu l'inverse dans ce fil.
Comme quoi, on s'embrouille facilement.
Non j'ai pas vu l'inverse. Le make buildworld prépare des outils qui
permettent de faire le make buildkernel avec le *nouvel* userland
caché sous /usr/obj.
Donc en résumé, comme ça a toujours été dit, sauf dans le charabia du
Handbook:
mount -a pour pouvoir écrire!!! (*)
installworld
mergemaster
multiuser ...
A vrai dire je n'ai pas eu d'ennui à faire mergemaster en multiuser sous
X, ce qui est plus confortable.
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. Pour mergemaster il faut se souvenir quand on veut faire un
merge que:
Il vaut mieux que EDITOR=vi !!! dés le départ
on peut choisir 'l' pour la gauche, 'r' pour la droite et 'e b'
pour éditer l'ensemble du diff sous vi. Evidemment il faut repérer si
c'est l'ancien ou le nouveau à gauche ou à droite, donc largement de
quoi se mettre dedans.
(*) Cas particulier installation en réseau par NFS. Dans cette étape,
il faut démarrer le réseau (/etc/netstart) monter /usr/src et /usr/obj
pour pouvoir faire l'install.
mount -a pour pouvoir écrire!!! (*) installworld mergemaster
multiuser ...
A vrai dire je n'ai pas eu d'ennui à faire mergemaster en multiuser sous X, ce qui est plus confortable.
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. Pour mergemaster il faut se souvenir quand on veut faire un merge que:
Il vaut mieux que EDITOR=vi !!! dés le départ
on peut choisir 'l' pour la gauche, 'r' pour la droite et 'e b' pour éditer l'ensemble du diff sous vi. Evidemment il faut repérer si c'est l'ancien ou le nouveau à gauche ou à droite, donc largement de quoi se mettre dedans.
(*) Cas particulier installation en réseau par NFS. Dans cette étape, il faut démarrer le réseau (/etc/netstart) monter /usr/src et /usr/obj pour pouvoir faire l'install.
--
Michel TALON
Eric Masson
"Michel" == Michel Talon writes:
Michel> Oui. A vrai dire le make buildworld compile une première fois à Michel> partir de l'ancien userland,
Il ne compile que la nouvelle version de la toolchain à l'aide du système couramment installé.
Après, il utilise la nouvelle version de la toolchain pour compiler le reste du système.
Eric Masson
-- RECHERCHE DES INGENIEURS DANS Linformatique IMPORTANT !! Envoyez moi vos cV -+- in Guide du Neuneu sur Usenet : Linformatique pour les nuls -+-
"Michel" == Michel Talon <talon@lpthe.jussieu.fr> writes:
Michel> Oui. A vrai dire le make buildworld compile une première fois à
Michel> partir de l'ancien userland,
Il ne compile que la nouvelle version de la toolchain à l'aide du
système couramment installé.
Après, il utilise la nouvelle version de la toolchain pour compiler le
reste du système.
Eric Masson
--
RECHERCHE DES INGENIEURS DANS Linformatique IMPORTANT !!
Envoyez moi vos cV
-+- in Guide du Neuneu sur Usenet : Linformatique pour les nuls -+-
Michel> Oui. A vrai dire le make buildworld compile une première fois à Michel> partir de l'ancien userland,
Il ne compile que la nouvelle version de la toolchain à l'aide du système couramment installé.
Après, il utilise la nouvelle version de la toolchain pour compiler le reste du système.
Eric Masson
-- RECHERCHE DES INGENIEURS DANS Linformatique IMPORTANT !! Envoyez moi vos cV -+- in Guide du Neuneu sur Usenet : Linformatique pour les nuls -+-
Eric Masson
"Xav" == xavier writes:
Xav> Ah non, ça va pas recommencer avec les câbles de 300 km :-)
Ben, avec de bons amplis de ligne, tu dois avoir un poil de latence, mais ça doit le faire ;)
Eric Masson
-- j'ai pour habitude de mettre le post auquel je réponds sous le mien et non au dessus et ce n'est pas de l'impolitesse envers vous il faudra bien que vous vous y habituez -+- MP in Guide du Neuneu d'Usenet : Le mépris par l'exemple -+-
"Xav" == xavier <xavier@groumpf.org> writes:
Xav> Ah non, ça va pas recommencer avec les câbles de 300 km :-)
Ben, avec de bons amplis de ligne, tu dois avoir un poil de latence,
mais ça doit le faire ;)
Eric Masson
--
j'ai pour habitude de mettre le post auquel je réponds sous le
mien et non au dessus et ce n'est pas de l'impolitesse envers vous il
faudra bien que vous vous y habituez
-+- MP in Guide du Neuneu d'Usenet : Le mépris par l'exemple -+-
Xav> Ah non, ça va pas recommencer avec les câbles de 300 km :-)
Ben, avec de bons amplis de ligne, tu dois avoir un poil de latence, mais ça doit le faire ;)
Eric Masson
-- j'ai pour habitude de mettre le post auquel je réponds sous le mien et non au dessus et ce n'est pas de l'impolitesse envers vous il faudra bien que vous vous y habituez -+- MP in Guide du Neuneu d'Usenet : Le mépris par l'exemple -+-
David MAREC
Selon Michel Talon:
[make buildworld avant le make buildkernel] Et j'étais persuadé d'avoir lu l'inverse dans ce fil. Comme quoi, on s'embrouille facilement.
Non j'ai pas vu l'inverse.
Et je ne l'ai certainement pas lu non plus, mais j'ai rédigé cette phrase croyant l'avoir vu dans le fil.
Donc en résumé, comme ça a toujours été dit, sauf dans le charabia du Handbook:
C'est maladroit. Prenons un exemple au hasard: moi.
J'ai, en bon novice, suivi la procédure suivante pour installer FreeBSD la première fois:
Installation du CéDé et réponses aux quelques questions posées. Intégration rapide de la station dans le réseau. Lecture de la doc de l'imprimante PostScript de l'entreprise. Edition de printcap pour configurer cette imprimante. Impression des 600 pages du manuel. Lecture du manuel.
Il serait donc intéressant de ré-écrire ce chapitre ou de rédiger une F.A.Q. sur le sujet ?
Le problème étant qu'aux premières lectures, cette procédure m'avait semblé touffue et confuse, c'est pourquoi je me suis intéressé à ce fil. Et suite à vos explications, le document que j'ai entre les mains me semble suffisamment clair. :-) - Cela est sans du aussi au fait que j'ai mieux pris en main le système. -
Enfin, suffisamment clair, sauf pour ce qui suit :
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.
Je suis impatient de le connaître s'il existe.
Selon Michel Talon:
[make buildworld avant le make buildkernel]
Et j'étais persuadé d'avoir lu l'inverse dans ce fil.
Comme quoi, on s'embrouille facilement.
Non j'ai pas vu l'inverse.
Et je ne l'ai certainement pas lu non plus, mais j'ai rédigé cette phrase
croyant l'avoir vu dans le fil.
Donc en résumé, comme ça a toujours été dit, sauf dans le charabia du
Handbook:
C'est maladroit.
Prenons un exemple au hasard: moi.
J'ai, en bon novice, suivi la procédure suivante pour installer FreeBSD la
première fois:
Installation du CéDé et réponses aux quelques questions posées.
Intégration rapide de la station dans le réseau.
Lecture de la doc de l'imprimante PostScript de l'entreprise.
Edition de printcap pour configurer cette imprimante.
Impression des 600 pages du manuel.
Lecture du manuel.
Il serait donc intéressant de ré-écrire ce chapitre ou de rédiger une F.A.Q.
sur le sujet ?
Le problème étant qu'aux premières lectures, cette procédure m'avait semblé
touffue et confuse, c'est pourquoi je me suis intéressé à ce fil.
Et suite à vos explications, le document que j'ai entre les mains me semble
suffisamment clair. :-)
- Cela est sans du aussi au fait que j'ai mieux pris en main le système. -
Enfin, suffisamment clair, sauf pour ce qui suit :
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.
[make buildworld avant le make buildkernel] Et j'étais persuadé d'avoir lu l'inverse dans ce fil. Comme quoi, on s'embrouille facilement.
Non j'ai pas vu l'inverse.
Et je ne l'ai certainement pas lu non plus, mais j'ai rédigé cette phrase croyant l'avoir vu dans le fil.
Donc en résumé, comme ça a toujours été dit, sauf dans le charabia du Handbook:
C'est maladroit. Prenons un exemple au hasard: moi.
J'ai, en bon novice, suivi la procédure suivante pour installer FreeBSD la première fois:
Installation du CéDé et réponses aux quelques questions posées. Intégration rapide de la station dans le réseau. Lecture de la doc de l'imprimante PostScript de l'entreprise. Edition de printcap pour configurer cette imprimante. Impression des 600 pages du manuel. Lecture du manuel.
Il serait donc intéressant de ré-écrire ce chapitre ou de rédiger une F.A.Q. sur le sujet ?
Le problème étant qu'aux premières lectures, cette procédure m'avait semblé touffue et confuse, c'est pourquoi je me suis intéressé à ce fil. Et suite à vos explications, le document que j'ai entre les mains me semble suffisamment clair. :-) - Cela est sans du aussi au fait que j'ai mieux pris en main le système. -
Enfin, suffisamment clair, sauf pour ce qui suit :
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.