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.45k stars 61 forks source link

Monitor fails to wake from sleep after switching source #96

Closed TheSwede86 closed 1 year ago

TheSwede86 commented 2 years ago

Hello,

Running the latest ShredOS from a USB (UEFI) and currently wiping 2* 4TB HDDs using a USB 3.0 dock. My monitor (AOC AG271QG) is connected to my Asus ROG 1070 Ti Strix using a DP-cable and my mouse and keyboard are directly connected to my computers USB-ports.

I switched source on my monitor to my work laptop (connected to HDMI) and now when I switch back to the DP-source it does not detect any source / active monitor.

I tried pressing the "R"-key, the "B"-key, reconnecting the keyboard and mouse, reconnecting my DP-cable, tried the built-in DP on the motherboard to no avail, the source still detects as "No source" and the monitor never comes out of sleep.

Any ideas?

The dock indicates the wipe is still running and the computer is still turned on.

Best Regards - Karl

PartialVolume commented 2 years ago

Have a read through this thread and see if you think a setting in the monitor may be the cause. https://github.com/PartialVolume/shredos.x86_64/issues/64

TheSwede86 commented 2 years ago

Have a read through this thread and see if you think a setting in the monitor may be the cause. https://github.com/PartialVolume/shredos.x86_64/issues/64

Thanks, I never knew I had such a setting - "Deep sleep" - for my monitor. However I guess it doesn't work retroactively? I gather from a reply in that thread that it worked for the user after he disabled "deep sleep" (that he was able to see his screen once again) whereas I've disabled deep sleep, disconnected and reconnected the DP-cable, powered the monitor off / on and the source still reports "no source" and is dark.

PartialVolume commented 2 years ago

Take a look at some of the non windows related possibilities here https://www.google.com/amp/s/www.maketecheasier.com/fix-a-monitor-not-waking-up-after-sleep/%3famp

One that I noticed was having to switch of auto input selection and manually select the appropriate input to wake the monitor up.

TheSwede86 commented 2 years ago

Take a look at some of the non windows related possibilities here https://www.google.com/amp/s/www.maketecheasier.com/fix-a-monitor-not-waking-up-after-sleep/%3famp

One that I noticed was having to switch of auto input selection and manually select the appropriate input to wake the monitor up.

Thanks for your suggestion. I tried toggling to the specific "DP"-input to no avail and went through the entire OSD-menu to see if there were any option there that might make sense but didn't find any.

I read that you could enable Telnet to telnet into ShredOS but that is something you need to enable beforehand so I'll guess I'll enable it after I abort this run.

Waiting for a USB 3.1 Gen2 adapter which would give me 10Gbit compared to the current 5Gbit dock and will enable Telnet beforehand.

I will also run a shorter wipe then "DoD short" next time and see if the disabled "deep sleep" solves it and if not I still have the Telnet-option.

PartialVolume commented 2 years ago

No problem.

Here's a little trick to see the progress of a running wipe, when your monitor won't play ball.

This assumes you have previously enabled telnet in grub.cfg. You can send a signal to the running nwipe process to tell it to immediately write the wipe progress to the log file. You can then 'more/cat/tail' the nwipe_log file to see how far the wipe has proceeded. Even better you could telnet into shredos from a second telnet session and run tail -f nwipe_log_20220307-211014.txt (alter filename as appropriate) to see a running output of the log. The signal to send to nwipe is kill -s SIGUSR1 pid, replace pid with the process ID from ps -ef | grep -i nwipe and use the process id from the /usr/bin/nwipe line.

To find the IP address ShredOS is using.

