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 fails to wake from suspend #70

Closed
PartialVolume opened this issue Jan 25, 2021 · 36 comments
Closed

ShredOS fails to wake from suspend #70

PartialVolume opened this issue Jan 25, 2021 · 36 comments
Assignees

Comments

@PartialVolume
Copy link
Owner

rtcwake -m mem -s 5 does indeed put the device to sleep but upon waking reboots ShredOS rather than the expected behaviour of restoring the running ShredOS from RAM.

@PartialVolume PartialVolume self-assigned this Jan 25, 2021
@PartialVolume
Copy link
Owner Author

PartialVolume commented Jan 25, 2021

@hameau
Copy link

hameau commented Jan 25, 2021

'ShredOS fails to wake from suspend' might be a better title – the suspend part appears to be okay.

Referring to https://github.com/PartialVolume/shredos.x86_64_2020.05/issues/20#issuecomment-766953990, ACPI support, or lack of, is the most likely culprit. That would also account for the waking without restarting the video hardware (https://github.com/PartialVolume/shredos.x86_64_2020.05/issues/20#issuecomment-766871022).

Apologies if you already know this stuff, but this Ubuntu wiki entry gives a useful overview.

@PartialVolume PartialVolume changed the title ShredOS doesn't suspend to RAM ShredOS fails to wake from suspend Jan 25, 2021
@PartialVolume
Copy link
Owner Author

Apologies if you already know this stuff, but this Ubuntu wiki entry gives a useful overview.

Feedback and links to articles are always useful, thanks.

@PartialVolume
Copy link
Owner Author

@hameau I just tried rtcwake -m mem -s 5 multiple times using the latest i686 version of ShredOS (identical to the x86_64 version except for the change in architecture only) on a Pentium 4 and it woke up correctly after 5 seconds. All virtual terminals are fully functional.

So the problem would seem to be related to specific hardware.

@hameau
Copy link

hameau commented Jan 28, 2021

Wake from suspend has been a thorn in the side of Linux for ever!

I have tried with an MSI Wind (Atom) and it fails to resume – black screen, but the computer is running. The same result using rtcwake and manipulating /sys/power/state, with both the i686 and x86-64 images. Neither of my test cases have provoked a reboot, just no video.

That hardware works correctly under SysRescCD, but not Clonezilla (Debian version).

For a standard installed Linux distribution, it's usually a matter of pushing options to the video driver. Interesting that both of my test cases have integrated Intel graphics, which your P4 doesn't. (Of course, integration itself may not be significant – other things will also have changed over time.)

There is a kernel-level TRACE_RESUME feature: https://www.kernel.org/doc/Documentation/power/s2ram.txt

I'll set up the MSI Wind to test with that in the next few days, if I can. It's something that needs a bit of preparation and some clear bench space.

Also, this Ubuntu wiki page: https://wiki.ubuntu.com/DebuggingKernelSuspend (but needs a workaround for pm-suspend, which isn't in ShredOS – not a disaster).

@hameau
Copy link

hameau commented Jan 28, 2021

... but upon waking reboots ShredOS ...

What's the hardware for this one? CPU & graphics.

@PartialVolume
Copy link
Owner Author

... but upon waking reboots ShredOS ...

What's the hardware for this one? CPU & graphics.

HP Pavilion dm1 notebook. AMD E-450 APU (AMD Radeon HD 6320)

@PartialVolume
Copy link
Owner Author

@hameau I've now got rtcwake working properly on my main laptop, which is an I7 with Nvidia graphics. The laptop now wakes correctly. Not only that but the LCD brightness controls on the keyboard now work too. I've had to expand the disc size from 38Mb to 41Mb to accommodate all the video, backlight, control drivers for Intel, AMD, ATI plus others. There is a couple of issues I need to work on, on the HP notebook the screen is alive in that it says 'ShedOS booting' but nwipe never displays. If you ALT F2 you can power off but the screen never changes from saying ShredOS booting.

