OpenWrt Forum Archive

Topic: [FIXED] automatic mount at boot

The content of this topic has been archived on 5 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi all.
I have attached an USB storage device to my OpenWRT box running "Barrier Breaker r41302".
I have successfully installed a few needed extra packages:

# opkg install kmod-usb-storage-extras kmod-fs-xfs xfs-fsck usbutils block-mount
# rm /bin/mount /bin/umount
# opkg install mount-utils mountd

Then in System-->Mount Points-->Mount Points and System-->Mount Points-->SWAP in the LuCI web UI I have added the relevant entries with the usual "Save & Apply".
Finally in System-->Startup I have enabled and started both the mountd and the fstab entry.
Once I double checked everything I rebooted the OpenWRT box.
While the SWAP entry has been take into account (as shown by both Status-->Overview and by "free" in the CLI), the Mount Point entry is being ignored.
In the CLI I can successfully mount that device with the very same parameters defined in the web UI.
What am I missing here? Any hint?
TIA.

UPDATE
This issue has a workaround, not really a fix. See post no.8

(Last edited by uqbar on 23 Jun 2014, 21:54)

post the output of

uci show fstab

and

dmesg

(Last edited by tmo26 on 23 Jun 2014, 18:46)

Here it is:

fstab.@global[0]=global
fstab.@global[0].anon_swap=0
fstab.@global[0].anon_mount=0
fstab.@global[0].auto_swap=1
fstab.@global[0].auto_mount=1
fstab.@global[0].delay_root=5
fstab.@global[0].check_fs=0
fstab.@swap[0]=swap
fstab.@swap[0].enabled=1
fstab.@swap[0].device=/dev/sda1
fstab.@mount[0]=mount
fstab.@mount[0].device=/dev/sda2
fstab.@mount[0].target=/overlay/NOA/mnt
fstab.@mount[0].fstype=xfs
fstab.@mount[0].enabled=1

By the way, where can I find a comprehensive documentation for uci as used in OpenWRT?

Have you tried mounting by label or UUID?

Have you tried mounting it to /NOA/mnt instead of /overlay/NOA/mnt ?

Your dmesg output could give some deeper insights.

Post the output of

opkg list-installed kmod-usb*

About uci: see http://wiki.openwrt.org/doc/uci

(Last edited by tmo26 on 23 Jun 2014, 19:03)

[    7.832689] SGI XFS with security attributes, large block/inode numbers, no debug enabled
[    7.850283] SCSI subsystem initialized
[    7.858910] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[    7.865404] scsi0 : usb-storage 1-1.2:1.0
[    7.870239] usbcore: registered new interface driver usb-storage
[    8.869914] scsi 0:0:0:0: Direct-Access     WD       5000BEV External 1.75 PQ: 0 ANSI: 4
[    8.898856] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
[    8.916694] sd 0:0:0:0: [sda] Write Protect is off
[    8.921526] sd 0:0:0:0: [sda] Mode Sense: 23 00 00 00
[    8.938273] sd 0:0:0:0: [sda] No Caching mode page found
[    8.943629] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    8.979457] sd 0:0:0:0: [sda] No Caching mode page found
[    8.984805] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    9.036065]  sda: sda1 sda2
[    9.065098] sd 0:0:0:0: [sda] No Caching mode page found
[    9.070440] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    9.076550] sd 0:0:0:0: [sda] Attached SCSI disk
[    9.924790] Adding 1048572k swap on /dev/sda1.  Priority:-1 extents:1 across:1048572k 

While

# blkid 
/dev/mtdblock3: TYPE="squashfs" 
/dev/sda1: LABEL="NOA-BT-SWAP" UUID="4f1d59e8-b101-40eb-9a4d-4a271a8b5ea3" TYPE="swap" PARTUUID="00228267-01" 
/dev/sda2: LABEL="NOA-BT-DATA" UUID="772569e3-3a1d-4852-87e8-567809922395" TYPE="xfs" PARTUUID="00228267-02"
# opkg list-installed kmod-usb*
kmod-usb-core - 3.10.36-1
kmod-usb-printer - 3.10.36-1
kmod-usb-storage - 3.10.36-1
kmod-usb-storage-extras - 3.10.36-1
kmod-usb2 - 3.10.36-1
kmod-usb2-fsl - 3.10.36-1

Remeber that a manual mount works just fine!
I don't expect a mount by UUID to work any better than mount by device. I'll give that a try, though.

(Last edited by uqbar on 23 Jun 2014, 19:13)

I changed the mount entry to UUID:

