Hi,
All this talk about Wandboard Quad D1 is because I'm trying to upgrade an existing device currently running on a Wandboard Dual C1. It's a system that started as Fedora 25 and was upgraded to Fedora 31 (via dnf system-upgrade). It's been running fine on the Dual. I upgraded the U-boot and it still runs fine on the C1, however if I try to use this SD card in the Quad-D1 I get this during boot:
[ 6.841555] Freeing unused kernel memory: 2048K [ 6.848283] ------------[ cut here ]------------ [ 6.852985] WARNING: CPU: 2 PID: 1 at arch/arm/mm/dump.c:248 note_page+0x1604 [ 6.860609] arm/mm: Found insecure W+X mapping at address 0xf0879000 [ 6.866994] Modules linked in: [ 6.870093] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.4.17-200.fc31.armv7h1 [ 6.877494] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 6.884062] [<c0311264>] (unwind_backtrace) from [<c030b744>] (show_stack+0x) [ 6.891825] [<c030b744>] (show_stack) from [<c0b2d580>] (dump_stack+0xb4/0xd) [ 6.899068] [<c0b2d580>] (dump_stack) from [<c034d5bc>] (__warn+0xdc/0xf8) [ 6.905958] [<c034d5bc>] (__warn) from [<c034d96c>] (warn_slowpath_fmt+0x70/) [ 6.913455] [<c034d96c>] (warn_slowpath_fmt) from [<c03197a8>] (note_page+0x) [ 6.921383] [<c03197a8>] (note_page) from [<c0319a34>] (walk_pgd+0xc8/0xe0) [ 6.928357] [<c0319a34>] (walk_pgd) from [<c0319b10>] (ptdump_check_wx+0x58/) [ 6.935858] [<c0319b10>] (ptdump_check_wx) from [<c0b4182c>] (kernel_init+0x) [ 6.943706] [<c0b4182c>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14) [ 6.951281] Exception stack(0xee943fb0 to 0xee943ff8) [ 6.956339] 3fa0: 00000000 00000000 00000 [ 6.964524] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000 [ 6.972708] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 6.979365] ---[ end trace eb98c3200f90d0b6 ]--- [ 6.984352] Checked W+X mappings: FAILED, 1 W+X pages found [ 6.989965] rodata_test: test data was not read only
and the system doesn't come up completely.
If I used a fresh Fedora-Minimal-31 on the Quad-D1 (or the Dual-C1) it works fine. Currently the main difference, as far as I can see, is that there is a different kernel. The working system is running 5.3.7-301.fc31.armv7hl whereas the non-working is running 5.4.17-200.fc31.armv7hl.
I am currently working on upgrading the Fedora-Minimal to a more recent kernel to try to reproduce the problem; if it doesn't reproduce I will also try to upgrade the existing system. If it DOES reproduce then clearly there's something with the F25->F31 filesystem, and I will have to migrate everything to a fresh install :(
I'll let you know in a couple hours how the testing goes -- unless you've seen this before and have an easy fix?
-derek
All this talk about Wandboard Quad D1 is because I'm trying to upgrade an existing device currently running on a Wandboard Dual C1. It's a system that started as Fedora 25 and was upgraded to Fedora 31 (via dnf system-upgrade). It's been running fine on the Dual. I upgraded the U-boot and it still runs fine on the C1, however if I try to use this SD card in the Quad-D1 I get this during boot:
[ 6.841555] Freeing unused kernel memory: 2048K [ 6.848283] ------------[ cut here ]------------ [ 6.852985] WARNING: CPU: 2 PID: 1 at arch/arm/mm/dump.c:248 note_page+0x1604 [ 6.860609] arm/mm: Found insecure W+X mapping at address 0xf0879000 [ 6.866994] Modules linked in: [ 6.870093] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.4.17-200.fc31.armv7h1 [ 6.877494] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 6.884062] [<c0311264>] (unwind_backtrace) from [<c030b744>] (show_stack+0x) [ 6.891825] [<c030b744>] (show_stack) from [<c0b2d580>] (dump_stack+0xb4/0xd) [ 6.899068] [<c0b2d580>] (dump_stack) from [<c034d5bc>] (__warn+0xdc/0xf8) [ 6.905958] [<c034d5bc>] (__warn) from [<c034d96c>] (warn_slowpath_fmt+0x70/) [ 6.913455] [<c034d96c>] (warn_slowpath_fmt) from [<c03197a8>] (note_page+0x) [ 6.921383] [<c03197a8>] (note_page) from [<c0319a34>] (walk_pgd+0xc8/0xe0) [ 6.928357] [<c0319a34>] (walk_pgd) from [<c0319b10>] (ptdump_check_wx+0x58/) [ 6.935858] [<c0319b10>] (ptdump_check_wx) from [<c0b4182c>] (kernel_init+0x) [ 6.943706] [<c0b4182c>] (kernel_init) from [<c03010e8>] (ret_from_fork+0x14) [ 6.951281] Exception stack(0xee943fb0 to 0xee943ff8) [ 6.956339] 3fa0: 00000000 00000000 00000 [ 6.964524] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000 [ 6.972708] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 6.979365] ---[ end trace eb98c3200f90d0b6 ]--- [ 6.984352] Checked W+X mappings: FAILED, 1 W+X pages found [ 6.989965] rodata_test: test data was not read only
and the system doesn't come up completely.
If I used a fresh Fedora-Minimal-31 on the Quad-D1 (or the Dual-C1) it works fine. Currently the main difference, as far as I can see, is that there is a different kernel. The working system is running 5.3.7-301.fc31.armv7hl whereas the non-working is running 5.4.17-200.fc31.armv7hl.
I am currently working on upgrading the Fedora-Minimal to a more recent kernel to try to reproduce the problem; if it doesn't reproduce I will also try to upgrade the existing system. If it DOES reproduce then clearly there's something with the F25->F31 filesystem, and I will have to migrate everything to a fresh install :(
I'll let you know in a couple hours how the testing goes -- unless you've seen this before and have an easy fix?
I've not seen it before but what I recommend is to go to a generic initrd so it pulls in all the drivers, move over to the new device and then allow it to go back to a host specific initrd.
I suspect there's slightly different HW requirements.
To do this install the dracut-config-generic package and reinstall or upgrade the kernel, it'll be slower to boot, make sure it boots on the current device, move to the new one.
Once it's running on the new one remove the package and the next kernel will go back to a host specific initrd with the specific initrd for the new HW.
Peter
On Fri, April 17, 2020 11:47 am, Peter Robinson wrote: [snip]
I'll let you know in a couple hours how the testing goes -- unless you've seen this before and have an easy fix?
Upgrading the Fedora-Minimal-31 system to 5.5.16-200.fc31.armv7hl and it's still working.
I've not seen it before but what I recommend is to go to a generic initrd so it pulls in all the drivers, move over to the new device and then allow it to go back to a host specific initrd.
See https://bugzilla.redhat.com/show_bug.cgi?id=1698208
I suspect there's slightly different HW requirements.
Could be. I can try that. Right now I'm upgrading the "older" system to 5.5.16, so I'll test that first, but if that fails then I can go your route and "dnf reinstall" the kernel package after adding the dracut-config-generic package.
To do this install the dracut-config-generic package and reinstall or upgrade the kernel, it'll be slower to boot, make sure it boots on the current device, move to the new one.
Once it's running on the new one remove the package and the next kernel will go back to a host specific initrd with the specific initrd for the new HW.
Peter
Thanks,
-derek
Peter,
On Fri, April 17, 2020 12:09 pm, Derek Atkins wrote: [snip]
Could be. I can try that. Right now I'm upgrading the "older" system to 5.5.16, so I'll test that first, but if that fails then I can go your route and "dnf reinstall" the kernel package after adding the dracut-config-generic package.
To do this install the dracut-config-generic package and reinstall or upgrade the kernel, it'll be slower to boot, make sure it boots on the current device, move to the new one.
Once it's running on the new one remove the package and the next kernel will go back to a host specific initrd with the specific initrd for the new HW.
So I had to dnf reinstall kernel{,-core,-modules}-5.5.16-200.fc31.armv7hl to get it to rebuild the initramfs. Just reinstalling 'kernel-..' was not sufficient.
However it was also not sufficient to get past this issue. I still have the same failure, same oops, and the system doesn't come up. So there must be something with the old disk or something about upgrading from F25 -> F31 that leaves something behind that this device doesn't like. If nothing else, it does not come up on the network using the old disk in the new board.
So the generic initramfs is not sufficient. I guess if I want to swap hardware I need to start from a fresh SD card F31-Minimal and migrate all my configuration. :-(
Any other suggestions?
-derek
-
Derek Atkins -
Peter Robinson