I don’t think you will find any simple way to do what you want on GNOME, if it’s even possible at all. The answer linked below is from an Ubuntu community but most of what is said there applies on any distro. (Ignore the rest of the answers there, they are many years old).
My guess is that the easiest solution is to use KDE or Xfce instead of GNOME…
Makes my 
my KDE even more and I didn’t think it was even possible…
So remove quiet and if you use plymouth disable it. You need to see what is going on.
If you use Grub to unlock your Boot and/or Root partition, you need to unlock it first. Otherwise the Grub menu will not be shown, since it is stored in the locked boot folder.
I tried to change the PAM GDM files (commented all lines with pam_gnome_keyring.so out) and it worked as expect. However I do not use Grub to unlock my LUKS devices and I do not use plymouth.
Okay, I tried it again. Turns out it’s almost impossible to enter the grub menu on Manjaro without a degree is you have LUKS enabled. I had to enter my LUKS password and then had to wait a few seconds until the volume was decrypted, then I had to immediately press Esc. One second earlier and it would have cancelled the decryption, one second later and it would have been too late.
I’d much rather have a shortcut other than Esc that wouldn’t throw me into rescue mode if pressed too early. I guess I’ll have to set GRUB_TIMEOUT_STYLE from hidden to menu in the grub config.
Anyway, after entering grub I was able to select a timeshift snapshot, but not the one I created right before making the pam.d changes because timeshift failed to run update-grub or whatever to add those snapshots to the menu. Very unfortunate that this doesn’t happen automatically. So I had to boot my live USB again to fix things.
I got stuck at [ OK ] Started Modem Manager. btw.
Then after removing plymouth, I got stuck at [ OK ] Started Thunderbolt system service.
No obvious errors.
My changes btw:
# before making changes:
$ grep -r "pam_gnome_keyring.so" /etc/pam.d/
/etc/pam.d/gdm-autologin:auth optional pam_gnome_keyring.so
/etc/pam.d/gdm-autologin:session optional pam_gnome_keyring.so auto_start
/etc/pam.d/gdm-fingerprint:auth optional pam_gnome_keyring.so
/etc/pam.d/gdm-fingerprint:session optional pam_gnome_keyring.so auto_start
/etc/pam.d/gdm-password:auth optional pam_gnome_keyring.so
/etc/pam.d/gdm-password:password optional pam_gnome_keyring.so use_authtok
/etc/pam.d/gdm-password:session optional pam_gnome_keyring.so auto_start
/etc/pam.d/gdm-smartcard:auth optional pam_gnome_keyring.so
/etc/pam.d/gdm-smartcard:session optional pam_gnome_keyring.so auto_start
# apply changes
$ sudo sed -i '/pam_gnome_keyring.so/s/^/#/' /etc/pam.d/*
# after making changes
$ grep -r "pam_gnome_keyring.so" /etc/pam.d/
/etc/pam.d/gdm-autologin:#auth optional pam_gnome_keyring.so
/etc/pam.d/gdm-autologin:#session optional pam_gnome_keyring.so auto_start
/etc/pam.d/gdm-fingerprint:#auth optional pam_gnome_keyring.so
/etc/pam.d/gdm-fingerprint:#session optional pam_gnome_keyring.so auto_start
/etc/pam.d/gdm-password:#auth optional pam_gnome_keyring.so
/etc/pam.d/gdm-password:#password optional pam_gnome_keyring.so use_authtok
/etc/pam.d/gdm-password:#session optional pam_gnome_keyring.so auto_start
/etc/pam.d/gdm-smartcard:#auth optional pam_gnome_keyring.so
/etc/pam.d/gdm-smartcard:#session optional pam_gnome_keyring.so auto_start
Why is it so complicated or impossible to disable Gnome Keyring on Manjaro when it’s so easy on other distributions?
Seeing as I don’t use Gnome (don’t like playing in heaps of sh…erm yeah) I don’t know about Gnome keyring actually. But from what I’ve read is that it’s very close to, if not completely impossible. But these looks promising:
https://c3pb.de/blog/keepassxc-secrets-service.html
Anything else…
I should’ve checked earlier, but:
https://wiki.archlinux.org/title/KeePass#Secret_Service
There is a section Secret Service, so that’s possibly it.
According to this page:
How to Disable GNOME Keyring Arch Linux
This feature bothers a lot of people and is generally considered really annoying because it keeps nagging you for a password even though you have never set it up or asked it to store passwords for you.
On Arch Linux it is apparently possible to disable the GNOME keyring with the following instructions.
Copy these files to your autostart directory:
cp /etc/xdg/autostart/gnome-keyring-gpg.desktop ~/.config/autostart cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostartSet autostart to disabled for each of these:
vi gnome-keyring-gpg.desktop:X-GNOME-Autostart-enabled=false
gnome-keyring-ssh.desktop:X-GNOME-Autostart-enabled=false
(Or something like that, anyway.)
You will need to make the boot process more verbose, check the other Kernel command line options you are using. Or boot up your system and check the journal messages for the last boot, this will not work if you restore form timeshift. You will need to fix your system via a live environment and the the journal form there (Hint: --directory= will be needed) or boot your normal system and use -b-1 for the last boot.
The problem the OK lines are that these are the last successful started services, it does not show which service failed. Also depending at which state it stops, you can still switch to a tty.
I just needed to do three things, disable the systemd user service for the keyring, comented out the pam entries for pam_gnome_keyring.so and removed /etc/xdg/autostart/gnome-keyring-secrets.desktop . I had no problem booting and no keyring service was running after login.
Did not seems to be that complicated.
Turns out you are right, I was indeed able to switch into a tty. From there I was able to find the errors:
$ journalctl -b -p 3
Aug 26 18:04:29 tvk-xps159575 gdm-autologin][665]: PAM bad jump in stack
Aug 26 18:05:38 tvk-xps159575 systemd[782]: gnome-keyring-daemon.socket: Socket service gnome-keyring-daemon.service not loaded, refusing.
Aug 26 18:05:38 tvk-xps159575 systemd[782]: Failed to listen on GNOME Keyring daemon.
I was not able to restore my pam.d backup from tty though because after deleting the current pam.d directory, sudo stopped working so that I couldn’t cp the backup into /etc. So I had to boot into the live USB again to fix it.
I really wonder how our systems differ. Maybe gnome keyring is somehow integrated into the whole LUKS thing?
Well that is an explanation. I would not use autologin. 
The problem is the line in /etc/pam.d/gdm-autologin above the first with pam_gnome_keyring.so
The default action is to skip one line, which means to skip system-local-login. (Or something similar, I not that similar with the pam actions, or the error is because this is now the last one starting with auth)
Either way, remove the # from this line, since it is not the auto_start, or use the optional shorthand action just for a test.
Oh, I see, I’d like to use autostart though because I already have LUKS encryption and don’t want to enter a second password every time with every restart.
My /etc/pam.d/gdm-autologin looks like this:
#%PAM-1.0
auth required pam_shells.so
auth requisite pam_nologin.so
auth optional pam_permit.so
auth required pam_env.so
auth [success=ok default=1] pam_gdm.so
auth optional pam_gnome_keyring.so
account include system-local-login
password required pam_deny.so
session include system-local-login
session optional pam_gnome_keyring.so auto_start
I’m not sure which line you are referring to that I should uncomment or add optional to.
I would try this:
#%PAM-1.0
auth required pam_shells.so
auth requisite pam_nologin.so
auth optional pam_permit.so
auth required pam_env.so
auth [success=ok default=1] pam_gdm.so
auth optional pam_gnome_keyring.so
account include system-local-login
password required pam_deny.so
session include system-local-login
#session optional pam_gnome_keyring.so auto_start
No # in front of auth optional pam_gnome_keyring.so
or
#%PAM-1.0
auth required pam_shells.so
auth requisite pam_nologin.so
auth optional pam_permit.so
auth required pam_env.so
auth optional pam_gdm.so
#auth [success=ok default=1] pam_gdm.so
#auth optional pam_gnome_keyring.so
account include system-local-login
password required pam_deny.so
session include system-local-login
#session optional pam_gnome_keyring.so auto_start
Both lines with pam_gnome_keyring.so with a # and a little different line for pam_gdm.so
I’m not sure if the second will work.
With the first suggestion, the keyring now starts like so:
/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
with its parent being /usr/lib/systemd/systemd --user.
I don’t understand why because I masked the service:
$ systemctl --user status gnome-keyring-daemon.socket
○ gnome-keyring-daemon.socket
Loaded: masked (Reason: Unit gnome-keyring-daemon.socket is masked.)
Active: inactive (dead)
$ systemctl --user status gnome-keyring-daemon.service
○ gnome-keyring-daemon.service
Loaded: masked (Reason: Unit gnome-keyring-daemon.service is masked.)
Active: inactive (dead)
Also, I was asked for the keyring password as soon as Gnome was showing up.
I will try the second suggestion now.
Edit:
With your second suggestion, I got the exact same results.
You don’t need to, it will be the same result.
Please see my short summary
Check the status command, it will now be in a different spot. You fixed two, but there are tree things you need to do. The suggestion to copy the desktop file to the Home autostart folder and edit it did not worked for me. I simply removed the desktop file in /etc/xdg/autostart/ .
I had deleted the filed from /etc/xdg/autostart as well.
The only error left is:
Aug 26 20:30:27 tvk-xps159575 systemd[688]: Failed to start Application launched by gnome-session-binary.
I’m not sure you can fix it. If a program starts that needs the Gnome-Keyring it will fail. Maybe, if you use your other secrets provider, it will go away on it self?
Just keep in mind that the file will be restored the next time gnome-keyring will be updated. You might want to add it to NoExtract in your pacman.conf.
The thing with KeypassXC is that you can only enable the secret service integration, if gnome keyring is not running. When I kill Gnome keyring forcefully, I can enable the KeepassXC secret service integration, but on the next reboot Gnome keyring will overrule it again.
You could always create a systemd timer un8it to run on login that disables it…
Just a thought…
More info:
https://wiki.archlinux.org/title/systemd/User
Also see:
Yes, I know that isn’t a solution. It’s but a workaround. It’s also the only thing that I can think of.
So then again check the systemctl status command and tell use where the process is.
Here is the (relevant) output:
State: running
Units: 433 loaded (incl. loaded aliases)
Jobs: 0 queued
Failed: 0 units
Since: Sun 2023-08-27 19:44:57 CEST; 37s ago
systemd: 253.8-1-manjaro
CGroup: /
├─init.scope
│ └─1 /sbin/init splash
├─system.slice
└─user.slice
└─user-1000.slice
├─session-1.scope
│ ├─742 "gdm-session-worker [pam/gdm-autologin]"
│ ├─774 /usr/lib/gdm-wayland-session /usr/bin/gnome-session
│ └─779 /usr/lib/gnome-session-binary
└─user@1000.service
├─app.slice
└─session.slice
├─dbus.service
│ ├─1100 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets
Now it is started by dbus. This means you startet a program that needs the keyring running. Is that immediately after your system reached the GUI or after you start programs. Do use Wifi with NM and saved the password only for your user? Which program do you use that needs the gnome-keyring? A browser for example? You can try to use dbus-monitor (without any parameter) but there is usually a lot, and you need to start it before the gnome-keyring process is started.
If you are not able to find the program that sends the dbus request, there are 3 files in /usr/share/dbus-1/services/ that will start the gnome-keyring process .
It happens before starting any applications and I’m not sure which application would want to start it. My Wifi passwords don’t appear to be managed by Gnome keyring.
Any ideas how I could achieve that? autostart would probably too late, right? I tried creating a systmd service that starts right after dbus.service:
[Unit]
Description=DBus Monitor Service
After=dbus.service
Requires=dbus.service
[Service]
ExecStart=/usr/bin/dbus-monitor > /var/log/dbus-monitor.log 2>&1
Restart=always
[Install]
WantedBy=default.target
But it failed:
× dbus-monitor.service - DBus Monitor Service
Loaded: loaded (/etc/systemd/system/dbus-monitor.service; enabled; preset: disabled)
Active: failed (Result: exit-code) since Sun 2023-08-27 22:06:35 CEST; 1min 24s ago
Duration: 1ms
Process: 678 ExecStart=/usr/bin/dbus-monitor > /var/log/dbus-monitor.log 2>&1 (code=exited, status=1/FAILURE)
Main PID: 678 (code=exited, status=1/FAILURE)
CPU: 2ms
Aug 27 22:06:35 tvk-xps159575 systemd[1]: dbus-monitor.service: Scheduled restart job, restart counter is at 5.
Aug 27 22:06:35 tvk-xps159575 systemd[1]: Stopped DBus Monitor Service.
Aug 27 22:06:35 tvk-xps159575 systemd[1]: dbus-monitor.service: Start request repeated too quickly.
Aug 27 22:06:35 tvk-xps159575 systemd[1]: dbus-monitor.service: Failed with result 'exit-code'.
Aug 27 22:06:35 tvk-xps159575 systemd[1]: Failed to start DBus Monitor Service.
(/var/log/dbus-monitor.log does not exist btw)