building of factory.bin about chef HOT 10 CLOSED

The idea of creating jefe.tk was to improve the experience for regular non-power users, always providing the most casual use-case as default. I'd really like to support both, advanced and regular users, however, keep the user interface simple.

from chef.

I would go for:
if -factory.bin has been created, provide only -factory.bin image (ignore sysupgrade file);
else provide -sysupgrade.bin

from chef.

why ignore sysupgrade?

from chef.

Correct me if I'm wrong:

• factory images can be used in all the occasions where sysupgrade images can be used
• sysupgrade images can not be used in all the occasions where factory images can be used

For example:

• for flashing from original interface: factory can be used
• for flashing from TFTP: factory can be used
• for flashing from serial: factory can be used
• for flashing from LEDE/OpenWrt/LibreMesh interface: both factory and sysupgrade can be used

The only point I can see for the existence of sysupgrade images is to minimize the data transfer over the network (when downloading sysupgrade images that usually are a few MB smaller), not a real problem nowadays.

The drawback is that having two options is confusing for the user.

Anyway for some routers just a file is compiled, and in this case it's called sysupgrade, that's why a check for -factory.bin existence is needed.

from chef.

@dangowrt opinions?

from chef.

for flashing from LEDE/OpenWrt/LibreMesh interface: both factory and sysupgrade can be used

This is only true on some devices and a pure coincidence. Some vendors choose to use U-Boot's uImage format also as their firmware image format, some others don't. In the likely case of a vendor choosing to add a custom header or the like, the factory image then cannot be used for sysupgrade.
Also note that for those factory images which are accepted for sysupgrade keeping the configuration fails in most cases.

I generally agree that for the case of jefe.tk it'd be nice to have access to all resulting images rather than only the -sysupgrade.

Also be aware that the whole debate for now has been focused on NOR-flash based targets. On block-device based targets (ie. microSD, eMMC, CF, SATA, ...) the filenames are again different. And for NAND (ie. UBI) each vendor created their own mess...

from chef.

this depends on openwrt/asu#47

from chef.

for flashing from LEDE/OpenWrt/LibreMesh interface: both factory and sysupgrade can be used

This is only true on some devices and a pure coincidence. Some vendors choose to use U-Boot's uImage format also as their firmware image format, some others don't. In the likely case of a vendor choosing to add a custom header or the like, the factory image then cannot be used for sysupgrade.

Ok, I chose a bad phrasing on that line, let's say for flashing from LEDE/OpenWrt/LibreMesh interface: if sysupgrade can be used, also factory can.

Also note that for those factory images which are accepted for sysupgrade keeping the configuration fails in most cases.

Uh! I had no idea of this...
This sounds like a real issue for us, even more for attended-sysupgrade.

I generally agree that for the case of jefe.tk it'd be nice to have access to all resulting images rather than only the -sysupgrade.

Also be aware that the whole debate for now has been focused on NOR-flash based targets. On block-device based targets (ie. microSD, eMMC, CF, SATA, ...) the filenames are again different. And for NAND (ie. UBI) each vendor created their own mess...

Considering this mess, I acknowledge that there's no way to avoid presenting the whole list of useless stuff to the end user :/

from chef.

Considering this mess, I acknowledge that there's no way to avoid presenting the whole list of useless stuff to the end user :/

I think the client-side has to do some work on that. Likely most regular users use plastic router dissolving the need of distinction between ext4 and squash. The use of factory and sysupgrade should be easily understandable. (factory -> first installation, sysupgrade -> upgrading the system)

from chef.

Also on plastic routers (ie. devices with small NOR flash) people may choose between a single read-write JFFS2 filesystem and read-only squashfs + JFFS2-overlay.
Similarly, on NAND devices user may choose between a single UBIFS and squashfs + UBIFS-overlay.
On x86 (and potentially also MMC targets) between ext4 and squashfs + {f2fs OR ext4}-overlay.

from chef.