MSI x470 Gaming Pro Carbon + Linux?

Is anyone running linux on the MSI x470 Gaming Pro Carbon?

System Config -
MSI X470 GPC
2700x
MSI VEGA 64
Corsair 2x16 2666
no overclocks on anything.

When try installing it, I can get ubuntu 18.04.1 installed but pretty much any other distro fails to install or load up the live-usb

Manjaro - I get stuck on the tlp hang
Fedora 28 - I get failed to start udev wait for complete device initialization. See ‘systemctl status systemd-udev-settle.service’ for details
Antergos - the only way I can get it to boot is to choose the non uefi option in the boot menu on the usb, and then it’s slow
Ubuntu - installs but startup time is like 3 min (After setting the bios to uefi Windows 10 WHQL mode in the bios, dual boot between W10 and Ubuntu are working boot times are as expected now. I still can’t get the other distos to even load on the live-usb’s.)
MX Linux (antix?) - loads just fine and it’s running debian testing

I just returned a Asus C7H because of issues I wasn’t able to get resloved but I could at least get all but manjaro to install on it, just would take 30 + seconds to post and randomly was reseting the bios on cold boots, so returned it and got this MSI board instead.

Issue is with the AGESA 1.0.0.4c update. I foudn this bug report and down graded the bios to the previous version before the updated 1.0.0.4c and it is working now.

Bug report for it.

https://bugzilla.redhat.com/show_bug.cgi?id=1615668

2 Likes

Hi, I’m having a similar problem with an MSI b360i.
No matter what I cannot get arch to install via grub.
Could you please explain to me your bios settings
and whatever else you did to get this pos to boot linux?
Sorry…I like that this board was affordable and seemed to have
a lot of features, but this msi bios is garbage imo.
Thanks!

I’m having the same issue with Fedora 28 on an X470 taichi.

I’m going to ubuntu 18.04 it would appear.

@xnor I had to downgrade to a previous bios version for my board that does not contain AGESA 1.0.0.4c this is for AMD Ryzen systems, since you’re using an Intel system this wouldn’t work for your board. :frowning:

@thro if you’re on the newer bios that has AGESA 1.0.0.4c you could try going back to a version with the older AGESA that worked for me, here’s a reddit post where people are talking https://www.reddit.com/r/Amd/comments/96w192/bugs_agesa_1004c_and_linux_udev/&ved=2ahUKEwivl5ydoK_dAhUPGnwKHYVoD8EQFjAAegQIBhAB&usg=AOvVaw2OWpX7tMyvGpY7c9PH9O56

About the only other option is to wait for the fix to either the bios or looks like a possible systemd patch. I can tell you while ubuntu installs it seems slow and sluggish and hangs on shutdown for about 3 min.

I just installed Ubuntu 18.04 last night just fine. I’m not going to go downgrading BIOS or AGESA just because Redhat/Fedora can’t get their shit together.

I’ve had a rough time with Fedora - i’ve mostly run Debian based distros for the past 15-20 years (my last serious dealings with Redhat were back with Redhat 6.2. Not RHEL. Before RHEL existed) and Fedora is just too “different” which makes it a pain in the ass to diagnose when it breaks, which with my dual GPU vega + Ryzen setup is FAR TOO OFTEN.

Now there’s a reasonably current Ubuntu LTS that supports my hardware i’ll probably just run with it. I run Ubuntu at work for similar stability + commercial software packaging reasons.

I don’t think this is a Fedora issue. It has to do with the UEFI and the the Windows 10 support on the board. I installed Ubuntu just fine. Of course, I prefer Arch and have my own build on another system I was going to migrate over. I’m definitely staying away from MSI or “Gaming” boards for now on. I’m gonna attempt to chain boot soon, if I can get it to work I’ll update on here if anyone is interested.
[EDIT] Also, Ubuntu’s efi keys are signed by microsoft, that’s why the bootloader and kernel is recognized.

Nah, pretty sure it is a Fedora vs. AGESA update, as i did actually have Fedora 28 running on this machine until it broke. The timing would have been around the time i did a bios update, now that my memory has been refreshed now that it has been mentioned.

It’s not a gaming pro carbon exclusive issue i can confirm that much, as i am seeing the exact same behaviour on X470 taichi.

I re-confirmed that Fedora 28 latest ISO does not work (an error from XHCI_XCD (?) Can’t setup : -19 after kernel load) and Ubuntu 18.04 does work last night with a new SSD.

edit:
@GrumpySasquatch i haven’t noticed any slow shutdown or other issues yet? I’ve only rebooted my most recent ubuntu install a few times but my older 18.04 install never had any issues?

@thro Interesting, mine would hang on shutdown with ubuntu 18.04 and 18.10 beta. The bulk of the reports are from Fedora but it has been reported on Arch as well, it seems that anything above kernel 4.15 may be impacted. I also had issues with debian I installed 9.5 (4.9 kernel) which was fine until upgraded to testing branch which was on 4.17 and it would hang just like fedora did. I do remember reading something some where that it was because of LVM and since that’s the default config with fedora it could be why it’s impacted more? I was using LVM in debian to test I never thought to go back and just try a non-lvm setup with it.

It seems that it has something to do with something called SEV being reported by the bios as enabled for the CPU which AMD is saying is not supported, I don’t really understand it to be honest.

My linux skill’s is mostly a power user/application support on RHEL/Oracle EL based systems I realize that CentOS would be more like those but I wanted a newer kernel so that’s the main reason I wanted to stick with fedora it’s more like what I am used to. I don’t mind running a older version of the bios if it means I don’t have to run ubuntu I don’t know why but just can’t stand it, maybe it’s the ugly orange brown default colors :slight_smile:

Ubuntu is non very far from the windows mindset. I tend to use arch on my personal devices, but through work I am familiar with most distros.
I understand that I am using an intel board, not an amd board. Still, the bios should be similar on both.
@thro the X470 taichi is not MSI of course, so in your case it might actually be a Fedora thing. But @GrumpySasquatch is having issues with any non Ubuntu distro. Same here.
Which leads me to believe it is not a specifically Fedora problem.
Ubuntu uses keys signed by Microsoft to allow it’s efi file to be run from the UEFI.
UEFI is uses a “hidden” cpu core to check a PK, with Microsoft initially being the only authority. These MSI bios do allow you to manually add your own keys, but you have to enable Windows 10 mode. I haven’t yet tried installing Ubuntu with Windows 10 mode off (Windows 10 WHQL plus Secure Boot enabled). Either way, any other distro (read bootloader) is ignored, and in my case, the entire drives ( I used 2 nvme + LVM) were not visible UNLESS I specifically navigated to the /boot/efi path within the bios. I would then manually add the efi to the db. Still nothing. So …maybe this IS an LVM issue (Windows 10 does not recognize LVM…so this motherboard won’t either? not sure if that really makes sense) OR you need to first boot using a Microsoft signed key, and then we can chain boot with our desired efi.

The only distros i have tried are fedora 28 and ubuntu 18.04…

Like i said, i had fedora 28 running on this thing before - until AGESA broke it - with the same error mentioned… so i’d say its the same issue.

I guess my question is, if it were a Fedora issue, than why is every linux distro BUT ubuntu having an issue with the msi bios. The msi bios is the constant here. Most linux distributions will have the same, or close to the same, current linux kernel. So I’m not sure where you think this is specifically a Fedora issue. …Anyways, I managed to get Arch to boot tonight. The path for your boot-loader needs to be /boot/EFI/BOOT/BOOTX64.EFI …caps are important here. Try that, see if it works. Also, I used grub, and once I finished setting everything up I mv grubx64.efi to /boot/EFI/BOOTX64.EFI . Also, I could not get this to work with LVM. So I settled for two nvmes mounted to / and /home respectively. …sigh.

My board isn’t MSI (ASROCK X470 Taichi). So no, MSI is not one of the constants here.

The constant is the current AGESA update vs. whatever version of systemd or the kernel that Fedora 28 runs.

I’m not saying it is (only) Fedora specific - i’m saying that i also see the issue with Fedora plus non-MSI board. MSI aren’t to blame here. Common factor is the AGESA update that ships with new BIOS for any Ryzen 2000 series board (I too started seeing issues after the current BIOS update that includes new AGESA version). The other common factor is “not ubuntu” (and possibly also not some other distros like I’d bet - slackware (which doesn’t run systemd at all)- are not affected).

From what I can see, i think it’s actually an issue with SYSTEMD as shipped on Fedora 28 (and likely other distros) and the current AGESA…

If it was a BIOS key/signing issue as you suspect, you wouldn’t boot as far as the kernel loading and then throwing an error from either the kernel or systemd. The boot loader simply wouldn’t load.

@thro, is your unbuntu install running with out systemd enabled then? I wonder if that’s why you don’t see the same slow shutdown I was seeing with it installed.

Pretty sure Ubuntu runs systemd out of the box with 18.04.

I do however suspect/think it runs a different VERSION which may not be impacted.

Ill get a chance to confirm a few of these things this evening, at the moment i’ve not had a lot of time to look into specifics since monday, but have a few hours to myself this evening (Aussie time).

My install of fedora is on

systemctl --version

systemd 238
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +I

When booting to the live usb for ubuntu it’s on 237 with the same flags, so yes it’s a different version