search

libremesh / chef

Online ImageBuilder for OpenWrt/LibreMesh
https://chef.libremesh.org/
GNU Affero General Public License v3.0
78 stars 31 forks source link

building of factory.bin #3

Closed FreifunkUFO closed 6 years ago

FreifunkUFO commented 6 years ago

at the moment there are only sysupgrade images. sometimes a factory.bin would be nice.

ilario commented 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

aparcar commented 6 years ago

why ignore sysupgrade?

ilario commented 6 years ago

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.

aparcar commented 6 years ago

@dangowrt opinions?

dangowrt commented 6 years ago

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...

aparcar commented 6 years ago

this depends on https://github.com/aparcar/gsoc17-attended-sysupgrade/issues/47

ilario commented 6 years ago

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 :/

aparcar commented 6 years ago

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)

dangowrt commented 6 years ago

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.

aparcar commented 6 years ago

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.