the mount command behaves incorrectly

[jduck]

The traditional way to remount a filesystem is with:

# mount -o remount,rw /mountpoint

However this does not work in toybox.

There is a workaround, though.

# mount -o rw,remount /mountpoint

Any thoughts as to why the "correct" way doesn't work? You can find the "remount,rw" ordering in tons of documentation, yet it doesn't work in toybox.

[landley]

On 09/17/2016 02:39 AM, Joshua J. Drake wrote:

The traditional way to remount a filesystem is with:

|# mount -o remount,rw /mountpoint |

However this does not work in toybox.

There is a workaround, though.

|# mount -o rw,remount /mountpoint |

blink blink That should totally not matter. If it does, it's a
bug. (You didn't say what "does not work" means in this context, lemme
see what I can dig up...)

Any thoughts as to why the "correct" way doesn't work? You can find the
"remount,rw" ordering in tons of documentation, yet it doesn't work in
toybox.

That would be a bug. The fact that remount doesn't work without an
absolute path is also a bug. Hmmm...

(I haven't put together a proper mount test suite yet because it
requires root access and a known host environment, meaning it's gated by
a dependency on a qemu-based test environment, which is gated on my
taking my aboriginal linux project apart and putting it back together
again as described on that list. Working on it. But mostly I have to get
back to Austin and a decent work environment again so my development
bandwidth for these projects isn't so severely constrained...)

Rob

[enh]

another report of this bug today: android/ndk#380 (comment)

[landley]

On 07/10/2017 02:56 PM, Elliott Hughes wrote: another report of this bug today: android/ndk#380 (comment) <android/ndk#380 (comment)>

Blah. Sorry about the delay. (The underfunded startup I work at can't afford to replace people it lost over the past year, so the rest of us gained more plates to spin. Very distracting. Yes, I am catching up on this at 4am.) The simple fix is: - remount = (void *)(long)comma_scan(opts, "remount", 1); + remount = (void *)(long)comma_scan(opts, "remount", 0); The problem is if comma_scan removes "remount" from the option string during early parsing (setting the "remount" flag that changes the behavior to do /proc/mounts lookup to find existing flags to delta against), then we never set the remount flag when collecting the set of flags to apply as a delta, meaning it tries to do a _new_ mount over the existing mount, which either gives you -EBUSY or stacks a new mount on top of the old mount (for tmpfs). The deeper question is "why the heck does rw,remount work then"? And the answer is that comma_scan() is failing to remove entries that match at the end of the list. (Ok, fixed. And that _failure_ is why it passed my initial testing way back when. Sigh...) Hmmm... if /proc/filesystems says that a filesystem type is nodev, I don't _have_ to require two arguments to mount it. I.E. there's no reason: mount -t tmpfs sub Can't work? Try the fstab lookup first, but if it's not there just use basename of sub as the device? Hmmm... that works for tmpfs, ramfs, and devtmpfs, and ntfs claims to need a device, but cifs and fuse are nodev and I'm pretty sure they care. (Use the "device" field as other info). Meanwhile the insane v9fs expects the address to live in the options as special arguments in the csv, because IBM. Sigh... (I need to write nfsmount, cifsmount, and v9fsmount commands. For two of those I could even do a reasonable server. It's on the todo list. But not at this time of morning. :) Rob

[enh]

i think this was fixed by d4adb3f and can now be closed.