[landley/toybox] the mount command behaves incorrectly (#49)
(too old to reply)
Rob Landley
2016-09-18 07:28:01 UTC
Raw Message
|# 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
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 Landley
2017-07-11 10:28:57 UTC
Raw Message
another report of this bug today: android-ndk/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. :)