New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

/etc/fstab down't work with RPI2 #824

Closed
pirulloz opened this Issue Feb 11, 2015 · 43 comments

Comments

Projects
None yet
@pirulloz

pirulloz commented Feb 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@notro

notro Feb 11, 2015

Contributor

It does at least mount nfs for me on RPI2:

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

notro commented Feb 11, 2015

It does at least mount nfs for me on RPI2:

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

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Feb 11, 2015

Collaborator

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

@notro any guesses?

Collaborator

popcornmix commented Feb 11, 2015

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

@notro any guesses?

@pirulloz

This comment has been minimized.

Show comment
Hide comment
@pirulloz

pirulloz Feb 11, 2015

Yes, with 3.18.6+ on RPI1 it works good.

pirulloz commented Feb 11, 2015

Yes, with 3.18.6+ on RPI1 it works good.

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Feb 11, 2015

Collaborator

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

Collaborator

popcornmix commented Feb 11, 2015

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

@pirulloz

This comment has been minimized.

Show comment
Hide comment
@pirulloz

pirulloz Feb 11, 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 commented Feb 11, 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

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Feb 11, 2015

Collaborator

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

Collaborator

popcornmix commented Feb 11, 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...

@pirulloz

This comment has been minimized.

Show comment
Hide comment
@pirulloz

pirulloz Feb 11, 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 commented Feb 11, 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.....

@notro

This comment has been minimized.

Show comment
Hide comment
Contributor

notro commented Feb 11, 2015

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Feb 11, 2015

Collaborator

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

Collaborator

popcornmix commented Feb 11, 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)

@lekkerduidelijk

This comment has been minimized.

Show comment
Hide comment
@lekkerduidelijk

lekkerduidelijk Feb 11, 2015

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

lekkerduidelijk commented Feb 11, 2015

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

@pirulloz

This comment has been minimized.

Show comment
Hide comment
@pirulloz

pirulloz Feb 11, 2015

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

pirulloz commented Feb 11, 2015

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

@keithellis74

This comment has been minimized.

Show comment
Hide comment
@keithellis74

keithellis74 Feb 15, 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 commented Feb 15, 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

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Feb 16, 2015

Collaborator

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

Collaborator

popcornmix commented Feb 16, 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.

@keithellis74

This comment has been minimized.

Show comment
Hide comment
@keithellis74

keithellis74 Feb 16, 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 notifications@github.com 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 commented Feb 16, 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 notifications@github.com 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

This comment has been minimized.

Show comment
Hide comment
@keithellis74

keithellis74 Feb 17, 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 commented Feb 17, 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.

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Feb 17, 2015

Collaborator

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.

Collaborator

popcornmix commented Feb 17, 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.

@keithellis74

This comment has been minimized.

Show comment
Hide comment
@keithellis74

keithellis74 Feb 19, 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 commented Feb 19, 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.

@StevenHickson

This comment has been minimized.

Show comment
Hide comment
@StevenHickson

StevenHickson Feb 19, 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 commented Feb 19, 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

This comment has been minimized.

Show comment
Hide comment
@StevenHickson

StevenHickson Feb 26, 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 commented Feb 26, 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?

@limpygnome

This comment has been minimized.

Show comment
Hide comment
@limpygnome

limpygnome Mar 7, 2015

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

limpygnome commented Mar 7, 2015

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

@kernc

This comment has been minimized.

Show comment
Hide comment
@kernc

kernc Mar 23, 2015

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

kernc commented Mar 23, 2015

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

syntheticpp pushed a commit to syntheticpp/linux that referenced this issue Jun 2, 2015

Jiri Slaby
parport: parport_pc, do not remove parent devices early
commit 91905b6 upstream.

When the parport_pc module is removed from the system, all parport
devices are iterated in parport_pc_exit and removed by a call to
parport_pc_unregister_port. Note that some parport devices have its
'struct device' parent, known as port->dev.  And when port->dev is a
platform device, it is destroyed in parport_pc_exit too.

Now, when parport_pc_unregister_port is called for a going port,
drv->detach(port) is called for every parport driver in the system.
ppdev can be one of them. ppdev's detach() tears down its per-port
sysfs directory, which established port->dev as a parent earlier.

But since parport_pc_exit kills port->dev parents before unregisters
ports proper, ppdev's sysfs directory has no living parent anymore.
This results in the following warning:

