Re: [PATCH] base-files: fix nand_upgrade_ubinized()
On 4/10/23 15:38, Daniel Golle wrote: On Mon, Apr 10, 2023 at 07:01:35PM +0200, Rafał Miłecki wrote: From: Rafał Miłecki When using "ubiformat" with stdin it requires passing image size using the -S argument. Provide it just like we do for "ubiupdatevol". This fixes: ubiformat: error!: must use '-S' with non-zero value when reading from stdin This change fixes sysupgrade for bcm53xx and bcm4908 NAND devices possibly some other targets too. Cc: Rodrigo Balerdi Cc: Daniel Golle Fixes: 971071212052 ("base-files: accept gzipped nand sysupgrade images") Signed-off-by: Rafał Miłecki Acked-by: Daniel Golle Please apply asap. (Dan, do you want me to PR?) hi Rafa, thanks! i wonder how it is possible that the code as is worked for me; i tested many times with compressed ubinized image. --- package/base-files/files/lib/upgrade/nand.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/package/base-files/files/lib/upgrade/nand.sh b/package/base-files/files/lib/upgrade/nand.sh index 907945b349..fa29d575a8 100644 --- a/package/base-files/files/lib/upgrade/nand.sh +++ b/package/base-files/files/lib/upgrade/nand.sh @@ -261,10 +261,12 @@ nand_upgrade_ubinized() { local ubi_file="$1" local gz="$2" + local ubi_length=$( (${gz}cat "$ubi_file" | wc -c) 2> /dev/null) + nand_detach_ubi "$CI_UBIPART" || return 1 local mtdnum="$( find_mtd_index "$CI_UBIPART" )" - ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach -m "$mtdnum" + ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -S "$ubi_length" -y -f - && ubiattach -m "$mtdnum" } # Write the UBIFS image to UBI rootfs volume -- 2.34.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
On 1/24/23 18:08, Koen Vandeputte wrote: Hi, I think our previous mails overlapped a bit as I didn't notice your previous response :) I'll send the data tomorrow. I'm also wondering if adding a sleep before ubiformat in the old way would influence/break it's behaviour? possibly yes Piotr, Would you have any idea here? Thanks again for your efforts, Koen if your active watchdog device is /dev/MyWatchdog, then... just before the line: ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach -m "$mtdnum" you could add this to try disable the watchdog: echo -n V >/dev/MyWatchdog or else you could tickle the watchdog while flashing like this: ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - 2>&1 | tee /dev/MyWatchdog && ubiattach -m "$mtdnum" BUT... this is a hack, cause shell option pipefail would be needed to detect a failure of ubiformat then, as normally only the exit code of the last piped process gets returned from the pipe expression. so these are just tests, not fixes. another dirty thing you could do is doubling the watchdog timeout period for your platform. this at least could maybe be accepted as a stopgap band aid in the openwrt tree. but the race condition remains, and it will bite back sometime. a real fix for the race should be implemented. BTW your watchdog seems to be: https://www.kernelconfig.io/config_imx2_wdt thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
On 1/24/23 17:35, Lanchon wrote: On 1/24/23 13:25, Koen Vandeputte wrote: On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte wrote: On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote: hi Koen, thanks again. i copied your log here for ease of reference: https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db first let me say: - ubinized sysupgrade is not used by any of my devices. - ubinized sysupgrade happens when when an ubi partition image is fed as an upgrade file. the image contains the complete set of ubi volumes that are normally stored within the ubi partition on your device: typically kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during said sysupgrade, the current configuration is first copied to RAM, then the ubi partition image is written, and finally -if current config is kept- the RAM contents are written back to the new overlay volume. - ubinized sysupgrades were known to be broken by other people at the time of my commits, and they wanted to remove the feature altogether because it was unused (look it up in the relevant pull request for my commits on github). as i remember it, it was broken because some ubi volumes within the ubi partition were sometimes mounted or R/O block devices were created on top of them (/dev/ubiblock*), locking the ubi partition and preventing the upgrade. - although my devices would normally not use such upgrades, i could still take a whole ubi partition backup and then test ubinized sysupgrade with it on my devices. in fact, if you restore the ubi partition image without conserving the current configuration, then this procedure is the best way to do a backup/restore of the complete state of the router: kernel, rootfs, and overlay are completely saved and restored. btw, i think this should be documented. (and this is mostly the reason why i added gzip support on sysupgrade: ubinized images of backed-up ubi partitions compress like crazy.) - my tests of ubinized sysupgrade worked after these changes but not before. specifically the fix is in: af34733593 base-files: fix ubinized nand sysupgrade regarding your log: - nand_do_platform_check succeeds: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192 - next comes the actual nand_do_flash_file: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061 - it is determined that passed file is a ubi partition image, so nand_upgrade_ubinized is invoked: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088 nand_upgrade_ubinized is basically a one-liner: ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach -m "$mtdnum" cat/zcat the image, feeding that to ubiformat -f - which writes it. and the write does take place, but take a look: --- + cat /tmp/nandnew.ubi + ubiformat /dev/mtd2 -y -f - ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes libscan: scanning eraseblock 0 -- 0 % complete libscan: scanning eraseblock 1 -- 0 % complete libscan: scanning eraseblock 2 -- 0 % complete ... libscan: scanning eraseblock 1868 -- 97 % complete libscan: scanning eraseblock [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1 1869 -- 97 % complete libscan: [ 207.883339] usb usb2: USB disconnect, device number 1 scanning eraseblock 1870 -- 97 % [ 207.891238] usb 2-1: USB disconnect, device number 2 complete libscan: scanning eras [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered eblock 1871 -- 97 % complete libscan: scanning eraseblock 1872 [ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4 -- 97 % complete libscan: scan [ 207.917055] usb usb1: USB disconnect, device number 1 ning eraseblock 1873 -- 98 % comp [ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered lete libscan: scanning eraseblo [ 207.934010] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot! ck 1874 -- 98 % complete libsca [ 207.942382] reboot: Restarting system --- while sysupgrade is flashing UBI the partition, the system is rebooted; i don't know why. here are the cleaned-up kernel messages: [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1 [ 207.883339] usb usb2: USB disconnect, device number 1 [ 207.891238] usb 2-1: USB disconnect, device number 2 [ 207.901522] ci_hdrc ci_hdrc.1: USB bus
Re: sysupgrade broken on imx nand targets (and maybe others too)
On 1/24/23 13:25, Koen Vandeputte wrote: On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte wrote: On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote: hi Koen, thanks again. i copied your log here for ease of reference: https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db first let me say: - ubinized sysupgrade is not used by any of my devices. - ubinized sysupgrade happens when when an ubi partition image is fed as an upgrade file. the image contains the complete set of ubi volumes that are normally stored within the ubi partition on your device: typically kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during said sysupgrade, the current configuration is first copied to RAM, then the ubi partition image is written, and finally -if current config is kept- the RAM contents are written back to the new overlay volume. - ubinized sysupgrades were known to be broken by other people at the time of my commits, and they wanted to remove the feature altogether because it was unused (look it up in the relevant pull request for my commits on github). as i remember it, it was broken because some ubi volumes within the ubi partition were sometimes mounted or R/O block devices were created on top of them (/dev/ubiblock*), locking the ubi partition and preventing the upgrade. - although my devices would normally not use such upgrades, i could still take a whole ubi partition backup and then test ubinized sysupgrade with it on my devices. in fact, if you restore the ubi partition image without conserving the current configuration, then this procedure is the best way to do a backup/restore of the complete state of the router: kernel, rootfs, and overlay are completely saved and restored. btw, i think this should be documented. (and this is mostly the reason why i added gzip support on sysupgrade: ubinized images of backed-up ubi partitions compress like crazy.) - my tests of ubinized sysupgrade worked after these changes but not before. specifically the fix is in: af34733593 base-files: fix ubinized nand sysupgrade regarding your log: - nand_do_platform_check succeeds: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192 - next comes the actual nand_do_flash_file: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061 - it is determined that passed file is a ubi partition image, so nand_upgrade_ubinized is invoked: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088 nand_upgrade_ubinized is basically a one-liner: ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach -m "$mtdnum" cat/zcat the image, feeding that to ubiformat -f - which writes it. and the write does take place, but take a look: --- + cat /tmp/nandnew.ubi + ubiformat /dev/mtd2 -y -f - ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes libscan: scanning eraseblock 0 -- 0 % complete libscan: scanning eraseblock 1 -- 0 % complete libscan: scanning eraseblock 2 -- 0 % complete ... libscan: scanning eraseblock 1868 -- 97 % complete libscan: scanning eraseblock [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1 1869 -- 97 % complete libscan: [ 207.883339] usb usb2: USB disconnect, device number 1 scanning eraseblock 1870 -- 97 % [ 207.891238] usb 2-1: USB disconnect, device number 2 complete libscan: scanning eras [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered eblock 1871 -- 97 % complete libscan: scanning eraseblock 1872 [ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4 -- 97 % complete libscan: scan [ 207.917055] usb usb1: USB disconnect, device number 1 ning eraseblock 1873 -- 98 % comp [ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered lete libscan: scanning eraseblo [ 207.934010] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot! ck 1874 -- 98 % complete libsca [ 207.942382] reboot: Restarting system --- while sysupgrade is flashing UBI the partition, the system is rebooted; i don't know why. here are the cleaned-up kernel messages: [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1 [ 207.883339] usb usb2: USB disconnect, device number 1 [ 207.891238] usb 2-1: USB disconnect, device number 2 [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered [ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4 [
Re: sysupgrade broken on imx nand targets (and maybe others too)
On 1/24/23 12:26, Koen Vandeputte wrote: On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote: hi Koen, thanks again. i copied your log here for ease of reference: https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db first let me say: - ubinized sysupgrade is not used by any of my devices. - ubinized sysupgrade happens when when an ubi partition image is fed as an upgrade file. the image contains the complete set of ubi volumes that are normally stored within the ubi partition on your device: typically kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during said sysupgrade, the current configuration is first copied to RAM, then the ubi partition image is written, and finally -if current config is kept- the RAM contents are written back to the new overlay volume. - ubinized sysupgrades were known to be broken by other people at the time of my commits, and they wanted to remove the feature altogether because it was unused (look it up in the relevant pull request for my commits on github). as i remember it, it was broken because some ubi volumes within the ubi partition were sometimes mounted or R/O block devices were created on top of them (/dev/ubiblock*), locking the ubi partition and preventing the upgrade. - although my devices would normally not use such upgrades, i could still take a whole ubi partition backup and then test ubinized sysupgrade with it on my devices. in fact, if you restore the ubi partition image without conserving the current configuration, then this procedure is the best way to do a backup/restore of the complete state of the router: kernel, rootfs, and overlay are completely saved and restored. btw, i think this should be documented. (and this is mostly the reason why i added gzip support on sysupgrade: ubinized images of backed-up ubi partitions compress like crazy.) - my tests of ubinized sysupgrade worked after these changes but not before. specifically the fix is in: af34733593 base-files: fix ubinized nand sysupgrade regarding your log: - nand_do_platform_check succeeds: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192 - next comes the actual nand_do_flash_file: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061 - it is determined that passed file is a ubi partition image, so nand_upgrade_ubinized is invoked: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088 nand_upgrade_ubinized is basically a one-liner: ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach -m "$mtdnum" cat/zcat the image, feeding that to ubiformat -f - which writes it. and the write does take place, but take a look: --- + cat /tmp/nandnew.ubi + ubiformat /dev/mtd2 -y -f - ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes libscan: scanning eraseblock 0 -- 0 % complete libscan: scanning eraseblock 1 -- 0 % complete libscan: scanning eraseblock 2 -- 0 % complete ... libscan: scanning eraseblock 1868 -- 97 % complete libscan: scanning eraseblock [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1 1869 -- 97 % complete libscan: [ 207.883339] usb usb2: USB disconnect, device number 1 scanning eraseblock 1870 -- 97 % [ 207.891238] usb 2-1: USB disconnect, device number 2 complete libscan: scanning eras [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered eblock 1871 -- 97 % complete libscan: scanning eraseblock 1872 [ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4 -- 97 % complete libscan: scan [ 207.917055] usb usb1: USB disconnect, device number 1 ning eraseblock 1873 -- 98 % comp [ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered lete libscan: scanning eraseblo [ 207.934010] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot! ck 1874 -- 98 % complete libsca [ 207.942382] reboot: Restarting system --- while sysupgrade is flashing UBI the partition, the system is rebooted; i don't know why. here are the cleaned-up kernel messages: [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1 [ 207.883339] usb usb2: USB disconnect, device number 1 [ 207.891238] usb 2-1: USB disconnect, device number 2 [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered [ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4 [ 207.917055] usb usb1: USB disconnect, device number 1 [ 20
Re: sysupgrade broken on imx nand targets (and maybe others too)
hi Koen, thanks again. i copied your log here for ease of reference: https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db first let me say: - ubinized sysupgrade is not used by any of my devices. - ubinized sysupgrade happens when when an ubi partition image is fed as an upgrade file. the image contains the complete set of ubi volumes that are normally stored within the ubi partition on your device: typically kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during said sysupgrade, the current configuration is first copied to RAM, then the ubi partition image is written, and finally -if current config is kept- the RAM contents are written back to the new overlay volume. - ubinized sysupgrades were known to be broken by other people at the time of my commits, and they wanted to remove the feature altogether because it was unused (look it up in the relevant pull request for my commits on github). as i remember it, it was broken because some ubi volumes within the ubi partition were sometimes mounted or R/O block devices were created on top of them (/dev/ubiblock*), locking the ubi partition and preventing the upgrade. - although my devices would normally not use such upgrades, i could still take a whole ubi partition backup and then test ubinized sysupgrade with it on my devices. in fact, if you restore the ubi partition image without conserving the current configuration, then this procedure is the best way to do a backup/restore of the complete state of the router: kernel, rootfs, and overlay are completely saved and restored. btw, i think this should be documented. (and this is mostly the reason why i added gzip support on sysupgrade: ubinized images of backed-up ubi partitions compress like crazy.) - my tests of ubinized sysupgrade worked after these changes but not before. specifically the fix is in: af34733593 base-files: fix ubinized nand sysupgrade regarding your log: - nand_do_platform_check succeeds: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192 - next comes the actual nand_do_flash_file: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061 - it is determined that passed file is a ubi partition image, so nand_upgrade_ubinized is invoked: https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269 https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088 nand_upgrade_ubinized is basically a one-liner: ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach -m "$mtdnum" cat/zcat the image, feeding that to ubiformat -f - which writes it. and the write does take place, but take a look: --- + cat /tmp/nandnew.ubi + ubiformat /dev/mtd2 -y -f - ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes libscan: scanning eraseblock 0 -- 0 % complete libscan: scanning eraseblock 1 -- 0 % complete libscan: scanning eraseblock 2 -- 0 % complete ... libscan: scanning eraseblock 1868 -- 97 % complete libscan: scanning eraseblock [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1 1869 -- 97 % complete libscan: [ 207.883339] usb usb2: USB disconnect, device number 1 scanning eraseblock 1870 -- 97 % [ 207.891238] usb 2-1: USB disconnect, device number 2 complete libscan: scanning eras [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered eblock 1871 -- 97 % complete libscan: scanning eraseblock 1872 [ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4 -- 97 % complete libscan: scan [ 207.917055] usb usb1: USB disconnect, device number 1 ning eraseblock 1873 -- 98 % comp [ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered lete libscan: scanning eraseblo [ 207.934010] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot! ck 1874 -- 98 % complete libsca [ 207.942382] reboot: Restarting system --- while sysupgrade is flashing UBI the partition, the system is rebooted; i don't know why. here are the cleaned-up kernel messages: [ 207.876200] ci_hdrc ci_hdrc.1: remove, state 1 [ 207.883339] usb usb2: USB disconnect, device number 1 [ 207.891238] usb 2-1: USB disconnect, device number 2 [ 207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered [ 207.910396] ci_hdrc ci_hdrc.0: remove, state 4 [ 207.917055] usb usb1: USB disconnect, device number 1 [ 207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered [ 207.934
Re: sysupgrade broken on imx nand targets (and maybe others too)
hi Koen, thanks for this detailed report, i'll try to take a look at it tonight. thank you again. On 1/23/23 12:37, Koen Vandeputte wrote: Hi Rodrigo, After a long absence and now testing the latest master, I noticed that imx nand flash sysupgrade was broken: expected behaviour: - scan the nand - write image - format empty space -reboot Seen behaviour: - Scan the nand - reboots I traced it back to this batch of commits by you: 9d1e687da3 base-files: verify nand sysupgrade images 9710712120 base-files: accept gzipped nand sysupgrade images af34733593 base-files: fix ubinized nand sysupgrade e25e6d8e54 base-files: fix and clean up nand sysupgrade code It can be easily confirmed by reverting /lib/upgrade/nand.sh with a version before these commits are applied to it. I added a "set -x" to nand.sh to get more detailed logs: https://pastebin.com/raw/yxY0SK1x Any idea? Thanks, Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: fix sysupgrade with ubi and kernel sharing partition
On 5/4/22 12:09, Sungbo Eo wrote: On 2022-05-02 17:10, Bjørn Mork wrote: I can understand that. I have not been able to find any other examples, so I have to take full responsibility for this unexpected configuration. I guess I thought it would make sense to have a "Kernel" partition large enough to allow reverting to OEM firmware. But I recently found out that the bootloader can be configured to boot from "Kernel2", which means that we can document a "revert to OEM" procedure using that partition instead. Will fail if/when we add dual image support to OpenWrt though. Another alternative is of course to add another partition for the OpenWrt kernel (pointed to by $CI_KERNPART), keeping the "Kernel" as an unused container only. Maybe the safest solution? How about using partition nesting here? I've started to use it for NAND devices recently. One example: https://github.com/openwrt/openwrt/blob/65258f5d6093/target/linux/ramips/dts/mt7621_iptime_t5004.dts#L62-L79 Sungbo that's interesting, i didn't know that was possible. in my extensive experience modding the partitioning of devices, which encompasses exactly *one* device, this is what i take home: in order to facilitate return to stock, i prefer keeping the complete set of OEM partitions and add new, overlapping partitions. the deprecated OEM partitions (those with their space repurposed) are renamed to "stock_" and marked read-write. also the new partitions are added at the end of the list, so that OEM partition numbering is not affected and scripts designed to work on them work under OEM and custom kernels. this was important on my device which included a partition with MACs and stuff that had to be relocated to consolidate reusable space. nested partitioning is interesting but does not generalize: it can't coalesce partitions. it would also not conserve the partition numbering. it seems partition nesting is a great mechanism to support reading and writing a set of related partitions in one go, and applies to NOR. for NAND, where bad block skipping occurs, this doesn't work. and nesting doesn't appear to offer any advantage over plain overlapping partitions, which is a more general solution. PS. the original concern of this thread has been worked around by patching the code (merged into master). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: fix sysupgrade with ubi and kernel sharing partition
hi, sorry for the delay. I didn't expect that kind of sharing. your fix is not enough: when later the partition is written, it is via 'mtd -n write' which expects an erased partition. i will do a PR ASAP to fix this by invalidating the start of the kernel partition instead of erasing it, this is enough to invalidate the kernel CRC. thanks! On 4/29/22 11:37, Bjørn Mork wrote: Commit ecbcc0b59551 bricks devices where a ubi rootfs and a raw kernel shares the same mtd partition. This is the case for the ZyXEL NR7101 for example. The OEM bootloader has no UBI support. OpenWrt splits the "Kernel" mtd partition in a raw kernel part used by the bootloader and a UBI part used for the OpenWrt rootfs and rootfs_data. Running mtd erase on this partition during during upgrade erases the UBI part and results in a soft brick. Fixes: ecbcc0b59551 ("base-files: safer sysupgrade.tar for kernel-out-of-UBI") Signed-off-by: Bjørn Mork --- I'm not sure what the proper fix for this is. I believe the intended functionality of commit ecbcc0b59551 should be re-implemented somehow. I guess the real bug might be the dual usage of this partition? But I'm pretty sure I found that as an example in some other device, without being able to point it out now. But I believe we need this immediate fix in any case, since this is a bricking regression. package/base-files/files/lib/upgrade/nand.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/base-files/files/lib/upgrade/nand.sh b/package/base-files/files/lib/upgrade/nand.sh index 5ecdb0ff2363..5e5607d35cd8 100644 --- a/package/base-files/files/lib/upgrade/nand.sh +++ b/package/base-files/files/lib/upgrade/nand.sh @@ -305,7 +305,7 @@ nand_upgrade_tar() { local ubi_kernel_length if [ "$kernel_length" ]; then if [ "$kernel_mtd" ]; then - mtd erase "$CI_KERNPART" + : # mtd erase "$CI_KERNPART" else ubi_kernel_length="$kernel_length" fi ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel