I'm trying to use a compressed squashfs ubi volume as my root file system. The idea is to have two ubi volumes. Volume one contains a read-only squashfs file system. Volume two is re-sizable and uses the remaining flash space. It contains a writable ubifs file system. These two ubi volumes are to be overlayed using overlayfs after booting so that I have a writable file system with the ability to restore to factory state by formatting the second (ubifs) volume.

I know squashfs works only on block devices, so I'm using gluebi driver to emulate them on top of ubi volumes (this creates mtdx and mtdblockx for each ubi volume):


Here's my ubinize.conf file to create the ubi image:


I'm using these MTD partitions for testing:

mtd18: 03a00000 00040000 "sys_back"
mtd19: 058c0000 00040000 "system"

I flashed the ubi image to mtd18 (sys_back), attached it to ubi, mounted the resulting mtdblock and everything worked as intended, so I presume my ubi volume and squashfs file system are correct.

# ubiattach -m 18
# mount /dev/mtdblock23 /mnt/
# mount
/dev/mtdblock23 on /mnt type squashfs (ro,relatime)

So, I wanted to try the final configuration. I flashed the ubi image to mtd19 (system) and modified my kernel parameters to contain this:

ubi.mtd=system root=mtd:ubi_vol_rom rootfstype=squashfs

However, mounting the root file system failed:

[    3.334908] ubi0: attaching mtd19
[    3.725841] ubi0: scanning is finished
[    3.751239] gluebi (pid 1): gluebi_resized: got update notification for unknown UBI device 0 volume 1
[    3.759465] ubi0: volume 1 ("ubi_vol_overlay") re-sized from 1 to 203 LEBs
[    3.767111] ubi0: attached mtd19 (name "system", size 88 MiB)
[    3.772007] ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes
[    3.778938] ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096
[    3.785670] ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192
[    3.792583] ubi0: good PEBs: 355, bad PEBs: 0, corrupted PEBs: 0
[    3.798604] ubi0: user volume: 2, internal volumes: 1, max. volumes count: 128
[    3.805807] ubi0: max/mean erase counter: 3/1, WL threshold: 4096, image sequence number: 1328192
[    3.814929] ubi0: available PEBs: 0, total reserved PEBs: 355, PEBs reserved for bad PEB handling: 40
[    3.823843] ubi0: background thread "ubi_bgt0d" started, PID 148
[    4.639909] UBIFS error (pid: 1): cannot open "mtd:ubi_vol_rom", error -22
List of all partitions:
[    4.647770] 1f00            2560 mtdblock0  (driver?)
[    4.652783] 1f01            2560 mtdblock1  (driver?)
[    4.657822] 1f02           22528 mtdblock2  (driver?)
[    4.662851] 1f03            5120 mtdblock3  (driver?)
[    4.667886] 1f04            3072 mtdblock4  (driver?)
[    4.672925] 1f05            1280 mtdblock5  (driver?)
[    4.677956] 1f06            1536 mtdblock6  (driver?)
[    4.682994] 1f07            1280 mtdblock7  (driver?)
[    4.688030] 1f08            9216 mtdblock8  (driver?)
[    4.693059] 1f09            9216 mtdblock9  (driver?)
[    4.698094] 1f0a            6400 mtdblock10  (driver?)
[    4.703214] 1f0b           14336 mtdblock11  (driver?)
[    4.708339] 1f0c           16896 mtdblock12  (driver?)
[    4.713458] 1f0d           61440 mtdblock13  (driver?)
[    4.718582] 1f0e            1280 mtdblock14  (driver?)
[    4.723701] 1f0f           30720 mtdblock15  (driver?)
[    4.728826] 1f10           57344 mtdblock16  (driver?)
[    4.733945] 1f11          127232 mtdblock17  (driver?)
[    4.739069] 1f12           59392 mtdblock18  (driver?)
[    4.744228] 1f13           90880 mtdblock19  (driver?)
[    4.749313] 1f14           26676 mtdblock20  (driver?)
[    4.754471] 1f15           50344 mtdblock21  (driver?)
[    4.759552] No filesystem could mount root, tried:  ubifs
[    4.764942] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    5.837944] Rebooting in 5 seconds..

So from the log I can tell that ubi attached to mtd19 as expected, resized the second partition (ubi_vol_overlay), created two mtd partitions from the ubi volumes (mtd20 and mtd21), and created two block devices on top of these (mtdblock20 and mtdblock21), great.

However, mounting the squashfs filesystem (mtdblock20) failed. The log says it tried mounting with as ubifs even though I explicitly said to use squashfs via the rootfstype argument.

At first I thought that maybe the name of the device wasn't resolving correctly in the root= parameter, so I've tried using /dev/mtdblock20 but it resulted in the same.

How can I force the kernel to mount it with squashfs instead of ubifs?

  • 1
    I am so annoyed that this is among top Google results, with no answer. I hope my reply helps. Dec 27, 2018 at 17:28
  • I've resolved the issue since, but I'll accept your answer since it's what I ended up using. Thanks.
    – PoVa
    Jan 2, 2019 at 6:58
  • @PoVa, do you mean you resolved the issue in another way than the accepted answer, and if so, how?
    – psv
    Jan 28, 2019 at 9:11
  • 1
    @petersv my particular issue was that I was dumb enough to use a wrong defconfig file and ended up without squashfs compiled in.
    – PoVa
    Jan 29, 2019 at 7:41

1 Answer 1


Squashfs needs a block device to run, thus you need the block emulation over UBI. First make sure it is enabled in your kernel.

You can test this by using the ubiblock command on a running system. For example, running ubiblock -c /dev/ubi0_0 will create the devnode /dev/ubiblock0_0.

Once you have the dependency, you can enable the UBI block on the cmdline like this:

ubi.mtd=2 ubi.block=0,ubi_vol_rom root=/dev/ubiblock0_0

This will use the UBI volume named ubi_vol_rom and create an emulated block device. Then you can use it to mount your root.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.