Is /dev/ubi0_1 '/overlay' or '/rom/overlay'?

Hi all,

I have 2 identical routers (ZyXEL-P2812HNU-F1) with both the same -own build- v22.03.2
They both work as desired.

root@OpenWrt:~# cat /etc/openwrt_release
DISTRIB_ID='TorRouter'
DISTRIB_RELEASE='22.03.2'
DISTRIB_REVISION='r19803-9a599fee93'
DISTRIB_TARGET='lantiq/xrx200'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='TorRouter 22.03.2 r19803-9a599fee93'
DISTRIB_TAINTS='no-all'

I discovered a weird situation, although I think I know why.

1 of the 2 routers show a u(n)mount button in Luci's mount-GUI for '/rom/overlay' ?

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                19.8M     19.8M         0 100% /rom
tmpfs                    59.1M     10.0M     49.1M  17% /tmp
/dev/ubi0_1              92.1M    300.0K     87.2M   0% /rom/overlay
overlayfs:/overlay       92.1M    300.0K     87.2M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev
root@OpenWrt:~# mount
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/ubi0_1 on /rom/overlay type ubifs (rw,noatime,assert=read-only,ubi=0,vol=1)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
mountd(pid2019) on /tmp/run/blockd type autofs (rw,relatime,fd=7,pgrp=2019,timeout=30,minproto=5,maxproto=5,indirect)

On the other router it is labeled '/overlay' and does not have the u(n)mount button.

root@TorRouter-TEST:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                19.8M     19.8M         0 100% /rom
tmpfs                    59.1M     10.7M     48.4M  18% /tmp
/dev/ubi0_1              92.1M    292.0K     87.2M   0% /overlay
overlayfs:/overlay       92.1M    292.0K     87.2M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev
root@TorRouter-TEST:~# mount
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/ubi0_1 on /overlay type ubifs (rw,noatime,assert=read-only,ubi=0,vol=1)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
mountd(pid1987) on /tmp/run/blockd type autofs (rw,relatime,fd=7,pgrp=1987,timeout=30,minproto=5,maxproto=5,indirect)

I found only a difference on serial boot, different initramfs-kernel.bin files.
As my own build initramfs did not work, I used the 'default' openwrt_orig-21.02.0-lantiq-xrx200-zyxel_p-2812hnu-f1-initramfs-kernel.bin
This newest initramfs-kernel.bin file (the one with the u(n)mount button), shows on serial logs:

U-Boot 2013.10-openwrt5 (Jul 06 2021 - 10:04:01) P-2812HNU-Fx

The router without the u(n)mount button is an older initramfs version, same as in the logs on https://openwrt.org/toh/zyxel/p-2812hnu-f1:

U-Boot 2013.10-openwrt5 (Nov 18 2014 - 19:54:01) P-2812HNU-Fx

My main question is: Which version is the correct or best one?
What are the differences between these 2 initramfs files?

Testing with usb devices /dev/ubi0_1 will disappear if an usb device is removed.
With the same result as pressing the u(n)mount button in GUI.

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                19.8M     19.8M         0 100% /rom
tmpfs                    59.1M     10.3M     48.9M  17% /tmp
overlayfs:/overlay       92.1M    300.0K     87.2M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev
root@OpenWrt:~# mount
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
mountd(pid2019) on /tmp/run/blockd type autofs (rw,relatime,fd=7,pgrp=2019,timeout=30,minproto=5,maxproto=5,indirect)

logread and syslog only show removal of usb device, noting when /dev/ubi0_1 is removed?
The router keeps working without /dev/ubi0_1. (it is a copy of overlayfs:/overlay)
After a reboot /dev/ubi0_1 is restored again.

DG.

It even gets weirder, /rom (/dev/root) is now missing but still working as desired.


This happened after mounting an usb device and remove it within GUI.

And not only on GUI, also on CLI:

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
tmpfs                    59.1M     10.9M     48.3M  18% /tmp
overlayfs:/overlay       92.1M    300.0K     87.2M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev

And the mount returns:

root@OpenWrt:~# mount
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,noexec,noatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,noatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
mountd(pid2018) on /tmp/run/blockd type autofs (rw,relatime,fd=7,pgrp=2018,timeout=30,minproto=5,maxproto=5,indirect)

DG.

This is about the bootloader, and has nothing to do with the initramfs version you used to install OpenWrt. The bootloaders are basically the same, but the one dated Jul 06 2021 is hexedited to reserve 16MiB ram to extract the uImage to. Your own build initramfs doesn't boot because it extracts to >8MiB.
As far as I know this cannot have impact on your problem. The kernel (+optional initramfs) boots or not. When the kernel boots u-boot role is over.

Thx Mijzelf,

But I do see differences in behavior with 2 identical P2812 (1.2) with the same OpenWrt image.
Like I wrote above, 1 has an u(n)mount button for /dev/ubi0_1 the other does not, idk why.
/dev/ubi0_1 should not have an u(n)mount button, i presume.

And when playing around with USB storage even /rom is removed?

I think I'll try both again with firstboot.

Mijzelf, should I use the 16M tpl file or the older (8MB) one?

DG.

The kernel of stock 22.03.2 sysupgrade is meanwhile bigger than 8MiB:

binwalk -e kernel 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0xF1EEEBD6, created: 2022-10-14 22:44:41, image size: 2698291 bytes, Data Address: 0x80002000, Entry Point: 0x80002000, data CRC: 0x9DD186C9, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "MIPS OpenWrt Linux-5.10.146"
64            0x40            LZMA compressed data, properties: 0x6D, dictionary size: 8388608 bytes, uncompressed size: 9092030 bytes

So the older 8MiB bootloader cannot boot that anymore. I'm a bit surprised you can boot a custom build 22.03.2 kernel with it. A whole megabyte is a lot to slim down.

Mijzelf,

I just discovered that both run the same (16MB) u-boot environment.
But then the question why both have different /dev/ubi0_1 definitions, if they run exactly the same OpenWrt images. Even one has a unmount button ?
This gets weirder every day.

On both the /dev/root and /dev/ubi0_1 disappear if an usb was mounted and removed within the GUI.
But they is still working as desired.

DG.

Why are /dev/root and /dev/ubi0_1 removed after deleting a -not mounted- usb device and Save&Apply? (only uci del fstab.cfg024d78 is shown to be executed)
image

Afterwards it shows:
image

Where are /dev/root and /dev/ubi0_1 going?

DG.

Have you looked at the nand detection in the kernel logs?

I think both can be unmounted as the overlayfs keeps a lock on both. (When that is the correct terminology here).

Mijzelf,

Thx for the reply, and indeed the router(s) keeps working without those.
But ... 2 identical machines (even uboot is the same), both after firstboot have different mount points for /dev/ubi0_1? (/overlay and /rom/overlay)
1 Does have a unmount button in GUI the other not, I can't figure out why.

On both routers /dev/root and /dev/ubi0_1 disappear after usb deletion on GUI.

DG.

Where do you see those mounts? I think that an unmount button is shown when the mountpoint is not in the root. But I can't find your GUI list, and so can't test that.
Of course it doesn't explain why you have two different mountpoints.

Mijzelf,

The mount points are in the pictures in this topic (2nd column) and on CLI output (command: df -h).
If I flash latest firmware over current, I get
/dev/ubi0_1 92.1M 292.0K 87.2M 0% /overlay
As it suppose to be.

On the other router it's now
/dev/ubi0_1 92.1M 296.0K 87.2M 0% /rom/overlay
Don't know how this happened. Testing now...

The buttons on top of mount GUI (System / Mount Points) are doing this: Generate Config & Mount attached devices.


Idk why yet, but as these can also be unmounted it is no big issue. Only weird :slight_smile: .

DG.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.