Announcement

**burnsy** · Jul 21, 2007, 11:16 PM

Re: Bizarre and far-reaching problem.

Also, I think I've discovered that Konqueror _does_ work, but can't show my home folder.

Any kind of "open folder" or "save file" dialogues will hang if I try to point them at my home folder.

Well, I suppose that goes a fair way to pointing out where the problem might lie, but it doesn't make me overjoyed to think that I might lose all that data.

**penguin.ch** · Jul 22, 2007, 01:16 AM

Re: Bizarre and far-reaching problem.

First of all, make a full copy of your "home" (just in case ...).

With this done, ensure

- that there is still "disk space" available:

Code:

sudo df -h -x usbfs -x tmpfs --local

- that the "home" really belongs to you:

Code:

sudo chown -R [user]:[user] /home/[user]

**burnsy** · Jul 23, 2007, 07:38 AM

Re: Bizarre and far-reaching problem.

Thanks for your reply.

I've checked the disk space, and there's heaps and heaps.

I also ran the last command to ensure that I 'owned' my home folder, but still no joy.

I noticed something more when looking at the process table of KDE system guard.
The programs that I've mentioned as having a problem show processes, even though I haven't run them this boot.
For instance, there are:
2 amarokapp
1 kaffeine
2 kate
and 3 konqueror
Trying to kill the processes removes 2 of the konquerors, but the other processes don't respond to my attempt to kill them.

I've verified that Kaffeine will work provided I can prevent it from ever pointing at the home directory.

Aha! I think I may have discovered something mid-post!

I was confirming that Konqueror would also work provided I kept it away from /home, and opened up my 'storage media' to test it. Clicking on my sdb1 partition caused it to hang!
There is a symlink in my /home pointing to this partition, where I keep my music.
It would seem that the problem lies in this partition.
I'll try and remove the symlink through the terminal and see if that gets me back my /home.

Hopefully then we can establish what's actually causing the problem.

The universe doesn't like my music collection. It seems that whenever I lose data it's mp3s, never anything else. That is, unless it's crucial receipts.

**burnsy** · Jul 23, 2007, 07:43 AM

Re: Bizarre and far-reaching problem.

Yes! We have taken back the /home folder, commander!

The enemy have retreated to their bunker in the sdb1 partition.

**penguin.ch** · Jul 23, 2007, 08:05 AM

Re: Bizarre and far-reaching problem.

Originally posted by burnsy

The enemy have retreated to their bunker in the sdb1 partition.

Nuke 'em 8) or create a better ]
USER # ls -l /home [in excerpts]
lrwxrwxrwx root root data -> /media/data
lrwxrwxrwx root root fake -> /fake
lrwxrwxrwx root root save -> /media/save
USER # ls -l /media [in excerpts]
drwxrwxrwx root root data
drwxrwxrwx root root save
USER # ls -l / [in excerpts]
drwxrwxrwx root root fake
[/code]

**dibl** · Jul 23, 2007, 08:24 AM

Re: Bizarre and far-reaching problem.

Originally posted by burnsy

Clicking on my sdb1 partition caused it to hang!

That wouldn't happen to be a NTFS formatted partition, would it?

**penguin.ch** · Jul 23, 2007, 09:09 AM

Re: Bizarre and far-reaching problem.

Originally posted by burnsy

the sdb1 partition

Could you please elaborate ...

Code:

[sudo] more /etc/fstab | grep sdb1
[sudo] more /etc/mtab | grep sdb1
[sudo] ls -la [mountpoint_address]

**burnsy** · Jul 24, 2007, 06:33 PM

Re: Bizarre and far-reaching problem.

No, sdb1 is an ext3 partition.

I'll post the fstab and mtab info tonight when I get home.
I won't be able to 'ls -la' though, because changing to that mountpoint hangs even when using konsole.

Thanks for your replies.

**penguin.ch** · Jul 25, 2007, 12:16 AM

Re: Bizarre and far-reaching problem.

Originally posted by burnsy

changing to that mountpoint hangs even when using konsole

Interesting, isn't it

If mounted to e.g. /media/disk, you could issue ls -l /media instead. You get the idea ...

**burnsy** · Jul 27, 2007, 03:21 AM

Re: Bizarre and far-reaching problem.

burnsy@bdig:~$ sudo more /etc/fstab | grep sdb1
Password:
# /dev/sdb1
UUID=82aaedae-b160-4852-86c1-31c4d6a49e25 /media/sdb1 ext3 defaults 0 2

