PartialVolume / shredos.x86_64

Shredos Disk Eraser 64 bit for all Intel 64 bit processors as well as processors from AMD and other vendors which make compatible 64 bit chips. ShredOS - Secure disk erasure/wipe
Other
1.52k stars 64 forks source link

Shred OS freezing (same as in Issue #210) #213

Open Trump125532 opened 10 months ago

Trump125532 commented 10 months ago

Im having an issue here with multiple different Laptop models. Currently im trying to wipe the 512GB M.2 disk of a Fujitsu Lifebook U7410 and Shred OS just freezes after a couple of minutes (3-5m). The same issue was observerd on HP Elitebook 830 G6/G8. I tried a couple of different Shred OS releases but none seem to resolve this issue. All Laptops have an M.2 SSD. The Shred OS USB-Stick is the only thing connected to the Laptop and it doesnt matter which USB-Port I plug it in. The whole wiping process should take less than an hour, according to Shred OS's estimation and considering it crashing so early I dont think it's the USB-Controller overheating. I also opened one Laptop and there was no dust clogging the fan / heatpipes.

PartialVolume commented 10 months ago

I'm assuming you are wiping the internal M.2 drive?

What's the drive temperature reporting at the moment of the crash, if the screen is just freezing you should still be able to see the temperature. Can you take a picture.

Trump125532 commented 10 months ago

Yes i am indeed wiping the internal M.2 drive. The temperature is between 45 and 55°C. (I am currently running Shred OS on 2 Laptops, one is at 45, the other at 54)

PartialVolume commented 10 months ago

What are the make and model of the M.2 SSDs on the laptop that freezes and once frozen is the estimated time changing over say 30 mins after freeze, i.e increasing? Is the spinning character at the end of the wipe line also frozen

Trump125532 commented 10 months ago

Yes, the spinning character is also frozen and no, the estimated time doesnt change at all, I left it over night and nothing happend. The SSD is a Western Digital PC SN720 NVMe SSD with 512GB.

Trump125532 commented 10 months ago

Quick update: Somehow using ShredOS version v2021.08.2_23_x86-64_0.34 resolved this issue for one Laptop at least. I have tried using this exact version before and it didnt work. But now the Laptop with this version is almost at 50% (It has never even gone above 10%) so I'd assume that this is working now. But the other one running the newest release (ShredOS version v2023.08.2_25_x86-64_0.35) still has this issue.

PartialVolume commented 10 months ago

It can't be anything to do with SSD then as the drive and screen are operating in different threads, the time to completion would be increasing to a much larger number. Is there a disc activity light on the laptop? Was that still blinking, if yes it would indicate the graphics has hung but not the CPU. I wonder what the CPU and motherboard temperature were at the time it hung. Might have to put that on the title bar of nwipe.

Trump125532 commented 10 months ago

Unfortunately this model does not have a disc activity light. The disc was wiping at around 700MB/s. Those Laptops are "old" laptops from our company which will be given away to the employes. All that I tested with Shred OS worked perfectly fine and none of them is older than 4 years, so I would asume that they dont have any defects. This is the result of lspci: image

PartialVolume commented 10 months ago

Just thinking about what might cause this, the order is of no particular significance:

This is where telemetry would be incredibly useful because we could see at a glance by going to shredos.com and looking at the database how many systems with VGA Intel UHD hardware were wiping successfully with no issues.

Trump125532 commented 10 months ago

I have tried pretty much every availible wiping Method, but the one im using is overwriting everyting with 0s. But ShredOS version v2021.08.2_23_x86-64_0.34 did work for me over night, however ShredOS version v2023.08.2_25_x86-64_0.35 still isnt working. I think for now using the older version is fine. I did put a Laptop outside at ~10°C but it still crashed with the newest version.

PartialVolume commented 9 months ago

Added lspci output so Google can find it a bit easier.

sh-5.18 Ispci 00:00.0 Host bridge: Intel Corporation Device 9b61 (rev 0c) 00:02.0 UGA compatible controller: Intel Corporation UHD Graphics (rev 02) 00:12.0 Signal processing controller: Intel Corporation Conet Lake Thernal Subsyten 00:14.0 USB controller: Intel Corporation Device 02ed 00:14.2 RAM nenory: Intel Corporation Device 02ef 00:14.3 Network controller: Intel Corporation Wireless-AC 9462 00:15.0 Serial bus controller [0c80]: Intel Corporation Serial 10 12C Host Controller 00:15.3 Serial bus controller [0c001: Intel Corporation Device 02eb 00:16.0 Communication controller: Intel Corporation Conet Lake Management Engine Interface 00:10.0 PCI bridge: Intel Corporation Device 0218 (rev f0) 00:10.7 PCI bridge: Intel Corporation Device 02hf (rev fo) 00:14.0 PCI bridge: Intel Corporation Device 0260 (rev 10) 00:14.4 PCI bridge: Intel Corporation Device 6264 (reu (0) 00:10.0 Communication controller: Intel Corporation Device 02a8 00:10.1 Communication controller: Intel Corporation Device 0249 00:11.0 ISA bridge: Intel Corporation Device 0284 00:11.3 Audio device: Intel Corporation Device 0208 00:10.4 SMB: Intel Corporation Device 0243 00:11.5 Serial bus controller [0600]: Intel Corporation Conet Lake SPI (flash) Controller 00:11.6 Ethernet controller: Intel Corporation Ethernet Connection (10) 1219-IM 06:00.0 SD Host controller: 02 Micro, Inc. SD/MMC Card Reader Controller (rev 01) 06:00.0 Mon-Volatile nenory controller: Sandisk Corp WD Black 2018/PC SN720 HUME SSD 10:00.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge (Titan Ridge 2C 2018] (rev 06) 11:00.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge (Titan Ridge 2C 2018] (rev 06) 11:01.0 PCI bridge: Intel Corporation JHL.7540 Thunderbolt 3 Bridge (Titan Ridge 2C 20181 (rev 06) 11:02.0 PCI bridge: Intel Corporation JHL7540 Thunderbolt 3 Bridge (Titan Ridge 20 20181 (rev 06) 12:00.0 Systen peripheral: Intel Intel Corporation JHL7540 Thunderbolt 3 NHI (Titan Hidge 20 2018) (rev 06) 49:00.0 USB controller: Intel Corporation JHL7540 Thunderbolt 3 USB Controller (Titan Ridge 2C 20181 (rev 06) sh-5.18

Vadar commented 7 months ago

Hi @PartialVolume, Not wanting to hijack this thread. I am experiencing this same issue. Things noted/information:

v2023.08.2_25_x86-64_0.35

v2021.08.2_23_x86-64_0.34

Noticed UHD different version and processor gen to @Trump125532

Hardware information Multiple Dell Latitude 5500 Laptops, Variety of M.2 NVME disks including SK Hynix, WD etc. Temps when displayed are sub 70oc (Ambient Office Temp, Not in sunlight) lspci dump: ApplicationFrameHost_oBk50rccgh

Cheers, Cal

jpatry07 commented 7 months ago

I am also experiencing this issue on Lenovo X1 Carbon (multiple units, multiple gens),, intel CPU and Toshiba NVME. I ran the program from bootable USB vanilla and am doing a full DoD wipe and it freezes every time. The entire screen freezes and the only "solution" is to do a reboot but I cant get the drives wiped.

Note: Im using the latest version as I need the certificate for compliancy to regulatory authorities

lizord69 commented 6 months ago

I was experiencing the same thing but using a tower as my "disk killer". I used to be able to run 6+ drives at a time, when i upgraded to v.35 to use the PDF feature it would crash if i had more than 3 drives. Even disabling the PDF feature it would consistently freeze. I tried using a mixture of just about every setting. I tried just about everything including different motherboard, CPU, RAM, GPU vs Integrated, peripherals, sata cables, power supply, and even different USB drives. As soon as i went back to v.34 it froze once (bad drive i believe) then never again.

Specs: ASUS H270m-plus, i5-7500, 4gb 2400T, 350W PSU

I have had no issues with v.34 since reverting back. I frequently wipe 6 sata drives and 2 nvme drives simultaneously. the case i am using has two fans that i have set to run at full capacity with the drives sitting basically touching the fan. The side pannel is always off while the disk killer is running.

I just thought another input with a different approach may be helpful. :)

Sincera2024 commented 3 months ago

Hi guys,

Just wanted to chip in on this topic as I've faced the same freezing experience on over 30+ laptops.

I've used the latest version and have been successful in wiping quite a few of the old laptops (pre-2019).

The freezing started to occur on the more recent laptops with different freeze times. Specifically, Dell latitude 5300s and 5491 series with nvme M2 Micron 1100 SSD.

The freezing periods range from 3 minutes to 2 hours.

Here is the chosen wipe method I've been running: Rounds: 2 (plus blanking pass) Method: HMG IS5 Enhanced Verify: Last Pass PRNG: XORoshiro-256 Throughput around: 150 ~ 200 Mbps

Below is a log file from one of the 5491 series laptops that I was wiping which I had to forcefully turn off but somehow a log file was saved.

[2024/08/13 14:23:36] info: ShredOS v2024.02.2_26.0_x86-64_0.37 [2024/08/13 14:23:36] info: Linux version 6.6.22 (nick@nick-np5xnp6xnp7xpnp) (x86_64-buildroot-linux-gnu-gcc.br_real (Build root -g9c929fc958) 12.3.0, GNU ld (GNU Binutils ) 2.40) #2 SMP PREEMPT_DYNAMIC Mon Jun 10 23:52 :33 BST 2024 [2024/08/13 14:23:36] notice: Found /dev/sda, ATA-SSD, Micron 1100 SATA, 256 GB, S/N=18291D85DF09 [2024/08/13 14:23:36] info: /dev/sda, sector(logical)/block(physical) sizes 512/4096 [2024/08/13 14:23:36] info: HPA: max sectors = 500118192/500118192, accessible max address disabled on /dev/sda [2024/08/13 14:23:36] info: HPA values 500118192 / 500118192 on /dev/sda [2024/08/13 14:23:36] info: hdparm:DCO Real max sectors reported as 1 on /dev/sda [2024/08/13 14:23:36] info: NWipe: DCO Real max sectors reported as 1 on /dev/sda [2024/08/13 14:23:36] info: libata: apparent max sectors reported as 500118192 with sector size as 512/4096 (logical/physical) on /dev/sda [2024/08/13 14:23:36] info: No hidden sectors on /dev/sda [2024/08/13 14:23:36] info: func:nwipe_read_dco_real_max_sectors(), DCO real max sectors = 0 [2024/08/13 14:23:36] info:
[2024/08/13 14:23:36] warning: Smartctl is unable to provide smart data for /dev/sdb [2024/08/13 14:23:36] notice: Found /dev/sdb, USB , USB SanDisk 3.2Gen1, 61 GB, S/N=(S/N: unknown) [2024/08/13 14:23:36] info: /dev/sdb, sector(logical)/block(physical) sizes 512/512 [2024/08/13 14:23:36] error: SG_IO bad/missing sense data hdparm --verbose -N /dev/sdb 2>&1

[2024/08/13 14:23:36] warning: [UNKNOWN] We can't find the HPA line, has hdparm ouput unknown/changed? /dev/sdb [2024/08/13 14:23:36] info: hdparm:DCO Real max sectors reported as 1 on /dev/sdb [2024/08/13 14:23:36] info: NWipe: DCO Real max sectors reported as 1 on /dev/sdb [2024/08/13 14:23:36] info: libata: apparent max sectors reported as 120127488 with sector size as 512/512 (logical/physical) on /dev/sdb [2024/08/13 14:23:36] info: func:nwipe_read_dco_real_max_sectors(), DCO real max sectors = 0 [2024/08/13 14:23:36] info:
[2024/08/13 14:23:36] info: Automatically enumerated 2 devices. [2024/08/13 14:23:36] info: bios-version = 1.25.0 [2024/08/13 14:23:36] info: bios-release-date = 11/21/2022 [2024/08/13 14:23:36] info: system-manufacturer = Dell Inc. [2024/08/13 14:23:36] info: system-product-name = Latitude 5491 [2024/08/13 14:23:36] info: system-version = Not Specified [2024/08/13 14:23:36] info: system-serial-number = 7X00TQ2 [2024/08/13 14:23:36] info: system-uuid = 4c4c4544-0058-3010-8030-b7c04f545132 [2024/08/13 14:23:36] info: baseboard-manufacturer = Dell Inc. [2024/08/13 14:23:36] info: baseboard-product-name = 0NFNN4 [2024/08/13 14:23:36] info: baseboard-version = A00 [2024/08/13 14:23:36] info: baseboard-serial-number = /7X00TQ2/CNCMK0089100F5/ [2024/08/13 14:23:36] info: baseboard-asset-tag = Not Specified [2024/08/13 14:23:36] info: chassis-manufacturer = Dell Inc. [2024/08/13 14:23:36] info: chassis-type = Notebook [2024/08/13 14:23:36] info: chassis-version = Not Specified [2024/08/13 14:23:36] info: chassis-serial-number = 7X00TQ2 [2024/08/13 14:23:36] info: chassis-asset-tag = Not Specified [2024/08/13 14:23:36] info: processor-family = Core i5 [2024/08/13 14:23:36] info: processor-manufacturer = Intel(R) Corporation [2024/08/13 14:23:36] info: processor-version = Intel(R) Core(TM) i5-8300H CPU @ 2.30GHz [2024/08/13 14:23:36] info: processor-frequency = 3900 MHz [2024/08/13 14:23:36] notice: Opened entropy source '/dev/urandom'. [2024/08/13 14:23:36] notice: hwmon: Module drivetemp loaded, drive temperatures available [2024/08/13 14:23:36] notice: hwmon: sda has temperature monitoring [2024/08/13 14:23:36] 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/08/13 14:23:36] 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/08/14 11:06:19] info: Nwipe was aborted by the user prior to the wipe starting.

PartialVolume commented 3 months ago

@Sincera2024

Can you run smartctl -a /dev/sd[x] I'm wondering what firmware these drives have installed. See https://www.lieberbiber.de/2019/01/16/micron-ssd-1100-firmware-update/

The log you posted would have been written to the USB drive prior to the wipe starting. The full log which is stored in memory doesn't get flushed to USB until you exit nwipe with a Control C.

Do you know what the drive temperature is being reported as just prior to the freeze?

When it does freeze are you trying CONTROL C to exit nwipe?

I would probably switch ALT F2 and run a secure erase using nvme to see if that works, something like nvme format /dev/nvmeXnY --ses=2 or if its a SATA SSD use hdparm.

Also what does smartctl report as the general health of these drives, specifically

Media and Data Integrity Errors:    0
Error Information Log Entries:      1
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
PartialVolume commented 3 months ago

Just clarifying something:

You state throughput at Throughput around: 150 ~ 200 Mbps

Do you mean bits per second or bytes per second. Because if you mean bits per second that would be about 18-25 Mbytes/sec. Which is a similiar speed mentioned in the article regarding the buggy firmware.

Sincera2024 commented 3 months ago

@PartialVolume I've got one stuck right now and it was left overnight. Screenshot of the frozen state: 20240815_100155

Nothing works except to force the computer off with the power button.

This one has an NVMe SK Hynix SSD with 256GB storage.

  1. Can you run smartctl -a /dev/sd[x] I'm wondering what firmware these drives have installed:

    • Sure can.
    • Here is the screen shot: 20240815_115607
  2. Do you know what the drive temperature is being reported as just prior to the freeze?

    • Yes, it is/was showing 50C
    • Screenshot of the frozen state above.
  3. When it does freeze are you trying CONTROL C to exit nwipe?

    • Yes, however nothing happens.
    • Other than the keyboard light I haven't found anything else working.
    • Usually, I would have to force shutdown using the power button.
  4. I would probably switch ALT F2 and run a secure erase using nvme to see if that works, something like nvme format /dev/nvmeXnY --ses=2 or if its a SATA SSD use hdparm.

    • Tried using this but got the following error:
    • NVMe status: INVALID_FIELD: A reserved coded value or an unsupported value in a defined field(0x2)
    • Screen shot for reference: 20240815_120303
  5. Also what does smartctl report as the general health of these drives, specifically

    • 0 for all 4
    • Here is the screen shot: 20240815_115953
  6. You state throughput at Throughput around: 150 ~ 200 Mbps. Do you mean bits per second or bytes per second.

    • Sorry about that, I had forgotten that the capital and lower case "b" have different meanings.
    • It is showing in Bytes. If you can see from the screenshot photo it is running in MB/s.
    • So this means that the one with the frozen state screenshot provided in this comment was running at 326 MBytes/s

I have this nagging feeling that there might be some changes that needs to be done in the BIOS but havent confirmed anything yet. I'll keep making changes and try to wipe.

Let me know if you want any tests done, I have about ~20 Latitude 5300 with 2 types of SSDs to wipe so, until I find the right way to wipe these I'll be doing a lot of trial runs.

Sincera2024 commented 3 months ago

Good news!

I successfully wiped one Dell Latitude 5300 with the following changes to the BIOS settings (basically, disabled everything):

  1. UEFI Boot Path Security - Disabled
  2. SATA Operation - Selected AHCI (this is a must because if this is on RAID then the drives dont show up - Tested on 40+ laptops)
  3. Integrated NIC - Disabled
  4. USB Configuration - Enabled both
    • there are 2 selections for 5300 models and I enabled both selection
    • Enable USB Boot Support
    • Enable External USB Port
  5. USB PowerShare - Enabled
  6. MAC Address Pass-Through - Disabled
  7. TPM 2.0 Security - Disabled (turned off in this case)
  8. Absolute(R) - Disabled
  9. OROM Keyboard Access - Disabled
  10. Secure Boot - Disabled (this is also a must. Tested on 20+ laptops - different models)
  11. Intel(R) Software Guard Extensions tm - Disabled (This is also a must with tests done on the 20+ latest laptopsand I think it is to stop changes to the OS or attempting to run anything in the context of the OS but havent really done research on it)
  12. POST Behaviour Fastboot - Set to Thorough
  13. Virtualization support - Disabled all
  14. BIOS Recovery - Disabled
  15. SupportAssist System Resolution - Auto OS Recovery Threshold - Set to OFF
  16. SupportAssist System Resolution - SupportAssist OS Recovery - Disabled
  17. SupportAssist System Resolution - BIOSConnect - Disabled

I have started another one and post the results of that one here as well.

I've also attached the log file for the successfully wiped 5300 model:

nwipe_log_20240815-123228.txt

Sincera2024 commented 3 months ago

Good news again!

The BIOS change worked on another Dell Latitude 5300.

Testing on the Dell Latitude 5491 models now.

Started 10 laptops and leaving overnight with the same BIOS config.

Will post update tomorrow. Hopefully, all of them will be successful.

PartialVolume commented 3 months ago

Good news!

I successfully wiped one Dell Latitude 5300 with the following changes to the BIOS settings (basically, disabled everything):

  1. UEFI Boot Path Security - Disabled
  2. SATA Operation - Selected AHCI (this is a must because if this is on RAID then the drives dont show up - Tested on 40+ laptops)
  3. Integrated NIC - Disabled
  4. USB Configuration - Enabled both
  • there are 2 selections for 5300 models and I enabled both selection
  • Enable USB Boot Support
  • Enable External USB Port
  1. USB PowerShare - Enabled
  2. MAC Address Pass-Through - Disabled
  3. TPM 2.0 Security - Disabled (turned off in this case)
  4. Absolute(R) - Disabled
  5. OROM Keyboard Access - Disabled
  6. Secure Boot - Disabled (this is also a must. Tested on 20+ laptops - different models)
  7. Intel(R) Software Guard Extensions tm - Disabled (This is also a must with tests done on the 20+ latest laptopsand I think it is to stop changes to the OS or attempting to run anything in the context of the OS but havent really done research on it)
  8. POST Behaviour Fastboot - Set to Thorough
  9. Virtualization support - Disabled all
  10. BIOS Recovery - Disabled
  11. SupportAssist System Resolution - Auto OS Recovery Threshold - Set to OFF
  12. SupportAssist System Resolution - SupportAssist OS Recovery - Disabled
  13. SupportAssist System Resolution - BIOSConnect - Disabled

I have started another one and post the results of that one here as well.

I've also attached the log file for the successfully wiped 5300 model:

nwipe_log_20240815-123228.txt

Thanks for taking the time to post the detail. Much appreciated. This is always useful for other users with the same hardware.

PartialVolume commented 3 months ago

Good news again!

The BIOS change worked on another Dell Latitude 5300.

Testing on the Dell Latitude 5491 models now.

Started 10 laptops and leaving overnight with the same BIOS config.

Will post update tomorrow. Hopefully, all of them will be successful.

Looking forward to hearing the results. Strange how a bios setting would cause a freeze but then again maybe I'm not surprised seeing how many bugs can exist in bios code and cause all sorts of weird problems.

Sincera2024 commented 3 months ago

Good news again! The BIOS change worked on another Dell Latitude 5300. Testing on the Dell Latitude 5491 models now. Started 10 laptops and leaving overnight with the same BIOS config. Will post update tomorrow. Hopefully, all of them will be successful.

Looking forward to hearing the results. Strange how a bios setting would cause a freeze but then again maybe I'm not surprised seeing how many bugs can exist in bios code and cause all sorts of weird problems.

Hi @PartialVolume .

So, all the 10 laptops with differing SSDs have successfully wiped.

The BIOS was the cause of the freeze (at least for the dell latitude 5300 and 5491 models).

If anyone faces something similar in more recent models then initial changes to the BIOS may be the key.

I've just started another 10 laptops and all is going well.

Thank you for developing ShredOS and improving it!

Sincera2024 commented 3 months ago

Good news! I successfully wiped one Dell Latitude 5300 with the following changes to the BIOS settings (basically, disabled everything):

  1. UEFI Boot Path Security - Disabled
  2. SATA Operation - Selected AHCI (this is a must because if this is on RAID then the drives dont show up - Tested on 40+ laptops)
  3. Integrated NIC - Disabled
  4. USB Configuration - Enabled both
  • there are 2 selections for 5300 models and I enabled both selection
  • Enable USB Boot Support
  • Enable External USB Port
  1. USB PowerShare - Enabled
  2. MAC Address Pass-Through - Disabled
  3. TPM 2.0 Security - Disabled (turned off in this case)
  4. Absolute(R) - Disabled
  5. OROM Keyboard Access - Disabled
  6. Secure Boot - Disabled (this is also a must. Tested on 20+ laptops - different models)
  7. Intel(R) Software Guard Extensions tm - Disabled (This is also a must with tests done on the 20+ latest laptopsand I think it is to stop changes to the OS or attempting to run anything in the context of the OS but havent really done research on it)
  8. POST Behaviour Fastboot - Set to Thorough
  9. Virtualization support - Disabled all
  10. BIOS Recovery - Disabled
  11. SupportAssist System Resolution - Auto OS Recovery Threshold - Set to OFF
  12. SupportAssist System Resolution - SupportAssist OS Recovery - Disabled
  13. SupportAssist System Resolution - BIOSConnect - Disabled

I have started another one and post the results of that one here as well. I've also attached the log file for the successfully wiped 5300 model: nwipe_log_20240815-123228.txt

Thanks for taking the time to post the detail. Much appreciated. This is always useful for other users with the same hardware.

No problem at all!

I have previously benefited a lot from people posting the solution details to problems I've faced, so in a way I'm also giving back (though its a small one this time)

Hope this helps other users!

Arexiga commented 3 months ago

Hi! I'm having the same freezing issue with all the 15+ laptops I'm trying to wipe (Dell Latitude 5400 all the way up to 5440). As an alternative, I've been booting into a KaisenOS liveUSB which includes nwipe 0.37 and it's been working great. I only disabled Secure Boot and changed RAID to AHCI in BIOS.

Today I noticed @Sincera2024 's solution for ShredOS (which I'll definitely try later today), and it made me ponder the true nature of this issue. Could this be kernel or driver related? Unfortunately, I'm not skilled enough to find this out but I wanted to give my two cents on the matter. I'd gladly provide any logs/reports if it helps.

Arexiga commented 3 months ago

Hi! I'm having the same freezing issue with all the 15+ laptops I'm trying to wipe (Dell Latitude 5400 all the way up to 5440). As an alternative, I've been booting into a KaisenOS liveUSB which includes nwipe 0.37 and it's been working great. I only disabled Secure Boot and changed RAID to AHCI in BIOS.

Today I noticed @Sincera2024 's solution for ShredOS (which I'll definitely try later today), and it made me ponder the true nature of this issue. Could this be kernel or driver related? Unfortunately, I'm not skilled enough to find this out but I wanted to give my two cents on the matter. I'd gladly provide any logs/reports if it helps.

Good news!

Based on @Sincera2024 's configuration, I went ahead and wiped a laptop but this time I only disabled UEFI Boot Path Security along with Secure Boot and also changed RAID to AHCI. This configuration did the trick for me and I didn't have to disable the remaining 16 options they listed.

I'll keep testing with more laptops and let you know if I find anything else.

tiger960 commented 2 months ago

图像 (2) We are experiencing the same problem with the progress bar freezing up when performing a data wipe on a Thinkpad model. So we connected to a wired network and re-executed the data erase task again and it was successful, this method has been verified on multiple computers and it works. I just don't understand why we still need to connect to the network when erasing data?

PartialVolume commented 2 months ago

It may be caused by a buggy DRM graphics driver. May well be fixed in the next release. Can you post your hardware details from a system that freezes using lspci -k. Thanks.

tiger960 commented 2 months ago

It may be caused by a buggy DRM graphics driver. May well be fixed in the next release. Can you post your hardware details from a system that freezes using lspci -k. Thanks.

媒体 (3) 媒体 (2) 媒体 (1)

Today while wiping data without connecting to a wired network, 3 of the computers had the same problem again and the progress bar froze . The screenshots below are the relevant information, I'm not sure if they will help you.

BTW these models are Thinkpad X13 and X390.

tiger960 commented 2 months ago

It may be caused by a buggy DRM graphics driver. May well be fixed in the next release. Can you post your hardware details from a system that freezes using lspci -k. Thanks.

媒体 (4)

tiger960 commented 2 months ago

It may be caused by a buggy DRM graphics driver. May well be fixed in the next release. Can you post your hardware details from a system that freezes using lspci -k. Thanks.

媒体 (5)

PartialVolume commented 2 months ago

If it is caused by the Intel i915 DRM graphics driver I would expect it to work without a problem if you append nomodeset to the end of the kernel command line in both the grub.cfg files on the USB stick.

PartialVolume commented 2 months ago

All Intel cometlake or whiskeylake GT2 UHD graphics chipsets. It will be interesting to know if nomodeset solves the problem. If you added nomodeset correctly the VGA compatible controller line in lspci -k should mention cometlake or whiskeylake but the kernel driver in use line will be missing. There may or may not be any difference in the way the screen looks.

tiger960 commented 2 months ago

All Intel cometlake or whiskeylake GT2 UHD graphics chipsets. It will be interesting to know if nomodeset solves the problem. If you added nomodeset correctly the VGA compatible controller line in lspci -k should mention cometlake or whiskeylake but the kernel driver in use line will be missing. There may or may not be any difference in the way the screen looks.所有 Intel cometlake 或 whiskeylake GT2 UHD 图形芯片组。了解 nomodeset 是否解决了这个问题会很有趣。如果您正确添加了 nomodeset,lspci -k 中的 VGA 兼容控制器行应该提到 cometlake 或 whiskeylake,但 kernel driver in use 行将丢失。屏幕的外观可能会有所不同,也可能不会有任何差异。

Hi, thank you very much for your reply. We will patiently wait for the next update and hopefully these issues will be resolved in the next version.

Zombiehamser commented 2 weeks ago

Hi. ShredOS freezing ant my Intel NUC's too. Is it true that process of erasing still working good while picture is freezing? How can I check it?

PartialVolume commented 2 weeks ago

I would read the section on wiping headless systems by enabling the inbuilt telnet server. You can then login and run the wipe remotely from a terminal in windows using putty or from Linux.

https://github.com/PartialVolume/shredos.x86_64#how-to-wipe-drives-on-headless-systems-or-systems-with-faulty-display-hardware-for-use-on-secure-lans-only

Tral-IT commented 6 days ago

Hello, I’m facing a rather disturbing issue. When I try to launch a wipe, no matter which wipe type I choose, the moment I start the wipe, ShredOS freezes. Nothing works except for manually pressing CTRL+C to cancel and quit NWipe. I’ve tried the solutions suggested in the thread and others without success, like disable the bios. I’ve already successfully wiped the disk in question (I need ShredOS for regular wipes, so I needed to test new settings), and similarly, I tried to wipe an external disk and encountered the same issue as with an internal one—instant freeze. I thought it might be related to BitLocker, as the disks are BitLocked, but I was able to wipe them without disabling it. I’m running out of ideas on where this could be coming from. The PCs in question are mostly Latitude 5410 up to 5440.

PartialVolume commented 6 days ago

That's are very unusual problem. The fact you can Control C out of it means the main nwipe thread is running ok. Can you take a video of the screen and post it, start the video from the moment you do a shift s to start, then for about 10 seconds. I want to see how it freezes. The wipe (disc) threads operate independently from the gui update thread. Thanks.

Tral-IT commented 6 days ago

GitHub only accepts files up to 10 MB in size, so I have done my best with the video. I have linked the video in order, normally. To describe a bit, I wait a moment, then initiate the wipe. As mentioned, the OS freezes—at least graphically. I try using the arrow keys while moving my hand, but nothing happens. After about 10 seconds, I press CTRL+C. If providing startup logs would help, I can share them.

https://github.com/user-attachments/assets/2d39c164-7b48-4c02-8927-b367c5d07249

https://github.com/user-attachments/assets/84b9fcf0-7299-4305-8da3-ba4c386c8fe7

https://github.com/user-attachments/assets/a6a2b663-ff7d-495e-b89b-c8615182f81b

https://github.com/user-attachments/assets/49c60378-985c-416a-9107-c3fc448bbb3f

https://github.com/user-attachments/assets/d1308056-e1f9-42b6-aa50-7e617a63320f

PartialVolume commented 6 days ago

According to that last video where you control c to abort, the log says you never started any wipe? How are you starting the wipe? Are these UK or US keyboards?

Tral-IT commented 6 days ago

Oh my God, I am ashamed of myself. It's been two days that instead of pressing SHIFT+S, I press CTRL+S. As they say, the problem lies between the chair and the computer... In any case, thank you, you helped me realize my mistake

PartialVolume commented 6 days ago

No problem, we all make mistakes 😁

PartialVolume commented 6 days ago

Just to add a little more information, just in case anybody comes across this thread in the future.

You can freeze the whole screen in either drive selection or during a wipe by typing control s. To unfreeze the screen you can type control q. Control s only freezes the screen, it doesn't freeze keyboard input, hence why you can control c out of the situation.

As it's possible to accidentally freeze the screen using control s I may look at someway of improving the user experience so it's more obvious you need to unfreeze the screen with a message about control q being shown on screen, or alternatively trying to disable control s & control q if possible.