From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020913
Description of problem:
fdisk change the file system during the following procedure: call `fdisk' then
press `p' to see the partition table and after that press `q' to quit fdisk
without saving anything. Then make an fsck over all partitions on the device
from which you had a look at the partition table. In an not so heavy matter fsck
can repair the file systems without any lost of your data. In an very heavy case
the superblock might be corrupted. fsck can repair your file system, but as in
my case the following system directories were moved to lost+found and got
numbers instead of file names: /bin, /etc, /lib, /root, /usr and all
subdirectories of these.
I observed these behavior of fdisk on different computers every time when I do
the above described procedure.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. command `fdisk'
2. then press `p' to see the partition table
3. press `q' to quit without saving
4. run `fsck'
Actual Results: fsck finds different file system errors until corrupted
Expected Results: no change for the file system
My guess is that you are doing an fsck on mounted filesystems and that the fdisk
has nothing to do with it. Am I right?
No, the fsck is only to see that fdisk with the above steps to reproduce has
made changes to the file system. If you perform `fdisk' with the 3 steps
everthing seems to be okay. But after fdisk you run fsck on that disk to see
that there was something wrong.
What happens if you run the fsck's without doing the fdisk?
Fdisk is the problem. To get the error do the following:
1. run `fdisk'
2. while you are in fdisk press `p' to see the partition table
3. press `q' to quit fdisk
4. reboot your system
Be carefull to see what happens during the boot of your system. You should be
enforced to check the filesystem.
This bug is kind of old (for which I apologize, since it's my fault)
and I don't have any good ideas on fixing it since I can't reproduce
it. It's also against RHL 7.2, suggesting that there's a good chance
it has since been fixed. If you can reproduce with FC2 or RHEL3,
please re-open the bug by all means.