| Message ID | 1475221703-6414-2-git-send-email-koen.vandeputte@ncentric.com |
|---|---|
| State | Rejected |
| Headers | show |
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. - Felix
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. Koen > - Felix
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? - Felix
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 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' > - Felix >
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? > 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 - Felix
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? Here is my output when doing the steps above: [ node-3 ] cat /etc/config/system [ node-3 ] uci show system system.@system[0]=system system.@system[0].hostname='lede' system.@system[0].timezone='UTC' system.@system[0].ttylogin='0' system.@system[0].log_size='64' system.@system[0].urandom_seed='0' system.ntp=timeserver system.ntp.enabled='1' system.ntp.enable_server='0' system.ntp.server='0.lede.pool.ntp.org' '1.lede.pool.ntp.org' '2.lede.pool.ntp.org' '3.lede.pool.ntp.org' system.@led[0]=led system.@led[0].default='0' system.@led[0].name='heartbeat' system.@led[0].sysfs='user1' system.@led[0].trigger='heartbeat' [ node-3 ] uci commit [ node-3 ] cat /etc/config/system [ node-3 ] uci commit system [ node-3 ] cat /etc/config/system config system option hostname 'lede' option timezone 'UTC' option ttylogin '0' option log_size '64' option urandom_seed '0' config timeserver 'ntp' option enabled '1' option enable_server '0' list server '0.lede.pool.ntp.org' list server '1.lede.pool.ntp.org' list server '2.lede.pool.ntp.org' list server '3.lede.pool.ntp.org' config led option default '0' option name 'heartbeat' option sysfs 'user1' option trigger 'heartbeat' [ node-3 ] > - Felix >
Did a stupid test: printing the full UCI table contents: http://pastebin.com/raw/8LSLXZ7N 'system' also does not pop up here .. but when requested separately it does .. Is there a limit to the items? Koen 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? > > > > Here is my output when doing the steps above: > > [ node-3 ] cat /etc/config/system > [ node-3 ] uci show system > system.@system[0]=system > system.@system[0].hostname='lede' > system.@system[0].timezone='UTC' > system.@system[0].ttylogin='0' > system.@system[0].log_size='64' > system.@system[0].urandom_seed='0' > system.ntp=timeserver > system.ntp.enabled='1' > system.ntp.enable_server='0' > system.ntp.server='0.lede.pool.ntp.org' '1.lede.pool.ntp.org' > '2.lede.pool.ntp.org' '3.lede.pool.ntp.org' > system.@led[0]=led > system.@led[0].default='0' > system.@led[0].name='heartbeat' > system.@led[0].sysfs='user1' > system.@led[0].trigger='heartbeat' > [ node-3 ] uci commit > [ node-3 ] cat /etc/config/system > [ node-3 ] uci commit system > [ node-3 ] cat /etc/config/system > > config system > option hostname 'lede' > option timezone 'UTC' > option ttylogin '0' > option log_size '64' > option urandom_seed '0' > > config timeserver 'ntp' > option enabled '1' > option enable_server '0' > list server '0.lede.pool.ntp.org' > list server '1.lede.pool.ntp.org' > list server '2.lede.pool.ntp.org' > list server '3.lede.pool.ntp.org' > > config led > option default '0' > option name 'heartbeat' > option sysfs 'user1' > option trigger 'heartbeat' > > [ node-3 ] > > > >> - Felix >> >
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? - Felix
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 > - Felix
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. - Felix
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
Skip that last part .. Someone installed a folder inside /etc/config in the custom package (named network.d ....) argh ... During my testing below .. (copy new files to the config folder) the folder sometimes got copied along ... This closes it for me too .. On 2016-09-30 18:12, Koen Vandeputte wrote: > > > 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 >
diff --git a/package/base-files/files/bin/config_generate b/package/base-files/files/bin/config_generate index 80e5c9f..372e225 100755 --- a/package/base-files/files/bin/config_generate +++ b/package/base-files/files/bin/config_generate @@ -410,6 +410,8 @@ if [ ! -s /etc/config/network ]; then json_get_keys keys switch for key in $keys; do generate_switch $key; done + + uci commit network fi if [ ! -s /etc/config/system ]; then @@ -424,5 +426,7 @@ if [ ! -s /etc/config/system ]; then json_get_keys keys led for key in $keys; do generate_led $key; done + + uci commit system fi uci commit
The general "uci commit" does NOT store the generated sections. Fix this for now by storing each part separately. Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com> --- package/base-files/files/bin/config_generate | 4 ++++ 1 file changed, 4 insertions(+)