On Fri, 18 Mar 2011 20:05:19 -0000
Scott Moser <email address hidden> wrote:
> I think it would be probably best to post this upstream and see what
> their response is. Upstream has mailing list info at [2].
i thought so too. this is what karel said: "I'm still not sure if
mount(8) is the right place to fix odd kernel behaviour. Anyway, your
patch seems like a usable workaround.
I'll try to apply the patch later (it will necessary to modify
libmount, because the library is not able to add a new entry to mtab
for MS_REMOUNT requests)."
maybe on could convince the kernel guys to think over the underlying
problem, but i don't have enough insights to do a good enough bug report
and argue with them. i skimmed through the kernel's mounting source, but
it's not as easy understandable as mount itself :)
maybe someone at canoncial could try?
On Fri, 18 Mar 2011 20:05:19 -0000
Scott Moser <email address hidden> wrote:
> I think it would be probably best to post this upstream and see what
> their response is. Upstream has mailing list info at [2].
i thought so too. this is what karel said: "I'm still not sure if
mount(8) is the right place to fix odd kernel behaviour. Anyway, your
patch seems like a usable workaround.
I'll try to apply the patch later (it will necessary to modify
libmount, because the library is not able to add a new entry to mtab
for MS_REMOUNT requests)."
http:// marc.info/ ?l=util- linux-ng& m=1298279981117 93&w=2
maybe on could convince the kernel guys to think over the underlying
problem, but i don't have enough insights to do a good enough bug report
and argue with them. i skimmed through the kernel's mounting source, but
it's not as easy understandable as mount itself :)
maybe someone at canoncial could try?
--
lg, ameno