HPA_DCO_013 Continuation of HPA/DCO integration

[PartialVolume]

Fixes to apparent and real disc size fields in PDF based on use of c->Calculated_real_max_size_in_bytes.

Minor changes to HPA status messages for consistent messaging.

When HPA and DCO sector information cannot be obtained display the message "HPA/DCO data unavailable, can not determine hidden sector status" in the information field on the PDF.

Determine human readable size for the c->Calculated_real_max_size_in_bytes as used in the PDF real disc size field.

Instead of >>FAILURE!<< -1 when a I/O error occurs display >>IOERROR!<< -1 in the GUI.

[PartialVolume]

@mdcato v0.34.85 is now available for testing. I've hopefully fixed all the issues I'm aware of, I've tested with a mix of IDE and SATA on USB and so far getting the expected values in all the fields on the PDF. But as usual more testing is required also on SATA and IDE

I also fixed the issue that occurred when you abort a wipe on a multi disc erase when one disc has already completed. Prior to this fix all drives would have been marked as aborted. Now only the drives that have not completed their wipe will show as 'aborted', those that completed succesfully will show as erased in the nwipe log and on the PDFs.

I also discovered a issue on some old circa 2000-2005 maxdor and Quantum drives where the drive model and serial number endian is returned incorrectly by libata, so a Quantum Fireball model would appear as uQnaut m iFerablle. I can fix this in nwipe for these particular models so the text and serial numbers appear correctly.

[mdcato]

I’ve started a new run with 0.34.86 (you mentioned 0.34.85 below, but getting from the Master reports .86). Previous run had the issues you listed so no point in uploading results from it. Since you mentioned Quantum, I have a Quantum Bigfoot TX ca.1998 4—12GB 5.25” with IBM markings that I kept for nostalgia, but given it’s age I’m reluctant to power it up.

From: PartialVolume @.> Sent: Wednesday, April 12, 2023 18:02 To: martijnvanbrummelen/nwipe @.> Cc: Mike Cato / Hays Technical Services @.>; Mention @.> Subject: Re: [martijnvanbrummelen/nwipe] HPA_DCO_013 Continuation of HPA/DCO integration (PR #465)

@mdcatohttps://github.com/mdcato v0.34.85 is now available for testing. I've hopefully fixed all the issues I'm aware of, I've tested with a mix of IDE and SATA on USB and so far getting the expected values in all the fields on the PDF. But as usual more testing is required also on SATA and IDE

I also fixed the issue that occurred when you abort a wipe on a multi disc erase when one disc has already completed. Prior to this fix all drives would have been marked as aborted. Now only the drives that have not completed their wipe will show as 'aborted', those that completed succesfully will show as erased in the nwipe log and on the PDFs.

I also discovered a issue on some old circa 2000-2005 maxdor and Quantum drives where the drive model and serial number endian is returned incorrectly by libdata, so a Quantum Fireball model would appear as uQnaut m iFerablle. I can fix this in nwipe for these particular models so the text and serial numbers appear correctly.

— Reply to this email directly, view it on GitHubhttps://github.com/martijnvanbrummelen/nwipe/pull/465#issuecomment-1506075102, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANGK2PW3QW4AM3EWYFPBQ2TXA4X4XANCNFSM6AAAAAAW4JBPEA. You are receiving this because you were mentioned.Message ID: @.**@.>>

[PartialVolume]

you mentioned 0.34.85 below, but getting from the Master reports .86)

Yes, my mistake .86 it is.

I have a bunch of old SCSI drives from Sun based systems 9GB and 18GB & some old Codonics printer (Sun based) drives which I think may be even smaller. Some of these drives have issues but despite the fact they are 25+ years old others still wipe with no errors. I have a SCSI controller in a PC with various SCSI interface adapters and nwipe every so often gets to wipe one of these old drives.