# uci show fstab
fstab.@global[0]=global
fstab.@global[0].anon_swap=0
fstab.@global[0].anon_mount=0
fstab.@global[0].auto_swap=1
fstab.@global[0].auto_mount=1
fstab.@global[0].delay_root=5
fstab.@global[0].check_fs=0
fstab.@swap[0]=swap
fstab.@swap[0].enabled=1
fstab.@swap[0].device=/dev/sda1
fstab.@mount[0]=mount
fstab.@mount[0].target=/overlay/NOA/mnt
fstab.@mount[0].fstype=xfs
fstab.@mount[0].enabled=1
fstab.@mount[0].uuid=772569e3-3a1d-4852-87e8-567809922395

And rebooted too. No change in the behaviour.

I also mounted under /NOA/mnt instead of /overlay/NOA/mnt.
As expected, no news from this move.
I start suspecting than this "automount thing" is not working at all, as the manual mount command goes fine.
One request, tmo26: please post a real reply instead of re-editing your last post, otherwise I won't get any email notification.

FIXED!
mountd/automount only supports ext3 and ext4 (and probably squashfs).
I have no idea why, but as soon as I reformatted the storage to ext4 and reconfigured the mountpoint from the web UI, everything worked fine!
I also forwarded an enhancement ticket to devs in order to support also XFS (and possibly other FSs).

Why do you remove mount and umount? What do you need mountd and mount-utils for? Automatic mounting at boot doesn't require them.

Default mount and umount commands are symlinks to busybox and have a simplified (and minimal) behavior. For example, the original one is:

# ls -l /bin/*mount
lrwxrwxrwx    1 root     root             7 Mar 23  2013 /bin/mount -> busybox
lrwxrwxrwx    1 root     root             7 Mar 23  2013 /bin/umount -> busybox
# mount --help
BusyBox v1.19.4 (2013-03-14 11:28:31 UTC) multi-call binary.

Usage: mount [OPTIONS] [-o OPTS] DEVICE NODE

Mount a filesystem. Filesystem autodetection requires /proc.

        -a              Mount all filesystems in fstab
        -i              Don't run mount helper
        -r              Read-only mount
        -w              Read-write mount (default)
        -t FSTYPE       Filesystem type
        -O OPT          Mount only filesystems with option OPT (-a only)
-o OPT:
        loop            Ignored (loop devices are autodetected)
        [a]sync         Writes are [a]synchronous
        [no]atime       Disable/enable updates to inode access times
        [no]diratime    Disable/enable atime updates to directories
        [no]relatime    Disable/enable atime updates relative to modification time
        [no]dev         (Dis)allow use of special device files
        [no]exec        (Dis)allow use of executable files
        [no]suid        (Dis)allow set-user-id-root programs
        [r]shared       Convert [recursively] to a shared subtree
        [r]slave        Convert [recursively] to a slave subtree
        [r]private      Convert [recursively] to a private subtree
        [un]bindable    Make mount point [un]able to be bind mounted
        [r]bind         Bind a file or directory [recursively] to another location
        move            Relocate an existing mount point
        remount         Remount a mounted filesystem, changing flags
        ro/rw           Same as -r/-w

There are filesystem-specific -o flags.

while the full blown binaries are:

# ls -l /usr/bin/*mount
-rwxr-xr-x    1 root     root         26040 Jun 22 22:45 /usr/bin/mount
-rwxr-xr-x    1 root     root         17328 Jun 22 22:45 /usr/bin/umount
# mount --help

Usage:
 mount [-lhV]
 mount -a [options]
 mount [options] [--source] <source> | [--target] <directory>
 mount [options] <source> <directory>
 mount <operation> <mountpoint> [<target>]

Options:
 -a, --all               mount all filesystems mentioned in fstab
 -c, --no-canonicalize   don't canonicalize paths
 -f, --fake              dry run; skip the mount(2) syscall
 -F, --fork              fork off for each device (use with -a)
 -T, --fstab <path>      alternative file to /etc/fstab
 -h, --help              display this help text and exit
 -i, --internal-only     don't call the mount.<type> helpers
 -l, --show-labels       lists all mounts with LABELs
 -n, --no-mtab           don't write to /etc/mtab
 -o, --options <list>    comma-separated list of mount options
 -O, --test-opts <list>  limit the set of filesystems (use with -a)
 -r, --read-only         mount the filesystem read-only (same as -o ro)
 -t, --types <list>      limit the set of filesystem types
     --source <src>      explicitly specifies source (path, label, uuid)
     --target <target>   explicitly specifies mountpoint
 -v, --verbose           say what is being done
 -V, --version           display version information and exit
 -w, --rw, --read-write  mount the filesystem read-write (default)

 -h, --help     display this help and exit
 -V, --version  output version information and exit

Source:
 -L, --label <label>     synonym for LABEL=<label>
 -U, --uuid <uuid>       synonym for UUID=<uuid>
 LABEL=<label>           specifies device by filesystem label
 UUID=<uuid>             specifies device by filesystem UUID
 PARTLABEL=<label>       specifies device by partition label
 PARTUUID=<uuid>         specifies device by partition UUID
 <device>                specifies device by path
 <directory>             mountpoint for bind mounts (see --bind/rbind)
 <file>                  regular file for loopdev setup