The other problem is the text resolution on my I7, because it's now using the Nvidia video driver it defaults to the screens highest resolution which is too high for nwipe..
IMG_20210128_220125~2

On the plus side the laptop now wakes properly from sleep.

@PartialVolume
Copy link
Owner Author

nomodeset on the kernel command line gets me my original 80 x 25 character resolution back but reintroduces the rtcwake issue. So I definitely need to set a graphics mode, VGA=0x etc is deprecated and set gfxpayload=1024x1024x24 still leaves me with the highest resolution. Onwards and upwards ..

@hameau
Copy link

hameau commented Jan 29, 2021

I've had to expand the disc size from 38Mb to 41Mb ...

Yes, I was afraid of some growth. You're still pretty compact at around 7% of SysRescCD, so the wider usefulness is very much worthwhile, imo.

set gfxpayload=1024x1024x24 still leaves me with the highest resolution.

I doubt if 1024x1024x24 is a valid mode. Typo? You probably need to find a reasonable 'lowest common denominator' to suit a wide range of hardware. Personally, I find an 80x25 terminal too low-res., even in nwipe, as the wipe method text description overflows the available space (e.g., for zero method). Even if not ideal, I would be okay with the resolution in your screenshot – you're unlikely to find a single setting that will fit every case.

Impressive progress, thanks.

@PartialVolume
Copy link
Owner Author

@hameau thanks for those links, they were very useful. I think I'm going to have to spend a lot more time on making this reliable using video drivers rather than the fb driver, I have one generic I7/Nvidia laptop that works well but I need to work out a method by which the resolution can be easily changed by a user. While on a Sony VAIO the laptop freezes the frame buffer when switching drivers and the same with an HP.

This will be something I intend to do (or somebody else if they can can up with a good PR) but for the time being I need to fix a couple of bugs in nwipe and add HDA detection and correction and then I'll come back to this particular issue, therefore I'll leave this issue open. As always any help you can provide on this is appreciated.

@PartialVolume PartialVolume transferred this issue from PartialVolume/shredos.x86_64 Nov 30, 2021
@PartialVolume PartialVolume transferred this issue from another repository Dec 8, 2021
@PartialVolume
Copy link
Owner Author

PartialVolume commented Feb 14, 2022

I've been looking at the issue of ShredOS not waking from sleep this evening, and specifically what part of the system doesn't wake. This is a DELL Optiplex 9010. I've found I can telnet into ShredOS and the drives are indeed 'not frozen' and I can do a secure erase via hdparm. What seems to happen is that the display hardware (Intel) doesn't wake from sleep. The keyboard is functional so it seems the consoles ALT-F1-F3 is working. It's just the display that isn't.

I've been looking at the various power related features in /sys/devices/ etc and toggled auto to on in control but no luck yet.

@PartialVolume
Copy link
Owner Author

For a standard installed Linux distribution, it's usually a matter of pushing options to the video driver. Interesting that both of my test cases have integrated Intel graphics, which your P4 doesn't. (Of course, integration itself may not be significant – other things will also have changed over time.)

And my Dell optiflex also having integrated Intel graphics.

I think I will get on with making the changes to nwipe so it supports ATA secure erase and controls putting the system to sleep then come back to this.

@PartialVolume
Copy link
Owner Author

@PartialVolume
Copy link
Owner Author

@hameau @Firminator Looks like I may have solved the suspend to RAM issue. I've added some drm Direct Rendering Manager code to ShredOS along with a selection of Nvidia, AMD and Intel DRM drivers and some configuration of ACPI and now ShredOS on my Nvidia laptop boots ShredOS with the native resolution of the screen. Previously it only ever displayed ShredOS in a low Res display.

