Mounting home folders to sd card

Just ran the suite against the card and looks like the card has the storage as advertised. It was very simple to use and did its job quickly.

The new card still seems to be functioning fine, though I have noticed the phone periodically rebooting when left on its own. I just leave it with some things running and come back to notice that the apps aren’t running and it needs to unlock the key ring again. I wouldn’t expect this to be related.

Another difference between the old and new card is that I formatted and setup the new one directly on the phone whereas I set up the old one on my laptop and then inserted it into the phone and setup automatic decryption and mounting myself. This is another note that I think is unrelated to the issue, but want to note it here for posterity and in case someone else is desperate for something to try to fix a similar issue.

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.

1 Like

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.

1 Like

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. :wink:

Direct Rendering Manager is alarming?

1 Like

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:

  1. The card mounted on /home.
  2. The card mounted on /media/purism/Media.
  3. The card not mounted, but luks unlocked on boot.
  4. The card not mounted nor unlocked on boot.
  5. 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?

1 Like

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,

2 Likes

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.

1 Like

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.

1 Like

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!

3 Likes

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.

Typos corrected in my post :slight_smile:

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:

  1. mount the sdcard somewhere
  2. 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…

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.