Hey Everyone,
I have my GRUB set on a default timeout of 2 seconds, but it takes nearly 5 seconds before it proceeds to move forward with the default OS choice. This is without me interacting with it and just leaving it to automatically boot into the Default OS (Manjaro).
Not sure where this delay / lag is coming from. Anyone else experiencing anything similar?
Thanks!!
And if you interact with the arrows, does it lag?
Nope, no lag. If I interact and select Linux or Windows, it boots as soon as I hit enter as expected.
Not so long ago someone posted a similar topic.
There was nothing wrong - it just takes a few seconds for the plymouth loader to display.
If your system boots in EFI mode you could use another boot loader e.g. rEFInd. This allows for booting the kernel directly.
I appreciate it. Is there not a way to adjust Plymouth to boot later in the boot process (after Grub)? I assume I need Plymouth at login time (GDM).
plymouth is executed in init - and - you can remove plymouth - there is a guide somewhere in the forum - in short
rebuild init and grub config
One of the first things I do on any installation is remove plymouth. Itâs like the brakes on a carâthey only slow you downâŚ
But you do need those brakes. Nobody needs plymouth. 
Even the ISO images do not need Plymouth 
Remove it, remove also quiet from the boot line beside splash an see what happens.
Can anyone provide the steps needed to remove Plymouth please? Thank you!
Remove the word(s) splash (and optionally, quiet) from the line near the top of /etc/default/grub⌠
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash udev.log_priority=3"
Remove the word plymouth from the âHOOKS=( base udev ...â line near the bottom of /etc/mkinitcpio.conf.
Issue the following commands in a terminal windowâŚ
sudo mkinitcpio -P
sudo update-grub
sudo pacman -R plymouth
Thank you! So, another interesting part of the story, it looks like at some point in the past I ALREADY removed Plymouth. However, I am still getting the lag with Grub (I completed all the steps and all my configs are already modified @Aragorn).
This lag started fairly recently (1-2 months ago), so my assumption here is an updated package may have introduced something.
Any other ideas from anyone? Thank you so far for the help!
2 shots in the dark from me: you may try with and without kms hook in the hooks. Or in the grub config uncomment
#GRUB_TERMINAL_OUTPUT=console
Just to test.
Sure! Can you expand on what these 2 changes actually control behind the scenes?
Thank you!
Yes, I do.
I donât consider it a functional issue; nor a problem to be fixed.
Deactivating or removing the Plymouth splash screen (mentioned) is, however, a popular act of vandalism, regardless. 
The post from @Aragorn (above) will give you what you immediately need, but as a detailed reference, the following âHowToâ is suggested for anyone finding this thread.
Regards.
Kms are the video drivers. They coud be included earlier in the boot process or later. Earlier is usually better but one never knows.
The console output deactivates the nice styling of the grub menu, another graphics related thing.
Remove grub - use rEFInd or use the EFI system to load the OS from a unified kernel.
It is easy to implement.
But I really donât understand what a few seconds shaved of the loading time matters.
That is probably just me.
I know the faster the system is declared; we think the faster it should boot; but hardware can only initialise so fast, and no matter the gimmicks - it is just as fast as the total compound of hardware can be initialised.
My workstation takes around 90 seconds to fully load and the parts must be powered on in a specific sequence - and I only do this in the morning.
I have two USB disks connected to USB-C10 Perhaps I could shave of a few seconds by disconnecting them - but to what end? 
I am not there - I am boiling water to make coffee - lighting up the stove so we have heat in the house - petting the cats - enjoying the quiet - chatting with my wife if sheâs awake - when I get back the system is up - no big fuzz
Best result is with a LTS kernel. Stable branch only has 6.12 but testing and unstable provides 6.18.
Ensure you have enough free space on the $esp - usually mounted at /boot/efi but you must be root to access the content.
sudo df /boot/efi
Edit /etc/mkinitcpio.d/linux618.preset or /etc/mkinitcpio.d/linux612.preset depending on availablitity on your system to look similar to below example (I donât use the fallback image so I have commented that as well - saves space on $esp partition.
# mkinitcpio preset file for the '6.18-x86_64' package
#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-6.18-x86_64"
PRESETS=('default')
#PRESETS=('default' 'fallback')
#default_config="/etc/mkinitcpio.conf"
#default_image="/boot/initramfs-6.18-x86_64.img"
default_uki="/efi/EFI/Linux/manjaro-6.18-x86_64.efi"
default_options="--splash /usr/share/systemd/bootctl/splash-manjaro.bmp"
#fallback_config="/etc/mkinitcpio.conf"
#fallback_image="/boot/initramfs-6.18-x86_64-fallback.img"
#fallback_uki="/efi/EFI/Linux/manjaro-6.18-x86_64-fallback.efi"
#fallback_options="-S autodetect"
Note the path in /efi/EFI/Linux/manjaro-6.18-x86_64.efi - it does not yet exist and you need to create it manually and refactor your /etc/fstab to mount the $esp at /efi instead of /boot/efi
sudo mkdir /efi/EFI/Linux
Then mount your $esp at /efi
sudo mount /dev/<disk><partnum> /efi
Grab your currently booted cmdline
cat /proc/cmdline | sudo tee /etc/kernel/cmdline
This is an example from my system booting UKI via EFI.
root=UUID=cafce1fc-a404-48b9-b7e8-00ec59a4e2c0 rw quiet nowatchdog mitigations=off lsm=landlock,lockdown,yama,integrity,apparmor,bpf
Yours will likely have BOOT_IMAGE or perhaps init entries - those must be removed otherwise the system will not boot from the entry.
The remainder - in most circumstances it will be like this - perhaps including quiet, splash and udev.log_priority=3
The file /etc/kernel/cmdline must be modified to reflect this
sudo micro /etc/kernel/cmdline
This is an example - please adjust accordingly
root=UUID=cafce1fc-a404-48b9-b7e8-00ec59a4e2c0 rw quiet udev.log_priority=3
Then run mkinitcpio to create the UKI (adjust if using another kernel)
sudo mkinitcpio -p linux618
Donât get worried about the possible message from about Secureboot key directory. If you do - simply run sudo sbctl create-keys and the message will go away - because now your UKI will be signed automagically.
Then create a EFI boot entry - replace <disk> with the actual disk (usually sda or nvme0n1) and <part> with the actual partition number (usually 1)
sudo efibootmgr --create --disk /dev/<disk> --part <part> --loader '\EFI\Linux\manjaro-6.18-x86_64.efi' --label 'Manjaro 6.18' --unicode --index 0
List the entries using and verify you have similar entry - especially watch out for the UUID - it must include a valid UUID - zeroes are not valid
Also doublecheck the loader - it must exist as
$ efibootmgr
...
Boot0000* Manjaro 6.18 HD(1,GPT,9981070a-c172-4eae-98e7-296dfcc243b6,0x6e9e7000,0x400000)/\EFI\Linux\manjaro-6.18-x86_64.efi
...
When you reboot your system - use your firmware hotkey for boot override - examples F2, F7 or F12 - if you donât know consult your system manual.
Then select the Manjaro 6.18 entry - or whichever label you gave it
No, itâs not just you. Mine takes maybe 45/60 seconds to fully load (including anything set to run at login).
The actual boot phases vary â I set rEFInd to a 5sec timeout, which in turn boots Grub; I havenât disabled Plymouth yet since installing to a new SSD, but itâs still somewhere around 25 seconds before reaching SDDM.
So thatâs 25-10 (rEFInd + Grub timeouts) = 15
(Fast enough for me)
I have nobody here that cares how long my machine takes to boot, so thereâs no boasting value, either; nothing to prove.
Wonderful. You even have time to have a shave. 