Question on zchunk delta update

305 views
Skip to first unread message

Noah Parker

unread,
Oct 15, 2023, 9:02:18 PM10/15/23
to swupdate
Hello,

I am attempting to install a delta update using zchunk. 
I have booted the 2nd root FS partition dev/mmcblk0p3.
I am expecting the update to target and write to dev/mmcblk0p2.

Here is my sw-description:
************************
software =
{
    version = "0.0.1";
    description = "Firmware update for XXXXX Project";

    hardware-compatibility: [ "1.0", "1.2", "1.3"];
    images: (
        {
            filename="output.zck.header";
            type = "delta";
            device = "/dev/mmcblk0p2";
            properties: {
                      url = "https://**********.cloudfront.net/software/b/output.zck";
                      chain = "raw";
                      source = "/dev/mmcblk0p3";
                    };
        }
    );
}
************************

To update I am running:
sudo swupdate -H raspi4:1.0 -i ~/zchunk.swu -v

Which progresses nicely for ~20 minutes, and finally fails with this output:
*****************************
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (finish_chunk) Index 224017 digest 243db7c398bda10a64333a5866a8948c1d7db0cbc69b690fb3adbd6407a426af digest uncomp 243db7c398bda10a64333a5866a8948c1d7db0cbc69b690fb3adbd6407a426af
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (zck_end_chunk) Finished chunk size: 42507
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (hash_init) Initializing SHA-256 hash
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (hash_init) Initializing SHA-256 hash
[INFO ] : SWUPDATE running :  [get_total_size] : Total bytes to be reused     :  14855030358

[INFO ] : SWUPDATE running :  [get_total_size] : Total bytes to be downloaded :     64068459

[INFO ] : SWUPDATE running :  [install_delta] : Size of artifact to be installed : 15115223040
[TRACE] : SWUPDATE running :  [install_single_image] : Found installer for stream output.zck.header raw
[TRACE] : SWUPDATE running :  [trigger_download] : Range request : 15387823-15390657,15411853-15419054,15452925-15468571,15969312-15981475,16039860-16058334,16094795-16108533,16118342-16120923,16122967-16141611,16692915-16704474,16933573-16950500,17138156-17152533,17154798-17156167,17159204-17190414,17227787-17236022,17395940-17406939,17423428-17432900,17449299-17515938,17690975-17696929,17782544-17785645,17850027-18425242,18541306-18923994,19125804-19492279,19701877-20030661,73036470-73043024,73055347-73100319,587761848-587763578,587764774-587767917,588128395-588143791,588149047-588154723,588165319-588168896,588169971-588180605,588211532-588226176,588242782-588251346,588322932-588339158,588737416-588747300,588749661-588761415,588765908-588768049,588772252-588783497,588785151-588813671,588821301-588827361,588832437-588835714,588864111-588880726,588893086-588900282,588925720-588938310,588966426-588975085,589014978-589033002,589037767-589042508,589130595-589133925,589148346-589163895,589216414-589220331,589255753-589262745,589278671-589282154,589394453-589402145,589404521-589406580,589409485-589414897,589554311-589561308,589564502-589565487,589569253-589579565,589588421-589590946,589598920-589604744,589610614-589616691,589623662-589638105,589673024-589676505,589827220-589831858,589832326-589838358,589840451-589842556,589843928-589847227,589848547-589849613,589850590-589851888,589852569-589854807,589857649-589859834,589867655-589868843,589870236-589871649,589872544-589876403,589881820-589965072,589997279-590014376,590054857-590073975,590189070-590251046,590388662-590404707,590468686-590508908,610901750-610929759,619057134-619081197,636153729-636159400,654808268-654882888,660793924-661015118,679243280-679269358,679302322-679365740,680686036-680713373,680796608-680828679,684469739-684499336,695981854-695994324,699527008-699556441,699571965-699585045,699623500-699653849,699657659-699669700,699697154-699715967,699763575-699797841,699844065-699901547,699907580-699910693,699948467-699961500,699975476-700016887,700075117-700111397,702426640-702492684,
[DEBUG] : SWUPDATE running :  [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.

[ERROR] : SWUPDATE failed [0] ERROR delta_handler.c : install_delta : 1077 : Delta Update fails : aborting
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close) Closing compression
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close) Closing compression
[TRACE] : SWUPDATE running :  [install_single_image] : Installer for delta not successful !
[ERROR] : SWUPDATE failed [1] Installation failed !
[TRACE] : SWUPDATE running :  [network_initializer] : Main thread sleep again !
[INFO ] : No SWUPDATE running :  Waiting for requests...
[ERROR] : SWUPDATE failed [0] ERROR install_from_file.c : endupdate : 55 : SWUpdate *failed* !
*****************************

The deltas seem to be correct, but the install fails immediately after the range requests are printed. It does not seem that anything is being downloaded as the link is quite slow and it should take a while to download the 64MB.

I would like a more experienced look at this. Things to try or advice to get more debugging information would be much appreciated.

Things I have done to try and debug:
1.) Verified that with cURL I can download at least a few of the ranges specified from the same URL that is listed on the sw-description
2.) Switched around the device and source values (They were originally the same partition but I realize now thar source should be active mounted rootFS and device should be inactive target)

Other system info:
OS: Debian 10 (Buster)
Hardware: Raspi CM4
ZChunk version: 1.3.2

Happy to provide more information if necessary.

Many thanks in advance.

Stefano Babic

unread,
Oct 17, 2023, 4:42:04 AM10/17/23
to Noah Parker, swupdate
.1
Hi Noah,

On 16.10.23 03:02, Noah Parker wrote:
> Hello,
>
> I am attempting to install a delta update using zchunk.
> I have booted the 2nd root FS partition dev/mmcblk0p3.
> I am expecting the update to target and write to dev/mmcblk0p2.
>
> Here is my sw-description:
> ************************
> software =
> {
>     version = "0.0.1";
>     description = "Firmware update for XXXXX Project";
>
>     hardware-compatibility: [ "1.0", "1.2", "1.3"];
>     images: (
>         {
>             filename="output.zck.header";
>             type = "delta";
>             device = "/dev/mmcblk0p2";
>             properties: {
>                       url =
> "https://**********.cloudfront.net/software/b/output.zck";
>                       chain = "raw";
>                       source = "/dev/mmcblk0p3";
>                     };
>         }
>     );
> }
> ************************
>
> To update I am running:
> sudo swupdate -H raspi4:1.0 -i ~/zchunk.swu -v
>

I suggest you add "-l 5" to add verbosity.
This is the final error, it just told us that chunks (downloaded or not)
were not correct.

> [TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close)
> Closing compression
> [TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close)
> Closing compression
> [TRACE] : SWUPDATE running :  [install_single_image] : Installer for
> delta not successful !
> [ERROR] : SWUPDATE failed [1] Installation failed !
> [TRACE] : SWUPDATE running :  [network_initializer] : Main thread sleep
> again !
> [INFO ] : No SWUPDATE running :  Waiting for requests...
> [ERROR] : SWUPDATE failed [0] ERROR install_from_file.c : endupdate : 55
> : SWUpdate *failed* !
> *****************************
>
> The deltas seem to be correct, but the install fails immediately after
> the range requests are printed. It does not seem that anything is being
> downloaded as the link is quite slow and it should take a while to
> download the 64MB.
>

If you say nothing was downloaded, it seems a connectionm issue with the
repository where the .zck file is stored.

> I would like a more experienced look at this. Things to try or advice to
> get more debugging information would be much appreciated.
>

See above.

A possible issue could be with the list of chunks. Default is SWupdate
matches the major Webserver that accept up to 200 entries in a single
HTTP request. Some other Server could have a smaller value.

If this is the issue, you can rule it by setting in the properties
"max-range". Default in SWUpdate is 150.

> Things I have done to try and debug:
> 1.) Verified that with cURL I can download at least a few of the ranges
> specified from the same URL that is listed on the sw-description

But maybe the server returns an error if the number of ranges exceeds
the setup.

> 2.) Switched around the device and source values (They were originally
> the same partition but I realize now thar source should be active
> mounted rootFS and device should be inactive target)
>
> Other system info:
> OS: Debian 10 (Buster)
> Hardware: Raspi CM4
> ZChunk version: 1.3.2
>

Best regards,
Stefano Babic

Stefano Babic

unread,
Oct 17, 2023, 4:42:10 AM10/17/23
to Noah Parker, swupdate
Hi Noah,

