Closed FreifunkUFO closed 6 years ago
I would go for:
if -factory.bin
has been created, provide only -factory.bin
image (ignore sysupgrade file);
else provide -sysupgrade.bin
why ignore sysupgrade?
Correct me if I'm wrong:
For example:
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.
@dangowrt opinions?
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...
this depends on https://github.com/aparcar/gsoc17-attended-sysupgrade/issues/47
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 :/
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)
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.
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.
at the moment there are only sysupgrade images. sometimes a factory.bin would be nice.