New system build - reboot loop when attempting to boot from SATA HDD

This is a new system build that fails to boot from the SATA HDD.
Instead, it appears to power down and restart, in a loop.

Mobo: ASRock Z390 Taichi (original BIOS P1.20, since updated to P1.80)
*RAM: G.Skill Ripjaws F4-3200C16Q-64GVK (4x16GB)
*CPU: Intel Core i7-8700
Asus optical drive scavenged from parts drawer
Samsung 2TB 5400RPM SATA HDD scavenged from parts drawer
PS2 keyboard
USB mouse
Onboard video (also tested with older PCIe video card)

*The CPU and RAM are on ASRock's approved compatible list for this mobo.

With all parts on hand, I built the new system on a non-conductive
table, using the mobo's non-static envelope for additional protection. I
like to do the initial build outside of a case to make sure everything
works before I go to the trouble of physically installing everything
inside the case.

The CPU and stock cooler installed without issue, with the stock cooler
coming from the factory with heat transfer compound already applied. I
installed a single memory module in slot A1 (closest to CPU). I
connected a known working PSU (Corsair vx550w), the PS2 keyboard and the
USB mouse. I connected a monitor via HDMI to the onboard video and fired
it up. No optical drive or HDD connected at this point. The PSU is
connected by the standard 24-pin connector and the 8-pin EPS12v
connector. The mobo has a separate 4-pin ATX12v connector, which remains
unconnected. ASRock tech support says that's fine.

With no boot devices connected, the system came up directly in the BIOS
screen, where everything looked normal. The CPU and RAM were recognized;
the CPU fan RPM was reported as about 1580 RPM and CPU temp at 34C
(later stabilizing at about 38-45C, depending on activity).

I shut it down, plugged in a USB thumb drive with Memtest+ 6.00 on it,
and started back up. As the only available boot device, the system
automatically booted into the Memtest program. (Fast forward here, but I
tested an individual RAM stick in slot A1, then B1, then A2, and finally
B2. Then I jumped ahead and installed all 4 memory modules and let
Memtest run overnight. Absolutely no issues so far, but I removed all
but the A1 module before proceeding to the next test.)

Next, I removed the Memtest USB thumb drive and connected the optical
drive via SATA. I inserted a known good Linux Mint 19 disc and started
the system. The 'live' Linux environment came up without any issues. I
temporarily connected the breadboard system to my LAN and browsed the
net for a period of time to watch for issues, but everything was fine.

Next, I shut down and connected a single Samsung 2TB 5400 SATA HDD and
restarted the system. Again, I booted the Linux live environment, but
this time I elected to install Linux to the HDD. That completed without
issue. The next step would be to boot into that new Linux install.

When I was ready, I removed the Linux disc from the optical drive and
rebooted, expecting the system to boot into Linux from the HDD. I got to
the expected grub menu, where I have 4 choices and the first choice is
the default: Linux Mint 19. Pressing Enter or allowing the timer to
expire, the next thing that happens is all of the LEDs (there are quite
a few on this mobo) go out, the CPU fan stops spinning, and after 2-3
seconds, the system powers up again, repeating the behavior described.
It gets to the grub menu, then whether I intervene or not, it powers
down and restarts, in a loop.

===
Status so far:
Stable in the BIOS screens with no storage devices connected.
Stable in Memtest when run from USB thumb drive.
Stable in the live Linux environment when run from optical disc.
**Unable to boot into Linux from the SATA HDD.**
===

I grabbed a second Samsung 2TB SATA HDD and different SATA cable, then
installed Linux to that drive. I got exactly the same behavior described
above.

Next, with the SATA HDD still connected, I chose the Memtest option from
the grub menu. A slightly older version comes up, 5.01 rather than the
6.00 that I have on the USB thumb drive, but Memtest comes up and runs
successfully.

Thinking it's possibly a too-weak PSU at 550W, I swapped in the 650W PSU
from another working system, a Corsair tx650w, but it made absolutely no
difference, so I went back to the 550W unit. Online PSU calculators tell
me that I need between 230W and 340W, depending on the calculator, so
adding a bit for headroom they think I should be OK with 350W to 450W,
indicating to me that 550 and 650 are well into the safe area.

