Hello,
> Am I interpreting correctly that, "On system start-up, since the
> encrypted volume wasn't opened, iscsitarget failed to access the files.
> Thus failed. Later, after opening the encrypted volume, iscsitarget was
> restarted, successfully" ???
At first, iscsitarget starts, but complains that it can't find the
files mentioned in /etc/iet/ietd.conf. Thus I gave the following
commands:
/etc/init.d/iscsitarget stop
crsetup <args>
mount /dev/mapper/something /mnt/storage3
/etc/init.d/iscsitarget start
Further experimentation has shown me the following:
- Creating a new empty image (dd if=/dev/zero of=wherever bs=1G
count=40), making it available as a iscsitarget never fails to get
hooked/booted from (apart from the fact that it is empty). This does
not cause the kernel bug.
- Booting my (apparently) broken win7 installation image (which
broke halfway during installation) causes win7 to bsod and reboot
immediately (I haven't been able to tell windows not to do that,
since it's not completely installed yet). This somehow leaves the
iscsitarget-system in a state where the next attempt to do anything
with an exported volume (for example a sanhook-command from ipxe)
causes the kernel bug to happen.
It doesn't matter if the imagefile itself is stored on an encrypted
volume or not.
Is there any way I can let the iscsitarget-system log everything it
does to file and reproduce the above scenario (tried 4 times, always
has the same outcome)?
--
Best regards,
H. Buurman
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
