CDROM not recognised: 'Device is not a TYPE_DISK block device'

[Andrew Watt]

Hello all,

I'm having a problem creating an iblock backstore from the CDROM drive in my HP Microserver.

The command:

create name=cdrom dev=/dev/sr0

Will return the following error:

Generating a wwn serial.
Device is not a TYPE_DISK block device.

I have been able to create a pscsi backstore to this device, and I can access it from my Windows 7 laptop, although it can get confused and lock the drive tray if I mount it within the server - which is why I'm trying the iblock configuration.

This behaviour is for a TSST Corp CDDVDW SH-24DBSCSI CDRom in a HP Microserver N54, with a clean install of Ubuntu 14.04 server, and targetcli.

Any help would be greatly appreciated.

Thanks in advance,
a.

[Jerome Martin]

Hi Andrew,

Post by Andrew Watt
Hello all,
I'm having a problem creating an iblock backstore from the CDROM drive in my HP Microserver.
create name=cdrom dev=/dev/sr0
Generating a wwn serial.
Device is not a TYPE_DISK block device.
I have been able to create a pscsi backstore to this device, and I can access it from my Windows 7 laptop, although it can get confused and lock the drive tray if I mount it within the server - which is why I'm trying the iblock configuration.
This behaviour is for a TSST Corp CDDVDW SH-24DBSCSI CDRom in a HP Microserver N54, with a clean install of Ubuntu 14.04 server, and targetcli.

Could you please give me the major device number for your CDROM drive?
In case you are not familiar with this, simply run:

# ls -l /dev/sr0

You should get something like that:

brw-rw---- 1 root cdrom 11, 0 Oct 13 16:01 /dev/sr0

In that case, 11 is the major number and 0 the minor.

Note that if I remember correctly, not adding CD-ROM majors as TYPE_DISK
was a deliberate decision, I'll have to go through my notes to find out
exactly why. In the meantime, you could add it manually to the
type_disk_known_majors list found in utils.py from the python-rtslib
package:

--- /usr/lib/python2.7/dist-packages/rtslib/utils.py 2014-10-13
16:04:08.000000000 +0200
+++ /tmp/utils.py 2014-10-15 14:24:31.932000000 +0200
@@ -219,6 +219,7 @@
type_disk_known_majors = [1, # RAM disk
8, # SCSI disk devices
9, # Metadisk RAID devices
+ 11, # Temporary hack for CD-ROM
13, # 8-bit MFM/RLL/IDE controller
19, # "Double" compressed disk
21, # Acorn MFM hard drive interface

Please report here on the outcome, and let me know how the CD-ROM
behaves with iblock. I am not convinced that this is a good idea at all,
but feel free to test it :-)

Post by Andrew Watt
Any help would be greatly appreciated.
Thanks in advance,
a.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Andrew Watt]

Thanks for getting back to me Jerome; very much appreciated.
 
My major device number is as you expected:
brw-rw---- 1 root cdrom 11, 0 Oct 15 11:29 /dev/sr0

And I'd also spotted a discussion on device numbers under a ZFS thread (https://github.com/zfsonlinux/zfs/issues/515), but I didn't want to hack around without a bit more reassurance; so thanks again.

I tried to add your suggestion to utils.py, but this this caused targetcli to error when I attempted to create the iblock backstore:

/backstores/iblock> create name=cdrom dev=/dev/sr0
Generating a wwn serial.
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 983, in run_interactive
self._cli_loop()
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 806, in _cli_loop
self.run_cmdline(cmdline)
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 927, in run_cmdline
self._execute_command(path, command, pparams, kparams)
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 902, in _execute_command
result = target.execute_command(command, pparams, kparams)
File "/usr/lib/python2.7/dist-packages/targetcli/ui_node.py", line 101, in execute_command
pparams, kparams)
File "/usr/lib/python2.7/dist-packages/configshell/node.py", line 1405, in execute_command
result = method(*pparams, **kparams)
File "/usr/lib/python2.7/dist-packages/targetcli/ui_backstore.py", line 381, in ui_command_create
raise exception
IOError: [Errno 30] Read-only file system

