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 <[email protected]> >> To: Daniel Golle <[email protected]>, [email protected] >> Cc: [email protected] >> 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 [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
