L5 Doesn't Shut Down Properly - Not Important - Just Odd

Hardware Librem 5
,
1

This is just a FYI.

ISSUE:
When power off by swiping up from desktop, and clicking Power icon then Power Off, and Power Off again, the screen displays “Librem”. It sticks there and doesn’t go away any time soon.

Poor solution:
Hold Power button in until screen goes dark.

Example:
L5 sits for about 28 hours plugged in (to power adapter). I used L5 once to view a text file. Closed Chat, then pressed the Power button once to sleep mode(?)
Next morning, tapped Power button. Read a new text message.

Important:
After reading new text message, I noticed that the WiFi icon was off (no bars).
I swiped down, tapped the darkened WiFi button - no change.

Other attempts:
Tapped the Power button to sleep mode(?) then again to turn it on. No effect on WiFi.

Tapped Power icon - then tapped Power Off and again Power Off again on next screen.

Result:
Screen went black leaving “Librem” centre screen.
“Librem” remained on the screen for about 5 minutes, and finally went blank.

Rebooted:
Wifi was on. Powering off, "Librem stayed on for about 5 seconds - if that. All fixed - but odd.
This is 3rd time I’ve had this happen, not always though.

3 Likes
2

Not reproducible from my Librem 5 USA. I use the exact same procedure to turn it off, but everything behaves normally.

3

Happens to me ALL THE TIME. Rarely get a clean shutdown. Clean restart is even more rare.

Annoyance. Not going to bother with re-flash until Crimson.

3 Likes
4

Interesting to read that some people have shutdown and startup issues. My Librem 5 starts and shuts down without any issues (although I have to say I barely ever shut it down). I’m using Byzantium. Are these issues reported at the PureOS GitLab project: Librem5 / OS-issues · GitLab?

2 Likes
5

Probably not.

6

Can not reproduce either. I would suggest disabling plymouth to see which part of the process hangs exactly.

1 Like
7

Thank you for that, I did try to read, follow and understand but I am just a wannbe L5 user and am far removed from the pay-grade of L5 phone engineers and PureOS dos commands.

There are three ways to pass options to the kernel and thus control its behaviour:

:face_with_spiral_eyes:

It’s OK. As I said in the title it’s “Not Important” (to me).

Side note:
I was able to repeat it again today. Meh, It is what it is.

Thanks for the suggestions,
~s

2 Likes
8

It’s fine. Technically plymouth is used for the startup and shutdown animation which is shown instead of systemd commands going through. You could also try looking up logs (via GNOME Logs for example). The timestamps potentially indicate which step is taking longer than expected.

My guess would be you installed some software that activated a service which needs a bit longer to shutdown. Could also be some un-mounting process of a drive or similar. Unsure.

Likely it is just some issue on the road of securely shutting everything down. So it should not be worrying.

2 Likes
9

I read through all 230 open (93) issues and closed (137) issues from your link (repeated here).

I couldn’t find anything relevant. I read twice but could be wrong.

~s

2 Likes
10

The only things I added were standard stuff:

  • BM818 Tool
  • WARP

Neither were open. As well, everything else was closed.

Not worried.

Thanks
~s

1 Like
11

I only have the issue failing to shut down when I am doing convergence docking. It is based on how the device is used.

We can tap Volume Down on the Librem 5 to toggle away the “Librem 5” logo and show the ongoing log of what we are hanging on, instead.

The issue also coincides with when hardware kill switches stop working as expected and start just waiting indefinitely for the hardware. But I didnt read the tiny log text carefully to figure it out when it would hang; I just hard boot, and then use convergence less so I don’t have the problem. The Librem 14 for me is mostly “better than convergence,” it just seems like a great device, although I customized mine to make it feel that way.

2 Likes
12

So it might be USB driver related then, I guess. If docking or the kill switches make a difference. The cellular baseband is connected via USB as well.

2 Likes
13

I am intermittently (on average, once every several days or so) having an issue with similar symptoms, which may be caused by the same problem. In my case, something keeps getting hung up badly somewhere in the networking system, which causes various programs to also get super stuck and upon shutting down, it never completes and I have to hold down the power button. Along with this symptom, NetworkManager is hung and if I turn off the wifi switch, the status does not show wifi being off but after that point, nothing networking-related works anymore.

If it’s the same issue I’m having, you can check your dmesg log, and see if it contains something similar to this:

