Once again IET fails to compile against the newest kernel. cc -Wl,-O1 -Wl,--as-needed ietd.o iscsid.o conn.o session.o target.o message.o ctldev.o log.o chap.o event.o param.o plain.o isns.o md5.o sha1.o -o ietd cc -Wl,-O1 -Wl,--as-needed ietadm.o param.o -o ietadm make[1]: Leaving directory `/var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/usr' make -j3 KSRC=/usr/src/linux kernel make -C /usr/src/linux M=/var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel modules make[1]: Entering directory `/usr/src/linux-2.6.38-gentoo-r3' CC [M] /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/tio.o CC [M] /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/iscsi.o CC [M] /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/nthread.o CC [M] /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/wthread.o CC [M] /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.o /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/wthread.c: In function ‘worker_thread’: /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/wthread.c:75:3: error: implicit declaration of function ‘copy_io_context’ make[2]: *** [/var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/wthread.o] Error 1 make[2]: *** Waiting for unfinished jobs.... /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.c:12:8: warning: type defaults to ‘int’ in declaration of ‘DECLARE_MUTEX’ /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.c:12:1: warning: parameter names (without types) in function declaration /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.c: In function ‘ioctl’: /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.c:261:28: error: ‘ioctl_sem’ undeclared (first use in this function) /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.c:261:28: note: each undeclared identifier is reported only once for each function it appears in /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.c: In function ‘release’: /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.c:350:8: error: ‘ioctl_sem’ undeclared (first use in this function) /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.c: At top level: /var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.c:12:8: warning: ‘DECLARE_MUTEX’ declared ‘static’ but never defined make[2]: *** [/var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel/config.o] Error 1 make[1]: *** [_module_/var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2/kernel] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.38-gentoo-r3' make: *** [kernel] Error 2 emake failed * ERROR: sys-block/iscsitarget-1.4.20.2 failed (compile phase): * (no error message) * * Call stack: * ebuild.sh, line 56: Called src_compile * environment, line 3697: Called die * The specific snippet of code: * emake KSRC="${KERNEL_DIR}" kernel || die * * If you need support, post the output of 'emerge --info =sys-block/iscsitarget-1.4.20.2', * the complete build log and the output of 'emerge -pqv =sys-block/iscsitarget-1.4.20.2'. * The complete build log is located at '/var/tmp/portage/sys-block/iscsitarget-1.4.20.2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-block/iscsitarget-1.4.20.2/temp/environment'. * S: '/var/tmp/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2' Reproducible: Always Steps to Reproduce: 1.Install kernel 2.6.38 2.Try to emerge iscsitarget Actual Results: Compile fails with error in wthread.c Expected Results: Compile succeeds This will supposedly be fixed in IET 1.4.20.3, but I wouldn't hold my breath for that release. There was a patch a while ago on IET's sourceforge page, but for some reason I can't seem to find it anymore. The Sabayon overlay has the patch: http://gentoo-overlays.zugaina.org/sabayon/portage/sys-block/iscsitarget/files/iscsitarget-2.6.38.patch
hmm, it doesnt compile for me even with the sabayon patch :/
It looks like it's more than just that patch. When I pull in the entire sabayon iscsitarget ebuild, that compiles. They have a different patch set than the one in portage.
on iscsitarget-devel they just recommend pulling from SVN. makes me think we could use a iscsitarget-9999.ebuild.
ok since this copy_io_context problem actually started from 2.6.37, you also need that patch. with those two, iscsitarget now compiled for me. i added epatch_user to the ebuild in my overlay for now, is it possible to make epatch_user a global FEATURE?
Created attachment 272011 [details] iscsitarget-9999.ebuild hm, -9999.ebuild didn't turn out to be difficult at all.
forgot that init script will probably need to migrate to looking for ietd.conf /etc/ietd, since ietd has complaining for a while that /etc/ietd.conf is deprecated. hopefully this will reach hwoarang soon enough.
(In reply to comment #6) > forgot that init script will probably need to migrate to looking for ietd.conf > /etc/ietd, since ietd has complaining for a while that /etc/ietd.conf is > deprecated. hopefully this will reach hwoarang soon enough. sigh, nice typos and all. /etc/iet, NOT /etc/ietd
nasty, kernel BUG when connecting to iscsitarget-r446 with OS X SNS globalSAN initiator. May 3 23:15:58 kernel: [ 2887.194316] iscsi_trgt: Removing all connections, sessions and targets May 3 23:16:27 kernel: [ 2916.166676] iSCSI Enterprise Target Software - version trunk May 3 23:16:27 kernel: [ 2916.166740] iscsi_trgt: Registered io type fileio May 3 23:16:27 kernel: [ 2916.166741] iscsi_trgt: Registered io type blockio May 3 23:16:27 kernel: [ 2916.166742] iscsi_trgt: Registered io type nullio May 3 23:19:24 kernel: [ 3092.339287] iscsi_trgt: BUG at /var/tmp/portage/sys-block/iscsitarget-9999/work/iscsitarget-9999/kernel/iscsi.c:392 assert(req->tio) May 3 23:19:24 kernel: [ 3092.339295] Pid: 14844, comm: istiod1 Tainted: P 2.6.38-gentoo-r3 #14 May 3 23:19:24 kernel: [ 3092.339299] Call Trace: May 3 23:19:24 kernel: [ 3092.339308] [<f9266cc3>] ? send_data_rsp+0x1d3/0x200 [iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339315] [<f926b145>] ? is_volume_reserved+0x45/0x70 [iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339321] [<f926c5ec>] ? get_iotype+0xa6c/0x1c30 [iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339328] [<c117c0eb>] ? current_io_context+0x1b/0x30 May 3 23:19:24 kernel: [ 3092.339334] [<f926888d>] ? wthread_start+0x24d/0x3a0 [iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339341] [<c10284f7>] ? __wake_up_common+0x47/0x70 May 3 23:19:24 kernel: [ 3092.339347] [<c1032c20>] ? default_wake_function+0x0/0x10 May 3 23:19:24 kernel: [ 3092.339352] [<f9268770>] ? wthread_start+0x130/0x3a0 [iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339359] [<c104dd04>] ? kthread+0x74/0x80 May 3 23:19:24 kernel: [ 3092.339364] [<c104dc90>] ? kthread+0x0/0x80 May 3 23:19:24 kernel: [ 3092.339369] [<c1003236>] ? kernel_thread_helper+0x6/0x10 May 3 23:19:24 kernel: [ 3092.339389] ------------[ cut here ]------------ May 3 23:19:24 kernel: [ 3092.339393] kernel BUG at /var/tmp/portage/sys-block/iscsitarget-9999/work/iscsitarget-9999/kernel/iscsi.c:392! May 3 23:19:24 kernel: [ 3092.339397] invalid opcode: 0000 [#1] PREEMPT SMP May 3 23:19:24 kernel: [ 3092.339402] last sysfs file: /sys/devices/virtual/block/md127/md/sync_speed May 3 23:19:24 kernel: [ 3092.339405] Modules linked in: iscsi_trgt vboxnetadp vboxnetflt vboxdrv coretemp it87 hwmon_vid hwmon nfs nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs snd_seq snd_seq_device af_packet sco bnep rfcomm l2cap snd_dummy loop fuse crc32c_intel hid_logitech snd_hda_codec_realtek btusb nvidia(P) bluetooth snd_hda_intel snd_hda_codec dvb_usb_dib0700 dib7000p usbhid dibx000_common snd_pcm dib0070 dvb_usb dvb_core imon snd_timer r8169 rc_core snd rtc_cmos i2c_i801 snd_page_alloc uhci_hcd skge rtc_core rtc_lib mii button sg processor sr_mod firewire_ohci cdrom firewire_core crc_itu_t pata_jmicron [last unloaded: iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339450] May 3 23:19:24 kernel: [ 3092.339451] Pid: 14844, comm: istiod1 Tainted: P 2.6.38-gentoo-r3 #14 Gigabyte Technology Co., Ltd. P55M-UD2/P55M-UD2 May 3 23:19:24 kernel: [ 3092.339457] EIP: 0060:[<f9266cc3>] EFLAGS: 00010282 CPU: 1 May 3 23:19:24 kernel: [ 3092.339460] EIP is at send_data_rsp+0x1d3/0x200 [iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339461] EAX: 00000000 EBX: e7de0000 ECX: 00000001 EDX: 00000000 May 3 23:19:24 kernel: [ 3092.339462] ESI: e7de001c EDI: e7de0000 EBP: e6544350 ESP: e6505f18 May 3 23:19:24 kernel: [ 3092.339464] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 May 3 23:19:24 kernel: [ 3092.339465] Process istiod1 (pid: 14844, ti=e6504000 task=ea243750 task.ti=e6504000) May 3 23:19:24 kernel: [ 3092.339466] Stack: May 3 23:19:24 kernel: [ 3092.339467] f9270be4 f9270b90 00000188 f927018f 00000000 ea156390 f4ec5c80 c1513c80 May 3 23:19:24 kernel: [ 3092.339470] ea2438dc c1513c80 f926b145 00010000 e7de0000 e7de001c ebcf4000 e6544350 May 3 23:19:24 kernel: [ 3092.339473] f926c5ec c117c0eb 000000d0 00000001 e62f1d40 e7de0000 e6544340 ebcf4000 May 3 23:19:24 kernel: [ 3092.339476] Call Trace: May 3 23:19:24 kernel: [ 3092.339478] [<f926b145>] ? is_volume_reserved+0x45/0x70 [iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339480] [<f926c5ec>] ? get_iotype+0xa6c/0x1c30 [iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339482] [<c117c0eb>] ? current_io_context+0x1b/0x30 May 3 23:19:24 kernel: [ 3092.339484] [<f926888d>] ? wthread_start+0x24d/0x3a0 [iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339486] [<c10284f7>] ? __wake_up_common+0x47/0x70 May 3 23:19:24 kernel: [ 3092.339488] [<c1032c20>] ? default_wake_function+0x0/0x10 May 3 23:19:24 kernel: [ 3092.339490] [<f9268770>] ? wthread_start+0x130/0x3a0 [iscsi_trgt] May 3 23:19:24 kernel: [ 3092.339492] [<c104dd04>] ? kthread+0x74/0x80 May 3 23:19:24 kernel: [ 3092.339494] [<c104dc90>] ? kthread+0x0/0x80 May 3 23:19:24 kernel: [ 3092.339496] [<c1003236>] ? kernel_thread_helper+0x6/0x10 May 3 23:19:24 kernel: [ 3092.339497] Code: eb b9 c7 44 24 0c 8f 01 27 f9 c7 44 24 08 88 01 00 00 c7 44 24 04 90 0b 27 f9 c7 04 24 e4 0b 27 f9 e8 9a 8b 11 c8 e8 eb 89 11 c8 <0f> 0b eb fe 89 7c 24 0c c7 44 24 08 fb 00 00 00 c7 44 24 04 84 May 3 23:19:24 kernel: [ 3092.339513] EIP: [<f9266cc3>] send_data_rsp+0x1d3/0x200 [iscsi_trgt] SS:ESP 0068:e6505f18 May 3 23:19:24 kernel: [ 3092.339517] ---[ end trace c1e3ffe7cf29916e ]---
Created attachment 272021 [details] iscsitarget-9999.ebuild it's cool to respect flags
Created attachment 272023 [details] updated flags patch, some of it had been merged into trunk since .2
it looks like i ran into another issue with my 2.6.38 upgrade [1], which seems to have caused some major corruption for iscsi traffic and in combination with this bug pretty much destroyed contents of one of my timemachine-over-iscsi targets. i am not able to get a BUG-free build of -9999 thus far, so i am now back with euser_patching sabayon .37+.38 and with a normally working r8168 nic driver it seems like everything is in a workable state again. new backup run is at 15/50GB with no errors on either side.
(In reply to comment #11) > it looks like i ran into another issue with my 2.6.38 upgrade [1], which seems [1]: https://bugs.gentoo.org/show_bug.cgi?id=359671
Created attachment 278615 [details, diff] patch for iscsitarget 1.4.20.2 and kernel 2.6.38 Tested on gentoo sources 2.6.38-r6
Created attachment 278785 [details, diff] patch for iscsitarget 1.4.20.2 and kernel 2.6.38 block-io.c: Kernel 2.6.38 removed open_bdev_exclusive and close_bdev_exclusive conn.c: line 47 "%p" expects 'void*' wthread.c config.c iscsi.h target.c patch for kernel 2.6.37: http://gentoo-overlays.zugaina.org/sabayon/portage/sys-block/iscsitarget/files/iscsitarget-2.6.37.patch
*** Bug 378835 has been marked as a duplicate of this bug. ***
as far as i can tell, their 1.4.20.3 release candidate gets a kernel BUG every time on my system when connecting to it.
work started here: https://groups.google.com/d/topic/iscsitarget/nzHy8h3MSk8/discussion
It seems to me that iscsitarget is getting obsolete and deprecated. Lio core has been merged to the mainline kernel. More can be found at www.linux-iscsi.org. LIO has replaced STGT as the standard Target with Linux kernel version 2.6.38. It is not only iscsi target but also FC and FCoE. I thing that usage of iscsi in the gentoo should take this path.
thanks for the info. am i correct to understand that iscsi target can be run directly out of kernel only from 3.1 earliest? [1] [1]: http://www.linux-iscsi.org/wiki/ISCSI
Yes, I dig trough kernels git and there is lot of merges from http://git.kernel.org/pub/scm/linux/kernel/git/nab/lio-core-2.6.git to the mainline. So, in 3.1 will be lot of iscsi target necessary stuff. I have discovered LIO yesterday when searching net for some target driver for QLogic qla2xxx Fiber Channel HBA card. Also found this: http://stgt.sourceforge.net/ But from comparison table at http://linux-iscsi.org/wiki/SCST#SCST it is clear that LIO could be the right way, because iscsitarget and open-iscsi initiator suffer from performance issues.
@Martin: do i understand correctly that iscsi-scst [1][2] is yet another option? [1]: http://article.gmane.org/gmane.linux.drivers.rdma/9426 [2]: http://iscsi-scst.sourceforge.net/index.html
replacing the portage/sys-block/iscsitarget directory completely with the one from sabayon and modifying the 3.0-patched Makefile manually to ---------------------- # Linux 3.0 support #if... KREV := 00 #fi ---------------------- helped to build with hardened-sources-3.0.4-r1, otherwise the build failed very early with ---------------------- >>> Source unpacked in /mnt/ramdisk/portage/sys-block/iscsitarget-1.4.20.2/work >>> Compiling source in /mnt/ramdisk/portage/sys-block/iscsitarget-1.4.20.2/work/iscsitarget-1.4.20.2 ... make -j4 KSRC=/usr/src/linux usr Sorry, your kernel version and/or distribution is currently Applying Patch compat-2.6.32.patch patching file kernel/conn.c Hunk #1 FAILED at 44. not supported. 1 out of 1 hunk FAILED -- saving rejects to file kernel/conn.c.rej make: *** [.patched.3.0.4-hardened-r1] Error 1 make: *** Waiting for unfinished jobs.... ----------------------
So, gentoo-sources 3.1 with brand new iscsi target stack from http://linux-iscsi.org/wiki/ISCSI has been released. My opinion is, that we no longer need this!?
i don't know just yet. i think it's best wait with a radical action like dropping until at least 3.2 if not 3.3. iscsitarget does have active development which means it must have use cases to justify it.
Yes, of course, but not to spend too much effort with old code.
*** Bug 385537 has been marked as a duplicate of this bug. ***
As per a chat with robbat2 in #gentoo-dev, I am taking this bug. I am adding base-system to the CC list.
Created attachment 307421 [details] Snapshot that builds against Linux 3.3.0 I am attaching a snapshot ebuild that uses attachment #272023 [details] as ${FILESDIR}/iscsitarget-1.4.20.2-respect-flags-v2.patch. It will build against Linux 3.3.0, but I need to do some more testing before I am convinced that it is ready for the tree. That could take a while, so I am attaching it here for early adopters. Feel free to try it and report whether or not it works (specifying your kernel version).
*** Bug 419623 has been marked as a duplicate of this bug. ***
Richard, For new kernels it would be better to focus on LIO and deprecate our support for this past 3.1.0
FYI, recents SVN commits allow iscsitarget/ietd to be built against 3.x up to 3.4. 3.5-rc untested so far.
If it can help I join the ebuild Funtoo uses, it should not require any changes to work on Gentoo. This takes the last known version (1.4.20) and "upgrades" it at SVN revision 483.
Created attachment 314239 [details] 1.4.20+SVN @R483 Build against Linux 3.4, untested with Linux 3.5 series
(In reply to comment #30) > Richard, > > For new kernels it would be better to focus on LIO and deprecate our support > for this past 3.1.0 There is a pull request in ZFSOnLinux's upstream GIT that implements a ZFS feature where zvols can be shared through iSCSI, but it requires iSCSITarget for that to work. As such, I need to either rework the upstream code or support iSCSITarget. At the moment, supporting iSCSITarget is the easiest thing to do. This has been open for a while because I had wanted to validate both it and the ZFS upstream pull request at the same time, but some issues appeared that delayed that. Expect this to be closed soon. (In reply to comment #33) > Created attachment 314239 [details] > 1.4.20+SVN @R483 > > Build against Linux 3.4, untested with Linux 3.5 series Thanks. I will commit an update soon.
(In reply to comment #34) > (In reply to comment #30) > > Richard, > > > > For new kernels it would be better to focus on LIO and deprecate our support > > for this past 3.1.0 > > There is a pull request in ZFSOnLinux's upstream GIT that implements a ZFS > feature where zvols can be shared through iSCSI, but it requires iSCSITarget > for that to work. As such, I need to either rework the upstream code or > support iSCSITarget. At the moment, supporting iSCSITarget is the easiest > thing to do. > ZFS zvols can be used with any iSCSI target software. Just not natively via the zfs command line tool but instead via the iSCSI daemon's config. I'm merely encouraging you to lean forward and not backwards. My vote is for base-system to not support iscsitarget on newer kernels as its a pile of crap and is one of the things that had lead me to using FreeBSD instead of Linux for iSCSI targets. Now with LIO and ZFS available for Linux things might begin to improve.
I also vote for LIO. iscsitarget is crapy stuff and used to prepare me some nasty surprises. Thus I have moved my storages to NexentaStor.
(In reply to comment #35) > ZFS zvols can be used with any iSCSI target software. Just not natively via > the zfs command line tool but instead via the iSCSI daemon's config. I'm > merely encouraging you to lean forward and not backwards. > > My vote is for base-system to not support iscsitarget on newer kernels as > its a pile of crap and is one of the things that had lead me to using > FreeBSD instead of Linux for iSCSI targets. Now with LIO and ZFS available > for Linux things might begin to improve. I am not opposed to depreciating iSCSITarget in favor of LIO. My earlier attempts to test iSCSITarget in conjunction with the ZFSOnLinux iSCSI integration caused me some pain and if LIO is superior, I would be happy to switch to it. I would like to involve ZFSOnLinux upstream in this conversation because what they do will affect what we need in-tree to support ZFS. Would you voice the case for LIO instead of iSCSITarget in the ZFSOnLinux upstream pull request: https://github.com/zfsonlinux/zfs/pull/621
(In reply to comment #37) > (In reply to comment #35) > > ZFS zvols can be used with any iSCSI target software. Just not natively via > > the zfs command line tool but instead via the iSCSI daemon's config. I'm > > merely encouraging you to lean forward and not backwards. > > > > My vote is for base-system to not support iscsitarget on newer kernels as > > its a pile of crap and is one of the things that had lead me to using > > FreeBSD instead of Linux for iSCSI targets. Now with LIO and ZFS available > > for Linux things might begin to improve. > > I am not opposed to depreciating iSCSITarget in favor of LIO. My earlier > attempts to test iSCSITarget in conjunction with the ZFSOnLinux iSCSI > integration caused me some pain and if LIO is superior, I would be happy to > switch to it. > > I would like to involve ZFSOnLinux upstream in this conversation because > what they do will affect what we need in-tree to support ZFS. Would you > voice the case for LIO instead of iSCSITarget in the ZFSOnLinux upstream > pull request: > > https://github.com/zfsonlinux/zfs/pull/621 Do we agree on lastritting this?
(In reply to comment #38) > Do we agree on lastritting this? I have no objections. I can always revisit this if the upstream pull request results in anything.
(In reply to comment #39) > (In reply to comment #38) > > Do we agree on lastritting this? > > I have no objections. I can always revisit this if the upstream pull request > results in anything. I have to withdraw my agreement to tree cleaning. A user informed me of filesystem corruption involving LIO following system power loss and after looking at the LIO code, I cannot find barrier support. I will try to find time to fix sys-block/iscsitarget unless someone writes a patch for barrier support in LIO.
As of today, I have taken over primary maintainership of this ebuild from base-system. sys-block/iscsitarget-1.4.20.2_p20130103 has been committed to gentoo-x86. It adds support for Linux 2.6.38 to Linux 3.6. Linux 3.7 support will come at a future date. The original issue has been fixed, so I am marking this bug as RESOLVED. Please file a new bug if you encounter compatibility issues.
*** Bug 444760 has been marked as a duplicate of this bug. ***
(In reply to comment #41) > As of today, I have taken over primary maintainership of this ebuild from > base-system. sys-block/iscsitarget-1.4.20.2_p20130103 has been committed to > gentoo-x86. It adds support for Linux 2.6.38 to Linux 3.6. Linux 3.7 support > will come at a future date. > > The original issue has been fixed, so I am marking this bug as RESOLVED. > Please file a new bug if you encounter compatibility issues. I tried to buid sys-block/iscsitarget-1.4.20.2_p20130103 But it broke because /usr/portage/sys-block/iscsitarget/files/iscsitarget-1.4.20.2-respect-flags-v2.patch does not exist * Cannot find $EPATCH_SOURCE! Value for $EPATCH_SOURCE is: * * /usr/portage/sys-block/iscsitarget/files/iscsitarget-1.4.20.2-respect-flags-v2.patch * ( iscsitarget-1.4.20.2-respect-flags-v2.patch ) * ERROR: sys-block/iscsitarget-1.4.20.2_p20130103 failed (prepare phase): * Cannot find $EPATCH_SOURCE!
Yeah, confirming that the ebuild is broken.
(In reply to comment #44) > Yeah, confirming that the ebuild is broken. I have committed the missing patch. That patch was from an earlier attempt at reviving the port that laid dominant until I took up the cause again this year. Unfortunatley, I missed it when committing to portage. That should not happen again. I have deployed sys-block/iscsitarget on my home network, so it will get a fair amount of testing from me the coming weeks. It supports a wide range of kernel versions and I am just beginning to maintain it, so it would not surprise me if there are other issues that I missed. As always, please file bug reports if you encounter issues.
Hmmm, it's now failing at MODPOST Building modules, stage 2. MODPOST 1 modules CC /mnt/datapool/tmp/portage/sys-block/iscsitarget-1.4.20.2_p20130103/work/iscsitarget-1.4.20.2_p20130103/kernel/iscsi_trgt.mod.o In file included from include/linux/srcu.h:31:0, from include/linux/notifier.h:15, from include/linux/memory_hotplug.h:6, from include/linux/mmzone.h:694, from include/linux/gfp.h:4, from include/linux/kmod.h:22, from include/linux/module.h:13, from /mnt/datapool/tmp/portage/sys-block/iscsitarget-1.4.20.2_p20130103/work/iscsitarget-1.4.20.2_p20130103/kernel/iscsi_trgt.mod.c:1: include/linux/rcupdate.h: In function ‘__kfree_rcu’: include/linux/rcupdate.h:917:2: error: size of unnamed array is negative make[2]: *** [/mnt/datapool/tmp/portage/sys-block/iscsitarget-1.4.20.2_p20130103/work/iscsitarget-1.4.20.2_p20130103/kernel/iscsi_trgt.mod.o] Error 1 make[1]: *** [modules] Error 2 make[1]: Leaving directory `/mnt/datapool/gentoo/kernel/linux-3.4.18-pf' make: *** [kernel] Error 2
