On 15/08/2024 at 16:25, Diederik de Haas wrote:
On Thu Aug 15, 2024 at 3:46 PM CEST, Pascal Hambourg wrote:
On 15/08/2024 at 08:26, Holger Wansing wrote:
Am 15. August 2024 00:47:22 MESZ schrieb Diederik de Haas 
<didi.deb...@cknow.org>:

So it would be very helpful if the recipe(s) for ARM devices would
reserve the first 16MB automatically with plain partitioning.

What do you mean exactly by "plain partitioning" ? Manual partitioning ?
Guiding partitioning with all files in one filesystem ? Other ?

Partitioning NOT involving LVM.
I 'jumped in' when the subject of creating blank/reserved partitions
with LVM and then the question arose if that should also be used for
"plain" partitioning, which I interpreted as not using LVM.

Ah, now I understand why you quoted that part. But it is unrelated.

Guided partitioning (partman-auto-lvm) allows to reserve some unallocated space in the LVM VG, in other words not use all the available space in the VG. This is simply done by reducing the amount of free space used to perform the LVM recipe. Of course the location of the reserved space within the PV is unspecified, as is the location of LVs. The LVM PV partition still uses all the available disk space.

Allowing guided partitioning without LVM (partman-auto) to not use all the available space could also be done by reducing the amount of free space used to perform the recipe. I guess the unallocated space would be located at the end of the disk. The purpose was not to reserve a specific disk area but leave some free space for future allocation (create new partitions or extend the last partition, unlike LVM which allows to easily extend any LV).

I do not know any way to reserve unallocated space in recipes. The
recipes could create a 16-MiB unused partition but the table in [2]
lists a lot of special partitions within the first 16 MiB. Are these
actual partitions ? If yes, how are they supposed to be created ?

I think you technically could create those partitions, but those are not
relevant. All that matter is that the first 16 MiB stay unused so that
U-Boot can be put there.

It is still unclear to me if it can be an unused partition or if it must be unallocated space which can be used to create new partitions.
AFAIK, only the former can be done in recipes.

Looks like another incarnation of
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770666>

It looks like a different issue to me. IIUC these bug reports are about
parted_server erasing the boot loader location when creating a new
partition table, not the first partition overlapping with the boot
loader location.

AIUI bug #770666 is the same/similar as this 'Rockchip' issue.
Bug #751704 OTOH is related, but does deal with problems wrt partition
table.

AIUI, #751704 and #770666 are the same bug for different platforms and are unrelated with the first partition position. They are caused by parted erasing the first 9 KiB when creating a new partition table. The fix for #770666 only extended the fix for #751704 to handle more platforms. The 'Rockchip' issue you mention is unrelated as the boot loader is located after 32 KiB, beyond the erased area.

Reply via email to