eternaltyro / cryptsetup

Since Google code is shuttering...
http://code.google.com/p/cryptsetup
GNU General Public License v2.0
0 stars 0 forks source link

yaffs2 on nand flash and veritysetup #203

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1.mount -t yaffs2 /dev/mtdblock4 /tmp/
yaffs: dev is 32505860 name is "mtdblock4" rw
yaffs: passed flags ""

2.ls /tmp
lost+found    romfs.img     squashfs.img

3.umount /tmp

4.veritysetup format /dev/mtdblock4 /dev/mtdblock5

5.veritysetup create dm-verity /dev/mtdblock4 /dev/mtdblock5 8bd95b2911f8630a489
67400088733db82fe662f545b16a0950ec88583d38d92

6.mount -t yaffs2 /dev/mapper/dm-verity /tmp
yaffs: dev is 264241152 name is "dm-0" ro
yaffs: passed flags ""
mount: mounting /dev/mapper/dm-verity on /tmp failed: Invalid argument

What is the expected output? What do you see instead?
I expected the dm-verity of device mapper is mounted succeed, but this is 
failed.

What version of the product are you using? On what operating system?
Linux 192.168.6.108 3.4.67_s40 #13 SMP Sun Jan 26 23:19:11 CST 2014 armv7l 
GNU/Linux

Please provide any additional information below.
I think the problem is whether or not that the oob data of nand flash is not 
mapped.

Original issue reported on code.google.com by askxia...@gmail.com on 26 Jan 2014 at 8:09

GoogleCodeExporter commented 9 years ago
version of the product: veritysetup 1.6.2

Original comment by askxia...@gmail.com on 26 Jan 2014 at 8:11

GoogleCodeExporter commented 9 years ago
version of the product: veritysetup 1.6.2

Original comment by askxia...@gmail.com on 26 Jan 2014 at 8:11

GoogleCodeExporter commented 9 years ago
Supplement the output of command "veritysetup format /dev/mtdblock4 
/dev/mtdblock5"
VERITY header information for /dev/mtdblock5
UUID:                   1196eb3c-24c4-4c7d-ac2f-c0bbe683b165
Hash type:              1
Data blocks:            25600
Data block size:        4096
Hash block size:        4096
Hash algorithm:         sha256
Salt:                   
c662b049da15a72accd1e05f722f1c1719896ac6b7de849e31869da20ec69b09
Root hash:              
8bd95b2911f8630a48967400088733db82fe662f545b16a0950ec88583d38d92

Original comment by askxia...@gmail.com on 26 Jan 2014 at 8:13

GoogleCodeExporter commented 9 years ago
> mount: mounting /dev/mapper/dm-verity on /tmp failed: Invalid argument

I do not think this is directly related to veritysetup but perhaps kernel 
device-mapper, can you try to map e.g. simple linear device-mapper volume, 
something like:

dmsetup create test --table "0 `blockdev --getsize /dev/mtdblock4` linear 
/dev/mtdblock4 0"

and try to mount /dev/mapper/test? If it works, please post strace and output 
of messages from syslog (from both cases). (Anyway, maybe dm-devel list will be 
more appropriate for this report.)

Original comment by gmazyl...@gmail.com on 26 Jan 2014 at 9:04

GoogleCodeExporter commented 9 years ago

Original comment by gmazyl...@gmail.com on 26 Jan 2014 at 9:09

GoogleCodeExporter commented 9 years ago
dmsetup create test --table "0 1024000 linear /dev/mtdblock4 0"
device-mapper: table: 252:1: mtdblock4 too small for target: start=0, 
len=1024000, dev_size=204800
device-mapper: resume ioctl on test failed: Invalid argument
Command failed

dmsetup create test --table "0 204800 linear /dev/mtdblock4 0"

# dmsetup ls
test    (252:1)

# dmsetup deps
test: 1 dependencies    : (31, 4)

mount -t yaffs2 /dev/mapper/test tmp/
yaffs: dev is 264241153 name is "dm-1" rw
yaffs: passed flags ""
mount: mounting /dev/mapper/test on tmp/ failed: Invalid argument

Still fails,Why???

Original comment by askxia...@gmail.com on 26 Jan 2014 at 9:48

GoogleCodeExporter commented 9 years ago
The romfs is succeed to dmsetup. The process of operation is:
# dmsetup create test-romfs --table "0 2048000 81920 /dev/mtdblock6 0" 
device-mapper: table: 252:0: 81920: unknown target type
device-mapper: ioctl: error adding target to table
device-mapper: reload ioctl on test-romfs failed: Invalid argument
Command failed

# dmsetup create test-romfs --table "0 81920 linear /dev/mtdblock6 0"

# mount /dev/mapper/test-romfs tmp/

# cd tmp/

# ls
blkone  blktwo

# hexdump blkone 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0200000

# hexdump blkone 
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0200000

Original comment by askxia...@gmail.com on 26 Jan 2014 at 9:56

GoogleCodeExporter commented 9 years ago
ok, so if it fails even with linear, it is not dm-verity problem but some 
generic restriction between mtd / device-mapper maybe arch related (this is 
ARM).

What is in syslog? Maybe also paste lsblk ; lsblk -D ; lsblk -t  (maybe you can 
find some problem in block sizes in stacked devices, dunno.)

But perhaps the best is to send report to dm-devel list (link both issues 
203/204 from here).

Original comment by gmazyl...@gmail.com on 26 Jan 2014 at 10:00

GoogleCodeExporter commented 9 years ago
# dmsetup create test-romfs --table "0 2048000 linear /dev/mtdblock6 0"
device-mapper: table: 252:0: mtdblock6 too small for target: start=0, 
len=2048000, dev_size=81920
device-mapper: resume ioctl on test-romfs failed: Invalid argument
Command failed

This is used to get the size of mtdblock6

Original comment by askxia...@gmail.com on 26 Jan 2014 at 10:05

GoogleCodeExporter commented 9 years ago
> This is used to get the size of mtdblock6

btw why? use blockdev --getsz <device> (for sector count) or if you have no 
blockdev installed, just cat /sys/block/<device>/size

Original comment by gmazyl...@gmail.com on 26 Jan 2014 at 10:40

GoogleCodeExporter commented 9 years ago
I am seeing similar behaviour on a 3.0.15 kernel using jffs2 and cryptsetup 
(using LUKS). This is on an armv7l arch. Everything appears to work except for 
the final mounting of the mapped device. Has the original poster of this issue 
found a resolution?

Original comment by jopa...@yahoo.com on 9 Jul 2014 at 7:52

GoogleCodeExporter commented 9 years ago
Please read
http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7567

I think the problem is exactly the same, you need to add another MTD emulation 
layer on top of your device-mapper device stack.

Original comment by gmazyl...@gmail.com on 1 Aug 2014 at 9:30