[FS#462] Lede 17.01.0-rc1 - ramips/rt3883/rt-n56u bootloop

LEDE Bugs lede-bugs at lists.infradead.org
Mon Mar 27 09:29:53 PDT 2017


The following task has a new comment added:

FS#462 - Lede 17.01.0-rc1 - ramips/rt3883/rt-n56u bootloop
User who did this - Mathias Kresin (mkresin)

----------
I finally found the problem. But It needs a bit of explanation how the partition thingy is working in LEDE/OpenWrt.

The kernel, rootfs and rootfs_data partitions are created on the fly during boot. The concatenated kernel+rootfs is stored in the firmware partition.

The rt-n56u kernel has a so called uImage header at the beginning. The uImage header has size field which normally matches the size of the kernel.

During boot the firmware splitter checks for the uImage header at the beginning of the firmware partition. If the header is found, the number of bytes from the size header field are skipped. If the next bytes are a known filesystem header, the firmware partition is splitted into a kernel partition and a rootfs part.

Now the problem. The size field of the uImage header of the factory image covers not only the kernel. It is for kernel+rootfs. The "original" uImage header which covers only the kernel is appended to the end of the image. The firmware splitter kicks in during boot, finds the uImage header with the size set to kernel+rootfs, skips the kernel+rootfs and can not find a valid filesystem => error.

It most likely works with the Barrier Breaker image due to a bug in the BB firmware splitter. It seams to me the BB firmware splitter tries to find the next uImage header on the firmware partition if the first one didn't result in a usable rootfs.

The BB firmware splitter behaviour is really error prone. Since we have more than just the uImage based firmware splitter. Assuming the uImage based splitter always runs at first and searches the whole flash for uImage headers it might find a byte sequence which looks like a valid uImage but isn't. This will cause issues for images which are not using the uImage header.

Long story short: It only worked due to a bug in BB and was the wrong approach from the beginning.

I would propose to simply remove the -factory.bin image since the -sysupgrade.bin image works fine with the tftp recovery and allows to do the initial LEDE installation.

Is everybody fine with the "solution"? Would anyone of you take care of updating the OpenWrt Wiki article since OpenWrt 15.01 is affected by the same issue?
----------

More information can be found at the following URL:
https://bugs.lede-project.org/index.php?do=details&task_id=462#comment2253



More information about the lede-bugs mailing list