Turning on laptop goes through Manjaro boot settings screen twice for no reason

Support
1

Hard to say when the issues started happening, but there has recently been some sort standalone kwallet update (no other updates) - that’s the only change to the system that I can think of that could have caused issues.

Installing it didn’t cause any immediate issues.

First signs of trouble appeared after faillock engaged due to failed password attempts. After 10 minutes of faillock ended, I logged in and was greeted by kwalletmanager password request box. Not knowing what it’s for (first time seeing it) - I closed it. However, it didn’t bug off - on the next login it would request password again. I got annoyed - deleted the kwalletmanager through the “add remove software”.

Then I found out I’m logged out from everything in Chromium and Slack. I figured it was being indirectly used by these apps, so installed it back. Didn’t help for Slack. So did a snapshot restore to a few days back.

After the restore I was greeted with the kwallet manager login again. I logged in and everything seemed to work fine. That is until I turn off /on again the machine.

Now on every turning on or reboot of the machine upon loading Manjaro (I can see that loading graphic) Manjaro goes directly into Manjaro options, then the timer expires and it auto-selects to boot into Manjaro.

Then I get to see the loading animation again, then it goes into Manjaro options again very briefly, and then switches to the login screen. What the?

What’s going on? Did kwallet introduce some backdoor or smth, or did it just mangle some sort of configuration?

Since then I installed Firefox standalone update & then the latest batch of 140+ updates (including kwallet patch) just now. Does not fix the issue.

Is there any way to resolve or make sense of this?

2

No, but you attempted to update the system from within the GUI, and with the faulty kwallet — which would have been fixed if you had downgraded the package, as was recommended on the Stable Updates thread and the various other threads about kwallet — your authentication failed.

