search

martijnvanbrummelen / nwipe

nwipe secure disk eraser
GNU General Public License v2.0
707 stars 80 forks source link

HPA/DCO detection confusion #542

Open Perkolator opened 8 months ago

Perkolator commented 8 months ago

I have an USB 3.0 drive and nwipe shows HS? YES for the drive, but when I run the hdparm commands your previous version of the "readme.md" had

For versions prior to this, you will need to run hdparm to detect and if necessary correct the reported size of the disc prior to using nwipe. sudo hdparm -N /dev/sdx and sudo hdparm --dco-identify /dev/sdx. The three sector values returned should all be identical for there to be no hidden sectors on the disc. xxxxxxxxxx / yyyyyyyyyy as returned by hdparm -N and Real max sectors = zzzzzzzzzz as returned by hdparm --dco-identify.

all the sector values are the same.

hdparm -N reports: max sectors = 7814037168/7814037168, HPA is disabled

hdparm --dco-identify reports: Real max sectors: 7814037168

I don't understand deeply what this HPA/DCO thing is, but I'd like to erase drives completely.

Any idea why nwipe says that there are hidden sectors but hdparm doesn't?

Nwipe does not currently allow removal of the HPA/DCO so you will still need to use hdparm to reset the drive so it reports its correct size before using nwipe to wipe the drive.

How does that happen with hdparm?

Perkolator commented 8 months ago

Forgot to mention that the USB drive is encrypted and has got only 1 "partition" (according to GParted and lsblk (latter shows only as a "disk")), in case that has anything to do with this problem.

PartialVolume commented 8 months ago

Can you post the nwipe log, thanks.

Perkolator commented 8 months ago

Can you post the nwipe log, thanks.

Thanks for the fast reply. What log is that? I haven't wiped anything yet.

PartialVolume commented 8 months ago

You don't need to wipe anything, just control C it exit nwipe, then ALT F2 to switch to the 2nd virtual terminal, ls will display the / directory contents. There will be a file called nwipexxxxxxx. If you more that and take a photo. If you prefer to anonymize the serial no. Etc at the prompt run nwipe -q, once it's displayed the selection just control c to exit, there will be a 2nd nwipe log with serial numbers replaced with xxxxxx.

Perkolator commented 8 months ago

There's no "nwipexxxxxxx" files, ls shows only "packages-list.txt", "packages-size.txt" and "version" files.

However, exiting nwipe, it outputs text to tty1, same where nwipe was started/exited. Could not get the full text, but luckily the problematic /dev/sdc is shown:

nwipe

PartialVolume commented 8 months ago

Interesting, can you post the output of sudo fdisk -l /dev/sdc thanks.

Perkolator commented 8 months ago

nwipe2

PartialVolume commented 8 months ago

Thanks, looks like you have discovered a bug.

Nwipe reporting HS = yes, is incorrect in this case. The reason for the error is that the HPA and DCO are being reported as 512 byte sectors, by both hdparm and nwipe's own HPA/DCO functions, but libata is reporting the number of sectors as 4096 byte sectors for both physical and logical which results in the number of sectors being 8 times less. 976754646 * 8 = 7814037168.

I'll submit a patch over the next couple of days to fix this. I think all my drives report physical/logical as 512/512 although I do have a encrypted device it also reports physical/logical sector size as 512 so would not show this bug and correctly reports HS status.

Thank you for reporting this. That is much appreciated.

Perkolator commented 8 months ago

Ok. Thanks. Good to know, now I can start wiping the drive, no need to manipulate the drive with hdparm (which I don't know how to). :)

PartialVolume commented 8 months ago

Can you post a link from Amazon/Ebay where I can get hold of the exact same device you have. I don't think any of the hardware I have reports as 4096/4096 so it would be handy to have for testing.

Are you able to build from source? I might need you to test the patched version if you have some spare time.

Perkolator commented 8 months ago

Can you post a link from Amazon/Ebay where I can get hold of the exact same device you have.

It's an old drive, I don't think you could get it anymore, unless someone sells it used.. I think. Can't even remember where I bought it.

EDIT: Is it not possible to format a drive and manually select sector sizes?

Are you able to build from source?

Well... I really haven't done that much, only once (RHash) and although there were only few commands, I had to google/learn a lot so I could get it working (the github page didn't have that great instructions.. IIRC, it was rather outdated info). I'm running Linux Mint 20.3 Cinnamon (I have that also in a VirtualBox machine, so I could easily play with it without damaging my host system). But the biggest problem is that how am I going to get the test build to run on my old laptop with USB stick? I'm now running nwipe that is included in the SystemRescue ISO, which I'm starting from a Ventoy "formatted" USB stick (can boot basically any ISO file). If you can figure out a (relatively) easy way for me to test, sure I can test it for you, no problem. I really wouldn't like to play with building on my main laptop (might need to install a lot of packages.. and not sure if even compatible packages are available.. that happened to me with some other software I was trying to build (in same OS in VirtualBox)).

Perkolator commented 8 months ago

EDIT: Is it not possible to format a drive and manually select sector sizes?

hdparm ?:

--set-sector-size
              For drives which support reconfiguring of the Logical Sector Size, this flag can be
              used to specify the new desired sector size in bytes.  VERY  DANGEROUS.  This  most
              likely will scramble all data on the drive.  The specified size must be one of 512,
              520, 528, 4096, 4160, or 4224.  Very few drives support values other than  512  and
              4096.  Eg.  hdparm --set-sector-size 4096 /dev/sdb
PartialVolume commented 8 months ago

I've just tried a WD & a Seagate EXOS drive with that command, both unfortunately fail with the error READ_LOG_EXT(SECTOR_CONFIGURATION) failed: No such file or directory

Not to worry, I'm sure somebody out there has a drive that reports logical/physical as 4096, the important part of that for this discussion is that logical reads 4096.

I can still work on the patch in the meantime.

PartialVolume commented 8 months ago

Fixed by #543 Please Note. Anybody that has access to a 4096/4096 logical/physical drive I would be grateful if you could test that it correctly detects a disc with and without hidden sectors, the procedure for doing this is as described in the comments to #543

Perkolator commented 8 months ago

Not to worry, I'm sure somebody out there has a drive that reports logical/physical as 4096

I hope somebody could chip in, sorry that I couldn't help more.

Perkolator commented 7 months ago

Hey, I got the repo master compiled (hopefully ok) in a virtualbox machine and now I can test the USB drive with the patch.

sudo hdparm -N /dev/sdb

/dev/sdb:
 max sectors   = 7814037168/7814037168, HPA is disabled

sudo hdparm --dco-identify /dev/sdb

/dev/sdb:
DCO Checksum verified.
DCO Revision: 0x0002
The following features can be selectively disabled via DCO:
    Transfer modes:
         mdma0 mdma1 mdma2
         udma0 udma1 udma2 udma3 udma4 udma5 udma6
    Real max sectors: 18446744072933654192
    ATA command/feature sets:
         SMART self_test error_log security PUIS HPA
         FUA selective_test conveyance_test
         WRITE_UNC_EXT
    SATA command/feature sets:
         interface_power_management SSP

I don't understand why the sector count is now different.

sudo fdisk -l /dev/sdb

Disk /dev/sdb: 3,65 TiB, 4000787030016 bytes, 976754646 sectors
Disk model: USB 3.0 device  
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

nwipe 0.35.6: [ ] /dev/sdb USB [4000 GB] [--C] [HS? NO ] Intenso USB 3.0 device/XXXXXXXXXXXXXXX

& output after quitting (including vbox hdd, etc., all info):

