5

Recently, when I've been starting my computer I'm informed that it is recovering the journal for one of my ext3 partitions.

One might expect this behaviour if the computer shutdown improperly, but, as far as I can tell this is occurring after normal shutdowns.

Additionally, the number of inodes which are found to be orphaned and cleared is only one or two in these cases.

I have performed an fsck, but the situation continues.

Which logs files can I check to try to find out why this is happening? What are some reasons it may have happened? How can I resolve it?

UPDATE

fstab is as follows:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda5 during installation
UUID=ead12a48-4a3b-4e3a-b611-d3fc62e8716a /               ext4    errors=remount-ro,noatime,nodiratime 0       1
# /home was on /dev/sda6 during installation
UUID=217f1c44-5d04-4c75-9d4a-2a70b1726434 /home           ext3    defaults,noatime,nodiratime        0       2

UPDATE 2

cat /var/log/fsck/{checkfs,checkroot} returns (Nothing has been logged yet.) twice.

Richard
  • 1,367
  • @Rinzwind, filesystem state: clean. – Richard Jan 28 '13 at 11:17
  • I am out of suggestions @richard :) Here have a bounty on your question >:) – Rinzwind Jan 28 '13 at 11:23
  • @Rinzwind, let me check the filesystem state another time or two just to be sure that the shutdown was symptomatic. – Richard Jan 28 '13 at 11:27
  • Do the files /var/log/fsck/{checkfs,checkroot} something? What is your system date and what time shows your BIOS? – qbi Jan 28 '13 at 20:16
  • @qbi, those files both show (Nothing has been logged yet.) I'll check the BIOS time shortly. – Richard Jan 28 '13 at 20:37
  • What kind of hardware do you have? Type of SSD, storage controller, etc. I've seen OCZ SSDs claiming a write had performed, but it was actually only written to its DRAM cache. Whenever my laptop powered off or suspended the DRAM cache buffer wasn't fully flushed yet and my /home got corrupted more and more silently... By the time I found the cause and a workaround in the shutdown scripts (extra sleep) it died completely. I changed it to an Intel SSD and boom all problems vanished. – gertvdijk Jan 28 '13 at 23:15
  • @gertvdijk, I have an HDD. How would I check the cache settings? – Richard Jan 29 '13 at 11:16
  • @Richard The cache I was talking about is properly handled by the kernel by doing a sync on unmount. The issue I was talking about was a plain hardware problem. I haven't seen HDDs doing this, so I think this is not applicable to you. Please do include all the details I asked for. And please integrate the information in your question, rather than posting update 2. We can see the differences if you update your question. – gertvdijk Jan 29 '13 at 11:48
  • @richard which of the 2 is the best answer? >:) – Rinzwind Feb 04 '13 at 13:24

2 Answers2

2

Your only ext3 partition happens to be /home. One possible reason for your problem is that /home isn't being unmounted because it is in use at the time your system is being shut down. Since /home shouldn't be in use when no normal user is logged in, identifying if it is in use when nobody is logged in is one way of identifying if this particular possible issue is the cause of your specific problem.

  1. Temporarily enable root login on your system (we'll disable it again later). This will allow you to log in without accessing /home, so that you can check whether anything else is using it and whether it unmounts correctly.

  2. Log out.

  3. Press Ctrl+Alt+F1 to switch to a text virtual terminal.

  4. Log in as root. This will start a shell in root's home directory (/root) which is outside of /home.

  5. Try to unmount /home by typing umount /home (no sudo is required since you're already root).

  6. If this succeeds, then this isn't your problem. If it fails, then this is your problem. If the reason is that the filesystem is in use, then the command fuser -m /home will list processes using /home which you can investigate.

  7. Mount /home again by typing mount /home.

  8. Log out with the command exit.

  9. Switch back to the graphical login screen by pressing Alt+F7.

  10. Log back in as yourself.

  11. Disable root login to return your system to its original configuration.

This may or may not identify the cause of your specific problem, but should work to identify processes that are preventing /home from being cleanly unmounted on system shutdown in the general case.

Community
  • 1
Robie Basak
  • 15,930
  • I gave this a try and, indeed, it would not unmount. Using fuser -vm /home showed that there was single process with PID kernel accessing the file-system. I'm not sure where to go from here. Is it possible to see what file is being accessed? I have an inkling that it may be related to the home directory being encrypted (ecryptfs). – Richard Jan 28 '13 at 23:02
  • Could you paste the output of fuser into your question? – qbi Jan 29 '13 at 18:57
2

As you mentioned in your comment eCryptfs is a possible cause for your problem. To check this out do the following steps:

  1. Log out and log in as a different user
  2. Try to open your files in /home/richard (or however your user is called).
  3. If you can access and read the files, your home was not correct unmounted.

Another thing you can do as user is to enter ecryptfs-umount-private. This scripts quits on success with the message:

Your private directory has been unmounted.

On error you might get the message:

fopen: No such file or directory
Cannot chdir into mountpoint.

In the latter case the problem are often missing symlinks. So do the following steps:

  1. Login as your normal user
  2. Make sure your home directory is not encrypted (You can read all files).
  3. Open a terminal (If you are working in a terminal, just type cd to get into your $HOME).
  4. Type ln -s /home/.ecryptfs/YOUR_USERNAME/.ecryptfs and ln -s /home/.ecryptfs/YOUR_USERNAME/.Private.

The main point are the symbolic links in the last step. In some cases they are missing. This leads to not encrypting and umounting your data in the home.

However if the problem persists then there might also the file $HOME/.ecryptfs/auto-umount missing. If this is the case your home directory will not be automatically unmounted. Just enter touch $HOME/.ecryptfs/auto-umount to change it.

qbi
  • 19,545
  • I tried this and could not access the files, so I guess the logout went correctly. Is there any log file for checking to see if this happens consistently? – Richard Jan 29 '13 at 11:16