Re: Converting from iscsitarget to targetcli-fb

In case anyone else runs into this catch-22 which is really not clearly documented
in terms of what this will do with your iSCSI target data (no way to recover data),

here is what I did as a temporary workaround:

jessie was added back to sources.list while keeping stretch in there.

grub set set to default to the 3.16 kernel, and the system rebooted

apt-get update
and then:
apt-get install --reinstall iscsitarget-dkms iscsitarget

Keep the old config files of course.

In my case, the output indicated the current kernel was already set up, in the output from the iscsitarget reinstall.

This is what it output:

Fetched 139 kB in 0s (344 kB/s)
Reading changelogs... Done
(Reading database ... 125705 files and directories currently installed.)
Preparing to unpack .../iscsitarget_1.4.20.3+svn502-1_amd64.deb ...
Unpacking iscsitarget (1.4.20.3+svn502-1) over (1.4.20.2-10.1) ...
Preparing to unpack .../iscsitarget-dkms_1.4.20.3+svn502-1_all.deb ...

-------- Uninstall Beginning --------
Module: iscsitarget
Version: 1.4.20.3+svn502
Kernel: 3.16.0-6-amd64 (x86_64)
-------------------------------------

Status: Before uninstall, this module version was ACTIVE on this kernel.

iscsi_trgt.ko:
- Uninstallation
   - Deleting from: /lib/modules/3.16.0-6-amd64/updates/dkms/
- Original module
   - No original module was found for this module on this kernel.
   - Use the dkms install command to reinstall any previous module version.

depmod......

DKMS: uninstall completed.

------------------------------
Deleting module version: 1.4.20.3+svn502
completely from the DKMS tree.
------------------------------
Done.
Unpacking iscsitarget-dkms (1.4.20.3+svn502-1) over (1.4.20.3+svn502-1) ...
Setting up iscsitarget-dkms (1.4.20.3+svn502-1) ...

Creating symlink /var/lib/dkms/iscsitarget/1.4.20.3+svn502/source ->
                 /usr/src/iscsitarget-1.4.20.3+svn502

DKMS: add completed.

Kernel preparation unnecessary for this kernel. Skipping...

Building module:
cleaning build area...
make -j8 KERNELRELEASE=3.16.0-6-amd64 -C /lib/modules/3.16.0-6-amd64/build M=/var/lib/dkms/iscsitarget/1.4.20.3+svn502/build.....
cleaning build area...

DKMS: build completed.

iscsi_trgt:
Running module version sanity check.
- Original module
   - No original module exists within this kernel
- Installation
   - Installing to /lib/modules/3.16.0-6-amd64/updates/dkms/

depmod...

DKMS: install completed.
Setting up iscsitarget (1.4.20.3+svn502-1) ...
Installing new version of config file /etc/init.d/iscsitarget ...

Depending whether there was a new kernel module installed (unlike my case)

it might require a reboot.

If no reboot, then restart the service.

/etc/init.d/iscsitarget restart

lsof -PNi | grep LIS

(this should show ietd listening for connections)

Now check the client system can see the connections again.

I will need to copy all of the partition data to another system before I can upgrade this iSCSI target

to the Debian 9 solution.

I think it is crazy that iSCSI comes along like it is a new standard and it is worse than working

with a file system like ext4. Storage should be something that is treated very conservatively

and provides a bit more depth of warning about how a person will be up the creek and with data lost

if they continue.

I'm seriously thinking we'd be safer to just use some network drive appliance than give this trust

to the OS to keep our upgrade path a safe one.

On Mon, Jul 30, 2018 at 6:13 PM, Shea Alterio <krusete@gmail.com> wrote:

That's why I said it really; is i had read that iscsitarget had become deprecated. https://bugs.debian.org/865632

It seemed like you could use lvm2 and open-iscsi to make a functional enough iSCSI configuration to get your configuration working well enough to back up or move your data... but then you still have to do the migration manually. Unfortunately, I don't have enough first hand experience with iSCSI to offer a better suggestion. It's possilbe downgrading to Debian 8 might be the fastest way.
On Mon, Jul 30, 2018 at 5:09 PM, francis picabia <fpicabia@gmail.com> wrote:
Of the packages you mention tgt is the only one which is iscsi target related.

I am looking at targetcli because my situation matches that of this bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865632

That tells me what to migrate to, but the examples for usage of targetcli do not
show working with existing iSCSI set up, only creating new, which would
likely destroy my existing data.

In the bug report it states:
     As the LIO stack was developed independently of the IET, the
     configuration has to be migrated manually.
It doesn't say "you will lose your data", and it doesn't say "here is how
to switch". I don't understand the inner workings of it.

I guess in a worse case I can try to downgrade to Debian 8 with the older
kernel and use iscsitarget again.

On Mon, Jul 30, 2018 at 4:11 PM, Zen Boy <krusete@gmail.com> wrote:

I have an iscsi setup in Debian 9. I don’t think iscsitarget is a supported package anymore? Do you have tgt, open-iscsi, lvm2 installed?

Get Outlook for iOS

On Mon, Jul 30, 2018 at 2:54 PM -0400, "francis picabia" <fpicabia@gmail.com> wrote:

This is with Debian 9 system which had been upgraded from Debian
8 a month or so ago.

I have an existing iscsi target blockio device with /dev/md1
Somehow it continued working under Debian 9 until a recent reboot
introduced a kernel update and then the module wasn't found:

FATAL: Module iscsi_trgt not found in directory /lib/modules/4.9.0-7-amd64

The solution in the bug report about that is to switch to targetcli-fb

When I look at the docs for targetcli, I don't see any hints/guides on how to configure
an existing iSCSI target made before on the blockio device.

My google fu has failed to find a guide/hints on existing iSCSI device conversion to targetcli.

Does anyone have a hint or link to share?

I have an existing target with valuable data on /dev/md1 and I need to configure it with targetcli.