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:
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
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.
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
The only things I added were standard stuff:
Neither were open. As well, everything else was closed.
Not worried.
Thanks
~s
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.
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.
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/0x198Note: 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.
Yup it is a kernel bug
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.’
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.
Well, they could easily be much clearer about:
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,
Sure, I suggest creating a separate topic in the Feedback category about your points:
You can also send an email to Purism:
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.
Meh. I’m talking from experience not what I want to portray Puri as.
It is what it is and can’t be helped.
Edit: typo
How does the “bug” affect customers with L5’s and is it on all L5’s regardless of if it’s Fir, Amber, Byzantium, and now Crimson?
Of all the places a customer should bookmark, is there a way to find out, without reading volumes of of places that might keep customers up to date? Maybe send out emails like we get when there is a new post we’re following? You know, the short route.
The activity in the Librem 5 GitLab groups can be followed here: Activity · Librem5 · GitLab. You can subscribe to the RSS feed of this page.
Regarding my suggestion to file a bug: I did this suggestion because some people provided detailed technical feedback. Here in the forums this information can easily ‘get lost’, while in an issue in GitLab it is easier findable, visible, and accessible, which also increases the chance that it gets fixed.
I’ve reviewed the links you give. But please understand I bought the L5 because I read all the ads and by all that is stated in the ads, the L5 is as good as or better than the latest Android/IoS phones. People I know with those don’t have to wait in line at Git to find out what the Hades is wrong with their L5.
My question didn’t expect a link to yet another site that requires one to learn the language of Techineze. I don’t care what “Merge branch ‘drv2624_vibra’ into 'main’” means, nor should I have to learn it. I just want to know, as I asked in my question:
I sent the L5 back on a RMA proceeded by a lot of emails asking me questions that I answered and fired back that ended up in Got trash can. Needless to say, it was a waste of time because nothing was fixed. I hoed a kernel bug report might be the reason the phone capabilities fall way way shorty of the ads pomp and circumstance.
So, in another way then, is it possible that this kernel bug is the root cause of the L5 unable to perform any where what ads imply?
Thanks janvlug and sorry for not being more precise in my question,
~s
So I don’t know a whole lot about the problem but I do know it it is now not present in my L5(s) after a recent kernel upgrade.
See this post for details about what I know.
I understand this from a regular customer perspective. I indeed kind of misunderstood your question. The link is indeed to a technical site.
I do not have the ‘not shutting down properly’ issue on my Librem 5 Byzantium, otherwise I might have reported it my self. So not all Librem 5’s are affected. I like to have all issues reported, so that they can be tracked, and hopefully eventually fixed.
I do not think the kernel bug is the root case of issues with your Librem 5. But this is more a guess than a known fact.