Bug 127840 - kudzu destroy fstab down to a zero length
kudzu destroy fstab down to a zero length
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-14 11:50 EDT by Michal Jaegermann
Modified: 2014-03-16 22:46 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-28 14:32:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2004-07-14 11:50:46 EDT
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. :-)
Comment 1 Bill Nottingham 2005-04-28 14:32:20 EDT
updfstab is no longer used in favor of HAL and fstab-sync. Therefore, this is
unlikely to be fixed.

Note You need to log in before you can comment on or make changes to this bug.