Bad Linux ARM64 Image magic
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux-raspi-5.4 (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Bionic |
Fix Released
|
High
|
Juerg Haefliger |
Bug Description
[Impact]
On all pi devices we are testing (rpi3, 3b+, cm3, rpi4, etc...) when refreshing the kernel snap to the 5.4 kernel in 18-pi (r333), it fails to boot. Here's the serial log on the failed boot from one of those devices:
Hit any key to stop autoboot: 0
WARNING at /build/
WARNING at /build/
switch to partitions #0, OK
mmc0(part 0) is current device
LOADBOOTENV
Running uenvcmd ...
ENVCMD
Saving Environment to FAT... OK
8624908 bytes read in 367 ms (22.4 MiB/s)
3947036 bytes read in 171 ms (22 MiB/s)
67581 bytes read in 22 ms (2.9 MiB/s)
Bad Linux ARM64 Image magic!
Armhf seems to be booting just fine after the refresh.
[Test Case]
See above.
[Where Problems Could Occur]
The worst that can probably happen is that the device won't boot, which is the current behavior. Well, since the kernel image is bigger I guess we could run out of disk space on the vfat partition...
description: | updated |
description: | updated |
Changed in linux-raspi-5.4 (Ubuntu Bionic): | |
status: | New → Fix Committed |
Changed in linux-raspi-5.4 (Ubuntu): | |
status: | New → Invalid |
Changed in linux-raspi-5.4 (Ubuntu Bionic): | |
assignee: | nobody → Juerg Haefliger (juergh) |
importance: | Undecided → High |
I also noticed just now that this kernel from the 20 track does seem to work fine on uc20 systems:
pi-kernel 5.4.0-1042.46 331 20/beta