Hello,
On Fri, 01 Nov 2013, Rodolfo García Peñas wrote:
> because IMO this bug is very important, and the system cannot boot, I
> created a new uswsusp package. The change is save the resume device as
> /dev/mapper (not like uuid device) if the user is using lvm2.
As far as I can see the problem seems to be with lvm2 not being able to
recognise UUIDs for block devices as "belonging to lvm2". [*]
I don't think that the problem lies with uswsusp or should be fixed by
uswsusp.
The point is that somewhere at the top of the initrd boot process, the
relevant logical volumes need to be activated.
After these volumes have been activated, uswsusp (or any other program)
can access them either by their UUID or by their other names.
So here is my 2 paise worth of suggestion.
Either, the initrd script "/scripts/local-top/lvm2" should activate
_all_ volume groups as suggested at 678687#5 by Goswin von Brederlow.
(This looks like overkill and may really slow down the boot on some
systems!)
Or, the initrd hooks should extract the relevant volume groups from the
UUIDs and write them to the initrd as a config file for
"/scripts/local-top/lvm2" to pick up and activate at boot time.
I think the second is a better option --- but then I am not writing the
code so I don't get to choose! :-)
Regards,
Kapil.
[*] For some reason lvm's own uuids stored in /etc/lvm2/backup/$VGNAME
are different from those created by libuuid. Otherwise, it would
have been possible for /scripts/local-top/lvm2 to use this information
to recognise its logical volumes from their UUIDs.
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