On 16.10.23 03:02, Noah Parker wrote:
> Hello,
>
> I am attempting to install a delta update using zchunk.
> I have booted the 2nd root FS partition dev/mmcblk0p3.
> I am expecting the update to target and write to dev/mmcblk0p2.
>
> Here is my sw-description:
> ************************
> software =
> {
>     version = "0.0.1";
>     description = "Firmware update for XXXXX Project";
>
>     hardware-compatibility: [ "1.0", "1.2", "1.3"];
>     images: (
>         {
>             filename="output.zck.header";
>             type = "delta";
>             device = "/dev/mmcblk0p2";
>             properties: {
>                       url =
> "https://**********.cloudfront.net/software/b/output.zck";
>                       chain = "raw";
>                       source = "/dev/mmcblk0p3";
>                     };
>         }
>     );
> }
> ************************
>
> To update I am running:
> sudo swupdate -H raspi4:1.0 -i ~/zchunk.swu -v
>

I suggest you add "-l 5" to add verbosity.

This is the final error, it just told us that chunks (downloaded or not)
were not correct.

> [TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close)
> Closing compression
> [TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close)
> Closing compression
> [TRACE] : SWUPDATE running :  [install_single_image] : Installer for
> delta not successful !
> [ERROR] : SWUPDATE failed [1] Installation failed !
> [TRACE] : SWUPDATE running :  [network_initializer] : Main thread sleep
> again !
> [INFO ] : No SWUPDATE running :  Waiting for requests...
> [ERROR] : SWUPDATE failed [0] ERROR install_from_file.c : endupdate : 55
> : SWUpdate *failed* !
> *****************************
>
> The deltas seem to be correct, but the install fails immediately after
> the range requests are printed. It does not seem that anything is being
> downloaded as the link is quite slow and it should take a while to
> download the 64MB.
>

If you say nothing was downloaded, it seems a connectionm issue with the
repository where the .zck file is stored.

> I would like a more experienced look at this. Things to try or advice to
> get more debugging information would be much appreciated.
>

See above.

A possible issue could be with the list of chunks. Default is SWupdate
matches the major Webserver that accept up to 200 entries in a single
HTTP request. Some other Server could have a smaller value.

If this is the issue, you can rule it by setting in the properties
"max-range". Default in SWUpdate is 150.

> Things I have done to try and debug:
> 1.) Verified that with cURL I can download at least a few of the ranges
> specified from the same URL that is listed on the sw-description
> 2.) Switched around the device and source values (They were originally
> the same partition but I realize now thar source should be active
> mounted rootFS and device should be inactive target)
>
> Other system info:
> OS: Debian 10 (Buster)
> Hardware: Raspi CM4
> ZChunk version: 1.3.2
>
> Happy to provide more information if necessary.
>
> Many thanks in advance.
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/10ad0d03-0cc7-4cf2-8d95-f19274b4cc1fn%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/10ad0d03-0cc7-4cf2-8d95-f19274b4cc1fn%40googlegroups.com?utm_medium=email&utm_source=footer>.

Noah Parker

unread,
Oct 21, 2023, 3:21:03 PM10/21/23
to swupdate
Stefano,

Thank you for reaching out with advice. I have continued the debugging process

>I suggest you add "-l 5" to add verbosity.

Doing this gave me no additional debug output. Same output logs as before in regards to the failure.
I have noticed this warning with the additional log output:
*****************************
[TRACE] : SWUPDATE running :  [network_initializer] : Software update started
[WARN ] : SWUPDATE running :  [swupdate_create_directory] : Directory scripts/ cannot be created due to : File exists
[WARN ] : SWUPDATE running :  [swupdate_create_directory] : Directory datadst/ cannot be created due to : File exists
[WARN ] : SWUPDATE running :  [scan_mtd_devices] : MTD is not present on the target
[WARN ] : SWUPDATE running :  [mtd_init] : MTD is not present in the system
[WARN ] : SWUPDATE running :  [mtd_init] : cannot open libmtd

************************

I built swupdate from source and libmtd was found + linked. Unsure why at runtime that would be different, could this be impacting things at all?

I updated my sw-properties file to set the max-ranges parameter to 50. This is an arbitrary value but I figured reducing by 66% was significant.
I also added the zckloglevel paramater and set it to debug but this had no effect on the verbosity regarding the failure.
Here is my current sw-properties file:

