Graphics Config Problem--New Z790-I System w RTX-4060

[GaryScottMartin]

System Type: Desktop

MOTHERBOARD: ROG STRIX Z790-I

BIOS Version: 2301 (2024/05/30)

CPU: i7-14700K

RAM: 32GB (G.SKILL Trident Z5 [PC5 48000])

STORAGE: Samsung NVME 990 Pro (4TB)

GPU: Dual GeForce RTX 4060 EVO OC Edition 8GB GDDR6

Power Supply: CORSAIR SF750

Monitor: LG 30" Ultrawide (21:9)

This desktop system is dual-booted: Arch Linux and Windows 10. I used Terabyte Unlimited's BootItUEFI as its boot manager.

During the initial setup, I was getting no output from the GPU and I noticed that the GPU fans started at boot, but shut down a few seconds later. I switched to the iGPU HDMI output and had no problems until I started trying to switch to the GPU as the primary graphics output.

While both Arch Linux and Windows are set up with the GPU as the primary graphics device, I noticed that graphics output disappears from the GPU at times during the boot/reboot. I currently have HDMI cables installed between both the iGPU output and the monitor and the GPU output and the monitor. I can either switch back and forth between inputs or display both inputs side-by-side.

At this point, I would like to disable the iGPU and use only the GPU. In System Agent Settings, I have "Primary Display" set to "PEG Slot" (the BIOS manual says there should be a "PCIE" option, but it does not appear in the UEFI BIOS settings) and "iGPU Multi-Monitor" set to "Disabled". The iGPU HDMI remains active and during boot I see the rebooting message on the GPU output, but when BootItUEFI appears, it is only visible on the iGPU output, the GPU output goes to black screen. I see the same behavior when booting from a flash drive. Initally output appears on the GPU output, but the system then switches to iGPU output only. Am I missing some other settings somewhere in the UEFI BIOS?

[achugh]

Hi @GaryScottMartin , I am curious as to why you are using a 3rd party UEFI Boot Manager. You can just install Windows and then install Linux on a different drive. This all works without the need for 3rd party boot loader.

See https://rog-forum.asus.com/t5/gaming-motherboards/z790-dark-hero-bios-1302-logo-patch-bsod-with-mult... and the very last message where I posted a link to https://rog-forum.asus.com/t5/gaming-motherboards/rog-strix-z790-f-gaming-wifi-won-t-boot-up/m-p/101... where another member of this forum is showing the dual boot via normal ASUS UEFI BIOS. I don't think @bwandowando used any custom boot loader. I have tagged him here so maybe he can help you setup your dual boot differently so that it works for you.

[GaryScottMartin]

Thanks for the links.

