Bug#1086051: [arm64] partman recipes: add new identifier for legacy_boot flag on GPT table?

[Holger Wansing]

Package: partman-auto
Version: 168


This is a follow-up for #1078871:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078871


Shortly it has been mentioned, that there are arm64 systems out there (for
example Rockchip), which require the 'legacy_boot' flag on the root partition
(or on separate /boot partition if such exists) on GPT table, to be able to boot.
[1] + further messages in the bug

To be able to set this 'legacy_boot' flag in a clean way and not mix this up
with setting of parted's 'boot'/'esp' flag on EFI partitions, it was
suggested to add a new identifier like
'$legacy_boot{ }'
to the pre-generated partman recipes.
This identifier could then set the 'legacy_boot' flag on root/boot partitions,
while the existing $bootable{ } identifier handles 'boot'/'esp' flag on EFI
partitions.
A new branch has been created for this proposal: [2]


Alternatively, we could add a value to the existing '$bootable{ }'
specifier to indicate we want to set the 'legacy_bootable' flag on GPT
(and the 'boot' flag on other disk labels). E.g.

$bootable{ } -> set 'boot' on non-GPT only
$bootable{ legacy } -> set 'boot' on non-GPT and 'legacy_boot' on GPT



What do people think about such changing the long-standing format of
pre-generated recipes?


Holger


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078871#67
[2] https://salsa.debian.org/pham/partman-auto/-/commits/legacy_boot_specifier/?ref_type=heads

[Pascal Hambourg]

Post by Holger Wansing
Shortly it has been mentioned, that there are arm64 systems out there (for
example Rockchip), which require the 'legacy_boot' flag on the root partition
(or on separate /boot partition if such exists) on GPT table, to be able to boot.
To be able to set this 'legacy_boot' flag in a clean way and not mix this up
with setting of parted's 'boot'/'esp' flag on EFI partitions, it was
suggested to add a new identifier like
'$legacy_boot{ }'
to the pre-generated partman recipes.
This identifier could then set the 'legacy_boot' flag on root/boot partitions,
while the existing $bootable{ } identifier handles 'boot'/'esp' flag on EFI
partitions.
A new branch has been created for this proposal: [2]

I feel a bit of clarification is needed here.

The '$bootable{ }' specifier sets the 'boot' flag only on non-GPT disk
labels. It has currently no effect on GPT, which is the default disk
label for arm64. The 'boot/esp' flag is set only by the 'efi' method
('method{ efi }') in EFI recipes.

My original proposal [3] was to change the behaviour of the '$bootable{
}' specifier so that it sets the 'legacy_boot' flag on GPT. But some
concern about possible side effects of setting this flag on other
architectures was raised. So I proposed to introduce a new specifier.

Post by Holger Wansing
Alternatively, we could add a value to the existing '$bootable{ }'
specifier to indicate we want to set the 'legacy_bootable' flag on GPT
(and the 'boot' flag on other disk labels). E.g.
$bootable{ } -> set 'boot' on non-GPT only
$bootable{ legacy } -> set 'boot' on non-GPT and 'legacy_boot' on GPT
What do people think about such changing the long-standing format of
pre-generated recipes?

This is not strictly within the scope of this bug report but we also
need to decide how to manage the 'legacy_boot' flag in manual
partitioning. My original proposal was to change the behaviour of the
existing 'Bootable' setting, which has currently no effect on GPT:
- non-GPT -> manage the 'boot' flag
- GPT -> manage the 'legacy_boot' flag

Post by Holger Wansing
[2] https://salsa.debian.org/pham/partman-auto/-/commits/legacy_boot_specifier/?ref_type=heads

[3]
<https://salsa.debian.org/pham/partman-auto/-/commits/legacy_boot/?ref_type=heads>

[Pascal Hambourg]

