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>: > >> > >> 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.
Ok. > Disclaimer: I have no experience nor knowledge about ARM (or any other > architectures than x86) and its boot process. For partitioning there's nothing special ... apart that the first 16MiB should not be used. > >> 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 /. I shouldn't have written which partition, but the important thing is that the first 'real' partition starts at 16 MiB. > >> 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). I think I've actually tried both and IIRC that didn't make a difference. > >> 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. > >> [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 ? 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. > > 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. But I don't know/understand which of parted* sub programs is responsible for which part. Cheers, Diederik
signature.asc
Description: PGP signature
