après un redmarage brutal de la machine (un malheureux coup de genoux
sur le bouton shutdown), j'ai perdu le son (mandrake 9.2 mise à jour et
sblive1024)
donc, si j'ai bien compris ca devrait être lancé (je suis en runlevel 5)
[root@pc-00065 root]# fuser -v /dev/dsp
/dev/dsp: No such file or directory
je lis la doc, je tente un insmod snd-emu10k1:
insmod snd-emu10k1
Using /lib/modules/2.4.22-10mdk/kernel/sound/pci/emu10k1/snd-emu10k1.o.gz
/lib/modules/2.4.22-10mdk/kernel/sound/pci/emu10k1/snd-emu10k1.o.gz:
unresolved symbol snd_pcm_hw_constraint_integer_R1b974a2f
/lib/modules/2.4.22-10mdk/kernel/sound/pci/emu10k1/snd-emu10k1.o.gz:
unresolved symbol snd_card_register_R569e4c1c
... et plein de lignes semblables
bref y'a une couille dans le potage. Laquelle ? et comment y rémédier ?
de la même façon, ma connexion réseau ne s'effectue plus
automatiquement. Il me faut aller dans drakconf et recréer une nouvelle
connexion pour que ça passe.
Un peu (beaucoup) d'aide serait bienvenue. Je précise que je suis un
amateur éclairé de linux donc, pas trop de termes barbares svp.
euh, je ne l'ai pas vraiment compris. Reparamétrer la config avec l'assistant Mandrake ne permet pas de choisir la connexion automatique au démarrage ?
ma carte utilise le module tulip. Comme dois-je renseigner module.conf ? alias tulip suffira t'il ?
je ne pense pas qu'il s'agisse d'un chargement de module.
Gérard Patel
On Wed, 04 Feb 2004 12:09:14 +0100, toufou
<mathieu.betton.pasdespam@free.fr> wrote:
Reste le pb de mon réseau
euh, je ne l'ai pas vraiment compris. Reparamétrer la
config avec l'assistant Mandrake ne permet pas de choisir
la connexion automatique au démarrage ?
ma carte utilise le module tulip. Comme dois-je renseigner module.conf ?
alias tulip suffira t'il ?
je ne pense pas qu'il s'agisse d'un chargement de module.
euh, je ne l'ai pas vraiment compris. Reparamétrer la config avec l'assistant Mandrake ne permet pas de choisir la connexion automatique au démarrage ?
ma carte utilise le module tulip. Comme dois-je renseigner module.conf ? alias tulip suffira t'il ?
je ne pense pas qu'il s'agisse d'un chargement de module.
Gérard Patel
g.patel
On Wed, 04 Feb 2004 04:28:51 +0100, no_spam wrote:
(...)
Notement, il doit garantir que ce genre de situation n'arrive jamais: un fichier peut être dans un état antérieur à celui attendu, mais jamais disparaitre, même en cours de modification.
Scénario : un programme veut modifier un fichier de configuration; il le charge en mémoire, efface le fichier sur disque et le recrée à partir de l'image en mémoire. Meme avec toute la journalisation du monde, dans ce genre de cas de figure le fichier peut disparaitre si on coupe le secteur au moment crucial.
Gérard Patel
On Wed, 04 Feb 2004 04:28:51 +0100, no_spam
<l_indien_no_more_spams@magic.fr> wrote:
(...)
Notement, il doit garantir que ce genre de situation n'arrive jamais:
un fichier peut être dans un état antérieur à celui attendu, mais
jamais disparaitre, même en cours de modification.
Scénario : un programme veut modifier un fichier de
configuration; il le charge en mémoire, efface le fichier
sur disque et le recrée à partir de l'image en mémoire.
Meme avec toute la journalisation du monde, dans ce
genre de cas de figure le fichier peut disparaitre si
on coupe le secteur au moment crucial.
On Wed, 04 Feb 2004 04:28:51 +0100, no_spam wrote:
(...)
Notement, il doit garantir que ce genre de situation n'arrive jamais: un fichier peut être dans un état antérieur à celui attendu, mais jamais disparaitre, même en cours de modification.
Scénario : un programme veut modifier un fichier de configuration; il le charge en mémoire, efface le fichier sur disque et le recrée à partir de l'image en mémoire. Meme avec toute la journalisation du monde, dans ce genre de cas de figure le fichier peut disparaitre si on coupe le secteur au moment crucial.
Gérard Patel
no_spam
On Wed, 04 Feb 2004 21:49:59 +0000, gerard patel wrote:
On Wed, 04 Feb 2004 04:28:51 +0100, no_spam wrote:
(...)
Notement, il doit garantir que ce genre de situation n'arrive jamais: un fichier peut être dans un état antérieur à celui attendu, mais jamais disparaitre, même en cours de modification.
Scénario : un programme veut modifier un fichier de configuration; il le charge en mémoire, efface le fichier sur disque et le recrée à partir de l'image en mémoire. Meme avec toute la journalisation du monde, dans ce genre de cas de figure le fichier peut disparaitre si on coupe le secteur au moment crucial.
Je parle de disparition en cours de modification (cf modifications "atomiques") et toi de tout autre chose... Tu remarqueras que, quelle que soit la technologie employée, ce qui est en RAM disparait quand tu coupes le courant. Ca n'a aucun rapport avec le filesystem employé sur le disque. Dans l'exemple que tu cites, le problème est du à un programme qui se comporte de façon stupide. Effectivement, les filesystem ne comportent pas de protection, ni contre la stupidité, ni contre les bugs... Quoique: sur un filesystem versionné, ton exemple ne pose aucun problème: il suffit de reprendre la dernière version du fichier avant effacement...
On Wed, 04 Feb 2004 21:49:59 +0000, gerard patel wrote:
On Wed, 04 Feb 2004 04:28:51 +0100, no_spam
<l_indien_no_more_spams@magic.fr> wrote:
(...)
Notement, il doit garantir que ce genre de situation n'arrive jamais:
un fichier peut être dans un état antérieur à celui attendu, mais
jamais disparaitre, même en cours de modification.
Scénario : un programme veut modifier un fichier de
configuration; il le charge en mémoire, efface le fichier
sur disque et le recrée à partir de l'image en mémoire.
Meme avec toute la journalisation du monde, dans ce
genre de cas de figure le fichier peut disparaitre si
on coupe le secteur au moment crucial.
Je parle de disparition en cours de modification (cf modifications
"atomiques") et toi de tout autre chose...
Tu remarqueras que, quelle que soit la technologie employée,
ce qui est en RAM disparait quand tu coupes le courant.
Ca n'a aucun rapport avec le filesystem employé sur le disque.
Dans l'exemple que tu cites, le problème est du à un programme
qui se comporte de façon stupide. Effectivement, les filesystem
ne comportent pas de protection, ni contre la stupidité, ni contre
les bugs...
Quoique: sur un filesystem versionné, ton exemple ne pose aucun
problème: il suffit de reprendre la dernière version du fichier
avant effacement...
On Wed, 04 Feb 2004 21:49:59 +0000, gerard patel wrote:
On Wed, 04 Feb 2004 04:28:51 +0100, no_spam wrote:
(...)
Notement, il doit garantir que ce genre de situation n'arrive jamais: un fichier peut être dans un état antérieur à celui attendu, mais jamais disparaitre, même en cours de modification.
Scénario : un programme veut modifier un fichier de configuration; il le charge en mémoire, efface le fichier sur disque et le recrée à partir de l'image en mémoire. Meme avec toute la journalisation du monde, dans ce genre de cas de figure le fichier peut disparaitre si on coupe le secteur au moment crucial.
Je parle de disparition en cours de modification (cf modifications "atomiques") et toi de tout autre chose... Tu remarqueras que, quelle que soit la technologie employée, ce qui est en RAM disparait quand tu coupes le courant. Ca n'a aucun rapport avec le filesystem employé sur le disque. Dans l'exemple que tu cites, le problème est du à un programme qui se comporte de façon stupide. Effectivement, les filesystem ne comportent pas de protection, ni contre la stupidité, ni contre les bugs... Quoique: sur un filesystem versionné, ton exemple ne pose aucun problème: il suffit de reprendre la dernière version du fichier avant effacement...
g.patel
On Thu, 05 Feb 2004 01:10:26 +0100, no_spam wrote:
(...)
Dans l'exemple que tu cites, le problème est du à un programme qui se comporte de façon stupide. Effectivement, les filesystem ne comportent pas de protection, ni contre la stupidité, ni contre les bugs...
Ni contre les pannes matérielles. La journalisation n'est absolument pas une garantie de système qui fonctionne bien sans perte d'information.
Gérard Patel
On Thu, 05 Feb 2004 01:10:26 +0100, no_spam
<l_indien_no_more_spams@magic.fr> wrote:
(...)
Dans l'exemple que tu cites, le problème est du à un programme
qui se comporte de façon stupide. Effectivement, les filesystem
ne comportent pas de protection, ni contre la stupidité, ni contre
les bugs...
Ni contre les pannes matérielles. La journalisation n'est absolument
pas une garantie de système qui fonctionne bien sans perte
d'information.
On Thu, 05 Feb 2004 01:10:26 +0100, no_spam wrote:
(...)
Dans l'exemple que tu cites, le problème est du à un programme qui se comporte de façon stupide. Effectivement, les filesystem ne comportent pas de protection, ni contre la stupidité, ni contre les bugs...
Ni contre les pannes matérielles. La journalisation n'est absolument pas une garantie de système qui fonctionne bien sans perte d'information.
Gérard Patel
toufou
On Wed, 04 Feb 2004 12:09:14 +0100, toufou wrote:
Reste le pb de mon réseau
euh, je ne l'ai pas vraiment compris. Reparamétrer la config avec l'assistant Mandrake ne permet pas de choisir la connexion automatique au démarrage ?
si si mais rien à faire, il veut pas me la lancer
pour le module, effectivement tulip n'est pas chargé au démarrage
@+
On Wed, 04 Feb 2004 12:09:14 +0100, toufou
<mathieu.betton.pasdespam@free.fr> wrote:
Reste le pb de mon réseau
euh, je ne l'ai pas vraiment compris. Reparamétrer la
config avec l'assistant Mandrake ne permet pas de choisir
la connexion automatique au démarrage ?
si si mais rien à faire, il veut pas me la lancer
pour le module, effectivement tulip n'est pas chargé au démarrage
euh, je ne l'ai pas vraiment compris. Reparamétrer la config avec l'assistant Mandrake ne permet pas de choisir la connexion automatique au démarrage ?
si si mais rien à faire, il veut pas me la lancer
pour le module, effectivement tulip n'est pas chargé au démarrage
@+
toufou
Le Wed, 04 Feb 2004 12:09:14 +0100, toufou a écrit:
ma carte utilise le module tulip. Comme dois-je renseigner module.conf ?
Ben, il est chargé ton module :
héhé
euh, ce que j'avais donné c'était un lsmod une fois connecté (pour pouvoir écrire ici)
donc j'ai vérifié et tulip n'est pas chargé au boot par contre, une fois la connection configurée, il apparaît dans lsmod
ma question reste donc entière, comment configurer mon modeule.conf (en supposant que ce soit la bonne démarche) ?
@+
Le Wed, 04 Feb 2004 12:09:14 +0100, toufou a écrit:
ma carte utilise le module tulip. Comme dois-je renseigner module.conf ?
Ben, il est chargé ton module :
héhé
euh, ce que j'avais donné c'était un lsmod une fois connecté (pour
pouvoir écrire ici)
donc j'ai vérifié et tulip n'est pas chargé au boot
par contre, une fois la connection configurée, il apparaît dans lsmod
ma question reste donc entière, comment configurer mon modeule.conf (en
supposant que ce soit la bonne démarche) ?
Le Wed, 04 Feb 2004 12:09:14 +0100, toufou a écrit:
ma carte utilise le module tulip. Comme dois-je renseigner module.conf ?
Ben, il est chargé ton module :
héhé
euh, ce que j'avais donné c'était un lsmod une fois connecté (pour pouvoir écrire ici)
donc j'ai vérifié et tulip n'est pas chargé au boot par contre, une fois la connection configurée, il apparaît dans lsmod
ma question reste donc entière, comment configurer mon modeule.conf (en supposant que ce soit la bonne démarche) ?
@+
Erwann ABALEA
On Thu, 5 Feb 2004, gerard patel wrote:
On Thu, 05 Feb 2004 01:10:26 +0100, no_spam wrote:
(...)
Dans l'exemple que tu cites, le problème est du à un programme qui se comporte de façon stupide. Effectivement, les filesystem ne comportent pas de protection, ni contre la stupidité, ni contre les bugs...
Ni contre les pannes matérielles. La journalisation n'est absolument pas une garantie de système qui fonctionne bien sans perte d'information.
Exact. La journalisation (telle qu'elle est mise en oeuvre en standard dans ext3) ne garantit au mieux que les metadatas, si le matériel n'a aucun problème.
Si le PC plante au milieu de la mise à jour d'un fichier, on aura un fichier qui du point de vue du filesystem sera correct, mais du point de vue applicatif sera foutu.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Ca se fait pas du tout d'avoir donné toutes les adresses email des votants C bon pour les spammers ça ! [suit la liste intégrale des votants mal quotée] -+- AN in Guide du Neuneu Usenet : bien suivre sa logique -+-
On Thu, 5 Feb 2004, gerard patel wrote:
On Thu, 05 Feb 2004 01:10:26 +0100, no_spam
<l_indien_no_more_spams@magic.fr> wrote:
(...)
Dans l'exemple que tu cites, le problème est du à un programme
qui se comporte de façon stupide. Effectivement, les filesystem
ne comportent pas de protection, ni contre la stupidité, ni contre
les bugs...
Ni contre les pannes matérielles. La journalisation n'est absolument
pas une garantie de système qui fonctionne bien sans perte
d'information.
Exact. La journalisation (telle qu'elle est mise en oeuvre en standard
dans ext3) ne garantit au mieux que les metadatas, si le matériel n'a
aucun problème.
Si le PC plante au milieu de la mise à jour d'un fichier, on aura un
fichier qui du point de vue du filesystem sera correct, mais du point de
vue applicatif sera foutu.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Ca se fait pas du tout d'avoir donné toutes les adresses email des
votants C bon pour les spammers ça !
[suit la liste intégrale des votants mal quotée]
-+- AN in Guide du Neuneu Usenet : bien suivre sa logique -+-
On Thu, 05 Feb 2004 01:10:26 +0100, no_spam wrote:
(...)
Dans l'exemple que tu cites, le problème est du à un programme qui se comporte de façon stupide. Effectivement, les filesystem ne comportent pas de protection, ni contre la stupidité, ni contre les bugs...
Ni contre les pannes matérielles. La journalisation n'est absolument pas une garantie de système qui fonctionne bien sans perte d'information.
Exact. La journalisation (telle qu'elle est mise en oeuvre en standard dans ext3) ne garantit au mieux que les metadatas, si le matériel n'a aucun problème.
Si le PC plante au milieu de la mise à jour d'un fichier, on aura un fichier qui du point de vue du filesystem sera correct, mais du point de vue applicatif sera foutu.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Ca se fait pas du tout d'avoir donné toutes les adresses email des votants C bon pour les spammers ça ! [suit la liste intégrale des votants mal quotée] -+- AN in Guide du Neuneu Usenet : bien suivre sa logique -+-
g.patel
On Thu, 05 Feb 2004 02:51:17 +0100, toufou wrote:
(... connexion automatique Internet marche pas sur Mandrake...)
si si mais rien à faire, il veut pas me la lancer
que dit ifconfig après un redémarrage (et sans reconfigurer la connexion, évidemment) ?
pour le module, effectivement tulip n'est pas chargé au démarrage
hmm... alias ethx tulip dans modules.conf (avec x = no de la carte, eth0 s'il n'y en a qu'une) Mais ça devrait etre paramétré par drakconnect normalement. Bizarre.
Gérard Patel
On Thu, 05 Feb 2004 02:51:17 +0100, toufou
<mathieu.betton.pasdespam@free.fr> wrote:
(... connexion automatique Internet marche pas sur Mandrake...)
si si mais rien à faire, il veut pas me la lancer
que dit ifconfig après un redémarrage (et sans reconfigurer
la connexion, évidemment) ?
pour le module, effectivement tulip n'est pas chargé au démarrage
hmm...
alias ethx tulip dans modules.conf (avec x = no de la carte, eth0 s'il
n'y en a qu'une)
Mais ça devrait etre paramétré par drakconnect normalement.
Bizarre.
(... connexion automatique Internet marche pas sur Mandrake...)
si si mais rien à faire, il veut pas me la lancer
que dit ifconfig après un redémarrage (et sans reconfigurer la connexion, évidemment) ?
pour le module, effectivement tulip n'est pas chargé au démarrage
hmm... alias ethx tulip dans modules.conf (avec x = no de la carte, eth0 s'il n'y en a qu'une) Mais ça devrait etre paramétré par drakconnect normalement. Bizarre.
