Discussion:
Kernel 6.9 fails to boot with "can't boot dump kernel from OF"
(too old to reply)
Reimar Döffinger
2024-07-06 15:10:01 UTC
Permalink
Hi!
The newest 6.9 powerpc kernel build seems to be incompatible with OpenFirmware boot,
so boot fails on my PowerPC macMini.
The error message is
"Error: You can't boot a kdump kernel from OF!"
The error message seems not entirely accurate, it seems the issue is that
CONFIG_PHYSICAL_START
is no longer 0, which probably comes from
CONFIG_CRASH_DUMP=y
being set.
Can this be reverted?

Thanks,
Reimar
John Paul Adrian Glaubitz
2024-07-06 15:20:01 UTC
Permalink
Hi Reimar,
Post by Reimar Döffinger
Hi!
The newest 6.9 powerpc kernel build seems to be incompatible with OpenFirmware boot,
so boot fails on my PowerPC macMini.
The error message is
"Error: You can't boot a kdump kernel from OF!"
The error message seems not entirely accurate, it seems the issue is that
CONFIG_PHYSICAL_START
is no longer 0, which probably comes from
CONFIG_CRASH_DUMP=y
being set.
Can this be reverted?
Could you verify that this change actually fixes the problem? This would save me some work.

Also, we need to figure out whether this change was made upstream or in Debian.

Adrian
Reimar Döffinger
2024-07-06 15:50:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
Hi Reimar,
Post by Reimar Döffinger
Hi!
The newest 6.9 powerpc kernel build seems to be incompatible with OpenFirmware boot,
so boot fails on my PowerPC macMini.
The error message is
"Error: You can't boot a kdump kernel from OF!"
The error message seems not entirely accurate, it seems the issue is that
CONFIG_PHYSICAL_START
is no longer 0, which probably comes from
CONFIG_CRASH_DUMP=y
being set.
Can this be reverted?
Could you verify that this change actually fixes the problem? This would save me some work.
I checked the kernel source, the error message is under a if (PHYSICAL_START > 0), so that I am quite certain is the issue.
Actually testing means compiling the kernel, which will take quite some while.
Post by John Paul Adrian Glaubitz
Also, we need to figure out whether this change was made upstream or in Debian.
The error check etc is not new.
I did also diff the config of the working 6.7 kernel and the non-working 6.9 kernel.
Whether upstream changed the option defaults I do not know, but Debian definitely decides on the config options used in the end.
But it seems most likely that CONFIG_CRASH_DUMP was enabled in Debian.

