[LEDE-DEV] [PATCH 2/2] base-files: fix config storing on generation

[Koen Vandeputte]

On 2016-09-30 17:43, Felix Fietkau wrote:
> On 2016-09-30 17:23, Koen Vandeputte wrote:
>>
>> On 2016-09-30 16:42, Felix Fietkau wrote:
>>> On 2016-09-30 16:25, Koen Vandeputte wrote:
>>>> On 2016-09-30 15:56, Felix Fietkau wrote:
>>>>> On 2016-09-30 15:10, Koen Vandeputte wrote:
>>>>>> On 2016-09-30 15:00, Felix Fietkau wrote:
>>>>>>> On 2016-09-30 14:57, Koen Vandeputte wrote:
>>>>>>>> On 2016-09-30 14:31, Felix Fietkau wrote:
>>>>>>>>> On 2016-09-30 09:48, Koen Vandeputte wrote:
>>>>>>>>>> The general "uci commit" does NOT store the generated sections.
>>>>>>>>>>
>>>>>>>>>> Fix this for now by storing each part separately.
>>>>>>>>> I'd prefer getting the real bug fixed instead of just working around it
>>>>>>>>> like this.
>>>>>>>> I totally agree, but the main intent was to have at least some temporary
>>>>>>>> solution until the real bug is fixed.
>>>>>>>> Without this temp fix, a device will regenerate the configs on each boot.
>>>>>>>>
>>>>>>>> If this consequence is OK for you, then I totally agree with rejection.
>>>>>>> I've never seen this bug in my own tests so far. What device did you
>>>>>>> reproduce it on?
>>>>>> Gateworks laguna (cns3xxx)
>>>>>>
>>>>>> When flashing a fresh image (not sysupgrade), no 'system' config file is
>>>>>> present in /etc/config
>>>>> Also when you use sysupgrade -n?
>>>> yes, same behaviour
>>>>>> So the file gets touched (empty) and the config gets generated as
>>>>>> expected (confirmed with 'uci show system')
>>>>>>
>>>>>> However,
>>>>>> - After the initial generation the 'system' file remains empty (also
>>>>>> when executing 'uci commit' manually afterwards)
>>>>>> - it only gets filled when manually executing 'uci commit system'
>>>>> I can't reproduce this on my GW2391
>>>> fyi, I'm testing on gw2388-4
>>>> Can you confirm you did this:
>>>>
>>>> - rm /etc/config/system
>>>> - reboot
>>>> ... booting ...
>>>> - cat /etc/config/system
>>>> --> content is present?
>>> Tried that, /etc/config/system gets regenerated normally. Did you try
>>> making a completely clean build? Do you have any local changes?
>> Removed some local packages and it's ok ..
>> If I find the rootcause, and it could be interesting for LEDE, ill let
>> you know.
>>
>> Thanks again for your time investigating this!
>> Consider as closed
> Could it be that one of these local packages had a config file with a
> filename that uci doesn't like? Maybe it stops at the first file with an
> invalid package name or something.
Found the rootcause ..
We have a custom package that installs a custom 'network' file in 
/etc/config (dated before I started working here ..)

config 'interface' 'loopback'
         option 'ifname' 'lo'
         option 'proto' 'static'
         option 'ipaddr' '127.0.0.1'
         option 'netmask' '255.0.0.0'

config 'interface' 'lan'
         option 'ifname' 'eth1'
         option 'type' 'bridge'
         option 'proto' 'static'

config 'interface' 'wan'
         option 'ifname' 'eth0'
         option 'type' 'bridge'
         option 'proto' 'static'

config 'switch'
         option 'name' 'eth1'
         option 'reset' '1'
         option 'enable_vlan' '1'

config 'switch_vlan'
         option 'device' 'eth1'
         option 'vlan' '1'
         option 'ports' '0 1 2 3 4'

When deleting the very last line (option 'ports' '0 1 2 3 4'), 
everything works as expected
What I dont understand is why 'UCI show' or 'UCI commit' stop 
printing/storing keys after exactly this line.

Checked following:
- ensure there is a \n behind the last line in the file
- tried removing the spaces between the values

Any idea?

Anyway .. ill cleanup the whole thing in our package .. most of this old 
stuff is probably not even needed anymore today..
> - Felix

-- 
Koen Vandeputte - Software Developer
koen.vandeputte at ncentric.com | +32499736158