Dear Fedora, FC 26 I spent endless hours till 06:00 in the morning yesterday recovering a customers Fedora server. For details on what happened, see: https://bugzilla.redhat.com/show_bug.cgi?id=1483279 So anyway, I had to switch back and forth from XFS to EXT4 and on and on and so forth. Very many times, gparted was useless as it could not get rid of an old file system, especially XFS. You think yo had it in EXT4 and it mounts, accepts data, once, then the next time you mount it, it is back to XFS. erase everyting with gparted and Fedora 26's installer says there is an "unknown partition" it can't erase. (Press the "-" button, it acts like it fixed it, and it comes right back.) No, I am not making this up. The guys over at linux-xfs.org confirmed that "I have seen blkid get confused when there was files that contained an xfs filesystem and xfs external log in the beginning of the filesystem (things that we basically do for testing)." So, I had to use one of the following workarounds to get a clean disk: 1) dd /dev/zero over the front of the drive. (did not always work) 2) dd /dev/zero over the entire drive (always worked, but took FOREVER) 3) In bios, throw the drive into an RSTe raid pair, which blanks the drive, then break it from the pair. (always worked). 4) wipefs, which was spotty if the drive was weird. (If you look at bug 1483279, my drives got pretty weird at times) So, that said, REQUEST FOR ENHANCEMENT: put an option in gparted to nuke a drive back to factory blank. And come up with something like #3 above which was really fast, not #2 above as it takes forever.
> The guys over at linux-xfs.org confirmed that "I have seen blkid get confused when there was files that contained an xfs filesystem and xfs external log in the beginning of the filesystem (things that we basically do for testing)." No, we did not confirm that. It's a completely separate issue, unrelated to your described behavior.
GParted already clears file system signatures before creating new file systems to ensure that previous file system signatures can't be detected. (Approximately it writes 512K of zero at the start and end of the partition. This is reported as "clear old file system signatures in /dev/PTN" step in the operation details. See https://git.gnome.org/browse/gparted/tree/src/GParted_Core.cc?h=GPARTED_0_29_0#n3788 for full details). Clearing a partition is directly exposed to the user via: (Select partition) > Format to > cleared Once all the partitions have been cleared no tool should recognise any file system. If this is not the case please provide step by step instructions on how to create the situation and I will look into it. Thanks, Mike Fleetwood (GParted Developer)
Hi Mike, In order to reproduce it, I would have to crash a production level server. > Once all the partitions have been cleared no tool should recognise any file system. This presumes that everything in correctly formatted on the drive. This was not the case after https://bugzilla.redhat.com/show_bug.cgi?id=1483279 crashed my OS drive. I am not after for to change a correctly formatted drive. What I am looking for is a catastrophic blank out of all the bad tables, bad formats, bad block IDs, GPT tables beginning and end, etc.. Something similar to "dd /dev/zero", only quick. RSTe's RAID bios tool does this in an instant when you switch from regular to raid and back (requires two disks). Basically, I want to "nuke the drive!" and make it usable again without having to jump through flaming hoops. Many thanks, -T
This from Carlos over on linux-xfs.org: It is a known issue with gparted that when you reformat a partition or disk with something else, it doesn't properly erase at least the critical areas of the previous filesystem, causing problems. One that has been noticed more than once at openSUSE is this: - 'dd' a CD image on an USB stick for operating system installation. For instance, openSUSE-Leap-42.2-NET-x86_64.iso install disk. - Afterwards, use gparted to remove partitions on the stick, create a new partition, format it as FAT32 (with a label). Tumbleweed (at some version) thought the USB to still be a CD (printing its old label) and failed to mount it (because it is FAT). The code detecting filesystem type had to be changed on Tumbleweed, but the cause of the issue is that gparted did not erase the areas at the start of the disk with that information, and the FAT format did not write on them. So this is not a problem with XFS, but a problem caused by gparted (feature needed). You have to manually destroy key areas manually, probably just a few sectors at partition start.
Todd, you need to actually identify what happened here, and not ask for impossible/magical "like dd, but quick!" features based on anecdotes. Mike told you that gparted /does/ wipe signatures. I told you that mkfs.ext4 /does/ wipe signatures. I'll tell you now that mkfs.xfs does the same - it zeros from 0 to 128k before it starts. > You have to manually destroy key areas manually, probably just a few sectors at partition start. Mike explained to you in comment #2 that it /does that/ today. You need to show us a reproducible test case to demonstrate that the above behavior is somehow missing filesystem signatures and allowing misidentification. You should not need to "crash a production server" to do this.
See comment #4. Carlos gave you instructions on how to reproduce.
With isofs on a whole disk, not a partition. That is not your bug.
(In reply to Eric Sandeen from comment #7) > With isofs on a whole disk, not a partition. That is not your bug. Exactly. That is what I am after. Nuke the whole stinking thing so I can starft over fresh.
(In reply to Eric Sandeen from comment #5) > Todd, you need to actually identify what happened here, and not ask for > impossible/magical "like dd, but quick!" features based on anecdotes. > > You need to show us a reproducible test case to demonstrate that the above > behavior is somehow missing filesystem signatures and allowing > misidentification. You should not need to "crash a production server" to do > this. Here is a second way to reproduce this. See the directions over on: https://bugzilla.opensuse.org/show_bug.cgi?id=1046096 (In reply to Eric Sandeen from comment #5) > With isofs on a whole disk, not a partition. That is not your bug. Please excuse the misunderstanding. I am not trying to troubleshoot a bug. I want a option to nuke the entire drive. Not just a partition. And I am not after help troubleshooting the issues I detailed in comment #1. I only put so much detail there to justify the need for the RFE, which was "put an option in gparted to nuke a drive back to factory blank". Between Carlos comments in #4 and the above opensuse bug, you should have enough detail to reproduce and test this RFE. If not, I will look for some more.
(In reply to Todd from comment #3) > What I am looking for is a catastrophic blank out of all the bad tables, bad > formats, bad block IDs, GPT tables beginning and end, etc.. Something > similar to "dd /dev/zero", only quick. RSTe's RAID bios tool does this in > an instant when you switch from regular to raid and back (requires two > disks). Simply use GParted to create a new partition table over the top of an existing hard drive. It applies the same zeroing described above in comment #2 but at the whole disk level before writing the new partition table. This clears the GPT table at the start and end of the hard drive before writing a new partition table.
(In reply to Todd from comment #4) > - 'dd' a CD image on an USB stick for operating system installation. For > instance, openSUSE-Leap-42.2-NET-x86_64.iso install disk. > > - Afterwards, use gparted to remove partitions on the stick, create a new > partition, format it as FAT32 (with a label). (In reply to Todd from comment #9) > Here is a second way to reproduce this. See the directions over on: > https://bugzilla.opensuse.org/show_bug.cgi?id=1046096 From GParted 0.28.0 onwards (released 14-Feb-2017) it reports a whole disk ISO9660 file system when an ISO image has been copied on to a USB key or other disk, rather than presenting the udev/kernel/libparted identified msdos table and embedded partitions. As the above details demonstrate treating an ISO9660 image like an msdos partition table doesn't work.
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '26'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 26 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.