Home FAQ Mailing Lists / IRC Source Documentation Misc Archive Fellows

Memory Technology Devices

UBI FAQ and HOWTO

How do I enable UBI?

In the Linux configuration menu, go to "Device Drivers" -> "Memory Technology Devices (MTD)" -> "UBI - Unsorted block images", and mark the "Enable UBI" check-box. UBI may be either compiled into the kernel or be built as a kernel module.

How do I attach an MTD device?

Each MTD device has a name and a number, which you may find out by examining the /proc/mtd file. The preferable way to attach MTD devices is to attach them by name, not by number, because MTD device numbers may change if you change the layout of your flash, while the names will supposedly stay the same.

If UBI is compiled as a kernel module, it is enough to specify the MTD device name or number to attach in the module arguments, e.g.

$ modprobe ubi mtd=rootfs
$ modprobe ubi mtd=0

loads the UBI kernel module and attaches MTD device named "rootfs" or with number 3 (mtd3). And

$ modprobe ubi mtd=config mtd=rootfs
$ modprobe ubi mtd=3 mtd=5

command loads UBI kernel module and attaches MTD devices named "config" and "rootfs", or mtd3 and mtd5.

If UBI is compiled into the kernel, the mtd device to attach may be specified in the ubi.mtd=kernel boot parameter, e.g.,

ubi.mtd=rootfs
ubi.mtd=0

command makes UBI attach MTD device named "rootfs" or mtd3 when the kernel is booting. And

ubi.mtd=config ubi.mtd=rootfs
ubi.mtd=3 ubi.mtd=5

command makes UBI attach MTD devices named "config" and "rootfs", or mtd3 and mtd5.

And finally, MTD devices may be attached or detached at any time with the ubiattach and ubidetach utilities; For example,

$ ubiattach /dev/ubi_ctrl -m 3

attaches mtd3. But these utilities will work with kernel versions starting from version 2.6.25. And someone should update them and teach to accept MTD device names, not only MTD device numbers.

How do I create/delete UBI volumes?

Use the ubimkvol and ubirmvol utilities. For example, the below command creates an 128MiB volume on UBI device 0:

$ ubimkvol /dev/ubi0 -N rootfs -s 128MiB

and the following command removes it:

$ ubirmvol /dev/ubi0 -n 0

For additional information, use ubimkvol -h and ubirmvol -h.

How do I run JFFS2 on top of an UBI volume?

There is an additional driver called gluebi which can emulate fake MTD devices for each UBI volume and JFFS2 can be used with these emulated MTD devices. Enable gluebi in the UBI configuration menu (the "MTD devices emulation driver (gluebi)" option).

Note, pre-2.6.31 kernels did not have a separate gluebi driver and it was built into the UBI driver. The corresponding UBI configuration menu option was "Emulate MTD devices"

Can I run ext2 on top of UBI?

UBI is not a block device emulation layer, it is not an FTL. Neither ext2 nor other "traditional" file systems can be run on top of an UBI device. Please, read the big red note and overview documentation sections to realize why.

However, given UBI takes care of many flash complexities, it provides a bad-block-free block device access on top of UBI volumes. This feature is useful to mount read-only file systems.

Can I run squashfs on top of UBI?

Yes. UBI allows to create a read-only block device on top of a UBI volume which is suitable for read-only, block-oriented file systems, such as squashfs. See the UBI block device section for more details.

Do I have to format my empty flash before running UBI on top of it?

Ideally, yes, but not necessarily.

Roughly speaking, "UBI-formatted MTD device" has each PEB erased and containing a valid EC header. However, it is not always possible because many a lot of existing software is not UBI-aware and cannot preserve erase counters. Often all it can do is to wipe out the flash. This is why UBI can to deal with empty flash perfectly well - it just automatically formats it.

So the answer is no, you do not have to. For example, if you wipe out the flash and try to attach it to UBI - it will work. UBI will just automatically format the flash. The formatting process takes time, though.

But keep in mind that every time you erase the flash, you lose erase counters, so you lose wearing information. Doing this over and over again may wear out some eraseblocks. This is especially dangerous on MLC NAND flashes which have very low eraseblock life-cycle. Try to use UBI-aware utilities and flashing programs.

How do I erase flash and preserve erase counters?

Use the ubiformat utility. Example:

$ ubiformat /dev/mtd0
ubiformat: mtd0 (NAND), size 536870912 bytes (512.0 MiB), 131072 eraseblocks of
131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 4095 -- 100 % complete
ubiformat: 4094 eraseblocks have valid erase counter, mean value is 104
ubiformat: bad eraseblocks: 13, 666
ubiformat: formatting eraseblock 4095 -- 100 % complete

Note! If you use an old kernel, which is older than 2.6.30 and where MTD does not support sysfs, you have to pass "-s" argument to ubiformat.

This section has some hints for those who implement a custom UBI flasher.

How do I create UBI images?

UBI images may be created using the ubinize utility. This utility takes the configuration file on input and generates an UBI image on output. The input configuration file describes all UBI volumes which the resulting UBI image has to contain. The configuration file has the ini-file syntax. Here is an example:

$ cat config.ini
[configuration-data-volume]
mode=ubi
image=config_data.img
vol_id=0
vol_size=512KiB
vol_type=static
vol_name=configuration

[rootfs-volume]
mode=ubi
image=rootfs.img
vol_id=1
vol_size=220MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize

$ ./ubinize -o ubi.img -p 128KiB -m 512 -s 256 config.ini

The config.ini file tells UBIFS to create 2 volumes:

static configuration volume of 512KiB in size, assign it ID 0 and name "configuration"; the contents of the volume should be taken from the config_data.img file;
dynamic root file-system volume of 220MiB in size, assign it ID 1 and name "rootfs"; the contents of the volume should be taken from the rootfs.img file; this volume should also have "auto-resize" flag which means the size of this volume will be amended when UBI runs for the first time; namely, UBI will make this volume larger by giving available eraseblocks; this may be very useful in case of NAND flash (see here for more details).

So in the above example, ubinize basically reads 3 input files:

The config.ini file which describes how many volumes should the resulting ubi.img file contain, their sizes, names, and so on; it also refers the files containing the data which should be put to the volumes; note, if the volume is supposed to be empty, just do not specify the image file;
the config_data.img image file for the first volume;
the rootfs.img image file for the second volume.

Users often wonder why ubinize needs a configuration file. The answer is that one UBI image may contain many UBI volumes with different characteristics and it is difficult to invent a nice command-line interface for specifying all those characteristics. Thus a configuration file is used. But feel free sending a patch which teaches ubinize working without the configuration file if there is only one volume.

Note, UBI reserves physical flash space for volumes. Namely, UBI reserves a physical eraseblock for each logical eraseblock. The size if LEB 130560 bytes in our example (found out by running ubinize with -v option), which means that the configuration volume will have 5 LEBs ([512 * 1024] / 130560 rounded up) and the root file-system volume will have at least 1767 LEBs. This means that the MTD device the ubi.img is going to be flashed to has to have at least 1772 physical eraseblocks, which is about 221MiB. But because of the UBI overhead (see this section), the MTD device actually has to be at least 225MiB in size. Of course it may be larger, in which case the "rootfs" volume will be re-sized and take the rest of the flash space (because of the auto-resize flag).

The implications of the above paragraph are important. The vol_size option effectively represents the minimum size of the flash where the volume will be installed. If you are working with multiple devices (i.e. you are producing an image to be flashed on various devices, even when 'identical'), the amount of usable flash will vary because some devices have more bad blocks than others. Excluding the vol_size option will cause vol_size to be automatically calculated based on the size of the input image, and this will produce maximum robustness in the face of varying numbers of bad blocks on target devices. You can combine this with the autoresize functionality so that the maximum amount of free space is made available upon first mount.

Also, the config_data.img and rootfs.img input files do not have to be 512KiB and 220MiB respectively, but may be smaller if they contain less data. In this case the resulting ubi.img file will also be smaller than 221MiB. All the ubinize utility does is it takes the image files, splits them to LEB-sized chunks, forms PEB data by adding UBI headers to these LEB chunks, and writes the result to the output file. It also writes the volume table (2 physical eraseblocks). Thus, ubi.img file size will be small if the input volume images are small. And ubinize does not do any further padding.

Please, use the Use the ubiformat utility to flash the resulting UBI image. Also, you can find detailed description of how UBI-aware flashing programs should work in this section.

How do I find out min. I/O unit size, sub-page size, and LEB size?

If you run kernel version 2.6.30 or later, the easiest way to find out all these parameters is to run the mtdinfo tool, which reports them. Of course, the tool has to be run on the target.

Otherwise, first find out the physical eraseblock (PEB) size from the flash manual, or from the /proc/mtd file on the target.

Refer this and this sections for some hints about what the min. I/O unit and sub-page sizes may be for you.

The LEB size is defined by:

physical eraseblock size;
minimum input/output unit size;
sub-page size;

Please, read this section for information about how LEB size is calculated (it is denoted by O there).

How do I flash UBI images and preserve erase counters?

Use the ubiformat utility. Example:

$ ubiformat /dev/mtd0 -f ubi.img
ubiformat: mtd0 (NAND), size 536870912 bytes (512.0 MiB), 131072 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 4095 -- 100 % complete
ubiformat: 4094 eraseblocks have valid erase counter, mean value is 105
ubiformat: bad eraseblocks: 13, 666
ubiformat: flashing eraseblock 50 -- 100 % complete
ubiformat: formatting eraseblock 4095 -- 100 % complete

Note, this section has describes how UBI-aware flasher program has to work.

Important!: even if you do not care about erasecounters, do not use dd for flashing UBI images to NAND flashes, because dd does handle bad eraseblocks.

Important!: even if you do not care about erasecounters, do not use nandwrite for flashing UBI images containing UBIFS file-system to NAND flashes, read here for more information.

Can UBI logical eraseblocks be written randomly?

No, the flash chip restrictions have to be taken into account. This is because UBI logical eraseblocks (LEB) are mapped to physical eraseblocks (PEB), and an LEB write operation is essentially a write to the corresponding PEB plus a small offset. The important flash restrictions are:

all writes have to be aligned to the min. I/O unit size and be multiple of min. I/O unit size;
sometimes it is prohibited to write more then once to the same PEB offset (e.g., in case of NAND flash);
many NAND flashes (specifically, MLC NAND flashes) require NAND pages to be written sequentially from the beginning of the physical eraseblock, to the end of the physical eraseblock; for example, it is prohibited to first write to offset 2048, then to offset 0; once offset 2048 has been written to, it is possible to write only to further offsets.

Even if the flash chip is devoid of the last restriction, UBI anyway requires logical eraseblocks to be written sequentially from the beginning to the end. This is because UBI calculates data CRC when moving logical eraseblocks to other physical eraseblocks (see here for more information), so a write an offset which is less than the furthest written data offset causes CRC errors;

Why UBI does not use OOB area of NAND flashes?

Because many flashes (e.g., NOR) do not have OOB and UBI was designed to be generic. Also, modern MLC NAND flashes use whole OOB area for the ECC checksum, so there is no room for application data.

But of course, things could be optimized for SLC NAND flashes if UBI used the space available in the OOB area. This is not implemented, but one could probably do this.

Is UBI tolerant of power failures?

Yes, UBI is designed to be tolerant of power failures and unclean reboots.

What happens when the PEBs reserved for bad block handling run out?

By default, about 2% of the whole chip size (20/1024 PEB) are reserved for bad blocks handling. If the number of blocks that turn bad exceeds that allocation, an error message will be printed and UBI will switch to read-only mode.

Note: If at attach time, there's already more bad blocks than reserved PEBs, UBI will stay in read-write mode. The switching to read-only mode only occurs when a new bad block appears.

May UBI be used on MLC flash?

Yes, it may, as long as the flash is supported by the MTD layer. UBI does not use OOB and it requires data to be written sequentially (see here). UBI guarantees that the difference between maximum and minimum erase-counters is withing certain threshold, which is 4096 by default. Since MLC flashes have quite low eraseblock life-cycle (about 1000-10000, unlike 100000-1000000 for SLC NAND and NOR flashes), the threshold has to be set to a lower value (e.g., 256). This may be done via the Linux kernel configuration menu.

Note, unlike UBI, JFFS2 uses random wear-leveling algorithm, which is in fact not completely random, because JFFS2 makes it more probable to garbage collect eraseblocks with more dirty data. This means that JFFS2 is not really appropriate for MLC flashes. However, it is possible to use JFFS2 file-system on top of UBI (see this section) to improve wear-leveling.

