Dear Maintainer,

I made a default debian-edu bookworm install on single server with two
network interfaces.
Roles: main server, ltsp server, workstation
Desktop: Default/xfce
Network settings: installer defaults
Configured single 'student' user jdoe in addition to main/first user.

Proceeded to test LTSP network booting on multiple clients.

LTSP boot proceeds normally, but after login a mksquashfs process using
nearly all CPU capacity starts after about 1 minute.
Sections of the rootfs are mounted under /tmp/randomnamexx.
Client remains usable if slower, with 2G RAM usage.
A squashfs image is being created in /srv/ltsp/images/x86_64.img.tmp

This process eventually creates a 5.5GB file, /srv/ltsp/images/x86_64.img
and then terminates.
At this point, DNS name resolution stops working.
/etc/resolv.conf becomes empty (checked using 'watch /etc/resolv.conf)
Web browsing no longer works as a result, and the LDAP server can't be
accessed, so if I do a 'logout' without reboot, further login attempts fail.
The resolvconf.service is still running but can't be restarted due to
lack of privileged access.

I could not understand the purpose of creating the squashfs image on the
client.

So I decided to re-create the ltsp image on the server, with:

sudo debian-edu-ltsp-install --diskless_workstation yes

After the image is regenerated and client rebooted, the mysterious
mksquashfs process no longer runs after LTSP client logon, and DNS etc
function normally.

I am guessing there is an issue with the LTSP image creation in the original installer. Checked by reinstall from scratch, problem reappears.
As I  am new to the rather complex setup of debian-edu, I can't be more specific than that, sorry.

Chris Billington

I can see the same behavior with user "Test Student" on Debian Edu
12.8 and on Debian Edu 12.9.
Even after the second reboot, a creation time (needed to create an
image) of /srv/ltsp/images/x86_64.img doesn't change.
After creating the image, a memory on a terminal is cleaned up.

Not exactly. The file /etc/resolv.conf still exists and browser can
open sites w/o any issues:
google.com, ipleak.net, tjener.no (parked), ftp.debian.org

As I see, it works without problems after logout.

Parallel mksquashfs: Using 4 processors
Creating 4.0 filesystem on /srv/ltsp/images/x86_64.img.tmp, block size 131072.
..
Generated ltsp.img:
-rw-r--r-- 1 root root 168960 Feb 15 02:36 /srv/tftp/ltsp/ltsp.img
..
Installed /usr/share/ltsp/server/nfs/ltsp-nfs.exports in
/etc/exports.d/ltsp-nfs.exports
..
Installed /usr/share/ltsp/server/ipxe/ltsp.ipxe in /srv/tftp/ltsp/ltsp.ipxe
..
Modifying /srv/tftp/ltsp/ltsp.ipxe

After rebooting the diskless terminal, it runs without (!) generating
of mksquashfs (at least in first 10 minutes).

I think it would be good to initiate such image assembling during
adding LTSP role (or right after it) in tjener's installation.

Maximal used memory for "unused" diskless station in this case was
553M (instead of 2000+ with creating the image).