Funny to think I have Seagate drives that are 25 years old that wipe just fine with no errors and 2 x 10TB Seagate drives that are barely 2 years old, one just about works with lots of head hunting and noise and the other makes a right racket and fails to initialise. ! May be anecdotal but I sometimes wonder whether modern drives are just not as reliable as they once were.

[mdcato]

The Seagate 10TB I have is a replacement (I switched the client to a different set knowing the RMA would take time). It does the head hunting and (guessing) a total recal with sounds of “banging” back to home, and also runs at 50-58C while others stay in the 30s or low-40s. The quality of spinning drives undoubtedly went down as SSDs started taking over. I had hoped the ~10TB-class ones from Seagate and WD would be better, but they haven’t proved that to be true.

Even a new 2TB Samsung T7 Shield SSD USB-C 3.2 Gen2 gave problems when Samsung Magician reported it needed a firmware update, but the update appears to have removed the Samsung branding so now it reports the as the USB controller’s mfr (ASMedia ASM236X USB<>NVME) instead of Samsung. It still works so didn’t lose the US$140 cost, but obviously something didn’t proceed correctly, likely a left-hand/right-hand large chaebol problem. Plus it doesn’t work on my AMD Ryzen 9 5900X / Asus ROG STRIX X570-E system, but works fine on Intel based systems; I suspect a mainboard USB controller issue, but subsequent driver updates over several months haven’t changed anything.

From: PartialVolume @.> Sent: Thursday, April 13, 2023 16:45 To: martijnvanbrummelen/nwipe @.> Cc: Mike Cato / Hays Technical Services @.>; Mention @.> Subject: Re: [martijnvanbrummelen/nwipe] HPA_DCO_013 Continuation of HPA/DCO integration (PR #465)

you mentioned 0.34.85 below, but getting from the Master reports .86)

Yes, my mistake .86 it is.

I have a bunch of old SCSI drives from Sun based systems 9GB and 18GB & some old Codonics printer (Sun based) drives which I think may be even smaller. Some of these drives have issues but despite the fact they are 25+ years old others still wipe with no errors. I have a SCSI controller in a PC with various SCSI interface adapters and nwipe every so often gets to wipe one of these old drives.

Funny to think I have Seagate drives that are 25 years old that wipe just fine with no errors and 2 x 10TB Seagate drives that are barely 2 years old, one just about works with lots of head hunting and noise and the other makes a right racket and fails to initialise. ! May be anecdotal but I sometimes wonder whether modern drives are just not as reliable as they once were.

— Reply to this email directly, view it on GitHubhttps://github.com/martijnvanbrummelen/nwipe/pull/465#issuecomment-1507646259, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ANGK2PVGLK7TWWJW6FJLAD3XBBXWHANCNFSM6AAAAAAW4JBPEA. You are receiving this because you were mentioned.Message ID: @.**@.>>

[mdcato]

Here are results using #465 version 0.34.86. PDFs seem to be as you expected, with apparent/real sizes the same. nwipe-20230413.log

nwipe_report_2023-04-14-04-41-26_Model_ST10000NM0016_1T_Serial_ZA20SSAR.pdf nwipe_report_2023-04-13-19-47-45_Model_ST4000VN008_2DR1_Serial_ZGY1DA5C.pdf nwipe_report_2023-04-13-20-36-39_Model_ST4000NM0033_9ZM_Serial_Z1Z7NVF7.pdf

[PartialVolume]

That's excellent, thanks.

So next on the list:

1. Complete PDFs by adding /etc/nwipe.conf so that organisation & tech info can be retrieved from this conf file and displayed in the PDF.
2. Add secure erase method.
3. Add restore DCO/HPA method (i.e expose hidden sectors to the O.S. so they can be wiped)
4. Decide whether to do a custom hack to provide UEFI on iso or probably the better option although more time consuming, due to the driver checks I need to do,. upgrade to latest buildroot that now supports hybrid UEFI and bios boot methods for .iso with isolinux for bios and grub2 for UEFI.