Best regards,
Reimar
Reimar Döffinger
2024-07-06 16:10:02 UTC
Permalink
Post by Reimar Döffinger
Post by John Paul Adrian Glaubitz
Hi Reimar,
Post by Reimar Döffinger
Hi!
The newest 6.9 powerpc kernel build seems to be incompatible with OpenFirmware boot,
so boot fails on my PowerPC macMini.
The error message is
"Error: You can't boot a kdump kernel from OF!"
The error message seems not entirely accurate, it seems the issue is that
CONFIG_PHYSICAL_START
is no longer 0, which probably comes from
CONFIG_CRASH_DUMP=y
being set.
Can this be reverted?
Could you verify that this change actually fixes the problem? This would save me some work.
I checked the kernel source, the error message is under a if (PHYSICAL_START > 0), so that I am quite certain is the issue.
Actually testing means compiling the kernel, which will take quite some while.
I can at least confirm that unsetting CONFIG_CRASH_DUMP in menuconfig results in CONFIG_PHYSICAL_START to revert to 0.
So it seems very likely that this single config setting is the root cause.
Reimar Döffinger
2024-07-07 20:30:02 UTC
Permalink
Post by Reimar Döffinger
Post by Reimar Döffinger
Post by John Paul Adrian Glaubitz
Hi Reimar,
Post by Reimar Döffinger
Hi!
The newest 6.9 powerpc kernel build seems to be incompatible with OpenFirmware boot,
so boot fails on my PowerPC macMini.
The error message is
"Error: You can't boot a kdump kernel from OF!"
The error message seems not entirely accurate, it seems the issue is that
CONFIG_PHYSICAL_START
is no longer 0, which probably comes from
CONFIG_CRASH_DUMP=y
being set.
Can this be reverted?
Could you verify that this change actually fixes the problem? This would save me some work.
I checked the kernel source, the error message is under a if (PHYSICAL_START > 0), so that I am quite certain is the issue.
Actually testing means compiling the kernel, which will take quite some while.
I can at least confirm that unsetting CONFIG_CRASH_DUMP in menuconfig results in CONFIG_PHYSICAL_START to revert to 0.
So it seems very likely that this single config setting is the root cause.
Taking a step back, can someone explain how CONFIG_CRASH_DUMP ended up enabled in the powerpc kernel?
Looking at https://salsa.debian.org/kernel-team/linux/-/tree/master/debian?ref_type=heads it does not seem to be enabled.
There is a changelog entry from 2018 that says [powerpc,ppc64el,ppc64] Enable CRASH_DUMP (Closes: #883432)
But that seems just incorrect, that change only modified debian/config/kernelarch-powerpc/config-arch-64
So I am not sure it's intentional that this setting is enabled?
Anyone understanding what happened there?

Best regards,
Reimar

John Paul Adrian Glaubitz
2024-07-06 16:20:01 UTC
Permalink
Hi Reimar,
Post by Reimar Döffinger
Post by John Paul Adrian Glaubitz
Could you verify that this change actually fixes the problem? This would save me some work.
I checked the kernel source, the error message is under a if (PHYSICAL_START > 0), so that I am quite certain is the issue.
Actually testing means compiling the kernel, which will take quite some while.
You should cross-compile the test kernel, of course.

I‘m not expecting you to build the kernel on your 32-bit PowerPC machine, that would take ages.
Post by Reimar Döffinger
https://mirrors.edge.kernel.org/pub/tools/crosstool/
Adrian
Reimar Döffinger
2024-07-07 16:30:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
Hi Reimar,
Post by Reimar Döffinger
Post by John Paul Adrian Glaubitz
Could you verify that this change actually fixes the problem? This would save me some work.
I checked the kernel source, the error message is under a if (PHYSICAL_START > 0), so that I am quite certain is the issue.
Actually testing means compiling the kernel, which will take quite some while.
You should cross-compile the test kernel, of course.
I‘m not expecting you to build the kernel on your 32-bit PowerPC machine, that would take ages.
Setting up cross-compilation takes my time, compiling locally only the computer's, thus I am sticking to the latter...
Anyway, yes, just disabling the crash dump option fixes the boot.
It MIGHT be possible that selecting RELOCATEABLE would also work, but I suspect
it would have a performance impact and just going back to the previous,
working config seems a better option to me for the PPC port...

Best regards,
Reimar
John Paul Adrian Glaubitz
2024-07-07 16:30:01 UTC
Permalink
Post by John Paul Adrian Glaubitz
Hi Reimar,
Post by Reimar Döffinger
Post by John Paul Adrian Glaubitz
Could you verify that this change actually fixes the problem? This would save me some work.
I checked the kernel source, the error message is under a if (PHYSICAL_START > 0), so that I am quite certain is the issue.
Actually testing means compiling the kernel, which will take quite some while.
You should cross-compile the test kernel, of course.
I‘m not expecting you to build the kernel on your 32-bit PowerPC machine, that would take ages.
Setting up cross-compilation takes my time, compiling locally only the computer's, thus I am sticking to the latter...
Setting up cross-compilation involves downloading the tarball for your host-target combination, extracting it and adding the path to the binaries to your PATH variable.

It’s extremely easy to cross-compile a kernel these days.

Adrian
Loading...