>>>>> "Christian" == Christian Lamparter <[email protected]> writes:
> I've posted a similar message to the bugreport: > <https://bugs.openwrt.org/index.php?do=details&task_id=2460> I should have filed the bug first and linked it in my patch. > What's happening here is that mksquashfs4 is being told > through the "-nopad" option to "do not pad filesystem to a > multiple of 4K" [0]. > |define Image/mkfs/squashfs | > $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call > mkfs_target_dir,$(1)) $@ \ | -nopad -noappend -root-owned \ | > -comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \ | -processors 1 |endef > My guess is that this affects more than just the MR24 (I'm > looking at you too: pad2jffs and various pad-to $value) > . I've tried tracking down the change that added the "-nopad" > and found it in a commit from 2005 titled: "add some changes > from whiterussian to head" [1] [2]: I agree that other devices where rootfs is squashfs and lives on a ubi volume are probaby also vulnerable to this problem. Regrettably, I haven't thought of any other of those devices that I have on hand to test. > | $(KDIR)/root.squashfs: | @mkdir -p $(KDIR)/root/jffs |- > $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -noappend > -root-owned -le |+ $(STAGING_DIR)/bin/mksquashfs-lzma > $(KDIR)/root $@ -nopad -noappend -root-owned -le > So, this is really old... > Question is, should we just drop the -nopad? Since as you > established, in the described corner-case (see above) > squashfs needs this 4k padding and the generated squashfs > could be considered broken otherwise? I'm under the impression that the -nopad makes sense for NOR flash where the kernel and rootfs are glued together, padding the isolated rootfs would cause alignment problems or wasted space in the combined blobs. > (Judging from your > message, you went through the kernel code. Can you please > share the place where the lack of the padding is breaking the > fs?) It's mostly inferred from the fact that I saw the error and kernel panic, and glancing at the kernel squashfs code. I am not pretending to understand completely how the squashfs kernel code works, but the position of the error relative to the size of the rootfs in my panic case strongly suggests it was trying to read past the end of the ubi volume. The error comes in the kernel's fs/squashfs/block.c in the squashfs_read_data() function. There are a bunch of conditions (at least 5) within the function (see "goto read_failure;") that will lead to that message being printed. -- Russell Senior, President [email protected] _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
