[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Hi Sven, yes this is very useful. I will try to test it this week and report
back.
Thanks!
SAn
On 11/23/20 1:30 PM, Sven Eckelmann wrote:
> On Monday, 3 August 2020 00:49:40 CET SAn via openwrt-devel wrote:
>> The LibreRouter uses a dual-boot scheme that relies on the bootloader
>> configuring the kernel cmdline. At ar71xx 18.06 it was possible to select
>> per device if the cmdline from the bootloader has to be honored (using
>> patch-cmdline).
>> AFAIK there is no such possibility on ath79.
>
> There should be the possibility to fix this by dropping the bootargs property
> from the /chosen/ node. But the MIPS kernel code had a bug which was recently
> fixed upstream [1]. The fix must still be integrated [2] into OpenWrt.
>
> The only code necessary in the dts is:
>
> / {
> chosen {
> /delete-property/ bootargs;
> };
> };
>
> I hope this helps you.
>
> Kind regards,
> Sven
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7784cac697351f0cc0a4bb619594c0c99348c5aa
> [2] (pending because I have to walk to the office to pick up my P300 test
> devices)
>
> https://github.com/ecsv/openwrt/commit/6e4750615dee12c3fd8ce14174fd91fc18fac498
>
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Daniel On 8/5/20 6:04 AM, Daniel Golle wrote: > On Tue, Aug 04, 2020 at 08:35:26PM -0300, SAn via openwrt-devel wrote: >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. > >> Date: Tue, 4 Aug 2020 20:35:26 -0300 >> From: SAn >> To: Daniel Golle , s@gmx.de >> Cc: openwrt-devel@lists.openwrt.org >> Subject: Re: your mail >> >> Hi Stefan and Daniel, >> >> On 8/2/20 8:19 PM, Daniel Golle wrote: >>> On Sun, Aug 02, 2020 at 07:49:40PM -0300, SAn via openwrt-devel wrote: >>>> Subject: ath79 subtarget with cmdline from bootloader >>>> >>>> Hi! >>>> >>>> The LibreRouter uses a dual-boot scheme that relies on the bootloader >>>> configuring the kernel cmdline. At ar71xx 18.06 it was possible to select >>>> per device if the cmdline from the bootloader has to be honored (using >>>> patch-cmdline). >>>> AFAIK there is no such possibility on ath79. >>>> >>>> Would you consider accepting a patch that adds a new ath79 subtarget with >>>> CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (or >>>> CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)? >>>> >>>> It would be valuable for the people using LibreRouter devices to be able >>>> to use official OpenWrt 20.xx images with the dual-boot support. Currently >>>> there are multiple mips targets that use >>>> CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (bcm47xx, octeon, malta, and a few >>>> more). >>> >>> I don't think this justifies an extra subtarget just for the sake of >>> having the kernel process cmdline arguments passed by an outdated >>> (ie. non-DT, non-FIT) bootloader. >>> If it really has to be that way (and eg. parsing uboot-env cannot be >>> used instead and bootloader cannot be updated to properly pass this >> . >> >> Another bootloader can be used, but I am not aware of a newer one with >> QCA955x support, do you? The last time I checked u-boot there was upstream >> support to qca956x and qca953x. Adding support to 955x seemed to me a lot of >> work (there are thousands of undocumented constants everywhere in the code), >> but maybe I am mistaken? >> >> I did not understand the "parsing uboot-env". Can you expand on this please? >> :) > > You can hack a MTD partition parser(/-splitter) which evaluates the > U-Boot environment and according to what it finds there sets partition > names accordingly (ie. swap firmware with firmware2, then 'firmware' > will be split into 'kernel' and 'rootfs' during boot). > For sysupgrade you can then always use firmware2 (ie. the currently > unused image) and toggle which image to load on boot by default (eg. > by using fw_setenv) > How does librerouter's vendor U-Boot decide which image to boot? If I understand you, that is how it is done at the moment, here [0] is documented. Or are you saying to read this u-boot env from the kernel itself to find out the mtd particions? >> >>> in dtb), I guess something along the lines of >>> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE >>> could work (would have to be implemented for MIPS first, obviously) >> >> If there is no other viable way I would go this way.. >> Thanks Stefan for the pointers to the patches! >> >>> Alternatively, as a quick-and-dirty workaround, just move the whole >>> librerouter.dts into a .dtsi and then have two .dts files referecing >>> them, each setting different cmdline. Then generate two images. >>> That'd be the same effect as what patch-cmdline used to do on non-DT >>> targets. >>> >> >> I think this is too complicated for end users. Maybe a friendlier way could >> be to pack both images into a tarfile and then use the correct one from a >> userspace tool to perform the upgrade. > > How have you been managing this on ar71xx until now? >From the fork [1] we just don't have the patch-cmdline in the kernel for the >device, so the kernel load the mtd from the cmdline. So until now only images >provided by our fork can be installed properly using dual-boot. Official >OpenWrt images can be installed only in the first partition (and if usins >sysupgrade only from the first firmware partition also). [0] https://github.com/libremesh/lime-packages/blob/master/packages/safe-upgrade/Readme.md#how-safe-upgrade-works [1] https://gitlab.com/librerouter/librerouteros Thanks SAn --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Stefan and Daniel, On 8/2/20 8:19 PM, Daniel Golle wrote: > On Sun, Aug 02, 2020 at 07:49:40PM -0300, SAn via openwrt-devel wrote: >> Subject: ath79 subtarget with cmdline from bootloader >> >> Hi! >> >> The LibreRouter uses a dual-boot scheme that relies on the bootloader >> configuring the kernel cmdline. At ar71xx 18.06 it was possible to select >> per device if the cmdline from the bootloader has to be honored (using >> patch-cmdline). >> AFAIK there is no such possibility on ath79. >> >> Would you consider accepting a patch that adds a new ath79 subtarget with >> CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (or CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)? >> >> It would be valuable for the people using LibreRouter devices to be able to >> use official OpenWrt 20.xx images with the dual-boot support. Currently >> there are multiple mips targets that use CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER >> (bcm47xx, octeon, malta, and a few more). > > I don't think this justifies an extra subtarget just for the sake of > having the kernel process cmdline arguments passed by an outdated > (ie. non-DT, non-FIT) bootloader. > If it really has to be that way (and eg. parsing uboot-env cannot be > used instead and bootloader cannot be updated to properly pass this . Another bootloader can be used, but I am not aware of a newer one with QCA955x support, do you? The last time I checked u-boot there was upstream support to qca956x and qca953x. Adding support to 955x seemed to me a lot of work (there are thousands of undocumented constants everywhere in the code), but maybe I am mistaken? I did not understand the "parsing uboot-env". Can you expand on this please? :) > in dtb), I guess something along the lines of > CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE > could work (would have to be implemented for MIPS first, obviously) If there is no other viable way I would go this way.. Thanks Stefan for the pointers to the patches! > Alternatively, as a quick-and-dirty workaround, just move the whole > librerouter.dts into a .dtsi and then have two .dts files referecing > them, each setting different cmdline. Then generate two images. > That'd be the same effect as what patch-cmdline used to do on non-DT > targets. > I think this is too complicated for end users. Maybe a friendlier way could be to pack both images into a tarfile and then use the correct one from a userspace tool to perform the upgrade. Thanks for the help! SAn --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi! The LibreRouter uses a dual-boot scheme that relies on the bootloader configuring the kernel cmdline. At ar71xx 18.06 it was possible to select per device if the cmdline from the bootloader has to be honored (using patch-cmdline). AFAIK there is no such possibility on ath79. Would you consider accepting a patch that adds a new ath79 subtarget with CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (or CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)? It would be valuable for the people using LibreRouter devices to be able to use official OpenWrt 20.xx images with the dual-boot support. Currently there are multiple mips targets that use CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (bcm47xx, octeon, malta, and a few more). Best! SAn --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] proc: cancel script killing only if process ends
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi ynezz thanks for bringing this conversation to the list! On 2/11/20 10:44 AM, Petr Štetiar wrote: > Santiago Piccinini [2019-10-10 18:35:53]: > > Hi, > >> Before this change if the cgi script hangs after writing headers >> then the process will never be killed. Let's only cancel the timeout >> if the process ends. > > < jow> well it is a change in behaviour > < jow> the proper solution would be introducing a separate read timeout I > guess. Thats how other servers handle it > < jow> one timeout until the first content, then another body read timeout The rationale behind adding another timeout is to maintain behavior (using an infinite default timeout for the new timeout) ? In my opinion another timeout adds more complexity than value if backwards compatibility is not taken in consideration. Anyhow, I can implement separate timeouts but if the patch will be accepted. Maybe something like script_timeout_abort or script_abort_timeout for the name? Best! SAn --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] proc: cancel script killing only if process ends
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi! I forgot to mention that this patch is for uhttpd. Best! SAn --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
