Open loonglade opened 5 months ago
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 ifup@.service
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.
I get this message on boot, which gets stucked (waited over an hour) and doesn't move:
Required Information
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