# nmap -p23 192.168.1.0/24 --open
Starting Nmap 7.80 ( https://nmap.org ) at 2022-03-07 21:37 GMT
Illegal character(s) in hostname -- replacing with '*'
Illegal character(s) in hostname -- replacing with '*'
Illegal character(s) in hostname -- replacing with '*'
Nmap scan report for 192.168.1.242
Host is up (0.0040s latency).

PORT   STATE SERVICE
23/tcp open  telnet

Nmap done: 256 IP addresses (15 hosts up) scanned in 2.58 seconds

Open the first telnet session using the IP address found above via nmap. This is the telnet window by which we will send the SIGUSR1 signal to the nwipe process to print it's wipe progress to the nwipe log file. We use ps -ef | grep -i nwipe to find the process ID of /usr/bin/nwipe. We then use kill to send a special signal to nwipe SIGUSR1. nwipe knows that when it receives this signal it must write the wipe progress to the log. We will monitor the log in the second telnet session.

telnet 192.168.1.242
Trying 192.168.1.242...
Connected to 192.168.1.242.
Escape character is '^]'.

shredos login: root
# 
# ps -ef | grep -i nwipe
  235 root     {nwipe_launcher} /bin/sh /usr/bin/nwipe_launcher --
 3574 root     /usr/bin/nwipe --logfile=nwipe_log_20220307-211014.txt
 7247 root     tail -f nwipe_log_20220307-211014.txt
 7572 root     grep -i nwipe
# kill -s SIGUSR1 3574
# kill -s SIGUSR1 3574
# kill -s SIGUSR1 3574
# kill -s SIGUSR1 3574

Then open the second telnet session using the IP address found above to tail the nwipe_log file, change directory to where the nwipe_log files are placed and tail -f the latest one.

telnet 192.168.1.242
Trying 192.168.1.242...
Connected to 192.168.1.242.
Escape character is '^]'.

shredos login: root
# 
# cd /
# ls      
bin   etc       lib      media      nwipe_log_20220307-210104.txt  proc  sbin   tmp
boot  init      lib64    mnt        nwipe_log_20220307-211014.txt  root  share  usr
dev   lftp.log  linuxrc  nohup.out  opt

# tail -f nwipe_log_20220307-211014.txt
[2022/03/07 21:10:38]  notice:   sync     = 100000
[2022/03/07 21:10:38]  notice:   verify   = 1 (last pass)
[2022/03/07 21:10:38]  notice: /dev/sdb has serial number WD-WX21A5341835
[2022/03/07 21:10:38]  notice: /dev/sdb, sect/blk/dev 512/4096/500107862016
[2022/03/07 21:10:38]  notice: Invoking method 'Fill With Zeros' on /dev/sdb
[2022/03/07 21:10:38]  notice: Starting round 1 of 1 on /dev/sdb
[2022/03/07 21:10:38]  notice: Starting pass 1/1, round 1/1, on /dev/sdb
[2022/03/07 21:13:57]    info: /dev/sdb: 01.50%, round 1 of 1, pass 1 of 1, eta 03:35:33, [syncing]
[2022/03/07 21:15:56]    info: /dev/sdb: 02.40%, round 1 of 1, pass 1 of 1, eta 03:37:58, [syncing]
[2022/03/07 21:16:26]    info: /dev/sdb: 02.62%, round 1 of 1, pass 1 of 1, eta 03:34:52, [syncing]
[2022/03/07 21:21:36]    info: /dev/sdb: 04.89%, round 1 of 1, pass 1 of 1, eta 03:35:03, [syncing]
[2022/03/07 21:21:38]    info: /dev/sdb: 04.91%, round 1 of 1, pass 1 of 1, eta 03:34:59, [syncing]
[2022/03/07 21:21:40]    info: /dev/sdb: 04.91%, round 1 of 1, pass 1 of 1, eta 03:34:59, [syncing]
[2022/03/07 21:21:41]    info: /dev/sdb: 04.94%, round 1 of 1, pass 1 of 1, eta 03:34:55, [syncing]

You could automate this a little by putting the kill command in a loop, so that the signal is sent to nwipe every 60 seconds. I wouldn't do it any faster than this, because nwipe is storing each message in RAM, maybe 300 seconds would be sufficient.

# while [ 1 ];do kill -s SIGUSR1 3574;sleep 60;done

and of course you can always run another nwipe process in the telnet session if the 'other' nwipe process is sitting at the selection screen. In fact, say you had started wiping /dev/sda and then realised you wanted to also wipe /dev/sdb. You can't just start nwipe with a nwipe command because it will just hang because it tries to enumerate all drives and it can't because the first nwipe process is wiping /dev/sda but what you can do is start nwipe but specify the specific drive you want to wipe. As long as the first nwipe process isn't wiping /dev/sdb then you can type nwipe /dev/sdb. A sort of non publicised feature is that nwipe can also wipe partitions from the command line (but not from the gui). So nwipe /dev/sda1 should work, although a note of caution. It's been a very long time since I've tested wiping partitions so use with caution.

I must put some of these notes in the README.md file.

GetGudKid commented 1 year ago

I experienced this on my first ShredOS experience. I ran the 64 bit version on a USB on my desktop PC. As the wipe was executing I turned off my monitors (I have 2 connected to the PC). Then when I woke up in the morning I tried to turn on both monitors, both refused to show anything but a black screen. Something along the lines of "no connection" being displayed on my screen, then my screens going into sleep mode automatically. No keyboard key pressing or mouse clicks brought back a connection to the monitor.

I have no idea if the wipe was successful or not. I really wish a log file was saved to the USB automatically. It would make sense to have that as a feature by default. Since if someone is running ShredOS on a USB stick then they have the capability to read/write where a burned disc wouldn't have that luxury.

I would try to use command options but I'm a complete noob to a command line. Do I run multiple options at once? Do I feed the command one command option at a time? I like GUIs for a smooth brain like me. 😂

PartialVolume commented 1 year ago

I really wish a log file was saved to the USB automatically.

That feature has recently been added. The latest release/pre-release automatically saves the log files & PDFs to USB. (PDFs coming in nwipe 0.35)

Also the latest pre-release using DRM graphics and drivers.

Please re-open if still an issue when using the latest pre-release. Thanks.