Bug#651691: closed by Rodolfo García Peñas (kix) k...@debian.org (Re: uswsusp needs specialkernel parameter to resume)

2013-12-27 Thread Joerg Dorchain
On Fri, Dec 27, 2013 at 12:06:05PM +, Debian Bug Tracking System wrote:
 I am closing this bug because I have no reply with in the last email.

Sorry, I did not notice it.

 
 uswsusp didsn't change their behavior, but other packages (like
 initramfs-tools) had changes. Please, test with other versions of
 uswsusp and initramfs-tools and reopen this bug if you think that the
 bug was not solved.
 
 I tested some versions here, and I cannot reproduce the problem. If
 you reopen the bug, please, include the info about the latest
 initramfs-tools and uswsusp package, and the configuration for
 /etc/uswsusp.conf and /etc/initramfs-tools/conf.d/resume files.

I checked the initramfs generated by a version of debian testing
of today (including uswsusp 1.0+20120915-4)

The file in question is scripts/local-premount/uswsusp, which
belongs to the uswsusp package.

Here, the line 
[ -n ${resume} ] || exit 0;
implies the resume variable (set in init from parsing the command
line) must be set in order to resume.

Former versions checked for the noresume variable and did not
resume when it was set (also set in init)

Bye,

Joerg


signature.asc
Description: Digital signature


Bug#651691: closed by Rodolfo García Peñas (kix) k...@debian.org (Re: uswsusp needs specialkernel parameter to resume)

2013-12-27 Thread Rodolfo García Peñas
On Fri, 27 Dec 2013, Joerg Dorchain escribió:

 On Fri, Dec 27, 2013 at 12:06:05PM +, Debian Bug Tracking System wrote:
  I am closing this bug because I have no reply with in the last email.
 
 Sorry, I did not notice it.

No problem, if you think the problem is not solved, I will reopen the bug.
 
  
  uswsusp didsn't change their behavior, but other packages (like
  initramfs-tools) had changes. Please, test with other versions of
  uswsusp and initramfs-tools and reopen this bug if you think that the
  bug was not solved.
  
  I tested some versions here, and I cannot reproduce the problem. If
  you reopen the bug, please, include the info about the latest
  initramfs-tools and uswsusp package, and the configuration for
  /etc/uswsusp.conf and /etc/initramfs-tools/conf.d/resume files.
 
 I checked the initramfs generated by a version of debian testing
 of today (including uswsusp 1.0+20120915-4)
 
 The file in question is scripts/local-premount/uswsusp, which
 belongs to the uswsusp package.
 
 Here, the line 
 [ -n ${resume} ] || exit 0;
 implies the resume variable (set in init from parsing the command
 line) must be set in order to resume.

I don't agree :-)

Yes, the file /usr/share/initramfs-tools/scripts/local-premount/uswsusp belongs 
to uswsusp. The script checks if the $resume variable is set. If is set, then 
the script calls /sbin/resume to load the save image. If is not set, is because 
the system was not hibernated (normal boot).

But it doesn't mean that the resume variable is set as kernel parameter.

You can test the initramfs-tools script to resume 
(/usr/share/initramfs-tools/scripts/local-premount/resume) and you will see the 
same:

---8---
if [ -z ${resume} ]; then
exit 0
fi
---8---

 Former versions checked for the noresume variable and did not
 resume when it was set (also set in init)

The noresume is used in the /usr/share/initramfs-tools/init script:

---8---
noresume)
noresume=y
;;
---8---
...
---8---
if [ -n ${noresume} ]; then
export noresume
unset resume
else
resume=${RESUME:-}
fi
---8---

If the variable resume was set, with the noresume option as kernel parameter, 
is unset.
 
 Bye,
 
 Joerg

Regards,
kix
-- 
 .''`.  Rodolfo García Peñas (kix) k...@debian.org
: :'  : Proud Debian Developer
`. `'`  4096R / 3F48 0B8C C385 AD41 9E28  006A 7B1F 5490 72B7 4923
 `- Debian - when you have better things to do than fixing systems


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#651691: closed by Rodolfo García Peñas (kix) k...@debian.org (Re: uswsusp needs specialkernel parameter to resume)

2013-12-27 Thread Joerg Dorchain
On Fri, Dec 27, 2013 at 09:27:18PM +0100, Rodolfo García Peñas wrote:
 
 I don't agree :-)
 
 Yes, the file /usr/share/initramfs-tools/scripts/local-premount/uswsusp
 belongs to uswsusp. The script checks if the $resume variable is set. If is
 set, then the script calls /sbin/resume to load the save image. If is not
 set, is because the system was not hibernated (normal boot).
 
 But it doesn't mean that the resume variable is set as kernel parameter.

To my understanding /proc/cmdline is used to parse the variables
in the init script parameters, but let's not be picky about it.

[...]
 If the variable resume was set, with the noresume option as kernel parameter,
 is unset.

I think I understand the resulting semantics of the scripts. My
point is more but I preferred the old behaviour, and changing
user visible behaviour without a mentioning it somewhere
prominently is what I would call a regression.

Esp. since if you boot without resuming once, you have no chance
to resume to the old state again, since the swap device is
overwritten, which can be quite unpleasant.

Bye,

Joerg


signature.asc
Description: Digital signature


Bug#651691: closed by Rodolfo García Peñas (kix) k...@debian.org (Re: uswsusp needs specialkernel parameter to resume)

2013-12-27 Thread Rodolfo García Peñas
On Fri, 27 Dec 2013, Joerg Dorchain escribió:

 On Fri, Dec 27, 2013 at 09:27:18PM +0100, Rodolfo García Peñas wrote:
 [...]
  If the variable resume was set, with the noresume option as kernel 
  parameter,
  is unset.
 
 I think I understand the resulting semantics of the scripts. My
 point is more but I preferred the old behaviour, and changing
 user visible behaviour without a mentioning it somewhere
 prominently is what I would call a regression.
 
 Esp. since if you boot without resuming once, you have no chance
 to resume to the old state again, since the swap device is
 overwritten, which can be quite unpleasant.
 
 Bye,
 
 Joerg

Hi Joerg,

I don't understand when you say old behaviour. I was working in uswsusp but I 
didn't change the behaviour. I added some things, like UUID support,... but 
with the same behaviour.

I was checking previous uswsusp versions, and I didn't see big differences with 
the old code. I am not sure if the problem is with uswsusp or with other Debian 
packages (initramfs-tools?). Could you help me to discover when the behaviour 
changed?

Old uswsusp package versions are here: 
http://snapshot.debian.org/package/uswsusp/

You can download the old binary packages. I started to work in uswsusp in 
version 1.0-1, so testing versions 0.8-1.2, 1.0-1 could help.

Thanks for your help.
kix.
-- 
 .''`.  Rodolfo García Peñas (kix) k...@debian.org
: :'  : Proud Debian Developer
`. `'`  4096R / 3F48 0B8C C385 AD41 9E28  006A 7B1F 5490 72B7 4923
 `- Debian - when you have better things to do than fixing systems


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org