Not sure how the process here works, is this enough or do i need to
change some status somewhere?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1469143
Title:
kpartx -d
Tested the above scenario on vivid, appears to work
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1469143
Title:
kpartx -d fails with image paths longer than 63 characters
Hello Simo, or anyone else affected,
Accepted multipath-tools into vivid-proposed. The package will build now
and be available at https://launchpad.net/ubuntu/+source/multipath-
tools/0.4.9-3ubuntu12.15.04.2 in a few hours, and then in the -proposed
repository.
Please help us by testing this new
** Description changed:
+ [Impact]
+ Users of kpartx to load disk images, possibly multiple images with the same
file name (but in different paths).
+
+ [Test case]
+ See below, also see
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1469143/comments/3
+
+ [Regression
** Changed in: multipath-tools (Ubuntu Vivid)
Status: New => In Progress
** Changed in: multipath-tools (Ubuntu Trusty)
Status: New => In Progress
** Changed in: multipath-tools (Ubuntu Precise)
Status: New => In Progress
** Changed in: multipath-tools (Ubuntu Precise)
This bug was fixed in the package multipath-tools - 0.5.0-7ubuntu5
---
multipath-tools (0.5.0-7ubuntu5) wily; urgency=medium
* debian/patches/0014-kpartx-long-path.patch: have kpartx match loopback
files by device and inode rather than by path, as paths are not complete
Thank you Mathieu
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1469143
Title:
kpartx -d fails with image paths longer than 63 characters
To manage notifications about
** Changed in: multipath-tools (Ubuntu Utopic)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1469143
Title:
kpartx -d fails with image
Unassigning Jorge, I will sponsor this fix.
** Changed in: multipath-tools (Ubuntu)
Assignee: Jorge Niedbalski (niedbalski) => Mathieu Trudel-Lapierre
(mathieu-tl)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools
Looks like the upstream people don't seem to be very responsive to handle this
case. Is there any way to kick it forward?
Also, could ubuntu still fix this properly while redhat sits on it?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed
I have sent the patch to the mailing list, no comments yet though.
https://www.redhat.com/archives/dm-devel/2015-July/msg00037.html
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
In addition to not handling long paths, kpartx also fails to handle
relative paths correctly. Here's an example:
for d in 1 2
do
mkdir $d (
cd $d
dd if=/dev/zero of=disk.img seek=8k count=1 2 /dev/null
(echo n;echo;echo;echo;echo;echo w) | fdisk disk.img /dev/null
kpartx -av
@simo-punnonen, @risto-kankkunen-i
Makes much more sense to use the device/inode for reference. Please could you
guys
send this patch to upstream via the dm-de...@redhat.com mailing list?
Once the patch is there I can prepare an Ubuntu patch containing the
fix.
Thanks.
--
You received this
Thanks Risto!
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1469143
Title:
kpartx -d fails with image paths longer than 63 characters
To manage notifications about this
Simo
Go ahead an propose the patch you are thinking on.
Best!
On Monday, June 29, 2015, Simo Punnonen simo.punno...@f-secure.com
wrote:
is the lo_name which gets stored in the loop_info structure actually
required to be an actual file path or is it enough to be an arbitrary
string
is the lo_name which gets stored in the loop_info structure actually
required to be an actual file path or is it enough to be an arbitrary
string identifier?
If it doesn't have to be a file path, could it be for instance a sha1
hash of the provided path? That fits into 40 chars and is relatively
If i understand correctly, the fix is to compare only the first 63 chars
of the path.
With kpartx the precise file path matters in resolving the correct loop
device, the suggested solution has the following consequence:
Assuming all loop devices are available, these commands succeed and
mount
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: multipath-tools (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
I can reproduce this on precise+. I've submitted the wily branch for
review.
** Changed in: multipath-tools (Ubuntu)
Assignee: (unassigned) = Jorge Niedbalski (niedbalski)
** Changed in: multipath-tools (Ubuntu)
Status: Confirmed = In Progress
--
You received this bug notification
** Also affects: multipath-tools (Ubuntu Precise)
Importance: Undecided
Status: New
** Also affects: multipath-tools (Ubuntu Vivid)
Importance: Undecided
Status: New
** Also affects: multipath-tools (Ubuntu Trusty)
Importance: Undecided
Status: New
** Also affects:
** Branch linked: lp:~niedbalski/ubuntu/wily/multipath-tools/fix-
lp-1469143
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to multipath-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1469143
Title:
kpartx -d fails with image paths
21 matches
Mail list logo
