How to use lxroot with squashfs?

[ghost]

I want to run MX Linux with lxroot. I grabbed the squashfs linuxfs from the ISO image. What I need to do next? Please tell me. Thank you.

[parke]

Thank you for contacting me.

What is the name of the ISO file? What is the name of the squashfs file?

Which Linux system are you running? MX Linux? Or something else?

[ghost]

https://sourceforge.net/projects/mx-linux/files/Final/Xfce/MX-23.6_ahs_x64.iso/download

The name of the squashfs file is linuxfs.

[parke]

I have an older ISO of MX Linux already on my system: MX-23.3_ahs_x64.iso

I extracted the antiX/linuxfs file and mounted it (read-only).

I was able to Lxroot into it.

If you mount it with OverlayFS (at /mnt/overlay, for example) to make it writable, I think you will be able to add and remove packages as follows:

$ lxroot -nw /mnt/overlay

Then, inside of Lxroot, run apt-get as follows:

$ fakeroot apt-get update
$ fakeroot apt-get install package

(You can probably use apt instead of apt-get, if you prefer apt.)

Alternatively, you should be able to tell lxroot to run fakeroot all in one single command, as follows:

$ lxroot -nw /mnt/overlay -- fakeroot apt-get update
$ lxroot -nw /mnt/overlay -- fakeroot apt-get install package

Please let me know if you have any additional questions.

[parke]

To answer your question, you probably do something like:

$ unsquashfs filename.squashfs

Followed by:

$ lxroot squashfs-root

You can rename the squashfs-root directory to some other name, if you like.

Or, alternatively, you could mount the squashfs file without extracting it, with something like:

$ sudo mkdir /mnt/foo
$ sudo mount filename.squashfs /mnt/foo
$ lxroot /mnt/foo

A disadvantage of the above is that /mnt/foo will be read-only, which will prevent you from making any changes inside of /mnt/foo.

Please let me know if any of the above work, or if you have any further questions.

If you tell me the name of the ISO image and squashfs file you are trying to use, I can probably provide more detailed instructions.

[ghost]

I prefer to not extract the squashfs file. Can I use OverlayFS to make it writable?

[parke]

I prefer to not extract the squashfs file. Can I use OverlayFS to make it writable?

Yes, if you manually create an OverlayFS filesystem, you should be able to Lxroot into it.

(Aside: A non-root process (i.e. Lxroot) cannot mount a SquashFS filesystem. That requires root. However, a non-root process can (via an unprivileged namespace) create and mount an OverlayFS filesystem. At some point in the past, I actually added OverlayFS support to Lxroot, and it did work. However, I found the feature (at least as I implemented it at that time) mentally cumbersome to use and manage. I ended up not using the feature, so eventually I removed the OverlayFS code from Lxroot. I never published that version of Lxroot, so that code is not in GitHub. I mention all this just FYI, just so you know what is possible with Linux, even if Lxroot does not support it.)

[parke]

I just remembered that you will probably need more than just OverlayFS.

The reason being: In order to modify a file or directory inside Lxroot, the (non-root) user must have permission to modify the file outside of Lxroot. And the files and directories in the linuxfs file will have the wrong ownership and permissions.

What I have done in the past is extract the SquashFS filesystem, chown all the files in it, and then build a new SquashFS filesystem from the modified files.

I have a 48 GiB tmpfs ram disk that I use for tasks like this. (Although 8 or 16 GiB would probably be enough in most cases.)

[ghost]

I'm trying to run Plop Linux with lxroot. It's a normal compressed rootfs:

https://download.plop.at/ploplinux/25.2/desktop/ploplinux-desktop-25.2-x86_64.tar.gz

I don't want to use sudo so I choose to extract the archive with my unprivileged user account. There are some errors:

tar: ploplinux-desktop-25.2-x86_64/var/named/chroot/dev/random: Cannot mknod: Operation not permitted
tar: ploplinux-desktop-25.2-x86_64/var/named/chroot/dev/zero: Cannot mknod: Operation not permitted
tar: ploplinux-desktop-25.2-x86_64/var/named/chroot/dev/null: Cannot mknod: Operation not permitted
tar: ploplinux-desktop-25.2-x86_64/var/named/chroot/dev/urandom: Cannot mknod: Operation not permitted
tar: Exiting with failure status due to previous errors

But lxroot into ploplinux-desktop-25.2-x86_64 is fine. After that, I realized that I can't write anything:

fatal: could not create work tree dir 'lxroot': Read-only file system

(I tried to clone the lxroot repository with git)

I found that /tmp is writable, but now I'm facing DNS issue:

fatal: unable to access 'https://github.com/parke/lxroot/': Could not resolve host: github.com

[parke]

Hi, @chatchoi,

Thanks for the question.

I've copied your question to a new thread, and provided some answers.

[parke]

Recently, I was using QEMU to run short duration tests of dnsmasq. I ran the tests on various versions of dnsmasq from the past several years. My test environments included the current version of Arch Linux and current and past versions of Ubuntu. My goal was to determine when (and on what distros) a particular regression appeared in dnsmasq.

While running these tests in QEMU, I realized it would be much nicer to be able to run the tests in Lxroot instead of in QEMU. Using Lxroot would use mean significantly less disk usage, much less CPU usage, much less RAM usage, near instantaneous "boot times", and easier file sharing between the different environments.

I also realized that it would be very convenient to use SquashFS and OverlayFS to perform these short duration tests. Additionally, there are many other short duration tests (i.e. not just my current testing of dnsmasq) that could be conveniently performed if Lxroot supported automatic creation of an OverlayFS filesystem.

I believe I now see a clear and compelling use case for (re)adding OverlayFS support to Lxroot. I may also see a way to avoid the conceptually cumbersome usability that was present in my previous implementation of OverlayFS support. (I now see that the previous implementation had too many features. It was, in a way, too powerful, and therefore less usable.)