|
Bugzilla – Full Text Bug Listing |
| Summary: | kpartx creates incorrect mappings when used against a loop device | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.2 | Reporter: | James Oakley <jfunk> |
| Component: | Basesystem | Assignee: | Petr Uzel <puzel> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | hare |
| Version: | Factory | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
James, I'd appreciate if you could test the fix from https://bugzilla.novell.com/show_bug.cgi?id=552596#c3 and report if it fixes kiwi. TIA *** This bug has been marked as a duplicate of bug 552596 *** |
User-Agent: Mozilla/5.0 (compatible; Konqueror/4.3; Linux) KHTML/4.3.1 (like Gecko) SUSE If I use kpartx to create mappings for a loop device that points to a raw disk image file, it creates a new pointer to my swap volume instead (system-swapp1). This breaks kiwi since it uses kpartx in this manner. Here's a demonstration: The image, as seen by fdisk: maus:~/phdmm/image # fdisk -l OpenVPNBridge.i686-1.1.0.raw You must set cylinders. You can do this from the extra functions menu. Disk OpenVPNBridge.i686-1.1.0.raw: 0 MB, 0 bytes 255 heads, 63 sectors/track, 0 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0xc5c98522 Device Boot Start End Blocks Id System OpenVPNBridge.i686-1.1.0.raw1 * 1 53 425691 83 Linux If I run kpartx on this image directly, everything works as normal: maus:~/phdmm/image # kpartx -av OpenVPNBridge.i686-1.1.0.raw add map loop0p1 (253:5): 0 851382 linear /dev/loop0 63 But if I first create a loop mapping to the file, I get a different, and baffling behaviour: maus:~/phdmm/image # losetup /dev/loop0 OpenVPNBridge.i686-1.1.0.raw maus:~/phdmm/image # kpartx -av /dev/loop0 add map system-swapp1 (253:5): 0 851382 linear /dev/loop0 63 Here's the list of my /dev/mapper directory at this point: crw-rw---- 1 root root 10, 60 Oct 7 10:39 control brw-r----- 1 root disk 253, 4 Oct 7 10:39 cr_home brw-r----- 1 root disk 253, 3 Oct 7 10:39 system-ftp brw-r----- 1 root disk 253, 1 Oct 7 10:39 system-home brw-r----- 1 root disk 253, 2 Oct 7 10:39 system-root brw-r----- 1 root disk 253, 0 Oct 7 10:39 system-swap brw-rw---- 1 root disk 253, 5 Oct 21 10:29 system-swapp1 I suspect this bug may only be present on LVM systems. Reproducible: Always