Egor Kobylkin wrote:
Hi All,
Just after I click in Nautilus 2.14.1 on a folder, which is an unmounted
samba share, the computer locks-up and the only thing I can do is
reboot. Can anybody tell which package it might be, so I can file a bug
report?
Below a snip from /var/log/messages and a dmesg. I have left the
computer running over the night in hope that it will recover, this is
why restart was done only next morning.
Your problem description is a bit sparse on details. Here are some tips on
reporting problems in case you need to follow through with this issue:
http://web.utk.edu/~rmahurin/debian-user-faq/faq.html
Attempting manual resume
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
ieee1394: Host added: ID:BUS[0-00:1023] GUID[0040ca010508a211]
kjournald starting. Commit interval 5 seconds
EXT3-fs: hda1: orphan cleanup on readonly fs
ext3_orphan_cleanup: deleting unreferenced inode 580780
ext3_orphan_cleanup: deleting unreferenced inode 580655
ext3_orphan_cleanup: deleting unreferenced inode 580627
ext3_orphan_cleanup: deleting unreferenced inode 580625
EXT3-fs: hda1: 4 orphan inodes deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
This snippet suggests that you didn't do a clean reboot. The last part of my
reply is based on that assumption, so that as you work through this issue, you
don't endanger any of your data in the process.
I can't address the samba issue specifically but your log messages don't seem to
cover the period of the failure. You may need to look at earlier logs, which
may be renamed in /var/log, possibly in gzip'd form, and post those. Any log
entries covering the SMB access attempt will be time stamped with the time of
the failure.
When drive or network access fails, it may appear to be a "lock-up." I don't
know if these are buggy drivers or excessive timeouts, but they may cause the
app or console to become unresponsive. It can also cause apparently
"unkillable" processes. NFS used to be notorious for this, and SMB may have
related problems.
In general, when an X terminal or X app becomes unresponsive due to a device or
network access failure, you may have to wait a long time for it to timeout.
Alternative you could try to start another terminal. If X is completely
unresponsive, you can start a session on another VT using xstart, kill X with
ctl-alt-backspace, or try to open a virtual terminal by pressing ctl-alt-F<n>,
then log in to fix the problem or reboot with shutdown, reboot or ctl-alt-del.
If none of these work, or the keyboard is unresponsive then you can try to
access the system over the LAN from another system, which requires ssh, vnc or
similar programs and specific configurations. All of these are explained in the
Howto's.
(There are some more extreme solutions such as using a serial console,
alt-sysreq reboot options, and even the the last-ditch joystick button kernel
reboot trick. These require special kernel support and I've never had to resort
to them with Debian stable, although serial consoles are handy for headless
servers. These are also in the Howto's)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]