Most importantly, the command echo "mem" > /sys/power/state powers down the drives and graphics system and then hitting the power button correctly restores ShredOS with all the drives 'Not Frozen'. Within nwipe this process will be handled by rtcwake -s 5 -m mem to automatically put ShredOS to sleep for five seconds in order to unfreeze the drives prior to issuing the secure erase.

I can now start writing the secure erase code in nwipe and have a working ShredOS that will correctly suspend to RAM that I can use as a test bed.

Before I do a release I'll need some testing done on systems with lots of different graphics hardware to make sure ShredOS can always be sent to sleep and restored with fully working graphics.

If anybody is interested in testing the beta version of ShredOS with secure erase then let me know and I'll send you a link to download the .img in due course.

@gorbiWTF
Copy link

Before I do a release I'll need some testing done on systems with lots of different graphics hardware to make sure ShredOS can always be sent to sleep and restored with fully working graphics.

If anybody is interested in testing the beta version of ShredOS with secure erase then let me know and I'll send you a link to download the .img in due course.

I've got a couple of different combinations of graphic cards and monitor resolutions, newer and older hardware, which I can test if you want.

@PartialVolume
Copy link
Owner Author

PartialVolume commented Feb 18, 2022

The test procedure: Once ShredOS has booted, ALT F2 to bring up the 2nd virtual terminal.

ShredOS version: You will need to be testing against the pre-release version v2021.08.2_22_x86-64_0.32.023 or higher. I'm not interested in the results from earlier revisions.

Once ShredOS has booted run the following rtcwake & hdparm commands in the 2nd virtual terminal (on a PC ALT F2) (on a Mac Fn ALT F2):

rtcwake -s 5 -m mem
Expected Result: System should power off hard drives and display hardware, display goes blank, backlight switches off on laptops. After approximately 9 seconds has elapsed, the computer should automatically with no user intervention power back up with hard drives running and the display will switch back on at the same screen that was being displayed when you ran the initial command. I.e no reboot should have occurred. The keyboard should be responsive.

hdparm -I /dev/sda
Expected Result: In the Security section near the end of the listing it should say "not frozen". If it says only "frozen" the disc drive power off never worked correctly.

Repeat for each drive on the system.

The following information can be obtained from the nwipe log (after a Control C) and from running the command lspci

Graphics Motherboard Bios Notes etc rtcwake status hdparm frozen state (success=not frozen
Nvidia GM107 (GeForce GTX750) Gigabyte H81M-DS2V Bios version F5 06/19/2014 SUCCESS SUCCESS
Intel IGC Crystal Well Apple MacBookPro 11,2 Bios 430.0.0.0.0 12/17/2020 SUCCESS SUCCESS
Nvidia GF114M (GeForce GTX 570M rev a1) Medion x681 (x7815) E16F2IM7 V5.0E 01/10/2012 SUCCESS SUCCESS
Nvidia GF119 (NVS 310) Dell OPC5F7 (Optiplex 9020) A07 04/25/2014 SUCCESS SUCCESS
Nvidia C73 (GeForce 7050/nForce 610i, rev a2) MSI MS-7366 V3.5 07/15/2008. In bios set 'S3' not 'S1' in power management, remove external video graphics card if present. Use integrated graphics. Trying to use external graphics resulted in image returning but keyboard unresponsive SUCCESS SUCCESS
Intel UHD 630 Lenovo 312A M1UKT68A (2021-12-27) SUCCESS SUCCESS (*)
Intel HD 4600 HP 1998 L01 v02.71 (2017-05-09) SUCCESS SUCCESS
Intel HD 4400 Acer Veriton X4630G P11-A0L (2013-08-15) SUCCESS SUCCESS
Intel HD 530 Fujitsu D3400-A1 v5.0.0.11 R1.29.0 for D3400-A1x (2020-01-27) SUCCESS SUCCESS
Intel HD 2000 HP 1495 J01 v02.06 (2011-06-09) SUCCESS SUCCESS
Intel HD 5500 + Radeon R9 M275X Lenovo Z51-70 C2CN19WWCU2.00 (2015-07-14) system just reboots -
Nvidia 1650 Ti Mobile + AMD Renoir (Ryzen 7 4800H) SchenkerTechnologiesGmbH GK7NxxR M20 N.1.20.A03 (2020-12-10) system turns off but not back on -

(*) I've got two drives in this machine: SATA drive is "not frozen", but for the NVME drive hdparm -I /dev/nvme0n1 and hdparm -I /dev/nvme0 returns nothing. [ @gorbiWTF ] See #70 (comment) and #70 (comment) for further info about the nvme-cli command for nvme drives.

Add you findings in the comments and I'll add your results to the table. Starting off with a I7 Nvidia laptop and a MacBook Pro that I'm currently testing.

@PartialVolume
Copy link
Owner Author

A note about screen resolution: With the new DRM drivers, the kernel controls the resolution of the display using KMS (kernel mode setting) With all the systems I've tested so far the kernel chooses the native resolution of the monitor. On a high resolution monitor this can result in quite small text. If this isn't to your taste you can have ShredOS boot using the 640x480 (80x30) resolution, nwipe then fills the entire monitor with larger text.

To disable KMS and revert to low resolution display and larger text add the following to the kernel command line

HOWEVER, if you disable KMS using the following method you will most likely find that rtcwake will no longer work as the kernel can't then control the display hardware to rewake it. So if you want secure erase to work properly DO NOT make the following additions to the linux kernel command line in grub.cfg

For Nvidia hardware, add nomodeset and nouveau.modeset=0

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 nomodeset nouveau.modeset=0
}

