Hello. I’m trying to update mender 2.6.1 to 4.0.4 with no success. Could I ask, please, if it can be done in theory? Thanks.
2025-01-03 09:31:16 +0000 UTC info: Running Mender client version: 2.6.1
2025-01-03 09:31:20 +0000 UTC info: State transition: update-fetch [Download_Enter] -> update-store [Download_Enter]
2025-01-03 09:31:21 +0000 UTC info: No public key was provided for authenticating the artifact
2025-01-03 09:31:21 +0000 UTC info: Update Module path "/usr/share/mender/modules/v3" could not be opened (open /usr/share/mender/modules/v3: no such file or directory). Update modules will not be available
2025-01-03 09:31:21 +0000 UTC info: Opening device "/dev/mmcblk0p2" for writing
2025-01-03 09:31:21 +0000 UTC info: Native sector size of block device /dev/mmcblk0p2 is 512 bytes. Mender will write in chunks of 1048576 bytes
2025-01-03 09:35:43 +0000 UTC info: All bytes were successfully written to the new partition
2025-01-03 09:35:43 +0000 UTC info: The optimized block-device writer wrote a total of 1745 frames, where 1177 frames did need to be rewritten (i.e., skipped)
2025-01-03 09:35:43 +0000 UTC info: Wrote 1828716544/1828716544 bytes to the inactive partition
2025-01-03 09:35:44 +0000 UTC info: State transition: update-store [Download_Enter] -> update-after-store [Download_Leave]
2025-01-03 09:35:44 +0000 UTC info: State transition: update-after-store [Download_Leave] -> update-install [ArtifactInstall]
2025-01-03 09:35:45 +0000 UTC info: Enabling partition with new image installed to be a boot candidate: 2
2025-01-03 09:35:46 +0000 UTC info: State transition: update-install [ArtifactInstall] -> reboot [ArtifactReboot_Enter]
2025-01-03 09:35:46 +0000 UTC info: Rebooting device(s)
2025-01-03 09:35:46 +0000 UTC info: Mender rebooting from active partition: /dev/mmcblk0p3
2025-01-03 09:35:47 +0000 UTC info: Daemon terminated with SIGTERM
2025-01-03 09:38:29 +0000 UTC info: Running Mender client version: 2.6.1
2025-01-03 09:38:29 +0000 UTC info: Update Module path "/usr/share/mender/modules/v3" could not be opened (open /usr/share/mender/modules/v3: no such file or directory). Update modules will not be available
2025-01-03 09:38:30 +0000 UTC info: State transition: init [none] -> after-reboot [ArtifactReboot_Leave]
2025-01-03 09:38:31 +0000 UTC error: transient error: Reboot to the new update failed. Expected "upgrade_available" flag to be true but it was false. Either the switch to the new partition was unsuccessful, or the bootloader rolled back
2025-01-03 09:38:31 +0000 UTC info: State transition: after-reboot [ArtifactReboot_Leave] -> rollback [ArtifactRollback]
2025-01-03 09:38:31 +0000 UTC info: Performing rollback
2025-01-03 09:38:31 +0000 UTC info: No update available, so no rollback needed.
2025-01-03 09:38:31 +0000 UTC info: State transition: rollback [ArtifactRollback] -> rollback-reboot [ArtifactRollbackReboot_Enter]
2025-01-03 09:38:32 +0000 UTC info: Rebooting device(s) after rollback
2025-01-03 09:38:32 +0000 UTC info: Mender rebooting from inactive partition: /dev/mmcblk0p3
2025-01-03 09:38:32 +0000 UTC info: Daemon terminated with SIGTERM
2025-01-03 09:41:01 +0000 UTC info: Running Mender client version: 2.6.1
2025-01-03 09:41:01 +0000 UTC info: Mender shut down in state: rollback-reboot
2025-01-03 09:41:01 +0000 UTC info: Update Module path "/usr/share/mender/modules/v3" could not be opened (open /usr/share/mender/modules/v3: no such file or directory). Update modules will not be available
2025-01-03 09:41:01 +0000 UTC info: State transition: init [none] -> verify-rollback-reboot [ArtifactRollbackReboot_Leave]
2025-01-03 09:41:01 +0000 UTC info: State transition: verify-rollback-reboot [ArtifactRollbackReboot_Leave] -> after-rollback-reboot [ArtifactRollbackReboot_Leave]
2025-01-03 09:41:02 +0000 UTC info: State transition: after-rollback-reboot [ArtifactRollbackReboot_Leave] -> update-error [ArtifactFailure]
2025-01-03 09:41:03 +0000 UTC info: State transition: update-error [ArtifactFailure] -> cleanup [Error]
2025-01-03 09:41:03 +0000 UTC info: State transition: cleanup [Error] -> update-status-report [none]
Hi @Vladimir,
(You seem to be having a different issue so maybe is best on a separate thread?)
Yes, in theory it is possible. But there are some caveats.
First the log that you are copying in your message is from the device (presumably from journalctl), so we cannot see what the Mender Client 4 attempted to do. Can you provide us the deployment logs from the server? There it should be possible to see that the partition with Client 4 booted, then failed somehow, and triggered the rollback into the old partition with Client 2.
But just guessing a bit by looking at your logs, I think that the issue might be that your update image (your new partition) does not have the rootfs-image update module.
Before Mender Client 4.0, the update modules were optional because the client came with a built-in module (the rootfs-image one). Since 4.0, the client does not come with any built-in, but installs some modules by default (like the rootfs-image one). This means that /usr/share/mender/modules/v3 must exist and the rootfs-image module should be installed there in the new partition if you want to complete a rootfs update.
Lluis
Hello @lluiscampos. The log I posted above is the deployment failure log I’ve copied from mender web-interface. Also, I think that new Mender 4.0.4 image contains /usr/share/mender/modules/v3/rootfs-image file. I create sdimg file alongside with mender update file for RPi4, and rootfs-image exists in sdimg. Not sure if it is possible to check in the .mender file directly. Mender 2.6.1 image doesn’t have /usr/share/modules directory. Thanks.
@Vladimir Interesting. If the log is from the server, it means that the client in the new partition never got started (or it failed early before even attempting to continue the update).
Are you creating your images with yocto or mender-convert? Can you try first updating from 2.6.1 to 3.x?
You can check the .mender file with mender-artifact. For example mender-artifact cat my-update.mender:/usr/share/modules/v3/rootfs-image
@lluiscampos I create images with yocto. The old image (Mender 2.6.1) is dunfell 3.1 yocto branch, the new one (Mender 4.0.4) is scarthgap 5.0 yocto branch. I checked existense of rootfs-image by mender-artifact, it is present, thanks. Yes, I will create Mender 3.x image and try. Thanks.
So you are also upgrading through two LTSs of yocto: dunfell → (kirkstone, skipped) → scarthgap. This I didn’t expect.
Note that yocto releases are not guaranteed to be upgradable; in Mender we have detected several times breakages wrt bootloader integration or other parts and had amended or created workarounds.
I would tackle one problem at a time. Trying the following combinations should point to where the problem may be:
- Upgrade dunfell Mender 2.6 to dunfell Mender 3 → it most certainly works
- Upgrade dunfell Mender 2.6 to kirkstone Mender 3 → if it fails, we know that that the issue is dunfell to kirkstone
- Upgrade dunfell Mender 2.6 to kirkstone Mender 4 → if it fails, we know that that the issue is Mender 2 to Mender 4
- Upgrade dunfell Mender 2.6 to scarthgap Mender 4 → if it fails, we know that that the issue is dunfell to scarthgap
Hope it helps
@lluiscampos I decided to follow your advice and fix Mender version. It is 3.5.0 once it is the most modern version that exists in dunfell (3.0), kirkstone (4.0) and scarthgap (5.0) yocto branches. It won’t be Mender upgrade, just yocto branch switch, as old and new images contain the same Mender version (3.5.0). Then, I created kirkstone image. I had to fix mender-community u-boot patch, because existing patch could not be applied (Fix RPi u-boot patch · AllianceTrooper/meta-mender-community@a47a886 · GitHub). I checked that the new kirkstone image is bootable. However, mender-client of kirkstone image cannot connect to the server. I copied mender-agent.pem file from dunfell image, but systemctl status mender-client shows:
Jan 20 19:59:25 raspberrypi4 mender[565]: time="2025-01-20T19:59:25Z" level=info msg="State transition: inventory-update [Sync] -> inventory-update-retry-wait [Sync]"
Jan 20 19:59:25 raspberrypi4 mender[565]: time="2025-01-20T19:59:25Z" level=info msg="Handle update inventory retry state try: 6"
Jan 20 19:59:27 raspberrypi4 mender[565]: time="2025-01-20T19:59:27Z" level=info msg="Device unauthorized; attempting reauthorization"
Jan 20 19:59:27 raspberrypi4 mender[565]: time="2025-01-20T19:59:27Z" level=info msg="Output (stderr) from command \"/usr/share/mender/identity/mender-device-identity\": using interface /sys/class/net/eth0"
Jan 20 19:59:27 raspberrypi4 mender[565]: time="2025-01-20T19:59:27Z" level=error msg="Failed to authorize with \"https://hosted.mender.io\": authentication request rejected server error message: Account suspended"
Jan 20 19:59:27 raspberrypi4 mender[565]: time="2025-01-20T19:59:27Z" level=warning msg="Reauthorization failed with error: transient error: authorization request failed"
Jan 20 19:59:27 raspberrypi4 mender[565]: time="2025-01-20T19:59:27Z" level=error msg="Failed to submit inventory data: transient error: authorization request failed"
Jan 20 19:59:27 raspberrypi4 mender[565]: time="2025-01-20T19:59:27Z" level=error msg="inventory submit failed: transient error: authorization request failed"
Jan 20 19:59:27 raspberrypi4 mender[565]: time="2025-01-20T19:59:27Z" level=warning msg="Failed to refresh inventory: failed to submit inventory data: inventory submit failed: transient error: authorization request failed"
Jan 20 19:59:27 raspberrypi4 mender[565]: time="2025-01-20T19:59:27Z" level=info msg="Wait 4m0s before next inventory update attempt in 3m59.999987278s"
I don’t see any new requests at web interface. Could you tell me, please, what does it mean “Account suspended”? Thanks.
@lluiscampos It looks like “Account suspended” is really related to the state of my account. But patch issue is relevant
Hi @Vladimir,
In order to support RPi5 also, we have decided on adding the meta-lts-mixins layer as a requirement which provides u-boot V2024.04 to scarthgap.
This allows for a uniform integration of all RPi models. Do you have a specific use case which does not allow for using it? Otherwise just add the layer, as also visible in the corresponding kas files
Greetz,
Josef
@TheYoctoJester Hello. I’m trying to perform dunfell → kirkstone upgrade at the moment (as a stage of subsequent upgrade to scarthgap). I don’t see any u-boot version bumps for branch kirkstone in meta-lts-mixins.
Hi @Vladimir,
Ok, after looking deeper I understood the problem. So, the current HEAD of kirkstone uses the scarthgap branch of meta-lts-mixins by patching it to be compatible. You can find the corresponding patch in kas/patches.
If you don’t want to apply this strategy, you can just use the commit of meta-mender-community before this, which is 61e495c4dd4dca81d1d1643092316886f104954b . Looking at the code then should perfectly build on the kirkstone version of u-boot: GitHub - mendersoftware/meta-mender-community at 61e495c4dd4dca81d1d1643092316886f104954b
Greetz,
Josef
@TheYoctoJester Thank you for the instructions, I built kirkstone with u-boot 2024.04, I should have checked kas config files.
1 Like
Hi @Vladimir,
Glad to hear its working!
Greetz,
Josef
@TheYoctoJester I tried to boot kirkstone image with u-boot 2024.04 and found out that boot process stalls on the same point as described there: Trouble getting RPi4 to work - #7 by Vladimir. Then, I cherry-picked two commits from scarthgap branch of meta-mender-community repo:
fix: rpi: uboot, increase memory area for kernel loading · mendersoftware/meta-mender-community@1d3da07 · GitHub
fix: rpi 32bit, ignore address range checks in u-boot · mendersoftware/meta-mender-community@b930ff3 · GitHub
And I’m able to boot after these changes. Could I ask, please, should it be ported from scarthgap to kirkstone branch? Thanks.
@TheYoctoJester Hello. Sorry for confusion, but I passed halfway only. I’ve upgraded dunfell → kirkstone (mender-client 3.5.0), but kirkstone → scarthgap upgrade attempt fails. Both images have mender-client 3.5.0 and u-boot 2024.04. Here the log:
2025-02-12 11:25:32 +0000 UTC info: Running Mender client version: 3.5.0
2025-02-12 11:25:33 +0000 UTC info: State transition: update-fetch [Download_Enter] -> update-store [Download_Enter]
2025-02-12 11:25:34 +0000 UTC info: No public key was provided for authenticating the artifact
2025-02-12 11:25:34 +0000 UTC info: Opening device "/dev/mmcblk0p2" for writing
2025-02-12 11:25:34 +0000 UTC info: Native sector size of block device /dev/mmcblk0p2 is 512 bytes. Mender will write in chunks of 1048576 bytes
2025-02-12 11:29:18 +0000 UTC info: All bytes were successfully written to the new partition
2025-02-12 11:29:18 +0000 UTC info: The optimized block-device writer wrote a total of 1745 frames, where 1169 frames did need to be rewritten (i.e., skipped)
2025-02-12 11:29:18 +0000 UTC info: Wrote 1828716544/1828716544 bytes to the inactive partition
2025-02-12 11:29:19 +0000 UTC info: State transition: update-store [Download_Enter] -> update-after-store [Download_Leave]
2025-02-12 11:29:22 +0000 UTC info: State transition: update-after-store [Download_Leave] -> mender-update-control-refresh-maps [none]
2025-02-12 11:29:22 +0000 UTC info: State transition: mender-update-control-refresh-maps [none] -> mender-update-control [none]
2025-02-12 11:29:22 +0000 UTC info: State transition: mender-update-control [none] -> update-install [ArtifactInstall]
2025-02-12 11:29:22 +0000 UTC info: Enabling partition with new image installed to be a boot candidate: 2
2025-02-12 11:29:24 +0000 UTC info: State transition: update-install [ArtifactInstall] -> mender-update-control-refresh-maps [none]
2025-02-12 11:29:24 +0000 UTC info: State transition: mender-update-control-refresh-maps [none] -> mender-update-control [none]
2025-02-12 11:29:25 +0000 UTC info: State transition: mender-update-control [none] -> reboot [ArtifactReboot_Enter]
2025-02-12 11:29:26 +0000 UTC info: Rebooting device(s)
2025-02-12 11:29:26 +0000 UTC info: Mender rebooting from active partition: /dev/mmcblk0p3
2025-02-12 11:29:27 +0000 UTC error: error forwarding from client to backend: websocket: close 1006 (abnormal closure): unexpected EOF
2025-02-12 11:29:27 +0000 UTC info: Daemon terminated with SIGTERM
2025-02-12 11:32:30 +0000 UTC info: Running Mender client version: 3.5.0
2025-02-12 11:32:30 +0000 UTC info: State transition: init [none] -> after-reboot [ArtifactReboot_Leave]
2025-02-12 11:32:30 +0000 UTC error: transient error: Reboot to the new update failed. Expected "upgrade_available" flag to be true but it was false. Either the switch to the new partition was unsuccessful, or the bootloader rolled back
2025-02-12 11:32:30 +0000 UTC info: State transition: after-reboot [ArtifactReboot_Leave] -> rollback [ArtifactRollback]
2025-02-12 11:32:31 +0000 UTC info: Performing rollback
2025-02-12 11:32:31 +0000 UTC info: No update available, so no rollback needed.
2025-02-12 11:32:31 +0000 UTC info: State transition: rollback [ArtifactRollback] -> rollback-reboot [ArtifactRollbackReboot_Enter]
2025-02-12 11:32:31 +0000 UTC info: Rebooting device(s) after rollback
2025-02-12 11:32:31 +0000 UTC info: Mender rebooting from inactive partition: /dev/mmcblk0p3
2025-02-12 11:32:31 +0000 UTC info: Daemon terminated with SIGTERM
2025-02-12 11:35:23 +0000 UTC info: Running Mender client version: 3.5.0
2025-02-12 11:35:23 +0000 UTC info: Mender shut down in state: rollback-reboot
2025-02-12 11:35:23 +0000 UTC info: State transition: init [none] -> verify-rollback-reboot [ArtifactRollbackReboot_Leave]
2025-02-12 11:35:24 +0000 UTC info: State transition: verify-rollback-reboot [ArtifactRollbackReboot_Leave] -> after-rollback-reboot [ArtifactRollbackReboot_Leave]
2025-02-12 11:35:25 +0000 UTC info: State transition: after-rollback-reboot [ArtifactRollbackReboot_Leave] -> update-error [ArtifactFailure]
2025-02-12 11:35:25 +0000 UTC info: State transition: update-error [ArtifactFailure] -> cleanup [Error]
2025-02-12 11:35:26 +0000 UTC info: State transition: cleanup [Error] -> update-status-report [none]
2025-02-12 11:35:26 +0000 UTC info: Device unauthorized; attempting reauthorization
2025-02-12 11:35:27 +0000 UTC info: Output (stderr) from command "/usr/share/mender/identity/mender-device-identity": using interface /sys/class/net/eth0
2025-02-12 11:35:27 +0000 UTC info: successfully received new authorization data from server https://hosted.mender.io
2025-02-12 11:35:27 +0000 UTC info: Local proxy started
2025-02-12 11:35:27 +0000 UTC info: Reauthorization successful
Hi @Vladimir,
Can you try to find out what is happening during the reboot? Looking at the timestamps 11:29-11:32, this is almost certainly a two-reboot situation and therefore the bootloader rolls back. Can you watch this process on the serial terminal and find out what u-boot and eventually Linux’ start up are doing?
Greetz,
Josef
@TheYoctoJester Hello. I use two different UARTs for u-boot and kernel output. I caught both. Garbage data after Starting kernel ... is the result of UART role change, and it is OK. It looks like the next lines are crucial:
## Booting kernel from Legacy Image at 00080000 ...
Image Name: Linux-6.6.22-v7l
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 8518280 Bytes = 8.1 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2eff4000
Booting using the fdt blob at 0x2eff4000
Loading Kernel Image
Image too large: increase CONFIG_SYS_BOOTM_LEN
Must RESET board to recover
resetting ...
bo
Kernel log is too long and uninformative, but I can post it too if it is needed.
Thanks.
Full bootloader.log:
U-Boot 2020.01 (Jan 06 2020 - 20:56:31 +0000)
DRAM: 3.9 GiB
RPI 4 Model B (0xd03114)
MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 2 1 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
300 bytes read in 10 ms (29.3 KiB/s)
## Executing script at 02400000
switch to partitions #0, OK
mmc0 is current device
7348392 bytes read in 1559 ms (4.5 MiB/s)
## Booting kernel from Legacy Image at 00080000 ...
Image Name: Linux-5.15.92-v7l
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 7348328 Bytes = 7 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2eff4000
Booting using the fdt blob at 0x2eff4000
Loading Kernel Image
Using Device Tree in place at 2eff4000, end 2f002f51
Starting kernel ...
~VRN~VRM~SHY~SLT~$S{~$Vw~a$Wu~$Xs~ $Yq~
*Sp~*Vl~*Wj~*Xh~*Yf~AOX~APV~ARS~AVN~AZI~BD]~BHX~BIV~BPN~BTI~C8c~CCW~ET~ CIO~ CRE~ CTB~ D0d~ D1b~!D2`~"D3^~#D4\~$D5Z~%D6X~&D7V~'D8T~(D9R~)DCG~*DDE~+DEC~,DH?~-DL:~.DM8~/DO5~0EAA~1EE<~2EO1~3ET+~4FK2~5GT'~6IC5~7ID3~8IR$~9JN&~:JV ~;KT ~<KY~=LT~>LX~?LY~@LZ~AM09~BM17~CNB$~DNH ~ENIFNJ~GNK~HNO~INT~JNW~KP0,~LP1*~MP2(~NP3&~OP4$~PPD~QPL
~RPO~SPR~TPS~URK~VRO~WRPþ~XSA~YSB ~ZSCa~[SD~\SE~]SMú~^SNø~_SOö~`SPô~aSTï~bTOò~cUSì~dV+~eVRê~fWHò~gZSã~hNRï~i¢B FþDB~j¢B ²ÿþDB)~k¢B D½ÿþDBö~l¢B GkÿþDBD~mNCù~n¢B FþNC~o¢B ²ÿþNC~p¢B D½ÿþNCæ~q¢B GkÿþNC4~rCHú~sOIì~tNCò~u¢B FþNC~v¢B ²ÿþNC~w¢B D½ÿþNCß~x¢B GkÿþNC-~yCHó~zOIå~{NCë~|¢B FþNCú~}¢B ²ÿþNC~~¢B D½ÿþNCØ~¢B GkÿþNC&~CHì~OIÞ~NCä~¢B FþNCó~¢B ²ÿþNC~
¢B D½ÿþNCÑ~¢B GkÿþNC ~CHå~OI×~NCÝ~¢B FþNCì~¢B ²ÿþNCý~¢B D½ÿþNCÊ~¢B GkÿþNC~CHÞ~OIÐ~NCÖ~¢B FþNCå~¢B ²ÿþNCö~¢B D½ÿþNCÃ~¢B GkÿþNC~CH×~OIÉ
U-Boot 2020.01 (Jan 06 2020 - 20:56:31 +0000)
DRAM: 3.9 GiB
RPI 4 Model B (0xd03114)
MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Saving Environment to MMC... Writing to redundant MMC(0)... OK
Hit any key to stop autoboot: 2 1 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
300 bytes read in 10 ms (29.3 KiB/s)
## Executing script at 02400000
switch to partitions #0, OK
mmc0 is current device
8518344 bytes read in 1820 ms (4.5 MiB/s)
## Booting kernel from Legacy Image at 00080000 ...
Image Name: Linux-6.6.22-v7l
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 8518280 Bytes = 8.1 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2eff4000
Booting using the fdt blob at 0x2eff4000
Loading Kernel Image
Image too large: increase CONFIG_SYS_BOOTM_LEN
Must RESET board to recover
resetting ...
bo
U-Boot 2020.01 (Jan 06 2020 - 20:56:31 +0000)
DRAM: 3.9 GiB
RPI 4 Model B (0xd03114)
MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Saving Environment to MMC... Writing to MMC(0)... sdhci_send_command: MMC: 0 busy timeout increasing to: 200 ms.
OK
Warning: Bootlimit (1) exceeded. Using altbootcmd.
Hit any key to stop autoboot: 2 1 0
Saving Environment to MMC... Writing to redundant MMC(0)... OK
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
300 bytes read in 10 ms (29.3 KiB/s)
## Executing script at 02400000
switch to partitions #0, OK
mmc0 is current device
7348392 bytes read in 1553 ms (4.5 MiB/s)
## Booting kernel from Legacy Image at 00080000 ...
Image Name: Linux-5.15.92-v7l
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 7348328 Bytes = 7 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2eff4000
Booting using the fdt blob at 0x2eff4000
Loading Kernel Image
Using Device Tree in place at 2eff4000, end 2f002f51
Starting kernel ...
~VRN~VRM~SHY~SLT~$S{~$Vw~a$Wu~$Xs~ $Yq~
*Sp~*Vl~*Wj~*Xh~*Yf~AOX~APV~ARS~AVN~AZI~BD]~BHX~BIV~BPN~BTI~C8c~CCW~ET~ CIO~ CRE~ CTB~ D0d~ D1b~!D2`~"D3^~#D4\~$D5Z~%D6X~&D7V~'D8T~(D9R~)DCG~*DDE~+DEC~,DH?~-DL:~.DM8~/DO5~0EAA~1EE<~2EO1~3ET+~4FK2~5GT'~6IC5~7ID3~8IR$~9JN&~:JV ~;KT ~<KY~=LT~>LX~?LY~@LZ~AM09~BM17~CNB$~DNH ~ENIFNJ~GNK~HNO~INT~JNW~KP0,~LP1*~MP2(~NP3&~OP4$~PPD~QPL
~RPO~SPR~TPS~URK~VRO~WRPþ~XSA~YSB ~ZSCa~[SD~\SE~]SMú~^SNø~_SOö~`SPô~aSTï~bTOò~cUSì~dV+~eVRê~fWHò~gZSã~hNRï~i¢B FþDB~j¢B ²ÿþDB)~k¢B D½ÿþDBö~l¢B GkÿþDBD~mNCù~n¢B FþNC~o¢B ²ÿþNC~p¢B D½ÿþNCæ~q¢B GkÿþNC4~rCHú~sOIì~tNCò~u¢B FþNC~v¢B ²ÿþNC~w¢B D½ÿþNCß~x¢B GkÿþNC-~yCHó~zOIå
U-Boot 2020.01 (Jan 06 2020 - 20:56:31 +0000)
DRAM: 3.9 GiB
RPI 4 Model B (0xd03114)
MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from MMC... OK
In: serial
Out: serial
Err: serial
Net: Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot: 2 1 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
300 bytes read in 10 ms (29.3 KiB/s)
## Executing script at 02400000
switch to partitions #0, OK
mmc0 is current device
7348392 bytes read in 1559 ms (4.5 MiB/s)
## Booting kernel from Legacy Image at 00080000 ...
Image Name: Linux-5.15.92-v7l
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 7348328 Bytes = 7 MiB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 2eff4000
Booting using the fdt blob at 0x2eff4000
Loading Kernel Image
Using Device Tree in place at 2eff4000, end 2f002f51
Starting kernel ...
This clearly is the killer.
So the new kernel on scarthgap exceeds the memory which u-boot has allocated for loading it. Good news is that it then fails to boot, and rollback saves you. Bad news is that this is probably hard to fix in place, as reflashing an updated version of u-boot on live devices usually creates a single point of failure.
The most practical advice would be to inspect your kernel configuration, and see if you can trim it down enough to fit into u-boots loading region. Usually the default kernel configurations leave quite some leeway for such.
Greetz,
Josef