On 28/09/2026 18:22, Mike Gabriel wrote:
When installing with the 13.7.0 BD ISO image (in offline mode, i.e. no network available) and adding `desktop=gnome` to the kernel command line, the installation proceeds to the end, but /dev/mapper/vg_system-root is completely full (all 16GB is used).See openQA: https://openqa.debian.net/tests/580778 The openQA environment provides a 30GiB empty HD during the installation. A 'regular', i.e. non-DebianEdu GNOME installation requires 4.7GB in `/Is debian-edu-ltsp-install executed by any chance during the Standalone installation?
No, this is a pure standalone workstation, no LTSP scripts were running.
Is it possible for you to identify where the storage consumption in / takes place? Please note, that Debian Edu by default installs many extra edu software packages. Maybe 30G are too little storage for an hdd device for Debian Edu.
I've locally run the test again, with a HD of 40GB instead of 30. The automatic partitioning still assigns 16GB to vg_system-root -> that is due to /usr/lib/partman/recipies-amd64-efi/98standalone, which will assign all additional space to the home partition. The other desktops (even KDE) have more than 1GB free in vg_system-root. Here are the numbers of my local openQA instance (using the unmodified partman recipe): ``` root@openqa6:/var/lib/openqa/testresults/00001# grep "vg_system-root" 00001???-debian-edu-trixie-BD-iso-x86_64-Buildtrixie_13_7_0-edu-offline-standalone-*/ulogs/df.txt 00001757-debian-edu-trixie-BD-iso-x86_64-Buildtrixie_13_7_0-edu-offline-standalone-gnome@uefi_secure_bigmem/ulogs/df.txt:/dev/mapper/vg_system-root 16G 16G 0 100% / 00001765-debian-edu-trixie-BD-iso-x86_64-Buildtrixie_13_7_0-edu-offline-standalone-cinnamon@uefi_secure_opengl/ulogs/df.txt:/dev/mapper/vg_system-root 16G 14G 1.2G 92% / 00001766-debian-edu-trixie-BD-iso-x86_64-Buildtrixie_13_7_0-edu-offline-standalone-lxqt@uefi_secure/ulogs/df.txt:/dev/mapper/vg_system-root 16G 14G 1.3G 92% / 00001767-debian-edu-trixie-BD-iso-x86_64-Buildtrixie_13_7_0-edu-offline-standalone-mate@uefi_secure/ulogs/df.txt:/dev/mapper/vg_system-root 16G 14G 1.2G 93% / 00001768-debian-edu-trixie-BD-iso-x86_64-Buildtrixie_13_7_0-edu-offline-standalone-lxde@uefi_secure/ulogs/df.txt:/dev/mapper/vg_system-root 16G 14G 1.3G 92% / 00001769-debian-edu-trixie-BD-iso-x86_64-Buildtrixie_13_7_0-edu-offline-standalone-xfce@uefi_secure/ulogs/df.txt:/dev/mapper/vg_system-root 16G 13G 1.6G 90% / 00001777-debian-edu-trixie-BD-iso-x86_64-Buildtrixie_13_7_0-edu-offline-standalone-kde@uefi_secure_bigmem/ulogs/df.txt:/dev/mapper/vg_system-root 16G 14G 526M 97% / ``` In a manual installation, using a 70GB HD and a local modification of /usr/lib/partman/recipies-amd64-efi/98standalone to add 10GB to vg_system-root: ``` /dev/mapper/vg_system-root 25G 19G 4.8G 80% / ``` When I compared the output of `dpkg-query -l` of the broken GNOME installation and the working GNOME installation, it shows that all dictionaries and language packs could be installed properly (which were partly installed with the unmodified recipe). Looking at the XFCE and KDE installations, only 'task-english' is installed, whereas on GNOME every language gets installed. So GNOME behaves differently. Looking further, the package 'gnome-core' has a recommends on 'locales-all', which will enable the installation of every language pack in the `/usr/share/debian-edu-config/tools/improve-desktop-l10n` script (which runs `locale -a` to find out which languages need to be available) So it boils down to determining the desired situation: * A) should all languages have been available for every desktop (i.e. install locales-all) * B) should in the case 'locales-all' is installed the 'improve-desktop-l10n' script use only the currently active language (from /etc/locale.conf) * C) should in the case 'locales-all' is installed the 'improve-desktop-l10n' script use only the locales from `dpkg-reconfigure -p low locales` (i.e. /etc/locale.gen) My preference would be: C, B, A With kind regards, Roland
OpenPGP_signature.asc
Description: OpenPGP digital signature
