Why my kernel does not find the rootfs in a ubi partition?

A little background:

I'm trying to add support for a ZyXEL NSA310 (kirkwood-based NAS), but the kernel does not find the rootfs in the ubi.

The image has kernel+rootfs+rootfs_data in ubi, built with
FILESYSTEMS := squashfs
IMAGES += factory.bin
IMAGE/factory.bin := append-ubi
KERNEL_IN_UBI := 1

If I boot the initramfs (ramdisk) system image while there is a ubi image flashed to nand, it gives this error while booting

[ 1.070706] UBI: auto-attach mtd2
[ 1.073868] ubi0: attaching mtd2
[ 1.083812] UBI: EOF marker found, PEBs from 28 will be erased
[ 1.089971] ubi0: scanning is finished
[ 1.093994] ubi0 error: ubi_read_volume_table: the layout volume was not found
[ 1.101458] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd2, error -22
[ 1.108559] UBI error: cannot attach mtd2

but since ubi isn't necessary for the initramfs image, it works fine and I get to system console.

If I flash the image to nand (and set uboot for booting from ubi, with NO bootargs passed to the kernel), the kernel boots until it finds the same error above, and then it posts this

[ 1.605331] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[ 1.612865] Please append a correct "root=" boot option; here are the available partitions:
[ 1.621268] 1f00 1024 mtdblock0 (driver?)
[ 1.626346] 1f01 512 mtdblock1 (driver?)
[ 1.631439] 1f02 129024 mtdblock2 (driver?)
[ 1.636521] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

And of course auto-reboots.

I've tried with bootargs like ubi.mtd=2 but with any bootarg about root= or ubi it simply hangs and does not even start the kernel (shortly after uboot hands over to the kernel the device resets).

the ubi partition seems to be OK according to uboot. Any help appreciated. :confounded:

NSA310> ubi part ubi
ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=2", size 126 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
ubi0: good PEBs: 1008, bad PEBs: 0, corrupted PEBs: 0
ubi0: user volume: 3, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1235565284
ubi0: available PEBs: 0, total reserved PEBs: 1008, PEBs reserved for bad PEB handling: 20

NSA310> ubi info
UBI: MTD device name: "mtd=2"
UBI: MTD device size: 126 MiB
UBI: physical eraseblock size: 131072 bytes (128 KiB)
UBI: logical eraseblock size: 129024 bytes
UBI: number of good PEBs: 1008
UBI: number of bad PEBs: 0
UBI: smallest flash I/O unit: 2048
UBI: VID header offset: 512 (aligned 512)
UBI: data offset: 2048
UBI: max. allowed volumes: 128
UBI: wear-leveling threshold: 4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 3
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 1008
UBI: number of PEBs reserved for bad PEB handling: 20
UBI: max/mean erase counter: 1/0

@bobafetthotmail
As you know I'm testing you image. lm85 was not installed probably because kmod-hwmon-core was not mark.

I think that we should clean uboot varablies
root@lede:~# fw_printenv
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200

root@lede:~# fw_setenv ethaddr=50:67:F0:00:00:00
Warning: Bad CRC, using default environment

What is assumption regarding sysupgrade:

What is the proper way to do it ? Does your code support it ? Which file use ? Does it support over 6MB ?

kofec@E5420Mint ~/openwrt/LEDEnsa310 $ ls -alh bin/targets/kirkwood/generic/
total 49M
4,0K Jan 26 10:29 .
4,0K Jan 25 09:20 ..
6,1K Jan 26 10:49 config.seed
5,4K Jan 26 10:49 lede-kirkwood-device-nsa310b.manifest
 13M Jan 26 10:49 lede-kirkwood-nsa310b-initramfs-uImage
 18M Jan 26 10:49 lede-kirkwood-nsa310b-squashfs-factory.bin
 17M Jan 26 10:49 lede-kirkwood-nsa310b-squashfs-sysupgrade.tar
1,9M Jan 25 09:46 lede-kirkwood-nsa310b-uImage
 12K Jan 26 10:40 packages
 603 Jan 26 10:49 sha256sums
4,0K Jan 25 21:28 u-boot-nsa310

(issue solved in another forum thread, in another forum, here)
So I answer only questions that I didn't answer already there.

root@lede:~# fw_setenv ethaddr=50:67:F0:00:00:00
Warning: Bad CRC, using default environment

This must be done from uboot, with serial.

setenv ethaddr ethaddr=MY-MAC-ADDRESS
saveenv

So the uboot saves the envs on flash, and you can see and change them with fw_setenv

Does it support over 6MB ?

Sysupgrade supports firmware of any size that can actually fit in the device.

@bobafetthotmail ping. this seems related to my issue, however i'm not able to get the EOF marker detected, but i'm having the exact same issue

i believe the link you provide suggests a newer u-boot, which is not in the cards here. is there something i'm overlooking for why the router cannot see the eof files? i don't want to erase my nand and brick the router (i had this experience with my DIR-882 once).

EOF marker is a specific number/code written to flash that says "the UBI partition ends here"
If it is not found then the system does not detect a UBI partition in the flash partition it is looking at.
It's like saying "this partition was not formatted".

This in itself means... not much, unless you explain a bit wtf is going on on your side and what you are trying to do, nobody can really help you.

I suggest to open a new thread with a full explanation of what is going on and what is actually broken, not just "I have an error that is the same as yours".

and then summon me again there like you did here.

hey boba, i actually do have a thread: Creating a ubifs for nand + kernel cmdline arguments - #2 by broly

it seems that the EOF, while useless in most cases concerning a UBI problem, is used to determine resizing of the partition. in my case it just fails to get picked up, and i think that is why i'm getting the vtbl errors

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