Re: Bug#750255: lio-utils: FTBFS: chmod: cannot access '/«BUILDDIR»/lio-utils-3.1+git2.fd0b34fd/debian/lio-utils/usr/share/pyshared/*.py': No such file or directory

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

 



On 09/21/2014 12:36 AM, Ritesh Raj Sarraf wrote:


On Saturday 20 September 2014 03:23 PM, Jerome Martin wrote:
Yes, the problem is that the kernel side uses this path unfortunately.
We could relocate policy and fabric to /var/lib/target, but that would
mean keeping both /lib/target and /var/target around for now, as the
kernel will use that for storing alua metadata in /var/target/alua.

However, what about relocating now, and keeping around a symlink to
/var/target, created in post-install?

This way, as soon as Nic can push the relocation to /var/lib/alua, we
are ready and just have to remove the symlink from packaging.

I am cc'ing the ML on this one.

The manpage, written by Andy, refers to /var/lib/. Which would imply
that Fedora/RHEL and all its derivatives must be using the new path.

I don't see any mention of /var/lib. In any case, RH packaging isn't creating /var/target/{alua,pr} directories, whose absence will cause PR ops to fail in 3.11+-based kernels even if they don't use APTPL. I need to fix that soon.

If I came up with a kernel patch that made the path that ALUA & PR files were written to settable via configfs, would that also be helpful to you?

Nick, thoughts?

Regards -- Andy

--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux