Toradex Easy Installer Raw Partition

On verdin eval board, I tried to modify an existing image.json (which is working) and replace an EXT4 partition with a raw partition. Everything else inside image.json is untouched.

	"partition_size_nominal": 1024,
	"want_maximised": false,
	"content": {
		"label": "Boot-A",
		"filesystem_type": "ext4",
		"filename": "rootfs.tar.xz",
		"uncompressed_size": 456.7
	"partition_size_nominal": 1024,
	"want_maximised": false,
	"content": {
		"filesystem_type": "raw",
		"rawfiles": [
				"filename": "rootfs.raw",
				"dd_options": "seek=0"

This leads to an error, for exactly this partition,

Timeout waiting for partition device /dev/mmcblk2p3.

The image has not be written completely …

Do I misunderstand part of the documentation? Because for me it looks like according to the docs, that a “Block Device” can contain several “Partition”, which contains a “Content”, which can include “Raw Files”.

The reason why I like to do this because one partition is a checked/verified by dm-verity and therefore I copy a raw disk image, while all other partitions are regular ext4 partitions.

I found a workaround for my problem. I partition everything via I don’t use the partitions section of the image.json anymore, while the blockdevs sections still work. This works better than expected and also would one allow to use the extended partition while still using the dos scheme. I just added the following to

sfdisk /dev/mmcblk2 << PARTITIONS
label: dos
unit: sectors

/dev/mmcblk2p1 : start=        2048, size=      204800, type=83, bootable
/dev/mmcblk2p2 : start=      206848, size=    10485760, type=83
/dev/mmcblk2p3 : start=    10692608, size=      454656, type=83
/dev/mmcblk2p4 : start=    11147264, size=    20971520, type=5
/dev/mmcblk2p5 : start=    11149312, size=      227328, type=83
/dev/mmcblk2p6 : start=    11378688, size=      454656, type=83


Hello @thomasstauffer,

Thanks for reporting this.
Could you please send me your image.json file with the modification that you made so that I could try to reproduce the error?
Also, which version of the module, carrier board, and type of image are you using?

Thanks for sharing your workaround in the meantime. And glad to hear that it works for you.

Attached two image-default.json which is working (using ext4) and image-raw.json which is failing with the previously mentioned error (using raw).

Model: Toradex Verdin iMX8M Plus Quad 4GB IT V1.1A, Serial# 15034114
Carrier: Toradex Verdin Development Board V1.1C, Serial# 10952591

image-default.json (2.4 KB)
image-raw.json (2.4 KB)

The image is created via Yocto (only a few added packages). The rootfs/bootfs are both working fine. Also when I use the hack mentioned above the rootfs/bootfs are working fine.

Hi @thomasstauffer,

I’m glad to hear that you were able to solve this by adding the partition scheme in It is definitely a recommended approach to add any modifications in the pre-installation stage. But I was still wondering about the cause of the error you saw with your original approach of modifying the image.json file. So I tried to reproduce the issue by adding the partition into the image.json file on a reference multimedia image just like you did. However, I never ran across this error and the installation just finished successfully for me. So I have a few questions for you:

  1. Which version of Toradex Easy Installer did you use?
  2. When did you see this error message (in the boot log after installation or during the installation phase)?

I used the Toradex Easy Installer which is preconfigured on the boards we get from Toradex or Verdin-iMX8MP_ToradexEasyInstaller_5.7.0-devel-20220710+build.406. The error happens very early in the process, before the Toradex Easy Installer begins to copy an image (the first images are quite large, so it would be noticable). I tried several modification (more/less partitions, …), but I always ended up with the same (just different device name) error. I added a picture:

But let me check then again with the most up to date Toradex Easy Installer.

I tried again with Toradex Easy Installer 5.7.3. When there is no table_type, it seems to work (to mix raw and non raw partitions), when I add "table_type": "gpt" to the blockdev section, the error pops up.

image.json (2.5 KB)

Just for information: We very likely need more than 4 partitions because of using secure boot together with an A/B update strategy (means 2 x bootfs, 2 x rootfs, very likely 2 x var fs, 1 x shared data partition).

Workaround from up there still works and at least for us is good enough.

1 Like

We have the same issue (ToradexEasyInstaller_5.7.4). If the partition table type is set to GPT, the installation fails with the above error as soon as there’s a raw partition listed.
@rudhi.tx : could you reproduce this issue? Is there a fix planned for this?

Hello @anri,

Thanks for your question. Could you please specify which module you are using?
Also, may I ask why you need the GPT partition table? That would help us support you better.


Hardware info
HW model:                 Toradex Verdin iMX8M Plus on Dahlia Board
Toradex version:          0063 V1.1A
Serial number:            14871135
Processor arch:           aarch64

We have ~10 partitions, so we need a GPT partition table. And we’d like to flash some partitions directly from an ext4 image, hence the raw partitions.

Hello @anri,

Thanks for sending the details. I was able to reproduce the issue. I will discuss this internally and let you know of any progress. In the meantime could you please try if you can solve this by creating partitions using script?

Sure, this works and we currently do this as workaround. Still, it’s a workaround…

1 Like

Hello @anri,

I hope you are doing well!
I have good news for you :slight_smile: This issue has been fixed on the latest nightly build of Toradex Easy Installer (I have tested and verified it). Please download the nightly release here and feel free to test it.
Thanks a lot for your patience!

We have validated with nightly build and can confirm this works now. Many thanks.

However, we have observed one issue with raw partitions. Even if we are providing partition_type as 11 it is taking 20.

Also, label fpr raw partition is not getting reflected in gtp table. Is it by design?

Hello @Prashant,

When working with GPT (GUID Partition Table) on a disk, you need to use GUIDs for specifying partition types rather than the hexadecimal codes (that are traditionally used with MBR partition tables). This is probably the reason why it did not work for you.
See the following snippet for reference (which did work for me):

"partition_size_nominal": 128,
"partition_type": "EBD0A0A2-B9E5-4433-87C0-68B6B72699C7",
"want_maximised": false,
"content": {
    "label": "DATA",
    "filesystem_type": "raw",
    "filename": "data.tar.gz",
    "uncompressed_size": 100

You can check the partition type ( Microsoft basic data ) after the image is being installed:

root@verdin-imx8mp-15247278:~# lsblk -o name,mountpoint,label,size,uuid,parttype
NAME         MOUNTPOINT            LABEL  SIZE UUID                                 PARTTYPE
mmcblk2                                  29.1G                                      
|-mmcblk2p1  /media/BOOT-mmcblk2p1 BOOT    48M 8EFB-F2E1                            ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
|-mmcblk2p2  /                     RFS     29G fd706540-dd36-458c-bd9a-c38ed31d7382 0fc63daf-8483-4772-8e79-3d69d8477de4
`-mmcblk2p3                               128M                                      ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
mmcblk2boot0                                4M                                      
mmcblk2boot1                                4M

I found the GUIDs here: debian - fdisk - Hex codes list - which ones are NTFS or FAT 32 among the below list? - Super User

Also, label fpr raw partition is not getting reflected in gtp table. Is it by design?

Regarding this:
Filesystem labels require a filesystem. Since filesystem labels are a part of the filesystem metadata, a partition must be formatted with a recognized filesystem type (which supports labeling) for the label to be applied and recognized. In the case of a raw partition, there’s no filesystem structure or metadata where a label can be stored or read from. This is why it does not show the label.

Thanks Rudhi