lime-example disappeared from lime-system

[G10h4ck]

After this commit 3e3c0f82feeabc82244cc210653d711222af66e9 the /etc/config/lime-example file is not present anymore in lime-system.

This file is the only documentation available to the user in case of internet loss, moreover it is very similar to lime-default so i believe that in the squashfs compression it ends up requiring almost no space even in 4MB images.

The decision to have this file included was taken a bunch of assemblies ago under @ilario suggestion, now unless there are proof that the image size is significantly reduced by 3e3c0f82feeabc82244cc210653d711222af66e9 i vouch to revert it.

@p4u do you have clues on how much bytes the final squashfs image is reduced by this commit?

[p4u]

On 18/05/17 11:14, Gioacchino wrote:

After this commit 3e3c0f82feeabc82244cc210653d711222af66e9 the /etc/config/lime-example file is not present anymore in lime-system.

This file is the only documentation available to the user in case of internet loss, moreover it is very similar to lime-default so i believe that in the squashfs compression it ends up requiring almost no space even in 4MB images.

To complete your summary: the file is still available on 8MB targets, but now it is part of the package lime-debug.

The decision to have this file included was taken a bunch of assemblies ago under @ilario suggestion, now unless there are proof that the image size is significantly reduced by 3e3c0f82feeabc82244cc210653d711222af66e9 i vouch to revert it.

@p4u do you have clues on how much bytes the final squashfs image is reduced by this commit?

I don't know how compressed is it, however in the squashFS of a libremesh node, 'ls -s' says 7kB (on a non-compressed FS it is 12kB). In the lime-mini images (4MB) the free space is around 70-80 kB, so we are talking about almost 10% of the free space. I think it's worth, at least until we find the way to get rid of some kB more.

In addition (this is another discussion) I don't think /etc/config is a good place for adding this example file, since UCI processes it. So I would move it somewhere else also if it is part of lime-debug.

-- ./p4u

[ilario]

I think that some documentation is needed in the firmware. lime-example is a bare minimum and 7 kB are worth for sure. If the problem is the location we can move it and point out the new location in the banner. For example we could expand the /etc/config/lime-example file into a /README-LibreMesh documentation file or move it into a /lime-docs/ folder.

[p4u]

On 18/05/17 17:31, Ilario Gelmetti wrote:

I think that some documentation is needed in the firmware. lime-example is a bare minimum and 7 kB are worth for sure. If the problem is the location we can move it and point out the new location in the banner. For example we could expand the /etc/config/lime-example file into a /README-LibreMesh documentation file or move it into a /lime-docs/ folder.

lime-example is still in the firmware, but now is in the lime-debug packet (instead of lime-system), so those firmware images which include lime-debug will have lime-example.

For the libremesh mini target (<4MB), 7kB is almost 10% of the current free space. You might think it is a really small amount of space, but it is not in the current situation.

