UEFI On This Motherboard

[Zema Bus]

I may need to flash the bios on this Z690P board. No matter what I try I can't get a 4th UEFI entry to appear in the motherboard's UEFI menu, or a 4th UEFI OS to even be recognized by the board. It ignored my new Arch install even after carefully re-creating the entry multiple times and updating Grub. So then I tried rEFInd, on my Ryzen machine that was immediately recognized, but this board just ignores it. Debian is one of the 3 entries it sees, so I tried installing rEFInd in Debian. Again it just ignores it. So nothing past 3 entries will be recognized. The only way I can boot into my new Arch install is via one of the other OS's Grub entry. I found some similar complaints for a different variant of this board, not surprising there wouldn't be a lot since the majority of users don't boot more than 2 OS's on their machine. My bios dates from January 2023, hopefully this was fixed in the past year (yeah, sure it was).

[Grogan]

You know the trouble I had with EFI boot loaders on this board. That's one of the things that happened too, I couldn't get boot entries to show up anymore in the disk boot order configuration and stuff. I got reFind to work by forcing it with a "makedefault" switch (I forget the syntax) and while that worked, it configured itself in the chroot and it was all wrong.

I'm still not sure if my EFI boot entries are workable again (that's probably been cleared after reflashing the bios), but I don't care to try it again. I'm really happier booting through CSM with normal MBR partition drives. That's all that affects, is booting. This way I have a choice of both boot methods.

[Zema Bus]

Well this isn't going well. I thought I'd go ahead and try flashing the bios, but guess what? Since it basically does a cold boot before going into bios flash mode I have no screen (because of the weird no screen output on cold boots until reaching an OS login manager issue). So there is no way for me to flash the bios on this board. I tried swapping in a different video card, and then it starts going into boot loops like it was doing before. So I guess it wasn't the power supply after all, though it's strange that it stopped bootlooping after swapping power supplies. I figured it must be this buggy board. I pulled all my drives out and put some of them in another machine so that I'd have some functionality until I could figure out what to do. And guess what happens next? The temp machine starts bootlooping! This machine runs perfectly fine so it had to be one of my drives. I pulled power from all of them and reconnected them one at a time. The culprit turned out to be my Slackware 15 drive, a Samsung sata SSD I've used for years. So now all I have is my old Arch install and my data drive. My new Arch install is on an NVME and I didn't feel like digging that out and tearing into this machine to access the m.2 ports tonight. While all this was going on my buggy KVM switch stopped working (95% of KVM switches are crap these days) so I had to pull out cables and run them directly. It's odd that that Samsung drive gave me no trouble after replacing the power supply a week ago up until acting up again tonight. I'm still considering sending this board back. I'll try it with a different video card again.

[Zema Bus]

One thing that occurred to me, that Samsung drive was common to both my Intel system and my Ryzen system before that. My Ryzen system never bootlooped but it did have no display on cold boots. Seems like a bit of a stretch but something to explore.

[Grogan]

In the sense that the Samsung drive might be doing bad things on the PCI-E bus, yes it's possible (i.e. not anything to do with the flash memory cells since it seems to be a good drive)

[Zema Bus]

I retried it this morning without the old Samsung drive and now I have screens on cold boots! So it was the Samsung drive all along. I put the two drives back in and I'm back up. Yeah when it wasn't bootlooping on a warm boot I could boot into Slackware on that drive and it worked perfectly fine. Well I was planning on doing a Slackware-Current install anyway lol!

[Grogan]

Isn't that a futhermucker. I think all the problems you've had with NVME drives are attributed to buying while the technology was still young. I avoided them until recently, so hopefully I shouldn't run into any ticking time bombs.

Likely firmware not behaving and your bios sorts out the resource conflicts on a reboot. Or something like that.

[Zema Bus]

Yeah I never would have guessed an SSD could do that, especially when it seemed to be working normally.

[Zema Bus]

Well I made an executive decision. I've been planning for a long time to redo the machine I use while working for all my look ups and reference material, my personal email and other stuff I need to keep track of. I'm going to repurpose this MSI board for that, along with the rest of the machine, minus the processor, memory and drives - I have an i5 13400 I can swap into it. And in it's place I ordered a Gigabyte board for my main system and I'll drop my i9 processor into it. This board has 3 NVME slots, 3 full length PCI-e slots, and 6 sata ports. With that capacity I probably wouldn't need to use many sata drives anymore (I'll still need at least one for my 5 TB mech data drive).

[Grogan]

You went with a DDR4 board too, eh? Much cheaper RAM (and maybe you already have some)

It looks like a nice board... AND... it doesn't have a stupid, mickey mouse i/o shield that you have to clip on like the MSI boards. Gigabyte also uses very good capacitors and stuff.

[Zema Bus]

Yeah I'm going to reuse the DDR4 that's currently on the MSI board (64 GB), and then the MSI board will get the memory from the board that it will replace. I considered going DDR5 (there's a DDR5 variant of this Gigabyte board) until I saw the price of 64 GB of DDR5 lol!

[Grogan]

Same here, I would only have been able to get 32 Gb of DDR5 (I was originally considering 4x32=128 but settled for 4x16. It only cost $160 CAD. That's a lot of RAM, for the money compared to the old days even.

I did make a mistake though, I should have gone with 2x32 as that would leave room to have 128 later without having to yank it, AND it's easier on your on-die memory controller. I didn't realize Intel nixed quad channel memory on consumer CPUs. Like AVX-512, they want you to buy a big expensive Xeon if you want that (and not all Xeons support quad channel either). I'm a dinosaur... I still live in the era where CPU improvements are cumulative, not taken away. It used to be that all you had to do was list one feature, and you knew the CPU supported everything preceding it.