Announcement

Collapse
No announcement yet.

Bizarre and far-reaching problem.

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Bizarre and far-reaching problem.

    Hi guys!

    I've been using linux for probably about 9 months now, but I've only started using Kubuntu recently. (Probably about a month ago.)

    It took me a little while to get it working, I had the ubiquitous xorg.conf problem with the wacom entries, etc. but I'd managed to get everything working pretty nicely until I ran into some trouble over the last couple of days.

    Several programs have ceased working, including Konqueror, Kate, and Amarok.

    Firefox still works (thankfully), Kopete, Adept do as well.

    When I boot up, I get a message from the panel saying something about how the trash system couldn't start correctly.

    Has anyone run into this problem before?
    Hopefully by giving you an idea of which programs are affected, someone will be able to guess what might be at fault.

    I haven't made any major changes as far as I'm aware. I installed GIMP recently, but that was after the problem had already occurred.

    Thanks.

    #2
    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.

    Comment


      #3
      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]

      Comment


        #4
        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.

        Comment


          #5
          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.

          Comment


            #6
            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]

            Comment


              #7
              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?

              Comment


                #8
                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]

                Comment


                  #9
                  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.

                  Comment


                    #10
                    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 ...

                    Comment


                      #11
                      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."

                      Comment


                        #12
                        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 ...

                        Comment


                          #13
                          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?

                          Comment


                            #14
                            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?
                            Windows no longer obstructs my view.
                            Using Kubuntu Linux since March 23, 2007.
                            "It is a capital mistake to theorize before one has data." - Sherlock Holmes

                            Comment


                              #15
                              Re: Bizarre and far-reaching problem.

                              Looks like it. Isn't it great when people comment their code?
                              For external use only.

                              Comment

                              Working...
                              X