Today I upgraded my pretty ancient Debian Linux kernel (3.2-23) to 3.16-7. The machine boots okay, except that some fstab entries are suddenly causing issues.

# /etc/fstab: static file system information.
# <file system> <mount point>   <type>  <options>                   <dump>  <pass>
proc            /proc           proc    defaults                    0       0
/dev/sda1       /               ext3    defaults,errors=remount-ro  0       1
#/dev/sda2      none            swap    sw                          0       0
#/dev/sda5      /home           ext3    defaults,errors=remount-ro  0       2

When I uncomment the last two lines, I boot into recovery mode because the partitions cannot be found even after a 1:30 wait. The message on screen while waiting is:

A start job is running for device dev-sda5.device

I don't even care much for the swap partition at this point, but without the home partition I cannot do much :(

If I leave the lines commented, I can mount the partition manually without any problems after booting, so why is it failing to mount at boot time? Obviously the device is ready, because it's the same drive as the root partition.

The file system is correctly set and the kernel was compiled with the same configuration after running make oldconfig. I've also tried switching to using UUIDs, but I get the same result (slightly different screen message though).

Any idea why this is happening?

  • Please check (and post here) what is logged to /var/log/syslog, /var/log/message and/or /var/log/dmesg during booting up when the mounting fails. – zagrimsan Dec 1 '14 at 14:05
  • I have this very same problem on an Ubuntu System I run. EVERY TIME I reboot the machine I loose 2 partitions, one used by my Postgres and one used by my E-Mail server. Given that it's a server however I generally don't have to reboot it very often, so it's not a huge problem. It appears (At least in my case) that I have a process that runs at boot up, that corrupts something in the file system info. In all honesty, I've never been able to track down exactly what causes it, but generally if I run fsck on the partition, it finds some problems, then fixes them. If I then Immediately re-start the – shawty Dec 1 '14 at 14:24
  • @zagrimsan /var/log/syslog and /var/log/message don't contain anything even mentioning the device, except just after booting: pastebin.com/BxycwR3q That only confirms the partition is in fact there though... – Thorarin Dec 1 '14 at 14:39
  • @shawty There is no corruption on the partition I'm trying to mount, at least not according to e2fsck -f – Thorarin Dec 1 '14 at 14:40
  • @Thorarin it's the same in my case too, sometimes fsck reports no damage, but just running it then rebooting seems to fix stuff. Like I say, not 100% why, but it fixes things :-) – shawty Dec 1 '14 at 15:20

I found the answer to my problem on stack overflow. In summary:

According to this readme, systemd apparently requires the CONFIG_FHANDLE kernel option. After recompiling with this option enabled, mounting the partitions worked fine again.

For people using make menuconfig, the option is under General setup: enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.