Bug#1056018: partman-base: parted_devices hangs with process in D state during Debian installer Detect Disks step
Source: partman-base Version: 226 Severity: critical Tags: d-i Justification: breaks the whole system Dear Maintainer, * What led up to the situation? Updating from Debian 8 to Debian 12 from an USB stick. * What exactly did you do (or not do) that was effective (or ineffective)? Ineffective: Tried disconnecting external disks & USB storage HUB, and switching SATA setting from AHCI to IDE in BIOS. Also tried expert mode & text mode. * What was the outcome of this action? Debian Installer is stuck on Detect Disks. Switching to a console and running ps shows that a parted_devices process is in D state. * What outcome did you expect instead? parted_devices should only take a few seconds and Debian Installer should continue to the partionning step. Note: I'm reporting from another computer. System information from the old OS is irrelevant anyway as the computer is booted on the Debian 12 installer image when the problem occurs. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-12-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1042544: systemd: Can't increase user default file descriptors (nofile) soft limit above 1024 for gnome-terminal.
Hello, Thanks for the warning, Luca Boccassi. I'm aware of the implications of increasing the soft limit. I read many discussions on the subject on the web while looking for a solution, and understand the rationale of the Debian decision to set the soft limit to 1024 and the hard limit to 1048576 in recent releases. I agree to that and expect that modern, non-select()-using applications set the soft limit themselves to deliberately indicate that they want more file descriptors. I filed a bug for Wine as it didn't work as expected in this case. (https://bugs.winehq.org/show_bug.cgi?id=55363) That should not be discussed here, though. What I report is that after changing every possible settings I could find documentation for on the web, the soft limit stays unchanged in the initial session of a freshly opened gnome-terminal in the graphical DE. The higher soft limit gets properly set everywhere else as expected, including opening a new session in the gnome-terminal with sudo to the same user, or temporarily setting the value with 'ulimit -n '. This means to me that something overrides the global settings from systemd & pam_limits.so in gnome-terminal initialization or a parent process, or that it takes a path that simply doesn't load the systemd/pam_limits settings. I would like to know if I simply missed something in my attempt to configure a higher soft limit, or if the issue lies within systemd or another component/application. How can I check that? Regards. P.S. Quoting the original message seems broken for me when using the 'reply' link on the Debian Bug page. The generated quote was limited to a few lines of my own quoted message in your reply. I removed it as it was meaningless. -- Olivier F. R. Dierick o.dier...@piezo-forte.be
