On Mon, Jun 2, 2025 at 4:09 PM Hans de Goede <hdego...@redhat.com> wrote: > I'm not sure why you are specifying apci=off in the first place?
On the system where I started, I met some ACPI related errors in the kernel ring buffer. Disabling the problematic functionality often works as a good starting ground for me when debugging. > Most modern (even old modern) systems all need ACPI for various reasons. Sure. When I disable kernel functionality, I expect some system functionality to be missing. However - and that is my main point - I also expect it to be traceable, so I would be able to tell from the running system that something does not work because of this missing functionality. > Generally speaking passing any extra kernel command line options other > then the default "root=... ro rhgb quiet" is a bad idea unless you have > a very specific reason for doing this; or were asked to try a kernel > cmdline option by a kernel-developer while debugging some option. In theory? Maybe. In practice, hardly. :) Common situations where I permanently set the parameters are 1) It was based on a fix suggestion from the kernel itself. (e.g. 'tsc=unstable') 2) I need to fix component specific issues (display problems, freezening problems, wrong GPU used ... commonly related to graphic drivers) 3) I need to workaround an issue very specific to the machine (e.g. the 'acpi' I have on my hand now) This is GNU/Linux. The configuration of everything is here to be tampered with, tried, tested, tuned, ... . I write my own bootloader configuration because the 'stock' one doesn't work for me. And I come here to ask for wisdom on how stuff works and how to debug when a conventional approach is falling short; instead of just asking others to fix stuff I broke. The main reason why I write to the devel@ list, instead of the users@ list is the question I opened - is it expected that 'acpi=off' would break all BIOS installation (but not UEFI) in the same way? > As for acpi=on helping, "on" is not a valid value for acpi="val", > so that likely is some false positive related to no longer specifying > acpi=off. Thanks for the heads-up. I re-checked the documentation https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt and now I see that the 'on' value is architecture-specific "on -- enable ACPI but allow fallback to DT [arm64,riscv64]" That adds to the mystery, why it fixed the issue on the machine. Michal -- Michal Schorm Software Engineer Databases Team Red Hat -- On Mon, Jun 2, 2025 at 4:09 PM Hans de Goede <hdego...@redhat.com> wrote: > > Hi Michal, > > On 2-Jun-25 15:28, Michal Schorm wrote: > > I maintain a fleet of very old 64-bit laptops in various conditions > > for events for youth. > > I use a set of custom installation and configuration scripts to > > install Fedora + Cinnamon DE. > > > > When debugging an issue on two machines, I discovered that using > > 'acpi=off' as a kernel parameter breaks every BIOS installation I > > have, and some UEFI too. > > > > Some UEFI installations just have low resolution, or respond noticeably > > slower. > > Some UEFI and some BIOS installations freeze somewhere during the boot > > sequence. (haven´t examined more closely) > > > > And most of the BIOS installations boot, but fail to display the GUI. > > The TTY1 ends in some non-interactive state, but not frozen (still can > > display incoming systemd journal messages etc.). I can switch to other > > TTYs, where there is a TUI login prompt and the system is normally > > accessible from there. > > > > I carefully examined the kernel messages and systemd journal, both > > with extra verbosity levels. > > Nothing seems wrong there. The multi-user.target was reached, all > > services are fine, none related errors or unusual warnings, all > > necessary packages seem to be installed, ... > > > > My first question is whether it is expected that 'acpi=off' will > > prevent the BIOS installations from displaying GUI. Or if any of you > > can reproduce at all. > > > > My second question is how to further debug and where to look. > > Most of the BIOS systems work completely normal when 'acpi=off' is NOT > > specified. > > I fixed one machine by setting 'acpi=on' (which leads to a different > > result than not specifying the acpi kernel option value at all) and I > > have one machine that shows the exact same symptom, but the cause > > doesn't seem to be 'acpi=...' related, as any possible value won't > > help. > > I'm not sure why you are specifying apci=off in the first place? > > Most modern (even old modern) systems all need ACPI for various reasons. > > Generally speaking passing any extra kernel commandline options other > then the default "root=... ro rhgb quiet" is a bad idea unless you have > a very specific reason for doing this; or were asked to try a kernel > cmdline option by a kernel-developer while debugging some option. > > As for acpi=on helping, "on" is not a valid value for acpi="val", > so that likely is some false positive related to no longer specifying > acpi=off. > > TL;DR: do not use acpi=off, actually do not use any special kernel > commandline arguments at all. > > Regards, > > Hans > -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