So I clearly don't know what I'm doing here; do I need to recompile compile this file, or something similar?

Removing this additional line resolves these errors, but takes me back to the original issue.

WRT using the CDROM as a pscsi blockstore: everything that I've tried (music CDs, movie DVDs) is detected by the laptop, it plays the media correctly, and the CD try is ejected on command from the laptop.

Unfortunately, not all is well. It does get into a bit of a twist when the server has accessed the CDROM (a mount, ls, and then unmount). The laptop can no-longer eject the CD tray, and the eject button on the CDROM will not work. I can eject the CD tray from the server command line, but only a server reboot will resolve the problem for the laptop. Not great, but good enough for my limited use case.

I have read that it's possible to 'unlock' the CD tray mechanism by default, but I'm not about to start hacking about with that for now.

Thanks again, and best regards,
a.
 
-----Original Message-----
From: "Jerome Martin" [***@netiant.com]
Date: 15/10/2014 01:26 PM
To: "Andrew Watt" <***@excite.com>, target-***@vger.kernel.org
Subject: Re: CDROM not recognised: 'Device is not a TYPE_DISK block device'

Hi Andrew,

Post by Andrew Watt
Hello all,
I'm having a problem creating an iblock backstore from the CDROM drive in my HP Microserver.
create name=cdrom dev=/dev/sr0
Generating a wwn serial.
Device is not a TYPE_DISK block device.
I have been able to create a pscsi backstore to this device, and I can access it from my Windows 7 laptop, although it can get confused and lock the drive tray if I mount it within the server - which is why I'm trying the iblock configuration.
This behaviour is for a TSST Corp CDDVDW SH-24DBSCSI CDRom in a HP Microserver N54, with a clean install of Ubuntu 14.04 server, and targetcli.

Could you please give me the major device number for your CDROM drive?
In case you are not familiar with this, simply run:

# ls -l /dev/sr0

You should get something like that:

brw-rw---- 1 root cdrom 11, 0 Oct 13 16:01 /dev/sr0

In that case, 11 is the major number and 0 the minor.

Note that if I remember correctly, not adding CD-ROM majors as TYPE_DISK
was a deliberate decision, I'll have to go through my notes to find out
exactly why. In the meantime, you could add it manually to the
type_disk_known_majors list found in utils.py from the python-rtslib
package:

--- /usr/lib/python2.7/dist-packages/rtslib/utils.py 2014-10-13
16:04:08.000000000 +0200
+++ /tmp/utils.py 2014-10-15 14:24:31.932000000 +0200
@@ -219,6 +219,7 @@
type_disk_known_majors = [1, # RAM disk
8, # SCSI disk devices
9, # Metadisk RAID devices
+ 11, # Temporary hack for CD-ROM
13, # 8-bit MFM/RLL/IDE controller
19, # "Double" compressed disk
21, # Acorn MFM hard drive interface

Please report here on the outcome, and let me know how the CD-ROM
behaves with iblock. I am not convinced that this is a good idea at all,
but feel free to test it :-)

Post by Andrew Watt
Any help would be greatly appreciated.
Thanks in advance,
a.
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

 

[Jerome Martin]

Hi Andrew,

Post by Andrew Watt
Thanks for getting back to me Jerome; very much appreciated.

You're welcome.

Post by Andrew Watt
brw-rw---- 1 root cdrom 11, 0 Oct 15 11:29 /dev/sr0

OK.

Post by Andrew Watt
And I'd also spotted a discussion on device numbers under a ZFS thread (https://github.com/zfsonlinux/zfs/issues/515), but I didn't want to hack around without a bit more reassurance; so thanks again.

Yes, same idea.
I added ZFS zvols to the list back then.

