Boot stuck at bluetooth.target

[loonglade]

I get this message on boot, which gets stucked (waited over an hour) and doesn't move:

[ OK ] Reached target local-fs.target - Local File Systems.
Starting console-setup.service - Set console font and keymap...
Starting systemd-binfmt.service - Set Up Additional Binary Formats...
Mounted proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System.
[ OK ] Finished console-setup.service - Set console font and keymap.
[ OK ] Finished systemd-binfmt.service - Set Up Additional Binary Formats.
Starting systemd-tmpfiles-setup.service - Create Volatile Files and Directories.
Finished systemd-tmpfiles-setup.service - Create Volatile Files and Formats.
Starting systemd-update-utmp.service - Update UTMP about System Boot/Shutdown.
Finished systemd-update-utmp.service - Update UTMP about System Boot/Shutdown.
[ OK ] Started systemd-timesyncd.service - Network Time Synchronization.
[ OK ] Reached target time-sync.target - System Time Synchronized.
[ OK ] Reached target time-set.target - System Time Set.
Starting ifupdown-pre.service - Helper to synchronize boot up for ifupdown.
Finished ifupdown-pre.service - Helper to synchronize boot up for ifupdown.
Starting networking.service - Raise network interfaces.
[ OK ] Finished networking.service - Raise network interfaces.
[ OK ] Reached target network.target - Network is up.
Listening on systemd-rfkill.socket - Load/Save RF Kill Switch Status.
Starting systemd-rfkill.service - Load/Save RF Kill Switch Status...
Started hciuart.service - Configure Bluetooth Modems connected by UART.
[ OK ] Created slice system-bthelper.slice - slice/system/bthelper.
Listening on dbus.socket - D-Bus System Message Bus Socket.
Starting [email protected] - Raspberry Pi bluetooth helper...
Started systemd-rfkill.service - Load/Save RF Kill Switch Status.
[ OK ] Started dbus.service - D-Bus System Message Bus.
Starting bluetooth.service - Bluetooth service.
[ OK ] Started bluetooth.service - Bluetooth service.
[ OK ] Started hciuart.service - Configure Bluetooth Modems connected by UART.
[ OK ] Reached target bluetooth.target - Bluetooth Support.

Required Information

• version | latest - Armv6 bookworm
• SBC model | RPI zero W
• Power supply used | 5v2a
• SD card used | Patriot class 10

Steps to reproduce

I believe this happens when WiFi is enabled/disabled and then a reboot is performed, but not 100% sure. This has happened to me 3 times now and having to re-flash.

Extra details

• Tried Ctrl+c, nothing happens
• Restart always result in the same behavior
• Tried Shift or F5 as maybe that would boot into some kind of safe mode, but no.

[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.