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>:
I'm not 100% sure if this fits into this subject/discussion, but ...
It is beyond the original scope (partition size limits) and I believe it
would deserve its own discussion involving people who are familiar with
ARM platforms.
Disclaimer: I have no experience nor knowledge about ARM (or any other
architectures than x86) and its boot process.
The U-Boot bootloader is normally put in the first part of the boot
device and for Rockchip based devices that can extend to the 16MB
'mark'. AFAIK bootloaders for other SoCs are before that.
If you use the current recipes you end up with an unbootable system as
the U-Boot bootloader get overwritten with the / (root) partition and
the data on it.
AFAICS, the first partition in all non-EFI ARM recipes is /boot, not /.
Right now, the instruction is to choose manual partitioning and create
a 16MB partition ([1] says 32MB, but it should be 16MB [2]) and then the
normal partitions and after that you could remove that partition again.
And if you type in 16MB, then you need to 'hope' that it is actually
16MB and not something (a bit) smaller.
16 MB (~15.3 MiB) or 16 MiB (~16.8 MB) ?
In partman, 1 MB really means 10^6 bytes, not 1 MiB (2^20 bytes).
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 ?
[1] https://wiki.pine64.org/wiki/ROCK64_Software_Releases#Debian
[2] https://opensource.rock-chips.com/wiki_Partitions
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 ?
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.