Operations:
 -B, --bind              mount a subtree somewhere else (same as -o bind)
 -M, --move              move a subtree to some other place
 -R, --rbind             mount a subtree and all submounts somewhere else
 --make-shared           mark a subtree as shared
 --make-slave            mark a subtree as slave
 --make-private          mark a subtree as private
 --make-unbindable       mark a subtree as unbindable
 --make-rshared          recursively mark a whole subtree as shared
 --make-rslave           recursively mark a whole subtree as slave
 --make-rprivate         recursively mark a whole subtree as private
 --make-runbindable      recursively mark a whole subtree as unbindable

For more details see mount(8).

I for one prefer the real ones, but you can test with the busybox ones.

Ok, but I imagine mountd might interfere with the built-in automount.

I am not sure, but I would bet that mountd simply calls mount/umount or links libmount.

uqbar wrote:

FIXED!
mountd/automount only supports ext3 and ext4 (and probably squashfs).
I have no idea why, but as soon as I reformatted the storage to ext4 and reconfigured the mountpoint from the web UI, everything worked fine!
I also forwarded an enhancement ticket to devs in order to support also XFS (and possibly other FSs).

The enhancement ticket will likely be closed. see http://wiki.openwrt.org/doc/devel/bugs#invalid.tickets

Supporting only a small subset keeps the size of OpenWrt down.
Contrary to your statement of "widespread" XFS I don't think it is used that much - and lately there are other developments with BTRFS or ZFS.
All these filesystems are probably only running nice on x86/x86-64 arch in OpenWrt, while default packages should handle all arch or most of them.

Are there any numbers about used filesystems (vfat,ntfs,ext2..4,btrfs, xfs ...) beside analysing things like # installed OS ?
With Windows 8.1 probably exfat might be more widespread ...

zloop wrote:

The enhancement ticket will likely be closed. see http://wiki.openwrt.org/doc/devel/bugs#invalid.tickets

Supporting only a small subset keeps the size of OpenWrt down.

This is why we love the packaged software in OpenWRT. You can install only the bits you need. I don't fully understand (surely my fault) why other filesystems than EXT3/EXT4 are not supported, though.

zloop wrote:

Contrary to your statement of "widespread" XFS I don't think it is used that much - and lately there are other developments with BTRFS or ZFS.

Go to phoronix.com and look for XFS-related articles. You'll find some news.
Also RedHat has some information about XFS.
In the years XFS has proven to be among the most reliable and effective filesystems in the Linux world.

zloop wrote:

All these filesystems are probably only running nice on x86/x86-64 arch in OpenWrt, while default packages should handle all arch or most of them.

"Probably"? This sounds like assumptions at best. Any facts?
Why do you think EXT3/EXT4 or even VFAT/ExFAT can be multiarch while XFS is x86 related? XFS has been developed by SGI originally for their RISC-based IRIX.

zloop wrote:

Are there any numbers about used filesystems (vfat,ntfs,ext2..4,btrfs, xfs ...) beside analyzing things like # installed OS ?

How could anyone know this? There is no way to know without a survey. 

zloop wrote:

With Windows 8.1 probably exfat might be more widespread ...

If the storage is managed by a Linux box I would ensure the filesystem is handled in the best possible way, as far as effectiveness, efficiency, reliability and performance.
I don't think EXFAT matches. EXT4 and XFS do.
Other machines would use it through the network as SMB or NFS thus making the actual (local) filesystem choice irrelevant.

uqbar wrote:
zloop wrote:

The enhancement ticket will likely be closed. see http://wiki.openwrt.org/doc/devel/bugs#invalid.tickets

Supporting only a small subset keeps the size of OpenWrt down.

This is why we love the packaged software in OpenWRT. You can install only the bits you need. I don't fully understand (surely my fault) why other filesystems than EXT3/EXT4 are not supported, though.

Because supporting it makes the package bigger.

uqbar wrote:
zloop wrote:

Are there any numbers about used filesystems (vfat,ntfs,ext2..4,btrfs, xfs ...) beside analyzing things like # installed OS ?

How could anyone know this? There is no way to know without a survey.

Lots of people have done surveys.

uqbar wrote:
zloop wrote:

With Windows 8.1 probably exfat might be more widespread ...

If the storage is managed by a Linux box I would ensure the filesystem is handled in the best possible way, as far as effectiveness, efficiency, reliability and performance.
I don't think EXFAT matches. EXT4 and XFS do.
Other machines would use it through the network as SMB or NFS thus making the actual (local) filesystem choice irrelevant.

Yeah but most external storage will be formatted as Exfat out of the box and lots of people will keep it that way in order to maintain its portability to a Windows machine.

(Last edited by qasdfdsaq on 25 Jun 2014, 18:07)

The discussion might have continued from here.