[86033.379958] INFO: task NetworkManager:443 blocked for more than 120 seconds.
[86033.387109]       Not tainted 6.6.0-1-librem5 #1
[86033.391784] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[86033.399641] task:NetworkManager  state:D stack:0     pid:443   ppid:1      flags:0x00000008
[86033.399667] Call trace:
[86033.399675]  __switch_to+0xf8/0x160
[86033.399711]  __schedule+0x2cc/0xb38
[86033.399723]  schedule+0x64/0xd8
[86033.399733]  schedule_timeout+0x1a0/0x1d0
[86033.399750]  wait_for_completion+0x7c/0x168
[86033.399762]  __flush_work.isra.0+0x178/0x2d0
[86033.399782]  __cancel_work_timer+0x12c/0x1b0
[86033.399794]  cancel_delayed_work_sync+0x1c/0x30
[86033.399806]  rfkill_pause_polling+0x34/0x50 [rfkill]
[86033.399856]  rsi_mac80211_stop+0x58/0xb0 [redpine_91x]
[86033.399933]  drv_stop+0x38/0x1b8 [mac80211]
[86033.400538]  ieee80211_stop_device+0x4c/0x68 [mac80211]
[86033.400755]  ieee80211_do_stop+0x628/0x838 [mac80211]
[86033.400971]  ieee80211_stop+0x54/0x198 [mac80211]
[86033.401187]  __dev_close_many+0xb4/0x160
[86033.401206]  __dev_change_flags+0xdc/0x218
[86033.401220]  dev_change_flags+0x2c/0x80
[86033.401232]  do_setlink+0x220/0xdd0
[86033.401248]  __rtnl_newlink+0x498/0x8c8
[86033.401261]  rtnl_newlink+0x58/0x90
[86033.401272]  rtnetlink_rcv_msg+0x12c/0x3a0
[86033.401284]  netlink_rcv_skb+0x64/0x150
[86033.401301]  rtnetlink_rcv+0x20/0x38
[86033.401312]  netlink_unicast+0x278/0x348
[86033.401323]  netlink_sendmsg+0x1e0/0x460
[86033.401333]  __sock_sendmsg+0x64/0xc0
[86033.401350]  ____sys_sendmsg+0x284/0x308
[86033.401362]  ___sys_sendmsg+0x88/0xf0
[86033.401376]  __sys_sendmsg+0x70/0xd8
[86033.401389]  __arm64_sys_sendmsg+0x2c/0x40
[86033.401402]  invoke_syscall+0x50/0x128
[86033.401419]  el0_svc_common.constprop.0+0x48/0xf0
[86033.401431]  do_el0_svc+0x24/0x38
[86033.401442]  el0_svc+0x30/0x88
[86033.401453]  el0t_64_sync_handler+0xc0/0xc8
[86033.401462]  el0t_64_sync+0x190/0x198

Note: this can be rather annoying, as it also causes the sudo command to hang (permanently, even ctrl+c, ctrl+z, etc. won’t stop it), generally rendering it impossible to get root privileges unless you already had a window open, or in my case, I re-enabled the root account, set a password, and use su instead of sudo. So, if you try to run ‘sudo dmesg’ and it just gets stuck, I bet it’s the same problem.

Me being very much not a fan of Poettering’s software, I want to blame this on NetworkManager, but more likely, it’s a kernel bug and NM just isn’t handling it gracefully.

1 Like
14

Yup it is a kernel bug

2 Likes
15

It might be a good idea to report this issue here: Issues · Librem5 / linux · GitLab

2 Likes
16

You do know that GitLab is not taking on new members without jumping through a lot of hoops and hurdles. They should hire someone that knows how to beat spam.

GitLab
Due to an influx of spam, we have had to impose restrictions on new accounts. Please see this page for instructions on how to get full permissions. Sorry for the inconvenience.

What a thing to have to tell customer to do. ‘Go file it at GitLab yourself.’

1 Like
17

Purism operates their own GitLab CE server, so they must manually handle spam with the limited resources they have, which currently means auditing/vetting each account registration for approval. @janvlug provided a suggestion, not a demand, and their post does not match your quote.

1 Like
18

Well, they could easily be much clearer about:

  • That nothing will happen until approval is actively requested
  • What the email address of the “gitlab administer” to notify is
  • That git@puri.sm is send only, if that is the case

As near as I can tell by what finally worked for me, approval requests need to be proactively submitted to info@puri.sm after applying for an account via the web form. git@puri.sm did not work for me even though that is where the email confirming acoount creation,

1 Like
19

Sure, I suggest creating a separate topic in the Feedback category about your points:

You can also send an email to Purism:

2 Likes
20

Yeah, I’ve been meaning to and your post has moved me to try to make the time to do so.

Post #17 just pushed my need to vent over the top.

2 Likes