Boot stuck at bluetooth.target

[loonglade]

Boot stuck at bluetooth.target

[MichaIng]

Hmm, where do you see this output, on some attached HDMI or LCD screen, SSH or serial console?

I am missing quite some targets/services, and also the order is strange: I do not see any network adapter/interface being configured. There should be some ifup for eth0 or ifup for wlan0, after ifupdown-pre.service, and before network.target and then a network-online.target reached. But System Time Synchronized sounds like network time synchronisation happened already, which should not be possible without network. But maybe I misinterpret that message, and it is more about synchronising a timestamp, stored on shutdown, as a starting point before actual network is there. Of is this device offline intentionally?

If network is intentionally disabled, no [email protected] exists, and network-online.target should be reached right after network.target, as nothing else delays it. But even if it for some reason hangs, the login prompts. The relevant service for this is, and is also missing in your ase:

root@micha:/tmp# systemctl cat systemd-user-sessions.service
[Unit]
Description=Permit User Sessions
Documentation=man:systemd-user-sessions.service(8)
After=remote-fs.target nss-user-lookup.target network.target home.mount

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-user-sessions start
ExecStop=/usr/lib/systemd/systemd-user-sessions stop

• network.target has been reached already.
• home.mount does not exist, as long as you did not actually create an /etc/fstab entry to mount something at /home.
• remote-fs.target is delayed (and AFAIK even invoked) only by actual network mounts, like SMB/CIFS or NFS, which requires network, of course. If you have no such mount, this is irrelevant.
• nss-user-lookup.target is delayed only by local DNS servers/resolvers, like Pi-hole, AdGuard Home, dnsmasq and such, which of course also requires network. If you have no such server/service, this is irrelevant.

And even if any of those targets is delayed by some failing software/service start, they by default always have a timeout of 90 seconds, after which the boot order should continue regardless.

And while Bluetooth is the last seen message, it seems to have been started up, hence is not the problem. We do not see some "started" from the bthelper, but:

Description=Raspberry Pi bluetooth helper
Requires=hciuart.service bluetooth.service
After=hciuart.service
Before=bluetooth.service

So it started between hciuart.service and bluetooth.target, otherwise the letter would not have been reached. And as it was reached, there should not be anything regarding Bluetooth holding bootup any further, and, it generally does not/should not delay login prompts, definitely not forever.

So no idea, something is definitely odd, indeed. Do you have another console to try getting a command prompt, like SSH or a USB-UART adapter for serial console access (and a GPIO header soldered to the PCM), or HDMI + keyboard if this is not the case already?

I remember there were some cases where WiFi needed to be enabled for Bluetooth to work and/or the other way round. One case was on RPi 3+, where is was a firmware bug, which was solved in the meantime. So at least it is not impossible that this is somehow related. I'll at least try to replicate this on my RPi Zero W, i.e. enabling Bluetooth, then disabling WiFi. Currently I see neither that it does, not how it can delay boot, but I can be wrong.

Thinking about it, a failing network mount as of missing network would be actually a good explanation: The systemd automount feature has this nasty behaviour of blocking really everything until a 5 minutes timeout has been reached, including any input etc. And this happens every time, anything is trying to access the failing mountpoint, as it is tried to be mounted each time again. Quite a nasty behaviour, but on the other hand, this automount feature is quite helpful for slower USB drives etc. And it should be clear to remove network mounts, which are accessed automatically by something else, before/when disabling network.