Linux: /etc/fstab down't work with RPI2

Created on 11 Feb 2015 · 43Comments · Source: raspberrypi/linux

Hello,

/etc/fstab doens't work in RPI2. Simply it doesn't mount anything.

You can see here a lot of people with this problem:
http://www.raspberrypi.org/forums/viewtopic.php?f=28&t=99491

Source

pirulloz

Most helpful comment

Try adding "noauto,x-systemd.automount" to your mount options in fstab.

DavidCWGA on 29 Jan 2016

👍4

All 43 comments

It does at least mount nfs for me on RPI2:

192.168.10.92:/home/pi  /home/pi/work   nfs     rw      0       0

notro on 11 Feb 2015

@pirulloz
Does same /etc/fstab mount okay on Pi1 with 3.18 kernel?

@notro any guesses?

popcornmix on 11 Feb 2015

Yes, with 3.18.6+ on RPI1 it works good.

pirulloz on 11 Feb 2015

Can you add maxcpus=1 to end of cmdline.txt and report if it works?

popcornmix on 11 Feb 2015

I've tried. With that command it works fine.....

But now am i limited to 1 core? I don't know how that line works

pirulloz on 11 Feb 2015

Yes, my suspicion was that /etc/fstab is being parsed before the disks have been identified (possibly through different parts of boot being done in parallel). There must be a way of ensuring /etc/fstab only occurs after disks are identified...

popcornmix on 11 Feb 2015

ok.... i understand..... so i wait for a patch from you :)

If you need some support please let me know. I can do some tests.....

pirulloz on 11 Feb 2015

notro on 11 Feb 2015

@pirulloz
can you remove maxcpus and add rootdelay=10 to cmdline.txt?
If that fixes it does a smaller number work?

I've got a USB ssd disk here, but it seems to be mounted just fine (without any cmdline.txt changes)

popcornmix on 11 Feb 2015

@popcornmix rootdelay=10 makes /etc/fstab work for me. Will try with lower values later on.

lekkerduidelijk on 11 Feb 2015

With rootdelay=10 it works fine.
With rootdelay=5 it works fine
With rootdelay=2 it doesn't work

pirulloz on 11 Feb 2015

I can confirm rootdelay=5 works fine for me.
Just as a bit of background, I did not have this problem with kernel 3.18.5 but when upgrading to 3.18.7 was when the issues started. All kernel versions worked find in a Pi rev 2 model B

keithellis74 on 15 Feb 2015

@keithellis74
Can you confirm that downgrading kernel avoids the requirement of rootdelay?

Look here: https://github.com/Hexxeh/rpi-firmware/commits/master
each firmware update has a git hash (hex number) at the end of the URL. Run:

sudo rpi-update <hash>

To get a specific version. E.g.

sudo rpi-update 96f2257f57196817ebb030096993823be721fb27

will get the initial 3.18.5 kernel. Try to identify the first kernel that fails to mount disk without rootdelay.

popcornmix on 16 Feb 2015

Hi, just tried to downgrade to 3.18.5 and get the following error.

** Updating kernel modules
cp: cannot start '//root/.rpi-firmware/modules/': No such file or directory

Keith Ellis

On 16 Feb 2015, at 14:14, popcornmix [email protected] wrote:

@keithellis74
Can you confirm that downgrading kernel avoids the requirement of rootdelay?

Look here: https://github.com/Hexxeh/rpi-firmware/commits/master
each firmware update has a git hash (hex number) at the end of the URL. Run:

sudo rpi-update
To get a specific version. E.g.

sudo rpi-update 96f2257f57196817ebb030096993823be721fb27
will get the initial 3.18.5 kernel. Try to identify the first kernel that fails to mount disk without rootdelay.

—
Reply to this email directly or view it on GitHub.

keithellis74 on 16 Feb 2015

Ok, I had a play about this morning. I downgraded to 3.18.6 using commit 3f11b3fb1f390b60daa22f2ca2ecda5266295a84 and still had the same problem. It booted using rootdelay=5 but once removed it failed to boot again.

