Closed GoogleCodeExporter closed 9 years ago
version of the product: veritysetup 1.6.2
Original comment by askxia...@gmail.com
on 26 Jan 2014 at 8:11
version of the product: veritysetup 1.6.2
Original comment by askxia...@gmail.com
on 26 Jan 2014 at 8:11
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
> 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
Original comment by gmazyl...@gmail.com
on 26 Jan 2014 at 9:09
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
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
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
# 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
> 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
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
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
Original issue reported on code.google.com by
askxia...@gmail.com
on 26 Jan 2014 at 8:09