For Intel, add nomodeset and i915.modeset=0

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 nomodeset i915.modeset=0
}

For Nvidia Optimus dual-graphics system, you need to add all the three kernel parameters (i.e. "nomodeset i915.modeset=0 nouveau.modeset=0").

set default="0"
set timeout="0"

menuentry "shredos" {
	linux /boot/shredos console=tty3 loglevel=3 nomodeset i915.modeset=0 nouveau.modeset=0
}

@PartialVolume
Copy link
Owner Author

PartialVolume commented Feb 19, 2022

With reference to the above comment about screen resolution, the preferred way to increase font size is to not mess with KMS and NOT set nomodeset and therefore let the kernel set the native resolution, however, in order to increase the font size, use the command

/bin/setfont -d

Important!
Notice that the full path to setfont is used above. If you don't specify the full path, .ie /bin/.. then the command won't work. This is because there are two setfont programs in ShredOS and they have a different set of options. So you must type /bin/setfont -d for this to work and NOT setfont -d

This command then doubles the size of the existing font. I think I may put an option in nwipe that toggles between default and double size font, specifically for high resolution monitors

The images below show a monitor operating at it's native resolution of 1920x1200. The first image is the default 8x16 font. The second image is after having run the setfont -d command. In both cases the monitor is still operating at 1920x1200.

frame1
frame2

@PartialVolume
Copy link
Owner Author

PartialVolume commented Feb 19, 2022

A little more info about manually doubling the font size of the default nwipe that runs in tty1.

So type ALT F2 (Fn ALT F2 on a MAC) to bring up the 2nd virtual console. Type the following tty command which will return the current console name. So from this result /dev/tty2 we can deduce that the default nwipe in ALT F1 is /dev/tty1. For reference ALT F3 is /dev/console.

tty
/dev/tty2

So to set the font for the default nwipe in the first virtual console ALT F1 (/dev/tty1), type the following command in the 2nd virtual console (ALT F2)

/bin/setfont -d -C /dev/tty1

Always specify the full path to setfont, setfont -d -C /dev/tty1 without the /bin/ prefix, will not work.

@gorbiWTF
Copy link