***************
software =
{
    version = "0.0.1";
    description = "Firmware update for XXXXX Project";

    hardware-compatibility: [ "1.0", "1.2", "1.3"];
    images: (
        {
            filename="output.zck.header";
            type = "delta";
            device = "/dev/mmcblk0p3";
            properties: {
                      url = "http://************.cloudfront.net/software/b/output.zck";
                      chain = "raw";
                      source = "/dev/mmcblk0p2";
                      max-ranges = "50";
                      zckloglevel = "debug";
                    };
        }
    );
}

***************
These configuration changes had no effect and I am still seeing the failure with unfortunately no more debug information.
***************
[INFO ] : SWUPDATE running :  [get_total_size] : Total bytes to be reused     :  14902792329

[INFO ] : SWUPDATE running :  [get_total_size] : Total bytes to be downloaded :     15862744

[INFO ] : SWUPDATE running :  [install_delta] : Size of artifact to be installed : 14991491072

[TRACE] : SWUPDATE running :  [install_single_image] : Found installer for stream output.zck.header raw
[TRACE] : SWUPDATE running :  [trigger_download] : Range request : 11143774-11146183,11153571-11167133,11170009-11178271,11179009-11196366,11198609-11209375,11219299-11225139,11229945-11238661,11251085-11251973,11256364-11263191,11267311-11284760,11288683-11293510,11295024-11328940,11364050-11364545,11367754-11368306,11375690-11385300,11386734-11387609,11397046-11400533,11404118-11407480,11413383-11420500,11426337-11431912,11462630-11467142,11699001-11705077,11728490-11750755,11801080-11802808,11811075-11819242,46812411-46827945,47202496-47217103,89421595-89435352,90406204-90416888,90430598-90455967,94711505-94736148,592871287-595834498,667958484-667961884,701819195-701835494,831435654-831504962,831551047-831552208,831577852-831585593,831597791-831605605,831608612-831612770,831616529-831620735,831662589-831663832,868807644-868813950,869022614-869035919,869280532-869316948,869370124-869387619,869408192-869414767,869418603-869430169,869435644-869447234,869493711-869495820,869516116-869519806

[DEBUG] : SWUPDATE running :  [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.

[ERROR] : SWUPDATE failed [0] ERROR delta_handler.c : install_delta : 1077 : Delta Update fails : aborting
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close) Closing compression
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close) Closing compression
[TRACE] : SWUPDATE running :  [install_single_image] : Installer for delta not successful !
[ERROR] : SWUPDATE failed [1] Installation failed !
[TRACE] : SWUPDATE running :  [network_initializer] : Main thread sleep again !
[INFO ] : No SWUPDATE running :  Waiting for requests...
[ERROR] : SWUPDATE failed [0] ERROR install_from_file.c : endupdate : 55 : SWUpdate *failed* !
*****************************

The command I am executing:
sudo swupdate -H raspberrypi4:1.0 -e stable,copy1 -f /home/ubuntu/linux_mtd/swupdate/examples/configuration/swupdate.cfg -i ./zchunk.swu -l 5 -v

I am further reducing the max-ranges for my next attempt but I have little reason to expect a difference.

I have looked into CloudFront quotas here: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html and it specs a maximum request length for headers + URL parameters to be 20,480 bytes. I have not yet looked at the size of the outgoing request to see if it is exceeding this.
Do you have a good gauge for the request size expected for the amount of ranges specified in that log?

Any further advice would be greatly appreciated.

-Noah

>See above.

>A possible issue could be with the list of chunks. Default is SWupdate
>matches the major Webserver that accept up to 200 entries in a single
>HTTP request. Some other Server could have a smaller value.

>If this is the issue, you can rule it by setting in the properties
>"max-range". Default in SWUpdate is 150.

Ok I set max-ranges to 50 and zckloglevel to debug.
Message has been deleted

Noah Parker

unread,
Oct 21, 2023, 4:08:38 PM10/21/23
to swupdate
Stefano,

I have some more information from my debugging efforts. Reducing max-ranges to 10 seems to have made a difference.

