Processed: Re: Bug#397214: overwrites values in /etc/uswsusp.conf
Processing commands for [EMAIL PROTECTED]: tags 397214 -patch Bug#397214: overwrites values in /etc/uswsusp.conf Tags were: patch Tags removed: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397214: overwrites values in /etc/uswsusp.conf
tags 397214 -patch thanks On Tue, 14 Nov 2006 23:16:03 + (GMT) Matthew Johnson [EMAIL PROTECTED] wrote: For more detail, what actually happens is that the config file is regenerated on upgrade from the original debconf questions. This is not true. It is regenerated from what is in the config file and any new answers. If you read the code carefully you see that it fills all the question with the values from the file. (except for splash, which is the real bug) b. several of the questions are not asked by debconf because of their priority. It's not immediately obvious how these should be configured since dpkg-reconfigure still doesn't ask them due to their debconf priority (in particular splash). The priority has nothing to do with it, the splash question is not asked at all. This is because splash was not supported yet. The current splash only works with the bootsplash kernel patch, which isn't applied to the debian kernel. I added the splash question because I've written a userspace splash library which can also be linked to uswsusp, but it isn't in debian yet. It's not clear that the automatic generation should happen more than once; I think it should happen only if the config file doesn't exist. No. That way people can't use dpkg-reconfigure. Using dpkg-reconfigure is convenient because that will also regenerate the initramfs and the encryption keys if you asked for it. To summarize, you bug is a different one. It sneaked in because splash was not supposed to be supported yet, but apparently you are using a patched kernel. The solution is very simple and is already in my svn. It will be included in the next upload. grts Tim signature.asc Description: PGP signature
Bug#397214: overwrites values in /etc/uswsusp.conf
On Wed, 15 Nov 2006, Tim Dijkstra wrote: For more detail, what actually happens is that the config file is regenerated on upgrade from the original debconf questions. This is not true. It is regenerated from what is in the config file and any new answers. If you read the code carefully you see that it fills all the question with the values from the file. (except for splash, which is the real bug) The postinst that I have (0.3~cvs20060928-2) does: # If we didn't got a value, we want the hardcoded default, # so del if [ -z $VAL ]; then SEDCMD=$SEDCMD -e '/$PATRN/ d' which means that if $VAL is not set in the debconf answers that line will be removed from the config file. b. several of the questions are not asked by debconf because of their priority. It's not immediately obvious how these should be configured since dpkg-reconfigure still doesn't ask them due to their debconf priority (in particular splash). The priority has nothing to do with it, the splash question is not asked at all. This is because splash was not supported yet. The current splash only works with the bootsplash kernel patch, which isn't applied to the debian kernel. I added the splash question because I've written a userspace splash library which can also be linked to uswsusp, but it isn't in debian yet. I am using the stock debian kernel from etch with splashy (a user-space splash program) which is in unstable with version number 0.1.8.1-3.1 It's not clear that the automatic generation should happen more than once; I think it should happen only if the config file doesn't exist. No. That way people can't use dpkg-reconfigure. Using dpkg-reconfigure is convenient because that will also regenerate the initramfs and the encryption keys if you asked for it. However, it should either not overwrite changes (even if you don't think there is a suitable splash system without recompiling the kernel, I think it ought to be supported) or should be clearer in the config file that an upgrade will overwrite and provide _all_ the questions in debconf. To summarize, you bug is a different one. It sneaked in because splash was not supposed to be supported yet, but apparently you are using a patched kernel. The solution is very simple and is already in my svn. It will be included in the next upload. If it's fixed in the next upload given the rest of my comments, then fine, but I'd like to see at least more of a warning in the config file, and the README.Debian should _not_ say If your not happy with it you can choose to alter it by hand or... Sorry for hassling you on this; I'm really happy with uswsusp in general, it works really well. The integration with splashy is also cool (although on resume it fails to init directfb, so I don't get a splash screen for that; that's presumably splashy's problem, not yours though) HTH, Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397214: overwrites values in /etc/uswsusp.conf
On Wed, 15 Nov 2006 10:37:38 + (GMT) Matthew Johnson [EMAIL PROTECTED] wrote: On Wed, 15 Nov 2006, Tim Dijkstra wrote: The postinst that I have (0.3~cvs20060928-2) does: # If we didn't got a value, we want the hardcoded default, # so del if [ -z $VAL ]; then SEDCMD=$SEDCMD -e '/$PATRN/ d' which means that if $VAL is not set in the debconf answers that line will be removed from the config file. But in the config script you'll see that the values from the config file are put as the default answer in the debconf database. I am using the stock debian kernel from etch with splashy (a user-space splash program) which is in unstable with version number 0.1.8.1-3.1 I know splashy, I'm one of the upstream authors. In the 0.3 series there will be a libsplashy which can be linked to uswsusp (created by yours truly, especially for this purpose), untill then it will not work. However, it should either not overwrite changes (even if you don't think there is a suitable splash system without recompiling the kernel, I think it ought to be supported) or should be clearer in the config file that an upgrade will overwrite and provide _all_ the questions in debconf. It will not overwrite, I explained that it will only do that for splash, which I do agree, is a bug. Not having splash support was not the reason I designed the script to overwrite your changes. It was simply the reason I didn't discover the bug myself. Nothing more, a bug. If it's fixed in the next upload given the rest of my comments, then fine, but I'd like to see at least more of a warning in the config file, and the README.Debian should _not_ say If your not happy with it you can choose to alter it by hand or... That sentence will stay. Reconfiguring uswsusp (should) KEEP ALL LOCAL CHANGES. There are two separate bugs in this report that need, and can be fixed. Sorry for hassling you on this; I'm really happy with uswsusp in general, it works really well. The integration with splashy is also cool (although on resume it fails to init directfb, so I don't get a splash screen for that; that's presumably splashy's problem, not yours though) I'm confused... Dit you compile with libsplashy from svn? Else you wouldn't get any splash at all on suspend/resume... splashy is not really mature yet. It has some problems with initramfs. Also the combination initramfs and uswusp+libsplashy is not working properly yet. But that will come. grts Tim signature.asc Description: PGP signature
Bug#397214: overwrites values in /etc/uswsusp.conf
On Wed, 15 Nov 2006, Tim Dijkstra wrote: # If we didn't got a value, we want the hardcoded default, # so del if [ -z $VAL ]; then SEDCMD=$SEDCMD -e '/$PATRN/ d' which means that if $VAL is not set in the debconf answers that line will be removed from the config file. But in the config script you'll see that the values from the config file are put as the default answer in the debconf database. I don't see that behavior, that's a good one to have though if it works. The postinst I have definitely looks for the splash value in debconf and removes it from the config file because it's not there. It will not overwrite, I explained that it will only do that for splash, which I do agree, is a bug. Not having splash support was not the reason I designed the script to overwrite your changes. It was simply the reason I didn't discover the bug myself. Nothing more, a bug. Fair enough Sorry for hassling you on this; I'm really happy with uswsusp in general, it works really well. The integration with splashy is also cool (although on resume it fails to init directfb, so I don't get a splash screen for that; that's presumably splashy's problem, not yours though) I'm confused... Dit you compile with libsplashy from svn? Else you wouldn't get any splash at all on suspend/resume... splashy is not really mature yet. It has some problems with initramfs. Also the combination initramfs and uswusp+libsplashy is not working properly yet. But that will come. Yes, I did (I recall). It works fine on suspend, there is an issue (directfb fails to create an image provider) with it in the initramfs. Thanks, Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397214: overwrites values in /etc/uswsusp.conf
Package: uswsusp Version: 0.3~cvs20060928-2 Followup-For: Bug #397214 I also confirm this bug. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (700, 'testing'), (600, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages uswsusp depends on: ii debconf [debconf-2.0]1.5.8 Debian configuration management sy ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libgcrypt11 1.2.3-2 LGPL Crypto library - runtime libr ii libgpg-error01.4-1 library for common error values an Versions of packages uswsusp recommends: ii initramfs-tools 0.84 tools for generating an initramfs -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397214: overwrites values in /etc/uswsusp.conf
For more detail, what actually happens is that the config file is regenerated on upgrade from the original debconf questions. However, this a. discards any local changes not made through debconf (should we allow these? if not the warning in the conf file should be bigger!) and b. several of the questions are not asked by debconf because of their priority. It's not immediately obvious how these should be configured since dpkg-reconfigure still doesn't ask them due to their debconf priority (in particular splash). It's not clear that the automatic generation should happen more than once; I think it should happen only if the config file doesn't exist. Matt -- Matthew Johnson http://www.matthew.ath.cx/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397214: overwrites values in /etc/uswsusp.conf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
tags 397214 patch
thanks
On Tue, 14 Nov 2006, Matthew Johnson wrote:
It's not clear that the automatic generation should happen more than
once; I think it should happen only if the config file doesn't exist.
I've attached a patch which does this. Basically, the test for the
config file existing is extended to around the whole block. Also,
TMPFILE isn't ever deleted, so we do that too.
- --
Matthew Johnson
http://www.matthew.ath.cx/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQFFWlVepldmHVvob7kRAnbYAJ0WWspGs8UYl5ImF/6e7WDrog6gYwCdHFXj
A3lv93kNqHiu14zi3RSb2q0=
=zsl1
-END PGP SIGNATURE-
diff -u uswsusp-0.3~cvs20060928/debian/uswsusp.postinst
uswsusp-0.3~cvs20060928.new/debian/uswsusp.postinst
--- uswsusp-0.3~cvs20060928/debian/uswsusp.postinst 2006-11-14
23:29:08.0 +
+++ uswsusp-0.3~cvs20060928.new/debian/uswsusp.postinst 2006-11-14
23:28:39.464412500 +
@@ -34,47 +34,51 @@
# db_get uswsusp/resume_device
#if [ -n $RET ]; then exit(0); fi
+ # Don't upgrade config file if one exists!
+ #
if [ ! -f $CONFIGFILE -o ! -s $CONFIGFILE ]; then
echo # $CONFIGFILE(8) -- Configuration file for s2disk/s2both
$CONFIGFILE
- fi
- TMPFILE=`mktemp`
- cp -a -f $CONFIGFILE $TMPFILE
+ TMPFILE=`mktemp`
+ cp -a -f $CONFIGFILE $TMPFILE
+
+ SEDCMD=
+
+ for I in $MEDQ $LOWQ $HIGHQ $CRYPTQ; do
+ db_get uswsusp/$I
+ VAL=$RET
+
+ db_metaget uswsusp/$I type
+ TYPE=$RET
+
+ if [ boolean = $TYPE ]; then
+ if [ $VAL = true ]; then
+ VAL=y;
+ else
+ VAL=
+ fi
+ fi
+
+ PATRN=^[[:space:]]*${I//_/ }[[:space:]]*[:=]
+
+ # If we didn't got a value, we want the hardcoded default, so del
+ if [ -z $VAL ]; then
+ SEDCMD=$SEDCMD -e '/$PATRN/ d'
+ # Else, rewrite the value
+ elif eval grep -q -e '$PATRN' $CONFIGFILE; then
+ SEDCMD=$SEDCMD -e 's/$PATRN.*$/${I//_/ } = ${VAL//\//\\/}/'
+ # Or add it
+ else
+ SEDCMD=$SEDCMD -e '$ a ${I//_/ } = $VAL'
+ fi
+
+ done
+
+ eval sed $SEDCMD $CONFIGFILE $TMPFILE
+ mv -f $TMPFILE $CONFIGFILE
- SEDCMD=
-
- for I in $MEDQ $LOWQ $HIGHQ $CRYPTQ; do
- db_get uswsusp/$I
- VAL=$RET
-
- db_metaget uswsusp/$I type
- TYPE=$RET
-
- if [ boolean = $TYPE ]; then
- if [ $VAL = true ]; then
- VAL=y;
- else
- VAL=
- fi
- fi
-
- PATRN=^[[:space:]]*${I//_/ }[[:space:]]*[:=]
-
- # If we didn't got a value, we want the hardcoded default, so del
- if [ -z $VAL ]; then
- SEDCMD=$SEDCMD -e '/$PATRN/ d'
- # Else, rewrite the value
- elif eval grep -q -e '$PATRN' $CONFIGFILE; then
- SEDCMD=$SEDCMD -e 's/$PATRN.*$/${I//_/ } = ${VAL//\//\\/}/'
- # Or add it
- else
- SEDCMD=$SEDCMD -e '$ a ${I//_/ } = $VAL'
- fi
-
- done
-
- eval sed $SEDCMD $CONFIGFILE $TMPFILE
- mv -f $TMPFILE $CONFIGFILE
+ rm $TMPFILE
+ fi
db_get uswsusp/create_RSA_key
VAL=$RET
Bug#397214: overwrites values in /etc/uswsusp.conf
On Mon, 06 Nov 2006 12:42:40 +0100
Frank Küster [EMAIL PROTECTED] wrote:
Vagrant Cascadian [EMAIL PROTECTED] wrote:
Package: uswsusp
Version: 0.3~cvs20060928-2
Severity: serious
Justification: Policy 10.7.3
i had locally modified my /etc/uswsusp.conf to use a different resume
device, but on a recent upgrade, it over-wrote my configuration file
changes without asking.
this also results in my resume partition getting written to a device it
can't read from(an encrypted swap device on lvm), which could cause
data loss if i do not manually regenerate the initramfs image and try to
use s2disk.
I think standard resume is started after encrypted swap is setup, so you
should be able to use it without problems.
At a short glance, it looks like the config script sets resume_device
unconditionally to the first partition in /proc/swap (or rather, the
first one produced from
sort -r -k 3 /proc/swaps | awk '$2==partition {print $1}'
) without asking or, what's more important, without checking the
configuration file. Later, the postinst script enters this value into
the configuration file, which would be correct if the config script had
taken it from there.
Thanks for looking in to this Frank, but I think you're mistaking. What
it does (well, is supposed to do) is make a debconf list of valid swap
partitions, with the biggest as the default. Then it parses the config
file and set values it found as the answers to the questions. Depending
on the priority the questions are then asked or not.
So the only scenario I can imagine that this goes wrong is that the swap
partition you configured in /etc/uswsusp.conf is not active at the time
of the upgrade.
Vagrant, was that the case? Can you send me the content of /proc/swaps?
Frank, did you have the same problem or where you just bug-hunting?
grts Tim
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397214: overwrites values in /etc/uswsusp.conf
Tim Dijkstra [EMAIL PROTECTED] wrote:
Thanks for looking in to this Frank, but I think you're mistaking. What
it does (well, is supposed to do) is make a debconf list of valid swap
partitions, with the biggest as the default. Then it parses the config
file and set values it found as the answers to the questions. Depending
on the priority the questions are then asked or not.
You are right, I didn't read on carefully enough
So the only scenario I can imagine that this goes wrong is that the swap
partition you configured in /etc/uswsusp.conf is not active at the time
of the upgrade.
Vagrant, was that the case? Can you send me the content of /proc/swaps?
Frank, did you have the same problem or where you just bug-hunting?
I was just bug-hunting. I don't know what the reason was why the device
was unavailable, but I think there may be valid setups where this is the
case. As an extreme example, one might want to save the current state
to a swap device on a removable medium and try to conserve it as a
snapshot, or boot a cloned machine to the same state.
What about something like
if ! echo $SWAPLIST | grep -q $SWAPDEFAULT; then
# add the SWAPDEFAULT device to SWAPLIST
SWAPDEFAULT=${SWAPDEFAULT} # currently not available
SWAPLIST=${SWAPLIST}${KOMMA}${SWAPDEFAULT}
fi
right after populating SWAPLIST? Hm, the comment might need special
treatment later on, since it's probably not yet in the configuration
file. And of course it assumes that the configuration file may contain
in-line comments.
Regards, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Bug#397214: overwrites values in /etc/uswsusp.conf
On Mon, 13 Nov 2006 15:46:44 +0100
Frank Küster [EMAIL PROTECTED] wrote:
I was just bug-hunting. I don't know what the reason was why the device
was unavailable, but I think there may be valid setups where this is the
case.
I just read in another report by Vagrant that he was trying to use a special
purpose swap partition for suspending only. And indeed it wasn't active during
the upgrade.
What about something like
if ! echo $SWAPLIST | grep -q $SWAPDEFAULT; then
# add the SWAPDEFAULT device to SWAPLIST
SWAPDEFAULT=${SWAPDEFAULT} # currently not available
SWAPLIST=${SWAPLIST}${KOMMA}${SWAPDEFAULT}
fi
right after populating SWAPLIST? Hm, the comment might need special
treatment later on, since it's probably not yet in the configuration
file. And of course it assumes that the configuration file may contain
in-line comments.
The config format doesn't allow for in-line comments, but that could be fixed
of course...
I am inclined however to just add the value from the configuration file to the
list. If people want to change the configuration file by hand, they should be
allowed to shoot themselves it the foot. The worst that can happen is that
the partition doesn't exist, but then they will get a big fat warning next time
they try to suspend any way.
grts Tim
signature.asc
Description: PGP signature
Bug#397214: overwrites values in /etc/uswsusp.conf
Tim Dijkstra [EMAIL PROTECTED] wrote: I am inclined however to just add the value from the configuration file to the list. If people want to change the configuration file by hand, they should be allowed to shoot themselves it the foot. The worst that can happen is that the partition doesn't exist, but then they will get a big fat warning next time they try to suspend any way. Yes, that sounds sensible. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#397214: overwrites values in /etc/uswsusp.conf
On Mon, Nov 13, 2006 at 05:22:57PM +0100, Tim Dijkstra wrote: On Mon, 13 Nov 2006 15:46:44 +0100 Frank K?ster [EMAIL PROTECTED] wrote: I was just bug-hunting. I don't know what the reason was why the device was unavailable, but I think there may be valid setups where this is the case. I just read in another report by Vagrant that he was trying to use a special purpose swap partition for suspending only. And indeed it wasn't active during the upgrade. yes. it is the same issue. cat /proc/swaps FilenameTypeSizeUsed Priority /dev/mapper/crypt1 partition 511992 56 -1 because bug #397212, encrypted swap is not (and would be very difficult to setup) supported. so i've tried using a swap partition that i only mount when using s2disk. ...snip... I am inclined however to just add the value from the configuration file to the list. If people want to change the configuration file by hand, they should be allowed to shoot themselves it the foot. The worst that can happen is that the partition doesn't exist, but then they will get a big fat warning next time they try to suspend any way. sounds good enough to to me. live well, vagrant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397214: overwrites values in /etc/uswsusp.conf
Vagrant Cascadian [EMAIL PROTECTED] wrote:
Package: uswsusp
Version: 0.3~cvs20060928-2
Severity: serious
Justification: Policy 10.7.3
i had locally modified my /etc/uswsusp.conf to use a different resume
device, but on a recent upgrade, it over-wrote my configuration file
changes without asking.
this also results in my resume partition getting written to a device it
can't read from(an encrypted swap device on lvm), which could cause
data loss if i do not manually regenerate the initramfs image and try to
use s2disk.
At a short glance, it looks like the config script sets resume_device
unconditionally to the first partition in /proc/swap (or rather, the
first one produced from
sort -r -k 3 /proc/swaps | awk '$2==partition {print $1}'
) without asking or, what's more important, without checking the
configuration file. Later, the postinst script enters this value into
the configuration file, which would be correct if the config script had
taken it from there.
Regards, Frank
--
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Bug#397214: overwrites values in /etc/uswsusp.conf
Package: uswsusp Version: 0.3~cvs20060928-2 Severity: serious Justification: Policy 10.7.3 i had locally modified my /etc/uswsusp.conf to use a different resume device, but on a recent upgrade, it over-wrote my configuration file changes without asking. this also results in my resume partition getting written to a device it can't read from(an encrypted swap device on lvm), which could cause data loss if i do not manually regenerate the initramfs image and try to use s2disk. live well, vagrant -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages uswsusp depends on: ii debconf [debconf-2.0]1.5.8 Debian configuration management sy ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libgcrypt11 1.2.3-2 LGPL Crypto library - runtime libr ii libgpg-error01.4-1 library for common error values an Versions of packages uswsusp recommends: ii initramfs-tools 0.84 tools for generating an initramfs -- debconf information: * uswsusp/compute_checksum: true uswsusp/no_snapshot: * uswsusp/suspend_loglevel: uswsusp/no_swap: * uswsusp/early_writeout: true * uswsusp/image_size: 150MB * uswsusp/compress: true * uswsusp/create_RSA_key: false * uswsusp/snapshot_device: * uswsusp/RSA_key_file: /etc/uswsusp.key * uswsusp/max_loglevel: * uswsusp/resume_device: /dev/mapper/crypt1 * uswsusp/encrypt: true uswsusp/splash: false * uswsusp/RSA_key_bits: 1024 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
