Hi,

just to let you know:
I have created a merge request to increase the size of ESP similar to what has been done for /boot (in git) shortly: https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/14

Note:
on big disks (> 10G I guess) the ESP is already 1G, so there is nothing to be done. Only on smaller disks it has ~512MB, so that could be changed to ~768MB to be consistent with /boot.


Holger

--
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Holger Wansing <hwansing@mailbox.org> wrote (Thu, 25 Jul 2024 20:38:48 +0200):

Hi,

just to let you know:
I have created a merge request to increase the size of ESP similar to what has
been done for /boot (in git) shortly: https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/14

Note:
on big disks (> 10G I guess) the ESP is already 1G, so there is nothing to be done. Only on smaller disks it has ~512MB, so that could be changed to ~768MB to be consistent with /boot.

Ok, I got it wrong again:
current recipe data for ESP is "538 538 1075 free"

So PRIORITY is identical to MIN, and that does not allow for growth.
Means, ESP is 512 MiB for all disks currently.

Thus this MR has effect on all disk sizes.

Sorry for the trouble


Holger


--
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/07/2024 at 21:47, I wrote:

Explanation: raw increment factors are normalized on a base 100 and
rounded to integers. It means that it a raw increment factor is less

^^
if

than 1% of the sum of all increment factors, then the normalized
increment factor equals 0 and the partition cannot grow.

The sum of raw factors is over 80000, so 44*100/8000=0,55 rounded to 0.

^^^^^
8000.

I should proofread myself before posting.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Thursday, 25 July 2024 20:38:48 CEST Holger Wansing wrote:

just to let you know:
I have created a merge request to increase the size of ESP similar to what has been done for /boot (in git) shortly: https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/14

Note:
on big disks (> 10G I guess) the ESP is already 1G, so there is nothing to
be done. Only on smaller disks it has ~512MB, so that could be changed to ~768MB to be consistent with /boot.

The primary reason why I objected to increase the ESP size in the 'other' MR was NOT because of its size; I assumed that could be a no-brainer.

Making ESP 1G was an implementation 'detail' of switching to Unified Kernel Image (UKI) where *I*IUC the kernels and initramfs would be stored. The idea
of storing important things like kernels/UKI on FAT32 horrifies me.
But that can be a complete misunderstanding on my part, exactly because I
don't know anything about that subject.

When going for UKI (or providing it as an option), it seemed to me that (at least) both the debian-boot and the debian-kernel teams should be involved to properly *discuss* that idea. And possibly other people who can say something useful on the matter, which thus excludes me.

Only having debian-boot in CC feels *to me* more of a notification and not as an invitation to discuss the idea itself. After there's consensus on the UKI idea itself, the implementation will follow (with a 1G ESP partition).

Sorry if I hadn't made myself clear before.

My 0.02
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZqKlRwAKCRDXblvOeH7b biEjAQC54yQEL856Jlp/RJVAeCTaPpDmAngSsO2lVs7wvNo1KQD/aPV2cx2CWunH uSBlfzbyiUy1X7O9YLAXBu6bxAiP7wo=
=tOHr
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

On 25/07/2024 at 20:38, Holger Wansing wrote:

on big disks (> 10G I guess) the ESP is already 1G

Actually not. As mentioned in <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076952>, the recipe
had MIN=PRIORITY which resulted in the size being stuck to MIN (538 MB) regardless of the available disk size.

Only on smaller disks it has ~512MB, so that could be changed to ~768MB
to be consistent with /boot.

OK. But with MIN=806 and PRIO=850 (how did you define this value ?), the increment factor (PRIO-MIN=44) is too low to allow any growth when
partitioning without LVM.

Explanation: raw increment factors are normalized on a base 100 and
rounded to integers. It means that it a raw increment factor is less
than 1% of the sum of all increment factors, then the normalized
increment factor equals 0 and the partition cannot grow.

The sum of raw factors is over 80000, so 44*100/8000=0,55 rounded to 0.

