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 ---
The updated procd did actually allow the upgrade to proceed:


root@OpenWrt:~# sysupgrade -v 
openwrt-brcm2708-bcm2711-rpi-4-squashfs-sysupgrade.img.gz 
Image not in /tmp, copying...
Reading partition table from bootdisk...
Reading partition table from image...
Saving config files...
boot/config.txt
etc/config/dhcp
etc/config/dropbear
etc/config/firewall
etc/config/network
etc/config/system
etc/config/wireless
etc/dropbear/dropbear_rsa_host_key
etc/group
etc/hosts
etc/inittab
etc/opkg/keys/0b26f36ae0f4106d
etc/opkg/keys/1035ac73cc4e59e3
etc/opkg/keys/5151f69420c3f508
etc/opkg/keys/72a57f2191b211e0
etc/opkg/keys/792d9d9b39f180dc
etc/opkg/keys/9ef4694208102c43
etc/opkg/keys/b2d571e0880ff617
etc/opkg/keys/b5043e70f9a75cde
etc/opkg/keys/c10b9afab19ee428
etc/opkg/keys/dace9d4df16896bf
etc/opkg/keys/dd6de0d06bbd3d85
etc/opkg/keys/f94b9dd6febac963
etc/passwd
etc/profile
etc/rc.local
etc/shadow
etc/shells
etc/sysctl.conf
Commencing upgrade. Closing all shell sessions.
-> 7b93da68 #7b93da68          hello: {}
<- 7b93da68 #00000000         lookup: {"objpath":"system"}
-> 7b93da68 #00000000           data: 
{"objpath":"system","objid":-672961887,"objtype":-575613211,"signature":{"board":{},"info":{},"reboot":{},"watchdog":{"frequency":5,"timeout":5,"magicclose":7,"stop":7},"signal":{"pid":5,"signum":5},"validate_firmware_image":{"path":3},"sysupgrade":{"path":3,"force":7,"backup":3,"prefix":3,"command":3,"options":2}}}
-> 7b93da68 #00000000         status: {"status":0}
<- 7b93da68 #d7e36aa1         invoke: 
{"objid":-672961887,"method":"sysupgrade","data":{"prefix":"/tmp/root","path":"/tmp/sysupgrade.img","backup":"/tmp/sysupgrade.tgz","command":"/lib/upgrade/do_stage2","options":{"save_partitions":1}}}
-> 13c8230f #7b93da68         invoke: 
{"objid":-672961887,"method":"sysupgrade","data":{"prefix":"/tmp/root","path":"/tmp/sysupgrade.img","backup":"/tmp/sysupgrade.tgz","command":"/lib/upgrade/do_stage2","options":{"save_partitions":1}},"user":"root","group":"root"}
Connection to 172.30.31.233 closed by remote host.



r11869-a176f8d3ec


Then using this current development snapshot it has failed again, and then 
again with just updating procd it has worked correctly. So the problem seems to 
be in procd (or interaction of procd with something else - such as libubox).


— PN

> On 1 Jan 2020, at 13:44, Petr Štetiar <yn...@true.cz> wrote:
> 
> Petr Novák <pe...@me.com> [2019-12-31 14:56:13]:
> 
> I was suspecting some issue in jshn, which empowers the json_dump command, but
> it seems, that the JSON passed from /usr/libexec/validate_firmware_image back
> to validate_firmware_image_call() looks correct:
> 
>> {
>>      "tests": {
>>              "fwtool_signature": true,
>>              "fwtool_device_match": true
>>      },
>>      "valid": true,
>>      "forceable": true,
>>      "allow_backup": true
>> }
> 
> but validate_firmware_image_call() somehow doesn't get/parse it and yields:
> 
>> {
>>      "error": {
>>              "message": "Firmware image couldn't be validated"
>>      }
>> }
> 
> looking at the validate_firmware_image_call() I really don't see anything 
> related to
> libubox which would lead to this error, so can you please try again with more
> verbose version of procd[1]? Thanks!
> 
> 1.  
> https://gitlab.com/ynezz/openwrt/commit/a8db973cc2bcf8d877b939801eba529f29ab7d3a
> 
> -- ynezz



--- End Message ---
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to