However, there is another Stable Update today, so please do as I explain below…

  1. Log out of Plasma completely. You have to be looking at the login screen.
  2. Switch over to a tty with CtrlAltF3, and log in there as yourself.
  3. Clean out your cache with “rm -rf ~/.cache/*”.
  4. Update your system with “sudo pacman-mirrors && sudo pacman -Syu”.
  5. Reboot the system with “sudo systemctl reboot”.

After this, you can use the pamac GUI to update your AUR packages, Snaps, FlatPaks and AppImages.

If you follow these instructions to the letter, you will be fine. :wink:

3

Thanks for your quick response.

I tried this twice. Does not appear to have had any effect.

On boot it still:

  1. goes into Manjaro boot settings with 5s remaining,
  2. then auto-selects Manjaro,
  3. goes into loading animation,
  4. and then goes into Manjaro settings for the 2nd time with 0s remaining,
  5. selects it,
  6. only then it switches to login screen.

Is there any way to find out why the boot process has changed?

4

Perhaps, also worth mentioning that it briefly displays the Manjaro boot options on logout.

5

That’s because you had manually selected that on the previous boot and then didn’t choose any other option anymore afterwards. As such, grub remembers your last choice and tries to boot that way.

That is odd, and it suggests that there was something wrong with the kernel that was being loaded under the “Advanced Options”, so that it fell back onto another entry, which did work.

I don’t know. Without any further information on what kernel you’re running and what other kernels you have installed, it’s hard to say.

That’s harmless. That’s only because that information is still in the screen buffer that it switches to on logout.

6

I don’t recall needing to ever needing to go boot options on this install as it’s a fresh one made less than a month ago. It just decided to go into boot options on its own out of the blue. That’s what baffled me the most. :thinking:

I have only one kernel installed:

Currently running: 6.12.28-1-MANJARO (linux612)
The following kernels are installed in your system:
   * linux612
7

Actually, I just checked the pacman log:

$ grep -i installed /var/log/pacman.log
...
[2025-05-05T09:27:17+0100] [ALPM-SCRIPTLET] Grub will be installed on: EFI
[2025-05-06T09:19:46+0100] [ALPM] installed dotnet-host (9.0.4.sdk105-1)
[2025-05-06T09:19:46+0100] [ALPM] installed dotnet-runtime-6.0 (6.0.36.sdk136-2)
[2025-05-06T09:19:46+0100] [ALPM] installed netstandard-targeting-pack (9.0.4.sdk105-1)
[2025-05-06T09:19:46+0100] [ALPM] installed dotnet-targeting-pack-6.0 (6.0.36.sdk136-2)
[2025-05-06T09:19:47+0100] [ALPM] installed dotnet-sdk-6.0 (6.0.36.sdk136-2)
[2025-05-06T09:19:48+0100] [ALPM] installed dotnet-runtime-8.0 (8.0.15.sdk115-1)
[2025-05-06T09:19:48+0100] [ALPM] installed dotnet-targeting-pack-8.0 (8.0.15.sdk115-1)
[2025-05-06T09:19:49+0100] [ALPM] installed dotnet-sdk-8.0 (8.0.15.sdk115-1)
[2025-05-06T09:19:49+0100] [ALPM] installed dotnet-runtime (9.0.4.sdk105-1)
[2025-05-06T09:19:49+0100] [ALPM] installed dotnet-targeting-pack (9.0.4.sdk105-1)
[2025-05-06T09:19:51+0100] [ALPM] installed dotnet-sdk (9.0.4.sdk105-1)
[2025-05-14T22:24:11+0100] [ALPM] warning: /etc/hosts installed as /etc/hosts.pacnew
[2025-05-14T22:24:11+0100] [ALPM] warning: /etc/passwd installed as /etc/passwd.pacnew
[2025-05-14T22:24:11+0100] [ALPM] warning: /etc/shells installed as /etc/shells.pacnew
[2025-05-14T22:24:23+0100] [ALPM] installed electron36 (36.2.0-1)
[2025-05-14T22:24:57+0100] [ALPM] installed libxmp (4.6.2-3)
[2025-05-14T22:25:45+0100] [ALPM-SCRIPTLET] Grub will be installed on: EFI
[2025-05-19T09:21:50+0100] [ALPM] installed kwalletmanager (25.04.0-1)

I see something grub related has changed on the 5th of May and appeared again on 14th.

I suppose this could be related? Though, I don’t understand why it would manifest starting today if it’s an old issue.

8

There was some issue with the install-grub script — which is not the same thing as the grub-install command, mind you.

But I am wondering, do you have plymouth installed? This is known to cause problems, not to mention that it hides the output of the boot messages.

I would recommend editing /etc/default/grub and removing the words “quiet splash” from your boot options. Then, save the file and run… :point_down:

sudo grub-install --recheck && sudo update-grub
9

Yes I do.

Done it. Though the text goes too fast to read.

1 Like
10

What’s most important is whether there are any entries with a red “[FAILED]” in front of them.

11

All white with green ok’s. A few blue lines. But no red.

But the Manjaro boot setting issue happens before any logs are shown.
It goes straight from manufacturer logo into Manjaro boot settings.

12

Then you must press Esc friom the moment you see the menu, and this should put you back in the main menu. You only have a few seconds for doing this — 5 seconds by default.

Try this, and see whether it still behaves oddly.

13

The Esc only stops the timer in the menu.

No matter what I select within the menu (Manjaro, Manjaro on device, advanced options for Manjaro, advanced options for Manjaro on device), it doesn’t change that the system is booting straight into that menu every time.

The pre-problem snapshots gone. And it seems like it’s not a straightforward fix… bit disappointing as the system is only 3 weeks old.

Though a saving grace is that it being so fresh, it’s probably going to be quicker to go through the re-installing and setting the system back up from scratch at this point. Will do that tomorrow.

However, thanks for giving a helping hand! Hopefully this is a unique issue for my machine only.

1 Like
14

See, this is information you should have included. You obviously have a btrfs installation, and grub has problems with btrfs.

You see, by default — meaning that this behavior can be changed — grub saves the last-booted entry to the filesystem that /boot is on, so that it would become the default boot option for the next boot, unless overridden by the user. So far, so good.

However, grub cannot write to btrfs. It can read from it, but it cannot write to it.

There are two workarounds for this problem. The first is to modify /etc/default/grub and tell it not to attempt to save the booted entry, and possibly set a default entry in the file yourself, after which you run “sudo update-grub” in order to apply the new configuration.

The second workaround is to install your system with a separate ext4 partition for /boot. grub can write to ext4. You can then still use btrfs for the rest, if you like.

1 Like
15

Interesting. I didn’t connect the dots that it might be btrfs issue. :eyes: Seems hopeful!

First time using it. I’ve got it as I went with defaults during this installation and it suggested btrfs.

My grub file:

# GRUB boot loader configuration

GRUB_DEFAULT=saved
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR='Manjaro'
GRUB_CMDLINE_LINUX_DEFAULT='resume=UUID=688188fa-a564-45da-8b90-1d00b3306fd2 udev.log_priority=3'
GRUB_CMDLINE_LINUX=""

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

# Uncomment to enable booting from LUKS encrypted devices
#GRUB_ENABLE_CRYPTODISK=y

# Set to 'countdown' or 'menu' to change timeout behavior,
# press ESC key to display menu.
GRUB_TIMEOUT_STYLE=hidden

# Uncomment to use basic console
GRUB_TERMINAL_INPUT=console

# Uncomment to disable graphical terminal
#GRUB_TERMINAL_OUTPUT=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command 'videoinfo'
GRUB_GFXMODE=auto

# Uncomment to allow the kernel use the same resolution used by grub
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you want GRUB to pass to the Linux kernel the old parameter
# format "root=/dev/xxx" instead of "root=/dev/disk/by-uuid/xxx"
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY=true

# Uncomment and set to the desired menu colors.  Used by normal and wallpaper
# modes only.  Entries specified as foreground/background.
GRUB_COLOR_NORMAL="light-gray/black"
GRUB_COLOR_HIGHLIGHT="green/black"

# Uncomment one of them for the gfx desired, a image background or a gfxtheme
#GRUB_BACKGROUND="/usr/share/grub/background.png"
GRUB_THEME="/usr/share/grub/themes/manjaro/theme.txt"

# Uncomment to get a beep at GRUB start
#GRUB_INIT_TUNE="480 440 1"

# Uncomment to make GRUB remember the last selection. This requires
# setting 'GRUB_DEFAULT=saved' above.
GRUB_SAVEDEFAULT=false

# Uncomment to disable submenus in boot menu
#GRUB_DISABLE_SUBMENU=y

# Uncomment this option to enable os-prober execution in the grub-mkconfig command
GRUB_DISABLE_OS_PROBER=false

# Uncomment to ensure that the root filesystem is mounted read-only so that
# systemd-fsck can run the check automatically. We use 'fsck' by default, which
# needs 'rw' as boot parameter, to avoid delay in boot-time. 'fsck' needs to be
# removed from 'mkinitcpio.conf' to make 'systemd-fsck' work.
# See also Arch-Wiki: https://wiki.archlinux.org/index.php/Fsck#Boot_time_checking
#GRUB_ROOT_FS_RO=true

I’m guessing I’d need to modify the GRUB_CMDLINE_LINUX_DEFAULT?
Is there a way to determine what the new value should be?

16

No, this one… :point_down:

Change that to… :point_down:

GRUB_DEFAULT=0

If you dual-boot with another distribution or with Microsoft Windows, then you should change this one… :point_down:

… to… :point_down:

GRUB_TIMEOUT_STYLE=menu
17

Hey, I had the same issue. As @Aragorn has pointed out, it’s related to plymouth with the latest and “greatest” Nvidia drivers. It was also mentioned in the release updates:

Although it doesn’t say you need also to remove quiet from the from boot options. Once I removed it, the problem was gone for me. Don’t forget the regenerate the grub configuration with grub-install.

No need to reinstall your system, just avoid Nvidia in the future :+1:.

3 Likes
18

Strictly speaking, it’s not necessary, as long as splash — i.e. plymouth — is disabled.

But indeed, plymouth in combination with Nvidia is a recipe for trouble. :wink:

No, with… :point_down:

sudo update-grub

:wink:

1 Like
19

I gave it a go, but with no luck.
Thanks for the suggestion, however.

20

Still no luck.
But I’ll give it a go with switching to the ext4 on reinstall.