Processed: Bug#1030850 marked as pending in tzsetup
Processing control commands: > tag -1 pending Bug #1030850 [src:tzsetup] Please stop creating /etc/timezone Added tag(s) pending. -- 1030850: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030850 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#969450: marked as done (partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition)
Your message dated Sat, 23 Nov 2024 12:03:14 +0100
with message-id <20241123120314.5bc9e4c1323842aea360d...@mailbox.org>
and subject line Re: #969450 partman-auto: on a machine with 384 Gb Ram and 512
Gb SSD, creates 400 Gb swap partition
has caused the Debian Bug report #969450,
regarding partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates
400 Gb swap partition
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
969450: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969450
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: partman-auto
Severity: important
Tags: d-i
Dear Maintainer,
I was a bit surprised when I did a quick Debian Stable install on my new
workstation (384 Gb RAM, 512 Gb ssd) and ended up with just 80 Gb usable
diskspace, thanks to a 400 Gb swap partition that the Debian installer created.
I think a warning/question when more than 25% of the disk is used as swap-space
would be in order. I would think that computer-owners who install large amounts
of memory carefully install enough memory to not swap excessively.
After re-installing, this seems a lot saner:
totalusedfree shared buff/cache available
Mem: 377Gi 842Mi 219Gi 9.0Mi 157Gi 374Gi
Swap: 44Gi 0B44Gi
Debian Release: 10.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-10-amd64 (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to
en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
--- End Message ---
--- Begin Message ---
> I was a bit surprised when I did a quick Debian Stable install on my new
> workstation (384 Gb RAM, 512 Gb ssd) and ended up with just 80 Gb usable
> diskspace, thanks to a 400 Gb swap partition that the Debian installer
> created. I think a warning/question when more than 25% of the disk is used as
> swap-space would be in order. I would think that computer-owners who install
> large amounts of memory carefully install enough memory to not swap
> excessively.
For such machines with that much RAM (which is a typical server setup) we have
just introduced a dedicated recipe ("server") for auto-partitioning, which
limits the swapsize to 1G.
That should do it here.
So closing this bug
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076--- End Message ---
Bug#1088104: partman-auto-raid: Recipe delimiter parsing shortcoming restricts mdadm $EXTRA_ARGS
Package: partman-auto-raid Version: 51 Severity: normal Tags: d-i patch Dear Maintainer, I was trying to get a preseeded Debian installation to create a md software RAID array with superblock version 1.0. To do that, one has to issue `mdadm --create ... --metadata=1.0 ...` at array creation time. partman-auto-raid's auto-raidcfg/create_raid() optionally consumes EXTRA_ARGS from a pre-seeded partman-auto-raid/recipe (the 8th argument in a single recipe record) key, which is documented in partman-auto-raid-recipe.txt[0]. By massaging the recipe correctly, it should be possible to supply `--metadata=1.0` on mdadm's resulting argv. HOWEVER, since recipe records are currently separated from each other by means of any single . character (ASCII 0x2e, a dot), it is effectively impossible to pass this argument to mdadm: There is a simple `while` loop near the end of auto-raidcfg that will try to split the recipe string as returned by confmodule's get_db() at each occurence of ., which breaks when the EXTRA_ARG intended for mdadm's argv contains that particular character. If the recipe record separator were to be changed to a single ASCII dot surrounded by any amount of whitespace, which all the preseed examples I could find in circulation on the web as well as in official Debian documentation already follow, having any mdadm metadata specification that requires a . in its optarg would become possible. I created a merge request on salsa with two patches that implement the new, fixed split logic available at [1], and hope you will find this useful. Thanks for all the hard and fruitful work you all are doing - on Debian in general, and d-i in particular! :) [0]: https://sources.debian.org/src/debian-installer/20240914/doc/devel/partman-auto-raid-recipe.txt/ [1]: https://salsa.debian.org/installer-team/partman-auto-raid/-/merge_requests/3 -- 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-27-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#969450: #969450 partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition
On 23/11/2024 at 12:03, Holger Wansing wrote:
I was a bit surprised when I did a quick Debian Stable install on my new
workstation (384 Gb RAM, 512 Gb ssd) and ended up with just 80 Gb usable
diskspace, thanks to a 400 Gb swap partition that the Debian installer
created. I think a warning/question when more than 25% of the disk is used as
swap-space would be in order. I would think that computer-owners who install
large amounts of memory carefully install enough memory to not swap excessively.
For such machines with that much RAM (which is a typical server setup) we have
just introduced a dedicated recipe ("server") for auto-partitioning, which
limits the swapsize to 1G.
That should do it here.
The "server" recipe also creates a big /srv partition and no separate
/home, so it may not be suited for a typical workstation use case.
Actually this bug was already fixed in 2020 by the introduction of
partman-auto/cap-ram limiting the swap size to 1GB by default. But this
limitation affected hibernation and made little sense on the vast
majority of systems with much more disk space than RAM. With the recent
changes, the swap size is now limited to 100% RAM size and ~5% disk size
except in the "server" recipe (servers usually do not need hibernation).
On the above workstation the swap size would now be limited to ~25GB (5%
of 512GB disk size) by the standard recipes.
Bug#969450: #969450 partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition
Hi,
Pascal Hambourg wrote (Sat, 23 Nov 2024 13:55:45
+0100):
> On 23/11/2024 at 12:03, Holger Wansing wrote:
> >
> >> I was a bit surprised when I did a quick Debian Stable install on my new
> >> workstation (384 Gb RAM, 512 Gb ssd) and ended up with just 80 Gb usable
> >> diskspace, thanks to a 400 Gb swap partition that the Debian installer
> >> created. I think a warning/question when more than 25% of the disk is used
> >> as
> >> swap-space would be in order. I would think that computer-owners who
> >> install
> >> large amounts of memory carefully install enough memory to not swap
> >> excessively.
> >
> > For such machines with that much RAM (which is a typical server setup) we
> > have
> > just introduced a dedicated recipe ("server") for auto-partitioning, which
> > limits the swapsize to 1G.
> > That should do it here.
>
> The "server" recipe also creates a big /srv partition and no separate
> /home, so it may not be suited for a typical workstation use case.
>
> Actually this bug was already fixed in 2020 by the introduction of
> partman-auto/cap-ram limiting the swap size to 1GB by default. But this
> limitation affected hibernation and made little sense on the vast
> majority of systems with much more disk space than RAM. With the recent
> changes, the swap size is now limited to 100% RAM size and ~5% disk size
> except in the "server" recipe (servers usually do not need hibernation).
>
> On the above workstation the swap size would now be limited to ~25GB (5%
> of 512GB disk size) by the standard recipes.
You are of course right, that the original report is somewhat different,
but the main issue (a heavy swap partition eats up most disk space) is
now solved with the server recipe, so I think it's ok to close this report.
Holger
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#969450: #969450 partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition
On 23/11/2024 at 14:03, Holger Wansing wrote: but the main issue (a heavy swap partition eats up most disk space) is now solved with the server recipe, so I think it's ok to close this report. This bug report could even have been closed in 2020 after the introduction of partman-auto/cap-ram. I just wanted to point out that the issue is solved with all built-in recipes, not only the server one.
Re: Speech mode of Debian installer
Hello Samuel, lists, On 19/11/2024 14:17, Samuel Thibault wrote: Cc-ing debian-accessibility at least for information. Roland Clobus, le mar. 19 nov. 2024 12:31:15 +0100, a ecrit: The most striking recording is at step 2:6:1 https://openqa.debian.net/tests/325775/file/bootwalk_2:6:1-captured.wav which is about 5 minutes long and lists 78 language options. Yes. One can use arrow keys instead to quickly go over the list. ... (I've noticed e.g. 'Chinese letter - Chinese letter' being spoken at 1:00) -> i.e. should the list of languages be reduced for this specific variant of the installer, because the speech module cannot read it? Ideally that could be implemented in localechooser, by looking at the list of voices in espeak to filter the list. The next screen typically works fine, so there appears no need for removing some languages from this list. However, could localechooser use a pre-rendered pronunciation for the language-selection question (activated only when espeak is active)? E.g.: # Prerendering of the language file: echo "Ελληνικά" | espeak-ng -x -v el # Then the line would become "28: Greek - [[,elinik'a]]" * Could a different font be used to show the UTF-8 characters, similar to the text installer? For the screen reader to work, we have to use the linux console, not an fbterm. So we are limited to the linux console capability, and thus cannot display everything at the same time. In practice this is not a problem because the speech is correct, and the font is switched once a language is selected. When I posted my first mail, I stopped looking after the first screen. For Greek (28) the spelling of each letter becomes fluent greek (instead of spelling each single letter) in the next screen and the font is updated as well. For Vietnamese (77) and Arabic (4) the next screens also look and sound good to me (I don't speak these languages). * The spoken text 'Prompt. For help' does not speak the most important bit, i.e. that the question mark will show the help text This is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690343 forwarded upstream https://github.com/espeak-ng/espeak-ng/issues/150 With no upstream activity since 2016, should the text in the installer be changed? E.g. from "Prompt: '?' for help" to "Prompt: enter a question mark for help" * Nowadays newer TTS voices exist that speak a more natural language (e.g. piper https://rhasspy.github.io/piper-samples/), could this be used instead? The problem is the size. espeak-ng supports a very wide range of languages with a quite small disk footprint. Piper etc. (we had mbrola already for a long time) take a *lot* of space. We have packages ready for including e.g. mbrola voices, but we cannot really include them on the default images, it's rather for specialized images. I noticed that mbrola is in contrib, and the voices in non-free/sound. The license conditions are severely restrictive, in the sense that the voices are to be used only by mbrola, which cannot be guaranteed in a generic installation of Debian. Piper has a MIT license and the voices appear to be less restrictive, but I didn't look at it too deeply. Regarding size: perhaps the netinst image cannot handle the growth, but e.g. a GNOME live image (already at 4GB) can have a bit more. Or there could even be an a11y live image (or are there already Debian derivatives that handle this?) With kind regards, Roland OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#969450: #969450 partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition
Hi, Pascal Hambourg wrote (Sat, 23 Nov 2024 15:05:15 +0100): > On 23/11/2024 at 14:32, Holger Wansing wrote: > > Pascal Hambourg wrote (Sat, 23 Nov 2024 14:17:31 > > +0100): > >> On 23/11/2024 at 14:03, Holger Wansing wrote: > >>> > >>> but the main issue (a heavy swap partition eats up most disk space) is > >>> now solved with the server recipe, so I think it's ok to close this > >>> report. > >> > >> This bug report could even have been closed in 2020 after the > >> introduction of partman-auto/cap-ram. I just wanted to point out that > >> the issue is solved with all built-in recipes, not only the server one. > > > > Things have changed here recently: > > > > from 2020 until September of this year you were right: it worked with any > > recipe (because of cap-ram -> 1G). > > > > However, in October we pushed in an overhaul of recipes, to improve > > calculation of partition sizes, and in-line with this, the cap-ram > > functionality was disabled by default; we needed this, to be able to get > > swap sizes bigger than 1G in auto-partitioning (and with this, to make > > hibernation work again on many machines). > > > > So, *now* it's only working with the server recipe on such machines. > > I beg to disagree. The new PRIORITY values defined in other recipes > (atomic, home, multi, small_disk) were designed to limit the swap size > to approximately 5% of disk size. So even with cap-ram disabled, the > swap cannot eat most disk space with any recipe. Ah, indeed I forgot that part. I should have known, that you understand that all better than I do ;-)) Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#969450: #969450 partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition
On 23/11/2024 at 14:32, Holger Wansing wrote: Pascal Hambourg wrote (Sat, 23 Nov 2024 14:17:31 +0100): On 23/11/2024 at 14:03, Holger Wansing wrote: but the main issue (a heavy swap partition eats up most disk space) is now solved with the server recipe, so I think it's ok to close this report. This bug report could even have been closed in 2020 after the introduction of partman-auto/cap-ram. I just wanted to point out that the issue is solved with all built-in recipes, not only the server one. Things have changed here recently: from 2020 until September of this year you were right: it worked with any recipe (because of cap-ram -> 1G). However, in October we pushed in an overhaul of recipes, to improve calculation of partition sizes, and in-line with this, the cap-ram functionality was disabled by default; we needed this, to be able to get swap sizes bigger than 1G in auto-partitioning (and with this, to make hibernation work again on many machines). So, *now* it's only working with the server recipe on such machines. I beg to disagree. The new PRIORITY values defined in other recipes (atomic, home, multi, small_disk) were designed to limit the swap size to approximately 5% of disk size. So even with cap-ram disabled, the swap cannot eat most disk space with any recipe.
Bug#969450: #969450 partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition
On 23/11/2024 at 15:05, Pascal Hambourg wrote: The new PRIORITY values defined in other recipes Correction: the new MINIMUM and PRIORITY values. (atomic, home, multi, small_disk) were designed to limit the swap size to approximately 5% of disk size. And the new MAXIMUM values limit the swap size to 100% of RAM size.
Bug#969450: #969450 partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition
On 23/11/2024 at 15:33, Holger Wansing wrote: Ah, indeed I forgot that part. I should have known, that you understand that all better than I do ;-)) No worries, even I tend to forgot about my own work sometimes. But I would not fix a regression with another regression knowingly. By the way, you are doing a great job digging up and closing old bugs now fixed.
Bug#1030850: #1030850Please stop creating /etc/timezone
Hi all, from the originally 20 bugreports there are 12 still open more than 16 months later. Do we want to wait any longer? And if so, should severity be raised? Holger -- Sent from /e/ OS on Fairphone3
Bug#1030850: #1030850Please stop creating /etc/timezone
On Sat, 23 Nov 2024 16:38:35 +0100 Holger Wansing wrote: > Hi all, > > from the originally 20 bugreports there are 12 still open more than 16 > months later. > > Do we want to wait any longer? > And if so, should severity be raised? Yeah, we have waited for the whole development cycle of Trixie, it should be enough. I'll raise severity and ping the MR again, thanks for the reminder.
Processed: Re: transition from /etc/timezone to /etc/localtime
Processing control commands: > severity -1 serious Bug #1030850 [src:tzsetup] Please stop creating /etc/timezone Severity set to 'serious' from 'normal' -- 1030850: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030850 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1030850: transition from /etc/timezone to /etc/localtime
Control: severity -1 serious Dear Maintainers(s), These bugs have been open since the release of Bookworm, and now the development cycle for Trixie is approaching its end. Bumping the severity of these bugs hence, as tzdata no longer creates the legacy file.
Processed: Re: #985463 partman-auto: Use ext4 filesystem for /boot if boot loader supports it
Processing control commands: > tags -1 + pending Bug #985463 [partman-auto] partman-auto: Use ext4 filesystem for /boot if boot loader supports it Added tag(s) pending. -- 985463: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985463 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#985463: #985463 partman-auto: Use ext4 filesystem for /boot if boot loader supports it
Control: tags -1 + pending MR24 merged, so mark this bug as pending -- Sent from /e/ OS on Fairphone3
Re: Speech mode of Debian installer
Roland Clobus, le sam. 23 nov. 2024 15:34:49 +0100, a ecrit: > On 19/11/2024 14:17, Samuel Thibault wrote: > > Cc-ing debian-accessibility at least for information. > > Roland Clobus, le mar. 19 nov. 2024 12:31:15 +0100, a ecrit: > > > (I've noticed e.g. 'Chinese letter - Chinese letter' being spoken > > > at 1:00) -> i.e. should the list of languages be reduced for this > > > specific variant of the installer, because the speech module cannot > > > read it? > > > > Ideally that could be implemented in localechooser, by looking at the > > list of voices in espeak to filter the list. > > The next screen typically works fine, so there appears no need for removing > some languages from this list. > > However, could localechooser use a pre-rendered pronunciation for the > language-selection question (activated only when espeak is active)? > E.g.: > # Prerendering of the language file: > echo "Ελληνικά" | espeak-ng -x -v el > # Then the line would become "28: Greek - [[,elinik'a]]" That'd be complex: espeakup just gets the whole text, it doesn't know what piece is in which language. > > > * The spoken text 'Prompt. For help' does not speak the most important > > > bit, > > > i.e. that the question mark will show the help text > > > > This is > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690343 > > > > forwarded upstream > > > > https://github.com/espeak-ng/espeak-ng/issues/150 > > With no upstream activity since 2016, should the text in the installer be > changed? That's a possibility, but the bug really wants to be fixed by somebody at some point, because such prompts do happen here and there. > Piper has a MIT license and the voices appear to be less restrictive, but I > didn't look at it too deeply. > > Regarding size: perhaps the netinst image cannot handle the growth, but e.g. > a GNOME live image (already at 4GB) can have a bit more. But it's not just "a bit". Look at the size per language of piper. We cannot just add a GB of voices for the various languages that d-i supports. > Or there could even be an a11y live image (or are there already Debian > derivatives that handle this?) Some derivatives do this, yes. Samuel
Bug#1030850: #1030850Please stop creating /etc/timezone
Am 23.11.24 um 16:38 schrieb Holger Wansing: Hi all, from the originally 20 bugreports there are 12 still open more than 16 months later. Do we want to wait any longer? And if so, should severity be raised? Please also usertag those bug reports. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1088087: debootstrap --exclude=systemd-sysv doesn't work
On Fri, Nov 22, 2024 at 06:14:13PM -0600, Ava wrote:
> debootstrap --exclude=systemd-sysv doesn't work. The option is completely
> ignored.
Could you please describe your goal? If you want to exclude the init
system, using "--variant=minbase" should help.
Bastian
--
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
stardate unknown.
Bug#969450: #969450 partman-auto: on a machine with 384 Gb Ram and 512 Gb SSD, creates 400 Gb swap partition
Hi, Pascal Hambourg wrote (Sat, 23 Nov 2024 14:17:31 +0100): > On 23/11/2024 at 14:03, Holger Wansing wrote: > > > > but the main issue (a heavy swap partition eats up most disk space) is > > now solved with the server recipe, so I think it's ok to close this report. > > This bug report could even have been closed in 2020 after the > introduction of partman-auto/cap-ram. I just wanted to point out that > the issue is solved with all built-in recipes, not only the server one. Things have changed here recently: from 2020 until September of this year you were right: it worked with any recipe (because of cap-ram -> 1G). However, in October we pushed in an overhaul of recipes, to improve calculation of partition sizes, and in-line with this, the cap-ram functionality was disabled by default; we needed this, to be able to get swap sizes bigger than 1G in auto-partitioning (and with this, to make hibernation work again on many machines). So, *now* it's only working with the server recipe on such machines. Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
