Bonjour, je viens de me faire avoir avec le très connu "touch: not
found" lors de make installworld
> ===> include (install)
> creating osreldate.h from newvers.sh
> touch: not found
> *** Error code 127
C'est un upgrade de 5-STABLE vers 6-STABLE (j'en ai fait plusieurs
récemment sans problème)
J'ai pourtant pris toutes mes pilules contre les boucs :
- reboot en single sur le noveau noyau
- vérification de la date
- adjkerntz -i
- vérification de la date
- gouguelisation, où la réponse est "Check the date, Luke"
- vérification de la date
Rien n'y fait. Pas d'autre piste dans Google. La machine tourne pour
l'instant avec un monde 5-STABLE et un noyau 6-STABLE, sans trop de
soucis, mais j'aime pô.
Hein! Sauf si /tmp est un système de fichiers en mémoire, je crois que c'est surtout utile pour /tmp.
L'objectif des soft-updates étant de garantir la cohérence du fs en cas de plantage, on s'en tape totalement dans le cas de /tmp, puisqu'on peut le détruire au boot suivant.
A moins que tu n'y vois comme avantage l'inconvénient que lui prète généralement : comme les écritures ne sont pas effectuées immédiatement, les fichiers temporaires qui ont une durée de vie courte ne seront jamais écrit sur le disque.
Si c'est ça l'avantage, vaut mieux effectivement mettre le fs en mémoire.
-- CN > J'ai enseigné l'algorythmique. GLG> C'est quoi l'algorythmique ? Une contrebasse programmée en Algol ? -+- in : <http://www.le-gnu.net> - Neuneu fait ses gammes. -+-
[soft-updates pour /tmp]
Hein! Sauf si /tmp est un système de fichiers en mémoire, je crois que c'est
surtout utile pour /tmp.
L'objectif des soft-updates étant de garantir la cohérence du fs en
cas de plantage, on s'en tape totalement dans le cas de /tmp,
puisqu'on peut le détruire au boot suivant.
A moins que tu n'y vois comme avantage l'inconvénient que lui prète
généralement : comme les écritures ne sont pas effectuées
immédiatement, les fichiers temporaires qui ont une durée de vie
courte ne seront jamais écrit sur le disque.
Si c'est ça l'avantage, vaut mieux effectivement mettre le fs en
mémoire.
--
CN > J'ai enseigné l'algorythmique.
GLG> C'est quoi l'algorythmique ? Une contrebasse programmée en Algol ?
-+- in : <http://www.le-gnu.net> - Neuneu fait ses gammes. -+-
Hein! Sauf si /tmp est un système de fichiers en mémoire, je crois que c'est surtout utile pour /tmp.
L'objectif des soft-updates étant de garantir la cohérence du fs en cas de plantage, on s'en tape totalement dans le cas de /tmp, puisqu'on peut le détruire au boot suivant.
A moins que tu n'y vois comme avantage l'inconvénient que lui prète généralement : comme les écritures ne sont pas effectuées immédiatement, les fichiers temporaires qui ont une durée de vie courte ne seront jamais écrit sur le disque.
Si c'est ça l'avantage, vaut mieux effectivement mettre le fs en mémoire.
-- CN > J'ai enseigné l'algorythmique. GLG> C'est quoi l'algorythmique ? Une contrebasse programmée en Algol ? -+- in : <http://www.le-gnu.net> - Neuneu fait ses gammes. -+-
TeXitoi
Stephane Dupille writes:
[soft-updates pour /tmp]
Hein! Sauf si /tmp est un système de fichiers en mémoire, je crois que c'est surtout utile pour /tmp.
L'objectif des soft-updates étant de garantir la cohérence du fs en cas de plantage, on s'en tape totalement dans le cas de /tmp, puisqu'on peut le détruire au boot suivant.
A moins que tu n'y vois comme avantage l'inconvénient que lui prète généralement : comme les écritures ne sont pas effectuées immédiatement, les fichiers temporaires qui ont une durée de vie courte ne seront jamais écrit sur le disque.
Y'a pas aussi l'avantage de meilleurs performances ?
Hein! Sauf si /tmp est un système de fichiers en mémoire, je crois
que c'est surtout utile pour /tmp.
L'objectif des soft-updates étant de garantir la cohérence du fs en
cas de plantage, on s'en tape totalement dans le cas de /tmp,
puisqu'on peut le détruire au boot suivant.
A moins que tu n'y vois comme avantage l'inconvénient que lui prète
généralement : comme les écritures ne sont pas effectuées
immédiatement, les fichiers temporaires qui ont une durée de vie
courte ne seront jamais écrit sur le disque.
Y'a pas aussi l'avantage de meilleurs performances ?
Hein! Sauf si /tmp est un système de fichiers en mémoire, je crois que c'est surtout utile pour /tmp.
L'objectif des soft-updates étant de garantir la cohérence du fs en cas de plantage, on s'en tape totalement dans le cas de /tmp, puisqu'on peut le détruire au boot suivant.
A moins que tu n'y vois comme avantage l'inconvénient que lui prète généralement : comme les écritures ne sont pas effectuées immédiatement, les fichiers temporaires qui ont une durée de vie courte ne seront jamais écrit sur le disque.
Y'a pas aussi l'avantage de meilleurs performances ?
``Software is like sex: it's better when it's free.'' -- Linus Torvalds
() Campagne du ruban ascii -- contre les mails en html / Contre les pièces jointes Microsoft
talon
Stephane Dupille wrote:
A moins que tu n'y vois comme avantage l'inconvénient que lui prète généralement : comme les écritures ne sont pas effectuées immédiatement, les fichiers temporaires qui ont une durée de vie courte ne seront jamais écrit sur le disque.
Si c'est ça l'avantage, vaut mieux effectivement mettre le fs en mémoire.
Oui c'est ça l'avantage que j'y vois. Softupdates augmente les performances sur un système de fichiers où il y a beaucoup de créations et de destructions de fichiers. Je ne suis pas absolument certain que mettre le système de fichiers totalement en mémoire fasse gagner grand chose de plus. Quand je l'avais essayé, il y a longtemps, je n'avais pas vu de différence significative. Le gain le plus important vient tout de suite avec softupdates. En ce qui concerne les garanties de sécurité qu'apporte softupdates, je n'y crois que trés modérément, ayant déjà observé qu'elles n'étaient manifestement pas satisfaites sur un certain nombre de mes cas particuliers. Elles sont invalidées par le cache du disque, et par des bugs éventuels (et on en trouve encore).
A moins que tu n'y vois comme avantage l'inconvénient que lui prète
généralement : comme les écritures ne sont pas effectuées
immédiatement, les fichiers temporaires qui ont une durée de vie
courte ne seront jamais écrit sur le disque.
Si c'est ça l'avantage, vaut mieux effectivement mettre le fs en
mémoire.
Oui c'est ça l'avantage que j'y vois. Softupdates augmente les performances
sur un système de fichiers où il y a beaucoup de créations et de destructions
de fichiers. Je ne suis pas absolument certain que mettre le système de
fichiers totalement en mémoire fasse gagner grand chose de plus. Quand
je l'avais essayé, il y a longtemps, je n'avais pas vu de différence
significative. Le gain le plus important vient tout de suite avec softupdates.
En ce qui concerne les garanties de sécurité qu'apporte softupdates, je n'y
crois que trés modérément, ayant déjà observé qu'elles n'étaient manifestement
pas satisfaites sur un certain nombre de mes cas particuliers. Elles sont
invalidées par le cache du disque, et par des bugs éventuels (et on en trouve
encore).
A moins que tu n'y vois comme avantage l'inconvénient que lui prète généralement : comme les écritures ne sont pas effectuées immédiatement, les fichiers temporaires qui ont une durée de vie courte ne seront jamais écrit sur le disque.
Si c'est ça l'avantage, vaut mieux effectivement mettre le fs en mémoire.
Oui c'est ça l'avantage que j'y vois. Softupdates augmente les performances sur un système de fichiers où il y a beaucoup de créations et de destructions de fichiers. Je ne suis pas absolument certain que mettre le système de fichiers totalement en mémoire fasse gagner grand chose de plus. Quand je l'avais essayé, il y a longtemps, je n'avais pas vu de différence significative. Le gain le plus important vient tout de suite avec softupdates. En ce qui concerne les garanties de sécurité qu'apporte softupdates, je n'y crois que trés modérément, ayant déjà observé qu'elles n'étaient manifestement pas satisfaites sur un certain nombre de mes cas particuliers. Elles sont invalidées par le cache du disque, et par des bugs éventuels (et on en trouve encore).
--
Michel TALON
Stephane Dupille
Oui c'est ça l'avantage que j'y vois. Softupdates augmente les performances sur un système de fichiers où il y a beaucoup de créations et de destructions de fichiers. Je ne suis pas absolument certain que mettre le système de fichiers totalement en mémoire fasse gagner grand chose de plus.
Tout dépend de la durée pendant laquelle le fichier va rester. Dans un cas, on est certain qu'il va rester en mémoire, dans l'autre, cela est seulement probable.
Ca ne répond pas forcément aux mêmes besoins. Le fs en mémoire est bien s'il reste petit, dans l'autre si les fichiers ne restent pas longtemps.
Quand je l'avais essayé, il y a longtemps, je n'avais pas vu de différence significative. Le gain le plus important vient tout de suite avec softupdates.
Je n'ai pas essayé les softupdates sur /tmp, je l'ai directement foutu en mémoire. Mais d'une part j'ai plus de mémoire qu'il ne m'en faut, et d'autre part mon besoin dans /tmp est anecdotique. Mileage may vary.
En ce qui concerne les garanties de sécurité qu'apporte softupdates, je n'y crois que trés modérément, ayant déjà observé qu'elles n'étaient manifestement pas satisfaites sur un certain nombre de mes cas particuliers. Elles sont invalidées par le cache du disque, et par des bugs éventuels (et on en trouve encore).
Les soft-updates c'est très beau, c'est très intelligent, c'est magnifique dans le principe, mais en pratique, ça vaut pas la journalisation.
-- je hais 1/ les assistantes sociales, 2/ les ivrognes, 3/ les sales cons en uniforme et 4/ tout ce qui ressemble à un humain de base. Et je suis armé. Bonne nuit, -+- Or in <http://www.le-gnu.net> - Nuit de Chine, nuit caline -+-
Oui c'est ça l'avantage que j'y vois. Softupdates augmente les performances
sur un système de fichiers où il y a beaucoup de créations et de destructions
de fichiers. Je ne suis pas absolument certain que mettre le système de
fichiers totalement en mémoire fasse gagner grand chose de plus.
Tout dépend de la durée pendant laquelle le fichier va rester. Dans
un cas, on est certain qu'il va rester en mémoire, dans l'autre, cela
est seulement probable.
Ca ne répond pas forcément aux mêmes besoins. Le fs en mémoire est
bien s'il reste petit, dans l'autre si les fichiers ne restent pas
longtemps.
Quand je l'avais essayé, il y a longtemps, je n'avais pas vu de
différence significative. Le gain le plus important vient tout de
suite avec softupdates.
Je n'ai pas essayé les softupdates sur /tmp, je l'ai directement
foutu en mémoire. Mais d'une part j'ai plus de mémoire qu'il ne m'en
faut, et d'autre part mon besoin dans /tmp est anecdotique. Mileage
may vary.
En ce qui concerne les garanties de sécurité qu'apporte softupdates,
je n'y crois que trés modérément, ayant déjà observé qu'elles
n'étaient manifestement pas satisfaites sur un certain nombre de mes
cas particuliers. Elles sont invalidées par le cache du disque, et
par des bugs éventuels (et on en trouve encore).
Les soft-updates c'est très beau, c'est très intelligent, c'est
magnifique dans le principe, mais en pratique, ça vaut pas la
journalisation.
--
je hais 1/ les assistantes sociales, 2/ les ivrognes, 3/ les sales
cons en uniforme et 4/ tout ce qui ressemble à un humain de base.
Et je suis armé. Bonne nuit,
-+- Or in <http://www.le-gnu.net> - Nuit de Chine, nuit caline -+-
Oui c'est ça l'avantage que j'y vois. Softupdates augmente les performances sur un système de fichiers où il y a beaucoup de créations et de destructions de fichiers. Je ne suis pas absolument certain que mettre le système de fichiers totalement en mémoire fasse gagner grand chose de plus.
Tout dépend de la durée pendant laquelle le fichier va rester. Dans un cas, on est certain qu'il va rester en mémoire, dans l'autre, cela est seulement probable.
Ca ne répond pas forcément aux mêmes besoins. Le fs en mémoire est bien s'il reste petit, dans l'autre si les fichiers ne restent pas longtemps.
Quand je l'avais essayé, il y a longtemps, je n'avais pas vu de différence significative. Le gain le plus important vient tout de suite avec softupdates.
Je n'ai pas essayé les softupdates sur /tmp, je l'ai directement foutu en mémoire. Mais d'une part j'ai plus de mémoire qu'il ne m'en faut, et d'autre part mon besoin dans /tmp est anecdotique. Mileage may vary.
En ce qui concerne les garanties de sécurité qu'apporte softupdates, je n'y crois que trés modérément, ayant déjà observé qu'elles n'étaient manifestement pas satisfaites sur un certain nombre de mes cas particuliers. Elles sont invalidées par le cache du disque, et par des bugs éventuels (et on en trouve encore).
Les soft-updates c'est très beau, c'est très intelligent, c'est magnifique dans le principe, mais en pratique, ça vaut pas la journalisation.
-- je hais 1/ les assistantes sociales, 2/ les ivrognes, 3/ les sales cons en uniforme et 4/ tout ce qui ressemble à un humain de base. Et je suis armé. Bonne nuit, -+- Or in <http://www.le-gnu.net> - Nuit de Chine, nuit caline -+-
talon
Stephane Dupille wrote:
Les soft-updates c'est très beau, c'est très intelligent, c'est magnifique dans le principe, mais en pratique, ça vaut pas la journalisation.
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
Les soft-updates c'est très beau, c'est très intelligent, c'est
magnifique dans le principe, mais en pratique, ça vaut pas la
journalisation.
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la
maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec
Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
Les soft-updates c'est très beau, c'est très intelligent, c'est magnifique dans le principe, mais en pratique, ça vaut pas la journalisation.
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
--
Michel TALON
Stephane Dupille
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
C'est bien la plus mauvaise excuse que j'ai vue pour rebooter une machine. Malproprement en plus !
(je suis déjà sorti).
-- Il n'est pas question de modération !!! Les gens ont à se prononcer sur les caractéristiques d'une robot-modération -+- BC in Guide du Neuneu Usenet - C'est robot pour être vrai -+-
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la
maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec
Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
C'est bien la plus mauvaise excuse que j'ai vue pour rebooter une
machine. Malproprement en plus !
(je suis déjà sorti).
--
Il n'est pas question de modération !!!
Les gens ont à se prononcer sur les caractéristiques d'une
robot-modération
-+- BC in Guide du Neuneu Usenet - C'est robot pour être vrai -+-
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
C'est bien la plus mauvaise excuse que j'ai vue pour rebooter une machine. Malproprement en plus !
(je suis déjà sorti).
-- Il n'est pas question de modération !!! Les gens ont à se prononcer sur les caractéristiques d'une robot-modération -+- BC in Guide du Neuneu Usenet - C'est robot pour être vrai -+-
Stephane Dupille
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
Mileage may vary, encore une fois. Les rares fois où j'ai éteint ma machine salement, sans démonter les disques ni rien, il a redémarré comme une fleur, sans le moindre soucis.
Mais je n'ai qu'un 4.10, et (je n'ai pas suivi mais) il ne me semble pas que je dispose du fsck en tache de fond qui, à ce que j'ai entendu, est assez rigolo.
--
Que puis-je faire d'un spam avec 750 Ko de pièces jointes, outre déposer plainte à ce qui a été fait. Là il y a notoirement abus sans que pour autant le B.I. soit dépassé.
-+- LCA in : Guide du Neuneu Usenetien - Le neuneu, c'est dépassé -+-
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la
maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec
Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
Mileage may vary, encore une fois. Les rares fois où j'ai éteint ma
machine salement, sans démonter les disques ni rien, il a redémarré
comme une fleur, sans le moindre soucis.
Mais je n'ai qu'un 4.10, et (je n'ai pas suivi mais) il ne me semble
pas que je dispose du fsck en tache de fond qui, à ce que j'ai
entendu, est assez rigolo.
--
Que puis-je faire d'un spam avec 750 Ko de pièces jointes, outre
déposer plainte à abuse@club-internet.fr ce qui a été fait.
Là il y a notoirement abus sans que pour autant le B.I. soit dépassé.
-+- LCA in : Guide du Neuneu Usenetien - Le neuneu, c'est dépassé -+-
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
Mileage may vary, encore une fois. Les rares fois où j'ai éteint ma machine salement, sans démonter les disques ni rien, il a redémarré comme une fleur, sans le moindre soucis.
Mais je n'ai qu'un 4.10, et (je n'ai pas suivi mais) il ne me semble pas que je dispose du fsck en tache de fond qui, à ce que j'ai entendu, est assez rigolo.
--
Que puis-je faire d'un spam avec 750 Ko de pièces jointes, outre déposer plainte à ce qui a été fait. Là il y a notoirement abus sans que pour autant le B.I. soit dépassé.
-+- LCA in : Guide du Neuneu Usenetien - Le neuneu, c'est dépassé -+-
talon
Stephane Dupille wrote:
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
C'est bien la plus mauvaise excuse que j'ai vue pour rebooter une machine. Malproprement en plus !
Comment excuse! la machine se bloque et ne répond plus à rien au clavier. Une fois j'ai essayé de la rebooter par le réseau, qui était accessible, mais elle n'a pas réussi à compléter le cycle de reboot, si bien que je n'ai rien gagné. C'est un problème connu, je ne suis pas le seul: ATI Radeon 9200SE + carte mère avec chipset VIA + DRI aussi bien sous Linux que FreeBSD.
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la
maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec
Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
C'est bien la plus mauvaise excuse que j'ai vue pour rebooter une
machine. Malproprement en plus !
Comment excuse! la machine se bloque et ne répond plus à rien au clavier.
Une fois j'ai essayé de la rebooter par le réseau, qui était accessible, mais
elle n'a pas réussi à compléter le cycle de reboot, si bien que je n'ai rien
gagné. C'est un problème connu, je ne suis pas le seul:
ATI Radeon 9200SE + carte mère avec chipset VIA + DRI
aussi bien sous Linux que FreeBSD.
Bien d'accord avec toi. J'ai des problèmes de video avec ma machine à la maison qui m'ont amené à appuyer fréquemment sur le bouton reset. Avec Linux+Reiserfs, c'est instantané, avec FreeBSD c'est la merde.
C'est bien la plus mauvaise excuse que j'ai vue pour rebooter une machine. Malproprement en plus !
Comment excuse! la machine se bloque et ne répond plus à rien au clavier. Une fois j'ai essayé de la rebooter par le réseau, qui était accessible, mais elle n'a pas réussi à compléter le cycle de reboot, si bien que je n'ai rien gagné. C'est un problème connu, je ne suis pas le seul: ATI Radeon 9200SE + carte mère avec chipset VIA + DRI aussi bien sous Linux que FreeBSD.
(je suis déjà sorti).
--
Michel TALON
talon
Stephane Dupille wrote:
Mais je n'ai qu'un 4.10, et (je n'ai pas suivi mais) il ne me semble pas que je dispose du fsck en tache de fond qui, à ce que j'ai entendu, est assez rigolo.
Moi j'ai tout mon système sur une seule partition /, car je n'ai pas de place à perdre, et de toute façon il fait un fsck en direct sur la partition / si bien qu'il faut attendre 5 minutes au redémarrage. Sur une dizaine de tels reboots, je me suis retrouvé 2 fois avec des fichiers dans lost+found, ce qui ne devrait *jamais* arriver si softupdates marchait selon la théorie.
Mais je n'ai qu'un 4.10, et (je n'ai pas suivi mais) il ne me semble
pas que je dispose du fsck en tache de fond qui, à ce que j'ai
entendu, est assez rigolo.
Moi j'ai tout mon système sur une seule partition /, car je n'ai pas de place
à perdre, et de toute façon il fait un fsck en direct sur la partition / si
bien qu'il faut attendre 5 minutes au redémarrage. Sur une dizaine de tels
reboots, je me suis retrouvé 2 fois avec des fichiers dans lost+found, ce
qui ne devrait *jamais* arriver si softupdates marchait selon la théorie.
Mais je n'ai qu'un 4.10, et (je n'ai pas suivi mais) il ne me semble pas que je dispose du fsck en tache de fond qui, à ce que j'ai entendu, est assez rigolo.
Moi j'ai tout mon système sur une seule partition /, car je n'ai pas de place à perdre, et de toute façon il fait un fsck en direct sur la partition / si bien qu'il faut attendre 5 minutes au redémarrage. Sur une dizaine de tels reboots, je me suis retrouvé 2 fois avec des fichiers dans lost+found, ce qui ne devrait *jamais* arriver si softupdates marchait selon la théorie.
Thierry Thomas
Jeudi 08 décembre 2005 à 10:10 GMT, Stephane Dupille a écrit :
Si c'est ça l'avantage, vaut mieux effectivement mettre le fs en mémoire.
Pour de meilleures performances, l'idéal c'est encore de mettre le swap sur un md. -- Th. Thomas. Snhg cnf pebver gbhg pr dh'ba yvg fhe Hfrarg !
Jeudi 08 décembre 2005 à 10:10 GMT, Stephane Dupille a écrit :
Si c'est ça l'avantage, vaut mieux effectivement mettre le fs en
mémoire.
Pour de meilleures performances, l'idéal c'est encore de mettre le swap
sur un md.
--
Th. Thomas.
Snhg cnf pebver gbhg pr dh'ba yvg fhe Hfrarg !