I have been using Terabyte Imaging and Boot suites since I dual-booted the predecessor of this desktop computer (ASUS H87M/E motherboard). I built that computer in early 2014, the dual booting came a couple of years later. I used BootIt because MBR motherboards could only deal with four primary partitions and I need to deal with more than that between the Windows and the Arch Linux systems. Originally, the old system had only a single drive and I used to BootIt to map the particular partitions on that drive to OS that was booted, when I booted Windows, only the Windows partitions were visible to the OS, when I booted Arch Linux (originally Kubuntu, but I move to Arch long ago), Linux could only see the Linux partitions. The new system has only a single 4TB NVME drive in it. I prefer that from the standpoint both flexibility and performance. Both Windows and Arch fit well on the drive with room to grow. BootItUEFI allows me the freedom to put both OSes on a single drive. I also have a 10TB SATA spinning drive in an external enclosure that I will using as a Windows & Arch Linux data drive (it has an 8.7 TB NTFS partition for data, as well as dedicated partitions for Linux swap and a Windows Page File.

My H87M/E had no such problems, everything went to the GPU, I had the RTX-4060 installed in the old system for about six months. If I can't resolve this issue with the motherboard, I may explore using GRUB in place of BootItUEFI. However, the issue is not limited to BootItUEFI, I see the same behavior during every boot, including booting from a flash drive. At an early point in the boot process it switches from the GPU to the iGPU, even though the iGPU is disabled in the BIOS.

[GaryScottMartin]

The basic issue is NOT dual boot setup. My Arch Linux installation is encrypted and I currently have to enter passwords to decrypt the Grub boot loader and later to decrypt the Linux system root partition and the boot partition (separate partition from the ESP). The prompt for the boot loader password appears on both the GPU and iGPU outputs, but after Grub is loaded, something causes GPU output to cease. The prompts for the passwords for the system root and boot partition and all subsequent boot activity up to and including the SDDM login screen appear only on the iGPU output. However, once I login through SDDM, the GPU again produces output and it becomes the primary screen, while the iGPU becomes a secondary screen. As a result, I have to switch back and forth between graphics sources to login to Arch Linux as well as to initiate the boot process with BootItUEFI.

[achugh]

Hi @GaryScottMartin I am going to say that I am a Windows only guy and do not understand Linux OS so your setup is beyond my ability to understand and help. I have already tagged a forum member here above who I saw is using Ubuntu and Windows as a dual boot setup so either him or the moderators or someone else will catch this post to provide further guidance.

All I can suggest is that you can give the default boot loaders a try since in the last 10 years things have made some progress and you may not need this 3rd party boot loader. It may just work for you and since it will be native to your board, you may be able to request for assistance from ASUS like I am requesting in my thread about DUAL Boot setup for Windows where both OSes are Windows.

I wish you all the best to find some answers here to help you out. At least you have a workaround available to keep you moving forward while you look for a better solution.

[GaryScottMartin]

I have tried that. Booting the Windows bootloader directly does result in the desired behavior. However, booting Grub directly from the MB boot menu [F8] produces the undesirable behavior. Regardless of bootloader progress, ASUS firmware has gone backward substantially, as a ten year old MBR config was working properly and reliably last week. The fundamental issue is the Firmware options fail to produce the behavior that the documentation claims.

[achugh]

Hi @GaryScottMartin , As you have been a veteran, you will know and understand that the legacy BIOS has been running for half a century (about 50 years) so it has plenty to time to mature and build ecosystem support.

The UEFI BIOS is new kid on the block offering lots of promises to solve issues legacy cannot solve but the ecosystem and maturity is not there yet.

Does your BIOS Boot Configuration have CSM Module as an option? If yes, you can ENABLE this module and it will make your BIOS operate in LEGACY mode instead of the modern UEFI mode.

NOTE: Changing this setting could prevent your current boot loaders to not work or you may require a fresh installation. You MAY also require your Windows installation media that is meant for MBR partition and not GPT partitions as the Windows 11 23H2 default mode is now GPT partition.

I am sorry I cannot help with Linux side so hopefully this CSM module may help solve your issues.

[GaryScottMartin · Accepted solution]

My particular problem was resolved by a simple hardware solution that I thought I had tried before I first posted here, but had not. That was to simply disconnect the cable from the iGPU video connector after setting the PEG Slot as the primary graphics output.  With no monitor connected to the iGPU, all output goes to the discrete GPU, as expected and desired. While that works in my particular case, as the iGPU/monitor connection was only for debugging, anyone who needs to use the iGPU and a discrete GPU while using Linux-based software such as GRUB or BootIt will likely experience this problem unless it is corrected in a future firmware update.

If the GPU hadn't failed to produce output and then shut down a few seconds after my initial attempts at booting the system, I might never have seen it either. I should have tried the GPU output without any connection to the iGPU immediately after making the PEG Slot the primary graphics output, but I was already deep into debug mode by then.

Another option that I am still researching, and plan to implement (but probably won't test), is creating and booting Arch Linux unified kernel images (UKIs) signed for Secure Boot with root volume decryption handled through the TPM. This would at least minimize the problem and might completely mask it. That might be why Windows does not evidence the problem when booted directly from the F8 menu, as it is not using a separate boot loader as most Linux-based software systems still do.

By the way, I did try to activate CSM and was never able to successfully boot the system from the USB drive containing my installation tools and files in Legacy mode (likely because the drive is a new, high capacity, USB3 device and the Legacy drivers can't recognize it). The only issue that I had with that drive in UEFI mode was that Windows installation media wouldn't boot from it either (they can't deal with USB3 drives, also, it appears). Terabyte Unlimited and Brian K solved that problem for me, though. Using Terabyte's imaging and installation tools, I was able to copy my working Windows 10 install from the previous SSD to the NVME drive, resize the partition, strip out all the installed drivers, install the default NVME driver, and finally create a new EFI boot entry by running Terabyte's fixboot script. The copy/resize took about 50 minutes, the post-copy operations took less than five minutes. While Terabyte's software may not be the slickest and most modern (and I do have issues with it: primarily,  lack of direct support for btrfs), the functionality is as documented and the documentation is thorough. I highly recommend both their imaging and boot suites.