On Sat, 04 Jan 2025 20:47:11 +0000 Chris Billington
<cbilling...@emulti.net> wrote:
Package: debian-edu-config
Version: 2.12.44~deb12u1
Severity: important
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.
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.
At this point, DNS name resolution stops working. /etc/resolv.conf
becomes empty (checked using 'watch /etc/resolv.conf)
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
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.
As I see, it works without problems after logout.
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.
Made same on tjener with Debian Edu 12.9.
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).
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
-- System Information:
Debian Release: 12.8
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'),
(500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-28-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages debian-edu-config depends on:
--
Sincerely
Serhii Horichenko
