Bug#651691: closed by Rodolfo García Peñas (kix) k...@debian.org (Re: uswsusp needs specialkernel parameter to resume)
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)
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)
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)
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