..modprobe: FATAL: Module drivetemp not found in directory /lib/modules/5.4.0-156-generic
[2024/02/09 14:50:39]    info: Nwipes config file /etc/nwipe/nwipe.conf exists
[2024/02/09 14:50:39]    info: Reading nwipe's config file /etc/nwipe/nwipe.conf
[2024/02/09 14:50:39]    info: Sucessfully written nwipe config to /etc/nwipe/nwipe.conf
[2024/02/09 14:50:39]    info: Nwipes customer file /etc/nwipe/nwipe_customers.csv exists
[2024/02/09 14:50:39]    info: nwipe 0.35.6
[2024/02/09 14:50:39]    info: Linux version 5.4.0-156-generic (buildd@lcy02-am
                               d64-078) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubun
                               tu1~20.04.1)) #173-Ubuntu SMP Tue Jul 11 07:25:
                               22 UTC 2023
[2024/02/09 14:50:39]  notice: Found /dev/sda,  ATA-SSD, VBOX HARDDISK,   21 GB, S/N=XXXXXXXXXXXXXXX
[2024/02/09 14:50:40]   error: SG_IO bad/missing sense data hdparm --verbose -N /dev/sda 2>&1

[2024/02/09 14:50:40] warning: [UNKNOWN] We can't find the HPA line, has hdparm ouput unknown/changed? /dev/sda
[2024/02/09 14:50:40]    info: hdparm:DCO Real max sectors reported as 1 on /dev/sda
[2024/02/09 14:50:40]    info: NWipe: DCO Real max sectors reported as 1 on /dev/sda
[2024/02/09 14:50:40]    info: libata: apparent max sectors reported as 41943040 with sector size as 0/512 on /dev/sda
[2024/02/09 14:50:40]    info: func:nwipe_read_dco_real_max_sectors(), DCO real max sectors = 0
[2024/02/09 14:50:40]    info:  
[2024/02/09 14:50:40]  notice: Found /dev/sdb,  USB    , Intenso USB 3.0 device, 4000 GB, S/N=XXXXXXXXXXXXXXX
[2024/02/09 14:50:40]    info: HPA:  max sectors   = 7814037168/7814037168, hpa is disabled
 on /dev/sdb
[2024/02/09 14:50:40]    info: HPA values 7814037168 / 7814037168 on /dev/sdb
[2024/02/09 14:50:40]    info: hdparm:DCO Real max sectors reported as -1 on /dev/sdb
[2024/02/09 14:50:40]    info: func:nwipe_read_dco_real_max_sectors(), DCO real max sectors = 7814037168
[2024/02/09 14:50:40]    info: NWipe: DCO Real max sectors reported as 7814037168 on /dev/sdb
[2024/02/09 14:50:40]    info: libata: apparent max sectors reported as 976754646 with sector size as 0/4096 on /dev/sdb
[2024/02/09 14:50:40]    info: No hidden sectors on /dev/sdb
[2024/02/09 14:50:40]    info: func:nwipe_read_dco_real_max_sectors(), DCO real max sectors = 7814037168
[2024/02/09 14:50:40]    info:  
[2024/02/09 14:50:40]    info: Automatically enumerated 2 devices.
[2024/02/09 14:50:40]    info: bios-version = VirtualBox
[2024/02/09 14:50:40]    info: bios-release-date = 12/01/2006
[2024/02/09 14:50:40]    info: system-manufacturer = innotek GmbH
[2024/02/09 14:50:40]    info: system-product-name = VirtualBox
[2024/02/09 14:50:40]    info: system-version = 1.2
[2024/02/09 14:50:40]    info: system-serial-number = XXXXXXXXXXXXXXX
[2024/02/09 14:50:40]    info: system-uuid = XXXXXXXXXXXXXXX
[2024/02/09 14:50:40]    info: baseboard-manufacturer = Oracle Corporation
[2024/02/09 14:50:40]    info: baseboard-product-name = VirtualBox
[2024/02/09 14:50:40]    info: baseboard-version = 1.2
[2024/02/09 14:50:40]    info: baseboard-serial-number = XXXXXXXXXXXXXXX
[2024/02/09 14:50:40]    info: baseboard-asset-tag = XXXXXXXXXXXXXXX
[2024/02/09 14:50:40]    info: chassis-manufacturer = Oracle Corporation
[2024/02/09 14:50:40]    info: chassis-type = Other
[2024/02/09 14:50:40]    info: chassis-version = Not Specified
[2024/02/09 14:50:40]    info: chassis-serial-number = XXXXXXXXXXXXXXX
[2024/02/09 14:50:40]    info: chassis-asset-tag = XXXXXXXXXXXXXXX
[2024/02/09 14:50:40]  notice: Opened entropy source '/dev/urandom'.
[2024/02/09 14:50:40] warning: hwmon: Unable to load module drivetemp, temperatures may be unavailable.
[2024/02/09 14:50:40] warning: hwmon: It's possible the drivetemp software isn't modular but built-in
[2024/02/09 14:50:40] warning: hwmon: to the kernel, as is the case with ShredOS.x86_64 in which case
[2024/02/09 14:50:40] warning: hwmon: the temperatures will actually be available despite this issue.
[2024/02/09 14:50:40]    info: Temperature limits for /dev/sda, critical=N/A, max=N/A, highest=N/A, lowest=N/A, min=N/A, low critical=N/A. 
[2024/02/09 14:50:40]    info: Temperature limits for /dev/sdb, critical=N/A, max=N/A, highest=N/A, lowest=N/A, min=N/A, low critical=N/A. 
[2024/02/09 14:51:49]    info: Nwipe was aborted by the user prior to the wipe starting.

