Bug#1092123: debian-edu-config: DNS stops working on LTSP clients after unusual mksquashfs process terminates

On Sat, 04 Jan 2025 20:47:11 +0000 Chris Billington  
<[email protected]> 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