Chromium fails to launch on SquashFS-based rootfs

Technical Support
, ,
1

Hello Toradex Team,
I’m using an i.MX8MP module with the Mallow carrier board, and building a custom image using Yocto Scarthgap.
I have built a custom Yocto image with ext4 rootfs and included Chromium browser following the official Toradex documentation. The image was successfully built, and Chromium launched correctly on the board using:
chromium --no-sandbox --disable-gpu --ozone-platform=x11

After that, I built the image again using the same steps, but this time with SquashFS and OverlayFS support enabled. I added the following lines in local.conf:
IMAGE_FSTYPES += “squashfs”
IMAGE_INSTALL:append = " squashfs-tools"
DISTRO_FEATURES:append = " overlayfs"

The image built successfully and booted properly on the board. However, now when I try to launch Chromium, it fails with the following error:
chromium --no-sandbox --disable-gpu --ozone-platform=x11
[1485:1485:0529/190526.087650:ERROR:filesystem_posix.cc(63)] mkdir : No such file or directory (2)
chrome_crashpad_handler: --database is required
Try ‘chrome_crashpad_handler --help’ for more information.
[1485:1485:0529/190526.088166:ERROR:chrome_main_delegate.cc(1631)] NOTREACHED hit.
[1485:1485:0529/190531.200834:FATAL:path_service.cc(265)] Failed to get the path for 1001
Trace/breakpoint trap (core dumped)

Chromium version in both builds is:
chromium --version
Chromium 132.0.6834.83 stable

Could anyone please guide me on how to make Chromium work with SquashFS rootfs?

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:

Hello,

Thank you for your detailed description. When running Chromium on a SquashFS root filesystem, you’ll encounter issues because SquashFS is read-only. Chromium requires several working directories to be writable (e.g., for cache, user profiles, crashpad).

Here’s how to solve the issue:

1. Ensure you have a writable partition for OverlayFS

  • Typically, you will have an extra partition (e.g., /dev/mmcblk0p3) mounted somewhere like /media/data to hold OverlayFS data.
  • Add the following to your /etc/fstab to auto-mount at boot:
    /dev/mmcblk0p3 /media/data auto defaults,sync,noauto 0 0
    (Reference)

2. Set OverlayFS mount points for writable directories

  • Set up the overlay for critical locations, such as /home/root. Example (run as root):
    mkdir -p /media/data/home/root/{upper,work}
mount -t overlay overlay -o lowerdir=/home/root,upperdir=/media/data/home/root/upper,workdir=/media/data/home/root/work /home/root
    Make sure /media/data/home/root/upper and /media/data/home/root/work are empty and on a writable partition.
    (Reference)

3. Review your local.conf for SquashFS and OverlayFS support

IMAGE_FSTYPES_append = " squashfs"

(using _append is generally safer than +=)
(Reference)

4. Chromium launch command

  • to minimize permission issues, launch Chromium with:
    chromium --no-sandbox --in-process-gpu
    (Reference)

Summary of Common Pitfall

  • Chromium fails because its required directories (such as $HOME/.cache or the crashpad database) are not writable—addressed by properly mounting OverlayFS over these directories.

Optional: Automate Overlay Mount

  • Add your overlay mount commands to a startup script or a systemd unit so that the overlay is established on every boot before any service (like a kiosk or UI session) launches Chromium.

Let me know if you would like sample scripts/systemd units or further details!

Best regards,
Toradex AI Assistant.