I don't understand why some of the data is now different, maybe something went wrong with the building of nwipe?

Anyhoo, if you have any further questions/instructions, I'm waiting here. :)

P.S. I'm currently wiping 2 USB drives on my old laptop and one of them just finished but the other one is still going at ~50%; can I disconnect the already ready USB drive while the other one still has approximately 55 hours to go?

PartialVolume commented 7 months ago

P.S. I'm currently wiping 2 USB drives on my old laptop and one of them just finished but the other one is still going at ~50%; can I disconnect the already ready USB drive while the other one still has approximately 55 hours to go?

Yes, it's ok to pull the finished USB.

I'll take a closer look at the output you posted and let you know. I can see something that's not quite correct in the line libata: apparent max sectors reported as 976754646 with sector size as 0/4096 on /dev/sdb, in regards to the 0/4096. I was expecting either 512/4096 or 4096/4096 but not 0/4096, so that's something I need to look at. Those numbers are provided by libata. I'll get back to you shortly.

PartialVolume commented 7 months ago

I have a request. When you get a chance can you plug in the 4096 (4kn) Intenso USB 3.0 4000 GB USB device and start nwipe with the verbose option. sudo nwipe -v. You also might want to specify the log file so the log text gets saved as it may be fairly long. So the command would be sudo nwipe -v --logfile=nwipelog.txt.

You don't need to run a wipe, just start nwipe with the above command and then control C to exit. The log will be displayed in stdout and also written to nwipelog.txt. Can you post nwipelog.txt. Thanks.

Perkolator commented 7 months ago

I can see something that's not quite correct in the line libata: apparent max sectors reported as 976754646 with sector size as 0/4096 on /dev/sdb, in regards to the 0/4096.

Noticed that the info: hdparm:DCO Real max sectors reported as -1 on /dev/sdb is also different to my first screenshot taken from the old laptop running nwipe. Maybe it's an older version of the software installed from the ubuntu repos (Linux Mint 20.3 / Ubuntu Focal 20.04)? Could that's also why libata is getting wrong data? Purely guessing though..

I'll try your request next.

Perkolator commented 7 months ago

Here's the log. It's from the virtualbox machine (which itself might not work ok, the USB "passthrough" might produce errors).

nwipelog.txt

I noticed that the smartctl says 512 bytes logical, 4096 bytes physical, while fdisk says it's 4096 bytes / 4096 bytes. I checked the drive with smartctl in my host OS and it still says the same 512 bytes logical, 4096 bytes physical, so I guess virtual machine doesn't at least mess that up.