Thinking it's an overheated CPU, I can see in the BIOS screen and in
Memtest that the CPU temp hovers at 38-45C, but usually stays right
around 40-41C. The heat fins on the CPU cooler appear to be at room
temperature, but then I'm only running Memtest or viewing the BIOS
screens, so not any appreciable load. (Yes, it's UEFI, but I'm used to
calling it BIOS.)

Thinking it's RAM that's not being properly recognized, I see in the
BIOS that it's recognized as exactly what G.Skill says it should be:
"DDR4-3200 PC4-25600 CL 16-18-18-38 1.35v"

ASRock suggested RMA'ing the mobo and Newegg agreed, so I did. When the
replacement arrived the other day, I repeated all of the steps listed
above and eventually arrived at exactly the same place:

===
Status so far:
Stable in the BIOS screens with no storage devices connected.
Stable in Memtest when run from USB thumb drive.
Stable in the live Linux environment when run from optical disc.
**Unable to boot into Linux from the SATA HDD.**
===

Beginning to doubt the integrity of the Linux DVD, even after its
integrity check was successful and it's a disc that I've used
successfully before, I downloaded and burned the latest Windows 10 ISO.
Booting from the Windows 10 disc, I get to the point where it starts to
copy files to the HDD, then the system powers down, LEDs and CPU fan
off, then 2-3 seconds later it powers up again and starts the Windows
install from scratch. Even though I was able to install Linux twice on
the first HDD and once on the second HDD, I couldn't get the system to
stay up long enough to get Windows installed. I also tried burning the
Windows 10 ISO to a USB thumb drive, but I couldn't get the system to
stay up long enough to get Windows installed that way, either. BTW,
there are 8 SATA ports on the mobo, 6 on one controller and 2 on another
controller. I tried SATA ports from both groups.

I'm currently on page 58 of 491 pages on the ASRock forums, and so far
I've seen two others with a "system powers down and restarts" issue, but
no resolution provided.

I've built at least several hundred PC systems for people since the
early 1990's, most of which have gone smoothly, but this one currently
has me stumped. This build is supposed to be for me, if I can get it
working.

At this point, I'm not sure where to go next.
- Is it running out of power? Do I need a newer, bigger, PSU?
- Is there an issue with the CPU?
- Should I chalk this expensive mobo, my first ASRock, up to experience
and go with something from ASUS or Gigabyte?

On 12/17/2018 9:11 AM, Char Jackson wrote:
This is a new system build that fails to boot from the SATA HDD.
Instead, it appears to power down and restart, in a loop.

Mobo: ASRock Z390 Taichi (original BIOS P1.20, since updated to P1.80)
*RAM: G.Skill Ripjaws F4-3200C16Q-64GVK (4x16GB)
*CPU: Intel Core i7-8700
Asus optical drive scavenged from parts drawer
Samsung 2TB 5400RPM SATA HDD scavenged from parts drawer
PS2 keyboard
USB mouse
Onboard video (also tested with older PCIe video card)

*The CPU and RAM are on ASRock's approved compatible list for this mobo.

With all parts on hand, I built the new system on a non-conductive
table, using the mobo's non-static envelope for additional protection. I
like to do the initial build outside of a case to make sure everything
works before I go to the trouble of physically installing everything
inside the case.

The CPU and stock cooler installed without issue, with the stock cooler
coming from the factory with heat transfer compound already applied. I
installed a single memory module in slot A1 (closest to CPU). I
connected a known working PSU (Corsair vx550w), the PS2 keyboard and the
USB mouse. I connected a monitor via HDMI to the onboard video and fired
it up. No optical drive or HDD connected at this point. The PSU is
connected by the standard 24-pin connector and the 8-pin EPS12v
connector. The mobo has a separate 4-pin ATX12v connector, which remains
unconnected. ASRock tech support says that's fine.

With no boot devices connected, the system came up directly in the BIOS
screen, where everything looked normal. The CPU and RAM were recognized;
the CPU fan RPM was reported as about 1580 RPM and CPU temp at 34C
(later stabilizing at about 38-45C, depending on activity).

