>> > the disabling is being done deliberately to give users a chance /
>> > force them to clean up the overlay after a reflash.
>> So this test is only for the `overlay' case, not the new "option
>> target /" case, right?
> No, it's for both because the option target / case still has the same
> problem, namely incorrect kernel modules and possibly broken uClibc
> binaries after a firmware flash, so in both cases the user probably
> needs to update for the system to not brick after a firmware upgrade.

I see there's indeed a problem for kernel modules (tho if you insmod all
the modules in squashfs+jffs before pivoting to the extroot, this is not
an issue), but for uclibc binaries I can't imagine how that can be
relevant in the non-overlay case.


        Stefan

_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to