Re: suspend to disk unreliable?
On Sun, Jul 04, 2010 at 04:42:46PM +0000, Camaleón wrote:
> On Sun, 04 Jul 2010 18:02:47 +0200, lee wrote:
>
> > On Sat, Jul 03, 2010 at 04:00:57PM +0000, Camaleón wrote:
>
> >> Then you can setup a chrooted environment and make the tests in there.
> >> Or you can try with a LiveCD to avoid data loss. Nowadays you have many
> >> choices to test hibernation in a safe environment.
> >
> > There's nothing save about turning off and on the hardware many times
> > consecutively. I could disconnect the disks to minimize the risks, but
> > then it won't be possible to test suspend to disk.
>
> You cannot disconnect the main disk because hibernation saves the image of
> the running system there (unless you manually change the location).
Sure I can disconnect the disks. But as I said, I won't be able to
test suspending to disk then.
> But again, if you want to safely test hibernation on your system, go with
> a LiveCD
And save the image on the live CD when suspending to disk?
> or install Debian into an old disk connected via USB. There you
> can make any test you want without worring about losing your data.
I don't have an old disk I could use for this. And what about the rest
of the hardware? Disconnect or remove that as well so that it can't be
damaged?
> >> If developers are not aware of your situation, they cannot correct the
> >> bugs
> >
> > Still filing bug reports doesn't seem to achieve anything these days.
>
> I think that is a bad attitude,
It's only my experience. What would that have to do with attitude?
> No sir. I'm afraid you still are not getting the inners of how
> hibernation works.
When hardware doesn't work and it's still under warranty, I return
it. That doesn't have to do anything with suspending to disk.
> When testing hibernation you are not testing a piece of hardware
> "separately" but a complete system (drivers, programs, hardware, kernel,
> DE tools...). Hardware can perform and work nice but not drivers, and the
> manufacturer has not provided you with any driver for that hardware.
It's still something that should work out of the box.
> >> > No manufacturer or dealer is going to give you a certificate that the
> >> > car in question will perform as desired under your particular
> >> > driving/using conditions.
> >>
> >> Sure they do!
> >
> > They don't --- or can you show me the certificate you got for your car
> > and a number of others other ppl got?
>
> Read on...
>
> <http://www.google.com/webhp?hl=en#hl=en&q=car+warranty+voided&fp=849006b7ea50a009>
Where's your certificate showing that your car is certified to perform
flawlessly under your particular driving conditions? And where are
such certifactes of other car owners?
> >> >> >> What "required tools" are you referring to?
> >> >> >
> >> >> > the tools needed for graphics cards
> >> >>
> >> >> There no such tools. What you usually have to do when the graphics
> >> >> card driver (or any other driver) has problems to resume from
> >> >> hibernating is creating a hook to load/unload the required driver,
> >> >> that should be all.
> >> >
> >> > The documentation says that there are. Perhaps what you're describing
> >> > is what these tools do ...
> >>
> >> If the docs say that "there are", it will also say "where to get" them
> >> >:-)
> >
> > Yet you say there are no such tools.
>
> No, I say that I dunno about any special tool for vga.
See above, you said "There are no such tools.".
> Just tell me where in the docs it says there are tools for graphic
> cards, besides the hook scripts I told you before that are used in
> hibernation/resume operations.
see /usr/share/doc/uswsusp/README
As sid before, the directories where the hook scripts would be are
empty.
Reply to: