Hi All,
To support persistent overlay FS Should I select "jffs2" int Target images? Currently, I observe the /overlay directory is empty and is mounted as tmpFS.
Log:=============
[12.010000] mount_root: no usable overlay file system found, using tmpfs overlay
=========
What should I do to make it as persistent overlayFS on flash?
Thanks,
Have a Great Day !
Guruvenkatesh R.
overlayfs is used on top of squashfs, you should not use jffs2 or ext4 unless you really know what you're doing.
Unless the router's ToH page says differently, the default option of SquashFS should be utilized. SquashFS is a highly compressed image, whereas ext4 and jffs2 images are not.
opkg to install any afterwards.It there enough free space on the flash?
What does "df -h" say?
root@OpenWrt:/# df -T
Filesystem Type 1K-blocks Used Available Use% Mounted on
rootfs rootfs 127808 68 127740 0% /
/dev/root squashfs 6400 6400 0 100% /rom
tmpfs tmpfs 127808 64 127744 0% /tmp
tmpfs tmpfs 127808 68 127740 0% /tmp/root
overlayfs:/tmp/root overlay 127808 68 127740 0% /
tmpfs tmpfs 512 0 512 0% /dev
root@OpenWrt:/# df -h
Filesystem Size Used Available Use% Mounted on
rootfs 124.8M 68.0K 124.7M 0% /
/dev/root 6.3M 6.3M 0 100% /rom
tmpfs 124.8M 64.0K 124.8M 0% /tmp
tmpfs 124.8M 68.0K 124.7M 0% /tmp/root
overlayfs:/tmp/root 124.8M 68.0K 124.7M 0% /
tmpfs 512.0K 0 512.0K 0% /dev
root@OpenWrt:/#No. This is a new MTK router we are trying to make it OpenWRT compliant with relevant HW, driver patches. Stuck on this for a while.
What is the model # of your router?
If you have more flash memory than your image takes now, you need to be sure that the free space gets allocated for overlay. That should happen pretty automatically, but it may require some setting to get enabled. Not quite sure.
Have you defined the proper flash map in the kernel bootcmd line and/or DTS?
There should be something like this in the kernel boot log. Note how the remaining part of the allocated rootfs space (that is not taken by the actual image) get splitted into rootfs_data that is then the overlay:
[ 0.370000] 6 cmdlinepart partitions found on MTD device physmap-flash.0
[ 0.380000] Creating 6 MTD partitions on "physmap-flash.0":
[ 0.380000] 0x000000000000-0x000000030000 : "u-boot"
[ 0.390000] 0x000000030000-0x000000040000 : "u-boot-env"
[ 0.400000] 0x000000040000-0x000000050000 : "factory"
[ 0.410000] 0x000000050000-0x000000130000 : "kernel"
[ 0.420000] 0x000000130000-0x000000800000 : "rootfs"
[ 0.430000] mtd: partition "rootfs" set to be root filesystem
[ 0.440000] mtd: partition "rootfs_data" created automatically, ofs=3E0000, len=420000
[ 0.440000] 0x0000003e0000-0x000000800000 : "rootfs_data"
[ 0.450000] 0x000000050000-0x000000800000 : "firmware"
Regarding space, you only need something like 4 erase blocks, meaning some 256 kB in practice.
[ 1.430000] Creating 6 MTD partitions on "EN7512-SPI_NAND":
[ 1.430000] 0x000000000000-0x000000080000 : "u-boot"
[ 1.440000] 0x000000080000-0x0000001c5a12 : "kernel"
[ 1.440000] 0x0000001c5a12-0x000007500000 : "rootfs"
[ 1.450000] 0x000000a00000-0x000007500000 : "rootfs_data"
[ 1.450000] 0x000007500000-0x000007580000 : "art"
[ 1.460000] 0x000000080000-0x000007500000 : "firmware"
root@OpenWrt:/# cat /proc/mtd
dev: size erasesize name
mtd0: 00080000 00020000 "u-boot"
mtd1: 00145893 00020000 "kernel"
mtd2: 0733a76d 00020000 "rootfs"
mtd3: 06b00000 00020000 "rootfs_data"
mtd4: 00080000 00020000 "art"
mtd5: 07480000 00020000 "firmware"
This what I see in my board. Looks OK?
Ok, so it is NAND device?
Then it might go a bit differently. Very often there is UBIFS around the writable rootfs and rootfs_data.
E.g. in my own R7800:
[ 1.124513] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 1.128413] 10 fixed-partitions partitions found on MTD device qcom_nand.0
[ 1.135885] Creating 10 MTD partitions on "qcom_nand.0":
[ 1.142716] 0x000000000000-0x000000c80000 : "qcadata"
[ 1.153711] random: fast init done
[ 1.167047] 0x000000c80000-0x000001180000 : "APPSBL"
[ 1.175447] 0x000001180000-0x000001200000 : "APPSBLENV"
[ 1.178133] 0x000001200000-0x000001340000 : "art"
[ 1.183180] 0x000001340000-0x000001480000 : "artbak"
[ 1.187938] 0x000001480000-0x000001680000 : "kernel"
[ 1.194196] 0x000001680000-0x000003480000 : "ubi"
[ 1.243762] 0x000003480000-0x000007900000 : "netgear"
[ 1.352948] 0x000007900000-0x000008000000 : "reserve"
[ 1.365579] 0x000001480000-0x000003480000 : "firmware"
[ 1.419367] no rootfs found after FIT image in "firmware"
...
[ 15.033746] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 168
[ 15.154393] UBIFS (ubi0:1): recovery needed
[ 15.640835] UBIFS (ubi0:1): recovery completed
[ 15.640953] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data"
[ 15.644207] UBIFS (ubi0:1): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[ 15.652170] UBIFS (ubi0:1): FS size: 20062208 bytes (19 MiB, 158 LEBs), journal size 1015809 bytes (0 MiB, 8 LEBs)
[ 15.662048] UBIFS (ubi0:1): reserved for root: 947587 bytes (925 KiB)
[ 15.672306] UBIFS (ubi0:1): media format: w4/r0 (latest is w4/r0), UUID E93684FE-76A7-40E9-B44B-E54AC1858CCA, small LPT model
[ 15.679916] block: attempting to load /tmp/ubifs_cfg/upper/etc/config/fstab
[ 15.692488] block: extroot: not configured
[ 15.732520] UBIFS (ubi0:1): un-mount UBI device 0
[ 15.732562] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" stops
[ 15.759389] UBIFS (ubi0:1): background thread "ubifs_bgt0_1" started, PID 169
[ 15.890818] UBIFS (ubi0:1): UBIFS: mounted UBI device 0, volume 1, name "rootfs_data"
[ 15.890847] UBIFS (ubi0:1): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048 bytes/2048 bytes
[ 15.897701] UBIFS (ubi0:1): FS size: 20062208 bytes (19 MiB, 158 LEBs), journal size 1015809 bytes (0 MiB, 8 LEBs)
[ 15.907608] UBIFS (ubi0:1): reserved for root: 947587 bytes (925 KiB)
[ 15.917824] UBIFS (ubi0:1): media format: w4/r0 (latest is w4/r0), UUID E93684FE-76A7-40E9-B44B-E54AC1858CCA, small LPT model
Practial question:
how are you defining your disk partitions?
static struct mtd_partition tc3162_parts[] = {
{ /* First partition */
name : "u-boot", /* Bootloader section MTD0*/
size : 0x00080000, /* Size 128 + 64(Romfile) KB */
offset : 0 /* Offset from start of flash- location 0x0*/
// mask_flags : MTD_WRITEABLE /* This partition is not writable */
},
{ /* Third partition */
name : "kernel", /* Kernel section MTD1*/
size : MTDPART_SIZ_FULL, //0x000d0000,
/*
* frank modify for nand flash support
* for nand flash, romfile partition is put in the last block,
* so the kernel partition cannot append after romfile section
*/
offset : 0x80000 /* Append after bootloader section */
},
{ /* rootfs partition MTD2*/
name : "rootfs", /* Root filesystem section /rom + /overlay (MTD3) */
size : MTDPART_SIZ_FULL, /* Occupy rest of flash - art size */
offset : MTDPART_OFS_APPEND /* Append after kernel section */
},
{
name : "rootfs_data", /* rootfs_data partition MTD3*/
size : MTDPART_SIZ_FULL, /* Occupy rest of flash */
offset : 0x00030000
}
,
{
name : "art", /*art partition mtd4, 64KB*/
size : 0x00080000, /* occupy the last 1 blocks */
offset : MTDPART_OFS_APPEND
}
,
{
name : "firmware", /* firmware partition MTD5 kernel+rootfs*/
size : MTDPART_SIZ_FULL - 0x40000, /* Occupy rest of flash - art size - bootloader size */
offset : 0x00080000
}
};I haven't checked example s from similar devices, but at the first glance the rootfsdata declaration seems superfluous, and it actually contradicts the comments in rootfs where it is said to take the whole remaining space.
I think that usually rootfs is automatically split and rootfsdata created from the unused space that the image does not take, so it seems unnecessary and maybe harmful to declare rootfsdata first, especially with a fixed starting offset.
But that is just guess based on my experince,not having recently looked at similar devices.
If an admin is going to delete a post, perhaps said admin could address the issue the post is about, else I'd be inclined to simply re-post the point being made.
Code, config, and log output should be in code boxes, and if an admin doesn't understand why, they shouldn't be an admin.
Hi All,
My flash layout is shown like this,
root@OpenWrt:/# df -Th
Filesystem Type Size Used Available Use% Mounted on
rootfs rootfs 124.8M 68.0K 124.7M 0% /
/dev/root squashfs 6.3M 6.3M 0 100% /rom
tmpfs tmpfs 124.8M 36.0K 124.8M 0% /tmp
tmpfs tmpfs 124.8M 68.0K 124.7M 0% /tmp/root
overlayfs:/tmp/root overlay 124.8M 68.0K 124.7M 0% /
tmpfs tmpfs 512.0K 0 512.0K 0% /dev
As you can see, Overlay is mounted in "tmpfs". Because, /dev/mtdblock3 is not having expected JFFS2 magic number "1985". It contains some garbage number like "6873".
[ 26.550000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0x6873 instead
Hex dump of /dev/mtdblock3 is,
root@OpenWrt:/# hexdump /dev/mtdblock3 | head -n 5
0000000 6873 7173 a606 0000 07b1 c35a 0000 0400
0000010 3c00 0000 0400 1200 c006 0100 0400 0000
0000020 d81f 2c2c 0000 0000 9adb 6200 0000 0000
0000030 92db 6200 0000 0000 ffff ffff ffff ffff
0000040 2e58 6200 0000 0000 3c8c 6200 0000 0000
Block Info is,
root@OpenWrt:/# block info
/dev/mtdblock2: UUID="aae5191b-840e826c-8532deb6-24ce9fd0" VERSION="4.0" TYPE="squashfs"
/dev/mtdblock3: UUID="aae5191b-840e826c-8532deb6-24ce9fd0" VERSION="4.0" TYPE="squashfs"
We are trying so hard to understand following things, But still no luck! Any information/guidelines would be so much helpful..!
1. Why /dev/mtdblock3 doesn't have magic number ox9185 (This magic number represents JFFS2).
2. How /dev/mtdblock3 is created and How to write magic number 0x9185 to /dev/mtdblock3 ?
I have checked source file "chaos_calmer\build_dir\target-mips_mips32_uClibc-0.9.33.2\fstools-2015-09-15\mount_root.c". Function "volume_identify()" reads magic number from /dev/mtdblock3. Instead of expected magic number 0x9185, I am receiving 0x6873. So overlay got mounted in tmpfs with warning "no usable overlay filesystem found, using tmpfs overlay".
Where I should look in source to fix this magic number error of /dev/mtdblock3 ?
@hnyman Can you give some clue about this??
Thanks In Advance,
By Perumal
Please put code, config, and log output within code boxes, not quote boxes.
``` text
Usually, the rootfs_data partition is automatically created by the kernel. The subsystem responsible for that is called mtdsplit and specific to OpenWrt/LEDE. You can find the important bit of the implementation here:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/drivers/mtd/mtdsplit/mtdsplit_squashfs.c
In short, the splitter will inspect the mtd partition, read the squashfs superblock to obtain the squashfs image size, then allocate a new partition rootfs_data in the remaing space of the mtd partition containing the squashfs image. So all you need to do is to ensure that the rootfs MTD partition is larger than you rootfs squashfs image.
Hi @jow,
Thanks for prompt reply. Following is allocations done by mtd parition. I am sure the size of rootfs is larger than image size. Even I have increased rootfs size and tried.
Can you please show me where this magic number is written to /dev/mtdblock3 ?
[ 1.410000] Flash Size is 7580000, erase size is 00020000
[ 1.410000] Leftsize size is 06b00000, Left block is 00000358
[ 1.420000] rootfs_data off is 00a00000, off block is 00000050
[ 1.430000] Creating 6 MTD partitions on "EN7512-SPI_NAND":
[ 1.430000] 0x000000000000-0x000000080000 : "u-b/oot"
[ 1.440000] 0x000000080000-0x0000001c59e4 : "kernel"
[ 1.440000] 0x0000001c59e4-0x000007500000 : "rootfs"
[ 1.450000] 0x000000a00000-0x000007500000 : "rootfs_data"
[ 1.450000] 0x000007500000-0x000007580000 : "art"
[ 1.460000] 0x000000080000-0x000007500000 : "firmware"
Thanks in Advance,
Perumal
The JFFS2 mounting code expects a special marker sequence 0xdeadc0de at the beginning of the rootfs_data partition, if this byte sequence is found; the entire rootfs_data partition is erased and reformatted as JFFS2.
When building your firmware images, you should pad the squashfs image to a multiple of the erase block size, then append the magic 4 byte 0xDE 0xAD 0xC0 0xDE sequence directly after the padded squashfs.
The fstools package will then detect the deadc0de marker and begin formatting it, relevant code is here:
https://git.openwrt.org/?p=project/fstools.git;a=blob;f=libfstools/overlay.c#l250
@perumal Please utilize code boxes. not quote boxes