I shut it down, plugged in a USB thumb drive with Memtest+ 6.00 on it,
and started back up. As the only available boot device, the system
automatically booted into the Memtest program. (Fast forward here, but I
tested an individual RAM stick in slot A1, then B1, then A2, and finally
B2. Then I jumped ahead and installed all 4 memory modules and let
Memtest run overnight. Absolutely no issues so far, but I removed all
but the A1 module before proceeding to the next test.)

Next, I removed the Memtest USB thumb drive and connected the optical
drive via SATA. I inserted a known good Linux Mint 19 disc and started
the system. The 'live' Linux environment came up without any issues. I
temporarily connected the breadboard system to my LAN and browsed the
net for a period of time to watch for issues, but everything was fine.

Next, I shut down and connected a single Samsung 2TB 5400 SATA HDD and
restarted the system. Again, I booted the Linux live environment, but
this time I elected to install Linux to the HDD. That completed without
issue. The next step would be to boot into that new Linux install.

When I was ready, I removed the Linux disc from the optical drive and
rebooted, expecting the system to boot into Linux from the HDD. I got to
the expected grub menu, where I have 4 choices and the first choice is
the default: Linux Mint 19. Pressing Enter or allowing the timer to
expire, the next thing that happens is all of the LEDs (there are quite
a few on this mobo) go out, the CPU fan stops spinning, and after 2-3
seconds, the system powers up again, repeating the behavior described.
It gets to the grub menu, then whether I intervene or not, it powers
down and restarts, in a loop.

===
Status so far:
Stable in the BIOS screens with no storage devices connected.
Stable in Memtest when run from USB thumb drive.
Stable in the live Linux environment when run from optical disc.
**Unable to boot into Linux from the SATA HDD.**
===

I grabbed a second Samsung 2TB SATA HDD and different SATA cable, then
installed Linux to that drive. I got exactly the same behavior described
above.

Next, with the SATA HDD still connected, I chose the Memtest option from
the grub menu. A slightly older version comes up, 5.01 rather than the
6.00 that I have on the USB thumb drive, but Memtest comes up and runs
successfully.

Thinking it's possibly a too-weak PSU at 550W, I swapped in the 650W PSU
from another working system, a Corsair tx650w, but it made absolutely no
difference, so I went back to the 550W unit. Online PSU calculators tell
me that I need between 230W and 340W, depending on the calculator, so
adding a bit for headroom they think I should be OK with 350W to 450W,
indicating to me that 550 and 650 are well into the safe area.

Thinking it's an overheated CPU, I can see in the BIOS screen and in
Memtest that the CPU temp hovers at 38-45C, but usually stays right
around 40-41C. The heat fins on the CPU cooler appear to be at room
temperature, but then I'm only running Memtest or viewing the BIOS
screens, so not any appreciable load. (Yes, it's UEFI, but I'm used to
calling it BIOS.)

Thinking it's RAM that's not being properly recognized, I see in the
BIOS that it's recognized as exactly what G.Skill says it should be:
"DDR4-3200 PC4-25600 CL 16-18-18-38 1.35v"

ASRock suggested RMA'ing the mobo and Newegg agreed, so I did. When the
replacement arrived the other day, I repeated all of the steps listed
above and eventually arrived at exactly the same place:

===
Status so far:
Stable in the BIOS screens with no storage devices connected.
Stable in Memtest when run from USB thumb drive.
Stable in the live Linux environment when run from optical disc.
**Unable to boot into Linux from the SATA HDD.**
===

Beginning to doubt the integrity of the Linux DVD, even after its
integrity check was successful and it's a disc that I've used
successfully before, I downloaded and burned the latest Windows 10 ISO.
Booting from the Windows 10 disc, I get to the point where it starts to
copy files to the HDD, then the system powers down, LEDs and CPU fan
off, then 2-3 seconds later it powers up again and starts the Windows
install from scratch. Even though I was able to install Linux twice on
the first HDD and once on the second HDD, I couldn't get the system to
stay up long enough to get Windows installed. I also tried burning the
Windows 10 ISO to a USB thumb drive, but I couldn't get the system to
stay up long enough to get Windows installed that way, either. BTW,
there are 8 SATA ports on the mobo, 6 on one controller and 2 on another
controller. I tried SATA ports from both groups.

I'm currently on page 58 of 491 pages on the ASRock forums, and so far
I've seen two others with a "system powers down and restarts" issue, but
no resolution provided.

I've built at least several hundred PC systems for people since the
early 1990's, most of which have gone smoothly, but this one currently
has me stumped. This build is supposed to be for me, if I can get it
working.

At this point, I'm not sure where to go next.
- Is it running out of power? Do I need a newer, bigger, PSU?
- Is there an issue with the CPU?
- Should I chalk this expensive mobo, my first ASRock, up to experience
and go with something from ASUS or Gigabyte?


Standard debugging procedu
Divide the system into two pieces.
Test each individually.
Divide busted part into two pieces.
Test each individually.
Divide busted part...you get the point.

Does the drive boot in a different system?
Does a working drive boot in this system?
rinse/repeat...

FWIW, there's a lot of settings in the BIOS/UEFI

On Mon, 17 Dec 2018 12:05:11 -0800, mike wrote:

Standard debugging procedu
Divide the system into two pieces.
Test each individually.
Divide busted part into two pieces.
Test each individually.
Divide busted part...you get the point.

Right, standard troubleshooting procedures, except in a case like this
you can't very well do that, so what I've tried to do is more of a
substitution approach. I've tried two different PSUs, two (identical)
motherboards, varying numbers of RAM modules in varying slots, two
different SATA HDDs, two different SATA cables, and two different
operating systems on two different media (USB and DVD, total of 4
combos). I don't have another CPU to drop in, but I'm hesitant to think
that's the issue, and I haven't tried a different optical drive,
keyboard, or mouse. I did try a PCIe graphics card to make sure it
wasn't somehow related to the onboard video, but that didn't help.

Does the drive boot in a different system?

I don't really expect it to, but I haven't tried. The only other system
available at the moment is an older AMD-based PC, so that's pretty
different from what I'm working on. Let me think about that.

Does a working drive boot in this system?
rinse/repeat...

I'll give it a try, thanks. I expect it to blue screen, but that assumes
that it gets farther into the boot process than what I have now, so it
could indicate something.

FWIW, there's a lot of settings in the BIOS/UEFI

True, but so far I'm not seeing anything on the ASRock forums about the
defaults being unbootable. Lots of people talking about OC, but I'm not
trying to do that. Thanks for the suggestions.

On 12/17/2018 1:07 PM, Char Jackson wrote:
On Mon, 17 Dec 2018 12:05:11 -0800, mike wrote:

Standard debugging procedu
Divide the system into two pieces.
Test each individually.
Divide busted part into two pieces.
Test each individually.
Divide busted part...you get the point.

Right, standard troubleshooting procedures, except in a case like this
you can't very well do that, so what I've tried to do is more of a
substitution approach. I've tried two different PSUs, two (identical)
motherboards, varying numbers of RAM modules in varying slots, two
different SATA HDDs, two different SATA cables, and two different
operating systems on two different media (USB and DVD, total of 4
combos). I don't have another CPU to drop in, but I'm hesitant to think
that's the issue, and I haven't tried a different optical drive,
keyboard, or mouse. I did try a PCIe graphics card to make sure it
wasn't somehow related to the onboard video, but that didn't help.

Does the drive boot in a different system?

I don't really expect it to, but I haven't tried. The only other system
available at the moment is an older AMD-based PC, so that's pretty
different from what I'm working on. Let me think about that.

I've found linux to be very resilient when swapping drives between systems.
Often have driver issues, but the systems almost always boot and mostly
work.

The other side of the coin is that I've seen several linux distros that
run fine from the live DVD, but won't run when installed. I don't
remember seeing
a boot loop though. Maybe try another distro. I've had issues with
linux mint beyond 17.

Windows 10 has shown to be very flexible when swapping hard drives
around, except for activation, which you don't really need anyway.
Might be worth cloning a win10 system to the drive and see if it boots.


Does a working drive boot in this system?
rinse/repeat...

I'll give it a try, thanks. I expect it to blue screen, but that assumes
that it gets farther into the boot process than what I have now, so it
could indicate something.

Another issue I've had recently relates to partition alignment.
I had old drives that were formatted with 32Kbyte partition offset.
I installed a new win10 OS without letting windows reformat the drive as
I'd done dozens of times in the past.
Well, win10 v1809 assumed 1MB aligned partitions and refused to install.
Win10 V17xx installed without
complaint, but wouldn't boot.

FWIW, there's a lot of settings in the BIOS/UEFI

True, but so far I'm not seeing anything on the ASRock forums about the
defaults being unbootable. Lots of people talking about OC, but I'm not
trying to do that. Thanks for the suggestions.

I've had issues when the boot order defined in the BIOS is incorrect.
Some systems just skip missing drives in the boot order.
Others hang waiting for the drive.
Others give up and reboot without continuing down the list.

I assume there's a hotkey that lets you select the boot
device and you've tried that.

I put PLOP boot manager on a thumb drive and use that to select the boot
device when the BIOS doesn't
have a boot hotkey.

Another possibility.
Do you have any USB devices?
I've had issues where the system refuses to boot if
there's a non bootable USB thumb drive plugged in.
Unlikely, but if you have USB keyboard/mouse, maybe
that's an issue. Worth a look when you run out of options.

On Mon, 17 Dec 2018 13:41:44 -0800, mike wrote:

Another issue I've had recently relates to partition alignment.
I had old drives that were formatted with 32Kbyte partition offset.

That rang a bell with me. I had a system refuse to boot due to the
allocation unit size. I'd tried using a large size for a partition I
used for backup and it did the power off and try again thing even
though the boot and system partitions hadn't changed. This was with
Windows 10 but it wasn't getting far enough to attempt the boot if I
remember correctly.

--
Regards - Rodney Pont
The from address exists but is mostly dumped,
please send any emails to the address below
e-mail rpont (at) gmail (dot) com

On Mon, 17 Dec 2018 22:20:21 +0000 (GMT), "rp"
wrote:

That rang a bell with me. I had a system refuse to boot due to the
allocation unit size. I'd tried using a large size for a partition I
used for backup and it did the power off and try again thing even
though the boot and system partitions hadn't changed. This was with
Windows 10 but it wasn't getting far enough to attempt the boot if I
remember correctly.

I only had one, but that's an much older MB than an old, then new,
$120/US Crucial 250G I put into it much later, years after buying the
MB.

And then I couldn't get past a basic Windows 98 DOS command-line,
perfunctory-utility partition. I'd gotten so far to boot to the
command prompt, on that SSD, but couldn't lay in, subsequently, a
*NIXDOS emulation, boot arbitrator for the other primary partitions,
I'd already prepared for activation.

I wouldn't neither have had a W7 setup available at that time.

Half-a-dozen, more partitioning methods and programs, I'd hit that
Crucial SSD with, but nothing worked or made a dent. (Whereas an
earlier Samsung 128G SSD took them in perfect working order, without
issue.) I then tried a couple versions of Partition Magic, lacking
anything else left;- they were the oldest programs of anything else I
had. Whereupon a token PartMagic repartition of the W98 DOS,
subsequently test good for whether a boot arbitrator would hold to
surface for arbitration to boot into the DOS partition. As well,
apparently, to have "realigned" the Crucial SSD geometry to match the
BIOS. A miraculous event had occurred.

A witch's-brew, SSD sector translation geometry should not be ruled
out of older builds, along with suspect software associations,
needlessly to say I'm by far more comfortable with newer MB chipset's
SSD boot integrity. Although I still prefer to keep a variety of
alignment and formatting utilities for as much chance, diversity, or
the scatter-gun effect.

I may upon special occasions bounce back and forth between an
installation test, across both a mechanical and SS drive, to verify
other than translational geometry is the result of a fault. But I
think the days of chipset-controller blues generally are now negated
with a couple new Legacy MB purchases this past year.