Newest failure log:
*******************
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (finish_chunk) Index 182488 digest fa43239bcee7b97ca62f007cc68487560a39e19f74f3dde7486db3f98df8e471 digest uncomp fa43239bcee7b97ca62f007cc68487560a39e19f74f3dde7486db3f98df8e471
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (finish_chunk) Index 182489 digest fa43239bcee7b97ca62f007cc68487560a39e19f74f3dde7486db3f98df8e471 digest uncomp fa43239bcee7b97ca62f007cc68487560a39e19f74f3dde7486db3f98df8e471
[INFO ] : SWUPDATE running :  [get_total_size] : Total bytes to be reused     :  14887482769

[INFO ] : SWUPDATE running :  [get_total_size] : Total bytes to be downloaded :     16668743


[INFO ] : SWUPDATE running :  [install_delta] : Size of artifact to be installed : 14991491072
[TRACE] : SWUPDATE running :  [install_single_image] : Found installer for stream output.zck.header raw
[TRACE] : SWUPDATE running :  [trigger_download] : Range request : 11143774-11146183,11153571-11167133,11170009-11178271,11179009-11196366,11198609-11209375,11219299-11225139,11229945-11238661,11251085-11251973,11256364-11263191,11267311-11269667

[DEBUG] : SWUPDATE running :  [channel_set_options] : cURL's low download speed timeout is disabled, this is most probably not what you want. Adapted it to 300s instead.

[ERROR] : SWUPDATE failed [0] ERROR delta_handler.c : install_delta : 1077 : Delta Update fails : aborting
[TRACE] : SWUPDATE running :  [channel_log_effective_url] : Channel's effective URL resolved to https://*******.cloudfront.net/software/b/output.zck
[DEBUG] : SWUPDATE running :  [channel_get_file] : Channel downloaded 78414 bytes ~ 0 MiB.

[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close) Closing compression
[TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close) Closing compression
[TRACE] : SWUPDATE running :  [install_single_image] : Installer for delta not successful !
[ERROR] : SWUPDATE failed [1] Installation failed !
[TRACE] : SWUPDATE running :  [network_initializer] : Main thread sleep again !
[INFO ] : No SWUPDATE running :  Waiting for requests...
[ERROR] : SWUPDATE failed [0] ERROR install_from_file.c : endupdate : 55 : SWUpdate *failed* !
*******************

The http to https redirect seems to be happening now based on that channel_log_effective_url statement.

If I curl those ranges specified like:
curl -X GET https://******.cloudfront.net/software/b/output.zck -i -H "Range: bytes=11143774-11146183,11153571-11167133,11170009-11178271,11179009-11196366,11198609-11209375,11219299-11225139,11229945-11238661,11251085-11251973,11256364-11263191,11267311-11269667" --output ./test_download

I also get 78414 bytes. 78414 is far off from the required 16668743 bytes however. Is the expected behavior that multiple successive requests are made?

Thanks,
-Noah 

Stefano Babic

unread,
Oct 21, 2023, 5:34:18 PM10/21/23
to Noah Parker, swupdate
Hi Noah,

On 21.10.23 22:05, Noah Parker wrote:
> Stefano,
>
> I attempted an update again with the max-ranges parameter at ten. This
> seems to have actually made a difference.
>

Ten is too short. There should be another problem.