Graphics Motherboard Bios Notes etc rtcwake status hdparm frozen state (success=not frozen
Intel UHD 630 Lenovo 312A M1UKT68A (2021-12-27) SUCCESS SUCCESS (*)
Intel HD 4600 HP 1998 L01 v02.71 (2017-05-09) SUCCESS SUCCESS

(*) I've got two drives in this machine: SATA drive is "not frozen", but for the NVME drive hdparm -I /dev/nvme0n1 and hdparm -I /dev/nvme0 returns nothing.

Even resolutions up to 5120x1440 are working flawlessly for me.

However, I got two machines which don't want to boot: "HP Compaq 8100 Elite" (doesn't want to boot at all) and "HP EliteDesk 800 G4" (stuck on "booting 'shredos'").

@PartialVolume
Copy link
Owner Author

PartialVolume commented Feb 22, 2022

but for the NVME drive hdparm -I /dev/nvme0n1 and hdparm -I /dev/nvme0 returns nothing.

hdparm doesn't support nvme, with nvme drives you would use nvme-cli, however I have read that even nvme-cli doesn't provide security status 'frozen' information. Don't quote me on that though as I've got no nvme hardware to test on. With nvme I think it's a case of sending ShredOS to sleep then issuing the secure erase command via nvme-cli.

This is something I'm going to have to take care of in nwipe. When it recognises a nvme drive it switches to using nvme-cli.

nvme-cli should be available on ShredOS so you may want to try a wipe using that. Let me know how it works out. I think @Firminator uses nvme-cli and may be able to help here.

nvme list
nvme format -s1 /dev/nvme0n1

      where /dev/nvme0n1 is the block name of the listed device.

-s1 meaning

0: No Secure Erase operation requested (generally speaking, this just TRIMs/deallocates all the LBAs)

1: User Data Erase – this physically erases the data on the drive. In a mainstream NAND NVMe SSD, this will trigger the erase of all the blocks as well as changing the cryptographic key. Due to the physics of NAND erases (consuming power and time) this can take some time (for large drives measured in single digit minutes)

2: Crypto Erase, this completes much faster (under 1 second in most cases) by swapping out the cryptographic key so that all data is rendered unreadable. Like all three cases, this will deallocate the LBAs and some drives may support deterministic read zero after TRIM for subsequent reads.

ref:Secure Erase: Format, and Sanitize section of open-source-nvme-management-utility-nvme-command-line-interface-nvme-cli

@PartialVolume
Copy link
Owner Author

@gorbiWTF

Even resolutions up to 5120x1440 are working flawlessly for me.

On those high resolution screens did you get to try the /bin/setfont -d command? Was the text better for reading at a distance?

@PartialVolume
Copy link
Owner Author

@gorbiWTF

However, I got two machines which don't want to boot: "HP Compaq 8100 Elite" (doesn't want to boot at all) and "HP EliteDesk 800 G4" (stuck on "booting 'shredos'").

Do those two systems have a secondary graphics card installed by any chance?

@PartialVolume
Copy link
Owner Author

@gorbiWTF Come to think of it, I think I had a HP Compaq 8100 Elite at some point and could never get the thing to boot from USB. It worked fine booting from CD though. Think I may have to build the .iso version of this pre-release.

@gorbiWTF
Copy link

but for the NVME drive hdparm -I /dev/nvme0n1 and hdparm -I /dev/nvme0 returns nothing.

hdparm doesn't support nvme, with nvme drives you would use nvme-cli, however I have read that even nvme-cli doesn't provide security status 'frozen' information. Don't quote me on that though as I've got no nvme hardware to test on. With nvme I think it's a case of sending ShredOS to sleep then issuing the secure erase command via nvme-cli.

This is something I'm going to have to take care of in nwipe. When it recognises a nvme drive it switches to using nvme-cli.

nvme-cli should be available on ShredOS so you may want to try a wipe using that. Let me know how it works out. I think @Firminator uses nvme-cli and may be able to help here.

