A summary from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076952#65 and follow-ups:
Holger Wansing <hwans...@mailbox.org> wrote: > Looks like another incarnation of > <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+770666> > > @vagrant: > is this still (or again) an issue? ---------------------------------------------------------------------------- Pascal Hambourg <pas...@plouf.fr.eu.org> 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. > > 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. ---------------------------------------------------------------------------- "Diederik de Haas" <didi.deb...@cknow.org> wrote: > > 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. ---------------------------------------------------------------------------- Pascal Hambourg <pas...@plouf.fr.eu.org> wrote: > >> 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. ---------------------------------------------------------------------------- "Diederik de Haas" <didi.deb...@cknow.org> wrote: > > 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. > > Either would work. ---------------------------------------------------------------------------- Pascal Hambourg <pas...@plouf.fr.eu.org> wrote: > On 15/08/2024 at 21:00, Diederik de Haas wrote: > > On Thu Aug 15, 2024 at 5:50 PM CEST, Pascal Hambourg wrote: > >> On 15/08/2024 at 16:25, Diederik de Haas wrote: > >>> > >>> 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. > > > > Either would work. > > Then I guess a 16 MiB unused partition could be added to relevant > recipes. Now, which are the relevant recipes ? In other words, which > arch/subarch need it ? > Currently, partman-auto has the following recipes for ARM: > > recipes-armel-kirkwood > recipes-armel-orion5x > recipes-armhf-efikasb > recipes-armhf-efi (=recipes-amd64-efi) > recipes-armhf > recipes-arm64-efi (=recipes-amd64-efi) > recipes-arm64 (=recipes-armhf) ---------------------------------------------------------------------------- "Diederik de Haas" <didi.deb...@cknow.org> wrote: > On Thu Aug 15, 2024 at 10:24 PM CEST, Pascal Hambourg wrote: > > Then I guess a 16 MiB unused partition could be added to relevant > > recipes. Now, which are the relevant recipes ? In other words, which > > arch/subarch need it ? > > Currently, partman-auto has the following recipes for ARM: > > > > recipes-armel-kirkwood > > recipes-armel-orion5x > > recipes-armhf-efikasb > > These ones are NOT relevant for this. > > > recipes-armhf-efi (=recipes-amd64-efi) > > recipes-armhf > > recipes-arm64-efi (=recipes-amd64-efi) > > recipes-arm64 (=recipes-armhf) > > Rockchip makes both 32bit as 64bit ARM SoCs, so `recipes-armhf` is > relevant. > I don't know if it's common, but AFAIK you can use U-Boot with EFI, but > it sounds 'weird' to add it to a recipe with AMD64 in its name... ---------------------------------------------------------------------------- Pascal Hambourg <pas...@plouf.fr.eu.org> wrote: > On 16/08/2024 at 00:27, Diederik de Haas wrote: > > On Thu Aug 15, 2024 at 10:24 PM CEST, Pascal Hambourg wrote: > >> Then I guess a 16 MiB unused partition could be added to relevant > >> recipes. Now, which are the relevant recipes ? In other words, which > >> arch/subarch need it ? > > > >> recipes-armhf-efi (= recipes-amd64-efi) > >> recipes-armhf > >> recipes-arm64-efi (= recipes-amd64-efi) > >> recipes-arm64 (= recipes-armhf) > > > > Rockchip makes both 32bit as 64bit ARM SoCs, so `recipes-armhf` is > > relevant. > > If only Rockchip SoCs need the reserved partition and are detected as a > specific subarchitecture by archdetect, new specific recipes for this > subarchitecture could be added. > > > I don't know if it's common, but AFAIK you can use U-Boot with EFI, but > > it sounds 'weird' to add it to a recipe with AMD64 in its name... > > Indeed. If some ARM EFI platforms need the reserved partition, then one > of the recipes-arm*-efi symlinks could be replaced with a directory > containing new specific recipes and the other could be changed to point > to it. -- Holger Wansing <hwans...@mailbox.org> PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
