UUIDs on drives (was Hibernate on battery low)

[Derek Broughton]

Florian Diesch wrote:

> Pastor JW <pastor_jw at the-inner-circle.org> wrote:
> 
>> On Wednesday 13 August 2008 05:58:20 pm Derek Broughton wrote:
>>> Pastor JW wrote:
>>> > On Wednesday 13 August 2008 03:26:51 pm Kennneth P. Turvey wrote:
>>> >> I prefer the old method too.  I think the problem is that many people
>>> >> use external drives now and the devices will change, so UUIDs solve
>>> >> the problem.
>>> >>
>>> >> Is this the correct reasoning?  I'm just guessing here.  Are there
>>> >> any other advantages to using UUIDs that I'm missing?
>>> >
>>> > I DO wish they would fix their UUID method to allow the OS to find the
>>> > swap
>>> > partition so hibernate would properly work with it.  Either that or
>>> > remove hibernate from the options.  Suspend seems to work and uses
>>> > very
>>> > little battery while suspended.  Maybe swap needs looked at itself as
>>> > with the current UUID style of doing things the OS can't find it.
>>>
>>> Huh?  Mine always has - even after mkswap.
>>
>> Wait a second here, you are the person who showed me how to set up fstab
>> in order to get swap recognized in the first place,  Worked too. 

Yep.  I have been known to suggest just renaming the fstab entry for fixed
devices.  It's not what I do though - mine uses UUIDs.

>> However, 
>> three kernel updates since then and my fstab is no longer what you told
>> me to
>> change it to.  Swap now again has a UUID and is not recognized for
>> hibernation purposes like it was when I first received my machine.

I _did_ only recently learn about  /etc/initramfs-tools/conf.d/resume -
clearly this could cause problems, but "man initramfs-tools" says:

"resume
 On install initramfs-tools tries to autodetect the resume partition. On
 success the RESUME variable is written to
 /etc/initramfs-tools/conf.d/resume. The boot variable noresume overrides
 it."

So the implication is that initramfs _should_ be trying to keep that
accurate.  If you make a new swap, though, between kernel updates it
certainly can't know it's changed.  However, I don't see a way to make
update-initramfs generate a new "resume" parameter.  Even "aptitude
reinstall initramfs-tools" after deleting the original "resume" file,
doesn't generate a new one.  So initramfs-tools ssems to be broken.

I've been reading through
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/66637 and
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/50437 and I
see three ways you could solve your problem.  #50437 is the one that would
really solve this problem.

1) modify /boot/grub/menu.lst and add "resume=/dev/xxxx" where "xxxx" is
your swap partition.  This could work, but I really don't like it - because
there's no guarantee that in future it will be right.

2) modify /boot/grub/menu.lst and add "resume=UUID=..." where "..." is your
swap's UUID.

3) fix /etc/initramfs-tools/conf.d/resume and run "sudo update-initramfs -u"

4) turn off your swap, run "mkswap /dev/... -U xxxx", where "xxxx" is the
current UUID from /etc/initramfs-tools/conf.d/resume, turn on your swap
again.

OK, I see FOUR solutions :-)  (3) seems by far the simplest.

I really wish I knew why I haven't run into this...  _Something_ must be
working.
-- 
derek