On 11/13/21 1:39 PM, Parodper wrote:
Hi,
I am currently on Debian with Linux 5.14.0. I wanted to try OpenSUSE, so I first downloaded the Tumbleweed GNOME Live image. Everything worked. Then I tried to install Tumbleweed. The installer correctly detected my trackpad, wifi card, and everything else.
However, after the install nothing worked. A normal boot would get stuck on «Generating Static Devices» (paraphrased), so the only way to boot is to disable ACPI. This breaks a lot more things, but at least gets me to a prompt.
My question would be; why does it only fail on the on-disk install, but work literally everywhere else?
Thanks.
I don't know why it works during the installation process but not after installation to storage. I have seen this happen (although not with openSUSE) when an installer loads a wide swath of kernel modules and the broadest possible settings to do the install but some specific to the installation hardware are not retained post-install. Again, no idea why. Does your Debian installation have kernel parameters being passed by grug2? Have you compared the kernel modules being loaded between Debian and TW? Is your Debian system using a fairly old kernel (as is typical for Debian)? Sometimes acpi problems arise with older bios software, and even with some not so old. Not infrequently there are acpi bugs in the bios software. E.g., this workstation is a couple years old using a nice MSI mobo and Ryzen cpu with a very comprehensive bios interface. Yet at boot, the kernel finds 4 bios code bugs, and even suggests a workaround boot kernel parameter. Check whether your machine has a bios update. And have you used dmesg and the logs to see what specific acpi errors the kernel is throwing? Also, at kernel.org there are about ~30 acpi kernel parameters for granular control of acpi. For example, you can tell the kernel to be forgiving to hardware that is not strictly acpi compliant, or to avoid using acpi for irq routing (which can conflict with kernel irq assignment). You can tell the kernel to use a different acpi table (there is more than one), you can check for conflicts between acpi and drivers, and you can add debugging. While this is a lot of stuff to consider, sometimes a logged error message will point you to where the issue is specifically and from that you can determine the kernel parameter needed.. Finally, another tack would be to erase TW and install the newest Ubuntu or Fedora, and see what happens. If that installation works properly, looks for what is different, e.g., the grub2 kernel command. HTH. --dg 15.2 & 15.3KDE