Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ShredOS GUI freezing during Wipe #312

Open
Torwass opened this issue Jan 6, 2025 · 6 comments
Open

ShredOS GUI freezing during Wipe #312

Torwass opened this issue Jan 6, 2025 · 6 comments

Comments

@Torwass
Copy link

Torwass commented Jan 6, 2025

My problem started with the freeze on DoD-7 around 90%, on the last verifying pass. I tried multiple times then, sometimes it also stops somewhere around 25%. Timer stops. Switching between virtual terminals doesn’t work, CTRL+Q doesn't work as well.

Following your advices on issue "ShredOS GUI freezes during Wipe - i915 video driver HD graphics 530" I looked the following:

HDD temperature — okay.
Memtest — 0 errors.
Smart drive’s health test — passed.
Reallocated sectors — 200.

Then I've tried different ways to make it work:

Separate DIMMS, different slots — frozen.
No DRM graphics driver — frozen.

Test after disabling DRM graphics driver:

Zero Pass, verifying pass, blanking pass — frozen.
Zero Pass, no verifying pass, blanking pass — finished.

PRNG, verifying pass, blanking pass — frozen.
PRNG, no verifying pass, blanking pass — finished.

DoD-short, verifying pass, blanking pass — frozen.
DoD-short, no verifying pass, blanking pass — finished.

DoD-7, verifying pass, blanking pass — frozen.
DoD-7, no verifying pass, blanking pass — frozen.
DoD-7, no verifying pass, no blanking pass — frozen.

Home computer, no overclocking, no known problems.

@PartialVolume
Copy link
Owner

PartialVolume commented Jan 6, 2025

CTRL+Q doesn't work as well.

Just checking you were doing a CTRL+Q to unfreeze terminal output as opposed to CTRL+S that freezes terminal output.

Can you output lspci and post it here so we can see what hardware you have. Thanks.

I'm assuming you are running the latest release?

When you say no DRM graphics how are you achieving that? Are you using one of the NO DRM images or are you editing the grub files and adding nomodeset to the kernel command line in both grub files. Are you booting UEFI or legacy?

Have you tried wiping a different drive to identify whether the drive is causing the problem or the computer.

I don't like the 200 reallocated sectors, I don't know what others think, almost all my drives have zero reallocated sectors. How many lifetime hours has this drive been going for?

As you can't switch virtual terminals I would say it's either the DRM graphics but you say you are not running in DRM graphics or something has killed the kernel.

This is what I would do.

Enable the telnet server in ShredOS, then login from another computer, run nwipe in a terminal from the remote computer. Wipe the disc. If it consistently wipes OK then it's a graphics related bug (but not in nwipe). See headless logins 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

@PartialVolume
Copy link
Owner

Don't forget ShredOS requires a DHCP server (router) on the network for ShredOS to obtain a IP address so that headless logins will work.

@Torwass
Copy link
Author

Torwass commented Jan 11, 2025

Just checking you were doing a CTRL+Q to unfreeze terminal output as opposed to CTRL+S that freezes terminal output.

Exactly.

I'm assuming you are running the latest release?

Yes.

When you say no DRM graphics how are you achieving that? Are you using one of the NO DRM images or are you editing the grub files and adding nomodeset to the kernel command line in both grub files. Are you booting UEFI or legacy?

I’ve edited both grub files with “nomodeset”. Booting UEFI.

How many lifetime hours has this drive been going for?

5 years or so. Manufacturer software says it’s 50% health.

Have you tried wiping a different drive to identify whether the drive is causing the problem or the computer.

I have not. However, I’ve just finished nwipe on the same disk on another machine. All methods worked as expected and finished wiping without problems.

I could not boot with default graphic driver, so I used “nomodeset” yet again. Basically, all variables stayed the same: no DRM graphics, UEFI, latest release nwipe (0.37), same HDD.

I could add “lspci” of this machine as well, but I need to figure out, how to change font size of the terminal to the smaller version (since the output can’t fit in one page with “nomodeset”). I’ve tried to use command “less” instead, but either it doesn’t work or I used it wrong.

Sadly, I can’t test remote wipe at the moment.

@PartialVolume
Copy link
Owner

5 years or so. Manufacturer software says it’s 50% health.

50% health? Straight in the bin or physically destroy it, if it was me. Unless it's 100% healthy with preferably zero reallocated sectors I personally don't think it worth the ongoing issues you might get further down the line if you reuse it.

I could add “lspci” of this machine as well, but I need to figure out, how to change font size of the terminal to the smaller version (since the output can’t fit in one page with “nomodeset”). I’ve tried to use command “less” instead, but either it doesn’t work or I used it wrong.

One way is to split the output into pages using lspci | more take a picture, press spacebar, take another picture and so on, alternatively lspci > lspci.txt to create a file, then mount the USB stick and copy the file onto the USB stick.

@Torwass
Copy link
Author

Torwass commented Jan 12, 2025

50% health? Straight in the bin or physically destroy it, if it was me.

I've mistaken there. It was the SDD I have with 50% health. Double checked with manufacturer's software today: HDD I'm wiping is all good. Though, 200 allocated sectors still stay. I could have given this up long ago, but I want to contribute to the project even if it's as little as is.

lspci -k files of both machines attached. "lspci_amd_okay" is the one I tested recently, all methods worked both blanking path and verifying pass enabled (Zeroes, PRNG, DoD, DoD-7). "lspci_intel_issue" is the one I'm using at home.

lspci_amd_okay.pdf
lspci_intel_issue.pdf

@PartialVolume
Copy link
Owner

Interesting both are using Nvidia graphics, it might explain why nomodeset was necessary.

It will be interesting to see if both these systems work without nomodeset with the new 6.11 kernel and it's updated DRM graphics drivers that I'll be releasing in the next week or so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants