loop-aes: It is not longer possible to create a filesystem on an encrypted DVD-RAM

loop-aes: It is not longer possible to create a filesystem on an encrypted DVD-RAM

[Thomas Siedlich]

Hi!
 
I try to format a loop-aes encrypted DVD-RAM in /dev/sr0 with mke2fs.
 
,----[command line]
| eagle:~# losetup -v -e AES256 -K ./key.gpg /dev/loop2 /dev/sr0
| Password:
| eagle:~# losetup /dev/loop2
| /dev/loop2: [000b]:985 (/dev/sr0) encryption=AES256 multi-key-v3
| eagle:~# mke2fs -K -N 2048 -m 0 -b 4096 -v /dev/loop2
| mke2fs 1.41.12 (17-May-2010)
| fs_types for mke2fs.conf resolution: 'ext2', 'default'
| Filesystem label=
| OS type: Linux
| Block size=4096 (log=2)
| Fragment size=4096 (log=2)
| Stride=0 blocks, Stripe width=0 blocks
| 2240 inodes, 1118352 blocks
| 0 blocks (0.00%) reserved for the super user
| First data block=0
| Maximum filesystem blocks=1149239296
| 35 block groups
| 32768 blocks per group, 32768 fragments per group
| 64 inodes per group
| Superblock backups stored on blocks:
|   32768, 98304, 163840, 229376, 294912, 819200, 884736
|
| Writing inode tables: done
| Writing superblocks and filesystem accounting information: done
|
| This filesystem will be automatically checked every 29 mounts or
| 180 days, whichever comes first.  Use tune2fs -c or -i to override.
| eagle:~# echo $?
| 0
| eagle:~#
`----
 
 
After the successfull mke2fs run ($? = 0) I have got this error message
in syslog:
 
,----[/var/log/syslog]
| Mar 27 15:29:27 eagle kernel: loop2: loop_end_io_transfer err=-95 bi_rw=0x461
| Mar 27 15:29:27 eagle kernel: Buffer I/O error on device loop2, logical block 0
| Mar 27 15:29:27 eagle kernel: lost page write due to I/O error on loop2
| Mar 27 15:29:27 eagle kernel: loop2: loop_end_io_transfer err=-95 bi_rw=0x20
| Mar 27 15:29:27 eagle kernel: Buffer I/O error on device loop2, logical block 0
`----
 
 
And I'm not able to mount the freshly created file system:
 
,----[command line]
| eagle:~# mount -text2 /dev/loop2 /media/backup/
| mount: wrong fs type, bad option, bad superblock on /dev/loop2,
|        missing codepage or helper program, or other error
|        In some cases useful info is found in syslog - try
|        dmesg | tail  or so
|
| eagle:~#
`----
 
,----[/var/log/syslog]
| Mar 27 15:30:40 eagle kernel: EXT2-fs (loop2): error: can't find an ext2 filesystem on dev loop2.
`----
 
 
Do I the same without encryption this means:
 
,----[command line]
| eagle:~# mke2fs -K -N 2048 -m 0 -b 4096 -v /dev/sr0
| mke2fs 1.41.12 (17-May-2010)
| /dev/sr0 is entire device, not just one partition!
| Proceed anyway? (y,n) y
| fs_types for mke2fs.conf resolution: 'ext2', 'default'
| Filesystem label=
| OS type: Linux
| Block size=4096 (log=2)
| Fragment size=4096 (log=2)
| Stride=0 blocks, Stripe width=0 blocks
| 2240 inodes, 1118352 blocks
| 0 blocks (0.00%) reserved for the super user
| First data block=0
| Maximum filesystem blocks=1149239296
| 35 block groups
| 32768 blocks per group, 32768 fragments per group
| 64 inodes per group
| Superblock backups stored on blocks:
|   32768, 98304, 163840, 229376, 294912, 819200, 884736
|
| Writing inode tables: done
| Writing superblocks and filesystem accounting information: done
|
| This filesystem will be automatically checked every 30 mounts or
| 180 days, whichever comes first.  Use tune2fs -c or -i to override.
| eagle:~# mount -text2 /dev/sr0 /media/backup/
| eagle:~#
`----

It just works fine but unencrypted :-(.

I guess it is a problem with loop-aes. Have someone an idea how I
can track this down or has someone seen this already?

My recipe above did work two years ago. I have a couple of working
formatted DVD-RAM from this time. Only e2fsck doesn't work any longer
in fact with the same behavior as mke2fs above this means $? = 0 and
the same errors in /var/log/syslog.

Thanks for help
Thomas



      

Re: loop-aes: It is not longer possible to create a filesystem on an encrypted DVD-RAM

[Jari Ruusu]

Thomas Siedlich wrote:
> I try to format a loop-aes encrypted DVD-RAM in /dev/sr0 with mke2fs.

What loop-AES version are you using?

What kernel version are you using?

> ,----[/var/log/syslog]
> | Mar 27 15:29:27 eagle kernel: loop2: loop_end_io_transfer err=-95 bi_rw=0x461

Backing device returned EOPNOTSUPP (Operation not supported on transport
endpoint) error for a write. Interpreting rest of bi_rw bits depends on
kernel version. For 2.6.38 kernel bi_rw means: "metadata io request",
"request to discard sectors", and "This bio has already been subjected to
throttling rules. Don't do it again"

> | Mar 27 15:29:27 eagle kernel: Buffer I/O error on device loop2, logical block 0
> | Mar 27 15:29:27 eagle kernel: lost page write due to I/O error on loop2

Somehow EOPNOTSUPP error got interpreted as I/O error and/or write was not
retried with bi_rw bits cleared that backing device do not support.

> | Mar 27 15:29:27 eagle kernel: loop2: loop_end_io_transfer err=-95 bi_rw=0x20
> | Mar 27 15:29:27 eagle kernel: Buffer I/O error on device loop2, logical block 0

Backing device returned EOPNOTSUPP error for a read. Interpreting rest of
bi_rw bits depends on kernel version. For 2.6.38 kernel bi_rw means:
"metadata io request".

> It just works fine but unencrypted :-(.

As a temporary workaround, you can create unencrypted file system and then
encrypt it in-place using aespipe tool.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Re: loop-aes: It is not longer possible to create a filesystem on an encrypted DVD-RAM

[markus reichelt]

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]

* Thomas Siedlich <thomas.siedlich@yahoo.com> wrote:

> [solved]

Thanks, added to the FAQ.

-- 
left blank, right bald
loop-AES FAQ: http://mareichelt.de/pub/texts.loop-aes.php#faq

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: loop-aes: It is not longer possible to create a filesystem on an encrypted DVD-RAM

[Thomas Siedlich]

[solved]

Hi Jari!

Jari Ruusu wrote:
> Thomas Siedlich wrote:
> > For my kernel it should mean (if I interpret
> > /usr/src/linux/include/linux/bio.h right):
> > "Tell the IO scheduler not to wait for more requests
> > after this one has been submitted, even if it is a SYNC request."
> > "synchronous I/O hint."
> > "barrier"
> > "write"
> 
> "barrier" bit is the one that triggered EOPNOTSUPP error
> from backing device.
> 
> > Here:
> > "barrier"
> > and
> > "read"
> 
> Same here.
> 
> > So "barrier" is the same in both messages. But why does it work
> > without loop? The backing device should be the same, shouldn't it?
> 
> Because loop-AES-v3.3a has a bug in barrier request handling that
> triggers when a barrier request is sent to backing device that can't
> handle barrier request. This is what happens:
> 
> 1) Block layer kernel code above loop driver issues empty
>    barrier request to loop driver.
> 2) Loop driver does not pass that empty barrier request to
>    backing device.
>    Instead it sets a flag to indicate "mark next request as barrier".
> 3) Next request arrives at loop driver, loop driver marks that one
>    as barrier request, and eventually sends it to backing device.
> 4) Backing device driver decides that it doesn't do
>    barriers at all, and aborts processing that request.
> 
> In short: due to loop driver bug, backing device driver
> aborted wrong request with EOPNOTSUPP error code.

Thanks for the explanation.

> This bug is fixed in loop-AES-v3.6b (it got fixed as part
> of queue code removal/rewrite). 

Yes it is fixed.

> If you can reproduce this error with loop-AES-v3.6b, then I
> definitely want to know about it.

No I can't :-). I'm running now 2.6.38.2 (kernel.org) with
loop-AES-v3.6b and it works. I can mke2fs on the loop device
without errors. The filesystem ist mountable and I can e2fsck
the filesystem without syslog errors.

Thanks a lot Jari and sorry for the noise.

Thomas



      

Re: loop-aes: It is not longer possible to create a filesystem on an encrypted DVD-RAM

[Jari Ruusu]

Thomas Siedlich wrote:
> For my kernel it should mean (if I interpret
> /usr/src/linux/include/linux/bio.h right):
> "Tell the IO scheduler not to wait for more requests after this
>         one has been submitted, even if it is a SYNC request."
> "synchronous I/O hint."
> "barrier"
> "write"

"barrier" bit is the one that triggered EOPNOTSUPP error from backing device.

> Here:
> "barrier"
> and
> "read"

Same here.

> So "barrier" is the same in both messages. But why does it work
> without loop? The backing device should be the same, shouldn't it?

Because loop-AES-v3.3a has a bug in barrier request handling that triggers
when a barrier request is sent to backing device that can't handle barrier
request. This is what happens:

1) Block layer kernel code above loop driver issues empty barrier request to
   loop driver.
2) Loop driver does not pass that empty barrier request to backing device.
   Instead it sets a flag to indicate "mark next request as barrier".
3) Next request arrives at loop driver, loop driver marks that one as
   barrier request, and eventually sends it to backing device.
4) Backing device driver decides that it doesn't do barriers at all, and
   aborts processing that request.

In short: due to loop driver bug, backing device driver aborted wrong
request with EOPNOTSUPP error code.

This bug is fixed in loop-AES-v3.6b (it got fixed as part of queue code
removal/rewrite). If you can reproduce this error with loop-AES-v3.6b, then
I definitely want to know about it.

Seeing small amount of EOPNOTSUPP errors (loop_end_io_transfer err=-95 ...)
in syslog is normal. This can happen when a file system is probing and/or
learning that backing device under loop device driver does not support
barriers.

-- 
Jari Ruusu  1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9  DB 1D EB E3 24 0E A9 DD

Re: loop-aes: It is not longer possible to create a filesystem on an encrypted DVD-RAM

[Thomas Siedlich]

Hi Jari!

Jari Ruusu wrote:
> Thomas Siedlich wrote:
> > I try to format a loop-aes encrypted DVD-RAM in
> > /dev/sr0 with mke2fs.
> 
> What loop-AES version are you using?

3.3a, which is the latest in Debian.
I see sourceforge has 3.6b :-( and I see also that the Debian package
has orphaned.
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614808>
It's a pity.

> What kernel version are you using?

2.6.35.3 (selfcompiled from kernel.org).

> > ,----[/var/log/syslog]
> > | Mar 27 15:29:27 eagle kernel: loop2:
> > loop_end_io_transfer err=-95 bi_rw=0x461
> 
> Backing device returned EOPNOTSUPP (Operation not supported
> on transport
> endpoint) error for a write. Interpreting rest of bi_rw
> bits depends on
> kernel version. For 2.6.38 kernel bi_rw means: "metadata io
> request",
> "request to discard sectors", and "This bio has already
> been subjected to
> throttling rules. Don't do it again"

For my kernel it should mean (if I interpret 
/usr/src/linux/include/linux/bio.h right):
"Tell the IO scheduler not to wait for more requests after this
        one has been submitted, even if it is a SYNC request."
"synchronous I/O hint."
"barrier"
"write"

> > | Mar 27 15:29:27 eagle kernel: Buffer I/O error on
> >   device loop2, logical block 0
> > | Mar 27 15:29:27 eagle kernel: lost page write due to
> >   I/O error on loop2
> 
> Somehow EOPNOTSUPP error got interpreted as I/O error
> and/or write was not
> retried with bi_rw bits cleared that backing device do not
> support.
> 
> > | Mar 27 15:29:27 eagle kernel: loop2:
> >   loop_end_io_transfer err=-95 bi_rw=0x20
> > | Mar 27 15:29:27 eagle kernel: Buffer I/O error on
> >   device loop2, logical block 0
> 
> Backing device returned EOPNOTSUPP error for a read.
> Interpreting rest of
> bi_rw bits depends on kernel version. For 2.6.38 kernel
> bi_rw means:
> "metadata io request".

Here:
"barrier"
and
"read"

So "barrier" is the same in both messages. But why does it work
without loop? The backing device should be the same, shouldn't it?

> > It just works fine but unencrypted :-(.
> 
> As a temporary workaround, you can create unencrypted file
> system and then
> encrypt it in-place using aespipe tool.

Great idea! I give it a try.

dd if=/dev/sr0 bs=64k | aespipe -e AES256 -K ./key.gpg \
  | dd of=/dev/sr0 bs=64k conv=notrunc

This works. Thanks Jari for this workaround!

Thomas