3

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?

Improve this question
5
  • 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. Commented Dec 1, 2014 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 Commented Dec 1, 2014 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... Commented Dec 1, 2014 at 14:39
  • @shawty There is no corruption on the partition I'm trying to mount, at least not according to e2fsck -f Commented Dec 1, 2014 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 :-) Commented Dec 1, 2014 at 15:20

1 Answer 1

Reset to default
3

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

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.