> Here is the most recent failure log.
> ***********************
> [TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (finish_chunk)
> Index 182488 digest
> fa43239bcee7b97ca62f007cc68487560a39e19f74f3dde7486db3f98df8e471 digest
> uncomp fa43239bcee7b97ca62f007cc68487560a39e19f74f3dde7486db3f98df8e471
> [TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (finish_chunk)
> Index 182489 digest
> fa43239bcee7b97ca62f007cc68487560a39e19f74f3dde7486db3f98df8e471 digest
> uncomp fa43239bcee7b97ca62f007cc68487560a39e19f74f3dde7486db3f98df8e471
> [INFO ] : SWUPDATE running :  [get_total_size] : Total bytes to be
> reused     :  14887482769
>
> [INFO ] : SWUPDATE running :  [get_total_size] : Total bytes to be
> downloaded :     16668743
>
> [INFO ] : SWUPDATE running :  [install_delta] : Size of artifact to be
> installed : 14991491072
> [TRACE] : SWUPDATE running :  [install_single_image] : Found installer
> for stream output.zck.header raw
> [TRACE] : SWUPDATE running :  [trigger_download] : Range request :
> 11143774-11146183,11153571-11167133,11170009-11178271,11179009-11196366,11198609-11209375,11219299-11225139,11229945-11238661,11251085-11251973,11256364-11263191,11267311-11269667
> [DEBUG] : SWUPDATE running :  [channel_set_options] : cURL's low
> download speed timeout is disabled, this is most probably not what you
> want. Adapted it to 300s instead.
>
> [ERROR] : SWUPDATE failed [0] ERROR delta_handler.c : install_delta :
> 1077 : Delta Update fails : aborting
> [TRACE] : SWUPDATE running :  [channel_log_effective_url] : Channel's
> effective URL resolved to
> https://*******.cloudfront.net/software/b/output.zck
> [DEBUG] : SWUPDATE running :  [channel_get_file] : Channel downloaded
> 78414 bytes ~ 0 MiB.
> [TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close)
> Closing compression
> [TRACE] : SWUPDATE running :  [zck_log_toswupdate] : (comp_close)
> Closing compression
> [TRACE] : SWUPDATE running :  [install_single_image] : Installer for
> delta not successful !
> [ERROR] : SWUPDATE failed [1] Installation failed !
> [TRACE] : SWUPDATE running :  [network_initializer] : Main thread sleep
> again !
> [INFO ] : No SWUPDATE running :  Waiting for requests...
> [ERROR] : SWUPDATE failed [0] ERROR install_from_file.c : endupdate : 55
> : SWUpdate *failed* !
> ***********************
>
> Data is downloaded and the URL redirect from http to https looks to be
> happening based on that channel_log_effective_url statement.

Please note that support for SSL in the downloader for delta was
recently added, and it is just in -master branch. See commit 1979fa8bf2.

>
> If I curl for those specified ranges of output.zck like:
> curl -X GET https://dcygqrjfsypox.cloudfront.net/software/b/output.zck
> -i -H "Range:
> bytes=11143774-11146183,11153571-11167133,11170009-11178271,11179009-11196366,11198609-11209375,11219299-11225139,11229945-11238661,11251085-11251973,11256364-11263191,11267311-11269667" --output ./test_download
>
> I also get 78414 bytes.
>
> Still, 78414 is far off from the 16668743 bytes required. Is it expected
> that multiple sequential requests would be made?

Yes, but SWUpdate stops at the first error, and this is what I presume here.

Best regards,
Stefano

>
> Thanks,
> -Noah
>
> On Saturday, October 21, 2023 at 3:21:03 PM UTC-4 Noah Parker wrote:
>
> <http://cloudfront.net/software/b/output.zck>";
> https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html <https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html> and it specs a maximum request length for headers + URL parameters to be 20,480 bytes. I have not yet looked at the size of the outgoing request to see if it is exceeding this.
> <http://cloudfront.net/software/b/output.zck>";
> https://groups.google.com/d/msgid/swupdate/10ad0d03-0cc7-4cf2-8d95-f19274b4cc1fn%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/10ad0d03-0cc7-4cf2-8d95-f19274b4cc1fn%40googlegroups.com> <https://groups.google.com/d/msgid/swupdate/10ad0d03-0cc7-4cf2-8d95-f19274b4cc1fn%40googlegroups.com?utm_medium=email&utm_source=footer <https://groups.google.com/d/msgid/swupdate/10ad0d03-0cc7-4cf2-8d95-f19274b4cc1fn%40googlegroups.com?utm_medium=email&utm_source=footer>>.
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/ad203108-cbe9-4453-a47b-2fa16c1ede33n%40googlegroups.com <https://groups.google.com/d/msgid/swupdate/ad203108-cbe9-4453-a47b-2fa16c1ede33n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Noah Parker

unread,
Oct 22, 2023, 8:31:47 PM10/22/23
to swupdate
Stefano,

Thank you for your help throughout this process. You were onto something suggesting it was an issue with the serving of the range requests. My issues seem to have stemmed from:
A.) Originally the distribution hosting the .zck image was enforcing HTTPS and this is not yet supported (what is the expected released of SSL support?)
B.) The two other servers I tested with did not completely or properly support Range requests.

Switching to a nginx server on the local network with the device proved to be a useful test bed. I would recommend the same to anyone else having troubles.

Thanks again,
-Noah

Reply all
Reply to author
Forward
0 new messages