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. How reproducible: I prefer not to try. :-)
updfstab is no longer used in favor of HAL and fstab-sync. Therefore, this is unlikely to be fixed.