Bug 127840 - kudzu destroy fstab down to a zero length
Summary: kudzu destroy fstab down to a zero length
Alias: None
Product: Fedora
Classification: Fedora
Component: kudzu (Show other bugs)
(Show other bugs)
Version: 1
Hardware: All Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-14 15:50 UTC by Michal Jaegermann
Modified: 2014-03-17 02:46 UTC (History)
2 users (show)

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

Attachments (Terms of Use)

Description Michal Jaegermann 2004-07-14 15:50:46 UTC
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 18:32:20 UTC
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.