Description of problem:
A wayward process, from cron and owned by root, accidentally
managed to fill up / to 100%. This was missed before a reboot
and on a startup kudzu decided to rewrite /etc/fstab. Not entirely
independently from the preceding incident as they both were caused
by failures in controllers. The net result was that a machine
ended up with /etc/fstab of a size 0 and no other traces of the
previous fstab as there was no disk space. Very funny indeed.
(And to make things more exciting the box did not have a local
monitor and/or keyboard).
One would think that with such sensitive operation, where a failure
may render a machine rather hard to boot, a new fstab will be
written to a temporary file and only after this operation succeeded
results renamed to /etc/fstab.
This happened on an FC1 installation. If that behaviour changed
later then the merrier. I did not have an opportunity to test.
I prefer not to try. :-)
updfstab is no longer used in favor of HAL and fstab-sync. Therefore, this is
unlikely to be fixed.