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!
make installkernel make installworld en espérant que ça passe au moins un peu D'après mes tests, impossible pour un passage 4.X vers 5.2. Une fois une
partie du installworld réalisée on se vautre en beauté avec des SIGSYS de partout. Ensuite c'est passage obligé par la case fixit.
On peut pas faire un truc du style: on copie tout l'userland dans un dossier, on mounte / en nullfs dans /old_root/new_root , ensuite, on fait un chroot, et on installe le tout dans new_root avant de rebooter ?
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
make installkernel
make installworld en espérant que ça passe au moins un peu
D'après mes tests, impossible pour un passage 4.X vers 5.2. Une fois une
partie du installworld réalisée on se vautre en beauté avec des SIGSYS
de partout. Ensuite c'est passage obligé par la case fixit.
On peut pas faire un truc du style: on copie tout l'userland dans un
dossier, on mounte / en nullfs dans /old_root/new_root , ensuite, on
fait un chroot, et on installe le tout dans new_root avant de rebooter ?
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
make installkernel make installworld en espérant que ça passe au moins un peu D'après mes tests, impossible pour un passage 4.X vers 5.2. Une fois une
partie du installworld réalisée on se vautre en beauté avec des SIGSYS de partout. Ensuite c'est passage obligé par la case fixit.
On peut pas faire un truc du style: on copie tout l'userland dans un dossier, on mounte / en nullfs dans /old_root/new_root , ensuite, on fait un chroot, et on installe le tout dans new_root avant de rebooter ?
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Laurent Lefevre
Nicolas Le Scouarnec writes:
Hum... Dans le manuel FreeBSD, c'est plutot make buildworld make buildkernel make installkernel
Là tu installes le noyau GENERIC, si on veut plutôt le noyau custom, make kernel KERNCONF=CUSTOM, CUSTOM étant le nom du noyau que l'on a modifié, pour ceux qui ont du mal à suivre.
reboot (single) mergemaster -p make installworld mergemaster
C'est effectivement écrit dans le handbook depuis des lustres.
En plus, il y a les pages man :
man mergemaster(8):
DESCRIPTION The mergemaster utility is a Bourne shell script which is designed to aid you in updating the various configuration and other files associated with FreeBSD It is HIGHLY recommended that you back up your /etc directory before beginning this process.
-- Laurent
Nicolas Le Scouarnec <root@india.ath.cx.nospam.invalid> writes:
Hum... Dans le manuel FreeBSD, c'est plutot
make buildworld
make buildkernel
make installkernel
Là tu installes le noyau GENERIC, si on veut plutôt le noyau custom,
make kernel KERNCONF=CUSTOM, CUSTOM étant le nom du noyau que l'on
a modifié, pour ceux qui ont du mal à suivre.
reboot (single)
mergemaster -p
make installworld
mergemaster
C'est effectivement écrit dans le handbook depuis des lustres.
En plus, il y a les pages man :
man mergemaster(8):
DESCRIPTION
The mergemaster utility is a Bourne shell script which is designed
to aid you in updating the various configuration and other files
associated with FreeBSD It is HIGHLY recommended that you back up your
/etc directory before beginning this process.
Hum... Dans le manuel FreeBSD, c'est plutot make buildworld make buildkernel make installkernel
Là tu installes le noyau GENERIC, si on veut plutôt le noyau custom, make kernel KERNCONF=CUSTOM, CUSTOM étant le nom du noyau que l'on a modifié, pour ceux qui ont du mal à suivre.
reboot (single) mergemaster -p make installworld mergemaster
C'est effectivement écrit dans le handbook depuis des lustres.
En plus, il y a les pages man :
man mergemaster(8):
DESCRIPTION The mergemaster utility is a Bourne shell script which is designed to aid you in updating the various configuration and other files associated with FreeBSD It is HIGHLY recommended that you back up your /etc directory before beginning this process.
-- Laurent
Marwan Burelle
On Wed, 28 Jan 2004 17:21:02 +0100 David MAREC wrote:
« Since 4.6-RELEASE you can run mergemaster(8) in pre-buildworld mode by providing the -p option. This will compare only those files that are essential for the success of buildworld or installworld. » soit un mergemaster -p *avant* le make builworld.
J'ai pas souvenir de cas, où le mergemaster est été nécessaire avant le build, plutôt juste avant l'install.
Maintenant, ce n'est pas impossible qu'il y ai certain build qui nécessite certaines modifs de /etc avant.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On Wed, 28 Jan 2004 17:21:02 +0100
David MAREC <dmarec.spam@free.invalid> wrote:
«
Since 4.6-RELEASE you can run mergemaster(8) in pre-buildworld mode by
providing the -p option. This will compare only those files that are
essential for the success of buildworld or installworld.
»
soit un mergemaster -p *avant* le make builworld.
J'ai pas souvenir de cas, où le mergemaster est été nécessaire avant le
build, plutôt juste avant l'install.
Maintenant, ce n'est pas impossible qu'il y ai certain build qui
nécessite certaines modifs de /etc avant.
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
On Wed, 28 Jan 2004 17:21:02 +0100 David MAREC wrote:
« Since 4.6-RELEASE you can run mergemaster(8) in pre-buildworld mode by providing the -p option. This will compare only those files that are essential for the success of buildworld or installworld. » soit un mergemaster -p *avant* le make builworld.
J'ai pas souvenir de cas, où le mergemaster est été nécessaire avant le build, plutôt juste avant l'install.
Maintenant, ce n'est pas impossible qu'il y ai certain build qui nécessite certaines modifs de /etc avant.
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Eric Masson
"Marwan" == Marwan Burelle writes:
Marwan> Maintenant, ce n'est pas impossible qu'il y ai certain build Marwan> qui nécessite certaines modifs de /etc avant.
Pas forcément un build, mais un install oui, par exemple lors du split de sendmail en plusieurs daemons, les comptes snmsp et mailnull devaient être présents pour que l'install du bouzin passe, et iirc, c'était la même chose avec sshd lors de la mise en place de privsep.
Eric Masson
-- VR> y'en a vraiment qui manquent pas d'air. Alors là, je m'insurge ! Il ne manque certainement pas d'air, comme toutes les baudruches. -+- RG in <http://www.le-gnu.net> -+- Il est pas beau druche ? -+-
Marwan> Maintenant, ce n'est pas impossible qu'il y ai certain build
Marwan> qui nécessite certaines modifs de /etc avant.
Pas forcément un build, mais un install oui, par exemple lors du split
de sendmail en plusieurs daemons, les comptes snmsp et mailnull devaient
être présents pour que l'install du bouzin passe, et iirc, c'était la
même chose avec sshd lors de la mise en place de privsep.
Eric Masson
--
VR> y'en a vraiment qui manquent pas d'air.
Alors là, je m'insurge !
Il ne manque certainement pas d'air, comme toutes les baudruches.
-+- RG in <http://www.le-gnu.net> -+- Il est pas beau druche ? -+-
Marwan> Maintenant, ce n'est pas impossible qu'il y ai certain build Marwan> qui nécessite certaines modifs de /etc avant.
Pas forcément un build, mais un install oui, par exemple lors du split de sendmail en plusieurs daemons, les comptes snmsp et mailnull devaient être présents pour que l'install du bouzin passe, et iirc, c'était la même chose avec sshd lors de la mise en place de privsep.
Eric Masson
-- VR> y'en a vraiment qui manquent pas d'air. Alors là, je m'insurge ! Il ne manque certainement pas d'air, comme toutes les baudruches. -+- RG in <http://www.le-gnu.net> -+- Il est pas beau druche ? -+-
Nicolas Le Scouarnec
Maintenant, ce n'est pas impossible qu'il y ai certain build qui nécessite certaines modifs de /etc avant.
Pour moi, le mergemaster -p n'a rien fait, il me montre simplement les modifications apportées a make.conf, donc ca peut rappeler que l'on a des optimisations "trop fortes" qui empecheront la compilation.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Maintenant, ce n'est pas impossible qu'il y ai certain build qui
nécessite certaines modifs de /etc avant.
Pour moi, le mergemaster -p n'a rien fait, il me montre simplement les
modifications apportées a make.conf, donc ca peut rappeler que l'on a des
optimisations "trop fortes" qui empecheront la compilation.
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Maintenant, ce n'est pas impossible qu'il y ai certain build qui nécessite certaines modifs de /etc avant.
Pour moi, le mergemaster -p n'a rien fait, il me montre simplement les modifications apportées a make.conf, donc ca peut rappeler que l'on a des optimisations "trop fortes" qui empecheront la compilation.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Marwan Burelle
On Wed, 28 Jan 2004 17:00:29 +0000 (UTC) Nicolas Le Scouarnec wrote:
Pour moi, le mergemaster -p n'a rien fait, il me montre simplement les modifications apportées a make.conf, donc ca peut rappeler que l'on a des optimisations "trop fortes" qui empecheront la compilation.
Si tu avais eu des changement dans master.passwd ou dans group, tu aurais vu ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On Wed, 28 Jan 2004 17:00:29 +0000 (UTC)
Nicolas Le Scouarnec <root@india.ath.cx.nospam.invalid> wrote:
Pour moi, le mergemaster -p n'a rien fait, il me montre simplement les
modifications apportées a make.conf, donc ca peut rappeler que l'on a
des optimisations "trop fortes" qui empecheront la compilation.
Si tu avais eu des changement dans master.passwd ou dans group, tu
aurais vu ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
On Wed, 28 Jan 2004 17:00:29 +0000 (UTC) Nicolas Le Scouarnec wrote:
Pour moi, le mergemaster -p n'a rien fait, il me montre simplement les modifications apportées a make.conf, donc ca peut rappeler que l'on a des optimisations "trop fortes" qui empecheront la compilation.
Si tu avais eu des changement dans master.passwd ou dans group, tu aurais vu ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
pornin
According to David MAREC :
Le problème serait plutôt qu'il faille maitriser la procédure _avant_ de lire la doc ? :-)
Moi qui ai des réflexes de programmeur, avant de taper une commande qui commence par "make", je regarde un peu le Makefile. Or, il s'avère que /usr/src/Makefile commence par des commentaires très lisibles qui donnent la marche à suivre. J'y lis entre autres ceci :
# For individuals wanting to upgrade their sources (even if only a # delta of a few days): # # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 5. `reboot' (in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `mergemaster' # 9. `reboot'
ce qui est quand même très précis et clair.
--Thomas Pornin
According to David MAREC <dmarec.spam@free.fr>:
Le problème serait plutôt qu'il faille maitriser la procédure _avant_ de
lire la doc ? :-)
Moi qui ai des réflexes de programmeur, avant de taper une commande
qui commence par "make", je regarde un peu le Makefile. Or, il s'avère
que /usr/src/Makefile commence par des commentaires très lisibles qui
donnent la marche à suivre. J'y lis entre autres ceci :
# For individuals wanting to upgrade their sources (even if only a
# delta of a few days):
#
# 1. `cd /usr/src' (or to the directory containing your source tree).
# 2. `make buildworld'
# 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
# 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC).
# 5. `reboot' (in single user mode: boot -s from the loader prompt).
# 6. `mergemaster -p'
# 7. `make installworld'
# 8. `mergemaster'
# 9. `reboot'
Le problème serait plutôt qu'il faille maitriser la procédure _avant_ de lire la doc ? :-)
Moi qui ai des réflexes de programmeur, avant de taper une commande qui commence par "make", je regarde un peu le Makefile. Or, il s'avère que /usr/src/Makefile commence par des commentaires très lisibles qui donnent la marche à suivre. J'y lis entre autres ceci :
# For individuals wanting to upgrade their sources (even if only a # delta of a few days): # # 1. `cd /usr/src' (or to the directory containing your source tree). # 2. `make buildworld' # 3. `make buildkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 4. `make installkernel KERNCONF=YOUR_KERNEL_HERE' (default is GENERIC). # 5. `reboot' (in single user mode: boot -s from the loader prompt). # 6. `mergemaster -p' # 7. `make installworld' # 8. `mergemaster' # 9. `reboot'
ce qui est quand même très précis et clair.
--Thomas Pornin
talon
Thomas Pornin wrote:
ce qui est quand même très précis et clair.
Oui, mais le point est que le handbook est beaucoup moins précis et clair. Comment ce fait-il que personne ne le modifie alors que cette situation est connue depuis longtemps, ça m'échappe.
--Thomas Pornin
--
Michel TALON
Thomas Pornin <pornin@nerim.net> wrote:
ce qui est quand même très précis et clair.
Oui, mais le point est que le handbook est beaucoup moins précis et
clair. Comment ce fait-il que personne ne le modifie alors que cette
situation est connue depuis longtemps, ça m'échappe.
Oui, mais le point est que le handbook est beaucoup moins précis et clair. Comment ce fait-il que personne ne le modifie alors que cette situation est connue depuis longtemps, ça m'échappe.
--Thomas Pornin
--
Michel TALON
pornin
According to Michel Talon :
Oui, mais le point est que le handbook est beaucoup moins précis et clair. Comment ce fait-il que personne ne le modifie alors que cette situation est connue depuis longtemps, ça m'échappe.
Que la documentation ne soit pas à jour et/ou obscure, que ce soit un fait connu, et que personne ne fasse rien à ce sujet, est une situation courante dans le monde du développement logiciel, et donc non seulement ce n'est pas étonnant, mais en plus c'est assez facilement explicable par le fait qu'écrire de la doc, globalement, ce n'est pas rigolo.
Dit d'une autre manière : ceux qui sont à même de corriger le handbook ne lisent pas le handbook de toutes façons, mais /usr/src/UPDATING ou /usr/src/Makefile, et le problème leur apparaît comme peu crucial. La flemme fait le reste.
--Thomas Pornin
According to Michel Talon <talon@lpthe.jussieu.fr>:
Oui, mais le point est que le handbook est beaucoup moins précis et
clair. Comment ce fait-il que personne ne le modifie alors que cette
situation est connue depuis longtemps, ça m'échappe.
Que la documentation ne soit pas à jour et/ou obscure, que ce soit un
fait connu, et que personne ne fasse rien à ce sujet, est une situation
courante dans le monde du développement logiciel, et donc non seulement
ce n'est pas étonnant, mais en plus c'est assez facilement explicable
par le fait qu'écrire de la doc, globalement, ce n'est pas rigolo.
Dit d'une autre manière : ceux qui sont à même de corriger le handbook
ne lisent pas le handbook de toutes façons, mais /usr/src/UPDATING ou
/usr/src/Makefile, et le problème leur apparaît comme peu crucial. La
flemme fait le reste.
Oui, mais le point est que le handbook est beaucoup moins précis et clair. Comment ce fait-il que personne ne le modifie alors que cette situation est connue depuis longtemps, ça m'échappe.
Que la documentation ne soit pas à jour et/ou obscure, que ce soit un fait connu, et que personne ne fasse rien à ce sujet, est une situation courante dans le monde du développement logiciel, et donc non seulement ce n'est pas étonnant, mais en plus c'est assez facilement explicable par le fait qu'écrire de la doc, globalement, ce n'est pas rigolo.
Dit d'une autre manière : ceux qui sont à même de corriger le handbook ne lisent pas le handbook de toutes façons, mais /usr/src/UPDATING ou /usr/src/Makefile, et le problème leur apparaît comme peu crucial. La flemme fait le reste.
--Thomas Pornin
talon
Thomas Pornin wrote:
According to Michel Talon :
Oui, mais le point est que le handbook est beaucoup moins précis et clair. Comment ce fait-il que personne ne le modifie alors que cette situation est connue depuis longtemps, ça m'échappe.
Que la documentation ne soit pas à jour et/ou obscure, que ce soit un fait connu, et que personne ne fasse rien à ce sujet, est une situation courante dans le monde du développement logiciel, et donc non seulement ce n'est pas étonnant, mais en plus c'est assez facilement explicable par le fait qu'écrire de la doc, globalement, ce n'est pas rigolo.(*)
Dit d'une autre manière : ceux qui sont à même de corriger le handbook ne lisent pas le handbook de toutes façons, mais /usr/src/UPDATING ou /usr/src/Makefile, et le problème leur apparaît comme peu crucial. La flemme fait le reste.
Oui, autant que tu veux, mais l'un des gros points forts de FreeBSD par rapport à Linux est d'avoir une bonne documentation, notamment le Handbook. Donc c'est dommage qu'il ne soit pas peaufiné sur des points scabreux et importants comme celui là. Evidemment ça concerne l'équipe de documentation, qui est je crois assez grosse, et non pas celle de développement.
(*) surtout que dans le cas d'espèce, les modifications requises sont du type à prendre 5 minutes, ce n'est pas comme s'il y avait 3 pages à écrire.
--Thomas Pornin
--
Michel TALON
Thomas Pornin <pornin@nerim.net> wrote:
According to Michel Talon <talon@lpthe.jussieu.fr>:
Oui, mais le point est que le handbook est beaucoup moins précis et
clair. Comment ce fait-il que personne ne le modifie alors que cette
situation est connue depuis longtemps, ça m'échappe.
Que la documentation ne soit pas à jour et/ou obscure, que ce soit un
fait connu, et que personne ne fasse rien à ce sujet, est une situation
courante dans le monde du développement logiciel, et donc non seulement
ce n'est pas étonnant, mais en plus c'est assez facilement explicable
par le fait qu'écrire de la doc, globalement, ce n'est pas rigolo.(*)
Dit d'une autre manière : ceux qui sont à même de corriger le handbook
ne lisent pas le handbook de toutes façons, mais /usr/src/UPDATING ou
/usr/src/Makefile, et le problème leur apparaît comme peu crucial. La
flemme fait le reste.
Oui, autant que tu veux, mais l'un des gros points forts de FreeBSD par
rapport à Linux est d'avoir une bonne documentation, notamment le
Handbook. Donc c'est dommage qu'il ne soit pas peaufiné sur des points
scabreux et importants comme celui là. Evidemment ça concerne l'équipe
de documentation, qui est je crois assez grosse, et non pas celle de
développement.
(*) surtout que dans le cas d'espèce, les modifications requises sont
du type à prendre 5 minutes, ce n'est pas comme s'il y avait 3 pages à
écrire.
Oui, mais le point est que le handbook est beaucoup moins précis et clair. Comment ce fait-il que personne ne le modifie alors que cette situation est connue depuis longtemps, ça m'échappe.
Que la documentation ne soit pas à jour et/ou obscure, que ce soit un fait connu, et que personne ne fasse rien à ce sujet, est une situation courante dans le monde du développement logiciel, et donc non seulement ce n'est pas étonnant, mais en plus c'est assez facilement explicable par le fait qu'écrire de la doc, globalement, ce n'est pas rigolo.(*)
Dit d'une autre manière : ceux qui sont à même de corriger le handbook ne lisent pas le handbook de toutes façons, mais /usr/src/UPDATING ou /usr/src/Makefile, et le problème leur apparaît comme peu crucial. La flemme fait le reste.
Oui, autant que tu veux, mais l'un des gros points forts de FreeBSD par rapport à Linux est d'avoir une bonne documentation, notamment le Handbook. Donc c'est dommage qu'il ne soit pas peaufiné sur des points scabreux et importants comme celui là. Evidemment ça concerne l'équipe de documentation, qui est je crois assez grosse, et non pas celle de développement.
(*) surtout que dans le cas d'espèce, les modifications requises sont du type à prendre 5 minutes, ce n'est pas comme s'il y avait 3 pages à écrire.
