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!
Marwan> par contre, je ne sais pas ce que change le passage avec bin et Marwan> sbin en dynamique (quelle hérésie !) )
Pas grand chose, si tu pètes la babasse, il te reste /rescue qui est compilé en statique.
Le passage de /bin et /sbin en dynamique permet iirc, un méchant gain de place et une meilleure intégration de nsswitch et des modules existants sans avoir à les modifier énormément.
Matt Dillon est entrain de développer une autre méthode pour l'intégration de modules nsswitch qui permettrait de conserver /bin et /sbin statiques ainsi qu'une méthode pour accélérer le chargement des binaires liés dynamiquement.
Eric Masson
-- PR> tu es en avance d'un an pour le nouveau millénaire il me semble que (2000) est bien le nouveau millenaire justement par contre on change de siecle l'annee prochaine en 2001 -+- kiboot in http://www.le-gnu.net : Émile énerve pour l'an d'Émile.
Marwan> par contre, je ne sais pas ce que change le passage avec bin et
Marwan> sbin en dynamique (quelle hérésie !) )
Pas grand chose, si tu pètes la babasse, il te reste /rescue qui est
compilé en statique.
Le passage de /bin et /sbin en dynamique permet iirc, un méchant gain de
place et une meilleure intégration de nsswitch et des modules existants
sans avoir à les modifier énormément.
Matt Dillon est entrain de développer une autre méthode pour
l'intégration de modules nsswitch qui permettrait de conserver /bin et
/sbin statiques ainsi qu'une méthode pour accélérer le chargement des
binaires liés dynamiquement.
Eric Masson
--
PR> tu es en avance d'un an pour le nouveau millénaire
il me semble que (2000) est bien le nouveau millenaire justement
par contre on change de siecle l'annee prochaine en 2001
-+- kiboot in http://www.le-gnu.net : Émile énerve pour l'an d'Émile.
Marwan> par contre, je ne sais pas ce que change le passage avec bin et Marwan> sbin en dynamique (quelle hérésie !) )
Pas grand chose, si tu pètes la babasse, il te reste /rescue qui est compilé en statique.
Le passage de /bin et /sbin en dynamique permet iirc, un méchant gain de place et une meilleure intégration de nsswitch et des modules existants sans avoir à les modifier énormément.
Matt Dillon est entrain de développer une autre méthode pour l'intégration de modules nsswitch qui permettrait de conserver /bin et /sbin statiques ainsi qu'une méthode pour accélérer le chargement des binaires liés dynamiquement.
Eric Masson
-- PR> tu es en avance d'un an pour le nouveau millénaire il me semble que (2000) est bien le nouveau millenaire justement par contre on change de siecle l'annee prochaine en 2001 -+- kiboot in http://www.le-gnu.net : Émile énerve pour l'an d'Émile.
talon
Patrick Lamaizière wrote:
(Michel Talon) écrivait :
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 ?
Comme je t'ai déjà dit, c'est pour ça qu'il faut rebooter single-user. Comme ça le seul programme de l'ancien monde qui tourne est /bin/sh. On peut espérer que les développeurs ont fait attention que /bin/sh continue de tourner. Si des fois il y avait une catastrophe on pourrait booter un cdrom de rescue et recopier un shell statique de la nouvelle génération pour faire l'install. Ce serait trés simple.
--
Michel TALON
Patrick Lamaizière <plamaiziere@alussinan.org> wrote:
talon@lpthe.jussieu.fr (Michel Talon) écrivait :
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 ?
Comme je t'ai déjà dit, c'est pour ça qu'il faut rebooter single-user.
Comme ça le seul programme de l'ancien monde qui tourne est /bin/sh.
On peut espérer que les développeurs ont fait attention que /bin/sh
continue de tourner. Si des fois il y avait une catastrophe on pourrait
booter un cdrom de rescue et recopier un shell statique de la nouvelle
génération pour faire l'install. Ce serait trés simple.
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 ?
Comme je t'ai déjà dit, c'est pour ça qu'il faut rebooter single-user. Comme ça le seul programme de l'ancien monde qui tourne est /bin/sh. On peut espérer que les développeurs ont fait attention que /bin/sh continue de tourner. Si des fois il y avait une catastrophe on pourrait booter un cdrom de rescue et recopier un shell statique de la nouvelle génération pour faire l'install. Ce serait trés simple.
--
Michel TALON
mips
On Tue, 27 Jan 2004 12:48:16 +0000 (UTC) (Michel Talon) wrote:
Comme je t'ai déjà dit, c'est pour ça qu'il faut rebooter single-user. Comme ça le seul programme de l'ancien monde qui tourne est /bin/sh. On peut espérer que les développeurs ont fait attention que /bin/sh continue de tourner. Si des fois il y avait une
Si sh n'est pas lie statiquement ca risque d'etre la fete a la maison :)
mips
On Tue, 27 Jan 2004 12:48:16 +0000 (UTC)
talon@lpthe.jussieu.fr (Michel Talon) wrote:
Comme je t'ai déjà dit, c'est pour ça qu'il faut rebooter
single-user. Comme ça le seul programme de l'ancien monde qui tourne
est /bin/sh. On peut espérer que les développeurs ont fait attention
que /bin/sh continue de tourner. Si des fois il y avait une
Si sh n'est pas lie statiquement ca risque d'etre la fete a la maison :)
On Tue, 27 Jan 2004 12:48:16 +0000 (UTC) (Michel Talon) wrote:
Comme je t'ai déjà dit, c'est pour ça qu'il faut rebooter single-user. Comme ça le seul programme de l'ancien monde qui tourne est /bin/sh. On peut espérer que les développeurs ont fait attention que /bin/sh continue de tourner. Si des fois il y avait une
Si sh n'est pas lie statiquement ca risque d'etre la fete a la maison :)
mips
pornin
According to Patrick Lamaizière :
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 ?
Il existe un concept qui s'appelle la "compatibilité ascendante". Ça veut dire qu'un logiciel récent peut tourner avec d'autres logiciels plus anciens parce que le logiciel récent sait parler les anciens dialectes au besoin.
Dans le cas du userland face au noyau, le dialecte, c'est l'ensemble des appels système (incluant les nombreux paramètres à rallonge des ioctl()).
Il s'avère qu'il est ultra-pénible de faire du userland faisant de la compatibilité ascendante par rapport au noyau, mais que l'autre sens est facile. En gros, un noyau récent continue de pouvoir faire tourner de vieilles applications. C'est de toutes façon vaguement indispensable pour le cas des applications "binaire seulement". Donc, il est hautement improbable qu'un noyau récent ne permette pas de faire au moins un boot en single-user et un "make installworld" avec un vieux world.
--Thomas Pornin
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.
PS2 : pourquoi est-il donc plus facile d'avoir un noyau backward-compatible (noyau qui fait tourner un userland plus ancien) que l'inverse (userland qui accepte de tourner avec un noyau plus ancien) ? C'est parce que l'évolution du dialecte se fait par ajout d'appels systèmes (et d'ioctl() spécifiques). Globalement le dialecte s'enrichit. Celui qui écoute (le noyau) est donc naturellement backward-compatible, puisqu'il continue de parler l'ancien dialecte aussi : c'est juste qu'il peut comprendre des appels système supplémentaires. Alors qu'un userland backward-compatible, ce serait un userland qui fait des appels systèmes récents mais est capable, si le noyau lui dit blah, de se passer de ces appels systèmes récents. Ça suppose plus de code côté utilisateur, et aussi on se demande pourquoi des appels système récents existeraient si les applications peuvent s'en passer. Donc, dans la pratique, le userland n'est pas backward-compatible avec les vieux noyaux (ou, s'il l'est, c'est par hasard).
PS3 : pour que les upgrades se passent bien, il n'y a pas besoin des deux sens de backward-compatibilité ; celle noyau->userland suffit _pourvu que tout le monde soit bien conscient qu'on fait le "make installworld" en ayant booté sur le nouveau noyau_.
According to Patrick Lamaizière <plamaiziere@alussinan.org>:
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 ?
Il existe un concept qui s'appelle la "compatibilité ascendante". Ça
veut dire qu'un logiciel récent peut tourner avec d'autres logiciels
plus anciens parce que le logiciel récent sait parler les anciens
dialectes au besoin.
Dans le cas du userland face au noyau, le dialecte, c'est l'ensemble
des appels système (incluant les nombreux paramètres à rallonge des
ioctl()).
Il s'avère qu'il est ultra-pénible de faire du userland faisant de la
compatibilité ascendante par rapport au noyau, mais que l'autre sens
est facile. En gros, un noyau récent continue de pouvoir faire tourner
de vieilles applications. C'est de toutes façon vaguement indispensable
pour le cas des applications "binaire seulement". Donc, il est hautement
improbable qu'un noyau récent ne permette pas de faire au moins un boot
en single-user et un "make installworld" avec un vieux world.
--Thomas Pornin
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.
PS2 : pourquoi est-il donc plus facile d'avoir un noyau
backward-compatible (noyau qui fait tourner un userland plus ancien) que
l'inverse (userland qui accepte de tourner avec un noyau plus ancien) ?
C'est parce que l'évolution du dialecte se fait par ajout d'appels
systèmes (et d'ioctl() spécifiques). Globalement le dialecte s'enrichit.
Celui qui écoute (le noyau) est donc naturellement backward-compatible,
puisqu'il continue de parler l'ancien dialecte aussi : c'est juste qu'il
peut comprendre des appels système supplémentaires. Alors qu'un userland
backward-compatible, ce serait un userland qui fait des appels systèmes
récents mais est capable, si le noyau lui dit blah, de se passer de ces
appels systèmes récents. Ça suppose plus de code côté utilisateur, et
aussi on se demande pourquoi des appels système récents existeraient si
les applications peuvent s'en passer. Donc, dans la pratique, le
userland n'est pas backward-compatible avec les vieux noyaux (ou, s'il
l'est, c'est par hasard).
PS3 : pour que les upgrades se passent bien, il n'y a pas besoin des
deux sens de backward-compatibilité ; celle noyau->userland suffit
_pourvu que tout le monde soit bien conscient qu'on fait le
"make installworld" en ayant booté sur le nouveau noyau_.
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 ?
Il existe un concept qui s'appelle la "compatibilité ascendante". Ça veut dire qu'un logiciel récent peut tourner avec d'autres logiciels plus anciens parce que le logiciel récent sait parler les anciens dialectes au besoin.
Dans le cas du userland face au noyau, le dialecte, c'est l'ensemble des appels système (incluant les nombreux paramètres à rallonge des ioctl()).
Il s'avère qu'il est ultra-pénible de faire du userland faisant de la compatibilité ascendante par rapport au noyau, mais que l'autre sens est facile. En gros, un noyau récent continue de pouvoir faire tourner de vieilles applications. C'est de toutes façon vaguement indispensable pour le cas des applications "binaire seulement". Donc, il est hautement improbable qu'un noyau récent ne permette pas de faire au moins un boot en single-user et un "make installworld" avec un vieux world.
--Thomas Pornin
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.
PS2 : pourquoi est-il donc plus facile d'avoir un noyau backward-compatible (noyau qui fait tourner un userland plus ancien) que l'inverse (userland qui accepte de tourner avec un noyau plus ancien) ? C'est parce que l'évolution du dialecte se fait par ajout d'appels systèmes (et d'ioctl() spécifiques). Globalement le dialecte s'enrichit. Celui qui écoute (le noyau) est donc naturellement backward-compatible, puisqu'il continue de parler l'ancien dialecte aussi : c'est juste qu'il peut comprendre des appels système supplémentaires. Alors qu'un userland backward-compatible, ce serait un userland qui fait des appels systèmes récents mais est capable, si le noyau lui dit blah, de se passer de ces appels systèmes récents. Ça suppose plus de code côté utilisateur, et aussi on se demande pourquoi des appels système récents existeraient si les applications peuvent s'en passer. Donc, dans la pratique, le userland n'est pas backward-compatible avec les vieux noyaux (ou, s'il l'est, c'est par hasard).
PS3 : pour que les upgrades se passent bien, il n'y a pas besoin des deux sens de backward-compatibilité ; celle noyau->userland suffit _pourvu que tout le monde soit bien conscient qu'on fait le "make installworld" en ayant booté sur le nouveau noyau_.
Patrick Lamaizière
(Thomas Pornin) écrivait :
PS3 : pour que les upgrades se passent bien, il n'y a pas besoin des deux sens de backward-compatibilité ; celle noyau->userland suffit _pourvu que tout le monde soit bien conscient qu'on fait le "make installworld" en ayant booté sur le nouveau noyau_.
Comme ça c'est plus clair, merci.
pornin@nerim.net (Thomas Pornin) écrivait :
PS3 : pour que les upgrades se passent bien, il n'y a pas besoin
des deux sens de backward-compatibilité ; celle noyau->userland
suffit _pourvu que tout le monde soit bien conscient qu'on fait le
"make installworld" en ayant booté sur le nouveau noyau_.
PS3 : pour que les upgrades se passent bien, il n'y a pas besoin des deux sens de backward-compatibilité ; celle noyau->userland suffit _pourvu que tout le monde soit bien conscient qu'on fait le "make installworld" en ayant booté sur le nouveau noyau_.
Comme ça c'est plus clair, merci.
talon
mips wrote:
On Tue, 27 Jan 2004 12:48:16 +0000 (UTC) (Michel Talon) wrote:
Comme je t'ai déjà dit, c'est pour ça qu'il faut rebooter single-user. Comme ça le seul programme de l'ancien monde qui tourne est /bin/sh. On peut espérer que les développeurs ont fait attention que /bin/sh continue de tourner. Si des fois il y avait une
Si sh n'est pas lie statiquement ca risque d'etre la fete a la maison :)
Ecoute, je l'ai fait pour le passage 5.1 -> 5.2 sans problème. Le sh était peut être encore statique. Dans le futur le shell statique sera dans /rescue, donc je suppose que le boot single user te fera tomber dans /rescue.
mips
--
Michel TALON
mips <anti@spam.gov> wrote:
On Tue, 27 Jan 2004 12:48:16 +0000 (UTC)
talon@lpthe.jussieu.fr (Michel Talon) wrote:
Comme je t'ai déjà dit, c'est pour ça qu'il faut rebooter
single-user. Comme ça le seul programme de l'ancien monde qui tourne
est /bin/sh. On peut espérer que les développeurs ont fait attention
que /bin/sh continue de tourner. Si des fois il y avait une
Si sh n'est pas lie statiquement ca risque d'etre la fete a la maison :)
Ecoute, je l'ai fait pour le passage 5.1 -> 5.2 sans problème. Le sh
était peut être encore statique. Dans le futur le shell statique sera
dans /rescue, donc je suppose que le boot single user te fera tomber
dans /rescue.
On Tue, 27 Jan 2004 12:48:16 +0000 (UTC) (Michel Talon) wrote:
Comme je t'ai déjà dit, c'est pour ça qu'il faut rebooter single-user. Comme ça le seul programme de l'ancien monde qui tourne est /bin/sh. On peut espérer que les développeurs ont fait attention que /bin/sh continue de tourner. Si des fois il y avait une
Si sh n'est pas lie statiquement ca risque d'etre la fete a la maison :)
Ecoute, je l'ai fait pour le passage 5.1 -> 5.2 sans problème. Le sh était peut être encore statique. Dans le futur le shell statique sera dans /rescue, donc je suppose que le boot single user te fera tomber dans /rescue.
mips
--
Michel TALON
David MAREC
Bonjour,
dixitque Thomas Pornin :
fiat lux¹
Il existe un concept qui s'appelle la "compatibilité ascendante". [snip]
et facta est lux.
J'ai (enfin) compris quelque chose dans ce fil.
Enfin, je suppose et j'espère que si un jour, un nouveau noyau est incompatible avec l'«ancien monde»² en "single", nous serions prévenu à grand coups de clairons.
¹ : "oh, la belle voiture !" (P.Desproges) ² : S'il existe un terme plus approprié...
Bonjour,
dixitque Thomas Pornin :
fiat lux¹
Il existe un concept qui s'appelle la "compatibilité ascendante".
[snip]
et facta est lux.
J'ai (enfin) compris quelque chose dans ce fil.
Enfin, je suppose et j'espère que si un jour, un nouveau noyau est
incompatible avec l'«ancien monde»² en "single", nous serions prévenu à
grand coups de clairons.
¹ : "oh, la belle voiture !" (P.Desproges)
² : S'il existe un terme plus approprié...
Il existe un concept qui s'appelle la "compatibilité ascendante". [snip]
et facta est lux.
J'ai (enfin) compris quelque chose dans ce fil.
Enfin, je suppose et j'espère que si un jour, un nouveau noyau est incompatible avec l'«ancien monde»² en "single", nous serions prévenu à grand coups de clairons.
¹ : "oh, la belle voiture !" (P.Desproges) ² : S'il existe un terme plus approprié...
Marwan Burelle
On Tue, 27 Jan 2004 14:54:37 +0100 David MAREC wrote:
Enfin, je suppose et j'espère que si un jour, un nouveau noyau est incompatible avec l'«ancien monde»² en "single", nous serions prévenu à grand coups de clairons.
C'est pour ça qu'il faut _toujours_ lire src/UPDATING ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On Tue, 27 Jan 2004 14:54:37 +0100
David MAREC <dmarec.spam@free.invalid> wrote:
Enfin, je suppose et j'espère que si un jour, un nouveau noyau est
incompatible avec l'«ancien monde»² en "single", nous serions prévenu
à grand coups de clairons.
C'est pour ça qu'il faut _toujours_ lire src/UPDATING ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
On Tue, 27 Jan 2004 14:54:37 +0100 David MAREC wrote:
Enfin, je suppose et j'espère que si un jour, un nouveau noyau est incompatible avec l'«ancien monde»² en "single", nous serions prévenu à grand coups de clairons.
C'est pour ça qu'il faut _toujours_ lire src/UPDATING ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
talon
Patrick Lamaizière wrote:
(Thomas Pornin) écrivait :
PS3 : pour que les upgrades se passent bien, il n'y a pas besoin des deux sens de backward-compatibilité ; celle noyau->userland suffit _pourvu que tout le monde soit bien conscient qu'on fait le "make installworld" en ayant booté sur le nouveau noyau_.
Comme ça c'est plus clair, merci.
Il n'y a certainement pas compatibilité complète et parfaite noyau -> userland comme tu le dis. Il m'est arrivé de rebooter avec le nouveau noyau, d'oublier le flag single user et de me retrouver face à une panique. Donc il s'agit bien seulement de la compatibilité minimale suffisante pour booter single user et faire le make installworld.
--
Michel TALON
Patrick Lamaizière <plamaiziere@alussinan.org> wrote:
pornin@nerim.net (Thomas Pornin) écrivait :
PS3 : pour que les upgrades se passent bien, il n'y a pas besoin
des deux sens de backward-compatibilité ; celle noyau->userland
suffit _pourvu que tout le monde soit bien conscient qu'on fait le
"make installworld" en ayant booté sur le nouveau noyau_.
Comme ça c'est plus clair, merci.
Il n'y a certainement pas compatibilité complète et parfaite
noyau -> userland comme tu le dis. Il m'est arrivé de rebooter
avec le nouveau noyau, d'oublier le flag single user et de me retrouver
face à une panique. Donc il s'agit bien seulement de la compatibilité
minimale suffisante pour booter single user et faire le make
installworld.
PS3 : pour que les upgrades se passent bien, il n'y a pas besoin des deux sens de backward-compatibilité ; celle noyau->userland suffit _pourvu que tout le monde soit bien conscient qu'on fait le "make installworld" en ayant booté sur le nouveau noyau_.
Comme ça c'est plus clair, merci.
Il n'y a certainement pas compatibilité complète et parfaite noyau -> userland comme tu le dis. Il m'est arrivé de rebooter avec le nouveau noyau, d'oublier le flag single user et de me retrouver face à une panique. Donc il s'agit bien seulement de la compatibilité minimale suffisante pour booter single user et faire le make installworld.
--
Michel TALON
talon
David MAREC wrote:
Enfin, je suppose et j'espère que si un jour, un nouveau noyau est incompatible avec l'«ancien monde»² en "single", nous serions prévenu à grand coups de clairons.
Tu pourrais réparer le problème avec un CD de rescue, facilement.
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.
--
Michel TALON
David MAREC <dmarec.spam@free.invalid> wrote:
Enfin, je suppose et j'espère que si un jour, un nouveau noyau est
incompatible avec l'«ancien monde»² en "single", nous serions prévenu à
grand coups de clairons.
Tu pourrais réparer le problème avec un CD de rescue, facilement.
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.
Enfin, je suppose et j'espère que si un jour, un nouveau noyau est incompatible avec l'«ancien monde»² en "single", nous serions prévenu à grand coups de clairons.
Tu pourrais réparer le problème avec un CD de rescue, facilement.
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.