I then tried to downgrade to 3.18.5 using commit 67197d9d73c56570578cb2c6c188af263a37ecd9 (with the missing modules) This applies without any errors but upon reboot with rootdelay=5. uname -a reports kernel version 3.18.6 which is rather confusing. When rootdelay=5 is removed is fails to boot agian.

keithellis74 on 17 Feb 2015

Ah yes, 67197d9d73c56570578cb2c6c188af263a37ecd9 predates the Pi2 builds.
c9b520b05cf3c350c46f76ba36a9735ca24601b7 is the first commit with Pi2 support.

If that doesn't work without rootdelay then I suspect it has never worked.

popcornmix on 17 Feb 2015

@popcornmix
Yes you are right, hard drive mounting without rootdealy=5 has never work on kernel 3.18.5.

The reason I thought it had

I found an SD image with 3.18.5, booted my Pi, it worked fine, however it was not setup to mount a drive in /etc/fstab/
I attached the drive and mounted it manually, all worked
I edited /etc/fstab/ to mount the drive
I rebooted and the Pi booted fine, apparently on a reboot the hard drive barely stops spinning (if at all), thus is picked up during reboot. If I had shut shown and then restarted it would not have worked at this point.
I upgraded using sudo apt-get upgrade
rebooted, (I may have shut down at this point, I can't remember) and the Pi failed to boot.

Sorry for the confusion.

keithellis74 on 19 Feb 2015

I also had this problem when updating from the RPi B+ to RPi2 (even with updating everything properly). I had to login as root during the boot process and run mount -a and now it seems to mount all of my external drives properly on reboot without needing rootdelay.

StevenHickson on 19 Feb 2015

I think @popcornmix is right about /etc/fstab being parsed before the disks have been identified due to the parallelization of the boot process.
Though it is weird to me that mine is now working without root_delay though. I have my /home/ partition mounted on an external and set up fstab to run fsck checks on boot. Perhaps that adds enough delay that it works?

StevenHickson on 26 Feb 2015

After trying all night, I want to say thanks to this thread. rootdelay of 5 is working for me too!

limpygnome on 7 Mar 2015

Mounting a separate /home by _device path_ (e.g. /dev/mmcblk0p3) instead of UUID works with stock Raspbian with unmodified cmdline.

kernc on 23 Mar 2015

Hello,
I have the same problem with my new RPi2, BUT :

The problem occurs when I try to mount a network drive using CIFS
mount -a doesn't work. Only manual mount does (ie : sudo mount -t cifs //192.168.0.1/share/home/NAS -o uid=1000 ... does work, but mount -a with a fstab containing the very same arguments doesn't. The error msg is : "CIFS VFS: cifs_mount failed w/return code = -13")

Thank you for your help.
Regards,

natbon on 10 Jun 2015

I'm having the same issue as well. Interestingly, trying to mount the drives through /etc/rc.local fails as well, even though everything should have had a chance to load by then. I even added sleep 60 before the mount command and it still failed. The exact same command succeeds after I log in as the pi user however.

Darkhand81 on 17 Jun 2015

I'm having the same problem with nfs mounts in /etc/fstab. They don't mount on boot, but "mount -a" works fine after booting. rootdelay doesn't fix it. kernel 4.1.4-v7+

DavidCWGA on 7 Aug 2015

I'm having the same problem with nfs mounts in /etc/fstab. They don't mount on boot, but "mount -a" works fine after booting. rootdelay doesn't fix it. kernel 4.1.4-v7+

lathoub on 8 Aug 2015

Not sure why someone duplicated my comment. That wasn't me.

DavidCWGA on 10 Aug 2015

Because I had the exact same error! But let me change it, just for you: nfs mounts in /etc/fstab doesn't work at boot time, but mount -a works after booting. rootdelay did not help. The kernel i'm using is 4.1.4-v7+

lathoub on 10 Aug 2015