Post by Andrew Watt
/backstores/iblock> create name=cdrom dev=/dev/sr0
Generating a wwn serial.
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 983, in run_interactive
self._cli_loop()
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 806, in _cli_loop
self.run_cmdline(cmdline)
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 927, in run_cmdline
self._execute_command(path, command, pparams, kparams)
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 902, in _execute_command
result = target.execute_command(command, pparams, kparams)
File "/usr/lib/python2.7/dist-packages/targetcli/ui_node.py", line 101, in execute_command
pparams, kparams)
File "/usr/lib/python2.7/dist-packages/configshell/node.py", line 1405, in execute_command
result = method(*pparams, **kparams)
File "/usr/lib/python2.7/dist-packages/targetcli/ui_backstore.py", line 381, in ui_command_create
raise exception
IOError: [Errno 30] Read-only file system

Out of the top of my head, I can't tell if this is the targetcli stack
trying to perform some IO there (I can't imagine why) or if this is the
reason why we did not include cdroms to allwoed TYPE_DISK devices for
iblock.

Could you please give me the rtslib and targetcli versions you are using
so I can take a look at the code?

Post by Andrew Watt
So I clearly don't know what I'm doing here; do I need to recompile compile this file, or something similar?

No, what you did is fine.
You didn't know that you _did_ know what you did :-)

Post by Andrew Watt
Removing this additional line resolves these errors, but takes me back to the original issue.

<nod>

Post by Andrew Watt
WRT using the CDROM as a pscsi blockstore: everything that I've tried (music CDs, movie DVDs) is detected by the laptop, it plays the media correctly, and the CD try is ejected on command from the laptop.
Unfortunately, not all is well. It does get into a bit of a twist when the server has accessed the CDROM (a mount, ls, and then unmount). The laptop can no-longer eject the CD tray, and the eject button on the CDROM will not work. I can eject the CD tray from the server command line, but only a server reboot will resolve the problem for the laptop. Not great, but good enough for my limited use case.

Maybe Nic would have an idea of what this is.
As far as I know, the ALLOW_MEDIUM_REMOVAL opcode should be supported by
both fileio and iblock.

[Jerome Martin]

Post by Jerome Martin
Hi Andrew,
[..]

Post by Andrew Watt
IOError: [Errno 30] Read-only file system

Out of the top of my head, I can't tell if this is the targetcli stack
trying to perform some IO there (I can't imagine why) or if this is the
reason why we did not include cdroms to allwoed TYPE_DISK devices for
iblock.

OK, I took a look at that and it is the iblock code that fails when
trying to enable the device. So it is obviously not supported in the
current state of affairs. Sorry about that :-(

Nic, is having a RW device a hard requirement for iblock or is this
something that could/should be supported?

[Andy Grover]

Post by Jerome Martin
OK, I took a look at that and it is the iblock code that fails when
trying to enable the device. So it is obviously not supported in the
current state of affairs. Sorry about that :-(
Nic, is having a RW device a hard requirement for iblock or is this
something that could/should be supported?

iblock supports a "readonly=1" control setting that should allow a cdrom
to work.

Regards -- Andy

[Jerome Martin]

Post by Andy Grover

Post by Jerome Martin
OK, I took a look at that and it is the iblock code that fails when
trying to enable the device. So it is obviously not supported in the
current state of affairs. Sorry about that :-(
Nic, is having a RW device a hard requirement for iblock or is this
something that could/should be supported?

iblock supports a "readonly=1" control setting that should allow a cdrom
to work.

Ha, right, forgot about this.
Thanks Andy, I need to expose that one I guess.

[Nicholas A. Bellinger]

Post by Jerome Martin

Post by Jerome Martin
Hi Andrew,
[..]

Post by Andrew Watt
IOError: [Errno 30] Read-only file system

Out of the top of my head, I can't tell if this is the targetcli stack
trying to perform some IO there (I can't imagine why) or if this is the
reason why we did not include cdroms to allwoed TYPE_DISK devices for
iblock.

OK, I took a look at that and it is the iblock code that fails when
trying to enable the device. So it is obviously not supported in the
current state of affairs. Sorry about that :-(
Nic, is having a RW device a hard requirement for iblock or is this
something that could/should be supported?

So while the notion of using IBLOCK for a physical TYPE_ROM device might
make sense, it's a particularly bad idea and we should continue to
filter it from happening in userspace code.

The reasoning is that IBLOCK itself only understands struct bio level
I/O, which for the sake of this discussion means only READ + WRITE
operations. In order to utilize physical TYPE_ROM devices, there are a
number of SCSI MMC (multi-media command set) opcodes required to
interface with the device, that struct bio and the raw block layer has
no idea about.

That said, folks should be using PSCSI passthrough for TYPE_ROM export,
so that those MMC opcodes are dispatched directly to the device and not
emulated by target code.

--nab

[Andrew Watt]

Copied back to target-devel having removed the *rich text* flag from my original replay.
Sorry folks. 
 
-----Original Message-----
From: "Andrew Watt" [***@excite.com]
Date: 15/10/2014 05:30 PM
To: target-***@vger.kernel.org, ***@netiant.com
CC: ***@daterainc.com
Subject: Re: CDROM not recognised: 'Device is not a TYPE_DISK block device'


Hi Jerome,
 

OK, I took a look at that and it is the iblock code that fails when trying to enable the device. So it is obviously not supported in the current state of affairs. Sorry about that :-(

 
Thanks for digging into this for me, and please accept my apologies for any inconvenience that this has caused. Simply knowing that this isn't going to work for the time being is going to save me days of internet trawling.
 

Nic, is having a RW device a hard requirement for iblock or is this something that could/should be supported?

 
This probably won't help much in the short-term, but the *CDROM* is actually a DVD-RW, so apologies again for any confusion.
 
Thanks,
a.
 
-----Original Message-----
From: "Jerome Martin" [***@netiant.com]
Date: 15/10/2014 03:49 PM
To: "Andrew Watt" <***@excite.com>, target-***@vger.kernel.org
CC: "Nicholas Bellinger" <***@daterainc.com>
Subject: Re: CDROM not recognised: 'Device is not a TYPE_DISK block device'

Hi Andrew,
[..]

Post by Andrew Watt
IOError: [Errno 30] Read-only file system

Out of the top of my head, I can't tell if this is the targetcli stack
trying to perform some IO there (I can't imagine why) or if this is the
reason why we did not include cdroms to allwoed TYPE_DISK devices for
iblock.

OK, I took a look at that and it is the iblock code that fails when
trying to enable the device. So it is obviously not supported in the
current state of affairs. Sorry about that :-(

Nic, is having a RW device a hard requirement for iblock or is this
something that could/should be supported?
 
 

[Andrew Watt]

Copied back to target-devel having removed the *rich text* flag from my original replay.
Sorry folks.
 
-----Original Message-----
From: "Andrew Watt" [***@excite.com]
Date: 15/10/2014 05:21 PM
To: target-***@vger.kernel.org, ***@netiant.com
Subject: Re: CDROM not recognised: 'Device is not a TYPE_DISK block device'


Hi Jerome,
 

Could you please give me the rtslib and targetcli versions you are using so I can take a look at the code?

 
If only life were so easy:
/> version
Cannot find configshell version. The configshell package has probably not been built properly from either the git repository or a public tarball.
Cannot find rtslib version. The rtslib package has probably not been built properly from either the git repository or a public tarball.
Cannot find targetcli version. The targetcli package has probably not been built properly from either the git repository or a public tarball.
 
I installed targetcli from the Ubuntu repositories (apt-get install targetcli), so I *think* that I'm using version 2.1-1 or targetcli (http://packages.ubuntu.com/trusty/targetcli), and version 2.2-1 or rtslib (http://packages.ubuntu.com/trusty/python-rtslib), but I could be wrong. There are several Python directories on this server (2.7, 3, 3.4), but firing up the Python interpreter brings me into Python 2.7.6.
 
HTH,
a.
 
-----Original Message-----
From: "Jerome Martin" [***@netiant.com]
Date: 15/10/2014 03:17 PM
To: "Andrew Watt" <***@excite.com>, target-***@vger.kernel.org
Subject: Re: CDROM not recognised: 'Device is not a TYPE_DISK block device'

Hi Andrew,

Thanks for getting back to me Jerome; very much appreciated.

You're welcome.

brw-rw---- 1 root cdrom 11, 0 Oct 15 11:29 /dev/sr0

OK.

And I'd also spotted a discussion on device numbers under a ZFS thread (https://github.com/zfsonlinux/zfs/issues/515), but I didn't want to hack around without a bit more reassurance; so thanks again.

Yes, same idea.
I added ZFS zvols to the list back then.

/backstores/iblock> create name=cdrom dev=/dev/sr0
Generating a wwn serial.
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 983, in run_interactive
self._cli_loop()
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 806, in _cli_loop
self.run_cmdline(cmdline)
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 927, in run_cmdline
self._execute_command(path, command, pparams, kparams)
File "/usr/lib/python2.7/dist-packages/configshell/shell.py", line 902, in _execute_command
result = target.execute_command(command, pparams, kparams)
File "/usr/lib/python2.7/dist-packages/targetcli/ui_node.py", line 101, in execute_command
pparams, kparams)
File "/usr/lib/python2.7/dist-packages/configshell/node.py", line 1405, in execute_command
result = method(*pparams, **kparams)
File "/usr/lib/python2.7/dist-packages/targetcli/ui_backstore.py", line 381, in ui_command_create
raise exception
IOError: [Errno 30] Read-only file system

Out of the top of my head, I can't tell if this is the targetcli stack
trying to perform some IO there (I can't imagine why) or if this is the
reason why we did not include cdroms to allwoed TYPE_DISK devices for
iblock.

Could you please give me the rtslib and targetcli versions you are using
so I can take a look at the code?

So I clearly don't know what I'm doing here; do I need to recompile compile this file, or something similar?

No, what you did is fine.
You didn't know that you _did_ know what you did :-)

Removing this additional line resolves these errors, but takes me back to the original issue.

<nod>

WRT using the CDROM as a pscsi blockstore: everything that I've tried (music CDs, movie DVDs) is detected by the laptop, it plays the media correctly, and the CD try is ejected on command from the laptop.
Unfortunately, not all is well. It does get into a bit of a twist when the server has accessed the CDROM (a mount, ls, and then unmount). The laptop can no-longer eject the CD tray, and the eject button on the CDROM will not work. I can eject the CD tray from the server command line, but only a server reboot will resolve the problem for the laptop. Not great, but good enough for my limited use case.

Maybe Nic would have an idea of what this is.
As far as I know, the ALLOW_MEDIUM_REMOVAL opcode should be supported by
both fileio and iblock.
 
 

[Jerome Martin]

Post by Andrew Watt
Hi Jerome,

Post by Jerome Martin
Could you please give me the rtslib and targetcli versions you are

using so I can take a look at the code?
/> version
Cannot find configshell version. The configshell package has probably
not been built properly from either the git repository or a public tarball.
Cannot find rtslib version. The rtslib package has probably not been
built properly from either the git repository or a public tarball.
Cannot find targetcli version. The targetcli package has probably not
been built properly from either the git repository or a public tarball.
I installed targetcli from the Ubuntu repositories (apt-get install
targetcli), so I *think* that I'm using version 2.1-1 or targetcli
(http://packages.ubuntu.com/trusty/targetcli), and version 2.2-1 or
rtslib (http://packages.ubuntu.com/trusty/python-rtslib), but I could be
wrong. There are several Python directories on this server (2.7, 3,
3.4), but firing up the Python interpreter brings me into Python 2.7.6.
HTH,
a.

Mmmmh. OK.
I guess I should have a word or two with the Ubuntu package maintainer.

Thanks for the info!