burnsy@bdig:~$ sudo more /etc/mtab | grep sdb1
/dev/sdb1 /media/sdb1 ext3 rw 0 0

burnsy@bdig:~$ ls -la /media
total 60
drwxr-xr-x 7 root root 4096 2007-07-27 18:20 .
drwxr-xr-x 21 root root 4096 2007-07-11 23:15 ..
lrwxrwxrwx 1 root root 6 2007-07-11 23:39 cdrom -> cdrom0
drwxr-xr-x 2 root root 4096 2007-07-11 23:39 cdrom0
lrwxrwxrwx 1 root root 45 2007-07-11 23:40 .directory -> /etc/kubuntu-default-settings/directory-media
-rw-r--r-- 1 root root 0 2007-07-27 18:20 .hal-mtab
--wS--s--T 1 root root 0 2007-04-17 15:25 .hal-mtab-lock
lrwxrwxrwx 1 root root 42 2007-07-11 23:40 .hidden -> /etc/kubuntu-default-settings/hidden-media
drwxr-xr-x 4 burnsy burnsy 20480 2007-07-25 21:25 sdb1
drwxr-xr-x 5 burnsy burnsy 4096 2007-07-19 19:57 sdb2
drwxr-xr-x 390 burnsy burnsy 16384 2007-07-26 01:16 sdb3
dr-xr-x--- 1 root plugdev 8192 2007-07-19 20:23 xp

I've also been getting an error every time I boot:
"The process for the trash protocol died unexpectedly."

**penguin.ch** · Jul 27, 2007, 03:29 AM

Re: Bizarre and far-reaching problem.

Originally posted by burnsy

--wS--s--T 1 root root 0 2007-04-17 15:25 .hal-mtab-lock

Merely a gut feeling - but if this were my machine, I'd remove that "lock" and try again ...

**burnsy** · Jul 27, 2007, 08:08 PM

Re: Bizarre and far-reaching problem.

That .hal-mtab-lock file was empty, not sure if it's supposed to be or not, but I figured that if it's empty I can't edit it, so deleting it must be the go.
It's reappeared now that I've rebooted, but I don't think it was part of the problem, because it just happened by chance that this boot it decided to check my file system on a few partitions.

When it checked sdb1, it came up with:
"HTREE directory inode 2 has invalid root node"
It seemed to do a few things to fix this, and now that it's finished rebooting, I can access that partition once again.

I should have thought to check the file system straight away, but there you go. I'll think of that next time.
Thanks for all your help guys.

ps. What does that .hal-mtab-lock file do?

**Snowhog** · Jul 27, 2007, 09:27 PM

Re: Bizarre and far-reaching problem.

Originally posted by burnsy

ps. What does that .hal-mtab-lock file do?

From http://www.mail-archive.com/util-lin.../msg00009.html
(towards the bottom of the coding)

/* Create the lock file.
The lock file will be removed if we catch a signal or when we exit. */
/* The old code here used flock on a lock file /etc/mtab~ and deleted
this lock file afterwards. However, as rgooch remarks, that has a
race: a second mount may be waiting on the lock and proceed as
soon as the lock file is deleted by the first mount, and immediately
afterwards a third mount comes, creates a new /etc/mtab~, applies
flock to that, and also proceeds, so that the second and third mount
now both are scribbling in /etc/mtab.
The new code uses a link() instead of a creat(), where we proceed
only if it was us that created the lock, and hence we always have
to delete the lock afterwards. Now the use of flock() is in principle
superfluous, but avoids an arbitrary sleep(). */

/* 2007-01-10 Dieter Stueken <[EMAIL PROTECTED]>
Instead of creating new inodes for mtab~ each time, a static file
.mtab.lock is used, which is never deleted. This file is linked
to mtab~ to perform the lock. F_WRLCKW may be used in addition to
perform synchronization of outstanding mount processes. The flock
may either be placed on mtab~ or .mtab.lock itself (which is the same),
but it never gets lost, as the inode holding the flock remains.
*/

Not that I understand the code, but I think, basically, this file (.hal-mtab-lock) is created when a user logs on and accesses the /media partition. It's purpose is to prevent duplicate mounting?

**SheeEttin** · Jul 27, 2007, 10:27 PM

Re: Bizarre and far-reaching problem.

Looks like it. Isn't it great when people comment their code?

Announcement

Bizarre and far-reaching problem.

Bizarre and far-reaching problem.

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment