Description of problem: hdparm's "secure erase" feature fails to erase LVM name information from the drive. following the execution of hdparm with the --security-erase parameter, the secure erase process appears to proceed normally, exits with a success report. when anaconda is run on the drives to perform a new install and LVM is selected, anaconda finds the old LVM names that were on the hard disk before secure erase was performed. the secure erase failed to erase the LVM name information. Version-Release number of selected component (if applicable): hdparm-9.43-5.fc20.x86_64 How reproducible: very. Steps to Reproduce: 1. hdparm --user-master u --security-set-pass $password /dev/sdX 2. hdparm --user-master u --security-erase $password /dev/sdX 3. run anaconda to install F20 on drive 4. observe that anaconda finds the LVM volume name information from the previous install, in spite of performance of --security-erase in previous step Actual results: Anaconda displays LVM information from pervious install in spite of secure-erase being performed on disk. Expected results: secure erase Additional info: WDC WD800 SATA hard disk.
Did you remove logical volume and volume group from the device before wiping it out with hdparm? I suspect that LVM and device-mapper might come into play here. Once you reboot your machine, device-mapper may want to make sure that device remembers what logical volume it belongs to. Running just hdparm --security-erase would be safe on kernel without device-mapper/lvm support.
> Did you remove logical volume and volume group from the device before wiping it out with hdparm? No, I did not manually remove the vg or the logical volume from the device. I issued the secure-erase command as root, prior to "discarding" the drive from the system. My understanding is that the secure-erase command causes the device to throw away the encryption key that is used internally, replacing it with another one, which renders the entire drive, including partition tables, as unreadable. But that didn't happen here. If secure-erase actually changes the encryption key, then it would be unnecessary to manually edit logical volumes and volume groups, as the entire drive is being wiped. In this case it doesn't look like the encryption key was actually discarded and replaced, because the data was still readable when the drive was "discarded" and placed into another system. > I suspect that LVM and device-mapper might come into play here. Does secure-erase erase the data on the disk or not? If it does, then why should LVM or device-mapper even matter? > Once you reboot your machine, device-mapper may want to make sure that device remembers what logical volume it belongs to. Not applicable. The physical drive was in use as the primary OS disk on Machine A. Prior to being discarded, it was secure-erased on Machine A. It was then carried over to Machine B for the new install. Machine B was booted from a Fedora install CD, and Anaconda found the volume names on the drive that existed on the drive during it's employment on Machine A. This information was supposed to be purged by the successfully completed secure-erase operation but it was not. This is not about LVM information surviving a reboot when disks remain in a PC. This is about information remaining on a drive that is "discarded", and it is about data being found on a drive that is secure-erased and "discarded" when it's placed into another system. Machine B had *NOTHING* in common with Machine A. It was a brand-new motherboard being booted from an install CD, using a drive from Machine A that was purportedly secure-erased. The fact that the Install CD found data on the disk after it was successfully secure-erased tells us one thing -- secure erase does not do what it claims to do, even when it issues a success error code. It would appear that the encryption key wasn't discarded/changed. If that's the case then this is a serious security problem.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. 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 '20'. 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 20 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 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.