From: Milan Broz <gmazyland@gmail.com>
To: Joe Dougherty <jopado1@yahoo.com>,
"dm-crypt@saout.de" <dm-crypt@saout.de>
Cc: device-mapper development <dm-devel@redhat.com>
Subject: Re: [dm-crypt] LUKS on a jffs2 partition
Date: Fri, 01 Aug 2014 11:26:03 +0200 [thread overview]
Message-ID: <53DB5D2B.5020507@gmail.com> (raw)
In-Reply-To: <53C90676.2060501@gmail.com>
On 07/18/2014 01:35 PM, Milan Broz wrote:
> On 07/18/2014 12:42 AM, Joe Dougherty wrote:
>> I have a small embedded device with a raw nand flash using jffs2
>> filesystem. I want to create a luks container on one of the jffs2
>> partitions. Everything seems to work fine until I try to mount the
>> file system and I receive the error shown below. Here are the
>> commands I used to set this up:
>> cryptsetup luksFormat /dev/mtdblock4 --cipher=aes-cbc-essiv:sha256
>> cryptsetup luksOpen /dev/mtdblock4 efs
>> At this point I can perform luksDump and all looks OK and the /dev/mapper/efs exists. So I continue to create filesystem:
>> mkfs.jffs2 -p -l --eraseblock=0x20000 --no-cleanmarkers --pagesize=0x800 -r ./userdata -o /dev/mapper/efs
>> Now the mount fails:
>> mount -o loud -t jffs2 /dev/mapper/efs /mnt
>> MTD: Attempt to mount non-MTD device "/dev/mapper/efs"
>> mount: mounting /dev/mapper/efs on /mnt failed: Invalid argument
Interesting nobody from embedded world replied here to the obvious problem
which lies in confusion between MTD (memory technology device) and block devices :)
So how (I understand) it works and what is the workaround for these cases:
The jffs2 (and probably other MTD based filesystems) *requires* MTD device parameter to mount.
The /dev/mtdblock* device is created as simulated block device access to underlying MTD device.
Note there is a *hack* in kernel, which allows to mount mtdblock device directly as MTD device,
(it uses underlying device directly - see drivers/mtd/mtdsuper.c for this wonderful magic).
Obviously, if we add another translation layer (dmcrypt or whatever), underlying device
is not an MTD device and this hack fails.
Workaround is to add yet another layer, which simulates new MTD device again on top
of device-mapper stack.
For your example you can do it this way (you need to probably set erase block size
as parameter too):
# modprobe block2mtd block2mtd=/dev/mapper/efs
and the mount newly appeared mtdblock device instead:
# mount -o loud -t jffs2 /dev/mtdblockX /mnt
(I see a lot of kernel warnings here but that's another story.)
Hope this helps.
Milan
prev parent reply other threads:[~2014-08-01 9:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-17 22:42 [dm-crypt] LUKS on a jffs2 partition Joe Dougherty
2014-07-18 11:35 ` Milan Broz
2014-08-01 9:26 ` Milan Broz [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53DB5D2B.5020507@gmail.com \
--to=gmazyland@gmail.com \
--cc=dm-crypt@saout.de \
--cc=dm-devel@redhat.com \
--cc=jopado1@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox