UEFI boot configuration changes/resets in (cold) double boot

(Edit: Originally this was a two problems question (the factory reset and the (cold) double boot), now it’s just the double boot thing (apparently) caused by the RAM memory. The factory reset was fixed by itself.)

Recently I’ve noticed that when I turn on my computer it reboots after 3 seconds or so, while showing the mobo logo (“something goes wrong” and it reboots changing one of the options, that I know of, there may be other options changing). When I turn the computer off (every night before going to sleep), I tend to switch off the PSU and sometimes the power strip where it’s connected to (maybe the CMOS battery?).

It actually has happened three times, exactly the same thing. I think it’s when I don’t turn it on immediately after I wake up (meaning that when stays off for more then 9 hours, maybe 12 or more). When the reboot happens, it appears the recovery screen, the one that shows info about the mobo/firmware manufacturer and at the bottom it says enter setup to recover… When I go into the boot options I can see that inside secure boot the selected option is windows os…

I have an SSD where Manjaro is installed, then I have a hard drive with Windows 7 on a partition, the rest is for storing data. Windows was installed with the SSD disconnected so that it doesn’t mess with it, and I boot it through the linux grub.

I don’t have a clue as to why this is happening, but what I know is that long before this started I noticed lots of performance problems with firefox (mainly), I tend to have more than 10 tabs opened (RAM’s not the problem, I got 8GB), it may be the amdgpu driver (the one that is installed by default). Anyway I may need to open a different topic to address this other issue.

The thing is, I’m not paranoid until weird things start to happen… :thinking:

Maybe I need to do some testing. Aside from checking the CMOS battery, do I have missed something out that’s worth checking? I’ve already changed some options (enabled hot plug for the SATA drives) and the next time it happens I’ll check if they’re enabled. And if they’re not, hat would mean that it’s resetting the options, and it probably be the battery, right?

First, what’s POST?


Second, is any of these (ssd or hard drive) external and removable? If so, do you remove, even occasionally?

I have an SSD where Manjaro is installed, then I have a hard drive with Windows 7

Third, what’s your disks partitioned/ Are they the same?
Fourth, what boot you you use, bios-legacy or uefi? Yes, you said UEFI, but for both windows and Manjaro?

If you don’t know or unsure, provide at Manjaro terminal,

test -d /sys/firmware/efi && echo UEFI || echo BIOS
sudo parted -l
cat /etc/fstab

All disks connected, ‘parted -l’ small ‘L’

Yeah, sorry, POST stands for Power-on self-test, a test that the bios/uefi does every time it boots before anything else.

No, they are internal, although the case is special, Aerocool Strike-X Air, and the bays are removable but I never remove them, only the disks that I put from other computers/laptops to fix them.

They both are GPT for UEFI, I don’t like outdated stuff. And that answers fourth too.

Ok, noted.

At this point, though not certain for sure, I tend to think it’s your Aerocool Strike-X Air and POST, in which it regenerates your bootorder and causing it to reboot. A normal desktop with an external drive will do the same thing if that external is pulled out, booted, reinserted and rebooted.

You can check with “efibootmgr -v” and see if the bootorder has changed. Pay attention to the drive and partition that it output. The number may be the same but the drive/partition may have changed.

If that is the case, nothing to worry about.

On my mother board, there is a parameter that defines (up to 3 by default) the number of failed boot attempts before the MB resets the firmware parameters to the default values. That may be a point to check if this value is set to 1 (and the feature exists, of course).

I don’t know what it has to do with the case or the way the drives are installed, they’re connected to the SATA ports just like in any other case, they’re not external drives.

This is the output of that command:

$ efibootmgr -v
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,000E,0000,0012
Boot0000  Windows Boot Manager  HD(1,GPT,d2c4165d-7c41-4164-ab90-2cbd3ca18722,0x800,0x32000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.}...a................
Boot0001* Manjaro       HD(1,GPT,0953a354-aa75-4a8b-9385-94eb7bf3ab2a,0x800,0x96000)/File(\EFI\Manjaro\grubx64.efi)
Boot000E* Hard Drive    BBS(HD,,0x0)..GO..NO........O.S.a.m.s.u.n.g. .S.S.D. .8.4.0. .E.V.O. .2.5.0.G.B.................>..Gd-.;.A..MQ..L.1.S.B.D.S.N.D.B.0.A. .M. . . . ........BO..NO........O.S.T.>..Gd-.;.A..MQ..L. . . . . . . . . . . . .1.Z.8.D.G.G.C.0........BO
Boot0012  CD/DVD Drive  BBS(CDROM,,0x0)..GO..NO........O.H.L.-.D.T.-.S.T. .D.V.D.R.A.M. .G.H.2.4.N.S.B.0.................>..Gd-.;.A..MQ..L.B.K.D.B.4.B. .3. . . . . . . . ........BO

Each EFI partition is on it’s own drive (Manjaro EFI is in the SSD and Windows EFI in the HDD).

@Denis_Pom I will check the UEFI options to see if I can find that information. My mobo is Asus Maximus VI Formula, I’ll google it.

Correct. What I’m saying is note next time when you do efibootmgr again.
Your hard drive may have changed (from 000E) to 000F or something else.
And note your cd drive. It’s now at 0012. And you have only 4 entries. If it hasn’t changed, it would at maximum be 0003 (0000 to 0003). 000E is the 16th entry. no, doesn’t work that way, never mind. hexadecimal.

But as I said, no worries.
You can, if you like, find out how to prevent ‘POST’.

Ok, next time I’ll run the command again and see what’s changed.

It’s just annoying having to change the option every time it happens.

Why would anyone want to disable or prevent POST? Anyways I think it’s hard coded, it’s a security check after all, it checks that everything connected to the mobo is ok and that there are no hardware problems before loading things up.

Of course, there’s no harm checking your battery or graphic drivers again.
Another possible cause is your windows setting hardware clock to local time and linux setting hardware clock to utc. Your POST may determine that the hardware clock has changed and reboots. And as I said, I cannot be certain for sure. But that is something easier to change.

There is also a “fast boot” option that may cause problems … Normally you should not use it with Linux. An also it exists options for USB detection at start / POST time.

Now that you mention it, I’ve had that problem while dual booting both OS, the hardware clock changing as you mentioned. But the thing is, I haven’t booted Windows in a while, so that can’t be the problem also because I haven’t had it before when I dual booted to play, so… It must be something recent, it probably be the battery, I’ll replace it and see if it happens again (it’s 3 and a half years old).

I don’t use the fast boot mode, it was disabled last time I checked.

I did run efibootmgr and nothing has changed.

Okay, let us know ya when you’ve found the culprit.
May come in useful for others.

Cheers, good luck.

It has happened again. Yesterday I turned it off at 7:30 am (hard night working). And I didn’t turn it on until 5pm, after finishing some things. The power strip was turned off as well (I don’t know if this has something to do, but I think every time that has happened it was off and I’ll make sure the next time). The UEFI settings for the SATA ports (hot plug) were disabled.

This means it gets reset for some reason (I have yet to buy a bottom battery).

And the same output with the efibootmgr command.

Ok. I had thought it would be different. I am wrong. And thanks for telling me.

ps: don’t let it drive you crazy :grin:.
It’s ‘working’ anyway,

Yeah, my 1.5k rig is working :sweat_smile:

1 Like

I can confirm it’s not the cmos battery. I decided to let the PSU on at all times and it still reboots and resets the settings.

Because that is definite proof of a not dead/drained battery, right? I mean the mobo has power (psu on) and it shouldn’t loose the settings… So…

Any idea?

Maybe your POST is working too well. It rechecks and resets all the time.
Or your ‘removable drive bay’ causes your mobo POST to recheck and reset.

That sounds like sarcasm… :rofl:

The removable drive bay is something that doesn’t/cannot affect in any way as to how the mobo detects/treats the disks. Unless it’s not (physically) well connected to the PCB power/data ports. I’ll connect them directly to the mobo and see if it happens again… But I think there’s a very little chance of that being the reason.

Edit: I’ve been reading on other forums and it seems I’ve been mistaken about something. What is happening is not a bios reset but a factory reset (clear cmos), it seems it’s not the same thing. That’s why I’m asked to “press F1 to enter the bios”.

As far as I know, if the firmware resets itself during post, the problem is hardware or firmware settings regardless of the operating system used
I would try lowering the frequency of the ram and / or trying to change cables / psu (if possible)
However in my case the culprit of a similar behavior in my old house was the humidity

1 Like

I would disagree on that plus a battery is dimes not dollars does not matter if plugged in or not the battery does not recharge so if its faulty the same will happen plugged in or not?. The power supply does not affect the cmos that’s why you have a battery.

1 Like

Forum kindly sponsored by Bytemark