Mon Sep 21 08:36:03 2015: [....] Setting kernel variables ...[?25l[?1c7[27G[[32m ok [39;49m8[?25h[?0cdone.
Mon Sep 21 08:36:03 2015: [....] Configuring network interfaces...if-up.d/mountnfs[eth0]: waiting for interface wlan0 before doing NFS mounts ... (warning).
Mon Sep 21 08:36:04 2015: wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
Mon Sep 21 08:36:04 2015: run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1
Mon Sep 21 08:36:04 2015: if-up.d/mountnfs[wlan0]: waiting for interface wlan1 before doing NFS mounts ... (warning).
Mon Sep 21 08:36:04 2015: wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
Mon Sep 21 08:36:04 2015: run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return code 1
Mon Sep 21 08:36:05 2015: Starting rpcbind daemon...rpcbind: cannot create socket for udp6
Mon Sep 21 08:36:05 2015: rpcbind: cannot create socket for tcp6
Mon Sep 21 08:36:05 2015: .
Mon Sep 21 08:36:05 2015: Starting NFS common utilities: statd idmapd.
Mon Sep 21 08:39:05 2015: mount.nfs4: Connection timed out
Mon Sep 21 08:39:06 2015: ifup: interface eth0 already configured

here you can see the problems with timings of wpa-suplicant and mount-nfs.

I think that's the problem

andre-dierker on 21 Sep 2015

I'm using wired ethernet, so it's nothing to do with wpa.

DavidCWGA on 21 Sep 2015

I'm using wired ethernet too. The nfs timeout at boot time exist anyway.

andre-dierker on 21 Sep 2015

NFS4 requires idmapd, did you configured it right?

andre-dierker on 21 Sep 2015

Having the same issue as DavidCWGA and lathoub. No solution or workaround yet?

luispablo on 26 Sep 2015

Solved it by adding the package usbmount. Hope it helps...

luispablo on 26 Sep 2015

usbmount did the trick for me too. Thanks @luispablo

IntellixWeb on 29 Oct 2015

@pirulloz Does this work for you with jessie?
Does installing usbmount help?

popcornmix on 29 Oct 2015

I'm trying to mount an nfs volume via /etc/fstab, and installing usbmount did not help. sudo mount -a does work.

uname -a
Linux raspberrypi 4.1.15-v7+ #831 SMP Tue Jan 19 18:39:46 GMT 2016 armv7l GNU/Linux

afspear on 29 Jan 2016

Try adding "noauto,x-systemd.automount" to your mount options in fstab.

DavidCWGA on 29 Jan 2016

👍4

adding the options worked great! So, that says, don't use fstab to auto mount the volume, but ask systemd to do it?

afspear on 29 Jan 2016

Yes. Obviously this only works if you're using systemd.

DavidCWGA on 29 Jan 2016

you could simply write a cron under root that runs mount -a on reboot. Add in a sleep just in case things aren't ready yet. Worked for me.

$sudo su -

crontab -e

@reboot /root/mount_drives.sh

/root/mount_drives.sh:

!/bin/bash

sleep 10
mount -a

randoogle on 8 Feb 2016

you could simply write a cron under root that runs mount -a on reboot.

This is a super-ugly hack. Until the problem is fixed for real (and given this issue is closed, they're clearly not in any hurry) the "noauto,x-systemd.automount" mount options are the best solution.

DavidCWGA on 8 Feb 2016

you could simply write a cron under root that runs mount -a on reboot.

Agreed with @DavidCWGA - not only is this an ugly hack, please be aware that @reboot literally means reboot - and not a clean system start after a previous shutdown.

ziesemer on 8 Feb 2016

Thanks, ziesemer, for keying me in on that. I hadn't realized @reboot only works sometimes. As for the more elegant option of using systemd, I've tried installing it and adding the options above, but then my cifs shares won't mount at all. As I've already spent 1 1/2 hours looking into systemd, and trying different options, I think for now I'll just settle for putting "mount -a" in my /etc/rc.local, which seems to be working.

randoogle on 9 Feb 2016

Was this page helpful?

0 / 5 - 0 ratings