Note: The Size column is the size in bytes, as reported in /sys/class/block/mtdblock*/size (multiplied by 512) and of the files produced by dd if=/dev/mtdX.
The downloads are the same on every attempt in both Firefox and Chrome.
The Content-Length header of the HTTP response indicates the correct size, but the response is aborted before the download completes.
logread contains the following messages when an attempt was made to download mtd1:
Tue May 31 13:53:49 2022 kern.warn kernel: [ 1544.984764] print_req_error: 37 callbacks suppressed
Tue May 31 13:53:49 2022 kern.err kernel: [ 1544.984772] blk_update_request: I/O error, dev mtdblock1, sector 1568 op 0x0:(READ) flags 0x84700 phys_seg 15 prio class 0
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.000990] blk_update_request: I/O error, dev mtdblock1, sector 1576 op 0x0:(READ) flags 0x84700 phys_seg 14 prio class 0
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.012171] blk_update_request: I/O error, dev mtdblock1, sector 1584 op 0x0:(READ) flags 0x84700 phys_seg 14 prio class 0
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.023347] blk_update_request: I/O error, dev mtdblock1, sector 1592 op 0x0:(READ) flags 0x84700 phys_seg 13 prio class 0
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.034522] blk_update_request: I/O error, dev mtdblock1, sector 1600 op 0x0:(READ) flags 0x84700 phys_seg 13 prio class 0
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.045697] blk_update_request: I/O error, dev mtdblock1, sector 1608 op 0x0:(READ) flags 0x84700 phys_seg 12 prio class 0
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.056903] blk_update_request: I/O error, dev mtdblock1, sector 1616 op 0x0:(READ) flags 0x84700 phys_seg 12 prio class 0
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.068109] blk_update_request: I/O error, dev mtdblock1, sector 1624 op 0x0:(READ) flags 0x84700 phys_seg 11 prio class 0
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.079283] blk_update_request: I/O error, dev mtdblock1, sector 1632 op 0x0:(READ) flags 0x84700 phys_seg 11 prio class 0
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.090458] blk_update_request: I/O error, dev mtdblock1, sector 1640 op 0x0:(READ) flags 0x84700 phys_seg 10 prio class 0
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.143235] Buffer I/O error on dev mtdblock1, logical block 196, async page read
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.151257] Buffer I/O error on dev mtdblock1, logical block 196, async page read
Tue May 31 13:53:49 2022 kern.err kernel: [ 1545.158954] Buffer I/O error on dev mtdblock1, logical block 196, async page read
Are these a result of the non-UBI ECC errors mentioned in the Installation section of the OpenWrt ToH device page? If so, should the backup instructions advise avoiding LuCI for stock firmware? If not, I'd appreciate suggestions for further debugging or whether I should report this bug to the OpenWrt project.
I'm encountering a similar error after installing OpenWrt, which I reported as https://github.com/openwrt/openwrt/issues/10986 I'm closing this issue as it is likely not specific to the installer.
On a Belkin RT3200 running stock firmware "1.0.01 build 101415 OCT 14, 2020" if I follow the Device flash complete backup procedure by flashing
openwrt-22.03-snapshot-r19338-ae64d0624c-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb
(oropenwrt-22.03.0-rc6-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb
built from dangowrt/owrt-ubi-installer@e966acf with an edit to use 22.03.0-rc6 - same result) then download the mtdblock contents from System -> Backup / Flash Firmware, the downloaded files are incomplete:Note: The Size column is the size in bytes, as reported in /sys/class/block/mtdblock*/size (multiplied by 512) and of the files produced by
dd if=/dev/mtdX
.The downloads are the same on every attempt in both Firefox and Chrome.
The
Content-Length
header of the HTTP response indicates the correct size, but the response is aborted before the download completes.logread
contains the following messages when an attempt was made to download mtd1:Are these a result of the non-UBI ECC errors mentioned in the Installation section of the OpenWrt ToH device page? If so, should the backup instructions advise avoiding LuCI for stock firmware? If not, I'd appreciate suggestions for further debugging or whether I should report this bug to the OpenWrt project.
Thanks for all your work on this project! Kevin