Yeah you want /boot/efi as fat32.
Hmmm freaking crazy the Mobo has to be the issue here.
1 Like
MSI has always been a bit wonky with their software. Their hardware is pretty good, but their software leaves something to be desired.
1 Like
I've always just followed the Wiki.
instead of a separate /boot partition
I don't think that's talking about /boot/EFI so I don't know why the Arch Wiki doesn't mention that.
I've never had issues using /boot as the ESP directly. Using Grub's process for installation, it creates a EFI partition within /boot and puts the files there. But /boot is where the ESP is mounted directly.
Yeah, I'm seeing that software issue. MSI makes me go ".... eeeh?" a lot. Between this issue, their FAQ for this motherboard being all broken English, and their seemingly out-of-touch relationship with their customers, I think I won't be buying anything else MSI.
Aaaaah. I don't use EFISTUB. I've always preferred to use full grub, mainly because I spend half my time compiling different kernels and trying different features.
ASUS has the same problem sometimes though. my p8z77 has some odd options for "classical BIOS to enable" or something. Maybe I get to listen to some Beethoven while selecting a kernel. :P
I wouldn't go that far. I would just not buy brand new things from them. If you're looking for good Linux support, go Supermicro. maybe a bit more expensive, but the server-grade board is nice to have.
1 Like
ASRock is on the cheap side if you are looking for Linux Support.
They were and still are a server board maker.
1 Like
Oh, totally forgot about them. My company uses all Supermicro products because of the kickass support and decent pricing. (although, I keep forgetting how expensive it is to get a 2670 new, after browsing this forum)
EDIT: Like seriously. If someone is selling a 2670 for $100, jump on that shit. We buy them for about $1200 a pop. ($900 was the 2650)
2 Likes
Yeah, I'm currently using an ASUS motherboard no my PC at home. It has not been fun dual booting. Not fun at all.
Yes, I have owned a SuperMicro server board and have worked on an ASRock server board at work. I like them both quite a bit. Quality was never an issue.
My personal/home Arch Linux server is on that SuperMicro server board. Can I just say, as a home machine, IPMI is nice to have.
1 Like
ASUS likes to automatically reorder itself so that the windows boot manager thing is the first option. "Oh, I see you've got a windows partition, let's make that the first option" NO YOU BASTARD, THATS FOR MY VM! Seriously, haven't they heard of block device passthrough?
EDIT: Every time I see ASUS, I feel like I have to scream it. Mildly annoying.
1 Like
Oh, definitely. The general "non-standardization" regarding UEFI is infuriating.
When I installed Arch the first time, I did so on a separate drive from my Windows install. I removed all other drives as a safety measure since I knew I was still learning and didn't want to nuke my other OS installation. I had read Grub is smart enough to work itself around a Windows UEFI boot manager, so I figured it would give me the option to choose later.
After spending longer than I'd like to admit installing Arch, I plugged in all my drives.
Boom. No Windows Boot Manager.
After a lot of research (literally days), I found out that some Motherboard manufacturers delete UEFI boot options if the system boots without the device. i.e. if my Windows HDD isn't in the system, it deletes the entry in the UEFI for the boot manager.
It isn't smart enough to add it back. So since I didn't know how to edit the UEFI from the EFI shell, or how to fix it using my Arch install, I had to reinstall Windows.
The thing is, I didn't find out that information (that it deletes the UEFI entry if the disk isn't found) until I repeated the installation process for Windows and Arch a couple times.
Literally a couple weeks without a PC.
But.... hey, now I know how to install Arch without much issue.
... until situations like this thread happen.
I honestly am probably going to give up on UEFI in general from now on. Using BtrFS and subvolumes should alleviate my partition separation preferences and allow me to use BIOS/GPT.
1 Like
Yeah, I've got Windows in a VM, but that's it. I'm done with windows on bare metal. It's too rage inducing when dual booting. It literally nuked my solus partition a month ago. Not sure why.
BIOS/GPT is the best option if you can use it.
On the BTRFS note, did you sort out your other thread about the raid1 situation? I responded with a solution for removing /dev/sdb if that's what you were aiming to do.
Yes, I will reply there.
That's my goal with my Work PC and eventually my home PC. I play video games and would like to do GPU passthrough to Windows, but my home PC only has 1 GPU and my understanding is that I need two if I want do that. One for Linux and one for Windows.
Or I could just boot into Linux through an SSH session to boot Windows within it, but I'd rather not do that, as I'd prefer to use Linux as my "everything else that isn't video games" OS, so that wouldn't solve the issue, I think.
Thanks for the help to both of you. :D
I'll reply on Monday with what worked.
1 Like
Nope. As long as you have one descrete (read plugged into a PCIE slot) GPU, you'll be fine. I'm going to do a guide on how to hot-swap your GPU between your X11 session and the VM, but I need to iron out the kinks first. (Disclaimer: you must shut down the VM to remove or add the GPU) I don't want to say too much because I'm an evil tease, but it's going to be awesome.
1 Like
I am very excited for that. Thanks for letting me know. :D
Serious question though: Will it require UEFI? Or can I use BIOS/GPT?
I'd like to know so I'm prepared for whenever you do get time to post that.
I'm actually fairly certain that's the reason I always try to use UEFI beyond "it's new and more features." even though it can be a bear to deal with in some situations, because that's always been my end-goal.
The article on Arch Wiki about GPU passthrough sounds like it requires UEFI to work.
https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Using_vfio-pci
But yeah, don't worry about explaining any specifics here. I'll wait as patiently as I can. :D
Host boot method shouldn't matter, but VM may require UEFI. Not 100% sure though.
The archwiki is always only used as a starting point. It's used to point you in the proper direction and you've got to figure the rest out by yourself.
I'm going to go into quite a bit of detail about it. And, for the record, I'm 1000 words into the next article. (the previous article on ZFS was about 3200 words) I hope to have a Christmas gift for the forums :D
The thing is though, that I am doing something tonight as a gift that I want to document. It's going to be an ongoing "User Acceptance Testing" sort of summary. My mother's 2009 macbook is getting Linux. She's used to the mac, so let's see how she handles Budgie. (PGO on Solus should be a huge help here)
1 Like
Now I'm even more excited. :D
That sounds perfect. I'll provision my main PC with BtrFS then in preparation.
Sounds good. Remember, chattr +c <vm-image-directory> is your friend for disabling copy on write for vm images. :D
Also, remember, this coming article is only going to be discussing at length VFIO, the IOMMU and how PCIe works. Having an understanding of how it all works will help people troubleshoot problems themselves.
That said, I'll probably be typing an article on the 25th.
1 Like
So, I've updated the BIOS to the latest version.
To go over my information:
MSI Z170A PC Mate Motherboard
Samsung 850 EVO 500GB M.2 SSD
Hitachi 2TB HDD
My system will not view the M.2 SSD as a UEFI bootable drive even after I install Arch Linux following the guide (as I've done it with many other installations) using GRUB2.
The M.2 SSD is partitioned as 3 partitions using a GPT:
/dev/sda1 is the EFI boot partition at 500MB in size.
/dev/sda2 is the root file system at 483.5GB in size formatted as BtrFS.
/dev/sda3 is the swap partition at 12GB in size.
The 2TB HDD is a partitionless BtrFS drive.
Both drives appear in my BIOS correctly according to their ports. The Samsung 850 is not an NVMe drive, but a SATA based M.2 drive. It shows up as occupying my SATA 1 port. The manual says this is normal for non-NVMe M.2 drives.
I've tried installing Arch with BIOS/GPT, but that didn't work either. It will not boot from the SSD even if I make a 1MiB BIOS partition and install there.
I've noticed that older version of this motherboard (Z87 PC Mate) have a UEFI Hard Disk BBS Priorities menu under boot options to adjust the order. My BIOS lacks this entirely. It only has the legacy Hard Disk BBS Priorities.
I am able to boot into the Arch ISO and verify that I am booted using UEFI. I could just use Easy2Boot to boot to the SSD, but then my boot times would be exceptionally long waiting on a USB drive and having to traverse menus.
I'd also rather not need a USB drive to use my PC.
I've considered putting the EFI or BIOS partition on the 2TB Drive but having the root file system on the SSD, but I've installed this multiple times already trying various things.
I don't really want to waste more time with it, but I also don't know what would be sure to work in using my SSD as the boot drive.
I'm not above going crazy and hard linking everything from the HDD to the SSD, but I've never tried that and can't be sure it'd work either.
I'd put the ESP on the 2TB drive and give that a go. Sounds like this is a motherboard we should recommend against people buying.
You technically don't need to reinstall, just make a partition on the 2TB drive, format it, mount it and reconfigure grub.
1 Like
I'll try that next. If that fails, I'll go as vanilla as possible and fully install Arch on the HDD with BIOS to see if it's strictly a motherboard issue. I doubt that will have a problem though since the HDD has always appeared in the BIOS correctly.
I installed the entire installation to the 2TB HDD using UEFI. It did not work.
I installed using BIOS to the M.2 SSD. It worked.
See, I think this motherboard will just not boot into a UEFI device. I have an Easy2Boot USB stick. It has a function where it can boot to BIOS/CSM, then swap out to UEFI. So even if the system can't boot UEFI directly, if it boots to the stick at all, it can essentially switch to UEFI once that's happened.
This is being a bit of a curse as it is causing a fundamental misunderstanding of what the issue is when I install on some systems. Specifically, my (current) main PC at work will not boot unless I use the USB stick to do this UEFI swapping, as I installed the system with UEFI and I know it has an EFI BIOS, but it seems to not be able to see the boot options.
So I've been able to install with UEFI, but not boot from it, and that's apparently my issue with this MSI motherboard as well.
It also seems like this motherboard is flaky. It sometimes shows the USB stick as UEFI bootable, and sometimes it doesn't, when nothing has changed with the stick.
Regardless, I found this and this actually worked, so I'll just do this with BtrFS subvolumes:
mkfs.btrfs /dev/sda
grub-install /dev/sda
If I had known it'd be that easy, I would've done that to begin with. The Arch Wiki entry for GRUB does say the following though...
Warning: GRUB strongly discourages installation to a partition boot sector or a partitionless disk as GRUB Legacy or Syslinux does. This setup is prone to breakage, especially during updates, and is not supported by the Arch developers.
I figured that's technically installing to a partitionless disk, since that's effectively what BtrFS is when it's formatted directly to a device, but I'm thinking they mean a separate disk without any kind of formatting?
Not sure, but this works, and my config goes in the same usual place:
grub-mkconfig -o /boot/grub/grub.cfg
So I guess I'll just use this installation like this and move on.
Though I will be keeping up with my ticket to MSI for them to fix whatever the issue is with UEFI on this board.
Only problem/quirk with doing it this way? No UEFI speedy boot, and wtv else requires UEFI, but also no swap file. BtrFS doesn't support them. That's super weird to me. I don't need hibernation, but still.
1 Like