Why does ubiattach on a freshly formatted device fail with "Invalid argument"?

On NAND devices that support sub-page accesses, ubiformat may choose a different location for the VID header to the kernel UBI driver. This can result in the following error when attaching to a UBI device:

$ ubiformat /dev/mtd0
ubiformat: mtd0 (NAND), size 260046848 bytes (248.0 MiB), 131072 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
[...]
$ ubiattach /dev/ubi_ctrl -m 0
ubiattach: error!: cannot attach mtd0
           error 22 (Invalid argument)

and in dmesg you will see:

UBI error: validate_ec_hdr: bad VID header offset 2048, expected 512
UBI error: validate_ec_hdr: bad EC header
UBI error: ubi_io_read_ec_hdr: validation failed for PEB 0

This happens because ubiformat assumes the flash does not support sub-pages, because the kernel does not expose sub-page information to user-space (which should be fixed when sysfs support is added to MTD). However, the kernel UBI driver assumes sub-pages are supported and sub-page size is 512 bytes in our example. To fix this, you should override the default sub-page size that ubiformat uses to what the kernel expects using the -s option of ubiformat. For example, if you see the error above in dmesg, you can tell ubiformat to assume 512-byte sub-page by executing:

$ ubiformat /dev/mtd0 -s 512

Or you may pass "-O 512" would have the same effect as "-s 512" - the VID header would be put at offset 512.

Alternately, you may wish to actually attach to the UBI device by forcing VID header offset to be 2048 bytes. In other words, you may ask UBI to avoid using sub-pages. This is not recommended since this will require more storage overhead, but may be useful if your NAND driver incorrectly reports that it can handle sub-page accesses when it should not. To do this with ubiattach, use:

$ ubiattach /dev/ubi_ctrl -m 0 -O 2048

or on the kernel command-line, pass:

ubi.mtd=0,2048

What is a sub-page?

Please, refer to this section.

I get "ubi_io_write: error -5 while writing 512 bytes to PEB 5:512"

If you have a 2048 bytes per NAND page device, and have CONFIG_MTD_NAND_VERIFY_WRITE enabled in your kernel, you will need to turn it off. The code did not currently (as of 2.6.26) perform verification of sub-page writes correctly. As UBI is one of the few users of sub-page writes, not much else seemed to be affected by this bug. In Linux 3.7, CONFIG_MTD_NAND_VERIFY_WRITE was removed:

commit 657f28f8811c92724db10d18bbbec70d540147d6
Date:   Tue Aug 14 22:38:45 2012 -0400

    mtd: kill MTD_NAND_VERIFY_WRITE

    "Both UBI and JFFS2 are able to read verify what they wrote already.
    There are also MTD tests which do this verification. So I think there
    is no reason to keep this in the NAND layer, let alone wasting RAM in
    the driver to support this feature. Besides, it does not work for sub-pages
    and many drivers have it broken. It hurts more than it provides benefits."

    So kill MTD_NAND_VERIFY_WRITE entirely.

I get "no VID header found at PEB 7923, only 0xFF bytes"

The messages mean that UBI could not find VID header in the eraseblock, but the header supposed to be there. This probably means some corruption.

However, if you have UBI "build" debugging messages enabled, (CONFIG_MTD_UBI_DEBUG_MSG_BLD=y), you may see a lot of these messages and they are harmless. They are just debugging messages in this case.

I see this UBI error: "ubi_io_read: error -74 (ECC error) while reading 126976 bytes from PEB 47:4096, read 126976 bytes"

The -74 error code is -EBADMSG and means an ECC error. In other words, UBI tried to read some data from the flash, but the flash driver found that there is an uncorrectable ECC error, and returned -EBADMSG.

There may be many reasons for this. It may be because your NAND driver is buggy, or you HW is buggy. We recommend you to validate the driver using the MTD tests.

The other possibility is that you failed to flash your UBI/UBIFS image properly. Try to erase your flash, then attach it to UBI/UBIFS without writing any image, and check if you still have these errors.

If you do not have errors when you mount empty flash, it is probably indeed related to how you flash the UBI/UBIFS images. One typical problem is related to ECC calculation algorithm - read here for more information. Make sure that you use ubiformat, or make sure either that your flashing program skips 0xFF properly (see here) or that your UBIFS image was generated with the "free space fixup" flag set (see here).

Another possibility is that your flash reports that it supports sub-pages, but does not actually support them properly.

How do I force UBI to ignore sub-pages?"

If your NAND flash supports sub-pages, UBI will use them. But sometimes you may want to ask UBI to ignore sub-pages, for example if you have an UBI image which was made for a similar NAND flash, but without sub-pages, or if you just want to disable sub-pages for testing purposes. You may do this by forcing UBI to read/write the VID header from/to the beginning of the second page, instead of the second sub-page (which is the default behavior). And UBI uses sub-pages only for VID headers, so this is enough.

If you attach MTD devices using the ubiattach tool - just use the --vid-hdr-offset option and specify the second page offset. For example, if you have 2048-byte NAND pages, use --vid-hdr-offset 2048. All the below examples also assume 2048-byte NAND pages.

If you do not use ubiattach and instead specify the MTD device to attach using kernel boot parameters (see here), then you may put VID header offset after the MTD device name or number. For example:

$ ubi.mtd=rootfs,2048
$ ubi.mtd=3,2048

will attach MTD device named "rootfs" (or MTD device number 3) and force UBI to read/write VID headers from/to offset 2048, which is the second NAND page in the eraseblock.

Similarly, if you use module load parameters, try

$ modprobe ubi mtd=rootfs,2048
$ modprobe ubi mtd=3,2048

And of course, if you have an MTD partition which is already formatted so that sub-pages are used, which means all VID headers sit at offsets 512 (second sub-page of a 2048-byte NAND page), you cannot force UBI to stop using sub-pages (it will fail). You may do this only if you are attaching an empty MTD partition, or if the flash is already formatted so that all VID headers are at offset 2048. This means that if you use or ubinize, you should avoid using the -s parameter.

How do I implement UBI flasher?

Please, read here

What does the "ubi_bgt0d" thread do?

The UBI back-ground thread is a per-UBI device thread which has "ubi_bgtXd" name, where "X" is the UBI device number. For example, "ubi_bgt0d" is a background thread corresponding to UBI device 0.

The UBI background thread is doing background physical eraseblock erasure. This is an important optimization which greatly improves UBI I/O throughput (applications do not have to wait for erasure completion). For example, UBI unmap operation schedules physical eraseblocks for erasure.

The background thread also tortures faulty physical eraseblocks.

The UBI background thread also moves data from more worn-out physical eraseblocks to less worn out, i.e., performs wear-leveling. It also moves data from physical eraseblocks which have bit-flips. See the UBI overview section for some more information.

Note, UBI may work without the background thread, so the thread is just an optimization, although a very important one.

How do I speed up UBI initialization

As this section explains, UBI has scalability limitations imposed by its design, so there is no much you can do about it but without re-designing. Here are some ideas

When UBI attaches an MTD device, it reads a lot of data from the media. If you manage to improve read speed on the driver level, you will also speed up UBI initialization.
The MTD layer supplies upper layers (including UBI) with information about bad PEBs. It keeps so-called bad block table in RAM, which is usually 1 bit per PEB. When the driver initializes, it has to build this table by scanning whole flash media, which normally includes reading OOB area of 1st NAND page of each PEB. This takes time and may be improved by using on-flash BBT (bad block table). In this case the bad PEB map is stored on flash and MTD does not have to do any scanning. See the NAND_USE_FLASH_BBT constant in the Linux source codes. But note, bad PEB scanning is usually minor comparing to the UBI scan time, so on-flash BBT is not probably going to give much.
UBI scan time linearly depends on the number of PEB to read, which means that you may speed it up by merging two or more PEB and treating them as one composite PEB. Then from UBI POV PEB size will become larger, and the amount of PEBs to Scan will become smaller. The best way to do this is probably to teach UBI merging PEBs. It does not have to merge adjacent PEB. Instead, UBI can store the paired PEB number in the EC header. If one of the PEBs in the pair becomes bad, the pair may be "re-constructed" by moving the good PEB somewhere else and substituting the bad PEB by a good one from the pool of reserved PEBs.
Design and implement UBI2. You may teach UBI to store erase counters and mapping information in a separate internal volume, instead of storing it in each PEB. Then you could implement the "anchor" idea to quickly find that internal volume (see here). This would solve slow UBI attach problem, but not linear memory consumption problem. Later we could have UBI3 which could solve more issues. This plan was suggested here. Indeed, it is easier to solve one problem at a time.

Why a dynamic volume is faster to access than a static volume of the same size?

Static UBI volumes were originally designed to store blobs of data like configuration files. Static volumes provide CRC-32 protection for the stored data, and static volumes know how much data they store. E.g., if you have a static volume /dev/ubi0_1 of 254KiB in size consisting of 2 127KiB LEBs, and you store a 200KiB file there, and you read whole /dev/ubi0_1 , you'll get exactly 200KiB. If /dev/ubi0_1 was a dynamic volume, you'd read 254KiB. So static volumes make it easier to store blobs of data.

Thus, static volumes are slower to access (comparing to dynamic volumes) because UBI has to check the data CRC-32 checksum. And note, it is not a good idea to use static volumes with R/O UBIFS because UBIFS also protects all the information it stores in the UBI volume with CRC-32 checksums, and using static volumes with UBIFS would only slow down UBIFS mount speed.

How do I debug UBI?

Use fake MTD device

When debugging UBI one doesn't have to use a real embedded platform with real flash. In many cases, it is easier to use a PC with an MTD device emulator and run UBI on top of this emulated MTD device. In fact, this is how most of the UBI development was done.

There are 3 MTD device emulators in Linux kernel available:

mtdram which simulates NOR flash in RAM;
nandsim which simulates NAND flash in RAM;
block2mtd which simulates NOR flash on top of a block device;

For example, to get a 32MiB fake NOR flash, run

$ modprobe mtdram total_size=32768

or to get a 64MiB fake NAND flash, run

$ modprobe nandsim second_id_byte=0x36

See here for more information about the NAND simulator.

To ensure that you have fake MTD devices, run "cat /proc/mtd". It should print something like

dev:    size   erasesize  name
mtd0: 02000000 00020000 "mtdram test device"
mtd1: 04000000 00004000 "NAND simulator partition"

The fake MTD devices may further be attached to UBI (see here).

Debugging messages

Sometimes it is necessary to make UBI print about what it is doing. You may enable various UBI debugging messages using the "dynamic debug" Linux kernel infrastructure. Please, refer to the corresponding UBIFS section for more information. Below is a similar table for UBI.

Message Type	Magic string
All messages (very noisy)	'format "UBI DBG" +pf'
General messages	'format "UBI DBG gen" +pf'
EBA messages	'format "UBI DBG eba" +pf'
Wear-levelling messages	'format "UBI DBG wl" +pf'
Input/output messages	'format "UBI DBG io" +pf'
Attach messages	'format "UBI DBG bld" +pf'

Extra self-checks

UBI contains various internal self-check functions which are often very useful for debugging or testing. Please, refer to the corresponding UBIFS self-checks section for more information, because UBI extra self-checks are very similar, just a bit simpler. Here is a similar table for UBI.

Check type	File name
General checks.	`chk_gen`
I/O checks. Does things like verifying that eraseblocks contain only 0xFF bytes after erasure, verifies that all writes go to an empty flash area, verifies each writes by reading the data back and comparing to the original.	`chk_io`

Power-cut recovery testing

UBI suppors power-cut emulation for testing which emulates power-cuts after a random number of writes. When a power-cut is emulated, UBI switches to read-only mode and disallows any further write to the UBI volume, thus emulating a power cut. The main idea of this mode is to emulate power cuts in interesting places, e.g. when writing the vid header.

Use the tst_emulate_power_cut debugfs file to set flags for when to enable power-cut emulation. Possible flags for power-cut testing can be seen in the table below.

Use the files tst_emulate_power_cut_min and tst_emulate_power_cut_max to set the minimum and maximum number of successful writes, respectively, before a power-cut is emulated.

Note that UBIFS has its own power-cut emulation functions. Please, refere to the corresponding Power-cut recovery testing section.

Emulation type	Flag value
Allow power-cut to be emulated during EC header write	1
Allow power-cut to be emulated during VID header write	2

How do I send an UBI bug report?

Basically the same way as an UBIFS bug report

UBI FAQ and HOWTO

Table of contents

Debugging messages

Extra self-checks