Re: [PATCH v2] base-files: restore status of system-services after sysupgrade

[Martin Schiller]

On 2021-01-11 23:07, Sven Roederer wrote:

Restore the status of the system-services after sysupgrade.
Create a file with the status of all known services and keep it during
upgrade. After upgrade run a uci-default script to restore every
single service.


Doing the restore in an uci-default script is to late, because then you
are already in the procd rcS helper "loop" and new added init links
won't get called.

Also, have you thought about a backup/restore of the configuration?
The whole thing should/must work there as well.

I would do the restore at the end of the pre-init stage.

Martin

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH netifd] team: add simple bonding/teaming module

[Pavel Šimerda]

An initial version of a bonding/teaming module based on libteam and the
kernel team driver. It is capable of creating a team device and add
member ports. The ultimate goal is to support LAG offloaded to DSA
switch hardware with teamd handling the LACP management.

config interface teamdev
option ifname "lan1 lan2"
option type team

The module requires libteam's teamd and teamdctl commands.

Signed-off-by: Pavel Šimerda 
---
 CMakeLists.txt |   2 +-
 team.c | 178 +
 2 files changed, 179 insertions(+), 1 deletion(-)
 create mode 100644 team.c

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 9d19817..351e303 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -19,7 +19,7 @@ SET(SOURCES
main.c utils.c system.c tunnel.c handler.c
interface.c interface-ip.c interface-event.c
iprule.c proto.c proto-static.c proto-shell.c
-   config.c device.c bridge.c veth.c vlan.c alias.c
+   config.c device.c bridge.c team.c veth.c vlan.c alias.c
macvlan.c ubus.c vlandev.c wireless.c)
 
 
diff --git a/team.c b/team.c
new file mode 100644
index 000..9b67566
--- /dev/null
+++ b/team.c
@@ -0,0 +1,178 @@
+/*
+ * netifd - network interface daemon
+ * Copyright (C) 2021 Pavel Šimerda 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "netifd.h"
+#include "device.h"
+#include "interface.h"
+#include "system.h"
+
+enum {
+   TEAM_ATTR_IFNAME,
+   __TEAM_ATTR_MAX
+};
+
+static const struct blobmsg_policy team_attrs[__TEAM_ATTR_MAX] = {
+   [TEAM_ATTR_IFNAME] = { "ifname", BLOBMSG_TYPE_ARRAY },
+};
+
+static const struct uci_blob_param_info team_attr_info[__TEAM_ATTR_MAX] = {
+   [TEAM_ATTR_IFNAME] = { .type = BLOBMSG_TYPE_STRING },
+};
+
+static const struct uci_blob_param_list team_attr_list = {
+   .n_params = __TEAM_ATTR_MAX,
+   .params = team_attrs,
+   .info = team_attr_info,
+
+   .n_next = 1,
+   .next = { _attr_list },
+};
+
+struct team_device {
+   struct device dev;
+   device_state_cb set_state;
+
+   struct blob_attr *config_data;
+   struct blob_attr *ifnames;
+
+   int pid;
+};
+
+static int
+team_set_state(struct device *dev, bool up)
+{
+   struct team_device *teamdev = container_of(dev, struct team_device, 
dev);
+
+   if (up) {
+   int pid;
+   struct blob_attr *cur;
+   int rem;
+   char buffer[64];
+
+   printf("TEAM start teamd\n");
+
+   pid = fork();
+   if (pid == -1)
+   return -errno;
+   if (pid == 0)
+   execlp("teamd", "teamd", "-t", dev->ifname, NULL);
+   teamdev->pid = pid;
+   // TODO: Better handling of newly created devices.
+   sleep(1);
+   if (teamdev->ifnames) {
+   printf("TEAM port init\n");
+   blobmsg_for_each_attr(cur, teamdev->ifnames, rem) {
+   printf("TEAM one port init\n");
+   snprintf(buffer, sizeof buffer,
+   "teamdctl %s port add %s",
+   dev->ifname,
+   blobmsg_get_string(cur));
+   system(buffer);
+   }
+   }
+   teamdev->set_state(dev, up);
+   return 0;
+   } else {
+   printf("TEAM: killing %d\n", teamdev->pid);
+   if (teamdev->pid) {
+   kill(teamdev->pid, SIGTERM);
+   waitpid(teamdev->pid, NULL, 0);
+   teamdev->pid = 0;
+   }
+   return 0;
+   }
+}
+
+static enum dev_change_type
+team_reload(struct device *dev, struct blob_attr *attr)
+{
+   struct team_device *teamdev = container_of(dev, struct team_device, 
dev);
+   struct blob_attr *tb_tm[__TEAM_ATTR_MAX];
+
+   attr = blob_memdup(attr);
+
+   blobmsg_parse(team_attrs, __TEAM_ATTR_MAX, tb_tm, blob_data(attr), 
blob_len(attr));
+   teamdev->ifnames = tb_tm[TEAM_ATTR_IFNAME];
+
+   if (teamdev->pid) {
+   // TODO: More fine-grained reconfiguration
+   team_set_state(dev, false);
+   team_set_state(dev, true);
+   }
+
+   free(teamdev->config_data);
+   teamdev->config_data = attr;
+   return 

[no subject]

[Gagan Sidhu via openwrt-devel]

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
yeah, it will.

i don’t like how many files there are. 

i was looking at the 8xx-x1, 882-a1 and mt7621.dtsi. completely overlooked 
there may have also been an 882-x1.dtsi *eye roll*
-sometimes “factorisation” is a freakin’ nuisance.

this will for sure fix that problem. if only we could attach this to the 
mailing list to show how dumb i am (i have put it as a recipient).

thanks again pal

Thanks,
Gagan

> On Jan 11, 2021, at 4:45 PM, Alberto Bursi  wrote:
> 
> Yeah if you are hacking the dts for your custom build then you can just 
> copy-paste the contents of that file and it should fix the leds
> 
> -Alberto
> 
> On 12/01/21 00:40, Gagan Sidhu wrote:
>> nah this should work, thank you.
>> i am using the DTSes but not in the exact same way.
>> this is partially due to me using kernel 4.x and thus the mt7621.dtsi has 
>> slightly different properties.
>>  - wouldn’t work with 4.x mtk_eth_soc ethernet driver (esp w/  hardware nat 
>> and flow offload, no longer in driver).
>> thank you sir!
>> Thanks,
>> Gagan
>>> On Jan 11, 2021, at 4:38 PM, Alberto Bursi >> > wrote:
>>> 
>>> If you look at the commit that added support for that device:
>>> https://github.com/openwrt/openwrt/commit/28262f815e4d0fe5302babc696ed5ce518b33759
>>> 
>>> 
>>> you see that your device's dts is this file
>>> https://github.com/openwrt/openwrt/tree/master/target/linux/ramips/dts/mt7621_dlink_dir-882-r1.dts
>>> 
>>> and it is calling in two other dts files where most of the contents are.
>>> One is the one you also linked, the other is this
>>> https://github.com/openwrt/openwrt/tree/master/target/linux/ramips/dts/mt7621_dlink_dir-882-x1.dtsi
>>> 
>>> where you actually find that both USB leds are defined and have default 
>>> trigger set to "usbport".
>>> 
>>> 
>>> I don't know why it does not work in your device, maybe there is a typo 
>>> somewhere 
>>> or it is a slightly different hardware revision where the USB leds are on a 
>>> different GPIO line.
>>> 
>>> If it matters to you you can send an email to the guy that added support 
>>> for this device (his email is in the commit above), and ask him.
>>> 
>>> Just waiting works for things that are not developed by OpenWrt (the wifi 
>>> driver comes from Linux, upstream), 
>>> but is not the best way to solve OpenWrt-specific issues like wrong ports 
>>> or leds or whatever.
>>> 
>>> -Alberto
>>> 
>>> 
>>> On 11/01/21 20:17, Gagan Sidhu wrote:
 hi alberto,
 yeah i checked out the latest git and this is the relevant DTS file:
 https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7621_dlink_dir-8xx-x1.dtsi
  
 i am assuming it’s not trivial to add the usb trigger and that’s why it is 
 not done.
 it’s not a huge concern at this point anyways.
-it seems the driver still needs a bit more work on the mt7615 chipset.
 -mind you, it’s markedly improved from two years ago, but i’ve had a 
 few-too-many niggles on 5 Ghz (2.4Ghz works well) so i’m sitting pat.
 who knows, maybe it’ll be dealt with in a few months.
 Thanks,
 Gagan
> On Jan 11, 2021, at 12:14 PM, Alberto Bursi  > wrote:
> 
> 
> On 09/01/21 03:54, Gagan Sidhu via openwrt-devel wrote:
>> The sender domain has a DMARC Reject/Quarantine policy which disallows
>> sending mailing list messages using the original "From" header.
>> To mitigate this problem, the original message has been wrapped
>> hi,
> 
>> using the latest stuff from you guys, and i noticed the usb leds aren’t 
>> included in the dts.
>> is there an option i’m missing?
> 
>> currently i have:
>> CONFIG_NEW_LEDS=y
>> CONFIG_LEDS_CLASS=y
>> CONFIG_LEDS_GPIO=y
>> CONFIG_LED_TRIGGER_PHY=y
>> CONFIG_USB_LEDS_TRIGGER_USBPORT=y
>> CONFIG_LEDS_TRIGGER_GPIO=y
> 
>> enabled. what could i be missing?
> 
>> nice to see mt76 caught up to the proprietary driver.
> 
>> Thanks,
>> Gagan
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org 
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> The things you posted are kernel config, if there is no usb led defined 
> in dts file then that led will never work until you add it to the dts.
> 
> What device is this? Did you check the commit of the person that added it 
> to OpenWrt? Maybe they explain why there is no USB led.
> 
> -Alberto



Thanks,
Gagan
--- End Message ---
___
openwrt-devel mailing 

Re: [PATCH] base-files: sysupgrade: store status of system-services

[Sven Roederer]

Am Montag, 11. Januar 2021, 03:59:51 CET schrieb Alberto Bursi:
> On 10/01/21 22:40, Sven Roederer wrote:
> > Am Sonntag, 10. Januar 2021, 09:47:27 CET schrieb Andre Heider:
> >>> Same. I would personally like this as default sysupgrade procedure, as
> >>> that's what makes most sense imho.
> >>> If I have disabled a service it makes sense that after a firmware
> >>> upgrade it remains disabled.
> >> 
> >> Seconded.
> >> 
> >> Use case: Two identical routers for which I build a single image
> >> including all the packages I required. One has a workround to disable
> >> dnsmasq in rc.local, because it's always enabled after a sysupgrade and
> >> acts as a additional interfering dhcp server (I can probably configure
> >> it otherwise, but I don't require that instance at all).
> > 
> > That's quite the situation we have here with our common images. Users
> > during initial setup getting some services disabled based on their
> > choices. As the services shall remain inside the image (reconfiguration)
> > the services-state should be kept.
> > 
> > Sven
> 
> I don't understand what you are saying here. Can you explain?
> 

Alberto,

it's just the story why the current behavior annoyed me. 
Same as you wrote: a common image for multiple routers which have all relevant 
services installed.during setup our wizard disables some services, which 
should remain in this state.

Sven



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] base-files: restore status of system-services after sysupgrade

[Sven Roederer]

Restore the status of the system-services after sysupgrade.
Create a file with the status of all known services and keep it during
upgrade. After upgrade run a uci-default script to restore every
single service.
The list of the service status will be stored in etc/backup folder also
and formated as:
/etc/init.d/ {enable|disable}

When upgrading with an generic image all system services are enabled by
default which is usually not expected and can cause trouble.
The default behavior can be flipped with the "-s" option of sysupgrade.

Signed-off-by: Sven Roederer 
---

This v2 includes the feedback from the mailinglist:
* entangles this feature from "storing the packagelist"
* adds a option for disabling to sysupgrade
* makes it enabled by default
* includes the glue-script to restore the services after upgrade

I was not able to test on a real system yet.

 package/base-files/Makefile   |  2 +-
 .../uci-defaults/14_restore-services-state|  3 ++
 package/base-files/files/sbin/sysupgrade  | 38 ++-
 3 files changed, 32 insertions(+), 11 deletions(-)
 create mode 100644 
package/base-files/files/etc/uci-defaults/14_restore-services-state

diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index f18f221129..5a9bacba13 100644
--- a/package/base-files/Makefile
+++ b/package/base-files/Makefile
@@ -12,7 +12,7 @@ include $(INCLUDE_DIR)/version.mk
 include $(INCLUDE_DIR)/feeds.mk
 
 PKG_NAME:=base-files
-PKG_RELEASE:=246
+PKG_RELEASE:=247
 PKG_FLAGS:=nonshared
 
 PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
diff --git 
a/package/base-files/files/etc/uci-defaults/14_restore-services-state 
b/package/base-files/files/etc/uci-defaults/14_restore-services-state
new file mode 100644
index 00..d0085f3f80
--- /dev/null
+++ b/package/base-files/files/etc/uci-defaults/14_restore-services-state
@@ -0,0 +1,3 @@
+SERVICE_STATUS=/etc/backup/service_status.txt
+
+[ -e ${SERVICE_STATUS} ] && . ${SERVICE_STATUS}
diff --git a/package/base-files/files/sbin/sysupgrade 
b/package/base-files/files/sbin/sysupgrade
index 50f4e08e44..068ec27e3d 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -15,6 +15,7 @@ export SAVE_OVERLAY_PATH=
 export SAVE_PARTITIONS=1
 export SAVE_INSTALLED_PKGS=0
 export SKIP_UNCHANGED=1
+export SAVE_SERVICE_STATUS=1
 export CONF_IMAGE=
 export CONF_BACKUP_LIST=0
 export CONF_BACKUP=
@@ -35,6 +36,7 @@ while [ -n "$1" ]; do
-c) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/etc;;
-o) export SAVE_OVERLAY=1 SAVE_OVERLAY_PATH=/;;
-p) export SAVE_PARTITIONS=0;;
+   -s) export SAVE_SERVICE_STATUS=0;;
-k) export SAVE_INSTALLED_PKGS=1;;
-U) export SKIP_UNCHANGED=0;;
-b|--create-backup) export CONF_BACKUP="$2" NEED_IMAGE=1; 
shift;;
@@ -57,13 +59,14 @@ export CONFFILES=/tmp/sysupgrade.conffiles
 export CONF_TAR=/tmp/sysupgrade.tgz
 export ETCBACKUP_DIR=/etc/backup
 export INSTALLED_PACKAGES=${ETCBACKUP_DIR}/installed_packages.txt
+export SERVICE_STATUS=${ETCBACKUP_DIR}/service_status.txt
 
 IMAGE="$1"
 
 [ -z "$IMAGE" -a -z "$NEED_IMAGE" -a $CONF_BACKUP_LIST -eq 0 -o $HELP -gt 0 ] 
&& {
cat <...] 
-   $0 [-q] [-i] [-c] [-U] [-o] [-k]  
+   $0 [-q] [-i] [-c] [-U] [-o] [-s] [-k]  
 
 upgrade-option:
-f   restore configuration from .tar.gz (file or url)
@@ -75,6 +78,7 @@ upgrade-option:
 (this is a modification of Freifunk Berlin to unset -u)
-n   do not save configuration over reflash
-p   do not attempt to restore the partition table after flash.
+   -s   do not attempt to restore the status of the services.
-k   include in backup a list of current installed packages at
 $INSTALLED_PACKAGES
-T | --test
@@ -231,8 +235,7 @@ do_save_conffiles() {
run_hooks "$CONFFILES" $sysupgrade_init_conffiles
ask_bool 0 "Edit config file list" && vi "$CONFFILES"
 
-   if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
-   echo "${INSTALLED_PACKAGES}" >> "$CONFFILES"
+   if [ "$SAVE_INSTALLED_PKGS" -eq 1 ] || [ "$SAVE_SERVICE_STATUS" -eq 1 
]; then
mkdir -p "$ETCBACKUP_DIR"
# Avoid touching filesystem on each backup
RAMFS="$(mktemp -d -t sysupgrade.XX)"
@@ -243,13 +246,28 @@ do_save_conffiles() {
ask_bool 0 "Abort" && exit
}
 
-   # Format: pkg-name{rom,overlay,unkown}
-   # rom is used for pkgs in /rom, even if updated later
-   find /usr/lib/opkg/info -name "*.control" \( \
-   \( -exec test -f /rom/{} \; -exec echo {} rom \; \) -o \
-   \( -exec test -f /overlay/upper/{} \; -exec echo {} 
overlay \; \) -o \
-   \( -exec echo {} unknown \; 

Re:

[Alberto Bursi]

On 09/01/21 03:54, Gagan Sidhu via openwrt-devel wrote:

The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.

To mitigate this problem, the original message has been wrapped
hi,



using the latest stuff from you guys, and i noticed the usb leds aren’t 
included in the dts.
is there an option i’m missing?



currently i have:
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LED_TRIGGER_PHY=y
CONFIG_USB_LEDS_TRIGGER_USBPORT=y
CONFIG_LEDS_TRIGGER_GPIO=y



enabled. what could i be missing?



nice to see mt76 caught up to the proprietary driver.



Thanks,
Gagan


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel




The things you posted are kernel config, if there is no usb led defined 
in dts file then that led will never work until you add it to the dts.


What device is this? Did you check the commit of the person that added 
it to OpenWrt? Maybe they explain why there is no USB led.


-Alberto

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Add package version dependency for point releases

[Jo-Philipp Wich]

Hi,

why not simply wrap the workaround in a uname or /proc/version check?

~ Jo



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Add package version dependency for point releases

[Florian Eckert]

I would like to add a dependency to mwan3 on a specific kernel version.
In the master branch it does not matter, but I have a use case for this, 
especial for the stable release openwrt-19.07.
I just realized (thanks to @brianjmurrell [1]) that in a stable release, 
this is quite important.


The problem is, that a bug fix has been added to the kernel, which makes 
a workaround in mwan3 superfluous.
This workaround in the mwan3 I have now reverted. Since this is no 
longer needed.
Because of my revert now mwan3 tracking no longer works on IPv6 with 
older kernel version on openwrt-19.07, which do not have at least the 
kernel version from the 19.07.5 point release.
I was also not aware that the packages in the feeds for the point 
release are not pinned to the version that was in the repository when 
the tagging was on.

Only openwrt core is pinned.
The feeds always use the latest stable snapshot builds from 19.07 and so 
are rolling.


The fix now would be to check the version of the kernel when installing 
the package and only install or update the package if the correct 
version is installed.

But how can I do that? This is not a build dependency.

Or does anyone have another suggestion

See discussion on github [2].

Best regards

Florian

[1] https://github.com/brianjmurrell
[2] 
https://github.com/openwrt/packages/commit/6bd3f5c3777c5cbad4ac9156fa5b0fda26af14a9


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] base-files: sysupgrade: store status of system-services

[Martin Schiller]

On 2021-01-11 14:38, Stijn Segers wrote:

Hi Alberto,

Alberto Bursi  schreef op 11 januari 2021
03:56:23 CET:



On 10/01/21 22:50, Stijn Segers wrote:

Hi Sven,

Op zondag 10 januari 2021 om 22u28 schreef Sven Roederer
:

Am Samstag, 9. Januar 2021, 12:28:31 CET schrieb Stijn Segers:

 > @@ -228,6 +229,7 @@ do_save_conffiles() {
 >
 > if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
 > echo "${INSTALLED_PACKAGES}" >> "$CONFFILES"
 > +   echo "${SERVICE_STATUS}" >> "$CONFFILES"
 > mkdir -p "$ETCBACKUP_DIR"

 Am I reading this correctly and is this only keeping track of 
service
 status if you tell sysupgrade to save packages? What's the 
rationale

 behind that?

 I have a personal build with all packages preinstalled, so I don't 
need
 that. Would like to keep track of service status though. Can those 
two

 things be entangled?



Stijn,

my intention was to not change the current behavior by default, so 
an

extra
switch or extending an existing switch looked like the way. I've
choosen the
lazy one, based on "when the user is storing the packages-list, he 
is

for sure
interested in the services".
But I'm happy to add a separate switch to sysupgrade. Any preference
of the
letter? What about using "-s"?

Sven


Yes, that's still free and the most intuitive I think.

Thanks!

Stijn



Since we (me, Andre Heider and Paul Spooren) are discussing/asking 
about

enabling this by default, do you have any opinion on that?

-Alberto


That would be great, as Adrian pointed out it's something you'd expect
would be saved when you tell sysupgrade to keep settings.

So +1 from me on making it default. All my AP/testing devices now have
scripting to disable e.g. DHCP and DNS again after an upgrade.

Stijn


I am also in favor of saving the service status by default.
This is the expected behavior as long as you don't use the '-n' switch.

Currently we use our own patchset for this, but I would prefer to get
an upstream solution.

Martin

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] base-files: sysupgrade: store status of system-services

[Stijn Segers]

Hi Alberto,

Alberto Bursi  schreef op 11 januari 2021 03:56:23 
CET:
>
>
>On 10/01/21 22:50, Stijn Segers wrote:
>> Hi Sven,
>> 
>> Op zondag 10 januari 2021 om 22u28 schreef Sven Roederer 
>> :
>>> Am Samstag, 9. Januar 2021, 12:28:31 CET schrieb Stijn Segers:
  > @@ -228,6 +229,7 @@ do_save_conffiles() {
  >
  > if [ "$SAVE_INSTALLED_PKGS" -eq 1 ]; then
  > echo "${INSTALLED_PACKAGES}" >> "$CONFFILES"
  > +   echo "${SERVICE_STATUS}" >> "$CONFFILES"
  > mkdir -p "$ETCBACKUP_DIR"

  Am I reading this correctly and is this only keeping track of service
  status if you tell sysupgrade to save packages? What's the rationale
  behind that?

  I have a personal build with all packages preinstalled, so I don't need
  that. Would like to keep track of service status though. Can those two
  things be entangled?

>>>
>>> Stijn,
>>>
>>> my intention was to not change the current behavior by default, so an 
>>> extra
>>> switch or extending an existing switch looked like the way. I've 
>>> choosen the
>>> lazy one, based on "when the user is storing the packages-list, he is 
>>> for sure
>>> interested in the services".
>>> But I'm happy to add a separate switch to sysupgrade. Any preference 
>>> of the
>>> letter? What about using "-s"?
>>>
>>> Sven
>> 
>> Yes, that's still free and the most intuitive I think.
>> 
>> Thanks!
>> 
>> Stijn
>> 
>
>Since we (me, Andre Heider and Paul Spooren) are discussing/asking about 
>enabling this by default, do you have any opinion on that?
>
>-Alberto

That would be great, as Adrian pointed out it's something you'd expect would be 
saved when you tell sysupgrade to keep settings.

So +1 from me on making it default. All my AP/testing devices now have 
scripting to disable e.g. DHCP and DNS again after an upgrade.

Stijn
>
>___
>openwrt-devel mailing list
>openwrt-devel@lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel

-- 
Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] base-files: sysupgrade: store status of system-services

[Eneas U de Queiroz]

+1
I agree 100% with Adrian on this one.  Enable by default, add option
to disable.  Disabled services are, intuitively, part of the
configuration being saved.  So, it should not be saved when '-n' is
given.  I may be stretching things a bit, but I would consider this a
fix, not a feature change ;-).

Cheers,

Eneas

On Mon, Jan 11, 2021 at 9:48 AM Adrian Schmutzler
 wrote:
>
> > There are just 2 people (me, Andrew Heider) that would like to see saving
> > service status done by default when sysupgrading, and other 2 people that
> > would like it in its own setting option (Stjin Segers and Paul Spooren).
>
> +1 for saving service status by default. This has always annoyed me when 
> working with "default" images and actually for me it was expected behavior 
> until I found out it is not happening.
> This is a very relevant behavior/feature affecting many of our "standard" 
> users, e.g. when using OpenWrt for "Dump AP" setups where you disable DHCP 
> etc. I'm sure a two-digit percentage of users setting up their device like 
> that won't even be aware that they suddenly have a DHCP running again after 
> upgrade.
>
> Of course, if adding an option to _disable_ is fairly easy, we should do so.
>
> Best
>
> Adrian
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

RE: [PATCH] base-files: sysupgrade: store status of system-services

[Adrian Schmutzler]

> There are just 2 people (me, Andrew Heider) that would like to see saving
> service status done by default when sysupgrading, and other 2 people that
> would like it in its own setting option (Stjin Segers and Paul Spooren).

+1 for saving service status by default. This has always annoyed me when 
working with "default" images and actually for me it was expected behavior 
until I found out it is not happening.
This is a very relevant behavior/feature affecting many of our "standard" 
users, e.g. when using OpenWrt for "Dump AP" setups where you disable DHCP etc. 
I'm sure a two-digit percentage of users setting up their device like that 
won't even be aware that they suddenly have a DHCP running again after upgrade.

Of course, if adding an option to _disable_ is fairly easy, we should do so.

Best

Adrian 


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel