Using the "separate home+var+tmp" recipe under UEFI variant on a 10G disk results in an error(...)
"Unable to satisfy all constraints on the partition"
"Failed to partition the selected disk. This probably happened because there are too many (primary) partitions in the partition table."
In the partitioning overview (screenshot 3) the /home partition is
missing, so this is the one which raises the error apparently.
Do we need to adjust the minimum disk size for this recipe maybe, or similar?
Summary: existing reusable partitions (efi and swap) minimum sizes may wrongly be ignored when calculating the required minimum disk size even(...)
when using an entire disk.
You may want to try the fix I prepared (...)
<https://salsa.debian.org/pham/partman-auto/-/commits/choose_recipe-fixes?ref_type=heads>
On 15/09/2024 � 12:27, Holger Wansing wrote:
Using the "separate home+var+tmp" recipe under UEFI variant on a 10G disk results in an error
"Unable to satisfy all constraints on the partition"(...)
"Failed to partition the selected disk. This probably happened because there
are too many (primary) partitions in the partition table."
In the partitioning overview (screenshot 3) the /home partition is
missing, so this is the one which raises the error apparently.
Also, the /tmp partition size (468MB) is lower that the minimum size
defined in the EFI "multi" recipe (500MB). The minimum disk size for
this recipe is 11768MB, so the recipe should not be available on a
10.7GB (10GiB) disk. I suspect you hit the same bug on an already partitioned disk as described in <https://lists.debian.org/debian-boot/2024/08/msg00151.html>.
Summary: existing reusable partitions (efi and swap) minimum sizes may wrongly be ignored when calculating the required minimum disk size even
when using an entire disk.
Last time I guess it did not trigger an error because /home could be created, athough with the wrong size. This time, there was no free space left to create /home at all.
The bug already existed previously and is totally unrelated with the MR,
it could be triggered with specific disk sizes. It just happened that
10GiB is such a specific size for the updated recipes.
It cannot happen on a disk with no efi nor swap partitions.
Do we need to adjust the minimum disk size for this recipe maybe, or similar?
The minimum disk size for a recipe is calculated automatically by
summing up the minimum partition sizes in the recipe. Changing minimum partition sizes would just change the disk size which triggers the bug.
You may want to try the fix I prepared but considered not essential
(useful only on small disks with sizes close to the required minimum
size). Who would be fool enough to use the multi recipe on a 10GB disk ?
<https://salsa.debian.org/pham/partman-auto/-/commits/choose_recipe-fixes?ref_type=heads>
On 15/09/2024 at 14:39, Pascal Hambourg wrote:
Summary: existing reusable partitions (efi and swap) minimum sizes may wrongly be ignored when calculating the required minimum disk size even when using an entire disk.(...)
You may want to try the fix I prepared (...)
<https://salsa.debian.org/pham/partman-auto/-/commits/choose_recipe-fixes?ref_type=heads>
Draft merge request: <https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/17>
We cannot make it fool-proof for all and every situation.
On 15/09/2024 at 20:43, Holger Wansing wrote:
We cannot make it fool-proof for all and every situation.
Maybe not, but identified bugs with available fixes should not be left unfixed.
I thought I go for some testing then, but sadly the mechanism
to build mini.iso's from d-i commits seems broken for some
time.
Phil: are you aware of this?
I looks like an issue with the naming/versioning of linux-image,
but there have been some kernel uploads since then, and
the problem persists.
See
<https://salsa.debian.org/pham/partman-auto/-/pipelines/729206>:
The following packages have unmet dependencies:
builddeps:. : Depends: linux-image--amd64 but it is not installable
E: Unable to correct problems, you have held broken packages.
As this only happens with a very small disk (10G):
Do we need to adjust the minimum disk size for this recipe maybe, or similar?
Testing a local build against unstable, with a regular BIOS-based setup,
I'm seeing a failure to automatically partition a 5G disk, which I'd
call a major regression.
I'm not sure *where* I'd put the limit, but failing to partition a 5G
or 10G disk really doesn't seem acceptable to me.
On 23/09/2024 �at 16:57, Cyril Brulebois wrote:
Testing a local build against unstable, with a regular BIOS-based setup, I'm seeing a failure to automatically partition a 5G disk, which I'd
call a major regression.
Which method and recipe did you use ?
With a 5GB disk, the only available recipe should be "small_disk"
without LVM. On BIOS setup it requires at least 2.5GB disk space so it should not fail on a 5GB disk (I just tested).
Other recipes require 7.5-12.5GB, so they should not be offered.
I'm not sure *where* I'd put the limit, but failing to partition a 5G
or 10G disk really doesn't seem acceptable to me.
Our assumption was that guided partitioning primarily targeted casual desktop/laptop users who want to install a standard system with a
desktop environement, so we raised the limits of the "standard" recipes (atomic, home, multi) to enforce this use case. The "small_disk" recipe
was added to support small disks in other use cases.
Maybe we went to far ?
Pascal Hambourg <[email protected]> wrote (Mon, 23 Sep 2024 19:59:41 +0200):
On 23/09/2024 àat 16:57, Cyril Brulebois wrote:
Testing a local build against unstable, with a regular BIOS-based setup, >>> I'm seeing a failure to automatically partition a 5G disk, which I'd
call a major regression.
Which method and recipe did you use ?
With a 5GB disk, the only available recipe should be "small_disk"
without LVM. On BIOS setup it requires at least 2.5GB disk space so it
should not fail on a 5GB disk (I just tested).
Other recipes require 7.5-12.5GB, so they should not be offered.
I guess that's just another case of the "reuse" feature leading to
unexpected results, as in https://lists.debian.org/debian-boot/2024/09/msg00094.html
Pascal Hambourg <[email protected]> (2024-09-23):
Which method and recipe did you use ?
I guess that's just another case of the "reuse" feature leading to
unexpected results, as in https://lists.debian.org/debian-boot/2024/09/msg00094.html
Holger Wansing <[email protected]> (2024-09-23):
Pascal Hambourg <[email protected]> (2024-09-23):
Which method and recipe did you use ?
Encrypted LVM.
The default option works though.
On 24/09/2024 at 00:43, Cyril Brulebois wrote:org/debian-boot/2024/08/msg00149.html>. But I overlooked that it also disables encryption which requires LVM...
Holger Wansing <[email protected]> (2024-09-23):
Pascal Hambourg <[email protected]> (2024-09-23):
Which method and recipe did you use ?
Encrypted LVM.
The default option works though.
Ah, the small_disk recipe does not support LVM. It is intended, because I considered that using LVM does not make much sense on a < 10GB disk and takes more space for the separate /boot. See the part of the discussion starting with <https://lists.debian.
Enable LVM with small_disk (again) ?
On 24/09/2024 at 00:43, Cyril Brulebois wrote:
Holger Wansing <[email protected]> (2024-09-23):
Pascal Hambourg <[email protected]> (2024-09-23):
Which method and recipe did you use ?
Encrypted LVM.
The default option works though.
Ah, the small_disk recipe does not support LVM. It is intended, because I considered that using LVM does not make much sense on a < 10GB disk and
takes more space for the separate /boot. See the part of the discussion starting with <https://lists.debian.org/debian-boot/2024/08/msg00149.html>. But I overlooked that it also disables encryption which requires LVM...
Enable LVM with small_disk (again) ?
Pascal Hambourg <[email protected]> (2024-09-24):
Enable LVM with small_disk (again) ?
Yes please.
On Mon Sep 16, 2024 at 7:49 AM CEST, Holger Wansing wrote:(...)
I thought I go for some testing then, but sadly the mechanism
to build mini.iso's from d-i commits seems broken for some
time.
Phil: are you aware of this?
That looks like the kernel 'ABI' detection is going wrong.
https://salsa.debian.org/installer-team/debian-installer/-/blob/master/debian/salsa-ci.yml#L43
would be my guess where 'something' needs to be updated?
Holger Wansing <[email protected]> (2024-09-15):
As this only happens with a very small disk (10G):
Do we need to adjust the minimum disk size for this recipe maybe, or similar?
Testing a local build against unstable, with a regular BIOS-based
setup, I'm seeing a failure to automatically partition a 5G disk,
which I'd call a major regression.
Hi again,
Cyril Brulebois <[email protected]> (2024-09-23):
Holger Wansing <[email protected]> (2024-09-15):
As this only happens with a very small disk (10G):
Do we need to adjust the minimum disk size for this recipe maybe, or
similar?
Testing a local build against unstable, with a regular BIOS-based
setup, I'm seeing a failure to automatically partition a 5G disk,
which I'd call a major regression.
This time, still testing with a 5G disk, but using the default choice
(“use entire disk”, without encrypted LVM), I'm getting both Debian >Desktop environment and GNOME selected, but that doesn't fit: the >installation aborted mid-way with a weird error about dictionaries
(French not being found/installed as expected, while the root issue is >ENOSPC).
Should that matter, the partitioning scheme is the small disk one (as >expected given the <10G in parens).
There's no correlation with partitioning/partition sizes here, I think.
I guess there has never been any check in tasksel, if the selected
tasks fit on the disk? (or the other way around: tasksel does not
filter out tasks, if don't fit on the disk)
There's no correlation with partitioning/partition sizes here, I think.
That's what I thought as well, but that's the biggest, related change
I could think of.
I guess there has never been any check in tasksel, if the selected
tasks fit on the disk? (or the other way around: tasksel does not
filter out tasks, if don't fit on the disk)
Well, those two tasks were not enabled automatically until the last few >weeks… (and I've been testing with that particular disk size for many >release cycles), so *something* changed.
And that logic in tests/desktop controls indeed, if desktop task
is pre-selected.
Maybe it's time to raise that limit once again?
Of course, one might ask, what has changed in the last few weeks:
that might be the size of partition (however since you used the
small_disk recipe, that should only be marginal), or maybe some
dependencies have changed at some point, so that more packages
are now included in the default desktop.
But either way, at the end we will need to raise the limit above by
1 or 2G anyway, to get this solved IMO.
Holger Wansing <[email protected]> (2024-10-03):
And that logic in tests/desktop controls indeed, if desktop task
is pre-selected.
Maybe it's time to raise that limit once again?
Yeah, that looks plausible.
Of course, one might ask, what has changed in the last few weeks:
that might be the size of partition (however since you used the
small_disk recipe, that should only be marginal), or maybe some dependencies have changed at some point, so that more packages
are now included in the default desktop.
But either way, at the end we will need to raise the limit above by
1 or 2G anyway, to get this solved IMO.
That would work for me, yes: I think it's better to provide safe
defaults, and let people who want to have a desktop environment select
it; maybe they'll get lucky and it'll fit, maybe that won't be the case.
Seems better than selecting something by default without being sure it
does fit?
Cyril Brulebois <[email protected]> wrote (Thu, 3 Oct 2024 08:23:43 +0200):
Seems better than selecting something by default without being sure it
does fit?
Sure.
Tests show, that raising the limit by 1G to 4G brings back the old behaviour (no desktop task pre-selected), but to be a bit prepared for future growth,
I would propose to go to 5G here?
There is infact some sort of (incomplete) check for enough disk space
in tasksel.
In 2007 there was:
* Increase the minimum free disk for automatic selection of the desktop task to 3 gb.
And that logic in tests/desktop controls indeed, if desktop task
is pre-selected.
Maybe it's time to raise that limit once again?
Of course, one might ask, what has changed in the last few weeks:
that might be the size of partition
Holger Wansing <[email protected]> (2024-10-03):
Cyril Brulebois <[email protected]> wrote (Thu, 3 Oct 2024 08:23:43 +0200):
Seems better than selecting something by default without being sure it does fit?
Sure.
Tests show, that raising the limit by 1G to 4G brings back the old behaviour
(no desktop task pre-selected), but to be a bit prepared for future growth, I would propose to go to 5G here?
That would look good to me, thanks for the tests!
Tests show, that raising the limit by 1G to 4G brings back the old behaviour (no desktop task pre-selected), but to be a bit prepared for future growth,
I would propose to go to 5G here?
On 03/10/2024 at 12:11, Holger Wansing wrote:
Tests show, that raising the limit by 1G to 4G brings back the old behaviour >> (no desktop task pre-selected), but to be a bit prepared for future growth, >> I would propose to go to 5G here?
FWIW, 5GB is fine with the "multi" recipe minimum root size (7GB). Increasing it further may require to update the recipe.
Holger Wansing <[email protected]> (2024-10-03):
Cyril Brulebois <[email protected]> wrote (Thu, 3 Oct 2024 08:23:43 +0200):
Seems better than selecting something by default without being sure it does fit?
Sure.
Tests show, that raising the limit by 1G to 4G brings back the old behaviour
(no desktop task pre-selected), but to be a bit prepared for future growth, I would propose to go to 5G here?
That would look good to me, thanks for the tests!
Also there is a test in tests/desktop, if enough RAM is installed, to make sense for a desktop environment to be installed.
The actual value is 64MB, from the beginning of this logic, thus it's 19 years
old.
So, if less than 64MB of RAM is installed, the desktop task will not be pre-selected.
Should we update this to real world as well?
In https://d-i.debian.org/manual/en.amd64/ch03s04.html we recommend at least 2GB of RAM for desktop systems.
I could think of using this value for the above check as well, or maybe
the double of it.
Hi,
Cyril Brulebois <[email protected]> wrote (Thu, 3 Oct 2024 12:32:34 +0200):
Holger Wansing <[email protected]> (2024-10-03):
Cyril Brulebois <[email protected]> wrote (Thu, 3 Oct 2024 08:23:43 +0200):
Seems better than selecting something by default without being sure it does fit?
Sure.
Tests show, that raising the limit by 1G to 4G brings back the old behaviour
(no desktop task pre-selected), but to be a bit prepared for future growth,
I would propose to go to 5G here?
That would look good to me, thanks for the tests!
Just pushed to git.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 139:59:21 |
| Calls: | 12,087 |
| Files: | 14,998 |
| Messages: | 6,517,419 |
