I had a laptop that was hanging for a while on boot, and I traced the issue to the journal entry "Unexpected error response from GetNameOwner(): Connection terminated" bug mentioned above. Editing nsswitch.conf was necessary.
A recent update to nsswitch.conf (which now includes the line "group: files [SUCCESS=merge] systemd") has resolved the issue for me; perhaps that update was the actual solution here, too.
So you think it was the kernel?
What about now? Does the broken kernel boot properly.
Or explain what you think was the problem.
And how was it fixed/resolved?
The linked issue is very complicated, several users reported weird observations, like yours (issue cleared with dbus-broker and still no issue after disabling dbus-broker, and others).
FWIW I did my tests/troubleshooting on the same kernel, although I tested my backup one.
well I've taken my time and run through a lot of scenarios, and I believe the culprit to be this nsswitch.conf update that I applied last week. Every other situation results in similar issues, albeit from varying "directions" (sometimes dbus-broker seems culpable, other times another process), but in the end adjusting nsswitch.conf and removing the additional lines that were added from the update last week (I need to look through my pacman log and see if I can find the version number where the changes are first applied or maybe look up the commit in the repo). I still have the patch file I created from diff'ing the original and .pacnew files after the update....it is as follows:
4,5c4,5
< passwd: files
< group: files
---
> passwd: files systemd
> group: files [SUCCESS=merge] systemd
10c10
< hosts: files mymachines myhostname mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns wins
---
> hosts: files mymachines myhostname resolve [!UNAVAIL=return] dns
Hopefully that helps anyone who no longer has the original file to know what to revert....but, personally, I think this is the root of the issue- at least from my limited knowledge. Whoever is responsible for the nsswitch package may be dealing with bigger fish, because obviously the new config additions aren't performing as intended, but that's honestly over my head at this point....but give me 6 months 
It's an odd little bug that only affects a small number of users. In my case, it affected only one out of 6 computers, all running essentially the same Arch installation. One of my other laptops is identical to the affected one, but did not hang at boot. 
There are several workarounds that help some people but not others; removing the "systemd" mention from nsswitch.conf is the only "fix" that seems to work reliably for everyone.
The new nsswitch config did correct the issue with my laptop; I can confirm that it was the conf file by using the old config, which brings the hang back. Very strange bug, and again, it only affects a small group of users.
I really thought this was the fix for now but noticed that some maybe more of the systemd timers and services would show they ran successful but didn’t run. The logs showed me no errors.
When reverted back to what was working for me, the timers and services worked as expected.
As @tardy posted above it’s an odd little bug that only affects a small number of users.
@sammiev, IIRC, you were the first person I ever saw mention the bug, on an old, no-longer-working forum.
Found a few post back from that time of people having the same error back from years a go and tried a few things that worked and some that didn't. Glad the work around from back then is still working today. It will be interesting to see what the true fix will be when it's released.
Can you give an example?
This is a complicated issue, involving several combined apps/utilities that should inter-communicate, where they some times fail, in certain circumstances.
dbus-broker (I think), being a kind of dbus wrapper, makes communication better. I wonder what/if this has also consequences as you noticed…
I have a timer set to run at midnight every night which it does on all my installs. ( Arch and Debian base OS )
It shows it did run at Midnight successfully but the file was never created, logs show no errors when run. When removing dbus-broker and disabling the service and timer the file was been creating again. So was fstrim and all the other services, timers working? Yes they all showed they ran but I wasn’t going to count on it as I never had troubles before this.
My fstrim seems run successfully
$ journalctl -u fstrim --no-hostname --no-pager
-- Journal begins at Fri 2021-01-22 12:52:13 EET, ends at Tue 2021-02-02 22:53:54 EET. --
Ιαν 25 01:49:04 systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Ιαν 25 01:49:07 fstrim[16795]: /home: 42,2 GiB (45275856896 bytes) trimmed on /dev/nvme0n1p6
Ιαν 25 01:49:07 fstrim[16795]: /boot: 342,1 MiB (358744064 bytes) trimmed on /dev/nvme0n1p4
Ιαν 25 01:49:07 fstrim[16795]: /: 9,2 GiB (9854291968 bytes) trimmed on /dev/nvme0n1p5
Ιαν 25 01:49:07 systemd[1]: fstrim.service: Succeeded.
Ιαν 25 01:49:07 systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
-- Boot fa84e8abd2b8465aa38a43e1937b7935 --
Φεβ 01 00:46:07 systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Φεβ 01 00:46:09 fstrim[141586]: /home: 41 GiB (44034719744 bytes) trimmed on /dev/nvme0n1p6
Φεβ 01 00:46:09 fstrim[141586]: /boot: 342 MiB (358567936 bytes) trimmed on /dev/nvme0n1p4
Φεβ 01 00:46:09 fstrim[141586]: /: 5,1 GiB (5525708800 bytes) trimmed on /dev/nvme0n1p5
Φεβ 01 00:46:09 systemd[1]: fstrim.service: Succeeded.
Φεβ 01 00:46:09 systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
broker install
$ LANG=en pacman -Qi dbus-broker | grep Date
Build Date : Thu Jan 21 00:58:56 2021
Install Date : Wed Jan 27 17:12:58 2021Thread is deemed abandoned.
Thread is now closed.
PM a mod if you are the OP and wish the issue reopened.