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 fai
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 potential
** 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)
Im
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
enou
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 thi
** 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 paths
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.
https://bugs.launchpad.net/b
@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 bu
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 bu
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 &&
k
Simo
Go ahead an propose the patch you are thinking on.
Best!
On Monday, June 29, 2015, Simo Punnonen
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 identifier?
>
> If it doesn't hav
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 the
** 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 l
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 notificatio
** 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:
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.
https://bugs.launc
21 matches
Mail list logo
