On Fri, 26 Jul 2013, Ben Hutchings escribió:
> On Thu, 2013-07-25 at 21:31 +0200, Rodolfo García Peñas wrote:
> > On Thu, 25 Jul 2013, Ben Hutchings escribió:
> >
> > > On Thu, 2013-07-25 at 09:54 +0000, Rodolfo García Peñas (kix) wrote:
> > > > Ben Hutchings <b...@decadent.org.uk> escribió:
> > > >
> > > > > On Wed, 2013-07-24 at 15:57 +0400, Askar Safin wrote:
> > > > >> > I think this file should be updated every time the package
> > > > >> "initramfs-tools" is reconfigured.
> > > > >>
> > > > >> Also, ideally, initramfs should be rebuilded every time user changes
> > > > >> fstab. But, I think this is very hard to reach.
> > > > >> Also, I think, every tool which updates fstab, should call initramfs
> > > > >> rebuilding (if swap is changed and hibernation is enabled).
> > > > >> In particular, every package configuration script which updates fstab
> > > > >> should trigger initramfs-tools reconfiguring.
> > > > >
> > > > > I think there is only one such script, which is the postinst script
> > > > > for
> > > > > linux-base which made a one-time update of configuration files to use
> > > > > UUIDs. It updated the initramfs-tools resume file too.
> > > > >
> > > > > But I wonder whether this configuration file is really needed for most
> > > > > system. Couldn't we use blkid to find the swap partition
> > > > > automagically?
> > > > > (The configuration file would still be necessary if there are multiple
> > > > > swap partitions.)
> > > > >
> > > > > Ben.
> > > > >
> > > > > --
> > > > > Ben Hutchings
> > > > > Once a job is fouled up, anything done to improve it makes it worse.
> > > >
> > > > Hi Ben, Askar,
> > > >
> > > > thanks a lot for your replies. I will update the uswsusp.config and
> > > > uswsusp.postinst scripts to write that file and then call
> > > > update-initramfs script. I will use UUIDs in that file (when available).
> > >
> > > uswsusp is not allowed to change an initramfs-tools config file
> > > directly:
> > > <file:///usr/share/doc/debian-policy/policy.html/ch-files.html#s10.7.4>
> >
> > Yes, sorry about that. Then initramfs-tools should update that file,
> > checking if the /etc/uswsusp.conf file exists and reading the value of
> > "resume device". Should I forward the bug to initramfs-tools package?
>
> Sorry, I think there's some confusion here.
>
> initramfs-tools has its own resume configuration file, but so far as I
> can see the uswsusp package does not use it. So there would be no
> reason for you to modify it - would there?
>
> The uswsusp package can edit its own configuration file though I do not
> recommend it. I think it would be better to leave the resume device
> unspecified in /etc/uswsusp.conf by default, and then to select it
> automatically (both at suspend and resume time) if possible.
>
> > > And why should it make a difference whether uswsusp or kernel-only
> > > suspend is used?
> >
> > uswsusp has three tools:
> [...]
> > s2disk and s2both tools use the resume file, so your question is about
> > these tools. These tools can write the image to the swap file selected
> > by the user (the resume file), they can compress the image (using less
> > swap and doing the suspend faster (less disk I/O)), they can encrypt
> > the image file and other less important things.
>
> Sure, uswsusp has some advantages. But if we agree it is a good idea to
> select the resume device automatically, isn't that true for both
> suspend-to-disk methods?
Hi Ben,
IMHO we should use the same resume device in all packages. I saw cryptsetup
package is using their own method to get the resume device too. I will notify
it to the cryptsetup team.
I have some questions before start modify the uswsusp scripts and upload a new
package for testing.
1. uswsusp will use the initramfs resume device. So, uswsusp should read the
file included in the initrd image at "conf/conf.d/resume". Is ok?
2. If the user select the resume device using boot argument, what should the
uswsusp script do?
3. resume will use the device using the argument "-r". This argument will be
used in the uswsusp initrd script, using the file read in the initramfs resume
file (question 1).
4. Currently, the initrd image includes two different resume binaries, one in
/bin (I don't know who copies that binary. initramfs-tools?) and other in /sbin
(copied by the uswsusp hook script. Sizes are different. We should use only one
resume binary.
kix@osaka:~/tmp$ find *bin -name resume -exec ls -l {} \;
-rwxr-xr-x 1 kix kix 2792 jul 27 19:29 bin/resume
-rwxr-xr-x 1 kix kix 40720 jul 27 19:29 sbin/resume
kix@osaka:~/tmp$
kix@osaka:~/tmp$ cat debian/initramfs-tools/hooks/uswsusp | grep copy
copy_exec /usr/lib/uswsusp/resume /sbin
kix@osaka:~/tmp$
5. There are two different resume scripts, one included by initramfs-tools and
other by uswsusp. IMO we should use only one:
kix@osaka:~/tmp/scripts/local-premount$ grep 'bin/resume' *
resume: /bin/resume ${resume} ${resume_offset}
resume: /bin/resume ${resume}
uswsusp:[ -x /sbin/resume ] || exit 0;
uswsusp:/sbin/resume
kix@osaka:~/tmp/scripts/local-premount$
6. What file should read s2disk and s2both to find the resume device when they
save the image?
7. The configuration file for uswsusp won't have the resume device. The line
"resume device =" won't exist. So, if the user wants to override the resume
device or select different swap device, what is the better choice? Include this
change in the /etc/uswsusp.conf file? override it in the initramfs scripts?
s2disk and s2both must know the override.
8. debian/control file: uswsusp will depends on initramfs-tools?
8a. I am not sure about this, because initramfs-tools is required by the
kernel, but there are case that uswsusp doesn't depends on initramfs-tools and
use the resume device in /etc/uswsusp.conf if initramfs-tools is not installed?
Could be initramfs-tools not installed and uswsusp installed?
I am not sure if I am missing something or if I am in the wrong way. Comments a
very welcome.
Cheers,
kix
> Ben.
>
> --
> Ben Hutchings
> Once a job is fouled up, anything done to improve it makes it worse.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