I've just one original SSD binary OS image left, which has, more of
recent, come to a state, that the software that I used to create it,
now reports sector-partition inconsistencies upon initiation of the
indicated receptor device for a rewrite operation.

A Samsung 64G "receptor" SSD, when a SSD was once 64G, so a time
discrepancy is one, probably, for putting the 64G into a W7 box,
reformatting and refreshing repopulated data partitions, with a fresh
OS install to reduplicate. Or not, depending where kludge and laziness
are easier to deal with it.

On Mon, 17 Dec 2018 22:20:21 +0000 (GMT), "rp"
wrote:

On Mon, 17 Dec 2018 13:41:44 -0800, mike wrote:

Another issue I've had recently relates to partition alignment.
I had old drives that were formatted with 32Kbyte partition offset.

That rang a bell with me. I had a system refuse to boot due to the
allocation unit size. I'd tried using a large size for a partition I
used for backup and it did the power off and try again thing even
though the boot and system partitions hadn't changed. This was with
Windows 10 but it wasn't getting far enough to attempt the boot if I
remember correctly.

Good info, but I'm pretty sure alignment isn't the issue. I'll keep it
on the list, though. Thanks.

On Mon, 17 Dec 2018 13:41:44 -0800, mike wrote:

On 12/17/2018 1:07 PM, Char Jackson wrote:
On Mon, 17 Dec 2018 12:05:11 -0800, mike wrote:

Standard debugging procedu
Divide the system into two pieces.
Test each individually.
Divide busted part into two pieces.
Test each individually.
Divide busted part...you get the point.

Right, standard troubleshooting procedures, except in a case like this
you can't very well do that, so what I've tried to do is more of a
substitution approach. I've tried two different PSUs, two (identical)
motherboards, varying numbers of RAM modules in varying slots, two
different SATA HDDs, two different SATA cables, and two different
operating systems on two different media (USB and DVD, total of 4
combos). I don't have another CPU to drop in, but I'm hesitant to think
that's the issue, and I haven't tried a different optical drive,
keyboard, or mouse. I did try a PCIe graphics card to make sure it
wasn't somehow related to the onboard video, but that didn't help.

Does the drive boot in a different system?

I don't really expect it to, but I haven't tried. The only other system
available at the moment is an older AMD-based PC, so that's pretty
different from what I'm working on. Let me think about that.

I've found linux to be very resilient when swapping drives between systems.
Often have driver issues, but the systems almost always boot and mostly
work.

This afternoon I took a recent Win10 ISO image and burned it to an m.2
NVMe drive. I disconnected the optical drive and the SATA HDD, then
installed the m.2 drive. Twice, out of about 20 boot attempts, I saw a
flash of the initial login screen from Win10, but in every case the
system would power down, pause, and restart. So it's not a Samsung 2TB
SATA HDD issue.

Next, I booted my Linux Mint 19 disc on the other PC, after connecting a
17th SATA HDD, (that PC is my 16-drive, 40TB, server), then I installed
Mint 19 to drive 17. I brought that drive over to the new system but it
behaved exactly like everything before it: I get to the grub menu, but
about a second after I hit Enter to launch Mint, the system powers down,
pauses, then restarts.

The other side of the coin is that I've seen several linux distros that
run fine from the live DVD, but won't run when installed. I don't
remember seeing
a boot loop though. Maybe try another distro. I've had issues with
linux mint beyond 17.

I've used this exact Mint 19 disc several times already, so I trust it,
although this is my first Z390 board so something could be different or
incompatible by default.

Windows 10 has shown to be very flexible when swapping hard drives
around, except for activation, which you don't really need anyway.
Might be worth cloning a win10 system to the drive and see if it boots.

Done, see above. No joy, but everything I rule out gets me one step
closer.

Does a working drive boot in this system?
rinse/repeat...

I'll give it a try, thanks. I expect it to blue screen, but that assumes
that it gets farther into the boot process than what I have now, so it
could indicate something.