I see. When I first send the system to sleep, then use nvme format /dev/nvme0n1 -s 1 -l 0 it says "The LBA Format specified is not supported. This may be due to various condiditions(0x10a)". However, nvme id-ns /dev/nvme0n1 -n 1 -H says "LBA FORMAT 0 : Meadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)".

@gorbiWTF

Even resolutions up to 5120x1440 are working flawlessly for me.

On those high resolution screens did you get to try the /bin/setfont -d command? Was the text better for reading at a distance?

Text size is fine for me out of the box, with the command I think it's too big. The screen only has 109 ppi, but I will try it later with a 164 ppi screen.

@gorbiWTF

However, I got two machines which don't want to boot: "HP Compaq 8100 Elite" (doesn't want to boot at all) and "HP EliteDesk 800 G4" (stuck on "booting 'shredos'").

Do those two systems have a secondary graphics card installed by any chance?

Yes, they both do.

@gorbiWTF Come to think of it, I think I had a HP Compaq 8100 Elite at some point and could never get the thing to boot from USB. It worked fine booting from CD though. Think I may have to build the .iso version of this pre-release.

Haha, well, I got the same problem when I tried to install Windows 10 from an USB drive, but a BIOS update fixed that for me.

@PartialVolume
Copy link
Owner Author

@gorbiWTF

However, I got two machines which don't want to boot: "HP Compaq 8100 Elite" (doesn't want to boot at all) and "HP EliteDesk 800 G4" (stuck on "booting 'shredos'").

Do those two systems have a secondary graphics card installed by any chance?

Yes, they both do.

It would be interesting to see if pulling out the secondary graphics card fixed either of them, at least it would indicate a graphics related issue. I don't know if you have two monitors attached but it would be worth checking the output of both video outputs. I had a similar problem, the bios allowed you to set the default card but that appeared to have no affect. Yet other systems worked nicely with two graphics cards. Funnily enough the systems who's bios allowed you to set the default card didn't work and those bios that had no video setting worked just fine. Still, I guess it's a quick test to pull the secondary card out of the system and see if ShredOS boots properly.

@PartialVolume
Copy link
Owner Author

but for the NVME drive hdparm -I /dev/nvme0n1 and hdparm -I /dev/nvme0 returns nothing.

hdparm doesn't support nvme, with nvme drives you would use nvme-cli, however I have read that even nvme-cli doesn't provide security status 'frozen' information. Don't quote me on that though as I've got no nvme hardware to test on. With nvme I think it's a case of sending ShredOS to sleep then issuing the secure erase command via nvme-cli.
This is something I'm going to have to take care of in nwipe. When it recognises a nvme drive it switches to using nvme-cli.
nvme-cli should be available on ShredOS so you may want to try a wipe using that. Let me know how it works out. I think @Firminator uses nvme-cli and may be able to help here.

I see. When I first send the system to sleep, then use nvme format /dev/nvme0n1 -s 1 -l 0 it says "The LBA Format specified is not supported. This may be due to various condiditions(0x10a)". However, nvme id-ns /dev/nvme0n1 -n 1 -H says "LBA FORMAT 0 : Meadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)".

@gorbiWTF Did you send shredos to sleep with a rtcwake -s 5 -m mem before running that command?

@PartialVolume
Copy link
Owner Author

but for the NVME drive hdparm -I /dev/nvme0n1 and hdparm -I /dev/nvme0 returns nothing.

hdparm doesn't support nvme, with nvme drives you would use nvme-cli, however I have read that even nvme-cli doesn't provide security status 'frozen' information. Don't quote me on that though as I've got no nvme hardware to test on. With nvme I think it's a case of sending ShredOS to sleep then issuing the secure erase command via nvme-cli.
This is something I'm going to have to take care of in nwipe. When it recognises a nvme drive it switches to using nvme-cli.
nvme-cli should be available on ShredOS so you may want to try a wipe using that. Let me know how it works out. I think @Firminator uses nvme-cli and may be able to help here.

