Re: [PATCH 1/3] generic: platform/mikrotik: make soft_config writable without 4K sectors
Am Dienstag, 21. Dezember 2021, 08:45:59 CET schrieb Oskari Lemmela: > Make soft_config writable in all cases. Performing soft_config commit > will fail if mtd partition is not writable. > > Signed-off-by: Oskari Lemmela > --- > .../drivers/platform/mikrotik/rb_softconfig.c | 17 +++-- > 1 file changed, 3 insertions(+), 14 deletions(-) > > diff --git > a/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c > b/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c > index 070bd32d5a..31d06c423a 100644 > --- a/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c > +++ b/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c > @@ -59,20 +59,9 @@ > #define RB_SOFTCONFIG_VER "0.03" > #define RB_SC_PR_PFX "[rb_softconfig] " Oskari, maybe also good to bump version to 0.04 . Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: zram-swap: default to lzo instead of lzo-rle compression
Am Mittwoch, 1. Dezember 2021, 14:08:15 CET schrieb Rui Salvaterra: > Hi, Felix, > > On Wed, 1 Dec 2021 at 12:45, Felix Fietkau wrote: > > Maybe upstream would accept a simple makefile change that merges both > > into a single module without changing any of the source files. > > That's the most logical course of action, yes. Otherwise, this patch > [1] I sent last year seems the next best idea. > > Thanks, > Rui > As mentioned in my other mail, forcfully combining both compressors will result in an additional kernel-module, that gets loaded. In my case that will be counterproductive, as I already include "lzo" for other purpose and having to include "lzo-rle" too results in unwanted "memory bloat". That's why I think the kernel should not insist on a specific compressor by default. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: make zram honor available compressors when selecting the initial algo
Am Mittwoch, 1. Dezember 2021, 12:47:57 CET schrieb Rui Salvaterra: > Hi, Sven, > > [patch snipped] > > Why not just include the lzo-lre module in the lzo module package? We > already agreed they're basically inseparable. In fact, I remember I > had sent a patch [1] a while ago, in order to do just that. > Rui, I'm trying to make a as small as possible kernel (to safe RAM / flash). As I'm already using the lzo-module I like to avoid to include both and keep the choice to select any combination of them. Both modules only share some "lower end" code, beside that they are completely independent. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: zram-swap: default to lzo instead of lzo-rle compression
Am Montag, 29. November 2021, 10:57:37 CET schrieb Rui Salvaterra: > Hi, Sven, > > On Sun, 28 Nov 2021 at 01:40, Sven Roederer wrote: > > Rui, not sure if to call it a bug. At the end there is a hardcoded default > > algo in the module, that is used initially when creating the device. The > > check for the valid algo is done later at device-activation. > > I spend some time in this code and have a patch ready, which checks for > > algos before announcing them. > > It's not a bug, but it's also not exactly an unsurprising behaviour. > This is the real issue: > > https://elixir.bootlin.com/linux/v5.10.82/source/crypto/Makefile#L153 > > obj-$(CONFIG_CRYPTO_LZO) += lzo.o lzo-rle.o > > Even though they're built as separate modules, they depend on a single > kconfig symbol. Moreover, lzo-rle uses most of the original lzo > functions (adding just RLE on top), so they should arguably just be > merged. I don't know how receptive upstream is to that idea, but it > seems logical to me. > Rui, during my work I also had the impression, that both files probably share a lot of common code. Based on your comment I had a closer look ... Back in 2019 (v5.1) the linux guys explicitly split the code into separate files to avoid potential data-corrution. https://github.com/torvalds/linux/commit/45ec975efb527625629d123f305 So I don't expect joining the code again will be accepted upstream. Back to the initial issue, I just send my patch of the selection-algorithm to the list for tests and comments. When it's proven to work, I'm fine with trying to push upstream. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: make zram honor available compressors when selecting the initial algo
When initializing the ZRAM it has a hardcoded default of "lzo-rle" compressor.
This
compressor is not available in OpenWrt as only "lzo" is provided. The current
behaviour make the PROCD_ZRAM_TMPFS feature failing, as procd-init is relying on
the kernels default-algo, which is not present. So setting tmpfs falls back to
not
use ZRAM.
Patch the kernel to keep the current preference to "lzo-rle" but check that it
is
present. If not, fall back to "lzo" or any other of the known compressors.
See also:
* http://lists.openwrt.org/pipermail/openwrt-devel/2020-September/031430.html
* 419f149e482641ddc520f80a7ab2038f7e2ebc8a
Signed-off-by: Sven Roederer
---
.../pending-5.4/801-zram_default-algo.patch | 109 ++
1 file changed, 109 insertions(+)
create mode 100644 target/linux/generic/pending-5.4/801-zram_default-algo.patch
diff --git a/target/linux/generic/pending-5.4/801-zram_default-algo.patch
b/target/linux/generic/pending-5.4/801-zram_default-algo.patch
new file mode 100644
index 00..332bf24fed
--- /dev/null
+++ b/target/linux/generic/pending-5.4/801-zram_default-algo.patch
@@ -0,0 +1,109 @@
+diff -ur linux-5.4.154.orig/drivers/block/zram/zcomp.c
linux-5.4.154/drivers/block/zram/zcomp.c
+--- linux-5.4.154.orig/drivers/block/zram/zcomp.c 2021-10-17
10:42:35.0 +0200
linux-5.4.154/drivers/block/zram/zcomp.c 2021-11-29 02:07:04.118702563
+0100
+@@ -14,24 +14,6 @@
+
+ #include "zcomp.h"
+
+-static const char * const backends[] = {
+- "lzo",
+- "lzo-rle",
+-#if IS_ENABLED(CONFIG_CRYPTO_LZ4)
+- "lz4",
+-#endif
+-#if IS_ENABLED(CONFIG_CRYPTO_LZ4HC)
+- "lz4hc",
+-#endif
+-#if IS_ENABLED(CONFIG_CRYPTO_842)
+- "842",
+-#endif
+-#if IS_ENABLED(CONFIG_CRYPTO_ZSTD)
+- "zstd",
+-#endif
+- NULL
+-};
+-
+ static void zcomp_strm_free(struct zcomp_strm *zstrm)
+ {
+ if (!IS_ERR_OR_NULL(zstrm->tfm))
+diff -ur linux-5.4.154.orig/drivers/block/zram/zcomp.h
linux-5.4.154/drivers/block/zram/zcomp.h
+--- linux-5.4.154.orig/drivers/block/zram/zcomp.h 2021-10-17
10:42:35.0 +0200
linux-5.4.154/drivers/block/zram/zcomp.h 2021-11-29 02:05:57.777496700
+0100
+@@ -6,6 +6,24 @@
+ #ifndef _ZCOMP_H_
+ #define _ZCOMP_H_
+
++static const char * const backends[] = {
++"lzo-rle",
++"lzo",
++#if IS_ENABLED(CONFIG_CRYPTO_LZ4)
++"lz4",
++#endif
++#if IS_ENABLED(CONFIG_CRYPTO_LZ4HC)
++"lz4hc",
++#endif
++#if IS_ENABLED(CONFIG_CRYPTO_842)
++"842",
++#endif
++#if IS_ENABLED(CONFIG_CRYPTO_ZSTD)
++"zstd",
++#endif
++NULL
++};
++
+ struct zcomp_strm {
+ /* compression/decompression buffer */
+ void *buffer;
+diff -ur linux-5.4.154.orig/drivers/block/zram/zram_drv.c
linux-5.4.154/drivers/block/zram/zram_drv.c
+--- linux-5.4.154.orig/drivers/block/zram/zram_drv.c 2021-10-17
10:42:35.0 +0200
linux-5.4.154/drivers/block/zram/zram_drv.c2021-11-29
02:04:57.400399244 +0100
+@@ -41,7 +41,6 @@
+ static DEFINE_MUTEX(zram_index_mutex);
+
+ static int zram_major;
+-static const char *default_compressor = "lzo-rle";
+
+ /* Module params (documentation at end) */
+ static unsigned int num_devices = 1;
+@@ -1882,6 +1881,7 @@
+ struct zram *zram;
+ struct request_queue *queue;
+ int ret, device_id;
++ int comp_count = 0;
+
+ zram = kzalloc(sizeof(struct zram), GFP_KERNEL);
+ if (!zram)
+@@ -1915,6 +1915,24 @@
+ goto out_free_queue;
+ }
+
++ /* check default compressors and select 1st available */
++ for (; backends[comp_count]; comp_count++) {
++ if (crypto_has_alg(backends[comp_count], 0, 0)) {
++ pr_info("Using %s compressor as zram default\n",
++ backends[comp_count]);
++ strlcpy(zram->compressor, backends[comp_count],
++ sizeof(zram->compressor));
++ } else {
++ pr_warn("%s compressor not found. Checking next ...\n",
++ backends[comp_count]);
++ }
++ }
++ if (!zram->compressor) {
++ pr_err("Error finding a default compressor\n");
++ ret = -ENXIO;
++ goto out_free_queue;
++ }
++
+ zram->disk->major = zram_major;
+ zram->disk->first_minor = device_id;
+ zram->disk->fops = _devops;
+@@ -1957,8 +1975,6 @@
+ (BDI_CAP_STABLE_WRITES | BDI_CAP_SYNCHRONOUS_IO);
+ device_add_disk(NULL, zram->disk, zram_disk_attr_groups);
+
+- strlcpy(zram->compressor, default_compressor, sizeof(zram->compressor));
+-
+ zram_debugfs_register(zram);
+ p
Re: zram-swap: default to lzo instead of lzo-rle compression
Am Donnerstag, 17. September 2020, 12:11:19 CET schrieben Sie: > On Thu, 17 Sep 2020 at 10:38, e9hack wrote: > > Hi, > > > > I think commit 419f149e482641ddc520f80a7ab2038f7e2ebc8a is not the proper > > fix for the described issue. > > > > The kernel module lzo-rle is still missing. To solve this, it must be > > installed on the root-fs: > > > > Good catch. You're absolutely right, the lzo-rle is a separate module. > Now, what I don't understand is why the crypto layer advertises > lzo-rle support without the module being present. Sounds like an > upstream bug to me? > Rui, not sure if to call it a bug. At the end there is a hardcoded default algo in the module, that is used initially when creating the device. The check for the valid algo is done later at device-activation. I spend some time in this code and have a patch ready, which checks for algos before announcing them. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[21.02] netifd: backport "system-linux: fix deletion of ip tunnels (FS#4058)"
Hi, recently found the time to update my router to OpenWrt-21.02. All seems fine beside an issue with IPIP-tunnels. I was able to track this down to netifd. And I also found FS#4058 and the recent fix () pushed by Hans. As the patch cleanly applies to current 21.02-netifd, it would be great to cherry-pick it to fix netifd. relevant commit is: https://git.op enwrt.org/?p=project/netifd.git;a=commit ;h=8f82742ca4f47f459284f3a07323d04da72ea 5f6 Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] dropbear: add config options for agent-forwarding support
* SSH agent forwarding might cause security issues, locally and on the jump machine (https://defn.io/2019/04/12/ssh-forwarding/). So allow to completely disabling it. * separate options for client and server * keep it enabled by default Signed-of-by: Sven Roederer --- package/network/services/dropbear/Config.in | 9 + package/network/services/dropbear/Makefile | 5 - 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/package/network/services/dropbear/Config.in b/package/network/services/dropbear/Config.in index 15000eff53..d4644fc88f 100644 --- a/package/network/services/dropbear/Config.in +++ b/package/network/services/dropbear/Config.in @@ -95,6 +95,11 @@ config DROPBEAR_DBCLIENT bool "Build dropbear with dbclient" default y +config DROPBEAR_DBCLIENT_AGENTFORWARD + bool "Enable agent forwarding in dbclient" + default y + depends on DROPBEAR_DBCLIENT + config DROPBEAR_SCP bool "Build dropbear with scp" default y @@ -109,4 +114,8 @@ config DROPBEAR_ASKPASS Increases binary size by about 0.1 kB (MIPS). +config DROPBEAR_AGENTFORWARD + bool "Enable agent forwarding" + default y + endmenu diff --git a/package/network/services/dropbear/Makefile b/package/network/services/dropbear/Makefile index 77887f39db..861f4486db 100644 --- a/package/network/services/dropbear/Makefile +++ b/package/network/services/dropbear/Makefile @@ -32,7 +32,8 @@ PKG_CONFIG_DEPENDS:= \ CONFIG_DROPBEAR_CURVE25519 CONFIG_DROPBEAR_ZLIB \ CONFIG_DROPBEAR_ED25519 CONFIG_DROPBEAR_CHACHA20POLY1305 \ CONFIG_DROPBEAR_UTMP CONFIG_DROPBEAR_PUTUTLINE \ - CONFIG_DROPBEAR_DBCLIENT CONFIG_DROPBEAR_SCP CONFIG_DROPBEAR_ASKPASS + CONFIG_DROPBEAR_DBCLIENT CONFIG_DROPBEAR_SCP CONFIG_DROPBEAR_ASKPASS \ + CONFIG_DROPBEAR_DBCLIENT_AGENTFORWARD CONFIG_DROPBEAR_AGENTFORWARD include $(INCLUDE_DIR)/package.mk @@ -137,6 +138,8 @@ DB_OPT_CONFIG = \ !!DROPBEAR_ECC_384|CONFIG_DROPBEAR_ECC_FULL|1|0 \ !!DROPBEAR_ECC_521|CONFIG_DROPBEAR_ECC_FULL|1|0 \ DROPBEAR_CLI_ASKPASS_HELPER|CONFIG_DROPBEAR_ASKPASS|1|0 \ + DROPBEAR_CLI_AGENTFWD|CONFIG_DROPBEAR_DBCLIENT_AGENTFORWARD|1|0 \ + DROPBEAR_SVR_AGENTFWD|CONFIG_DROPBEAR_AGENTFORWARD|1|0 \ TARGET_CFLAGS += -DARGTYPE=3 -ffunction-sections -fdata-sections -flto -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/3] base-files: failsafe: Start also CPU interface for DSA
Am Sonntag, 20. Juni 2021, 17:11:08 CEST schrieb Hauke Mehrtens: > On 6/20/21 4:30 PM, Sven Roederer wrote: > > > > The Rb750 is DSA, so it seems there is still something wrong. I'll retest > > with current master soon, to rule out issues based on 21.02-rc3. > > > > Sven > > Hi, > > I tried it on a lantiq device with the DSA patches applied and it works > fine. > Hauke, I found some tme to test and and confirm the this patch-series also fixes the issue on the RB750Gr3 with DSA. As it takes much longer till the network is up, in comparison to 19.07, it seems that I gave up to quickly. IÄve seen you pushed some updated patch-sets already, so my comment here might be only for reference. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/3] base-files: failsafe: Start also CPU interface for DSA
Am Samstag, 19. Juni 2021, 20:36:10 CEST schrieb Hauke Mehrtens: > On a DSA switch the ports have an upper device, the CPU device, e.g. > eth0. This device has to be in up state to bring up the lower devices > like lan1. > > Parse the link device from "ip link show" and bring it into up stated > before bringing up the actual interface. > > This is needed to make network in failsafe on systems with DSA work. > Hauke, I tested you patches on the Mikrotik RB750Gr3 and WDR3600 (as I did in FS#3866), this time with customized IP-adresses and patches applied to OpenWrt-21.02. For the WDR3600 the issue was fixed, but for the RB750 there is no network. I was not able to usr IPv6 link-local, OpenWrt default 192.168.1.1 or my custom IP-Address. The Rb750 is DSA, so it seems there is still something wrong. I'll retest with current master soon, to rule out issues based on 21.02-rc3. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02.0 Third release candidate
Am Donnerstag, 17. Juni 2021, 21:22:34 CEST schrieb Hauke Mehrtens: > In particular, make sure to read the regressions and known issues before > upgrading: > https://openwrt.org/releases/21.02/notes-21.02.0-rc3#known_issues > just let me highlight FS#3866 (no network in failsafe) Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] libopkg: pkg_hash: print unresolved dependencies
Am Dienstag, 8. Juni 2021, 21:48:40 CEST schrieb Hauke Mehrtens: > When a package is not installed because it has unresolved dependencies > normally we get only an error message like this: > * pkg_hash_fetch_best_installation_candidate: Packages for ltq-vdsl-app > found, but incompatible with the architectures configured * > opkg_install_cmd: Cannot install package ltq-vdsl-app. > > Log in addition the following error message: > * pkg_hash_check_unresolved: cannot find dependency ltq-dsl-base for > ltq-vdsl-app > > Signed-off-by: Hauke Mehrtens > --- Hauke, might be worth to mention in the commitmessage that this closes FS#3814. Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH luci] luci-mod-network: split config migration into 2 steps
Am Samstag, 29. Mai 2021, 18:10:59 CEST schrieb Hauke Mehrtens: > On 5/29/21 5:25 PM, Rafał Miłecki wrote: > > > > For the sake of simplicity and reliability use 2 steps migration. The > > downside is that users may get prompted twice to migrate. > > > > I tested it in OpenWrt 21.02 doing the migration in one step by clicking > continue 2 times and also interrupting it in between, both worked. > I just gave it a try from a 21.02-rc1 based config and it looks fine. One note: I made PR https://github.com/openwrt/luci/pull/5086 to include a hint, that the conversion-dialog might come up multiple times. This will prevent confusion of the user, which might expect an endless loop when the dialog comes up the 2nd time. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
build-environment and pathlength
Hi, since some time I carry a patch along to fix running mkimage with a long pathname for $TOPDIR. Recently 5a9608102b3c4 was added to work around a similar issue in kernel2minor (also addressed by [1]) and I just found another when building uclibc++ . Based on this it might be required to add a check for the length of $TOPDIR to avoid buildfailures just as of such upstream-limitations. At least the uclibc+ + is easy to identify, but kernel2minor and mkimage took some effort and upstream fixing. But there are more like this waiting for sure. Adding such test will be quite straight forward, but 2 questions come up instantly: * Do we want such check / restriction? * What will be the best limit for the pathlength? Sven uclibc++ build-log make[5]: Entering directory '/mnt/hosts/strike/develop/sven/openwrt/freifunk/ lng- path/freifunk-berlin/openwrt/build_dir/target-mipsel_24kc_musl/uClibc++-0.2.5' make[5]: stat: src/abi/ libsupc/._mnt_hosts_strike_develop_sven_openwrt_freifunk_lng- path_freifunk-berlin_openwrt_staging_dir_toolchain- mipsel_24kc_gcc-8.4.0_musl_lib_gcc_mipsel-openwrt-linux- musl_8.4.0_.._.._.._.._mipsel-openwrt-linux-musl_lib_libsupc++.a.dep: File name too long /bin/sh: 1: cannot create src/abi/ libsupc/._mnt_hosts_strike_develop_sven_openwrt_freifunk_lng- path_freifunk-berlin_openwrt_staging_dir_toolchain- mipsel_24kc_gcc-8.4.0_musl_lib_gcc_mipsel-openwrt-linux- musl_8.4.0_.._.._.._.._mipsel-openwrt-linux-musl_lib_libsupc++.a.dep: File name too long AR cr src/libuClibc++.a /mnt/hosts/strike/develop/sven/openwrt/freifunk/ lng- path/freifunk-berlin/openwrt/staging_dir/toolchain-mipsel_24kc_gcc-8.4.0_musl/ lib/gcc/mipsel-openwrt-linux-musl/8.4.0/../../../../mipsel-openwrt-linux-musl/ bin/ar: array_type_info.o: No such file or directory src/Makefile.in:44: recipe for target 'src/libuClibc++.a' failed make[5]: *** [src/libuClibc++.a] Error 1 mkimage failure: /mnt/hosts/strike/develop/sven/openwrt/freifunk/second_builddir/openwrt/ scripts/mkits-qsdk-ipq-image.sh /mnt/hosts/strike/develop/sven/openwrt/ freifunk/second_builddir/openwrt/build_dir/target-arm_cortex-a7+neon- vfpv4_musl_eabi/linux-ipq40xx_generic/tmp/freifunk-berlin-sam0815- master-08aa269af-ipq40xx-generic-alfa-network_ap120c-ac-squashfs-nand- factory.bin.its ubi /mnt/hosts/strike/develop/sven/openwrt/freifunk/ second_builddir/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/ linux-ipq40xx_generic/tmp/freifunk-berlin-sam0815-master-08aa269af-ipq40xx- generic-alfa-network_ap120c-ac-squashfs-nand-factory.bin PATH=/mnt/hosts/strike/develop/sven/openwrt/freifunk/second_builddir/openwrt/ build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx_generic/ linux-5.4.119/scripts/dtc:/mnt/hosts/strike/develop/sven/openwrt/freifunk/ second_builddir/openwrt/staging_dir/toolchain-arm_cortex-a7+neon- vfpv4_gcc-8.4.0_musl_eabi/bin:/mnt/hosts/strike/develop/sven/openwrt/freifunk/ second_builddir/openwrt/staging_dir/toolchain-arm_cortex-a7+neon- vfpv4_gcc-8.4.0_musl_eabi/bin:/mnt/hosts/strike/develop/sven/openwrt/freifunk/ second_builddir/openwrt/staging_dir/toolchain-arm_cortex-a7+neon- vfpv4_gcc-8.4.0_musl_eabi/bin:/mnt/hosts/strike/develop/sven/openwrt/freifunk/ second_builddir/openwrt/staging_dir/toolchain-arm_cortex-a7+neon- vfpv4_gcc-8.4.0_musl_eabi/bin:/mnt/hosts/strike/develop/sven/openwrt/freifunk/ second_builddir/openwrt/staging_dir/host/bin:/mnt/hosts/strike/develop/sven/ openwrt/freifunk/second_builddir/openwrt/staging_dir/toolchain-arm_cortex- a7+neon-vfpv4_gcc-8.4.0_musl_eabi/bin:/mnt/hosts/strike/develop/sven/openwrt/ freifunk/second_builddir/openwrt/staging_dir/host/bin:/mnt/hosts/strike/ develop/sven/openwrt/freifunk/second_builddir/openwrt/staging_dir/host/bin:/ usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/ local/games:/snap/bin mkimage -f /mnt/hosts/strike/develop/sven/openwrt/ freifunk/second_builddir/openwrt/build_dir/target-arm_cortex-a7+neon- vfpv4_musl_eabi/linux-ipq40xx_generic/tmp/freifunk-berlin-sam0815- master-08aa269af-ipq40xx-generic-alfa-network_ap120c-ac-squashfs-nand- factory.bin.its /mnt/hosts/strike/develop/sven/openwrt/freifunk/ second_builddir/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/ linux-ipq40xx_generic/tmp/freifunk-berlin-sam0815-master-08aa269af-ipq40xx- generic-alfa-network_ap120c-ac-squashfs-nand-factory.bin.new /mnt/hosts/strike/develop/sven/openwrt/freifunk/second_builddir/openwrt/ build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx_generic/tmp/ freifunk-berlin-sam0815-master-08aa269af-ipq40xx-generic-alfa-network_ap120c-
Re: opkg fails to install manually downloaded packages
Hauke, thanks for the pointer. My comments in the original thread. Sven Am Sonntag, 16. Mai 2021, 23:34:04 CEST schrieb Hauke Mehrtens: > > I debugged a similar problem a week ago and added this patch to opkg: > https://patchwork.ozlabs.org/project/openwrt/patch/20210502205912.23753-1-ha > u...@hauke-m.de/ > > This shows the missing dependencies, but I am not sure if the > pkg_hash_check_unresolved() function could also fail in good cases. > > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH opkg] libopkg: pkg_hash: print unresolved dependencies
Hi,
Am Montag, 3. Mai 2021, 19:46:22 CEST schrieb Hauke Mehrtens:
> On 5/3/21 2:38 PM, Baptiste Jonglez wrote:
> > Hi,
> >
> > On 02-05-21, Hauke Mehrtens wrote:
> >> When a package is not installed because it has unresolved dependencies
> >>
> >> normally we get only an error message like this:
> >> * pkg_hash_fetch_best_installation_candidate: Packages for ltq-vdsl-app
> >> found, but incompatible with the architectures configured *
> >> opkg_install_cmd: Cannot install package ltq-vdsl-app.
> >>
> >> Log in addition the following error message:
> >> * pkg_hash_check_unresolved: can not find dependency ltq-dsl-base for
> >> ltq-vdsl-app>
> > Since the error has probably nothing to do with "architectures", wouldn't
> > it make more sense to remove or improve the first error message? Or
> > understand why it fails for seemingly unrelated reasons.
>
> This "incompatible with the architectures configured" error message is
> shown for more error cases than the newly added one, see here:
> https://lxr.openwrt.org/source/opkg-lede/libopkg/pkg_hash.c#L395
>
> It would probably be good to improve the error messages, but I do not
> understand the full code. If someone has some suggestions on how to
> improve this it would be nice.
>
Hauke mentioined this patch in relation to FS#3814. I build a patched version
myself and gave it a test - It fixes the problem
Having no packagelist avail an trying to install luci-proto-ipip results in a
message pointing towards the missing dependent package
~# opkg install /tmp/luci-proto-ipip_git-19.307.61018-284918b_all.ipk
Unknown package 'luci-proto-ipip'.
Collected errors:
* pkg_hash_check_unresolved: can not find dependency ipip for luci-proto-ipip
* pkg_hash_fetch_best_installation_candidate: Packages for luci-proto-ipip
found, but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package luci-proto-ipip.
The "Unknown package 'luci-proto-ipip'." line is still incorrect, but "can not
find dependency ipip" is the key.
So maybe not the last change to the code, but a big improvement.
Sven
> >> Signed-off-by: Hauke Mehrtens
> >> ---
> >>
> >> I am not sure if this would happen in normal cases too and spam the
> >> error log, I only saw this in an error case.
> >>
> >> libopkg/pkg_hash.c | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
> >> index a07a25e..6c04ab2 100644
> >> --- a/libopkg/pkg_hash.c
> >> +++ b/libopkg/pkg_hash.c
> >> @@ -263,8 +263,10 @@ pkg_hash_check_unresolved(pkg_t *maybe)
> >>
> >>if (unresolved) {
> >>
> >>res = 1;
> >>tmp = unresolved;
> >>
> >> - while (*tmp)
> >> + while (*tmp) {
> >> + opkg_msg(ERROR, "can not find dependency %s for %s\n",
> >> *tmp,
> >> maybe->name);>>
> >>free(*(tmp++));
> >>
> >> + }
> >>
> >>free(unresolved);
> >>
> >>}
> >>pkg_vec_free(depends);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: opkg fails to install manually downloaded packages
Hannu, thanks for your support to narrow this down. Am Sonntag, 2. Mai 2021, 18:43:20 CEST schrieb Hannu Nyman: > Sounds like a bug, but it should be named something like "Misleading opkg > catch-all error message 'incompatible architecture' " > Made https://bugs.openwrt.org/index.php?do=details_id=3814 for it. > Those opkg commits in October-November 2020 by Paul, Daniel & Baptiste made > lots of changes to the opkg dependency logic, and apparently the > "incompatible architecture" is now some kind of catch-all, which > catches/displays all kinds of errors too easily. At least: > Earlier there actually was an "incompatible architecture" message that got > displayed if you tried mvebu package to x86 etc.. Apparently now that > message surfaces too easily. Yeah, seems a bit unspecific. Reverting opkg to cf44c2feb606b60, at least gives the expected behaviour. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 1/2] imagebuilder: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archive
Baptiste, Am Freitag, 7. Mai 2021, 14:12:21 CEST schrieb Baptiste Jonglez: > > Since these settings are hidden under "Advanced configuration options (for > developers)", I don't think it's really necessary to leave this kind of > implicit information, I would prefer having a valid .config file. > Just sent out v4 of this patch including all the mentioned changes. > Maybe we should even ignore every setting under this "Advanced > configuration options" menu when generating the SDK and Imagebuilder... > But these two are a good start. > Not sure what's all inside these options, but seems a good idea. Probably then a more niversal way should be used than handling every option individually. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4 2/2] sdk: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives
Using these config-options to customize the folders used at build-time makes
these
folder settings appear in generated archive. This causes the SDK to be not
portable, as it's going to use the build-time folders on the new systems.
The errors vary from passing the build, disk out-of-space to permission denied.
The build-time settings of these folders are passed into the archive via
Config.build.
The expected behavior is that the SDK acts after unpacking like these settings
have
their defaults, using intree folders. So just filter these folders out when
running
convert-config.pl to create Config.build.
This addresses the same issue that's fixed in the previous commit for the
imagebuilder.
Signed-off-by: Sven Roederer
---
target/sdk/convert-config.pl | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/target/sdk/convert-config.pl b/target/sdk/convert-config.pl
index f73744af09..08189df95c 100755
--- a/target/sdk/convert-config.pl
+++ b/target/sdk/convert-config.pl
@@ -9,7 +9,13 @@ while (<>) {
chomp;
next if /^CONFIG_SIGNED_PACKAGES/;
- if (/^CONFIG_([^=]+)=(.*)$/) {
+ if (/^CONFIG_((BINARY)|(DOWNLOAD))_FOLDER=(.*)$/) {
+ # We don't want to preserve the build setting of
+ # BINARY_FOLDER and DOWNLOAD_FOLDER.
+ $var = "$1_FOLDER";
+ $val = '""';
+ $type = "string";
+ } elsif (/^CONFIG_([^=]+)=(.*)$/) {
$var = $1;
$val = $2;
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4 0/2] imagebuilder, sdk: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives
This is v4 of this series including the findings and comments of Baptiste * use standard format of disabled config items for imagebuilder * remove unneeded and no-op SED call for SDK ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4 1/2] imagebuilder: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archive
Using these config-options to customize the folders used at build-time makes these folder settings appear in generated archive. This causes the imagebuilder to be not portable, as it's going to use the build-time folders on the new systems. Errors look like: mkdir: cannot create directory '/mnt/build': Permission denied Makefile:116: recipe for target '_call_image' failed make[2]: *** [_call_image] Error 1 Makefile:241: recipe for target 'image' failed make[1]: *** [image] Error 2 The build-time settings of these folders are passed into the archives via .config file. The expected behavior is that after unpacking the imagebuilder acts like these settings have their defaults, using intree folders. So unset the build-time settings. Signed-off-by: Sven Roederer --- target/imagebuilder/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile index f9c08776a8..0580e41c57 100644 --- a/target/imagebuilder/Makefile +++ b/target/imagebuilder/Makefile @@ -29,6 +29,8 @@ $(BIN_DIR)/$(IB_NAME).tar.xz: clean mkdir -p $(IB_KDIR) $(IB_LDIR) $(PKG_BUILD_DIR)/staging_dir/host/lib \ $(PKG_BUILD_DIR)/target $(PKG_BUILD_DIR)/scripts $(IB_DTSDIR) -cp $(TOPDIR)/.config $(PKG_BUILD_DIR)/.config + $(SED) 's/^CONFIG_BINARY_FOLDER=.*/# CONFIG_BINARY_FOLDER is not set/' $(PKG_BUILD_DIR)/.config + $(SED) 's/^CONFIG_DOWNLOAD_FOLDER=.*/# CONFIG_DOWNLOAD_FOLDER is not set/' $(PKG_BUILD_DIR)/.config $(CP) -L \ $(INCLUDE_DIR) $(SCRIPT_DIR) \ $(TOPDIR)/rules.mk \ -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 2/2] sdk: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives
Baptiste,
Am Donnerstag, 6. Mai 2021, 13:08:56 CEST schrieb Baptiste Jonglez:
> Hi,
>
> >
> > target/sdk/Makefile | 1 +
> > target/sdk/convert-config.pl | 8 +++-
> > 2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/sdk/Makefile b/target/sdk/Makefile
> > index 0606621192..5330d14955 100644
> > --- a/target/sdk/Makefile
> > +++ b/target/sdk/Makefile
> > @@ -159,6 +159,7 @@ $(BIN_DIR)/$(SDK_NAME).tar.xz: clean
> >
> > $(SED) 's,^# REVISION:=.*,REVISION:=$(REVISION),g'
> > $(SDK_BUILD_DIR)/include/version.mk $(SED) 's,^#
> > SOURCE_DATE_EPOCH:=.*,SOURCE_DATE_EPOCH:=$(SOURCE_DATE_EPOCH),g'
> > $(SDK_BUILD_DIR)/include/version.mk $(SED) '/LINUX_VERMAGIC:=/ {
> > s,unknown,$(LINUX_VERMAGIC),g }' $(SDK_BUILD_DIR)/include/kernel.mk>
> > + $(SED) 's,default "$(CONFIG_DOWNLOAD_FOLDER)",default "",'
> > $(SDK_BUILD_DIR)/Config.in
> This is unnecessary: as far as I can tell, this file is just copied
> verbatim from target/sdk/files/Config.in and does not contain any
> build-time setting.
Seems you are right ... Need to check again if this is just a forgotten change
of the initial version or if it's really needed.
My initial chages did not use the changes of sdk/convert-config.pl ...
> >
> > diff --git a/target/sdk/convert-config.pl b/target/sdk/convert-config.pl
> > index f73744af09..08189df95c 100755
> > --- a/target/sdk/convert-config.pl
> > +++ b/target/sdk/convert-config.pl
> > @@ -9,7 +9,13 @@ while (<>) {
> >
> > chomp;
> > next if /^CONFIG_SIGNED_PACKAGES/;
> >
> > - if (/^CONFIG_([^=]+)=(.*)$/) {
> > + if (/^CONFIG_((BINARY)|(DOWNLOAD))_FOLDER=(.*)$/) {
> > + # We don't want to preserve the build setting of
> > + # BINARY_FOLDER and DOWNLOAD_FOLDER.
> > + $var = "$1_FOLDER";
> > + $val = '""';
> > + $type = "string";
> > + } elsif (/^CONFIG_([^=]+)=(.*)$/) {
> >
> > $var = $1;
> > $val = $2;
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 1/2] imagebuilder: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archive
Baptiste, Am Donnerstag, 6. Mai 2021, 13:13:46 CEST schrieb Baptiste Jonglez: > > > > + $(SED) 's/^CONFIG_BINARY_FOLDER=.*/# CONFIG_BINARY_FOLDER was reset by > > Imagebuilder/' $(PKG_BUILD_DIR)/.config + $(SED) > > 's/^CONFIG_DOWNLOAD_FOLDER=.*/# CONFIG_DOWNLOAD_FOLDER was reset by > > Imagebuilder/' $(PKG_BUILD_DIR)/.config > Several scripts assume that this exact format is used for disabled config: > "# CONFIG_FOO is not set" (same as in the kernel). > > While your patch works [probably because these scripts are not run when > using the ImageBuilder], it seems cleaner to stick to the standard format, > e.g. in case a .config file is copied around from an imagebuilder. > The intention to not use th normal "unset" message was to leave a pointer why it's unset in contrast to the build-time file, in case someone relies on it. But I'm happy to us the normal message here. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 0/2] imagebuilder, sdk: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives
Am Montag, 26. April 2021, 16:58:20 CEST schrieb Sven Roederer: > Using the BINARY_FOLDER or DOWNLOAD_FOLDER options make them escape from the > build-system to the system the archives run later. > As the build-time path will usually not work on the other system, restore > the intree defaults. > > Hi, are there any concerns with this patch series? Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Installing OpenWrt 21.02 on the TP-Link AD7200
Hi Alex, great to hear that you was able to fix the complete support for this unit. Am Sonntag, 2. Mai 2021, 09:56:04 CEST schrieb Alex Henrie: > > I tried renaming the file to > > AD7200v1-up-ver2-0-1-P1[20170103-rel71053]_2017-01-04_10.08.28.bin to > > match the latest stock firmware and the web interface still didn't > > accept it. > > This was just a rough guessing, based on the old vendor WefIf. But was a bling road ... > > I now have a header soldered to the four pins labeled JP4 but so far I > > have not been able to get serial communication. Do you happen to > > remember what the pinout is? > > I got it working with help from a friend The serial pinout on the > AD7200 is the same as on the C2600. I have attached the complete > serial output while attempting to upload OpenWrt over TFTP, but the Probably it's worth to put a not on the pinout to the Wiki, including a photo of the pcb? Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: opkg fails to install manually downloaded packages
Am Samstag, 1. Mai 2021, 15:14:35 CEST schrieb Hannu Nyman: > Sven Roederer kirjoitti 30.4.2021 klo 22.43: > > ... > > Digging further I found installing online pulled librt in. Restarting from > > scratch ... > > Downloading librt and wall via wget and running `opkg *.ipk` - packages > > have been installed successfully. > > > > So the issue is obviously caused by resolving the dependencies which > > triggers the faulty message: > > > > Collected errors: > > * pkg_hash_fetch_best_installation_candidate: Packages for wall found, > > but > > > > incompatible with the architectures configured" > > > > Previous opkg-version gave a correct indication about missing > > dependencies. > > Yeah, I think that the changes in last November(?) caused several different > errors to be grouped under that error message. > I made a build reverting opkg to "2020-08-31.cf44c2feb606" which restored the known behavior. > * satisfy_dependencies_for: Cannot satisfy the following dependencies for jupp-data: > * jupp Which makes quite clear that some depending package is missing. Example opkg (v2020-08-31.cf44c2feb606 on openwrt-21.02.0-rc1) root@Ahof-Frieden05:~# opkg install -V2 /tmp/jupp-data_3.1.40-1_all.ipk opkg_conf_parse_file: Loading conf file /etc/opkg.conf. opkg_conf_parse_file: Loading conf file /etc/opkg/customfeeds.conf. opkg_conf_parse_file: Loading conf file /etc/opkg/distfeeds.conf. pkg_hash_load_feeds: pkg_hash_load_feeds: pkg_hash_load_status_files: pkg_info_preinstall_check: Updating file owner list. Installing jupp-data (3.1.40-1) to root... satisfy_dependencies_for: This could mean that your package list is out of date or that the packages mentioned above do not yet exist (try 'opkg update'). To proceed in spite of this problem try again with the '-force-depends' option. opkg_configure_packages: Configuring unpacked packages. opkg_configure_packages: Reordering packages before configuring them... Collected errors: * satisfy_dependencies_for: Cannot satisfy the following dependencies for jupp-data: * jupp * opkg_install_cmd: Cannot install package jupp-data. root@Ahof-Frieden05:~# ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: opkg fails to install manually downloaded packages
Am Samstag, 1. Mai 2021, 15:14:35 CEST schrieb Hannu Nyman: > Sven Roederer kirjoitti 30.4.2021 klo 22.43: > > ... > > Digging further I found installing online pulled librt in. Restarting from > > scratch ... > > Downloading librt and wall via wget and running `opkg *.ipk` - packages > > have been installed successfully. > > > > So the issue is obviously caused by resolving the dependencies which > > triggers the faulty message: > > > > Collected errors: > > * pkg_hash_fetch_best_installation_candidate: Packages for wall found, > > but > > > > incompatible with the architectures configured" > > > > Previous opkg-version gave a correct indication about missing > > dependencies. > > Yeah, I think that the changes in last November(?) caused several different > errors to be grouped under that error message. > > > @Hannu: can you reproduce the issue by installing a package that is > > definitively missing a dependency? > > > > Sven > > It still works for me. Below is log of installing a local jupp-data.ipk, > which causes quite properly the jupp.ipk to be downloaded. > > Note that both packages are from the packages download repo. I imagined that > there might be some corner cases where the missing package is from the > .../target/... packages repo, and would have been built by the phase1 > buildbot (like librt actually is). So I test also with protobuf, which > pulls libatomic from .../target/... and even that dowloads properly and > succeeds. > > Can you please show more details about your error, with opkg more verbose > (V2 or V3). So that we could see, what actually fails for you. > > Hannu, below the "v2 logs" of opkg. >From your logs it seems that your opkg is aware of the complete package-list. you seem to have ran "opkg update". My finding is based on a "blank" unit without package-cache * rebooting the board * scp-ing the package to /tmp * then login * calling opkg install The workflow is based on the situation, where the board has no internet-access and I can only login via IPv6-link-local, to install a missing package. example: jupp-data (from the freshly "firstboot"-ed WDR3600) root@OpenWrt:~# cd /tmp root@OpenWrt:/tmp# opkg install -V2 /tmp/jupp-data_3.1.40-1_all.ipk opkg_conf_parse_file: Loading conf file /etc/opkg.conf. opkg_conf_parse_file: Loading conf file /etc/opkg/customfeeds.conf. opkg_conf_parse_file: Loading conf file /etc/opkg/distfeeds.conf. pkg_hash_load_feeds: pkg_hash_load_feeds: pkg_hash_load_status_files: pkg_info_preinstall_check: Updating file owner list. Unknown package 'jupp-data'. opkg_configure_packages: Configuring unpacked packages. opkg_configure_packages: Reordering packages before configuring them... Collected errors: * pkg_hash_fetch_best_installation_candidate: Packages for jupp-data found, but incompatible with the architectures configured * opkg_install_cmd: Cannot install package jupp-data. Sven > > Example: jupp-data > > root@router1:/tmp# opkg install -V2 /tmp/jupp-data_3.1.40-1_all.ipk > opkg_conf_parse_file: Loading conf file /etc/opkg.conf. > opkg_conf_parse_file: Loading conf file /etc/opkg/customfeeds.conf. > opkg_conf_parse_file: Loading conf file /etc/opkg/distfeeds.conf. > pkg_hash_load_feeds: > pkg_hash_load_feeds: > pkg_hash_load_feeds: > pkg_hash_load_feeds: > pkg_hash_load_status_files: > pkg_info_preinstall_check: Updating file owner list. > pkg_hash_fetch_best_installation_candidate: Using latest matching jupp > 3.1.40 arm_cortex-a15_neon-vfpv4. > Installing jupp-data (3.1.40-1) to root... > pkg_hash_fetch_best_installation_candidate: Using latest matching jupp > 3.1.40 arm_cortex-a15_neon-vfpv4. > Installing jupp (3.1.40-1) to root... > Downloading > https://downloads.openwrt.org/releases/21.02-SNAPSHOT/packages/arm_cortex-a1 > 5_neon-vfpv4/packages/jupp_3.1.40-1_arm_cortex-a15_neon-vfpv4.ipk > pkg_run_script: Running script /tmp/opkg-DehkKF/jupp-hndleK/preinst. > opkg_install_pkg: Installing maintainer scripts. > opkg_install_pkg: Installing data files for jupp. > install_data_files: Extracting data files to /. > pkg_write_filelist: Creating //usr/lib/opkg/info/jupp.list file for pkg > jupp. opkg_install_pkg: Resolving conf files for jupp > pkg_run_script: Running script /tmp/opkg-DehkKF/jupp-data-pNIIIk/preinst. > opkg_install_pkg: Installing maintainer scripts. > opkg_install_pkg: Installing data files for jupp-data. > install_data_files: Extracting data files to /. > pkg_write_filelist: Creating //usr/lib/opkg/info/jupp-data.list file for pkg > jupp-data. > opkg_install_pkg: Resolving conf files for jupp-data > opkg_configure_packages: Configuring unpacked packages. &
Re: Installing OpenWrt 21.02 on the TP-Link AD7200
Am Freitag, 30. April 2021, 04:49:09 CEST schrieb Alex Henrie: > I haven't gotten a serial cable hooked up yet, but I tried with > another AD7200 router that is running stock firmware version 1.0.10 > and was not able to upload OpenWrt to it either. Its web interface > gives the error "Invalid file type." When started with the reset > button held down, it looks for a file named > ArcherC2600_1.0_tp_recovery.bin on TFTP, but again, the file transfers > and then the device simply reboots back into its stock firmware. > Alex, not sure if you tried or if it even still applies to TPLink WebIf. But back in the days there was a link in the length of the firmware filename to be uploaded. The message was teh same "invalid firmware type". Probably renaming the file is worth a try ... Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: opkg fails to install manually downloaded packages
Am Freitag, 30. April 2021, 14:23:12 CEST schrieb Hannu Nyman: > Sven Roederer kirjoitti 30.4.2021 klo 1.44: > > Am Donnerstag, 29. April 2021, 01:54:34 CEST schrieb Sven Roederer: > >> Using a freshly installed OpenWrt 21.02 fails to install a package that > >> has > >> been downloaded manually. I had seen this initially when using my own > >> image > >> where a package was missing. To fix I copied over with scp and wanted to > >> install with 'opkg '. It failed, complaining about > >> incompatible arch. rebuilding my image via Imagebuilder made my image > >> work. > >> > > Just did a check on master, which shows the same behavior. > > I wonder if your error is somehow specific to your settings, or some > specific conditions. > > I tested, and I can install downloaded buildbot package .ipks just fine to > my R7800, both with 21.02 and master, my own builds. > > > WNDR3700v2 master: > > OpenWrt SNAPSHOT, r16599-43dad22025 > > - > root@router2:~# cd /tmp > root@router2:/tmp# > wgethttps://downloads.openwrt.org/snapshots/packages/mips_24kc/base/wall_2. > 36.1-2_mips_24kc.ipk Downloading > 'https://downloads.openwrt.org/snapshots/packages/mips_24kc/base/wall_2.36. > 1-2_mips_24kc.ipk' Connecting to 2a01:4f8:251:321::2:443 > Writing to 'wall_2.36.1-2_mips_24kc.ipk' > wall_2.36.1-2_mips_2 100% |***| 10770 0:00:00 > ETA Download completed (10770 bytes) > root@router2:/tmp# opkg install /tmp/wall_2.36.1-2_mips_24kc.ipk > Installing wall (2.36.1-2) to root... > Configuring wall. > fist obvious thing is that your code a 1 day older than my snapshot, but the commits in between seem absolutely irrelevant. One difference: you build your own image, I used the prebuilt from downloads.openwrt.org. Just defaulted my board again with firstboot and had the issue again... Digging further I found installing online pulled librt in. Restarting from scratch ... Downloading librt and wall via wget and running `opkg *.ipk` - packages have been installed successfully. So the issue is obviously caused by resolving the dependencies which triggers the faulty message: Collected errors: * pkg_hash_fetch_best_installation_candidate: Packages for wall found, but incompatible with the architectures configured" Previous opkg-version gave a correct indication about missing dependencies. @Hannu: can you reproduce the issue by installing a package that is definitively missing a dependency? Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[21.02] cherry-pick "ath79: force SGMII SerDes mode to MAC operation"
Hi, there are reports about unstable ethernet-links for TPLink EAP2x5 devices in the forum [1]. I can confirm that cherry-picking fbbad9a9a629b388626b477e6cd692c160f63fb3 to 21.02 fixes it. Can somebody cherry-pick? Best Sven 1 - https://forum.openwrt.org/t/eap225-v1-lan-port-link-speed-100mbit-not-working/88060 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] imagebuilder, sdk: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives
Adrian, Am Sonntag, 25. April 2021, 21:09:40 CEST schrieb Adrian Schmutzler: > Hi, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Sven Roederer > > Sent: Samstag, 24. April 2021 23:48 > > To: openwrt-devel@lists.openwrt.org > > Subject: [PATCH v2] imagebuilder, sdk: unset BINARY_FOLDER and > > DOWNLOAD_FOLDER in final archives > > > > Using these config-options to customize the folders used at build-time > > makes these folder settings appear in generated archives. This causes the > > archives to be not portable, as they going to use the build-time folders > > on > > > > the new systems. Errors look like for the imagebuilder: > > mkdir: cannot create directory '/mnt/build': Permission denied > > Makefile:116: recipe for target '_call_image' failed > > make[2]: *** [_call_image] Error 1 > > Makefile:241: recipe for target 'image' failed > > make[1]: *** [image] Error 2 > > > > The build-time settings of these folders are passed into the archives via > > .config for the imagebuilder and via Config.in and Config.build for the > > sdk. The expected behavior is that after unpacking sdk and imagebuilder > > act like these settings have the default, using intree folders. So unset > > or filter out the build- time settings. > > Consider breaking this down into separate patches for imagebuilder and sdk. > pushed a splitted version as V3 [1]. Indeed I squashed them before submitting initially :-) Best Sven 1 - https://patchwork.ozlabs.org/project/openwrt/list/?series=240802 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: opkg fails to install manually downloaded packages
Am Donnerstag, 29. April 2021, 01:54:34 CEST schrieb Sven Roederer: > > Using a freshly installed OpenWrt 21.02 fails to install a package that has > been downloaded manually. I had seen this initially when using my own image > where a package was missing. To fix I copied over with scp and wanted to > install with 'opkg '. It failed, complaining about incompatible > arch. rebuilding my image via Imagebuilder made my image work. > > Initially thought of some faulty config on my board, but was just testing > with official build from downloads.openwrt.org and could confirm. > > Here my console log (taken on TPLink WDR-3600): > > - > > OpenWrt 21.02.0-rc1, r16046-59980f7aaf > > - > > root@OpenWrt:~# cd /tmp > > root@OpenWrt:/tmp# wget > > https://downloads.openwrt.org/releases/21.02.0-rc1/ > > packages/mips_24kc/base/wall_2.36.1-2_mips_24kc.ipk > > > Downloading 'https://downloads.openwrt.org/releases/21.02.0-rc1/packages/ > > mips_24kc/base/wall_2.36.1-2_mips_24kc.ipk' > > > Connecting to 168.119.138.211:443 > > Writing to 'wall_2.36.1-2_mips_24kc.ipk' > > wall_2.36.1-2_mips_2 100% |***| 10770 > > 0:00:00 > > ETA > > > Download completed (10770 bytes) > > root@OpenWrt:/tmp# opkg install /tmp/wall_2.36.1-2_mips_24kc.ipk > > Unknown package 'wall'. > > > > Collected errors: > > * pkg_hash_fetch_best_installation_candidate: Packages for wall found, > > but > > incompatible with the architectures configured > > > * opkg_install_cmd: Cannot install package wall. > > As far as I can see opkd config looks fine ... > > > root@OpenWrt:/tmp# opkg print-architecture > > arch all 1 > > arch noarch 1 > > arch mips_24kc 10 > > Any ideas? > I did not check on master yet, but I think it's a blocker for 21.02 release. > Just did a check on master, which shows the same behavior. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[21.02] opkg fails to install manually downloaded packages
Hi, I've seen this once, but just was able to double check ... Using a freshly installed OpenWrt 21.02 fails to install a package that has been downloaded manually. I had seen this initially when using my own image where a package was missing. To fix I copied over with scp and wanted to install with 'opkg '. It failed, complaining about incompatible arch. rebuilding my image via Imagebuilder made my image work. Initially thought of some faulty config on my board, but was just testing with official build from downloads.openwrt.org and could confirm. Here my console log (taken on TPLink WDR-3600): > - > OpenWrt 21.02.0-rc1, r16046-59980f7aaf > - > root@OpenWrt:~# cd /tmp > root@OpenWrt:/tmp# wget https://downloads.openwrt.org/releases/21.02.0-rc1/ packages/mips_24kc/base/wall_2.36.1-2_mips_24kc.ipk > Downloading 'https://downloads.openwrt.org/releases/21.02.0-rc1/packages/ mips_24kc/base/wall_2.36.1-2_mips_24kc.ipk' > Connecting to 168.119.138.211:443 > Writing to 'wall_2.36.1-2_mips_24kc.ipk' > wall_2.36.1-2_mips_2 100% |***| 10770 0:00:00 ETA > Download completed (10770 bytes) > root@OpenWrt:/tmp# opkg install /tmp/wall_2.36.1-2_mips_24kc.ipk > Unknown package 'wall'. > Collected errors: > * pkg_hash_fetch_best_installation_candidate: Packages for wall found, but incompatible with the architectures configured > * opkg_install_cmd: Cannot install package wall. As far as I can see opkd config looks fine ... > root@OpenWrt:/tmp# opkg print-architecture > arch all 1 > arch noarch 1 > arch mips_24kc 10 Any ideas? I did not check on master yet, but I think it's a blocker for 21.02 release. Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 2/2] sdk: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives
Using these config-options to customize the folders used at build-time makes
these
folder settings appear in generated archive. This causes the SDK to be not
portable, as it's going to use the build-time folders on the new systems.
The errors vary from passing the build, disk out-of-space to permission denied.
The build-time settings of these folders are passed into the archive via
Config.in
and Config.build.
The expected behavior is that the SDK acts after unpacking like these settings
have
their defaults, using intree folders.
This addresses the same issue that's fixed in the previous commit for the
imagebuilder.
Signed-off-by: Sven Roederer
---
target/sdk/Makefile | 1 +
target/sdk/convert-config.pl | 8 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/target/sdk/Makefile b/target/sdk/Makefile
index 0606621192..5330d14955 100644
--- a/target/sdk/Makefile
+++ b/target/sdk/Makefile
@@ -159,6 +159,7 @@ $(BIN_DIR)/$(SDK_NAME).tar.xz: clean
$(SED) 's,^# REVISION:=.*,REVISION:=$(REVISION),g'
$(SDK_BUILD_DIR)/include/version.mk
$(SED) 's,^#
SOURCE_DATE_EPOCH:=.*,SOURCE_DATE_EPOCH:=$(SOURCE_DATE_EPOCH),g'
$(SDK_BUILD_DIR)/include/version.mk
$(SED) '/LINUX_VERMAGIC:=/ { s,unknown,$(LINUX_VERMAGIC),g }'
$(SDK_BUILD_DIR)/include/kernel.mk
+ $(SED) 's,default "$(CONFIG_DOWNLOAD_FOLDER)",default "",'
$(SDK_BUILD_DIR)/Config.in
find $(SDK_BUILD_DIR) -name .git | $(XARGS) rm -rf
find $(SDK_BUILD_DIR) -name .svn | $(XARGS) rm -rf
find $(SDK_BUILD_DIR) -name CVS | $(XARGS) rm -rf
diff --git a/target/sdk/convert-config.pl b/target/sdk/convert-config.pl
index f73744af09..08189df95c 100755
--- a/target/sdk/convert-config.pl
+++ b/target/sdk/convert-config.pl
@@ -9,7 +9,13 @@ while (<>) {
chomp;
next if /^CONFIG_SIGNED_PACKAGES/;
- if (/^CONFIG_([^=]+)=(.*)$/) {
+ if (/^CONFIG_((BINARY)|(DOWNLOAD))_FOLDER=(.*)$/) {
+ # We don't want to preserve the build setting of
+ # BINARY_FOLDER and DOWNLOAD_FOLDER.
+ $var = "$1_FOLDER";
+ $val = '""';
+ $type = "string";
+ } elsif (/^CONFIG_([^=]+)=(.*)$/) {
$var = $1;
$val = $2;
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 0/2] imagebuilder, sdk: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives
Using the BINARY_FOLDER or DOWNLOAD_FOLDER options make them escape from the build-system to the system the archives run later. As the build-time path will usually not work on the other system, restore the intree defaults. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 1/2] imagebuilder: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archive
Using these config-options to customize the folders used at build-time makes these folder settings appear in generated archive. This causes the imagebuilder to be not portable, as it's going to use the build-time folders on the new systems. Errors look like: mkdir: cannot create directory '/mnt/build': Permission denied Makefile:116: recipe for target '_call_image' failed make[2]: *** [_call_image] Error 1 Makefile:241: recipe for target 'image' failed make[1]: *** [image] Error 2 The build-time settings of these folders are passed into the archives via .config file. The expected behavior is that after unpacking the imagebuilder acts like these settings have their defaults, using intree folders. So unset the build-time settings. Signed-off-by: Sven Roederer --- target/imagebuilder/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile index f9c08776a8..ef7fd3f25e 100644 --- a/target/imagebuilder/Makefile +++ b/target/imagebuilder/Makefile @@ -29,6 +29,8 @@ $(BIN_DIR)/$(IB_NAME).tar.xz: clean mkdir -p $(IB_KDIR) $(IB_LDIR) $(PKG_BUILD_DIR)/staging_dir/host/lib \ $(PKG_BUILD_DIR)/target $(PKG_BUILD_DIR)/scripts $(IB_DTSDIR) -cp $(TOPDIR)/.config $(PKG_BUILD_DIR)/.config + $(SED) 's/^CONFIG_BINARY_FOLDER=.*/# CONFIG_BINARY_FOLDER was reset by Imagebuilder/' $(PKG_BUILD_DIR)/.config + $(SED) 's/^CONFIG_DOWNLOAD_FOLDER=.*/# CONFIG_DOWNLOAD_FOLDER was reset by Imagebuilder/' $(PKG_BUILD_DIR)/.config $(CP) -L \ $(INCLUDE_DIR) $(SCRIPT_DIR) \ $(TOPDIR)/rules.mk \ -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] imagebuilder, sdk: unset BINARY_FOLDER and DOWNLOAD_FOLDER in final archives
Using these config-options to customize the folders used at build-time makes
these
folder settings appear in generated archives. This causes the archives to be not
portable, as they going to use the build-time folders on the new systems. Errors
look like for the imagebuilder:
mkdir: cannot create directory '/mnt/build': Permission denied
Makefile:116: recipe for target '_call_image' failed
make[2]: *** [_call_image] Error 1
Makefile:241: recipe for target 'image' failed
make[1]: *** [image] Error 2
The build-time settings of these folders are passed into the archives via
.config
for the imagebuilder and via Config.in and Config.build for the sdk.
The expected behavior is that after unpacking sdk and imagebuilder act like
these
settings have the default, using intree folders. So unset or filter out the
build-
time settings.
Signed-off-by: Sven Roederer
---
This is an rewrite and extension of the patch send on 11. April.
target/imagebuilder/Makefile | 2 ++
target/sdk/Makefile | 1 +
target/sdk/convert-config.pl | 9 -
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile
index f9c08776a8..ef7fd3f25e 100644
--- a/target/imagebuilder/Makefile
+++ b/target/imagebuilder/Makefile
@@ -29,6 +29,8 @@ $(BIN_DIR)/$(IB_NAME).tar.xz: clean
mkdir -p $(IB_KDIR) $(IB_LDIR) $(PKG_BUILD_DIR)/staging_dir/host/lib \
$(PKG_BUILD_DIR)/target $(PKG_BUILD_DIR)/scripts $(IB_DTSDIR)
-cp $(TOPDIR)/.config $(PKG_BUILD_DIR)/.config
+ $(SED) 's/^CONFIG_BINARY_FOLDER=.*/# CONFIG_BINARY_FOLDER was reset by
Imagebuilder/' $(PKG_BUILD_DIR)/.config
+ $(SED) 's/^CONFIG_DOWNLOAD_FOLDER=.*/# CONFIG_DOWNLOAD_FOLDER was reset
by Imagebuilder/' $(PKG_BUILD_DIR)/.config
$(CP) -L \
$(INCLUDE_DIR) $(SCRIPT_DIR) \
$(TOPDIR)/rules.mk \
diff --git a/target/sdk/Makefile b/target/sdk/Makefile
index 0606621192..5330d14955 100644
--- a/target/sdk/Makefile
+++ b/target/sdk/Makefile
@@ -159,6 +159,7 @@ $(BIN_DIR)/$(SDK_NAME).tar.xz: clean
$(SED) 's,^# REVISION:=.*,REVISION:=$(REVISION),g'
$(SDK_BUILD_DIR)/include/version.mk
$(SED) 's,^#
SOURCE_DATE_EPOCH:=.*,SOURCE_DATE_EPOCH:=$(SOURCE_DATE_EPOCH),g'
$(SDK_BUILD_DIR)/include/version.mk
$(SED) '/LINUX_VERMAGIC:=/ { s,unknown,$(LINUX_VERMAGIC),g }'
$(SDK_BUILD_DIR)/include/kernel.mk
+ $(SED) 's,default "$(CONFIG_DOWNLOAD_FOLDER)",default "",'
$(SDK_BUILD_DIR)/Config.in
find $(SDK_BUILD_DIR) -name .git | $(XARGS) rm -rf
find $(SDK_BUILD_DIR) -name .svn | $(XARGS) rm -rf
find $(SDK_BUILD_DIR) -name CVS | $(XARGS) rm -rf
diff --git a/target/sdk/convert-config.pl b/target/sdk/convert-config.pl
index f73744af09..f6bc831d3a 100755
--- a/target/sdk/convert-config.pl
+++ b/target/sdk/convert-config.pl
@@ -9,7 +9,14 @@ while (<>) {
chomp;
next if /^CONFIG_SIGNED_PACKAGES/;
- if (/^CONFIG_([^=]+)=(.*)$/) {
+ if (/^CONFIG_((BINARY)|(DOWNLOAD))_FOLDER=(.*)$/) {
+ # We don't want to preserve the build setting of
+ # BINARY_FOLDER and DOWNLOAD_FOLDER.
+ $var = "$1_FOLDER";
+ $val = '""';
+ $type = "string";
+# warn "DEBUG: type: $type found for symbol CONFIG_$var=$val\n";
+ } elsif (/^CONFIG_([^=]+)=(.*)$/) {
$var = $1;
$val = $2;
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] toolchain: use xz compression
Also use xz compression, as we do for sdk and imagebuilder. Signed-off-by: Sven Roederer --- target/toolchain/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/target/toolchain/Makefile b/target/toolchain/Makefile index c3ba70db04..cf34a89e04 100644 --- a/target/toolchain/Makefile +++ b/target/toolchain/Makefile @@ -62,13 +62,13 @@ $(BIN_DIR)/$(TOOLCHAIN_NAME).tar.bz2: clean find $(TOOLCHAIN_BUILD_DIR) -name CVS | $(XARGS) rm -rf mkdir -p $(BIN_DIR) (cd $(BUILD_DIR); \ - tar cfj $@ $(TOOLCHAIN_NAME); \ + tar -I '$(STAGING_DIR_HOST)/bin/xz -7e -T$(if $(filter 1,$(NPROC)),2,0)' -cf $@ $(TOOLCHAIN_NAME); \ ) download: prepare: -compile: $(BIN_DIR)/$(TOOLCHAIN_NAME).tar.bz2 +compile: $(BIN_DIR)/$(TOOLCHAIN_NAME).tar.xz install: compile clean: - rm -rf $(TOOLCHAIN_BUILD_DIR) $(BIN_DIR)/$(TOOLCHAIN_NAME).tar.bz2 + rm -rf $(TOOLCHAIN_BUILD_DIR) $(BIN_DIR)/$(TOOLCHAIN_NAME).tar.xz -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: prereq: drop support for Python 3.5
Am Samstag, 17. April 2021, 16:45:01 CEST schrieb Sven Roederer: > On my Ubuntu 16.04 based build-system I also have build-failures for meson > using Python3.5. Correction: it's a 18.04 LTS ... Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build: prereq: drop support for Python 3.5
Hi, Am Dienstag, 16. Februar 2021, 17:17:17 CEST schrieb Petr Štetiar: > > > The meson build system bumped their python requirement to 3.6 for the > > 0.57.0 release. This patch ensures that OpenWrt can update meson while > > still relying on the host python. > > Current buildbot images are based on Debian 9, which uses Python 3.5 so > merging this would result in broken buildbots. > On my Ubuntu 16.04 based build-system I also have build-failures for meson using Python3.5. They are triggered by the "mlog module" . Cherry-picking the recent meson updates into the packages feed fixing these errors, not sure if this is caused by the meson upgrade or the python-upgrade. So it's indeed a tricky situation. But having the EOLed Python3.5 as minimum requirement for an upcoming release seems non optimal. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 21.02] feeds: freifunk: use mirror from openwrt.org
Am Sonntag, 21. Februar 2021, 20:13:40 CEST schrieb Petr Štetiar: Hi, > > > I have submitted two PR's to remove the freifunk feed from master and > > openwrt-21.02. > > thank you for the heads up, I'm just wondering why we should left > openwrt-19.07[1] behind? > > 1. https://git.openwrt.org/2a3dbded93775aeaf28fbebbd6aada07c9f588c1 > probably as removing inside a release-branch without real need has the potential to cause more trouble than we will gain. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: firmware-utils: mkmylofw broken since 9. Apr 2021
Hi Rafał,
thanks for picking this up soo quickly.
Am Dienstag, 13. April 2021, 14:02:10 CEST schrieb Rafał Miłecki:
> > The original code comes from Florian from the 2007 commit 7b564bfdcbef
> > ("Fix potential unligned access with MyLoader based devices, thanks
> > Juhos")
> >
> > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=7b564bfdcbef
> > 05f68d8a658caf832c6832705e1f
> >
> > Sven, Florian: any chance you know how that code:
> > /* align next block on a 4 byte boundary */
> > len = ALIGN(len,4) - block->size;
> >
> > was meant to behave originally?
>
> Please check commit d4f2c2914a65 ("firmware-utils: mkmylofw: fix blocks
> padding")
> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=d4f2c2914a6547
> ef6067dd0968c4970e913f17f0
I can confirm, that this change make the image-building pass with filesizes as
expected.
As I don't own any of this hardware, I can't do run-test but only compile
test.
Best Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Strongswan 6.0 removing ipsec CLI
Philip, I already read about deprecating ipsec tool someyears ago and started to use swanctl. I hacked some scripts together on one of my nodes to not use ipsec- cli. (Sadly I stopped at some point, without making it useable outside of my "lab" to pubish / share.) By the time I became a fan of swanctl more and more. Happy to see that you made swanctl-config integration to UCI. So no worries in dropping ipsec-tool way, even it feels like a era is ending .. Sven Am Dienstag, 13. April 2021, 22:19:07 CEST schrieb Philip Prindeville: > Hi all, > > Word is that strongswan-6.0 will remove the ipsec interface. No idea how > many 5.9.x releases will come out before that happens. Doing some > prediction based on the past roadmap: > > The cadence in the past has been every 3 months, and typically x.y.3 or > x.y.4 is the maximum release until 'y' gets bumped. We're at 5.9.2 > (2021/2/26) currently, so .3 or .4 could be out in 1 month and 4 months, > respectively. > > With this news, I'm disinclined (and I believe Noel concurs) to put a lot of > effort into maintaining the ipsec UCI initd scripting. > > I'd rather just focus on adding Wiki documentation on how to tweak your > /etc/config/ipsec configuration to work with swanctl instead. > > Anyone have an objection to this plan? > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
firmware-utils: mkmylofw broken since 9. Apr 2021
Hi, since some days my master builds failing for ath79-generic. I was able to narrow it to running "mkmylofw for compex_wpj344-16m". The tool runs till the drive is full, currently my "compex_wpj344-16m- squashfs-cpximg-6a08.bin.new" is 161GB and growing ... Has anyone else seen this? I'll check to see which of the relevant 6 commit trigger this during the next days. Full command is: > let size="$(stat -c%s /mnt/hosts/strike/develop/sven/openwrt/freifunk/ freifunk-berlin/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/ tmp/freifunk-berlin-sam0815-experimental-nightly-cbbe3507-ath79-generic- compex_wpj344-16m-squashfs-cpximg-6a08.bin)" pad="64* 1024" pad="(pad - (size % pad)) % pad" newsize='size + pad' ; [ $newsize -lt $((0x66)) ] && newsize=0x66 ; /mnt/hosts/strike/develop/sven/openwrt/freifunk/freifunk- berlin/openwrt/staging_dir/host/bin/mkmylofw -B WPE72 -i 0x11f6:0x690:0x11f6:0x690 -r 3 -s 0x100 -p0x3:$newsize:al: 0x8006:"OpenWRT":/mnt/hosts/strike/develop/sven/openwrt/freifunk/freifunk- berlin/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/tmp/ freifunk-berlin-sam0815-experimental-nightly-cbbe3507-ath79-generic- compex_wpj344-16m-squashfs-cpximg-6a08.bin /mnt/hosts/strike/develop/sven/ openwrt/freifunk/freifunk-berlin/openwrt/build_dir/target-mips_24kc_musl/ linux-ath79_generic/tmp/freifunk-berlin-sam0815-experimental-nightly-cbbe3507- ath79-generic-compex_wpj344-16m-squashfs-cpximg-6a08.bin.new Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] imagebuilder: unset BINARY_FOLDER and DOWNLOAD_FOLDER in imagebuilder archive
Setting these folder during buildtime will embedd their location in the .config file. This results in trying to use the same subfolders on the (other) machine running the imagebuilder, where these might be not accessible at all. mkdir: cannot create directory '/mnt/build': Permission denied Makefile:116: recipe for target '_call_image' failed make[2]: *** [_call_image] Error 1 Makefile:241: recipe for target 'image' failed make[1]: *** [image] Error 2 Signed-off-by: Sven Roederer --- target/imagebuilder/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/target/imagebuilder/Makefile b/target/imagebuilder/Makefile index f9c08776a8..3e69ae4a13 100644 --- a/target/imagebuilder/Makefile +++ b/target/imagebuilder/Makefile @@ -29,6 +29,8 @@ $(BIN_DIR)/$(IB_NAME).tar.xz: clean mkdir -p $(IB_KDIR) $(IB_LDIR) $(PKG_BUILD_DIR)/staging_dir/host/lib \ $(PKG_BUILD_DIR)/target $(PKG_BUILD_DIR)/scripts $(IB_DTSDIR) -cp $(TOPDIR)/.config $(PKG_BUILD_DIR)/.config + sed -i 's/^CONFIG_BINARY_FOLDER=.*/# CONFIG_BINARY_FOLDER was reset by Imagebuilder/' $(PKG_BUILD_DIR)/.config + sed -i 's/^CONFIG_DOWNLOAD_FOLDER=.*/# CONFIG_DOWNLOAD_FOLDER was reset by Imagebuilder/' $(PKG_BUILD_DIR)/.config $(CP) -L \ $(INCLUDE_DIR) $(SCRIPT_DIR) \ $(TOPDIR)/rules.mk \ -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[21.02] cherry-pick missing kernel-symbol "RTC_DRV_JZ4740"
Happy easter all and thanks for branching 21.02. Holidays and lockdown give me some time to keep-up with OpenWrt. During this I found that 21.02 is still missing the kernel-CONFIG for RTC_DRV_JZ4740 Can someone cherry-pick 55ed4bf6d7bf80b705d015c3b73f772db485ba9c into 21.02 to fix? Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath10k-ct all hash values are different?
Ben, seems to me, that at least "firmware-5-ct-full-community-12.bin-lede.013" is still not recovered. File is there, but contains only 0x00. This seems to cause my fresh build of 19.07.5 to fail. + curl -f --connect-timeout 20 --retry 5 --location --insecure https:// www.candelatech.com/downloads/ath10k-10-4b/firmware-5-ct-full- community-12.bin-lede.013 % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 548k 100 548k0 0 985k 0 --:--:-- --:--:-- --:--:-- 985k Hash of the downloaded file does not match (file: 6a95c4323e008499af8d3549513c8a128c69b97296888a4c4b642e6c14a65508, requested: 6fa74a3fc87cba97dbc4a7213b760f8d997cd9c5f11900d47d387b23764cf20a) - deleting download. Can you check please? Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] base-files: restore status of system-services after sysupgrade
Am Dienstag, 12. Januar 2021, 13:01:45 CET schrieb Adrian Schmutzler: > > Hello, > > You don't have to run such complicated script. Just restore /etc/rc.d/ > > directory after upgrade. > > Well, that depends on how we want to deal with new services. If I upgrade > from 19.07.5 to master, I'd expect new services to be in their default > initial state. Restoring "old" rc.d would have everything new disabled. > That's counter-intuitive for me. I'm also in favor of not touching new services, which have not been installed before the upgrade. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] base-files: restore status of system-services after sysupgrade
Am Dienstag, 12. Januar 2021, 19:56:54 CET schrieb Hannu Nyman: > Martin Schiller kirjoitti 12.1.2021 klo 9.25: > > 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 > > My two cents to the discussion: > > * I assume that a small minority of users actually disable services, or at > least disable several services, so defaulting to "lets by default always > store status of all services" sounds like overkill. > > * Backuping always info that the dozens of standard services are enabled > sounds unncessary. As services are installed by default as "enabled" to the > image, it might make sense to store only info about "disabled" services and > disable those when restoring the backup in sysupgrade. (Re-enabling the > already enabled services is unnecessary.) That would also help to keep the > amount of new backup info small. > > * make clear in sysupgrade script help texts and documentation that > saving/restoring service status depends on "keep settings". If settings are > not kept, the service status can not be copied in sysupugrade as there is no > sysupgrade.tar.gz to be passed. (And naturally it would not even make sense > to e.g. revert network settings to defaults but keep selected network > services disabled. Easy to cause soft-bricks that way.) > > Hannu, as long as no service was disabled with the "DISABLED_SERVICES" option of the imagebuilder the explicit "enable" is not required. Indeed enabling a service that have been disabled during image creation is a bit edge-case, but I prefer here the "full featured" way. Not enabling such a service also breaks the user experience like the disable case. For sure I can add a explicit note, that the "-n" option will not keep the states. But "do not save configuration over reflash" imho implicitly means all image defaults are used. ___ 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
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
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"
Re: [PATCH] base-files: sysupgrade: store status of system-services
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 ___ 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
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
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] base-files: sysupgrade: store status of system-services
When saving the list of installed pkgs, also store the status of the
system services. The list is created in the etc/backup folder also
and formated as:
/etc/init.d/ {enable|disable}
This way it can be sourced after sysupgrade, to restore the previous
state.
Signed-off-by: Sven Roederer
---
Currently all services get enabled during image creation. This can cause
issues after upgrade with services explicitly disabled by the user.
With this created list sourced by a simple uci-defaults script the state
can be restored automatically.
Not including such a uci-defaults script by default, as currently the
stored package list is also not reinstalled.
package/base-files/Makefile | 2 +-
package/base-files/files/sbin/sysupgrade | 11 +++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/package/base-files/Makefile b/package/base-files/Makefile
index 0c612b73ca..fbcb694592 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:=239
+PKG_RELEASE:=240
PKG_FLAGS:=nonshared
PKG_FILE_DEPENDS:=$(PLATFORM_DIR)/ $(GENERIC_PLATFORM_DIR)/base-files/
diff --git a/package/base-files/files/sbin/sysupgrade
b/package/base-files/files/sbin/sysupgrade
index 79927a2b5c..cadce36172 100755
--- a/package/base-files/files/sbin/sysupgrade
+++ b/package/base-files/files/sbin/sysupgrade
@@ -57,6 +57,7 @@ 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"
@@ -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"
# Avoid touching filesystem on each backup
RAMFS="$(mktemp -d -t sysupgrade.XX)"
@@ -245,6 +247,15 @@ do_save_conffiles() {
\( -exec test -f /overlay/upper/{} \; -exec echo {}
overlay \; \) -o \
\( -exec echo {} unknown \; \) \
\) | sed -e 's,.*/,,;s/\.control /\t/' >
${INSTALLED_PACKAGES}
+
+ # Format: /etc/init.d/servicename {enable,disable}
+ rm -f ${SERVICE_STATUS}
+ for service in /etc/init.d/* ; do \
+ ${service} enabled && \
+ echo >> ${SERVICE_STATUS} "$service" "enable"
|| \
+ echo >> ${SERVICE_STATUS} "$service" "disable" \
+ ; \
+ done
fi
v "Saving config files..."
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
LuCI: split luci.mk into a common and a feed-internal file
Hi, based on Pauls recent idea "rules: add findrev function from LuCI" of reusing some LuCI-code, I'd like to point to a github-PR with a related suggestion: https://github.com/openwrt/luci/pull/2637 As noted in the PR-message, it splits the current luci.mk file into two files. One for common code that might be usefull for other repos and the 2nd file containing the very LuCI-repo specific code. Common code "luci-common.mk" can be included by other repos to use common constants (LUCI_MENU.*, LUCI_LANG.*, LUCI_LIBRARYDIR) and macros (findrev, PKG_GITBRANCH, SrcDiet, JsMin, Package/$(PKG_NAME)/install). But the code only relevant to the packages of the LuCI-repo (template-package-receips, $ (PKG_NAME),luci-base, LuciTranslation) stays in "luci.mk". For LuCI is reduces the size of the current makefile and makes it more easy to understand by new users. For "foreign" repos just including "luci-common.mk" reduces conflicts and clashes. This code is used in the development-branch of the Freifunk Berlin Firmware since mid of 2019 without problems. Also Florian sees some benefits in this change, but it's still waiting for a final ACK or NACK by Jo-Philipp. So probably this is now the best chance to get it also included into 20.xx . Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
build-requirements when using the Imagebuilder
Hi, based on the recent changes to the tools required when using the imagebuilder, I wonder If there are more tools that can be excluded for this case. Candidates I see here are: * patch * unzip * bzip2 * Perl 5.x (including Data::Dumper, Thread::Queue) * Python * Git * rsync This list is just guessing and I did not check. Most of this tools are usually installed on recent systems per defaul and checking for them will nore harm. But Perl and Python might be interesting to exclude from the checks. Is anyone aware, that these are real requirements for Imagebuilder? Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build/prereq: merge ifndef IB block together
Am Donnerstag, 31. Dezember 2020, 20:35:47 CET schrieb Paul Spooren: > > Merged and backported. > I think 4f3806364011aa3aef26fcab2e7b71837a777bcc needs to be backported too, to make it work. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build/prereq: merge ifndef IB block together
Am Mittwoch, 30. Dezember 2020, 05:23:41 CET schrieb Paul Spooren: > Multiple prereq checks are only required within the build system but not > for the ImageBuilder. These checks are excluded by using ifndef IB. > > This commit merges the three ifndef IB blocks together. Happy new year to all. When I made the change to not check for gcc, g++ I was also thinking of using a common "ifndef" block. I used atomic blocks, as I expect it's more straight-forward on later changes and more consistent (copy and paste) for other tools. Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] linux5.4: build-dependency to rsync
Am Freitag, 2. Oktober 2020, 21:34:30 CET schrieb Sven Roederer: > Am Sonntag, 19. April 2020, 11:32:03 CEST schrieb Bjørn Mork: > > Sven Roederer writes: > > > I was just building a master-branch for x86-generic and got following > > > error: > > > > > > make[5]: Entering directory '/mnt/local/btrfs/build/freifunk/ffberlin/ > > > firmware/openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/ > > > linux-5.4.28' > > > > > > INSTALL > > > /mnt/local/btrfs/build/freifunk/ffberlin/firmware/openwrt/build_dir/> > > > > > > toolchain-i386_pentium4_gcc-8.4.0_musl/linux-dev//include > > > /bin/sh: 1: rsync: not found > > > make[5]: *** [Makefile:1186: headers_install] Error 127 > > > make[5]: Leaving directory > > > '/mnt/local/btrfs/build/freifunk/ffberlin/firmware/ > > > openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/linux-5.4.28' > > > make[4]: *** [Makefile:108: > > > /mnt/local/btrfs/build/freifunk/ffberlin/firmware/ > > > openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/ > > > linux-5.4.28/.configured] Error 2 > > > make[4]: Leaving directory > > > '/mnt/local/btrfs/build/freifunk/ffberlin/firmware/ > > > openwrt/toolchain/kernel-headers' > > > time: toolchain/kernel-headers/compile#1.46#0.83#2.26 > > > > > > > > > In https://github.com/torvalds/linux/commit/59b2bd05f5f4d the call to > > > rsync > > > was added. I think we have the 2 options: > > > * use host-command (changing the build-requirements) > > > * compile it ourself (like we do with zip: ad8c2d6099a7da51) > > > > This new dependency looks like it might have been unintentional. rsync > > is not documented in Documentation/process/changes.rst . And there must > > be many other recursive file copying rules in the kernel build system, > > which do *not* depend on rsync. > > > > Maybe check with the kernel community first, verifying that this new > > build dependency was in fact intended? At the very least, that should > > result in a patch to Documentation/process/changes.rst making this > > explicit. > > As neoraider mentioned on github [1] is doesn't look unintended, also the PR > [2] seems to be welcome. > Thanks Stijn, to fix this now by 0ba83a7577. My local patch was also relying on the host-tool and I can get of this patch now. Sven P.S: used this mail to ping on my patch for the kernel-doc too. > Sven > > 1 - https://github.com/freifunk-gluon/gluon/commit/ > 0d616ff2d4cd0a78410ccd993eebdc12d9ecf97f#commitcomment-42864694 > 2 - https://marc.info/?l=linux-doc=160159054823006=2 > > > > ___ > 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: [RFC PATCH 2/5] kernel: deactivate usb on ath79-tiny
Am Sonntag, 6. Dezember 2020, 14:05:15 CET schrieb Adrian Schmutzler: > > Apart from that, I don't see disabling basic features like USB on a device > with USB ports as an option for pure OpenWrt. > Disabling USB was just a pragmatic solution, as without SCSI-support, partition-handling and USB-ACM, I did not see a usecae the USB-port might be needed for. > If the basic configuration does not run or build, we should simply put > "DEFAULT := n" and have the user select the configuration he/she needs. One > might reorganize features between kernel and modules or remove really > optional stuff, but this patch is too much of forcing here. > To me it looked like kernel USB-support is present, even the OpenWrt USB- support is not enabled I've choosen the hardcoded way. So I was able to test the change and ask for comments, without long rework of the config-menu options. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
Am Sonntag, 6. Dezember 2020, 11:03:56 CET schrieb Baptiste Jonglez: > Hi, > > On 06-12-20, Sven Roederer wrote: > > Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as > > they work quite well for basic usage (including full LuCI). > > On some projects with advanced features (e.g. Freifunk) the lack of RAM > > turns them into unstable devices. Mostly caused by several OOM problems > > per day. This series tries to prolong the usage of these boards by moving > > them to the ath79-tiny target. Indeed it makes these boards available on > > ath79-tiny in addition to the current ath79-generic variant. > > Can't you just move the boards instead of duplicating them? > For sure this should be done, in the final merge. Having the same board in different subtargets might confuse ... > > [RFC PATCH 4/5] kernel: ath79-tiny deactivate usually not needed features > > Can you provide an overview of kernel memory consumption before and after? > /proc/vmstat just after boot would give an idea. > Having all this features diabled gives for the kernel of a Nanostation M XM ubnt_nanostation-m-kernel.bin: - ath79-generic: 1792151 - ath79-tiny: 1500108 vmlinux: - ath79-generic: 5588220 - ath79-tiny: 4687644 So a bit more than 16% smaller size, or 900k absolute. A direct runtime comparision I can't provide at the moment, as my test device is running other stuff already. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
Am Sonntag, 6. Dezember 2020, 13:59:52 CET schrieb Adrian Schmutzler:
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Sven Roederer
> > Sent: Sonntag, 6. Dezember 2020 02:07
> > To: openwrt-devel@lists.openwrt.org
> > Subject: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
> >
> > Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as
> > they work quite well for basic usage (including full LuCI).
> > On some projects with advanced features (e.g. Freifunk) the lack of RAM
> > turns them into unstable devices. Mostly caused by several OOM problems
> > per day.
> > This series tries to prolong the usage of these boards by moving them to
> > the ath79-tiny target. Indeed it makes these boards available on
> > ath79-tiny in addition to the current ath79-generic variant.
> > To improve the low RAM situation the default kernel-config for the tiny
> > sub- target will also disable some uncommon features. So the kernel image
> > becomes smaller, which results in lower flash- and RAM-footprint.
>
> As stated in the earlier discussion, I never liked mixing low-flash ("tiny")
> and low-RAM (???) devices.
>
> In contrast, David has made clear that this also is not possible due to
> conflicting goals for both approaches.
>
> So, rather than mixing things up here and making it even harder to
> understand what "tiny" is supposed to be, this proposal IMO should rather
> aim at introducing a new subtarget aiming specifically at low-RAM devices.
> One could then just stop building "tiny" by default (there is only one
> device left, and I doubt people will have much benefit from prebuilt
> packages when they have to strip stuff anyway), and build the new subtarget
> _instead_ (i.e. no additional building overhead).
>
I agree, that some of the "small_flash" defaults are probably not the optimal
choice for 8MB-flash devices.
A new subtarget might be an option, but is it really worth to define a new one
for "deprecated" boards? Esp. as it's to be expected that both will vanish in
the release following 20.xx. A new subtarget feels to me like just adding
additional maintenance and additional confusion to the users.
Adrian, as you mentioned there is currently only one board build for ath79-
tiny at all. So it's a target that might not be interesting for the average
user at all. For this it might be a good idea to stop now building this target
anyway in favor of using the build ressouces more effectively. Getting more
images for the tiny-subtarget will only change when customizing the config .
By writing this I wonder if it gives sense to add a new subtarget "deprecated"
(to all relevant targets) to include all boards that might fall out of support
"soon" as of limited ressources? This will be a clear statement to the users
and even easy to determ, when a board belonge to this subtarget. As we
currently see "tiny" was introduced for the 4/32MB boards but in the meanwhile
should include the 8/32MB boards, too. In the "next wave" I assume 8/64MB
boards will belong to this category in some years. Very likely the 4/32 and
8/32 boards have become unsupportable then anyway and removed from the code-
basis.
I also ran a quick check on the usage of the "small_flash" and "low_mem" flag
features. They are defined for some targets and used to set the "SMALL_FLASH"
and "LOW_MEMORY_FOOTPRINT" config-features. But there seems no other use of
them, or did I miss something? If I'm right, the most difference between
generic and tiny is the "config-default" file.
When there is no further use of the features, it's nor probably an option to
think of combining both into something like "low_ressources". Based on this
some default config-choices can be changed, like "optimize for size",
disabling some "comfort features". As said before, a smaller binary / kernel
will save flash-space and RAM-space, even the flash-space might not be
relevant for all "low_ressources" boards.
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 3/5] ath79: deactivate PARTITION_ADVANCED
on this low-end hardware it's nearly impossible to add external drives, so there seems no need for this partition-type. this will safe some kernel-size --- target/linux/ath79/tiny/config-default | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ath79/tiny/config-default b/target/linux/ath79/tiny/config-default index 8a83323bc2..c42f44b004 100644 --- a/target/linux/ath79/tiny/config-default +++ b/target/linux/ath79/tiny/config-default @@ -6,6 +6,7 @@ CONFIG_NET_DSA_MV88E6060=y # CONFIG_NET_DSA_TAG_QCA is not set CONFIG_NET_DSA_TAG_TRAILER=y CONFIG_NET_SWITCHDEV=y +# CONFIG_PARTITION_ADVANCED is not set CONFIG_PHYLINK=y # CONFIG_PHY_AR7100_USB is not set # CONFIG_PHY_AR7200_USB is not set -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 2/5] kernel: deactivate usb on ath79-tiny
From: adminuser --- target/linux/ath79/image/tiny-tp-link.mk | 4 target/linux/ath79/image/tiny-ubnt.mk| 2 -- target/linux/ath79/image/tiny.mk | 1 - target/linux/ath79/tiny/config-default | 5 +++-- 4 files changed, 3 insertions(+), 9 deletions(-) diff --git a/target/linux/ath79/image/tiny-tp-link.mk b/target/linux/ath79/image/tiny-tp-link.mk index d5b36de577..ab931f02fb 100644 --- a/target/linux/ath79/image/tiny-tp-link.mk +++ b/target/linux/ath79/image/tiny-tp-link.mk @@ -16,7 +16,6 @@ define Device/tplink_tl-mr3020-v1 SOC := ar9331 DEVICE_MODEL := TL-MR3020 DEVICE_VARIANT := v1 - DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport TPLINK_HWID := 0x3021 SUPPORTED_DEVICES += tl-mr3020 endef @@ -27,7 +26,6 @@ define Device/tplink_tl-mr3040-v2 SOC := ar9331 DEVICE_MODEL := TL-MR3040 DEVICE_VARIANT := v2 - DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport TPLINK_HWID := 0x3042 SUPPORTED_DEVICES += tl-mr3040-v2 endef @@ -39,7 +37,6 @@ define Device/tplink_tl-mr3220-v1 DEVICE_MODEL := TL-MR3220 DEVICE_VARIANT := v1 TPLINK_HWID := 0x3221 - DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport SUPPORTED_DEVICES += tl-mr3220 endef TARGET_DEVICES += tplink_tl-mr3220-v1 @@ -238,7 +235,6 @@ define Device/tplink_tl-wr703n $(Device/tplink-4mlzma) SOC := ar9331 DEVICE_MODEL := TL-WR703N - DEVICE_PACKAGES := kmod-usb-chipidea2 TPLINK_HWID := 0x07030101 SUPPORTED_DEVICES += tl-wr703n endef diff --git a/target/linux/ath79/image/tiny-ubnt.mk b/target/linux/ath79/image/tiny-ubnt.mk index a8c5a2cf68..be7dd46761 100644 --- a/target/linux/ath79/image/tiny-ubnt.mk +++ b/target/linux/ath79/image/tiny-ubnt.mk @@ -31,7 +31,6 @@ endef # UBNT_VERSION e.g. one of (6.0.0, 8.5.3) define Device/ubnt DEVICE_VENDOR := Ubiquiti - DEVICE_PACKAGES := kmod-usb2 IMAGES += factory.bin IMAGE/factory.bin := append-kernel | pad-to (BLOCKSIZE) | \ append-rootfs | pad-rootfs | check-size | mkubntimage-split @@ -40,7 +39,6 @@ endef define Device/ubnt-xm $(Device/ubnt) DEVICE_VARIANT := XM - DEVICE_PACKAGES += kmod-usb-ohci IMAGE_SIZE := 7448k UBNT_BOARD := XM UBNT_CHIP := ar7240 diff --git a/target/linux/ath79/image/tiny.mk b/target/linux/ath79/image/tiny.mk index 83c34d718b..800b2055db 100644 --- a/target/linux/ath79/image/tiny.mk +++ b/target/linux/ath79/image/tiny.mk @@ -34,7 +34,6 @@ define Device/pqi_air-pen SOC := ar9330 DEVICE_VENDOR := PQI DEVICE_MODEL := Air-Pen - DEVICE_PACKAGES := kmod-usb2 IMAGE_SIZE := 7680k SUPPORTED_DEVICES += pqi-air-pen endef diff --git a/target/linux/ath79/tiny/config-default b/target/linux/ath79/tiny/config-default index 42243cfc48..8a83323bc2 100644 --- a/target/linux/ath79/tiny/config-default +++ b/target/linux/ath79/tiny/config-default @@ -7,7 +7,8 @@ CONFIG_NET_DSA_MV88E6060=y CONFIG_NET_DSA_TAG_TRAILER=y CONFIG_NET_SWITCHDEV=y CONFIG_PHYLINK=y -CONFIG_PHY_AR7100_USB=y -CONFIG_PHY_AR7200_USB=y +# CONFIG_PHY_AR7100_USB is not set +# CONFIG_PHY_AR7200_USB is not set CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y +# CONFIG_USB_SUPPORT is not set -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 1/5] ath79: put some 8/32MB devices to tiny subtarget
Even the 8MB flash/ 32MB RAM devices provide enough space to install a full OpenWrt and LuCI they often fail to run as stable as 64MB RAM devices. For this reason make such boards also available in the ath79-tiny target. Affected boards include (for now): * Ubiquiti Nanostation M (XM) * TPLink WR1043v1; WR842v1/v2; WR710 Signed-off-by: Sven Roederer --- target/linux/ath79/image/Makefile | 1 + target/linux/ath79/image/common-tp-link.mk| 2 + target/linux/ath79/image/tiny-tp-link.mk | 66 + target/linux/ath79/image/tiny-ubnt.mk | 132 ++ .../ath79/tiny/base-files/etc/board.d/01_leds | 7 + .../tiny/base-files/etc/board.d/02_network| 11 +- .../base-files/etc/board.d/03_gpio_switches | 20 +++ .../etc/hotplug.d/firmware/10-ath9k-eeprom| 7 +- target/linux/ath79/tiny/target.mk | 4 +- 9 files changed, 246 insertions(+), 4 deletions(-) create mode 100644 target/linux/ath79/image/tiny-ubnt.mk create mode 100755 target/linux/ath79/tiny/base-files/etc/board.d/03_gpio_switches diff --git a/target/linux/ath79/image/Makefile b/target/linux/ath79/image/Makefile index 9bec159cf0..565ab14520 100644 --- a/target/linux/ath79/image/Makefile +++ b/target/linux/ath79/image/Makefile @@ -81,6 +81,7 @@ endif ifeq ($(SUBTARGET),tiny) include tiny-netgear.mk include tiny-tp-link.mk +include tiny-ubnt.mk endif $(eval $(call BuildImage)) diff --git a/target/linux/ath79/image/common-tp-link.mk b/target/linux/ath79/image/common-tp-link.mk index 0b7b0e1935..07dd622f30 100644 --- a/target/linux/ath79/image/common-tp-link.mk +++ b/target/linux/ath79/image/common-tp-link.mk @@ -40,6 +40,7 @@ define Device/tplink-4m $(Device/tplink-nolzma) TPLINK_FLASHLAYOUT := 4M IMAGE_SIZE := 3904k + FEATURES := small_flash DEFAULT := n endef @@ -47,6 +48,7 @@ define Device/tplink-4mlzma $(Device/tplink-v1) TPLINK_FLASHLAYOUT := 4Mlzma IMAGE_SIZE := 3904k + FEATURES := small_flash DEFAULT := n endef diff --git a/target/linux/ath79/image/tiny-tp-link.mk b/target/linux/ath79/image/tiny-tp-link.mk index c918c6baa6..d5b36de577 100644 --- a/target/linux/ath79/image/tiny-tp-link.mk +++ b/target/linux/ath79/image/tiny-tp-link.mk @@ -223,6 +223,17 @@ define Device/tplink_tl-wa901nd-v5 endef TARGET_DEVICES += tplink_tl-wa901nd-v5 +define Device/tplink_tl-wr1043nd-v1 + $(Device/tplink-8m) + SOC := ar9132 + DEVICE_MODEL := TL-WR1043N/ND + DEVICE_VARIANT := v1 + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport + TPLINK_HWID := 0x10430001 + SUPPORTED_DEVICES += tl-wr1043nd +endef +TARGET_DEVICES += tplink_tl-wr1043nd-v1 + define Device/tplink_tl-wr703n $(Device/tplink-4mlzma) SOC := ar9331 @@ -243,6 +254,29 @@ define Device/tplink_tl-wr740n-v1 endef TARGET_DEVICES += tplink_tl-wr740n-v1 +define Device/tplink_tl-wr710n-v1 + $(Device/tplink-8mlzma) + SOC := ar9331 + DEVICE_MODEL := TL-WR710N + DEVICE_VARIANT := v1 + DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport + TPLINK_HWID := 0x0711 + SUPPORTED_DEVICES += tl-wr710n +endef +TARGET_DEVICES += tplink_tl-wr710n-v1 + +define Device/tplink_tl-wr710n-v2.1 + $(Device/tplink-8mlzma) + SOC := ar9331 + DEVICE_MODEL := TL-WR710N + DEVICE_VARIANT := v2.1 + DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport + TPLINK_HWID := 0x0712 + TPLINK_HWREV := 0x2 + SUPPORTED_DEVICES += tl-wr710n +endef +TARGET_DEVICES += tplink_tl-wr710n-v2.1 + define Device/tplink_tl-wr740n-v3 $(Device/tplink-4m) SOC := ar7240 @@ -327,6 +361,16 @@ define Device/tplink_tl-wr802n-v2 endef TARGET_DEVICES += tplink_tl-wr802n-v2 +define Device/tplink_tl-wr810n-v2 + $(Device/tplink-8mlzma) + SOC := qca9533 + DEVICE_MODEL := TL-WR810N + DEVICE_VARIANT := v2 + TPLINK_HWID := 0x812 + SUPPORTED_DEVICES += tl-wr810n-v2 +endef +TARGET_DEVICES += tplink_tl-wr810n-v2 + define Device/tplink_tl-wr841-v5 $(Device/tplink-4m) SOC := ar7240 @@ -403,6 +447,28 @@ define Device/tplink_tl-wr841-v12 endef TARGET_DEVICES += tplink_tl-wr841-v12 +define Device/tplink_tl-wr842n-v1 + $(Device/tplink-8m) + SOC := ar7241 + DEVICE_MODEL := TL-WR842N/ND + DEVICE_VARIANT := v1 + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport + TPLINK_HWID := 0x8420001 + SUPPORTED_DEVICES += tl-mr3420 +endef +TARGET_DEVICES += tplink_tl-wr842n-v1 + +define Device/tplink_tl-wr842n-v2 + $(Device/tplink-8mlzma) + SOC := ar9341 + DEVICE_MODEL := TL-WR842N/ND + DEVICE_VARIANT := v2 + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport + TPLINK_HWID := 0x8420002 + SUPPORTED_DEVICES += tl-wr842n-v2 +endef +TARGET_DEVICES += tplink_tl-wr842n-v2 + define Device/tplink_tl-wr940n-v3 $(Device/tplink-4mlzma) SOC := tp9343 diff --git a/target/linux/ath79/image/tiny-ubnt.mk b/target/linux/ath79/image/tiny-ubnt.mk new file mode 100644 index 00..a8c5a2cf68 --- /dev/null +++ b/target/linux/ath79/image/tiny-ubnt.mk @@ -0,0 +1,132
[RFC PATCH 4/5] kernel: ath79-tiny deactivate usually not needed features
From: adminuser this includes: * CONFIG_AIO * CONFIG_HAVE_IDE * CONFIG_NVMEM * CONFIG_DEBUG_FS * CONFIG_DEBUG_KERNEL * CONFIG_HAVE_DEBUG_KMEMLEAK * CONFIG_HAVE_DEBUG_STACKOVERFLOW * CONFIG_ISDN * CONFIG_SND_DRIVERS * CONFIG_STAGING * CONFIG_HAVE_KVM * CONFIG_VIRTIO_MENU --- target/linux/ath79/tiny/config-default | 13 + 1 file changed, 13 insertions(+) diff --git a/target/linux/ath79/tiny/config-default b/target/linux/ath79/tiny/config-default index c42f44b004..5dcdf30af4 100644 --- a/target/linux/ath79/tiny/config-default +++ b/target/linux/ath79/tiny/config-default @@ -13,3 +13,16 @@ CONFIG_PHYLINK=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y # CONFIG_USB_SUPPORT is not set +# CONFIG_HAVE_DEBUG_KMEMLEAK is not set +# CONFIG_HAVE_DEBUG_STACKOVERFLOW is not set +# CONFIG_HAVE_IDE is not set +# CONFIG_HAVE_KVM is not set +# CONFIG_NVMEM is not set +# CONFIG_AIO is not set +# CONFIG_DEBUG_FS is not set +# CONFIG_DEBUG_KERNEL is not set +# CONFIG_ISDN is not set +# CONFIG_SND_DRIVERS is not set +# CONFIG_STAGING is not set +# CONFIG_VIRTIO_MENU is not set + -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 5/5] kernel: ath79-tiny: enable CONFIG_BLOCK
From: adminuser --- target/linux/ath79/tiny/config-default | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ath79/tiny/config-default b/target/linux/ath79/tiny/config-default index 5dcdf30af4..f686d284f6 100644 --- a/target/linux/ath79/tiny/config-default +++ b/target/linux/ath79/tiny/config-default @@ -16,6 +16,7 @@ CONFIG_REGULATOR_FIXED_VOLTAGE=y # CONFIG_HAVE_DEBUG_KMEMLEAK is not set # CONFIG_HAVE_DEBUG_STACKOVERFLOW is not set # CONFIG_HAVE_IDE is not set +CONFIG_BLOCK=y # CONFIG_HAVE_KVM is not set # CONFIG_NVMEM is not set # CONFIG_AIO is not set -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as they work quite well for basic usage (including full LuCI). On some projects with advanced features (e.g. Freifunk) the lack of RAM turns them into unstable devices. Mostly caused by several OOM problems per day. This series tries to prolong the usage of these boards by moving them to the ath79-tiny target. Indeed it makes these boards available on ath79-tiny in addition to the current ath79-generic variant. To improve the low RAM situation the default kernel-config for the tiny sub- target will also disable some uncommon features. So the kernel image becomes smaller, which results in lower flash- and RAM-footprint. [RFC PATCH 1/5] ath79: put some 8/32MB devices to tiny subtarget [RFC PATCH 2/5] kernel: deactivate usb on ath79-tiny [RFC PATCH 3/5] ath79: deactivate PARTITION_ADVANCED [RFC PATCH 4/5] kernel: ath79-tiny deactivate usually not needed features [RFC PATCH 5/5] kernel: ath79-tiny: enable CONFIG_BLOCK ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: flush kernel memory cache during sysupgrade
Am Dienstag, 24. November 2020, 07:39:48 CET schrieb Hannu Nyman:
> Flush kernel memory caches during sysupgrade in order
> to mitigate the impact from memory consumption spikes
> in low-RAM devices.
>
> This may help to prevent sysupgrade causing a reboot
> before the actual flashing starts.
>
> Signed-off-by: Hannu Nyman
> ---
>
> I have noticed this to help in 64 MB WNDR3700v2, where sysupgrade
> typically has failed when the router has been running some time,
> but succeeded when sysupgrade is done right after a reboot.
>
On a 8/32MB device (NanoStation M) it took several attemts to get a sysupgrade
in place. With this change it mostly finished successfully on the 1st attempt.
> The cache flushing is non-destructive and as the router is going
> to sysupgrade, there aren't "long-term" performance issues.
>
As it seems to have no sideeffects I would like to see this merged.
Best Sven
> Reference to mailing list discussion in
> http://lists.openwrt.org/pipermail/openwrt-devel/2020-November/032266.html
>
> Kernel documentation:
> https://www.kernel.org/doc/Documentation/sysctl/vm.txt
>
>
> package/base-files/files/lib/upgrade/common.sh | 1 +
> package/base-files/files/lib/upgrade/stage2| 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/package/base-files/files/lib/upgrade/common.sh
> b/package/base-files/files/lib/upgrade/common.sh index
> a5c27dc2fb..b44a5998f4 100644
> --- a/package/base-files/files/lib/upgrade/common.sh
> +++ b/package/base-files/files/lib/upgrade/common.sh
> @@ -297,6 +297,7 @@ indicate_upgrade() {
> # $(2): (optional) pipe command to extract firmware, e.g. dd bs=n skip=m
> default_do_upgrade() {
> sync
> + echo 3 > /proc/sys/vm/drop_caches
> if [ -n "$UPGRADE_BACKUP" ]; then
> get_image "$1" "$2" | mtd $MTD_ARGS $MTD_CONFIG_ARGS -j
"$UPGRADE_BACKUP"
> write - "${PART_NAME:-image}" else
> diff --git a/package/base-files/files/lib/upgrade/stage2
> b/package/base-files/files/lib/upgrade/stage2 index c7629c383f..23d356a447
> 100755
> --- a/package/base-files/files/lib/upgrade/stage2
> +++ b/package/base-files/files/lib/upgrade/stage2
> @@ -123,6 +123,7 @@ kill_remaining KILL 1
>
> sleep 1
>
> +echo 3 > /proc/sys/vm/drop_caches
>
> if [ -n "$IMAGE" ] && type 'platform_pre_upgrade' >/dev/null 2>/dev/null;
> then platform_pre_upgrade "$IMAGE"
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] procd: also depend on jshn
fixes "file no found" error on stripped down images, caused by prod.sh:43. Signed-off-by: Sven Roederer --- package/system/procd/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/system/procd/Makefile b/package/system/procd/Makefile index 09aded15b5..be41c5276d 100644 --- a/package/system/procd/Makefile +++ b/package/system/procd/Makefile @@ -8,7 +8,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=procd -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(PROJECT_GIT)/project/procd.git @@ -45,7 +45,7 @@ define Package/procd/Default SECTION:=base CATEGORY:=Base system DEPENDS:=+ubusd +ubus +libjson-script +ubox +USE_GLIBC:librt +libubox \ - +libubus +libblobmsg-json +libjson-c + +libubus +libblobmsg-json +libjson-c +jshn TITLE:=OpenWrt system process manager USERID:=:dialout=20 :audio=29 endef -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: running custom commands during sysupgrade -
Am Sonntag, 22. November 2020, 18:07:05 CET schrieb Hannu Nyman:
> Adrian Schmutzler wrote at Fri Oct 16 19:15:38 EDT 2020:
> > Fortunately, and I don't fully understand why, we were able to drive this
>
> to effectively zero by simply running
>
> > echo 3 > /proc/sys/vm/drop_caches
> > directly before sysupgrade. Out of a few hundred upgrades since then, I
>
> haven't had a single soft-brick. I do occasionally have the situation that
> the device reboots into the old firmware again (i.e. upgrade failed in an
> early stage), but for some reason the soft-bricks were completely gone.
>
I've seen this also only rarely, but when it was only happening in remote
localtions where no traces left :-/
> I have stumbled into similar "boot to the old firmware" symptom with my old
> WNDR3700v2 with 64 MB RAM.
> I have not been able to reproduce the problem in WNDR3800 that has 128 MB
> RAM but it otherwise identical, (and has serial cable connected).
>
> Sysupgrade in WNDR3700v2 used to regularly
> * fail, if sysupgrade was run after the router had been running a few days
> * succeed with the same image, when sysupgrade was re-run right after the
> first failure (and automatic reboot)
>
> To avoid failure I have patched the sysupgrade script components itself, and
> I have not seen the problem any more. Patched files are
> /lib/upgrade/common.sh and /lib/upgrade/stage2
>
> I am not sure if those insertion locations are quite optimal, but so far the
> approach has worked
>
>
Hannu,
When you have the patches in place, why not sending as patch officially? The
location in the code is quite the same I would choose. In addition it solves
problems on low-ressource devices and should not cause problems on more
powerfull boards.
Sven
> --- a/package/base-files/files/lib/upgrade/common.sh
> +++ b/package/base-files/files/lib/upgrade/common.sh
> @@ -297,6 +297,7 @@ indicate_upgrade() {
> # $(2): (optional) pipe command to extract firmware, e.g. dd bs=n skip=m
> default_do_upgrade() {
> sync
> +echo 3 > /proc/sys/vm/drop_caches
> if [ -n "$UPGRADE_BACKUP" ]; then
> get_image "$1" "$2" | mtd $MTD_ARGS $MTD_CONFIG_ARGS -j
> "$UPGRADE_BACKUP" write - "${PART_NAME:-image}"
> else
> --- a/package/base-files/files/lib/upgrade/stage2
> +++ b/package/base-files/files/lib/upgrade/stage2
> @@ -123,6 +123,7 @@ kill_remaining KILL 1
>
> sleep 1
>
> +echo 3 > /proc/sys/vm/drop_caches
>
> if [ -n "$IMAGE" ] && type 'platform_pre_upgrade' >/dev/null 2>/dev/null;
> then platform_pre_upgrade "$IMAGE"
>
>
> ___
> 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: running custom commands during sysupgrade - to free ram
Am Sonntag, 18. Oktober 2020, 18:59:19 CET schrieb Sven Roederer:
> > > fail ---
> > > root@gib-mir-einen-namen:~# cat /lib/upgrade/freifunk-berlin_freeup-
> > > ram.sh
> > > ffberlin_freeup_ram() {
> > >
> > > # stop uhttpd and luci
> > > /etc/init.d/uhttpd stop
> > > # remove LuCI-caches
> > > rm >/dev/null -f /tmp/luci-indexcache*
> > > rm >/dev/null -rf /tmp/luci-modulecache } ffberlin_freeup_ram
> > >
> > > ---
> > >
> > > The Upgrade starts as expected and runs up to
> > >
> > > Saving config files...
> > > Commencing upgrade. Closing all shell sessions.
> > >
> > > and then times out. on the serial console I can see that the board just
> > > reboots after some time. Normally it will do:
> > >
> > > Watchdog handover: fd=3
> > > - watchdog -
> > > killall: telnetd: no process killed
> > > killall: ash: no process killed
> > > Sending TERM to remaining processes ... netifd odhcpd uhttpd udhcpc
> > > odhcp6c ntpd dnsmasq pingcheck crond ubusd askfirst urngd logd rpcd
> > > hostapd Sending KILL to remaining processes ... netifd uhttpd dnsmasq
> > > pingcheck sh sh rpcd netifd uhttpd dnsmasq sh rpcd rpcd Switching to
> > > ramdisk...
> > > Performing system upgrade...
> > > Unlocking firmware ...
> > >
> > > Writing from to firmware ...
> > > Appending jffs2 data from /tmp/sysupgrade.tgz to firmware..
> > >
> > > Upgrade completed
> > > Rebooting system...
> > > umount: can't unmount /dev: Resource busy
> > > umount: can't unmount /tmp: Resource busy [ 343.465535] reboot:
> > > Restarting system
> > >
> > >
> > > Any idea what is causing this behavior?
> > > Is my idea a totally wrong approach?
As there was no other comment beside Adrians nice tip, I assume there is at
least no obvious reason why my approachs fails.
I'll see if I can find a way, to make this script running before flashing,
even if I have to patch sysupgrade for this.
Best Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: running custom commands during sysupgrade -
Am Samstag, 17. Oktober 2020, 01:15:38 CEST schrieb Adrian Schmutzler:
> Hi Sven,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Sven Roederer
> > Sent: Samstag, 17. Oktober 2020 00:51
> > To: openwrt-devel@lists.openwrt.org
> > Subject: running custom commands during sysupgrade -
> >
> > Hi,
> >
> > based on my setup for some 8/32 MB devices I'd like to run a custom script
> > before / during sysupgrade. The main task of the script should be to free
> > additional RAM, as I suspect some soft-bricks and aborted upgrades to a
> > OOM- situation.
>
> it's not exactly what you are looking for, but I'm sharing it anyway in case
> it helps you somehow:
>
> Fortunately, and I don't fully understand why, we were able to drive this to
> effectively zero by simply running
>
> echo 3 > /proc/sys/vm/drop_caches
Thanks for this hint. I'll add this line to my script.
>
> directly before sysupgrade. Out of a few hundred upgrades since then, I
> haven't had a single soft-brick. I do occasionally have the situation that
> the device reboots into the old firmware again (i.e. upgrade failed in an
> early stage), but for some reason the soft-bricks were completely gone.
>
> Regarding your actual question, we have a custom upgrade script for our
> firmware where the command above is simple the line before calling
> "sysupgrade $FILE", so we didn't touch OpenWrt routines at all here.
>
As we use plain LuCI and OpenWrt commandline, my intention was not to add
another wrapping-script, but integrate transparently into OpenWrt. But when
your firmware (Gloun) is havnig a script anyways, that's the most easy way.
Sven
>
> > To me the /lib/upgrade folder seems a good place to add such scripts, as
> > the *.sh files there will be sourced already, So additional patching is
> > not required.
> >
> > My problem is: adding a script
> > --
> > root@gib-mir-einen-namen:~# cat /lib/upgrade/freifunk-berlin_freeup-
> > ram.sh
> > ffberlin_freeup_ram() {
> >
> > # remove LuCI-caches
> > rm >/dev/null -f /tmp/luci-indexcache*
> > rm >/dev/null -rf /tmp/luci-modulecache } ffberlin_freeup_ram
> >
> > -
> > works as expected. The files are delete the the firmware gets flashed. But
> > just adding a "ifdown" or "/etc/init.d/ stop" make the upgarde
> > fail ---
> > root@gib-mir-einen-namen:~# cat /lib/upgrade/freifunk-berlin_freeup-
> > ram.sh
> > ffberlin_freeup_ram() {
> >
> > # stop uhttpd and luci
> > /etc/init.d/uhttpd stop
> > # remove LuCI-caches
> > rm >/dev/null -f /tmp/luci-indexcache*
> > rm >/dev/null -rf /tmp/luci-modulecache } ffberlin_freeup_ram
> >
> > ---
> >
> > The Upgrade starts as expected and runs up to
> >
> > Saving config files...
> > Commencing upgrade. Closing all shell sessions.
> >
> > and then times out. on the serial console I can see that the board just
> > reboots after some time. Normally it will do:
> >
> > Watchdog handover: fd=3
> > - watchdog -
> > killall: telnetd: no process killed
> > killall: ash: no process killed
> > Sending TERM to remaining processes ... netifd odhcpd uhttpd udhcpc
> > odhcp6c ntpd dnsmasq pingcheck crond ubusd askfirst urngd logd rpcd
> > hostapd Sending KILL to remaining processes ... netifd uhttpd dnsmasq
> > pingcheck sh sh rpcd netifd uhttpd dnsmasq sh rpcd rpcd Switching to
> > ramdisk...
> > Performing system upgrade...
> > Unlocking firmware ...
> >
> > Writing from to firmware ...
> > Appending jffs2 data from /tmp/sysupgrade.tgz to firmware..
> >
> > Upgrade completed
> > Rebooting system...
> > umount: can't unmount /dev: Resource busy
> > umount: can't unmount /tmp: Resource busy [ 343.465535] reboot:
> > Restarting system
> >
> >
> > Any idea what is causing this behavior?
> > Is my idea a totally wrong approach?
> >
> >
> > Thanks Sven.
> >
> >
> >
> > ___
> > 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
running custom commands during sysupgrade -
Hi,
based on my setup for some 8/32 MB devices I'd like to run a custom script
before / during sysupgrade. The main task of the script should be to free
additional RAM, as I suspect some soft-bricks and aborted upgrades to a OOM-
situation.
To me the /lib/upgrade folder seems a good place to add such scripts, as the
*.sh files there will be sourced already, So additional patching is not
required.
My problem is: adding a script
--
root@gib-mir-einen-namen:~# cat /lib/upgrade/freifunk-berlin_freeup-ram.sh
ffberlin_freeup_ram() {
# remove LuCI-caches
rm >/dev/null -f /tmp/luci-indexcache*
rm >/dev/null -rf /tmp/luci-modulecache
}
ffberlin_freeup_ram
-
works as expected. The files are delete the the firmware gets flashed. But
just adding a "ifdown" or "/etc/init.d/ stop" make the upgarde fail
---
root@gib-mir-einen-namen:~# cat /lib/upgrade/freifunk-berlin_freeup-ram.sh
ffberlin_freeup_ram() {
# stop uhttpd and luci
/etc/init.d/uhttpd stop
# remove LuCI-caches
rm >/dev/null -f /tmp/luci-indexcache*
rm >/dev/null -rf /tmp/luci-modulecache
}
ffberlin_freeup_ram
---
The Upgrade starts as expected and runs up to
Saving config files...
Commencing upgrade. Closing all shell sessions.
and then times out. on the serial console I can see that the board just
reboots after some time. Normally it will do:
Watchdog handover: fd=3
- watchdog -
killall: telnetd: no process killed
killall: ash: no process killed
Sending TERM to remaining processes ... netifd odhcpd uhttpd udhcpc odhcp6c
ntpd dnsmasq pingcheck crond ubusd askfirst urngd logd rpcd hostapd
Sending KILL to remaining processes ... netifd uhttpd dnsmasq pingcheck sh sh
rpcd netifd uhttpd dnsmasq sh rpcd rpcd
Switching to ramdisk...
Performing system upgrade...
Unlocking firmware ...
Writing from to firmware ...
Appending jffs2 data from /tmp/sysupgrade.tgz to firmware..
Upgrade completed
Rebooting system...
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource busy
[ 343.465535] reboot: Restarting system
Any idea what is causing this behavior?
Is my idea a totally wrong approach?
Thanks Sven.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] build, imagebuilder: Do not require compilers
Am Dienstag, 29. September 2020, 09:35:20 CEST schrieb Paul Spooren:
> On Sun Sep 27, 2020 at 11:07 AM HST, Sven Roederer wrote:
> > The buildroot and SDK both require the compilers (gcc, g++) to be
> > installed on the host system, however the ImageBuilder uses precompiled
> > binaries.
> >
> > This patch changes the prerequirements checks to skip the checking for
> > the compilers if running as ImageBuilder. A similar change has been
> > made for libncurses-dev in 4a1a58a3e2d2.
> >
> > Signed-off-by: Sven Roederer
>
> Acked-by: Paul Spooren
>
Anyone willing to merge?
> > ---
> > include/prereq-build.mk | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/include/prereq-build.mk b/include/prereq-build.mk
> > index 4637c6ca50..f67a01299e 100644
> > --- a/include/prereq-build.mk
> > +++ b/include/prereq-build.mk
> > @@ -26,6 +26,7 @@ $(eval $(call TestHostCommand,proper-umask, \
> > Please build with umask 022 - other values produce broken packages, \
> > umask | grep -xE 0?0[012][012]))
> >
> > +ifndef IB
> > $(eval $(call SetupHostCommand,gcc, \
> > Please install the GNU C Compiler (gcc) 4.8 or later, \
> > $(CC) -dumpversion | grep -E '^(4\.[8-9]|[5-9]\.?|10\.?)', \
> > @@ -37,7 +38,9 @@ $(eval $(call TestHostCommand,working-gcc, \
> > it appears to be broken, \
> > echo 'int main(int argc, char **argv) { return 0; }' | \
> > gcc -x c -o $(TMP_DIR)/a.out -))
> > +endif
> >
> > +ifndef IB
> > $(eval $(call SetupHostCommand,g++, \
> > Please install the GNU C++ Compiler (g++) 4.8 or later, \
> > $(CXX) -dumpversion | grep -E '^(4\.[8-9]|[5-9]\.?|10\.?)', \
> > @@ -50,6 +53,7 @@ $(eval $(call TestHostCommand,working-g++, \
> > echo 'int main(int argc, char **argv) { return 0; }' | \
> > g++ -x c++ -o $(TMP_DIR)/a.out - -lstdc++ && \
> > $(TMP_DIR)/a.out))
> > +endif
> >
> > ifndef IB
> > $(eval $(call TestHostCommand,ncurses, \
> > --
> > 2.20.1
> >
> >
> > ___
> > 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: ath79: move 8/32 boards to tiny subtarget
Am Samstag, 3. Oktober 2020, 19:16:51 CEST schrieb Paul Oranje: > > Op 21 sep. 2020, om 20:42 heeft Sven Roederer het > > volgende geschreven: > > > > Fernando, > > > > I'm only talking on the boards having 32MB RAM. This includes 4MB / 8MB > > flash boards. > > I'm not having the 8/64 boards in mind. They are fine and should work for > > some furture releases > > Would it be conceivable to differentiate TINY, or better LOW_MEM and > SMALL_FLASH independently (TINY being a build subtarget), per release ? > > Ratio being that the demands on storage and memory grow with each release. > So some device might in release 19.07 fall in the generic subtarget, but in > 20.xx in TINY (and in 22.xx in SOURCE-ONLY). > Paul, that sound very similar to my idea, right (support --> source-only --> drop)? >From the RAM-restriction side, 4/32 and 8/32 are the same and should probably not be treated very different. Even 8/32 gives the option to install more packages I experienced a lot of OOM events running them in background. In the mean time I tested moving the 8/32 to tiny and tweak the default- kernel config to strip it down. This massively improved the stability of a Ubiquity NSM5 already. It was sitting on my bench ideling and restarted at least once a day, now it's up and running since some days. Regarding differentiating low_ram and small_flash: Probably the profiles can be used for this. But that's behind my knowledge. Best Sven > Regards, > Paul > > > Sven > > > > Am Montag, 21. September 2020, 00:24:00 CEST schrieb Fernando Frediani: > >> I have some concern to call tiny the 8/32 boards. > >> While I understand the 4MB flash devices as phased out the 8/32 are > >> still very popular and probably most of the devices still running in > >> many and many places and they are not really tiny as of today. Some > >> newer low priced are coming with 8/64, but the point is that OpenWrt has > >> been the responsible for many devices to keep going for years with > >> stability and this no doubt will happen with 8/32 for a while. > >> Calling tiny means only 8MB flash or both 8MB flash and 32MB ram ? I may > >> see a point to call the 8MB devices maybe, but not 32MB ram ones. > >> > >> Fernando > > > > ___ > > 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: [OpenWrt-Devel] linux5.4: build-dependency to rsync
Am Sonntag, 19. April 2020, 11:32:03 CEST schrieb Bjørn Mork: > Sven Roederer writes: > > I was just building a master-branch for x86-generic and got following > > error: > > > > make[5]: Entering directory '/mnt/local/btrfs/build/freifunk/ffberlin/ > > firmware/openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/ > > linux-5.4.28' > > > > INSTALL > > /mnt/local/btrfs/build/freifunk/ffberlin/firmware/openwrt/build_dir/> > > toolchain-i386_pentium4_gcc-8.4.0_musl/linux-dev//include > > /bin/sh: 1: rsync: not found > > make[5]: *** [Makefile:1186: headers_install] Error 127 > > make[5]: Leaving directory > > '/mnt/local/btrfs/build/freifunk/ffberlin/firmware/ > > openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/linux-5.4.28' > > make[4]: *** [Makefile:108: > > /mnt/local/btrfs/build/freifunk/ffberlin/firmware/ > > openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/ > > linux-5.4.28/.configured] Error 2 > > make[4]: Leaving directory > > '/mnt/local/btrfs/build/freifunk/ffberlin/firmware/ > > openwrt/toolchain/kernel-headers' > > time: toolchain/kernel-headers/compile#1.46#0.83#2.26 > > > > > > In https://github.com/torvalds/linux/commit/59b2bd05f5f4d the call to > > rsync > > was added. I think we have the 2 options: > > * use host-command (changing the build-requirements) > > * compile it ourself (like we do with zip: ad8c2d6099a7da51) > > This new dependency looks like it might have been unintentional. rsync > is not documented in Documentation/process/changes.rst . And there must > be many other recursive file copying rules in the kernel build system, > which do *not* depend on rsync. > > Maybe check with the kernel community first, verifying that this new > build dependency was in fact intended? At the very least, that should > result in a patch to Documentation/process/changes.rst making this > explicit. > As neoraider mentioned on github [1] is doesn't look unintended, also the PR [2] seems to be welcome. Sven 1 - https://github.com/freifunk-gluon/gluon/commit/ 0d616ff2d4cd0a78410ccd993eebdc12d9ecf97f#commitcomment-42864694 2 - https://marc.info/?l=linux-doc=160159054823006=2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] build, imagebuilder: Do not require compilers
The buildroot and SDK both require the compilers (gcc, g++) to be
installed on the host system, however the ImageBuilder uses precompiled
binaries.
This patch changes the prerequirements checks to skip the checking for
the compilers if running as ImageBuilder. A similar change has been
made for libncurses-dev in 4a1a58a3e2d2.
Signed-off-by: Sven Roederer
---
include/prereq-build.mk | 4
1 file changed, 4 insertions(+)
diff --git a/include/prereq-build.mk b/include/prereq-build.mk
index 4637c6ca50..f67a01299e 100644
--- a/include/prereq-build.mk
+++ b/include/prereq-build.mk
@@ -26,6 +26,7 @@ $(eval $(call TestHostCommand,proper-umask, \
Please build with umask 022 - other values produce broken packages, \
umask | grep -xE 0?0[012][012]))
+ifndef IB
$(eval $(call SetupHostCommand,gcc, \
Please install the GNU C Compiler (gcc) 4.8 or later, \
$(CC) -dumpversion | grep -E '^(4\.[8-9]|[5-9]\.?|10\.?)', \
@@ -37,7 +38,9 @@ $(eval $(call TestHostCommand,working-gcc, \
it appears to be broken, \
echo 'int main(int argc, char **argv) { return 0; }' | \
gcc -x c -o $(TMP_DIR)/a.out -))
+endif
+ifndef IB
$(eval $(call SetupHostCommand,g++, \
Please install the GNU C++ Compiler (g++) 4.8 or later, \
$(CXX) -dumpversion | grep -E '^(4\.[8-9]|[5-9]\.?|10\.?)', \
@@ -50,6 +53,7 @@ $(eval $(call TestHostCommand,working-g++, \
echo 'int main(int argc, char **argv) { return 0; }' | \
g++ -x c++ -o $(TMP_DIR)/a.out - -lstdc++ && \
$(TMP_DIR)/a.out))
+endif
ifndef IB
$(eval $(call TestHostCommand,ncurses, \
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath79: move 8/32 boards to tiny subtarget
Am Sonntag, 20. September 2020, 15:32:52 CEST schrieb Sven Roederer: > > Actually, this narrows down to a question that struck me several times > > already: > > > > Now, that 4 MB flash devices are not "supported" anymore, how should we > > deal with the "tiny" subtargets: > > > > 1. We keep the tiny subtargets configured for low flash, so people still > > trying to build 4 MB flash devices still can use this. (This will also > > benefit a few devices with kernel size restrictions; however, this is a > > much smaller set than in earlier times; most of these devices have > > dual-stage bootloaders now or died anyway). > > > > 2. We convert the tiny targets to low-memory targets; this will improve > > the > > situation for a few devices (like you mentioned), but will make it much > > harder to still build the 4M flash devices without major changes. Apart > > from ath79, I don't know whether this would make sense for other targets > > like the old subtargets on ramips. This poses the risk of having some > > targets low-mem and some small-flash, which I'd like to avoid. > > Additionally, we will have to change back from low-mem to small-flash > > again > > when we start to hit limits with the 8M devices. > > > > 3. Though not intended by this conversation, the third option is obviously > > to just ignore all 4M or 32M devices from now on (as actually announced by > > the 4/32 warning), and design the tiny targets based on the requirements > > of > > the 8M devices that will start to become a "problem" soon (either due to > > kernel size restrictions or because of small rootfs). Actually, we already > > went into this direction by using wpad-basic-wolfssl on tiny targets as > > well. > > Adrian, > > thanks for reminding that 4/32 have be planned to phase out after 19.07. > This will or have to be done in the near future. > Reading your points my quick idea was: "Moving the 4/32 and 8/32 to the > tiny- target for 20.xx and removing this target after 20.xx bramch-off". > This shows clearly for 20.xx what will happen soon and the user can prepare > for this finally. The code can possibly also cahnged to take more advantage > of "low_mem" and "small_flash" flags for the "next 8/64 round". > regarding yout concerns that mixing 4/32 and 8/32 will make some more > devices not usable I think like: this will break probably some 4/32 on > tiny, but will make some 8/32 more usable. As the 4/32 warning is around > fror some years now, nobody should be really surprised that the boards > "dying" and that the 4/32 boards dying before the 8/32. > > Best Sven An alternative might be to consolidate all Low_Mem and Small_Flash boards to tiny for 20.xx and set them to source-only after branching 20.xx. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath79: move 8/32 boards to tiny subtarget
Fernando, I'm only talking on the boards having 32MB RAM. This includes 4MB / 8MB flash boards. I'm not having the 8/64 boards in mind. They are fine and should work for some furture releases Sven Am Montag, 21. September 2020, 00:24:00 CEST schrieb Fernando Frediani: > I have some concern to call tiny the 8/32 boards. > While I understand the 4MB flash devices as phased out the 8/32 are > still very popular and probably most of the devices still running in > many and many places and they are not really tiny as of today. Some > newer low priced are coming with 8/64, but the point is that OpenWrt has > been the responsible for many devices to keep going for years with > stability and this no doubt will happen with 8/32 for a while. > Calling tiny means only 8MB flash or both 8MB flash and 32MB ram ? I may > see a point to call the 8MB devices maybe, but not 32MB ram ones. > > Fernando > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath79: move 8/32 boards to tiny subtarget
Am Sonntag, 20. September 2020, 00:21:44 CEST schrieb Adrian Schmutzler: > > Indeed "LOW_MEMORY_FOOTPRINT" seems only to affedt 3 general options > > and one option of OpenSSL. > > > > So it might be an option to : > > * set LOW_MEM for 8/32 MB devies > > * set LOW_MEM and SMALL_FLASH for 4/32 MB devices > > * check the CONFIG-options for usefull defaults So the tiny aubtarget can > > be defined as "boards with 32MB or less of RAM; some boards also with > > only 4MB of flash". This definition would essentially match the "4/32 > > warning" [1]. > Actually, this narrows down to a question that struck me several times > already: > > Now, that 4 MB flash devices are not "supported" anymore, how should we deal > with the "tiny" subtargets: > > 1. We keep the tiny subtargets configured for low flash, so people still > trying to build 4 MB flash devices still can use this. (This will also > benefit a few devices with kernel size restrictions; however, this is a > much smaller set than in earlier times; most of these devices have > dual-stage bootloaders now or died anyway). > > 2. We convert the tiny targets to low-memory targets; this will improve the > situation for a few devices (like you mentioned), but will make it much > harder to still build the 4M flash devices without major changes. Apart > from ath79, I don't know whether this would make sense for other targets > like the old subtargets on ramips. This poses the risk of having some > targets low-mem and some small-flash, which I'd like to avoid. > Additionally, we will have to change back from low-mem to small-flash again > when we start to hit limits with the 8M devices. > > 3. Though not intended by this conversation, the third option is obviously > to just ignore all 4M or 32M devices from now on (as actually announced by > the 4/32 warning), and design the tiny targets based on the requirements of > the 8M devices that will start to become a "problem" soon (either due to > kernel size restrictions or because of small rootfs). Actually, we already > went into this direction by using wpad-basic-wolfssl on tiny targets as > well. > Adrian, thanks for reminding that 4/32 have be planned to phase out after 19.07. This will or have to be done in the near future. Reading your points my quick idea was: "Moving the 4/32 and 8/32 to the tiny- target for 20.xx and removing this target after 20.xx bramch-off". This shows clearly for 20.xx what will happen soon and the user can prepare for this finally. The code can possibly also cahnged to take more advantage of "low_mem" and "small_flash" flags for the "next 8/64 round". regarding yout concerns that mixing 4/32 and 8/32 will make some more devices not usable I think like: this will break probably some 4/32 on tiny, but will make some 8/32 more usable. As the 4/32 warning is around fror some years now, nobody should be really surprised that the boards "dying" and that the 4/32 boards dying before the 8/32. Best Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath79: move 8/32 boards to tiny subtarget
Hello David, Am Freitag, 18. September 2020, 09:44:10 CEST schrieb David Bauer: > Hello Sven, > > On 9/18/20 1:27 AM, Sven Roederer wrote: > > Adrian, David, > > > > Am Mittwoch, 16. September 2020, 16:15:42 CEST schrieb David Bauer: > >> Hi, > >> > >> On 9/16/20 11:40 AM, Adrian Schmutzler wrote: > >>>> -Original Message- > >>>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > >>>> On Behalf Of Sven Roederer > >>>> Sent: Mittwoch, 16. September 2020 09:17 > >>>> To: openwrt-devel@lists.openwrt.org > >>>> Subject: ath79: move 8/32 boards to tiny subtarget > >>>> > >>>> Hi, > >>>> > >>>> not sure if this has been discussed before. > >>>> I recently worked with some 8/32 boards (Ubiquiti Nanostation M (XM), > >>>> TPLink > >>>> WR842 v2) for our Freifunk-project and realized that the low RAM > >>>> situation > >>>> requires quite different handling than the full boards (8+/64+). > >>>> > >>>> I wonder if there is a reason to not move the boards, which are > >>>> affected > >>>> by > >>>> the 4/32MB warning also, to the ath79-tiny target? > >>> > >>> I wonder whether the tiny subtarget will actually make much difference > >>> for > >>> RAM issues? > > > > My idea based on the fact, to have an easy way to disable certain kernel- > > features to reduce teh kernel-size (in flash and RAM). Candidates I see > > here are: USB-Support, additional filesystems, block-devices, ... > > Even some devices provide USB-connectors it might be better to have less > > OOM- crashes and reboots than installing a usb-flashdrive. In our > > Freifunk-Firmware I've seen much less runtime-problems with a stripped > > down kernel. > > With having the 8/32 in tiny it would just be a config-file for the > > low-RAM > > boards. Having them in generic subtarget would require to build 2 kernels > > for the same subtarget. > > > >> In it's current state, it will most likely increase low-memory issues as > >> the squashfs blocksize is 1024kB compared to the regular 256kB. Not that > >> ath79-tiny has no target-flag for small memory set. > > > > Did you miss an "e" ? "Note that ath79-tiny has ..." gives more sense to > > me. Reading it this way, you expect the larger blocksize was choosen as > > tradeoff between using the flash most efficient vs. RAM for the 4/32 > > boards? I've seen there is a low_mem flag for some 16MB boards defined. > > It seems that for some config-options SMALL_FLASH and LOW-MEM are > > conflicting. > > Yes, there was an e missing. > > We've experienced severe system instabilities with larger blocksizes (the > default one for ar71xx-tiny to be precise) downstream. [0] [1] > > However, In my opinion the blocksize upstream works well for people looking > for a home router, as memory consumption is typically lower and some > additional space is desirable there. > For that reason Freifunk-Gluon and Freifunk-Berlin use the non-default value. Esp. for the routing-daemons these project need more RAM for apps running. > I could also imagine the low-mem target feature and It's configuration > implications have to be assessed as a whole, given it did not experience > much use for a longer period of time. > Indeed "LOW_MEMORY_FOOTPRINT" seems only to affedt 3 general options and one option of OpenSSL. So it might be an option to : * set LOW_MEM for 8/32 MB devies * set LOW_MEM and SMALL_FLASH for 4/32 MB devices * check the CONFIG-options for usefull defaults So the tiny aubtarget can be defined as "boards with 32MB or less of RAM; some boards also with only 4MB of flash". This definition would essentially match the "4/32 warning" [1]. [1] - https://openwrt.org/supported_devices/432_warning Sven > [0] https://github.com/freifunk-gluon/gluon/issues/2032 > [1] > https://github.com/freifunk-gluon/gluon/commit/7e8af99cf504ca1dc389f282a0c9 > 4f4a911571be > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: zram-swap: default to lzo instead of lzo-rle compression
Am Donnerstag, 17. September 2020, 11:38:42 CEST schrieb e9hack: >The kernel module lzo-rle is still missing. To solve this, it must be > installed on the root-fs: > > diff --git a/package/kernel/linux/modules/lib.mk > b/package/kernel/linux/modules/lib.mk index 1289cc1f25..fade8a5cfd 100644 > --- a/package/kernel/linux/modules/lib.mk > +++ b/package/kernel/linux/modules/lib.mk > @@ -109,9 +109,10 @@ define KernelPackage/lib-lzo >HIDDEN:=1 >FILES:= \ > $(LINUX_DIR)/crypto/lzo.ko \ > + $(LINUX_DIR)/crypto/lzo-rle.ko@ge5.1 \ > $(LINUX_DIR)/lib/lzo/lzo_compress.ko \ > $(LINUX_DIR)/lib/lzo/lzo_decompress.ko > - AUTOLOAD:=$(call AutoProbe,lzo lzo_compress lzo_decompress) > + AUTOLOAD:=$(call AutoProbe,lzo lzo-rle lzo_compress lzo_decompress) > endef > Hartmut, I had a short test wit zram-swap these days and also saw this. I fixed this by changing the default compression-algo to lzo via etc/config/ system. My intention was not to use an additional kernel-module which will consume additional RAM which I just won by using zram ... (Indeed I did not check the numbers and only assumed) Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ath79: move 8/32 boards to tiny subtarget
Adrian, David, Am Mittwoch, 16. September 2020, 16:15:42 CEST schrieb David Bauer: > Hi, > > On 9/16/20 11:40 AM, Adrian Schmutzler wrote: > >> -Original Message- > >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > >> On Behalf Of Sven Roederer > >> Sent: Mittwoch, 16. September 2020 09:17 > >> To: openwrt-devel@lists.openwrt.org > >> Subject: ath79: move 8/32 boards to tiny subtarget > >> > >> Hi, > >> > >> not sure if this has been discussed before. > >> I recently worked with some 8/32 boards (Ubiquiti Nanostation M (XM), > >> TPLink > >> WR842 v2) for our Freifunk-project and realized that the low RAM > >> situation > >> requires quite different handling than the full boards (8+/64+). > >> > >> I wonder if there is a reason to not move the boards, which are affected > >> by > >> the 4/32MB warning also, to the ath79-tiny target? > > > > I wonder whether the tiny subtarget will actually make much difference for > > RAM issues? My idea based on the fact, to have an easy way to disable certain kernel- features to reduce teh kernel-size (in flash and RAM). Candidates I see here are: USB-Support, additional filesystems, block-devices, ... Even some devices provide USB-connectors it might be better to have less OOM- crashes and reboots than installing a usb-flashdrive. In our Freifunk-Firmware I've seen much less runtime-problems with a stripped down kernel. With having the 8/32 in tiny it would just be a config-file for the low-RAM boards. Having them in generic subtarget would require to build 2 kernels for the same subtarget. > In it's current state, it will most likely increase low-memory issues as the > squashfs blocksize is 1024kB compared to the regular 256kB. Not that > ath79-tiny has no target-flag for small memory set. > Did you miss an "e" ? "Note that ath79-tiny has ..." gives more sense to me. Reading it this way, you expect the larger blocksize was choosen as tradeoff between using the flash most efficient vs. RAM for the 4/32 boards? I've seen there is a low_mem flag for some 16MB boards defined. It seems that for some config-options SMALL_FLASH and LOW-MEM are conflicting. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ath79: move 8/32 boards to tiny subtarget
Hi, not sure if this has been discussed before. I recently worked with some 8/32 boards (Ubiquiti Nanostation M (XM), TPLink WR842 v2) for our Freifunk-project and realized that the low RAM situation requires quite different handling than the full boards (8+/64+). I wonder if there is a reason to not move the boards, which are affected by the 4/32MB warning also, to the ath79-tiny target? Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: tplink-safeloader support-list on CPE/WBS devices
Am Sonntag, 30. August 2020, 22:43:32 CEST schrieb Adrian Schmutzler: > Hi, > > while increasing the kernel partition for the TP-Link CPE devices, I found > that the partitions called "soft-version" and "support-list" are handled as > a part of the file-system/firmware partition, in contrast to all other > tplink-safeloader devices where it is part of a read-only partition. > Examples: Adrian, some days ago I also found this and started to wonder. I came along this by realizing, that some of the TPLink CPe fail to create .factory and .sysupgrade images as of "os-image to big". Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] build, imagebuilder: Do not require libncurses-dev
Am Dienstag, 14. April 2020, 23:14:47 CEST schrieb Paul Spooren:
> The buildroot and SDK both require `libncurses-dev` to be installed on
> the system, however the ImageBuilder uses precompiled binaries.
>
> This patch changes the prerequirements checks to skip the
> `libncurses-dev` part if running as ImageBuilder.
>
Hi Paul,
I gave this today a test on my spare computer, but it still complained about
the missing libncurses.
I tested with snapshot imagebuilder (r13519-8a858363b0) with just calling
"make image"
Any ideas?
Sven
> Signed-off-by: Paul Spooren
> ---
> include/prereq-build.mk | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/prereq-build.mk b/include/prereq-build.mk
> index 830a9eff9a..72fb6ad97a 100644
> --- a/include/prereq-build.mk
> +++ b/include/prereq-build.mk
> @@ -51,10 +51,12 @@ $(eval $(call TestHostCommand,working-g++, \
> g++ -x c++ -o $(TMP_DIR)/a.out - -lstdc++ && \
> $(TMP_DIR)/a.out))
>
> +ifndef IB
> $(eval $(call TestHostCommand,ncurses, \
> Please install ncurses. (Missing libncurses.so or ncurses.h), \
> echo 'int main(int argc, char **argv) { initscr(); return 0; }' | \
> gcc -include ncurses.h -x c -o $(TMP_DIR)/a.out - -lncurses))
> +endif
>
> ifeq ($(HOST_OS),Linux)
>zlib_link_flags := -Wl,-Bstatic -lz -Wl,-Bdynamic
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] olsrd: not compiling with gcc 9
Am Sonntag, 7. Juni 2020, 23:39:08 CEST schrieb Rosen Penev:
> > Le 7 juin 2020 à 1:38 PM, Nick a écrit :
> >
> > I would suggest doing this PR as patch like freifunk berlin is doing it:
> > https://github.com/freifunk-berlin/firmware/commit/93f9a026e025c7b663369f5
> > 284cec0bb91345220
> Someone needs to propose one then.
>
This patch was referenced by an issue (https://github.com/openwrt-routing/
packages/issues/547#issuecomment-586213155), but original author was not
able to runtime-test. In Freifunk Berlin we also don't use the pud-plugin and
can't therefore not confirm it.
> > Otherwise, olsrd won't compile anymore. :/ Or making a fork, because
> > olsrd seems not to be maintained anymore.
> >
I just opened PR #575 to mark this package as broken, till there is a
maintainer again ...
Sven
> >> On 07.06.20 22:27, Nick wrote:
> >> Here is a PR that is fixing the issue. Why is that not merged? :/
> >>
> >> https://github.com/OLSR/olsrd/pull/79/files
> >>
> >> On 07.06.20 22:03, Rosen Penev wrote:
> Le 7 juin 2020 à 1:00 PM, Nick a écrit :
>
> I can not compile olsrd daemon with gcc9.
>
> > #define isNaN(x) (x != x)
> > ...
> > if (!isNaN(gpsdata->fix.time)) {
>
> Here fix.time is a struct timespec.
> The call is just wrong, or? Why should I check a struct for a valid
> float?
> >>>
> >>> This broke when gpsutils got updated. API change with libgps.
> >>>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] building python3 packages outside of lang/python3
Am Freitag, 1. Mai 2020, 20:20:05 CEST schrieb Alexandru Ardelean: > On Fri, May 1, 2020 at 7:04 PM Michael Richardson wrote: > > hi, > > python packages include ../python3-package.mk, and pypi.mk > > > > But I can't do that from my own feed directory. > > I don't want to copy the file!! > > > > Is there a relative path that would get me to feeds/packages/lang/python3? > > long-story-short: no > > you'll have to settle for some sort of absolute path if you need those > files from the packages feed in some other feed > if you take a look at > https://github.com/openwrt/packages/blob/master/lang/python/README.md > there's a suggestion: > PYTHON3_PACKAGE_MK:=$(wildcard > $(TOPDIR)/feeds/*/lang/python/python3-package.mk) [ similar can be done for > pypi.mk ] > We do quite the same in our feed to solve such issue. In addition we have a check that only one match will be returned by $(wildcard). https://github.com/freifunk-berlin/firmware-packages/blob/master/freifunk-berlin-generic.mk LUCIMKFILE:=$(wildcard $(TOPDIR)/feeds/*/luci.mk) # verify that there is only one single file returned ifneq (1,$(words $(LUCIMKFILE))) ifeq (0,$(words $(LUCIMKFILE))) $(error did not find luci.mk in any feed) else $(error found multiple luci.mk files in the feeds) endif endif > reason for the wildcard, is in case the "packages" feed is not named > literally 'packages', it picks up the first feed where that mk file is > found; > if there's only one, all is fine; if there's more than one, then > [anyone doing this] it's asking for trouble anyway; > > now, i've thought [and maybe Jeffery as well] about maybe doing a > helper that makes a short-hand to the python3-package.mk path somehow > [into the 'packages' feed], but there isn't a good reason to do it; > you still need to know exactly in which feed the 'python3-package.mk' > is found; and that helper needs to be done in OpenWrt core; and core > always needs good reasons to be modified; > so, some people do 'include > $(TOPDIR)/feeds/packages/lang/python/python3-package.mk' directly; > [1] > > maybe if [one day] these 2 files move into OpenWrt core, things will > be a bit simpler; but I don't think it's very soon, and I don't feel > it's a big problem [anyway], but that's my opinion; > > > I tried the whole thing, but that didn't work. > > > > I settled on: > > include $(INCLUDE_DIR)/../feeds/packages/lang/python/python3-package.mk > > > > which I found ugly, but it worked. > > yes & no; > you can choose to do a direct include like [1] > Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] dnsmasq: add /etc/dnsmasq.d/ to conffiles
This directory can hold configuration-snippets which should also included in the backup. Signed-off-by: Sven Roederer --- package/network/services/dnsmasq/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/package/network/services/dnsmasq/Makefile b/package/network/services/dnsmasq/Makefile index d07804bad0..24387ca77a 100644 --- a/package/network/services/dnsmasq/Makefile +++ b/package/network/services/dnsmasq/Makefile @@ -10,7 +10,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=dnsmasq PKG_UPSTREAM_VERSION:=2.81 PKG_VERSION:=$(subst test,~~test,$(subst rc,~rc,$(PKG_UPSTREAM_VERSION))) -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_SOURCE:=$(PKG_NAME)-$(PKG_UPSTREAM_VERSION).tar.xz PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq @@ -89,6 +89,7 @@ endef define Package/dnsmasq/conffiles /etc/config/dhcp /etc/dnsmasq.conf +/etc/dnsmasq.d/ endef define Package/dnsmasq-full/config -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] linux5.4: build-dependency to rsync
Hi, I was just building a master-branch for x86-generic and got following error: make[5]: Entering directory '/mnt/local/btrfs/build/freifunk/ffberlin/ firmware/openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/ linux-5.4.28' INSTALL /mnt/local/btrfs/build/freifunk/ffberlin/firmware/openwrt/build_dir/ toolchain-i386_pentium4_gcc-8.4.0_musl/linux-dev//include /bin/sh: 1: rsync: not found make[5]: *** [Makefile:1186: headers_install] Error 127 make[5]: Leaving directory '/mnt/local/btrfs/build/freifunk/ffberlin/firmware/ openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/linux-5.4.28' make[4]: *** [Makefile:108: /mnt/local/btrfs/build/freifunk/ffberlin/firmware/ openwrt/build_dir/toolchain-i386_pentium4_gcc-8.4.0_musl/ linux-5.4.28/.configured] Error 2 make[4]: Leaving directory '/mnt/local/btrfs/build/freifunk/ffberlin/firmware/ openwrt/toolchain/kernel-headers' time: toolchain/kernel-headers/compile#1.46#0.83#2.26 In https://github.com/torvalds/linux/commit/59b2bd05f5f4d the call to rsync was added. I think we have the 2 options: * use host-command (changing the build-requirements) * compile it ourself (like we do with zip: ad8c2d6099a7da51) What's the prefered way? Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] changes in UCI-reply after lede-17.01
Hi, I took out an shell-script that I used on lede-17.01 to work with uci network configuration. The script is iterating over all interfaces an checks for the physical devices attached to it. With lede-17.01 I was able to query the "ifname"-option to get the interfacename and "devices"-option returned the physical-devices of the interface. For regular interfaces "ifname" and "device" are the same, for e.g. bridges "ifname" returned the bridge-name and "devices" the connected interfaces. Log for lede-17.01.7 on a fresh installed board: > root@LEDE:~# sh /tmp/uci-test.sh > checking interface loopback > ifnames:lo > devices:lo > checking interface lan > ifnames:br-lan > devices:eth0 > checking interface wan > ifnames:eth1 > devices:eth1 > checking interface wan6 > ifnames:eth1 > devices:eth1 Since openwrt-18.06+ the "devices"-option always reutrns nothing. Log for openwrt-18.06.8 on a fresh installed board: > root@OpenWrt:~# sh /tmp/uci-test.sh > checking interface loopback > ifnames:lo > devices: > checking interface lan > ifnames:br-lan > devices: > checking interface wan > ifnames:eth1 > devices: > checking interface wan6 > ifnames:eth1 > devices: I wonder how to lookup the interfaces connected to a bridge? It the absence of the "devices"-option by intention? Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Is it possible to create two images for the same device with a different set of DEVICE_PACKAGES?
Am Dienstag, 7. April 2020, 16:22:37 CEST schrieb Hannu Nyman: > I do not think that there is a nice clean solution, as I do not remember > seeing a solution of different packages for iniramfs, factory and sysupgrade > images. > > I would approach that with a two-step build process, using two .config > recipes: > > * First a build with a smaller .config recipe without that large Quantenna > firmware. This creates the initramfs image, (which you copy to a safe place > before the second build) > > * Then a second build from a recipe including the Quantenna firmware. No > need to do "make clean", so the second build is rather quick. That produces > the full sysupgrade image. > > In your build automation scripts, those two builds could be run > consequtively, with a copy step between them. > For our Freifunk-build we do a similar 2-step thing * using a .config having all pacakges added modular and only the packages for the initrd set to "y" to have them embedded * doing a normal build produces the initrds and the imagebuilder * with the imagebuilder we generate the final sysupgrade images with the full package-set The generated initrds are just a luci-mod-failsafe wich allows flashing the sysupgrade via browser and of course console. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [19.07] kernel: avoid underscore in *6lowpan package names
Am Dienstag, 18. Februar 2020, 21:47:20 CET schrieb Eneas U de Queiroz: > Packages kmod-bluetooth_6lowpan and kmod-ieee802154_6lowpan contain an > underscore in the package name. This causes problems in package/install > because when building a list of package files to install offline using > opkg, it uses a wildcard of the form $(dir)/$(pkg)_*.ipk. > > If you were to select kmod-bluetooth=y, but kmod-bluetooth_6lowpan=m, > the latter would be picked up by that wildcard, and make package/install > would fail: > Hi, this patch was added in 07e1d88d7beb43a4152460b82976dbe49919b264. The same problem exists for 19.07. Can somebody cherry-pick this? Thanks Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [19.07] backport "build: have scripts/feeds honor all toplevel .mk-files of a feed"
Am Freitag, 27. Dezember 2019, 21:42:09 CET schrieb devel-s...@geroedel.de: > Hi, > > can anyone cherry-pick b81cee86e63d4421072839ec8a3780d8afff9337 to 19.07 > ? > This commit was added to master in Oct 2019. Picking this to 19.07 would also here in this release. Or do you expect any issues caused by this change? Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 19.07] ath79: add support for gl-ar750
Paul, Am Samstag, 14. Dezember 2019, 00:10:28 CET schrieb Paul Fertser: > Also, if you're going to improve the patch, I've noticed you have no > DTS designations for how the LEDs are to be used (aliases for led-boot > etc) and no label_mac assignment. Not sure if that's important. As the router is in a hidden location, I never checked the Leds ... Probably I should. But at least the board is running stable for me. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 19.07] ath79: add support for gl-ar750
Am Freitag, 13. Dezember 2019, 21:07:23 CET schrieb Paul Fertser: > Hello, > > On Fri, Dec 13, 2019 at 08:50:46PM +0100, Sven Roederer wrote: > > .../ath79/base-files/etc/board.d/02_network | 5 + > > .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 + > > .../ath79/dts/qca9531_glinet_gl-ar750.dts | 142 ++ > > target/linux/ath79/image/generic.mk | 9 ++ > > Is this not missing the additions to board.d/01_leds ? Paul, good point. But also on master seems to be no entry for this board in "01_leds". So I assume the default case fits for it. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 19.07] ath79: add support for gl-ar750
Adrian, it's just that I've this patch around for some time, as I use this device on 19.07. So just sharing this patch ... Sven Am Freitag, 13. Dezember 2019, 21:21:14 CET schrieb Adrian Schmutzler: > Hi Sven, > > so, the primary question remains unanswered: Why should exactly this device > be backported (out of the big set of devices only in master)? > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 19.07] ath79: add support for gl-ar750
From: Luochongjun
This patch supports gl-ar750, which was previously supported by ar71xx.
Specification:
- SOC: QCA9531 (650MHz)
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 128 MiB DDR2
- Ethernet: 10/100: 2xLAN + 10/100: 1xWAN
- Wireless: 2.4GHz (bgn) and 5GHz (ac)
- USB: 1x USB 2.0 port
- Switch: 1x switch
- Button: 1x reset button
- LED: 3x LEDS (white)
Flash instruction:
Support for sysupgrade directive upgrades, as well as luci upgrades.
Signed-off-by: Luochongjun
(cherry picked from commit 921675a2d148330a7ec44f10ea4d583b8d7b5a44)
[backported to 19.07]
Signed-off-by: Sven Roederer
---
.../ath79/base-files/etc/board.d/02_network | 5 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
.../ath79/dts/qca9531_glinet_gl-ar750.dts | 142 ++
target/linux/ath79/image/generic.mk | 9 ++
4 files changed, 157 insertions(+)
create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index 82c1e09981..41c8e37e31 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -128,6 +128,11 @@ ath79_setup_interfaces()
etactica,eg200)
ucidef_set_interface_lan "eth0" "dhcp"
;;
+ glinet,gl-ar750)
+ ucidef_set_interface_wan "eth1"
+ ucidef_add_switch "switch0" \
+ "0@eth0" "1:lan" "2:lan"
+ ;;
glinet,gl-ar750s)
ucidef_add_switch "switch0" \
"0@eth0" "2:lan:2" "3:lan:1" "1:wan"
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index d1f529fde5..cf28c474b1 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -117,6 +117,7 @@ case "$FIRMWARE" in
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat
/sys/class/net/eth0/address) +1)
;;
+ glinet,gl-ar750|\
glinet,gl-ar750s)
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0)
+1)
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
new file mode 100644
index 00..54aad320f6
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "qca953x.dtsi"
+
+/ {
+ compatible = "glinet,gl-ar750", "qca,qca9531";
+ model = "GL.iNet GL-AR750";
+
+ keys {
+ compatible = "gpio-keys";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_disable_pins>;
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
+
+ mode {
+ label = "mode";
+ linux,code = ;
+ gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ power {
+ label = "gl-ar750:white:power";
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+
+ wlan2g {
+ label = "gl-ar750:white:wlan2g";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "phy1tpt";
+ };
+
+ wlan5g {
+ label = "gl-ar750:white:wlan5g";
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "phy0tpt";
+ };
+
+ };
+
+ i2c {
+ compatible = "i2c-gpio";
+
+ sda-gpios = < 17 GPIO_ACTIVE_LOW>;
+ scl-gpios = < 16 GPIO_ACTIVE_LOW>;
+ };
+
+
+};
+
+ {
+ status = "okay";
+
+ wifi@0,0 {
+ compatible = "qcom,ath10k";
+ reg = <0 0 0 0 0>;
+ device_type = "pci";
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_phy {
+ status = "
[OpenWrt-Devel] [PATCH] ipq40xx: fritz4040 depends on uboot-fritz4040
The "append-uboot" macro is looking for the file "$(STAGING_DIR_IMAGE)/uboot-fritz4040.bin" which is provided by the u-boot-fritz4040 package. If this is not build, image creation will fail with "file not found". Signed-off-by: Sven Roederer --- target/linux/ipq40xx/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/ipq40xx/image/Makefile b/target/linux/ipq40xx/image/Makefile index a9c5e625af..7ae6f36baa 100644 --- a/target/linux/ipq40xx/image/Makefile +++ b/target/linux/ipq40xx/image/Makefile @@ -130,7 +130,7 @@ define Device/avm_fritzbox-4040 IMAGES = eva.bin sysupgrade.bin IMAGE/eva.bin := append-uboot | pad-to (UBOOT_PARTITION_SIZE) | append-kernel | append-rootfs | pad-rootfs IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata - DEVICE_PACKAGES := fritz-tffs fritz-caldata + DEVICE_PACKAGES := fritz-tffs fritz-caldata u-boot-fritz4040 endef TARGET_DEVICES += avm_fritzbox-4040 -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
