[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [dm-devel] semop failed for cookie?

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.



dm-devel mailing list
dm-devel redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]