Maybe. Maybe not. I would check the system journal to see whether the phone actually rebooted or whether a less dramatic disruption occurred.
This is good advice. You can check the end of the system journal from the previous boot using the command:
journalctl -e -b -1
Something else Iāve noticed is that my phone will shut off when itās on battery power and firefox is loading a page sometimes. However, I donāt have a Librem 5 (still waiting on it), I have a PinePhone Pro running Phosh. Not sure if you are having the same issue as me but I thought Iād mention it just in case.
You can also get a clue about a reboot using the command āuptimeā. It will tell you how long the system has been powered on in its current boot session.
Ah, simple and effective - thanks! Iāll check next time I suspect it has rebooted on me.
Alright, I confirmed it is randomly rebooting with uptime
as well as the two times it rebooted in the middle of listening to a podcast. I checked the system journal and found it littered with lines like this:
Nov 10 00:01:43 librem5 phoc[1181]: [types/output/cursor.c:223] Failed to get cursor display formats
Nov 10 00:01:43 librem5 phoc[1181]: [types/output/cursor.c:269] Failed to pick cursor format
Thereās some other concerning entries like this:
Nov 09 23:58:27 librem5 sm.puri.Phosh.desktop[4268]: DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory
Which sounds alarming. Iām not sure how to reproduce it, but it happens at least 3 to 5 times per day or at least thatās how much I notice it. I donāt know if this could even be related to the SD card.
Random general observation: Linux is like that. A lot of messages output that are meaningful only to the author and not actually indicative of a problem. So maybe justifiably alarming, maybe alarming but not justifiably so, maybe not alarming.
Fault isolation would be: temporarily reverse that change and just run /home
from the main (eMMC) drive and see whether you still get the reboots and/or the journal entries.
Well, anything to do with DRM is more alarming when it does work.
Direct Rendering Manager is alarming?
Yeah, I meant as in Digital Rights Management.
Okay, well itās been almost 24 hours since I unmounted the SD card from /home
and mounted it on /media
and I havenāt had a random reboot. Could there be some failure to read/write with the card that is critical causing a reboot?
Okay, so after a couple of days of testing, Iāve had random reboots in all these scenarios:
- The card mounted on
/home
. - The card mounted on
/media/purism/Media
. - The card not mounted, but luks unlocked on boot.
- The card not mounted nor unlocked on boot.
- The card removed from the phone altogether.
So, I think itās safe to say some other issue has been introduced by me or some update along the way. I havenāt been able to capture anything meaningful or that appears consistently in the system journal. Assuming data loss and reconfiguring/reinstalling stuff on the phone is not a factor for me, could it be helpful to reflash to stock and start from there or is that just wishful thinking? Without knowing what went wrong, I could just reintroduce the same issue. Any thoughts here?
For me, mounting individual folders e.g. Documents, Downloads, Pictures
, etc. on the SD card has worked without issues. I am a bit reluctant to mount the entire /home
folder with all the hidden folders and all.
Just reporting what works for me, but I realize this probably wonāt be much help for you,
Yes - but be sparing with reconfigure / reinstall - so that you can assess stability at various stages (and you are saving yourself some work if it all goes pear-shaped). In the extreme, you want to know whether there are stability issues with a completely unmodified reflashed phone.
Itās been a while since Iāve posted an update here because I hadnāt really found anything reproducable or something that looks directly responsible for the reboots. I reflashed the phone, took lots of notes on things I setup until the random reboots started happening about 24 hours after reflashing. I hadnāt introduced the SD card yet at this point.
I did notice a way to reproduce some of the reboots last night. I use a few web apps installed via Epiphanyās āInstall site as web applicationā function and one of them is Kodiās remote control web interface (I have Kodi installed on a PC connected to my TV). Iāve noticed that if I open the app and then lock the screen with the lock button, the phone will reboot immediately. I have some other apps installed the same way (Duolingo, Instagram, etc), but I didnāt get the same behaviour with those. I also noticed that if I opened the Kodi remote web interface in Epiphany itself, I get the reboot on lock there as well. This is NOT the case when I open the web interface in Firefox.
Iāve removed the app and am avoiding using this remote app to see if the reboots reduce. I have had one reboot on lock since, so Iām not convinced the problem is strictly related to this Kodi remote web app, but it could be hinting at something. One thing consistent with the reboots is that they occur when the screen is locked, usually shortly after it is locked.
I donāt really expect any help with this because it is very weird, but just wanted to get my experience on the record somewhere.
I know this post is slightly older but when I try to chown the newly created folder on my sda1 itās telling me the operation is not permitted. What am I missing?
UPDATE: In my excitement of receiving the phone I just jammed the sd card in and ran with it totally forgetting to format the card with an EXT4 filesystemā¦whoops.
Following up on the original post of this spin-off thread to add some details that I just discovered/tripped me up.
I finally put my 128GB card in my phone, formatted it with f2fs and set it up like the below:
But I found upon reboot that only /mnt/sda1
would be mounted, and not the bind mounts in my home dir.
Turns out that systemd tries to mount the filesystems in parallel, and so the main /mnt/sda1
is not mounted before the bind mounts are attempted and they silently fail.
So this is what I ended up doing, had to tell systemd about dependencies:
/dev/sda1 /mnt/sda1 auto auto,nofail 0 2
/mnt/sda1/Pictures /home/purism/Pictures none x-systemd-requires=/mnt/sda1,auto,bind,nofail 0 0
/mnt/sda1/Videos /home/purism/Videos none x-systemd-requires=/mnt/sda1,auto,bind,nofail 0 0
/mnt/sda1/Documents /home/purism/Documents none x-systemd-requires=/mnt/sda1,auto,bind,nofail 0 0
The addition, for every bind moutn, was x-systemd-requires=/mnt/sda1
After a rebooted I could confirm that all my bind mounts were present!
Thatās strange. On my L5, systemd auto-detects and honors those dependencies, as the generated unit file shows:
$ cat /etc/fstab
# [ā¦]
/dev/mapper/sdcard /media/sdcard ext4 defaults,noatime,nofail,x-systemd.wanted-by=local-fs.target 0 2
$ systemctl cat media-sdcard.mount
# /run/systemd/generator/media-sdcard.mount
# Automatically generated by systemd-fstab-generator
[Unit]
# [ā¦]
After=blockdev@dev-mapper-sdcard.target
[Mount]
Where=/media/sdcard
What=/dev/mapper/sdcard
Type=ext4
Options=defaults,noatime,nofail,x-systemd.wanted-by=local-fs.target
Note the After=blockdev@dev-mapper-sdcard.target
entry, which is part of the generated unit file.
/dev/sda1 /mnt/sda1 auto auto,nofail 0 2 /mnt/sda1/Pictures /home/purism/Pictures none x-stystemd-requires=/mnt/sda1,auto,bind,nofail 0 0 /mnt/sda1/Videos /home/purism/Videos none x-stystemd-requires=/mnt/sda1,auto,bind,nofail 0 0 /mnt/sda1/Documents /home/purism/Documents none x-stystemd-requires=/mnt/sda1,auto,bind,nofail 0 0
Thereās a typo in x-stystemd-requires
. Does your actual fstab have that typo? If so, chances are that directive has no effect.
Hmmmm placebo? Because before I added that, the bind mounts definitely did NOT mount. I did realize the typo just before nowā¦ So Iāll have to try again without and with those
The systemctl cat media-sdcard.mount
command returns nothing for meā¦
systemctl cat media-sdcard.mount
No files found for media-sdcard.mount.
/dev/sda1 /mnt/sda1 auto auto,nofail 0 2 /mnt/sda1/Pictures /home/purism/Pictures none x-stystemd-requires=/mnt/sda1,auto,bind,nofail 0 0 /mnt/sda1/Videos /home/purism/Videos none x-stystemd-requires=/mnt/sda1,auto,bind,nofail 0 0 /mnt/sda1/Documents /home/purism/Documents none x-stystemd-requires=/mnt/sda1,auto,bind,nofail 0 0
Thereās a typo in
x-stystemd-requires
. Does your actual fstab have that typo? If so, chances are that directive has no effect.
Typos corrected in my post
Tried to boot just now without the x-systemd-requires
option and it was fineā¦ Could be some race condition sometimes.
BTW Lilure, itās not clear from your example if you have the same type of setup I had:
- mount the sdcard somewhere
- bind-mount dirs from the sdcard into dirs on my disk
The issue supposedly happens because 1 and 2 happen in parallel. So even though it worked now (twice!), Iām not sure itās guaranteed to work every time. So Iāll try running without these options for a bit more and see what happensā¦
The
systemctl cat media-sdcard.mount
command returns nothing for meā¦
Thatās because your mount points are different than mine.
Try these commands:
systemctl cat home-purism-Pictures.mount
systemctl cat home-purism-Videos.mount
systemctl cat home-purism-Documents.mount
Can you post the contents of the [Unit]
section of one of those?
That should give us an idea whether or not systemd honors the constraint automatically, or needs some help in form of x-systemd-requires
.
BTW Lilure, itās not clear from your example if you have the same type of setup I had:
Youāre right. Your bind mount is different to my block device mount, because yours depends on a filesystem path to be present, while mine depends on a block device to be there.
Still, Iād have expected systemd to honor those constraints similarly.
Thanks, actually learning a few things here.
Try these commands
all 3 have the same config in the [Unit] section:
[Unit]
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
SourcePath=/etc/fstab
Youāre right. Your bind mount is different to my block device mount, because yours depends on a filesystem path to be present, while mine depends on a block device to be there.
Still, Iād have expected systemd to honor those constraints similarly
Right. So far after 4 reboots, I have had no issues without x-systemd-requires
. Not sure why a few reboots yesterday HAD the problem, which were only fixed after I added that (with a typo, so not really adding it) lol.