WARNING: CPU: 1 PID: 785 at fs/sysfs/group.c:219 sysfs_remove_group+0x9b/0xa0
sysfs group ffffffff81c69e20 not found for kobject 'parport1'
Modules linked in: parport_pc(E-) ppdev(E) [last unloaded: ppdev]
CPU: 1 PID: 785 Comm: rmmod Tainted: G        W   E  3.18.0-rc5-next-20141120+ #824
...
Call Trace:
...
 [<ffffffff810aff76>] warn_slowpath_fmt+0x46/0x50
 [<ffffffff8123d81b>] sysfs_remove_group+0x9b/0xa0
 [<ffffffff814c27e7>] dpm_sysfs_remove+0x57/0x60
 [<ffffffff814b6ac9>] device_del+0x49/0x240
 [<ffffffff814b6ce2>] device_unregister+0x22/0x70
 [<ffffffff814b6dac>] device_destroy+0x3c/0x50
 [<ffffffffc012209a>] pp_detach+0x4a/0x60 [ppdev]
 [<ffffffff814b32dd>] parport_remove_port+0x11d/0x150
 [<ffffffffc0137328>] parport_pc_unregister_port+0x28/0xf0 [parport_pc]
 [<ffffffffc0138c0e>] parport_pc_exit+0x76/0x468 [parport_pc]
 [<ffffffff81128dbc>] SyS_delete_module+0x18c/0x230

It is also easily reproducible on qemu with two dummy ports '-parallel
/dev/null -parallel /dev/null'.

So switch the order of killing the two structures. But since port is
freed by parport_pc_unregister_port, we have to remember port->dev
in a local variable.

Perhaps nothing worse than the warning happens thanks to the device
refcounting. We *should* be on the safe side.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Martin Pluskal <mpluskal@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
@natbon

This comment has been minimized.

Show comment
Hide comment
@natbon

natbon Jun 10, 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 commented Jun 10, 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,

@Darkhand81

This comment has been minimized.

Show comment
Hide comment
@Darkhand81

Darkhand81 Jun 17, 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 commented Jun 17, 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.

@DavidCWGA

This comment has been minimized.

Show comment
Hide comment
@DavidCWGA

DavidCWGA Aug 7, 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 commented Aug 7, 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

This comment has been minimized.

Show comment
Hide comment
@lathoub

lathoub Aug 8, 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 commented Aug 8, 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

This comment has been minimized.

Show comment
Hide comment
@DavidCWGA

DavidCWGA Aug 9, 2015

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

DavidCWGA commented Aug 9, 2015

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

@lathoub

This comment has been minimized.

Show comment
Hide comment
@lathoub

lathoub Aug 9, 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 commented Aug 9, 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+

@andre-dierker

This comment has been minimized.

Show comment
Hide comment
@andre-dierker

andre-dierker Sep 21, 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 commented Sep 21, 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

@DavidCWGA

This comment has been minimized.

Show comment
Hide comment
@DavidCWGA

DavidCWGA Sep 21, 2015

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

DavidCWGA commented Sep 21, 2015

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

@andre-dierker

This comment has been minimized.

Show comment
Hide comment
@andre-dierker

andre-dierker Sep 21, 2015

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

andre-dierker commented Sep 21, 2015

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

@andre-dierker

This comment has been minimized.

Show comment
Hide comment
@andre-dierker

andre-dierker Sep 21, 2015

NFS4 requires idmapd, did you configured it right?

andre-dierker commented Sep 21, 2015

NFS4 requires idmapd, did you configured it right?

@luispablo

This comment has been minimized.

Show comment
Hide comment
@luispablo

luispablo Sep 25, 2015

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

luispablo commented Sep 25, 2015

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

@luispablo

This comment has been minimized.

Show comment
Hide comment
@luispablo

luispablo Sep 26, 2015

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

luispablo commented Sep 26, 2015

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

@IntellixWeb

This comment has been minimized.

Show comment
Hide comment
@IntellixWeb

IntellixWeb Oct 29, 2015

usbmount did the trick for me too. Thanks @luispablo

IntellixWeb commented Oct 29, 2015

usbmount did the trick for me too. Thanks @luispablo

@popcornmix

This comment has been minimized.

Show comment
Hide comment
@popcornmix

popcornmix Oct 29, 2015

Collaborator

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

Collaborator

popcornmix commented Oct 29, 2015

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

@afspear

This comment has been minimized.

Show comment
Hide comment
@afspear

afspear Jan 29, 2016

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 commented Jan 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@DavidCWGA

DavidCWGA Jan 29, 2016

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

DavidCWGA commented Jan 29, 2016

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

@afspear

This comment has been minimized.

Show comment
Hide comment
@afspear

afspear Jan 29, 2016

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

afspear commented Jan 29, 2016

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

@DavidCWGA

This comment has been minimized.

Show comment
Hide comment
@DavidCWGA

DavidCWGA Jan 29, 2016

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

DavidCWGA commented Jan 29, 2016

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

@popcornmix popcornmix closed this Jan 29, 2016

@randoogle

This comment has been minimized.

Show comment
Hide comment
@randoogle

randoogle Feb 8, 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 commented Feb 8, 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

@DavidCWGA

This comment has been minimized.

Show comment
Hide comment
@DavidCWGA

DavidCWGA Feb 8, 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 commented Feb 8, 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.

@ziesemer

This comment has been minimized.

Show comment
Hide comment
@ziesemer

ziesemer Feb 8, 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 commented Feb 8, 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.

@randoogle

This comment has been minimized.

Show comment
Hide comment
@randoogle

randoogle Feb 9, 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 commented Feb 9, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment