In OpenWrt SNAPSHOT, r7878-d1ea8ac3b4 was support of Edimax BR-6478AC V2.
But after upgrade to latest
sysupgrade openwrt-ramips-mt7620-edimax_br-6478ac-v2-squashfs-sysupgrade.bin
Result: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Connected throught serial UART.
Restored original firmware. Debricking
Tried to upload openwrt-ramips-mt7620-edimax_br-6478ac-v2-squashfs-sysupgrade.bin throught standart WEB interface of firmware update.
Result is the same.
Does the forum search for Unable to mount root fs on unknown-block yield something useful regarding your problem?
After search, as I could understand, the problem that rootfs is absent.
But why it's absent?
After that I revert back to old snapshot, fortunately I stored version: d1ea8ac3b4
So I built it snapshot(d1ea8ac3b4)
git clone https://git.openwrt.org/openwrt/openwrt.git/
git checkout d1ea8ac3b4
....
make
Then flashed that snapshot to router via standard firmware update.
And voila system boots normally and everything works.
This is normal boot.log from old snapshot has much more partitions.
Creating 8 MTD partitions on "raspi":
0x000000000000-0x000000030000 : "Bootloader"
0x000000030000-0x000000040000 : "Config"
0x000000040000-0x000000050000 : "Factory"
0x000000050000-0x000000070000 : "Cimage"
0x000000070000-0x000000190000 : "Kernel"
0x000000190000-0x0000007e0000 : "RootFS"
0x000000070000-0x0000007e0000 : "Uimage"
0x0000007e0000-0x000000800000 : "FreeSpace"
So issue still actual, the current snapshot does not support router Edimax BR-6478AC V2, but why?
Because a bug sneaked in with d70ec3008d4cd0540a9f6c88fb7e786107f1679a. Thanks to your working boot.log, it was pretty easy to spot.
Would you please checkout the latest master, apply the following two patches (patch -p1 < 000...), build a new image and check if the issue is fixed:
As a general remark, please use the bugtracker for such issues.
Could you please explain me what was the problem?
Fixed in latest master, might take a few hours till fresh images are build by the buildbots.
OpenWrt uses only a single partition for the (concatinated) kernel + roofs. The partition is named firmware. During boot the firmware partition is split into a kernel and a rootfs partition. We are doing it this way, to eliminate the need to reserve space for a growing kernel.
To find the start of the rootfs, we need a hint how big the kernel on flash is. Usually the kernel has a header which tells us how big the kernel is. Skipping this amount of bytes and we have the start of our rootfs.
Unfortunately, a lot of vendors are using a custom header and not the well known denx,uimage one. Back in the days we used some heuristics to detect which header we have.
With the mentioned commit, we switched to define the expected header format (and the splitter to use) in the dts files. In case of the BR-6478AC v2, the wrong one was defined, and the one we should have used, doesn't had the necessary support to be defined in the dts.
Both issues are fixed with my patches.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.