Open Trump125532 opened 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.
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)
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
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.
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.
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.
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:
Just thinking about what might cause this, the order is of no particular significance:
A bug in the Intel graphics driver that affects Intel UHD ? That's possible, but if it was that, there isn't anything I can do about it that other than bump ShredOS to the next buildroot and kernel version and hope it's fixed, however if it was this I would have expected to see many issues with Intel graphics but you never know perhaps it's very specific to a certain Intel graphics chipset.
The WD SN720 has a operating spec of 70 deg.C so the 50 deg.C is well within spec.
Motherboard fault when the internal temperature increases ? It probably goes without saying but a secure erase using hdparm (provided with ShredOS) would most likely be much faster and not raise the temperature internally by any where near as much. So if a temperature related issue you may be able to get the drive wiped.
What wipe method are you using on the SSD, hopefully not the default DOD short. I wouldn't do anything more than a ones wipe or PRNG with last pass verification and NO final blanking. Basically a single wipe and single verification read. My preference being PRNG as it would show stuck bits in the data channels that a ones or zeros might not. PRNG however does put a little more pressure on the CPU which ones doesn't.
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.
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.
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
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:
Cheers, Cal
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
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. :)
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.
@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
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.
@PartialVolume I've got one stuck right now and it was left overnight. Screenshot of the frozen state:
Nothing works except to force the computer off with the power button.
This one has an NVMe SK Hynix SSD with 256GB storage.
Can you run smartctl -a /dev/sd[x] I'm wondering what firmware these drives have installed:
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
You state throughput at Throughput around: 150 ~ 200 Mbps. Do you mean bits per second or bytes per second.
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.
Good news!
I successfully wiped one Dell Latitude 5300 with the following changes to the BIOS settings (basically, disabled everything):
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:
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.
Good news!
I successfully wiped one Dell Latitude 5300 with the following changes to the BIOS settings (basically, disabled everything):
- UEFI Boot Path Security - Disabled
- SATA Operation - Selected AHCI (this is a must because if this is on RAID then the drives dont show up - Tested on 40+ laptops)
- Integrated NIC - Disabled
- USB Configuration - Enabled both
- there are 2 selections for 5300 models and I enabled both selection
- Enable USB Boot Support
- Enable External USB Port
- USB PowerShare - Enabled
- MAC Address Pass-Through - Disabled
- TPM 2.0 Security - Disabled (turned off in this case)
- Absolute(R) - Disabled
- OROM Keyboard Access - Disabled
- Secure Boot - Disabled (this is also a must. Tested on 20+ laptops - different models)
- 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)
- POST Behaviour Fastboot - Set to Thorough
- Virtualization support - Disabled all
- BIOS Recovery - Disabled
- SupportAssist System Resolution - Auto OS Recovery Threshold - Set to OFF
- SupportAssist System Resolution - SupportAssist OS Recovery - Disabled
- 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:
Thanks for taking the time to post the detail. Much appreciated. This is always useful for other users with the same hardware.
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.
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!
Good news! I successfully wiped one Dell Latitude 5300 with the following changes to the BIOS settings (basically, disabled everything):
- UEFI Boot Path Security - Disabled
- SATA Operation - Selected AHCI (this is a must because if this is on RAID then the drives dont show up - Tested on 40+ laptops)
- Integrated NIC - Disabled
- USB Configuration - Enabled both
- there are 2 selections for 5300 models and I enabled both selection
- Enable USB Boot Support
- Enable External USB Port
- USB PowerShare - Enabled
- MAC Address Pass-Through - Disabled
- TPM 2.0 Security - Disabled (turned off in this case)
- Absolute(R) - Disabled
- OROM Keyboard Access - Disabled
- Secure Boot - Disabled (this is also a must. Tested on 20+ laptops - different models)
- 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)
- POST Behaviour Fastboot - Set to Thorough
- Virtualization support - Disabled all
- BIOS Recovery - Disabled
- SupportAssist System Resolution - Auto OS Recovery Threshold - Set to OFF
- SupportAssist System Resolution - SupportAssist OS Recovery - Disabled
- 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!
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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
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?
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
No problem, we all make mistakes 😁
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.
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.