On 04/27/2010 05:33 PM, Alasdair G Kergon wrote:
On Tue, Apr 27, 2010 at 03:56:57PM -0500, Douglas McClendon wrote:
I have a user of an installation tool of mine that is hitting this
message, with a very recent pre-fedora-13 kernel.
udev is now involved in this process.
Check they have up-to-date lvm2 and udev packages and that they've not
tried to customise their udev rules - if they have, you'll need to
check their changes didn't break things.
Thanks for the reply and the advice. I'm not so interested in the issue
that I'll necessarily get to it very soon, but what you said will no
doubt help.
One thing though, which may not have been obvious, and almost sounds
dubious, is what I'm actually doing there. I'll try to describe it in
words here, to see if this shouts out as a situation that may no longer
be expected to work (because honestly I was probably pretty pleased and
half-surprised to discover that it did work 3 years ago)-
Basically the livecd mode you should be familiar with. ext3 image on a
loop device. cow file in tmpfs on a loop device. Combined with
dm-snapshot, resulting in what is used as the rootfs device. Simple enough.
So what I do (and this is dusty code I haven't payed attention to in a
long time, so maybe I'm misunderstanding my own code, but probably not)
is this-
1) with that dmsetup create that is now failing, I first create a
duplicate device (different name, same table) as the one that the
rootfs. I.e. another snapshot device with the same components/table.
2) I use a reload --table on the device that is the rootfs, to replace
it with a new table, that is a mirror of the device created in (1) and
the target normal hard disk partition that the script is installing the
OS to.
3) I do a resume on the rootfs device such that the new table with the
mirror activates, and the migration starts to occur
4) when the mirror completes, I do another reload then resume with a new
linear table pointing to the newly installed fs on normal disk
partition. Then I tear down all the unused original devices.
So, if something about this description screams out- the new udev
semantics will prevent (1) from working, let me know.
Big script.
Debug it by adding lines to dump the state immediately before the problem
command, then immediately after it.
Dump state by running 'dmsetup info -c', 'dmsetup table', 'dmsetup status'
and 'dmsetup udevcookies'.
If that still doesn't help, break the 'dmsetup create' command down into
its three constituent commands (dmsetup create --notable, dmsetup load,
dmsetup resume) and dump the state between each of them and confirm
which is failing.
Sounds good. Again, what I'm doing with two devices with the same table
smells like something that might have been inadvertently allowed before
and now not. Or maybe other people do it all the time for other reasons
I'm not considering right now.
-dmc
Alasdair
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