I just actually realized that my old laptop, I have same Linux Mint 20.x installed on it (kind of forgot it since I haven't used it in a long while). I can test the drive/nwipe with only that, no virtual environments, no SystemRescue USB boot with Ventoy (which had a small problem; I couldn't see the SystemRescue boot menu and couldn't load it into memory (I wanted to remove my Ventoy boot USB stick after booting)). I'll just take a snapshot with a Timeshift and then compile nwipe and try the USB drive there. BUT, I'll have to wait until the wiping ends for the remaining one USB drive. Takes a few days, so maybe on Monday/Tuesday(?) I'll report back. But in the meantime I can test with the virtualbox machine if you want.

PartialVolume commented 7 months ago

Takes a few days, so maybe on Monday/Tuesday(?) I'll report back.

No problem, I think I've found an issue with the soft block size being initialised once the drive/s for wiping have been selected and the wipe started, where as HPA/DCO determination is conducted prior to this, so I need to make a change to the code over the next few days. I'll let you know when there is a revised version 0.35.7 for downloading & compiling.

Perkolator commented 7 months ago

Hey, I just noticed (from an old smartctl log I had) that my 2TB USB drive (the last one now being wiped), smartctl reports sectors as 512 bytes logical, 4096 bytes physical, but nwipe 0.35 didn't incorrectly report that it might have hidden sectors. I can post all info about this drive on Monday/Tuesday as well if you want.

PartialVolume commented 7 months ago

Hey, I just noticed (from an old smartctl log I had) that my 2TB USB drive (the last one now being wiped), smartctl reports sectors as 512 bytes logical, 4096 bytes physical, but nwipe 0.35 didn't incorrectly report that it might have hidden sectors. I can post all info about this drive on Monday/Tuesday as well if you want.

That's ok, I believe 512 logical and 4096 physical is working ok, as is 512 logical and 512 physical, it's only 4096 logical and 4096 physical that has an issue.

ggruber commented 7 months ago

as for exotic disks: I have a SMR currently wiping, some more on the shelf (had been bought by accident not realising that "archive disk" was a code for "shingled magenetic recoding". Started with apparently normal data rates (~150MB/s), but now at 64.43% (round 1 of 1, pass 3 of 3) (very short blanking, long syncing) the data rate lowered to 104MB/s

It is a ST8000AS0002. Had hoped to find it 4kn, but the drive reports 512e. The data sheet https://www.seagate.com/files/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/archive-hdd-dS1834-3-1411us.pdf doesn't say much about this.

PartialVolume commented 7 months ago

Well you learn something new everyday. I'd never heard of "Shingled magnetic recording" until I just googled it.

Perkolator commented 7 months ago

I'll let you know when there is a revised version 0.35.7 for downloading & compiling.

Just making sure that I understood correctly; I was supposed to wait for the new version before doing anything?

PartialVolume commented 7 months ago

Just making sure that I understood correctly; I was supposed to wait for the new version before doing anything?

Yes, sorry I forgot to bump the minor version. You can now download the master (0.35.7) and give that a try.

Perkolator commented 7 months ago

Yes, sorry I forgot to bump the minor version. You can now download the master (0.35.7) and give that a try.

Hmm, you only updated the version number? I thought you wanted to change some actual code.

I think I've found an issue with the soft block size being initialised once the drive/s for wiping have been selected and the wipe started, where as HPA/DCO determination is conducted prior to this, so I need to make a change to the code over the next few days.

PartialVolume commented 7 months ago

I did, look at the previous commit.

PartialVolume commented 7 months ago

I did, look at the previous commit.

Ignore that, you are perfectly correct there was one other change I wanted to make. Hold fire with that testing, it will be 0.35.8 ! Apologies.

PartialVolume commented 7 months ago

@ggruber Do you have a 512/4096 drive on your server I could test with, maybe a smaller EXOS ? After a few changes I've made in 0.35.8 I want to check the logical/physical is being reported correctly in the logs and then I'll do a zeros wipe with verification. Would that be possible?

PartialVolume commented 7 months ago

@ggruber like that ST8000AS0002 should be fine.

PartialVolume commented 7 months ago

@Perkolator Master (0.35.8) is ready for download & testing.

If you plug that encrypted USB disk in that shows as 4096/4096 and start nwipe --logfile=nwipe_log1.txt, check the title is 0.35.8 and that the USB drives shows up in the drive selection window, you can then either control-C to abort and post the nwipe log or if you want to test fully do a zeros wipe + verification, no blanking pass and post the log. Thanks. In the meantime I'm hoping I can run a wipe on ggruber's server as well.

ggruber commented 7 months ago

@PartialVolume I will be able to take the one ST8000AS0002 with me that's currently being wiped (from @work to my homelab) when the wipe processed is finished. Or: I take some more from the shelf (this was a unintentional puchase) to the homelab. Then I could mount them in the 3,5" wipebox, together with an "normal" 6TB Exos drive (ST6000NM0115), also 512e. I also have 4TB SAS drives available, 3 ok, 1 with reallocated sectors, all ~6yo. Choose 8 disks and I will mount them available for you this evening.

Perkolator commented 7 months ago 
$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 3,65 TiB, 4000787030016 bytes, 976754646 sectors
Disk model: USB 3.0 device  
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 268431360 bytes
$ sudo hdparm -N /dev/sdb

/dev/sdb:
 max sectors   = 7814037168/7814037168, HPA is disabled
$ sudo hdparm --dco-identify /dev/sdb

/dev/sdb:
DCO Checksum verified.
DCO Revision: 0x0002
The following features can be selectively disabled via DCO:
    Transfer modes:
         mdma0 mdma1 mdma2
         udma0 udma1 udma2 udma3 udma4 udma5 udma6
    Real max sectors: 18446744072933654192
    ATA command/feature sets:
         SMART self_test error_log security PUIS HPA
         FUA selective_test conveyance_test
         WRITE_UNC_EXT
    SATA command/feature sets:
         interface_power_management SSP

nwipe:

[    ] /dev/sdb  USB     [4000 GB] [--C] [HS? NO ] Intenso USB 3.0 device/XXXXXXXXXXXXXXX

Zeros wipe + verification, no blanking pass: nwipe_log.txt

For some reason hdparm --dco-identify still gives weird sectors 18446744072933654192. My first post to this topic shows different sectors from the same command (ran hdparm & nwipe from SystemRescue booted with Ventoy).

PartialVolume commented 7 months ago

@Perkolator Thanks for the detail, much appreciated.

For some reason hdparm --dco-identify still gives weird sectors 18446744072933654192. My first post to this topic shows different sectors from the same command (ran hdparm & nwipe from SystemRescue booted with Ventoy).

There is a bug in hdparm 9.60, including possibly earlier or later versions but which is fixed in 9.65, that returns an incorrect (negative) value displayed as a very large positive number for some drives that are possibly over a certain size.

I wrote a low level function in nwipe that retrieves the DCO and correctly interprets it. My guess is you are running the version of hdparm that is between 9.60 and 9.64. The latest version of ShredOS is running hdparm v9.65 so will show the correct number of sectors with the --dco-identify command.

Looking at the nwipe log, it all looks correct, apart from one thing (which isn't an nwipe issue). As you can see hdparm incorrectly reports real max sectors as -1 hdparm:DCO Real max sectors reported as -1 on /dev/sdb , but nwipe's own function correctly obtains the real max sectors as 7814037168 [2024/02/16 02:04:12] info: func:nwipe_read_dco_real_max_sectors(), DCO real max sectors = 7814037168

[2024/02/16 02:04:12]    info: HPA values 7814037168 / 7814037168 on /dev/sdb
[2024/02/16 02:04:12]    info: hdparm:DCO Real max sectors reported as -1 on /dev/sdb
[2024/02/16 02:04:12]    info: func:nwipe_read_dco_real_max_sectors(), DCO real max sectors = 7814037168
[2024/02/16 02:04:12]    info: NWipe: DCO Real max sectors reported as 7814037168 on /dev/sdb
[2024/02/16 02:04:12]    info: libata: apparent max sectors reported as 976754646 with sector size as 4096/4096 (logical/physical) on /dev/sdb
[2024/02/16 02:04:12]    info: No hidden sectors on /dev/sdb
[2024/02/16 02:04:12]    info: func:nwipe_read_dco_real_max_sectors(), DCO real max sectors = 7814037168

So in summary it all looks as i would expect.

PartialVolume commented 7 months ago

@Perkolator oh, and of course the logical/physical sizes are reported correctly as 4096/4096 [2024/02/16 02:04:12] info: /dev/sdb, sector(logical)/block(physical) sizes 4096/4096

Found /dev/sdb,  USB    , Intenso USB 3.0 device, 4000 GB, S/N=XXXXXXXXXXXXXXX
[2024/02/16 02:04:12]    info: /dev/sdb, sector(logical)/block(physical) sizes 4096/4096
[2024/02/16 02:04:12]    info: HPA:  max sectors   = 7814037168/7814037168, hpa is disabled

and nwipe reports no hidden sectors which is as expected.

It would be nice to create a hidden sector on that device using hdparm which would then show that nwipe positively detects it. I'll leave it up to you whether you want to try that :-)

sudo hdparm -N p7814037160 /dev/sdb (assuming the drive is sdb) will reduce the size by 8 sectors. Power cycle the drive after making the change by unplugging it and plugging back in.

nwipe should report hidden sectors, in the certificate it will report 8 hidden sectors or 4096 bytes hidden.

Perkolator commented 7 months ago

My guess is you are running the version of hdparm that is between 9.60 and 9.64.

It's actually 9.58 (Linux Mint 20.3 (Ubuntu focal 20.04)), but anyways I'm happy that it's not affecting your testing of this stuff. :)

sudo hdparm -N p7814037160 /dev/sdb (assuming the drive is sdb) will reduce the size by 8 sectors. Power cycle the drive after making the change by unplugging it and plugging back in.

nwipe should report hidden sectors, in the certificate it will report 8 hidden sectors or 4096 bytes hidden.

What certificate? The PDF report?

I did as you instructed and I see these (ignored the incorrect hdparm:DCO):

info: HPA: max sectors = 7814037160/7814037168, hpa is disabled (8 sectors hidden) info: HPA values 7814037160 / 7814037168 on /dev/sdb (8 sectors hidden) info: func:nwipe_read_dco_real_max_sectors(), DCO real max sectors = 7814037168 (correct) info: NWipe: DCO Real max sectors reported as 7814037168 on /dev/sdb (correct) info: libata: apparent max sectors reported as 976754645 with sector size as 4096/4096 (logical/physical) on /dev/sdb (I guess this ok too, the number is only 1 lower... 8 x 976754645 = 7814037160)

And nwipe (GUI and log output after exit) shows hidden sectors detected. All seems to be ok. Anything else you'd want me to test or do I get to dismantle my test bench? :)

ggruber commented 7 months ago

@PartialVolume I have four ST8000AS0002 in the 3,5" wipebox, together with an "normal" 6TB Exos drive (ST6000NM0115), also 512e. Another 4TB SATA, 4TB SAS, 2TB SATA

PartialVolume commented 7 months ago

@Perkolator Looks good, thanks again, your help is much appreciated.

PartialVolume commented 7 months ago

@Perkolator

It's actually 9.58 (Linux Mint 20.3 (Ubuntu focal 20.04))

That bug in hdparm goes back a little further than I thought.

What certificate? The PDF report?

Yes, the PDF report. Sometimes I call it a certificate, other times a report. I don't need it BTW, it's just worth checking that it recorded the fact there were hidden sectors.

PartialVolume commented 7 months ago

@ggruber

@PartialVolume I have four ST8000AS0002 in the 3,5" wipebox, together with an "normal" 6TB Exos drive (ST6000NM0115), also 512e. Another 4TB SATA, 4TB SAS, 2TB SATA

Thanks, I need to make a minor commit to the code and then I'll start a wipe on these some time tomorrow.