Another issue I've had recently relates to partition alignment.
I had old drives that were formatted with 32Kbyte partition offset.
I installed a new win10 OS without letting windows reformat the drive as
I'd done dozens of times in the past.
Well, win10 v1809 assumed 1MB aligned partitions and refused to install.
Win10 V17xx installed without
complaint, but wouldn't boot.

MiniTool Partition Wizard says no alignment is necessary. The actual
message is, "The specified partition does not need to change partitions
alignment. It is already aligned."

FWIW, there's a lot of settings in the BIOS/UEFI

True, but so far I'm not seeing anything on the ASRock forums about the
defaults being unbootable. Lots of people talking about OC, but I'm not
trying to do that. Thanks for the suggestions.

I've had issues when the boot order defined in the BIOS is incorrect.
Some systems just skip missing drives in the boot order.
Others hang waiting for the drive.
Others give up and reboot without continuing down the list.

I assume there's a hotkey that lets you select the boot
device and you've tried that.

Yes, F11 is the key for the popup boot manager. That part has been fine.
I can set a default boot order, or I can make a one-time change, and my
choice has always been respected.

I put PLOP boot manager on a thumb drive and use that to select the boot
device when the BIOS doesn't
have a boot hotkey.

Another possibility.
Do you have any USB devices?
I've had issues where the system refuses to boot if
there's a non bootable USB thumb drive plugged in.
Unlikely, but if you have USB keyboard/mouse, maybe
that's an issue. Worth a look when you run out of options.

The mouse is USB, but I sincerely hope that a USB mouse can't take down
a system like this. Surely, if it were a widespread issue, people would
be complaining and it wouldn't be allowed to continue. I haven't seen a
peep in the ASRock forums.

Char Jackson wrote:


This afternoon I took a recent Win10 ISO image and burned it to an m.2
NVMe drive. I disconnected the optical drive and the SATA HDD, then
installed the m.2 drive. Twice, out of about 20 boot attempts, I saw a
flash of the initial login screen from Win10, but in every case the
system would power down, pause, and restart. So it's not a Samsung 2TB
SATA HDD issue.

A thread with a good deal of weirdness in it.

http://www.tomshardware.com/answers/...rd-owners.html

One person may have damaged a CPU.

Hard to believe they don't test this stuff and monitor
the voltage settings the BIOS is using, under lab
conditions.

Paul

On Mon, 17 Dec 2018 11:11:14 -0600, Char Jackson
wrote:

(Yes, it's UEFI, but I'm used to calling it BIOS.)


I've built at least several hundred PC systems for people since the
early 1990's, most of which have gone smoothly, but this one currently
has me stumped. This build is supposed to be for me, if I can get it
working.

-

Have or can you optionally turn off UEFI for Legacy compatibility?
Does the Intel CPU itself qualify for Microsoft non-support for "newer
devices", for anything but the latest Windows 10 drivers?

When I tried to bring up XP on an AMD octal core I had to shut down
everything on the BIOS CPU page. I could only stabilize XP by
allowing it adapt to paired-cores, one at a time, from a successful
boot as a 2-core system (BIOS allows turning off all other cores),
then 4 cores, six, then eight. Each time rebooting, upon a successful
load, with an addition paired-core added. Which I also binary-imaged,
the OS, to avoid possibly having to the go back a dual-core, as much
procedurally, in starting over in the event of a misstep.

All Legacy BIOS in these woods. And other than the cores, I haven't
yet gotten back to the BIOS to begin refreshing my knowledge of the
individual settings, to test virtually everything else I turned off
and hobbled on the CPU page.

Sounds to me like you're also into BIOS, except it's a more advanced
stage, and you need to call it for what it is - UEFI. I would. I'd
also consider turning it off. (All or selectively no doubt is an
interesting quandary.) Nevertheless, a reasonable thing to expect to
ask, even if I've never owned one, at the very least for the sake of
compatibility prior to a state of UEFI.

Just as it would be to assume ASRock (an ASUS subsidiary) wouldn't
expect people only to run Windows 10 on your Intel chipsets, but as
well provides W7 drivers. However that works in a latter case with an
OS designed before UEFI.