In one of my 4MB testing device, after installing lime 17.04, modify some configurations and some lua source code (for testing) the node end up without free space, so new configurations could not be saved. In addition the current LEDE setup does not allow to use all remaining free space, there is a kind of threshold (around 60-50kB) that overlayFS or JFFS2 (I don't know) do not let pass.

lime-example might be obtained and consulted from Internet, so it is still valid in most of the cases as documentation from the end user.

-- ./p4u

[G10h4ck]

Has we discussed in other context the size displayed by +ls+ is not the size really occupied on the disk as squashfs is compressed, to double check this you can do a byte count with +wc+ and you can see it is coherent to what +ls+ reports

$ wc -c lime-packages/packages/lime-system/files/etc/config/lime-example 8228 lime-packages/packages/lime-system/files/etc/config/lime-example

Moreover thinking to what you written:

I don't know how compressed is it, however in the squashFS of a libremesh node, 'ls -s' says 7kB (on a non-compressed FS it is 12kB).

About those extra ~kB~ you see on your computer it's because you are using the wrong command +ls -s+ displays the size in blocks not in bytes.

$ ls -alh lime-packages/packages/lime-system/files/etc/config/lime-example -rw-r--r-- 1 gio gio 8.1K May 18 11:37 lime-packages/packages/lime-system/files/etc/config/lime-example

[ilario]

I'm going to compile an image with and another without lime-example and I'll report the difference in dimension of the sysupgrade image.

[p4u]

Has we discussed in other context the size displayed by +ls+ is not the size really occupied on the disk as squashfs is compressed, to double check this you can do a byte count with +wc+ and you can see it is coherent to what +ls+ reports

$ wc -c lime-packages/packages/lime-system/files/etc/config/lime-example 8228 lime-packages/packages/lime-system/files/etc/config/lime-example

This is why I said "I don't know how compressed is it". Because I don't know a direct way to get the real compression size of squashFS file.

About those extra kB you see on your computer it's because you are using the wrong command +ls -s+ displays the size in blocks not in bytes.

You are right, I did not have this into account. However the default block size for the ls binary of my local computer is 1,048,576 bytes (source: man ls) which I would expect to be the same on another computer. However it looks like it is different (no idea which block size is using the busybox/ls binary of LEDE).

In any case, right know, even if the saved size is something like 5 kB I would prefer to not include it in lime-system. I've been dealing a lot trying to save space and right know, for the coming release, I don't see another way to reduce space (it needs more efforts).

[ilario]

I cloned two lime-sdk, changed the feeds, one with 3e3c0f8 and the other without, here you have the results.

Cooking with 3e3c0f8 (without lime-example):

igelmetti@PC:~/lime-sdk-withexample/output/ar71xx/generic/ubnt-bullet-m/lime_mini$ cat ../../../../../feeds.conf.default
src-git base https://github.com/lede-project/source.git;v17.01.1
src-git packages https://git.lede-project.org/feed/packages.git;lede-17.01
src-git luci https://git.lede-project.org/project/luci.git;lede-17.01
src-git routing https://git.lede-project.org/feed/routing.git;master
src-git telephony https://git.lede-project.org/feed/telephony.git;lede-17.01
src-git libremesh https://github.com/ilario/lime-packages.git;develop-revert_mv_lime-example
src-git libremap https://github.com/libremap/libremap-agent-openwrt.git;master
src-git limeui https://github.com/libremesh/lime-ui-ng.git;master

igelmetti@PC:~/lime-sdk-withexample/output/ar71xx/generic/ubnt-bullet-m/lime_mini$ ls extracted/squashfs-root/etc/config/
alfred      bmx6  dropbear  lime-defaults  luci       rpcd      uhttpd
batman-adv  dhcp  lime      lime-example   luci-bmx6  ucitrack

igelmetti@PC:~/lime-sdk-withexample/output/ar71xx/generic/ubnt-bullet-m/lime_mini$ ls -l
total 24376
drwxrwxrwx 2 igelmetti igelmetti       0 may 26 12:08 extracted
-rw-rw-rw- 1 igelmetti igelmetti    3599 may 26 09:38 lede-17.01.1-libremesh-ar71xx-generic-device-ubnt-bullet-m.manifest
-rw-rw-rw- 1 igelmetti igelmetti 2752512 may 26 09:38 lede-17.01.1-libremesh-ar71xx-generic-root.squashfs
-rw-rw-rw- 1 igelmetti igelmetti 3801500 may 26 09:38 lede-17.01.1-libremesh-ar71xx-generic-ubnt-bullet-m-squashfs-factory.bin
-rw-rw-rw- 1 igelmetti igelmetti 3801092 may 26 09:38 lede-17.01.1-libremesh-ar71xx-generic-ubnt-bullet-m-squashfs-sysupgrade.bin
-rw-rw-rw- 1 igelmetti igelmetti 1256766 may 26 09:38 lede-17.01.1-libremesh-ar71xx-generic-uImage-lzma.bin
-rwxr-xr-x 1 igelmetti igelmetti 4018260 may 26 09:38 lede-17.01.1-libremesh-ar71xx-generic-vmlinux.bin
-rwxr-xr-x 1 igelmetti igelmetti 4023384 may 26 09:38 lede-17.01.1-libremesh-ar71xx-generic-vmlinux.elf
-rw-rw-rw- 1 igelmetti igelmetti 1310720 may 26 09:38 lede-17.01.1-libremesh-ar71xx-generic-vmlinux.lzma
-rwxr-xr-x 1 igelmetti igelmetti 1328764 may 26 09:38 lede-17.01.1-libremesh-ar71xx-generic-vmlinux-lzma.elf
-rw-rw-rw- 1 igelmetti igelmetti    1123 may 26 09:38 sha256sums

igelmetti@PC:~/lime-sdk-withexample/output/ar71xx/generic/ubnt-bullet-m/lime_mini/extracted$ unsquashfs -s 140000.squashfs
Found a valid SQUASHFS 4:0 superblock on 140000.squashfs.
Creation or last append time Fri May 26 09:38:07 2017
Filesystem size 2388.32 Kbytes (2.33 Mbytes)
Compression xz
xz: error reading stored compressor options from filesystem!
Block size 262144
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always_use_fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 23
Number of inodes 1321
Number of ids 1

Cooking without 3e3c0f8 (with lime-example):

root@PC:/home/igelmetti/lime-sdk-noexample/output/ar71xx/generic/ubnt-bullet-m/lime_mini# cat ../../../../../feeds.conf.default
src-git base https://github.com/lede-project/source.git;v17.01.1
src-git packages https://git.lede-project.org/feed/packages.git;lede-17.01
src-git luci https://git.lede-project.org/project/luci.git;lede-17.01
src-git routing https://git.lede-project.org/feed/routing.git;master
src-git telephony https://git.lede-project.org/feed/telephony.git;lede-17.01
src-git libremesh https://github.com/ilario/lime-packages.git;develop
src-git libremap https://github.com/libremap/libremap-agent-openwrt.git;master
src-git limeui https://github.com/libremesh/lime-ui-ng.git;master

root@PC:/home/igelmetti/lime-sdk-noexample/output/ar71xx/generic/ubnt-bullet-m/lime_mini# ls extracted/squashfs-root/etc/config/
alfred  batman-adv  bmx6  dhcp  dropbear  lime  lime-defaults  luci  luci-bmx6  rpcd  ucitrack  uhttpd

root@PC:/home/igelmetti/lime-sdk-noexample/output/ar71xx/generic/ubnt-bullet-m/lime_mini# ls -l
total 23776
drwxr-xr-x 2 root root       0 may 26 10:12 extracted
-rw-r--r-- 1 root root    3599 may 26 09:37 lede-17.01.1-libremesh-ar71xx-generic-device-ubnt-bullet-m.manifest
-rw-r--r-- 1 root root 2752512 may 26 09:37 lede-17.01.1-libremesh-ar71xx-generic-root.squashfs
-rw-r--r-- 1 root root 3801500 may 26 09:37 lede-17.01.1-libremesh-ar71xx-generic-ubnt-bullet-m-squashfs-factory.bin
-rw-r--r-- 1 root root 3801092 may 26 09:37 lede-17.01.1-libremesh-ar71xx-generic-ubnt-bullet-m-squashfs-sysupgrade.bin
-rw-r--r-- 1 root root 1256766 may 26 09:37 lede-17.01.1-libremesh-ar71xx-generic-uImage-lzma.bin
-rwxr-xr-x 1 root root 4018260 may 26 09:37 lede-17.01.1-libremesh-ar71xx-generic-vmlinux.bin
-rwxr-xr-x 1 root root 4023384 may 26 09:37 lede-17.01.1-libremesh-ar71xx-generic-vmlinux.elf
-rw-r--r-- 1 root root 1310720 may 26 09:37 lede-17.01.1-libremesh-ar71xx-generic-vmlinux.lzma
-rwxr-xr-x 1 root root 1328764 may 26 09:37 lede-17.01.1-libremesh-ar71xx-generic-vmlinux-lzma.elf
-rw-r--r-- 1 root root    1123 may 26 09:37 sha256sums

root@PC:/home/igelmetti/lime-sdk-noexample/output/ar71xx/generic/ubnt-bullet-m/lime_mini/extracted# unsquashfs -s 140000.squashfs
Found a valid SQUASHFS 4:0 superblock on 140000.squashfs.
Creation or last append time Fri May 26 09:37:23 2017
Filesystem size 2385.62 Kbytes (2.33 Mbytes)
Compression xz
xz: error reading stored compressor options from filesystem!
Block size 262144
Filesystem is exportable via NFS
Inodes are compressed
Data is compressed
Fragments are compressed
Always_use_fragments option is not specified
Xattrs are not stored
Duplicates are removed
Number of fragments 23
Number of inodes 1320
Number of ids 1

As you can see, all the files have exactly the same size, but after unpacking with binwalk -e I can see using unsquashfs -s that there's a 2.7 kB difference in "Filesystem size" parameter. Is it enough information or should I flash both of them and check free space?

If the difference is just of 2.7 kB, in my opinion is worth to have documentation in mini, zero, light, micro, femto, pico, nano, atto, zepto, yocto, diet firmware versions.

[G10h4ck]

As you can see, all the files have exactly the same size, but after unpacking with binwalk -e I can see using unsquashfs -s that there's a 2.7 kB difference in "Filesystem size" parameter. Is it enough information or should I flash both of them and check free space?

It seems ok for me but if you have a device it is better to flash and see

If the difference is just of 2.7 kB, in my opinion is worth to have documentation in mini, zero, light, micro, femto, pico, nano, atto, zepto, yocto, diet firmware versions.

I agree, I believe it is more approriated to unify the the development documentation stripping in the code, so it get applied to all lua files, instead of removing this file.

[p4u]

Ok, so revert the commit if you wish.

I agree, I believe it is more approriated to unify the the development documentation stripping in the code, so it get applied to all lua files, instead of removing this file.

Would be nice to do it then as soon as possible, before publishing the first RC (end of May). Can you take care of it? Shall we open a new issue regarding this?

[ilario]

For further reducing the dimension of the image have you considered the work by @FreifunkUFO here?

[p4u]

I don't think more packages can be removed. Remove WAN packages is not a good approach (IMO) for official firmware images. Since many networks use a basic/zero profile router also to share the Internet access. One of the key points of libremesh is 'one firmware for all kind of setups', so having a flavor without WAN would break this rule.

The real solution would be to be able to modify the Kernel, so many stuff not used might be removed. But since we are using LEDE-SDK to generate firmware and to be compatible with upstream, we cannot do so.

So let's try to strip some code and save from space from there as @G10h4ck proposed.

[ilario]

139 addresses this issue reverting 3e3c0f8

140 addresses this issue adding a new location for documentation through two specific packages

[ilario]

Merging #140 fixed this.