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 _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
