Dave,

Quoting the last comment from the cloned bug:

"2) We should not store /dev/dm-# device node names in actions, but
    rather /dev/mapper/xxxxx-yyyyy names, as the /dev/dm-# name can change
    when we deactivate and re-activate things."

Regards,

Hans

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

We aren't storing dm-# anywhere. Parted is reporting dm-# because it has resolved the /dev/mapper/%name symlink to the real device name which is dm-#.

(In reply to comment #4)
> We aren't storing dm-# anywhere. Parted is reporting dm-# because it has
> resolved the /dev/mapper/%name symlink to the real device name which is dm-#.    

You are probably right, but even then we still have an issue, parted is returning the following error:
IOException: Error opening /dev/dm-1: No such file or directory

This means that the symlink is pointing to a non existing device node ?

Maybe some issue with the new udev driven lvm stuff ?

Note that the:

        if not os.access(self.device, os.W_OK):
            raise DeviceFormatError("device path does not exist")

check in disklabel.py does not trigger, maybe that is only checking the
existence of the symlink ?

Re-opening this so that it does not fall through the cracks (sorry).

One thing is for sure: according to the traceback we give parted the correct name of the device:

DiskLabel.destroy: device: /dev/mapper/vg00-lvRHEL5 ; status: True ; type: disklabel ;
12

I have a reproducing vmware image and there's actually no symlinks pointing to /dev/dm-2. So I am still wondering.

Here's whats happening: (it is only reproducible without Hans's patch for 576145, but it really can be an issue now that /dev/mapper/VolGrou00-* are udev manged symlinks)

1) during storageinit we initialize DiskLabel's parted devices through a call to pyparted:
self._partedDevice = parted.Device(path=self.device)

where self.device is '/dev/mapper/VolGroup00-lve1' links to '/dev/dm-2'

2) pyparted talks to libparted, it calls ped_device_get(path)
the first think ped_device_get does is to canonicalize the path. from then on it works with and remembers only the absolute path.

3) during the enablefilesystems step, at the point where we try to destroy disklabel on /dev/mapper/VolGroup00-lve1, /dev/mapper/VolGroup00-lve1 now points to /dev/dm-0 as the other lvm devices were deactivated/disappeared in the meantime (is this the correct behavior?) but /dev/dm-2 that libparted remembers no longer exists.

The fix should be to reinitialize disklabel._partedDevice whenever the given lvm is reactivated to keep the internal libparted object consistent with the disklabel object.

This is fixed in parted-2.1-6.el6, moving to modified.

Hi Hans and Ales,
the original bug doesn't have any clues as to how to reproduce nor does this one. How can QE test that this has been fixed?

Hi,

Maybe Hans will remember better, but I think it just appeared when you clicked 'Next' after the partitioning screen.

Ales

(In reply to comment #12)
> Hi Hans and Ales,
> the original bug doesn't have any clues as to how to reproduce nor does this
> one. How can QE test that this has been fixed?    

Hi,

If I dig deep enough and spend some time on it I might come up with a recipe to reproduce this. But that is not necessary. Whenever a parted bugs get fixed parted upstream adds a testcase for the specific bug to the test-suite, that has happened here too, and that test-case is part of our package too.

So as the test-suite runs properly (it gets run on the builsystem during the build, and I run it every time I check in changes), it is safe to say that this bug has been verified. IOW I believe you can close this as OtherQA.

Regards,

Hans

I've executed the test cases from parted-2.1-8.el6 SRPM. The results are:

PASS: t0000-basic.sh
PASS: t0001-tiny.sh
PASS: t0010-script-no-ctrl-chars.sh
PASS: t0100-print.sh
PASS: t0200-gpt.sh
PASS: t0201-gpt.sh
PASS: t0202-gpt-pmbr.sh
PASS: t0205-gpt-list-clobbers-pmbr.sh
PASS: t0220-gpt-msftres.sh
PASS: t0250-gpt.sh
PASS: t0280-gpt-corrupt.sh
PASS: t0300-dos-on-gpt.sh
PASS: t0400-loop-clobber-infloop.sh
PASS: t1100-busy-label.sh
PASS: t1700-ext-probe.sh
PASS: t2100-mkswap.sh
PASS: t2200-dos-label-recog.sh
PASS: t2300-dos-label-extended-bootcode.sh
FAIL: t3000-resize-fs.sh
PASS: t4000-sun-raid-type.sh
PASS: t4100-msdos-partition-limits.sh
PASS: t4100-dvh-partition-limits.sh
PASS: t4100-msdos-starting-sector.sh
PASS: t4200-partprobe.sh
PASS: t5000-tags.sh
PASS: t6000-dm.sh
PASS: t7000-scripting.sh
PASS: t8000-loop.sh
PASS: t9010-big-sector.sh
PASS: t9020-alignment.sh
PASS: t9021-maxima.sh
PASS: t9030-align-check.sh
===================================
1 of 32 tests failed
See tests/test-suite.log
Please report to bug-parted
===================================

The failed results is because mkfs.hfs was not found (I don't have it). Moving to VERIFIED.

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.