(unreachable) dans la console ? [ecryptfs+sudo]

En ce moment, j’ai souvent ce problème : quand j’ouvre un terminal :

Et plus rien ne fonctionne (tout plante).

Je n’ai pas la moindre idée d’où ça peut venir. J’ai entendu parler d’un problème de partition (mais ça n’apparait pas au démarrage, c’est un peu aléatoirement lors de l’utilisation).

Ça refonctionne après un reboot… jusqu’à la prochaine fois.

Des pistes ?

EDIT: dans /var/log/syslog, j’ai aussi plein d’erreurs comme ceci :

Quand je fais une recherche de ce message d’erreur, il est indiqué que c’est lié à /etc/inittab. Voici donc le contenu de ce fichier :

[code]# /etc/inittab: init(8) configuration.

$Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

The default runlevel.

id:2:initdefault:

Boot-time system configuration/initialization script.

This is run first except when booting in emergency (-b) mode.

si::sysinit:/etc/init.d/rcS

What to do in single-user mode.

~~:S:wait:/sbin/sulogin

/etc/init.d executes the S and K scripts upon change

of runlevel.

Runlevel 0 is halt.

Runlevel 1 is single-user.

Runlevels 2-5 are multi-user.

Runlevel 6 is reboot.

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

Normally not reached, but fallthrough in case of emergency.

z6:6:respawn:/sbin/sulogin

What to do when CTRL-ALT-DEL is pressed.

ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

Action on special keypress (ALT-UpArrow).

#kb::kbrequest:/bin/echo “Keyboard Request–edit /etc/inittab to let this work.”

What to do when the power fails/returns.

pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop

/sbin/getty invocations for the runlevels.

The “id” field MUST be the same as the last

characters of the device (after “tty”).

Format:

:::

Note that on most Debian systems tty7 is used by the X Window System,

so if you want to add more getty’s go ahead but skip tty7 if you run X.

co:2345:respawn:/sbin/getty hvc0 9600 linux

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

Example how to put a getty on a serial line (for a terminal)

#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

Example how to put a getty on a modem line.

#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3[/code]

Salut,
Les deux problèmes ne sont pas liés.

(unreachable): c’est ~ qui est “unreachable”. Ton home… C’est probablement un problème de chemin.

Que donne:

Ah, en fait c’est dès que je fais sudo, ça démonte mon /home chiffré…

Pour activer le sudo, j’ai juste fait :

puis rebooté.

Et maintenant, dès le premier sudo ça démonte mon /home/$USER…

bugs.debian.org/cgi-bin/bugreport.cgi?bug=639391
bugs.launchpad.net/ecryptfs/+bug/691237

[quote=“®om”]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639391
bugs.launchpad.net/ecryptfs/+bug/691237[/quote]

Et l’utilisation de su -c te permet pas de contourner l’utilisation de sudo ( si oui un alias dans ton bash.rc et le tour est joué :033 le temps que le souci soit réglé ).

Salut,
Tu ne réponds pas à ma question, et tu changes le sujet entre-temps.
Ça ne me donne pas envie de chercher. :exclamation:

Désolé, au départ je n’avais pas vu ta réponse (enfin question), et quand je l’ai vue c’est quand je me suis aperçu que ça venait de sudo (et donc pas d’un problème de chemin)…

quote=“lol”: c’est ~ qui est “unreachable”. Ton home… C’est probablement un problème de chemin.

Que donne:

[code]/home/rom[/comde]

[quote=“Clochette”][quote=“®om”]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639391
bugs.launchpad.net/ecryptfs/+bug/691237[/quote]

Et l’utilisation de su -c te permet pas de contourner l’utilisation de sudo ( si oui un alias dans ton bash.rc et le tour est joué :033 le temps que le souci soit réglé ).[/quote]
Ça peut effectivement remplacer temporairement, mais contrairement à sudo il redemande le mot de passe à chaque fois…

[quote=“®om”][quote=“Clochette”][quote=“®om”]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639391
bugs.launchpad.net/ecryptfs/+bug/691237[/quote]

Et l’utilisation de su -c te permet pas de contourner l’utilisation de sudo ( si oui un alias dans ton bash.rc et le tour est joué :033 le temps que le souci soit réglé ).[/quote]
Ça peut effectivement remplacer temporairement, mais contrairement à sudo il redemande le mot de passe à chaque fois…[/quote]

Heureusement, même l’utilisation de sudo devrais le demander c’est une hérésie d’utiliser sudo sans demande de mots de passe.

Il y a eu assez de fil traitant de ça :033