/etc/fstab down't work with RPI2

[pirulloz]

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

[notro]

It does at least mount nfs for me on RPI2:

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

[popcornmix]

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

@notro any guesses?

[pirulloz]

Yes, with 3.18.6+ on RPI1 it works good.

[popcornmix]

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

[pirulloz]

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

[popcornmix]

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

[pirulloz]

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

[notro]

Similar issue: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/367782

[popcornmix]

@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)

[rutger1140]

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

[pirulloz]

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

[keithellis74]

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

[popcornmix]

@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.

[keithellis74]

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]

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.

[popcornmix]

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.

[keithellis74]

@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.

[StevenHickson]

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]

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?

[marcuscraske]

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

[kernc]

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

[natbon]

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,

[Darkhand81]

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.

[DavidCWGA]

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]

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]

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

[lathoub]

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+

[andre-dierker]

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

[DavidCWGA]

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

[andre-dierker]

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

[andre-dierker]

NFS4 requires idmapd, did you configured it right?

[luispablo]

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

[luispablo]

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

[IntellixWeb]

usbmount did the trick for me too. Thanks @luispablo

[popcornmix]

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

[afspear]

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

[DavidCWGA]

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

[afspear]

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

[DavidCWGA]

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

[randoogle]

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

[DavidCWGA]

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.

[ziesemer]

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.

[randoogle]

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.