• rufus
    2·
    10 months ago

    Alright. You should also play with the options for the framebuffer, drm and video modes or forcefully enable some outputs. (I forgot how to do all of that.)

    • nvidia-drm.modeset …
    • video=“vesafb”
    • …

    I’d skip the general acpi=off since that only causes more issues and isn’t feasable in the long run anyways. You need to find the option that specifically fixes only the issue with that one component that isn’t working correctly.

    Another idea: Maybe you can find the error message. Can you perhaps login via SSH from another machine? This would allow you to run dmesg while your screen is black. Maybe the error shows up in the dmesg kernel messages and you can take it from there. (Some installers even allow login from remote, that is a bit tricky but should be documented somewhere with the distro.)

    • Varen@kbin.socialOP
      2·
      10 months ago

      @rufus

      I will try and report back if I can get the dmesg output. But since I guess that the USB gets cut off right before something happens I guess there simply isn‘t.

      Will try with the installed Nobara and see, if dmesg catches anything up at all

      • rufus
        2·
        10 months ago

        But once you’re trying to extract the log, you need to start it with acpi on. I mean we want to see that error happening.

        Maybe paste the whole log somewhere on a pastebin service… If you manage to do it… Sometimes it’s not an obvious error message. (…But something like the HDMI port being turned off…)

        • Varen@kbin.socialOP
          2·
          10 months ago

          @rufus

          I‘m afraid that it‘s where it will fail, cause I can‘t get it to work with acpi on

          I thought of getting the „bad installed“ (acpi=off) OS, let it start with acpi on and afterwards grab the logs again with acpi off, but don‘t know if that will work…

          • rufus
            2·
            10 months ago

            I don’t know what gets written to disk on which distro and which logs are just kept in memory. dmesg alone just shows the current boot. I think if you’re doing it that way journalctl --dmesg --boot=-1 would be the correct command. That should do it.

              • rufus
                2·
                10 months ago

                Good luck! 😀

                (FYI: You can skip mentioning names that way, a direct reply will show up on Lemmy. And if you want to mention someone, you’d need to add the instance name for it to have an effect. i.e. @rufus@discuss.tchncs.de )

                • Varen@kbin.socialOP
                  2·
                  10 months ago

                  Yeah thank you, I really hope we‘ll get some progress.

                  (Not doing it on purpose, it‘s just how kbin behaves 😅 really thinking about dropping it and give lemmy a try. Originally decided for kbin because I wanted both worlds but since the behaviour is so strange …yeah 😉)

                • Varen@kbin.socialOP
                  2·
                  10 months ago

                  Unfortunately nothing. Did install - reboot with acpi=off, reboot with no acpi parameter, reboot with acpi=off

                  Dmesg shows for the boot=-1 the first boot after install with acpi=off

                  No log for the try without acpi parameter 😢😢

                  Booting with acpi=off shows many logs with „IRQ not found for nvidia …“ (in the meaning, not wordly).

                  Edit: can‘t find an irq for your nvidia card

                  Edit 2: found a boot.log file. When trying to boot without acpi=off then no log is written, the bootprocess doesn‘t even start. From this point of view I‘d guess a Problem with UEFI. Still no idea what and where, but it‘s not graphics related if the bootprocess doesn‘t start at all… what d‘you think?

                  • rufus
                    2·
                    10 months ago

                    I think you can safely ignore all the errors that happen while acpi=off. That will switch all kinds of things around and the operating system can’t set up the hardware properly without it, so it is to be expected that half the things crap out and throw error messages. Could be a red herring anyways.

                    Are you sure Secure Boot is switched to “Other OS”? (see https://www.asus.com/support/faq/1049829/ ) You could verify that with the ‘msinfo32’ in the guide.

                    And I’m really not sure if it’s the UEFI. From your description it seems you’re getting to the boot loader and something happens after… Maybe try not messing with the acpi, but removing the “quiet” and “splash” if they’re there and adding “nomodeset” instead. After you hit Enter (or Ctrl-X with Grub) the early kernel messages should pop up. Something with loading and initrd or like that. What happens then? Does it load the kernel? Do additional log messages with a boot process appear? (If it’s too fast, you can try a video recording of your screen with your phone.)