Online ImageBuilder and Upgrade Server

How does OpenWrt follow that?

Surely this would be no different than somebody simply distributing a custom Linux distro?

Once the imagebuilder or opkg can handle spdx license tags I'm happy to integrate this feature, as requested a long time ago

1 Like

Awsome, nice work.

As @aparcar points out, handling the spdx and similar licensing tags to collect the licenses and required files would make distribution of images a lot "cleaner" from a licensing perspective. I'd definitely welcome that! does call out

PKG_LICENSE - The license(s) the package is available under, SPDX form.
PKG_LICENSE_FILE - file containing the license text

but I don't think that anything is done with them, nor are all packages annotated.

There are some very important distinctions between "a custom Linux distro" and a "bare-bones" binary distribution. If you look at most of the desktop/server distros out there, they typically either include in the distribution or directly host the full source code for the kernel, standard utilities, and packages. These typically include the license text for each component, as well as any additional files or build instructions needed to satisfy the specific licenses (not just GPL, but all of the licenses and their own peculiarities). They include the required statements about licenses and often include those licenses and required files in their binary distributions.

As an example of an embedded OS, Android (AOSP, at least) collects all the licenses and required documents and puts them into a compressed file that is included in the image to be flashed to the device. Yes, a challenge on ROM-constrained devices, but at least a direction on how to make compliance easier. Another embedded-device approach is that silly CD in the box that we all ignore ("what am I going to do with this Asus motherboard CD when I don't even have a CD drive?") -- typically containing the required statements and licenses and occasionally the source code itself.

1 Like

Hey @jeff I think I get your point and nobody is eager to produce any CDs. As long as opkg info or opkg list-installed does not print any information regarding the license, I can't really do anything. Once this is done I hope this information is included in the .manifest file and then available for every created image.

1 Like

Hello @aparcar.

First, congratulations for your work.
I´m trying to create a build for my router, but i have a doubt.
Look at the files created:

I cannot see the factory and sysupgrade file..
Which of these files i can write into my router?


Check your buildlog for error messages, but this is almost always indicating that your image got too large - especially for 4 MB flash devices.

I'm afraid the refactoring broke the detection for "to big images". I'll try to update the server within the next hours

Hello @aparcar.

I agree with you...
Using online image builder from libremesh, i get an error when the image become too big.
It´s easy to fix this?

Another question: It´s possible to customize the squashs block size?
In other builds that other users did, it seemed that using the 1024Kb block size improved the compression level.


I have no experience with that, if you'd suggest to use that value for all LibreMesh image builder I can add a feature to change individual .config options. Please send me the related line & request comments on the LiMe mailing list.

However, making all .config options editable per requested image is a bit out of scope.

Hello @aparcar.

I don´t know how to do this too.
I have no experience with linux. My sugestion was based on builds from other users.
If somebody can help.


The problem seem to be that the snapshot ImageBuilder don't print the error message. Here is an example of a working version while sometime it just doesn't. I'll ask on the mailing list for some further help.

I'll ask the LibreMesh mailing list if this is recommended, if so I'll implement it.

The config option is TARGET_SQUASHFS_BLOCK_SIZE, and the default is 256. Increasing it will noticeably reduce the size of the image. The drawback is that three of those will be cached by default, so if you increase it to 1 MB then it will use 4 times more RAM. It can be reduced to 1 using make kernel_menuconfig, the setting is SQUASHFS_FRAGMENT_CACHE_SIZE. Setting it to 512 KB and 1 cache fragment could be a good idea on a 4/32 router, though. I don't know how much it would influence CPU usage.


Thanks for these details. I may implement a way to set custom config options per build, at least per distro/version so.

Sorry for the inconvenience, due to a badly formatted SQL join only requests containing custom defaults would be build. It should now work again. Please feel free to message me here or via mail in case of troubles, I'm happy for everyone who's testing and feedback in general!

this is a great tool and service. i've successfully built a customized image for my wrt32x.
thank you!

i ran into a problem building for ar71/ mr16: i tried to add wpad-mash and take away wpad-mini. the build failed with error wpad-mini asking for modules that wpad-mesh had alrady required. this message was generated in the build process whether i put wpad-mesh at the top or bottom oof the list, and whether or not i removed wpad-mini fmr the list. it seems wpad-mini is in the build list no matter what packages are in the package window

thanks again

1 Like

Not clear from your post, have you included the -wpad-mini in the list (notice the preceding minus sign)? Some packages, which are included by default, need to be explicitly excluded (like -dnsmasq dnsmasq-full and -wpad-mini wpad-mesh).

@stangri -
AHA! thank you. i missed the - option to remove a default package.

now, we need an 18.06.1 version selection!

1 Like

Thank you very much @aparcar , I had just created images for my nucom R5010U modems with version 18.06.0, they are working very well, only I had some problems in removing -odhcp and leaving the package odhcpd-ipv6only (the error was mine when wanting to copy the same packages of my tplink mr3220v2). Congratulations for your work.