Tiny Core Base > TCB Talk
Suspend (to ram)
cv007:
This is a long shot, but here is my question-
I use Tinycore kernel + my custom core.gz for a specific purpose. I am trying to add one more 'purpose'- erasing hard drives, which I do often enough. Previously, I have been using DBAN, but it has problems booting on some pc's (Tinycore has never failed me). I wrote my own c utility to 'wipe' a hard drive with random data (random enough for my purposes, and not really necessary), which works fine.
Recently, I discovered (about 15? years late), that the ata standard provides for 'secure-erase' commands, which may be nice for spinning hard drives, and may be necessary for ssd's. So I test secure erase using hdparm, and it works ok although it is not any faster than my utility (takes the same time, so at least my program and linux are feeding the drive as fast as possible). The main advantage it seems, is that the enhanced secure erase will erase data in the sectors marked as bad (by the drive).
The problems are- the secure erase does not work with usb-sata adapters (like external usb drives), and it seems the BIOS of the several pc's I used to test put the hard drive in 'security freeze' when they boot.
To 'unfreeze' the drive, you can suspend/resume (I'm told), then because the drive powered down, powered on- it reset itself and since it did not receive the 'freeze' command from BIOS (after the drive powered up), it is now 'not frozen'. My question will be about suspending in Tinycore, but a few more comments before I ask.
What I have tried- I can spin down/spin up the hard drive by sending commands to somewhere in /sys (don't remember what they were now)- which spins down the drive, spins it back up, redetects the drive, but the 'frozen' status does not change (the drive is spinning down, goes offline, but drive controller never resets). There may be a proper way to actually reset the controller, but I have not found it. What does work, but is not really a good solution, is to simply pull the power connector from the drive, plug it back in, then the drive will be 'not frozen'.
I have not been able to properly try the suspend method (echo -n mem > sys/power/state), as I cannot get Tinycore to show video after the resume . The suspend works, resume works, keyboard works, but no video after resume. I am using a framebuffer video mode (800x600x16)- console only, no X.
Question- is there some trick I'm missing to suspend/resume?
Thanks.
curaga:
No, I'm afraid you're not missing anything, but just hitting the not-so-reliable suspend.
A couple things you can try:
- text mode instead of fb
- the s2ram utility has some additional options for video cards
cv007:
I suspected.
Testing is usually done in qemu before I run on hardware, and qemu acts the same way so I suspect it is a 'generic' problem instead of specific to certain hardware. I did try text mode in qemu, and then the resume works ok, so it must have something to do with the graphics mode not getting set after the resume. At least I now have some more ideas to google.
In the end, secure-erase may not be worth the hassle, as the only thing gained is wiping bad blocks which in my case is not really necessary. The other thing you lose with secure-erase, is you simply have to wait until its done (estimated time only, not knowing what progress is being made), where a wipe utility can show progress.
Thanks.
Alatun:
Perhaps the ATA spec will help: http://www.t13.org/documents/UploadedDocuments/docs2011/d2015r7-ATAATAPI_Command_Set_-_2_ACS-2.pdf
It's only a draft, because the final version is only available when you buy it.
The "UNLOCK SECURTIY" command will put the drive back to normal, but I think this won't help, because you need the 32 byte password. Probably the BIOS will hash/salt any user input to generate it. A soft reset will not help I think, because that would be to easy to circumvent this security feature.
If it is feasible for you, I would put the drives into a system that doesn't use the "SECURITY FREEZE LOCK" stuff and simply avoid this problem.
cv007:
The problem is most of the pc's I see (name brands) security freeze the drive on powerup (after which no more security commands are accepted). No way around that, and probably a good idea to prevent security commands being sent to the drive after the bios is done doing its thing (ransomware). Even if you correctly send a device reset to the drive, the security freeze setting will survive the reset. The only way to unfreeze a drive on these pc's (without having to remove it from the pc its in) is to get the power removed from the drive with suspend (resume will not give bios opportunity to freeze drive) , or pull the power cable on the drive and plug it back in.
If I was willing to give up 800x600 framebuffer mode and stay in text mode, I think I could get suspend to work. For the time being, I simply pop the cover, remove/re-attache power to the drive and do a secure erase (or just run my drive wiper utility). In many cases, I am working with a drive that has been removed from the pc, so then have many options.
I did find an instance that secure erase may be handy- when the drive is having problems, it seems the secure erase can do its thing whether it has read/write errors or not. I had a (bad) large drive which I tried to do my normal wipe, and it was very slow (about 20x slower than normal), so I did a secure erase instead and it finished in its estimated time.
Navigation
[0] Message Index
[#] Next page
Go to full version