When partitioning with LVM, the lvmok partitions (/ /home swap...) are
ignored for the non-lvmok partitions (efi, /boot) calculation size.
Instead, a lvm partition with PRIO=900 is used. With such low value, the normalized increment factor for the ESP equals 4 and the maximum size
1075 MB is reached with a disk size of 9 GB.

I anticipated this and looked at partman-auto-lvm for way to set the
same partition sizes with and without LVM. Not easy.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote (Thu, 25 Jul 2024 21:47:19 +0200):

Hello,

On 25/07/2024 at 20:38, Holger Wansing wrote:

on big disks (> 10G I guess) the ESP is already 1G

Actually not. As mentioned in <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076952>, the recipe
had MIN=PRIORITY which resulted in the size being stuck to MIN (538 MB) regardless of the available disk size.

Yes, I noticed that already :-)

Only on smaller disks it has ~512MB, so that could be changed to ~768MB
to be consistent with /boot.

OK. But with MIN=806 and PRIO=850 (how did you define this value ?), the increment factor (PRIO-MIN=44) is too low to allow any growth when partitioning without LVM.

The ESP seems to be a special case regarding the calculation of the disk size. There was a changing https://salsa.debian.org/installer-team/partman-auto/-/commit/a5df6f5c98a58bb81e688fc3c2b6532833a8e4d0
which bumped the 512 to 538 MB and the 1024 to 1075 MB.

Thus, I based my rough calculation on that new values (768 + that 'overhead' from above).

Explanation: raw increment factors are normalized on a base 100 and
rounded to integers. It means that it a raw increment factor is less
than 1% of the sum of all increment factors, then the normalized
increment factor equals 0 and the partition cannot grow.

The sum of raw factors is over 80000, so 44*100/8000=0,55 rounded to 0.

When partitioning with LVM, the lvmok partitions (/ /home swap...) are ignored for the non-lvmok partitions (efi, /boot) calculation size.
Instead, a lvm partition with PRIO=900 is used. With such low value, the normalized increment factor for the ESP equals 4 and the maximum size
1075 MB is reached with a disk size of 9 GB.

I anticipated this and looked at partman-auto-lvm for way to set the
same partition sizes with and without LVM. Not easy.

Hmm, that seems a bit out of my skills :-(
But if a value of 538 worked for 512MB, why should 806 not work then for
~768MB ?


Holger

--
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/07/2024 at 21:59, Holger Wansing wrote:

Pascal Hambourg <pascal@plouf.fr.eu.org> wrote (Thu, 25 Jul 2024 21:47:19 +0200):

On 25/07/2024 at 20:38, Holger Wansing wrote:

Only on smaller disks it has ~512MB, so that could be changed to ~768MB
to be consistent with /boot.

OK. But with MIN=806 and PRIO=850 (how did you define this value ?), the
increment factor (PRIO-MIN=44) is too low to allow any growth when
partitioning without LVM.

The ESP seems to be a special case regarding the calculation of the disk size.
There was a changing https://salsa.debian.org/installer-team/partman-auto/-/commit/a5df6f5c98a58bb81e688fc3c2b6532833a8e4d0
which bumped the 512 to 538 MB and the 1024 to 1075 MB.

The bug report <https://bugs.launchpad.net/curtin/+bug/1306164>
mentioned in the commit reports an issue with some UEFI firmware and
FAT32 ESP with size less than 512 MiB (537 MB). Any larger size is fine.

Thus, I based my rough calculation on that new values (768 + that 'overhead' from above).

Actually my question was about the PRIORITY value (850).

But if a value of 538 worked for 512MB, why should 806 not work then for ~768MB ?

Either 768 or 806 are perfectly fine. The problem is PRIORITY, not MIN.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Am 25. Juli 2024 22:36:13 MESZ schrieb Pascal Hambourg <pascal@plouf.fr.eu.org>:

I have created a merge request to increase the size of ESP similar to what has
been done for /boot (in git) shortly:
https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/14

Should we carry on this discussion in the MR on salsa or debian-boot ?

I moved that to MR14 now.


Holger

--
Sent from /e/ OS on Fairphone3

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)