Hi Maximilian,
On Wed, Jul 23, 2008 at 11:39:39AM +0200, maximilian attems wrote:
> On Wed, Jul 23, 2008 at 11:24:49AM +0200, Karel Zak wrote:
> > On Wed, Jul 23, 2008 at 04:43:30AM -0400, Christoph Hellwig wrote:
> > > On Wed, Jul 23, 2008 at 10:39:38AM +0200, maximilian attems wrote:
> > > > klibc mount has only short options thus uses the following syntax
> >
> > Frankly, it seems like a klibc problem...
>
> well not directly, but right klibc-utils should have proper syntax.
> initramfs-tools currently uses belows syntax. before we unmounted
> and remounted, which is much uglier.
>
> or even better have the util-linux-ng mount compiled against klibc,
this is the best solution and it's in our TODO for more than one
year. But nobody works on that...
If you create some restricted and incompatible environment (e.g.
"only short options") you shouldn't expect that standard system utils
are ready to blindly follow this your decision.
BTW, I don't understand what is bad on long options. Any idea?
> a hook script (live-initramfs) seems to add util-linux-ng mount
> for cifs support and thus belows error came to sight.
>
> > > > to move a mounted tree:
> > > > mount -o move /sys /root/sys
> > > >
> > > > this generates the following error on util-linux-ng mount:
> > > > mount: you must specify the filesystem type
> > > >
> > > > belows patch is enough to add an alternative to
> > > > mount --move /olddir /newdir
> > >
> > > Please don't. Overloading -o for bind mounts initially was a really bad
> > > idea already. -o should be reserved to filesystem options.
> >
> > Right. Unfortunately, we already have more exceptions ;-(
> >
> > -o {remount,bind,rbind,owner,noowner,groups,nogroups,_netdev,
> > comment,loop}
>
> so they are all getting deprecated?
No. The reason why we support these options is /etc/fstab (the "-o"
is a command line alternative to /etc/fstab mount options).
The "move" is unsupported in /etc/fstab.
--
Karel Zak <kzak@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