I see. When I first send the system to sleep, then use nvme format /dev/nvme0n1 -s 1 -l 0 it says "The LBA Format specified is not supported. This may be due to various condiditions(0x10a)". However, nvme id-ns /dev/nvme0n1 -n 1 -H says "LBA FORMAT 0 : Meadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)".

@gorbiWTF Did you send shredos to sleep with a rtcwake -s 5 -m mem before running that command?

@gorbiWTF Sorry, just reread your comment, looks like you did send the system to sleep before running that command.

@PartialVolume
Copy link
Owner Author

but for the NVME drive hdparm -I /dev/nvme0n1 and hdparm -I /dev/nvme0 returns nothing.

hdparm doesn't support nvme, with nvme drives you would use nvme-cli, however I have read that even nvme-cli doesn't provide security status 'frozen' information. Don't quote me on that though as I've got no nvme hardware to test on. With nvme I think it's a case of sending ShredOS to sleep then issuing the secure erase command via nvme-cli.
This is something I'm going to have to take care of in nwipe. When it recognises a nvme drive it switches to using nvme-cli.
nvme-cli should be available on ShredOS so you may want to try a wipe using that. Let me know how it works out. I think @Firminator uses nvme-cli and may be able to help here.

I see. When I first send the system to sleep, then use nvme format /dev/nvme0n1 -s 1 -l 0 it says "The LBA Format specified is not supported. This may be due to various condiditions(0x10a)". However, nvme id-ns /dev/nvme0n1 -n 1 -H says "LBA FORMAT 0 : Meadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)".

@gorbiWTF Did you send shredos to sleep with a rtcwake -s 5 -m mem before running that command?

@gorbiWTF Sorry, just reread your comment, looks like you did send the system to sleep before running that command.

Is the system shutting down so there is no display (or backlight) and all fans are off and if there are any spinning discs they have stopped spinning? One thing to check is whether the bios contains any ACPI settings, I found one of my systems was not powering down sufficiently because there was a setting that was set as S1 when it needed to be S3. Could be something like that. Maybe there is something specific in the bios for M2 or nmve power managment?

@gorbiWTF
Copy link

gorbiWTF commented Feb 24, 2022

but for the NVME drive hdparm -I /dev/nvme0n1 and hdparm -I /dev/nvme0 returns nothing.

hdparm doesn't support nvme, with nvme drives you would use nvme-cli, however I have read that even nvme-cli doesn't provide security status 'frozen' information. Don't quote me on that though as I've got no nvme hardware to test on. With nvme I think it's a case of sending ShredOS to sleep then issuing the secure erase command via nvme-cli.
This is something I'm going to have to take care of in nwipe. When it recognises a nvme drive it switches to using nvme-cli.
nvme-cli should be available on ShredOS so you may want to try a wipe using that. Let me know how it works out. I think @Firminator uses nvme-cli and may be able to help here.

I see. When I first send the system to sleep, then use nvme format /dev/nvme0n1 -s 1 -l 0 it says "The LBA Format specified is not supported. This may be due to various condiditions(0x10a)". However, nvme id-ns /dev/nvme0n1 -n 1 -H says "LBA FORMAT 0 : Meadata Size: 0 bytes - Data Size: 512 bytes - Relative Performance: 0 Best (in use)".

@gorbiWTF Did you send shredos to sleep with a rtcwake -s 5 -m mem before running that command?

@gorbiWTF Sorry, just reread your comment, looks like you did send the system to sleep before running that command.

Is the system shutting down so there is no display (or backlight) and all fans are off and if there are any spinning discs they have stopped spinning? One thing to check is whether the bios contains any ACPI settings, I found one of my systems was not powering down sufficiently because there was a setting that was set as S1 when it needed to be S3. Could be something like that. Maybe there is something specific in the bios for M2 or nmve power managment?

