I've reconsidered this, and I think it really is a problem with umount.
Although in the general case `umount -a -n' should never be necessary, there
are exceptional cases where the root filesystem is remounted read-only *after*
/etc/mtab has been updated with other mounts.
I think it's probably be
Did you check that the umount (without the -n flag) actually works?
Shutting it up can be a disaster on a large system.
Simon
P.S. Please ignore the below address and flame [EMAIL PROTECTED]
He receives and answers mail :-)
Simon Shapiro Bullet Techno
> I believe the flag may indeed be unnecessary; the source for umount indicates
> it will not attempt to update /etc/mtab when unmounting the root partition,
> regardless of its read/write status, because the partition ends up being
> remounted read-only by the kernel anyway.
That's a good feature
> -umount -a -n
> +umount -a
This may be a "umount" bug. When you unmount the root filesystem, it is
actually the same as remounting it read-only because of special-case code
in the kernel. Umount will attempt to change /etc/mtab to match the un-mount
of root, and will fail because /etc/mtab is no
> Package: sysvinit
> Version: 2.57b-0
>
> Package: mount
> Version: 2.5-1
>
> I'm not sure which package this reports belong to.
>
> The new umount (from mount-2.5-1) does not have a '-n' option.
> This option is used by some of the scripts from the sysvutils package.
I believe the flag may indee
Package: sysvinit
Version: 2.57b-0
Package: mount
Version: 2.5-1
I'm not sure which package this reports belong to.
The new umount (from mount-2.5-1) does not have a '-n' option.
This option is used by some of the scripts from the sysvutils package.
If this is a sysvinit bug, it is fixed by the
6 matches
Mail list logo