(Forwarding the relevant part of this reply from bug#1078871 to bug#1086051)

I think there are several things that u-boot treats as bootable ...
https://source.denx.de/u-boot/u-boot/-/blob/3fbc657669591ca893613f14d42e07069b7d56cd/doc/develop/distro.rst?plain=1#L38-62
Distros simply need to install the boot configuration files (see next
section) in an ext2/3/4 or FAT partition, mark the partition bootable (via
the MBR bootable flag, or GPT legacy_bios_bootable attribute), and U-Boot (or
any other bootloader) will find those boot files and execute them. This is
conceptually identical to creating a grub2 configuration file on a desktop
PC.
Note that in the absence of any partition that is explicitly marked bootable,
U-Boot falls back to searching the first valid partition of a disk for boot
configuration files. Other bootloaders are recommended to do the same, since
I believe that partition table bootable flags aren't so commonly used outside
the realm of x86 PCs.
So this is both relevent if using u-boot to using various boot methods,
such as extlinux.conf style configuration produced by u-boot-menu or
boot.scr produced by flash-kernel... but also it might be relevent if
you are using u-boot as your EFI implementation to load grub-efi.
I am not entirely sure the above documentation is exhaustive; I seem to
recall u-boot also treating the ESP/EFI partition as bootable, but that
may be because various other flags get set at the same time... though I
have used ESP/EFI partitions as /boot with u-boot before without any EFI
implementation.
A very cursory search of u-boot source code did not reveal any
additional ways u-boot might treat a partition as "bootable", though the
documentation I quoted from is kind of the old style "distro" boot
vs. the newer "bootstd" which I am less familiar with...

Unless I am missing something, things seem to be quite simple to me:
- EFI boot -> set the ESP type (partman "efi" method, parted 'esp' flag)
to the EFI partition (already done);
- non-EFI boot -> set the "legacy BIOS bootable" attribute on GPT
(parted 'legacy_boot' flag) or the "boot" flag on DOS/MBR (partman
"bootable" specifier, parted 'boot' flag).

Now how do we make partman manage the 'legacy_boot' flag in recipes and
manual partitioning ? See proposals in previous mails.

[Holger Wansing]

Hi,

- EFI boot -> set the ESP type (partman "efi" method, parted 'esp' flag) to the EFI partition (already done);
- non-EFI boot -> set the "legacy BIOS bootable" attribute on GPT (parted 'legacy_boot' flag) or the "boot" flag on DOS/MBR (partman "bootable" specifier, parted 'boot' flag).
Now how do we make partman manage the 'legacy_boot' flag in recipes and manual partitioning ? See proposals in previous mails.

For the recipe / guided partitioning part:
To be backward-compatible for the already existing identifier,, and keep
the format consistent, I would prefer using identifiers like

$bootable{ }
$legacy_boot{ }

as proposed in
<https://salsa.debian.org/pham/partman-auto/-/commits/legacy_boot_specifier/?ref_type=heads>



Holger

[Pascal Hambourg]

Post by Holger Wansing
To be backward-compatible for the already existing identifier,, and keep
the format consistent, I would prefer using identifiers like
$bootable{ }
$legacy_boot{ }
as proposed in
<https://salsa.debian.org/pham/partman-auto/-/commits/legacy_boot_specifier/?ref_type=heads>

Then if nobody objects, I will open a merge request from this branch.

[Debian Bug Tracking System]

tags -1 patch

Bug #1086051 [partman-auto] [arm64] partman recipes: add new identifier for legacy_boot flag on GPT table?
Added tag(s) patch.

[Pascal Hambourg]

Control: tags -1 patch

Post by Pascal Hambourg

Post by Holger Wansing
To be backward-compatible for the already existing identifier,, and keep
the format consistent, I would prefer using identifiers like
$bootable{ }
$legacy_boot{ }
as proposed in
<https://salsa.debian.org/pham/partman-auto/-/commits/legacy_boot_specifier/?ref_type=heads>

Then if nobody objects, I will open a merge request from this branch.

Yes, please.

<https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/21>

[Debian Bug Tracking System]

Your message dated Sun, 10 Nov 2024 20:57:15 +0100
with message-id <***@mailbox.org>
and subject line Re: Bug#1086051: [arm64] partman recipes: add new identifier for legacy_boot flag on GPT table?
has caused the Debian Bug report #1086051,
regarding [arm64] partman recipes: add new identifier for legacy_boot flag on GPT table?
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 ***@bugs.debian.org
immediately.)