Yes, the system is shutting down like all other system, the SATA drive correctly changes from "frozen" to "not frozen" but I can't use nvme format on the NVME drive.

There are no BIOS options regarding the NVME drive, and changing the only power option ("Enhanced Power Saving Mode") isn't helping.

@gorbiWTF
Copy link

@gorbiWTF

However, I got two machines which don't want to boot: "HP Compaq 8100 Elite" (doesn't want to boot at all) and "HP EliteDesk 800 G4" (stuck on "booting 'shredos'").

Do those two systems have a secondary graphics card installed by any chance?

Yes, they both do.

It would be interesting to see if pulling out the secondary graphics card fixed either of them, at least it would indicate a graphics related issue. I don't know if you have two monitors attached but it would be worth checking the output of both video outputs. I had a similar problem, the bios allowed you to set the default card but that appeared to have no affect. Yet other systems worked nicely with two graphics cards. Funnily enough the systems who's bios allowed you to set the default card didn't work and those bios that had no video setting worked just fine. Still, I guess it's a quick test to pull the secondary card out of the system and see if ShredOS boots properly.

I removed the graphics card from the HP EliteDesk 800 G4 and then ShredOS worked as expected. I can't remove the graphics card from the other system because the iGPU isn't working anymore.

I also tried it on my notebook with an external screen: "booting 'shredos'" is showing up on the integrated screen (and always stays there), while the UI is on the external screen.

@gorbiWTF
Copy link

Graphics Motherboard Bios Notes etc rtcwake status hdparm frozen state (success=not frozen
Intel HD 4400 Acer Veriton X4630G P11-A0L (2013-08-15) SUCCESS SUCCESS
Intel HD 530 Fujitsu D3400-A1 v5.0.0.11 R1.29.0 for D3400-A1x (2020-01-27) SUCCESS SUCCESS
Intel HD 2000 HP 1495 J01 v02.06 (2011-06-09) SUCCESS SUCCESS
Intel HD 5500 + Radeon R9 M275X Lenovo Z51-70 C2CN19WWCU2.00 (2015-07-14) system just reboots -
Nvidia 1650 Ti Mobile + AMD Renoir (Ryzen 7 4800H) SchenkerTechnologiesGmbH GK7NxxR M20 N.1.20.A03 (2020-12-10) system turns off but not back on -

I also got a HP Compaq dc7900 Convertible MT which can't boot (it just flashes an underscore cursor).

@PartialVolume
Copy link
Owner Author

PartialVolume commented Feb 24, 2022

I also got a HP Compaq dc7900 Convertible MT which can't boot (it just flashes an underscore cursor).

Does this boot with the previous version:
.img shredos-2021.08.2_21_x86-64_0.32.023_20220123.img
or
.iso shredos-2021.08.2_21_x86-64_0.32.023_20220126.iso

If it boots with the .iso then at least we know it's likely to be the HP USB boot issue rather than a graphics issue.

@Alphakilo
Copy link

Alphakilo commented Dec 13, 2022

Adding to the list a HPE ProLiant Microserver Gen8

Graphics Motherboard Bios Notes etc rtcwake status hdparm frozen state (success=not frozen
Matrox MGA 200EH Gen8 Microserver Option Number 819185-001 J06 05/21/2018 - HP Dynamic Smart Array B120i controller SUCCESS FAILURE
for d in sd{a,b,c,d}; do hdparm -I /dev/$d | grep frozen; done
   frozen
   frozen
   frozen
   frozen

What does however work is hot-plugging the drives. That should work on every platform. So far the best results I've achieved was by reconnecting the power cable, while the data cable stayed in place.

@PartialVolume
Copy link
Owner Author

PartialVolume commented Apr 2, 2023

Closing, as we now have switched to Linux DRM and include all the necessary firmware for most graphics cards, rtcwake -m mem -s 5 should work fine on the majority of systems. Please re-open if you have a system it doesn't work on.

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

4 participants