Hi Diederik,
First, thank you for the detailed test report !
On 19/10/2024 at 16:54, Diederik de Haas wrote:
On Sat Oct 19, 2024 at 1:40 PM CEST, Holger Wansing wrote:
@Diederik: could you test, if it works for you now?
Or anyone else, who has the possibility/the hardware for this?
(...)
I forgot to write down which partition option I choose, but I _think_ it
was 'use the entire disk' for 1 partition. More on that later as I want
to verify that.
I did take a photo of the partitioning suggestion and in text that was:
1.0 MB FREE SPACE
#1 16.8 MB
#2 896.5 MB f ext2 /boot
#3 14.0 GB f ext4 /
#4 825.2 MB f swap swap
1.0 MB FREE SPACE
It looks as expected with the "atomic" recipe.
After the install I examined the SDcard with `fdisk`:
Disk /dev/sdb: 14.64 GiB, 15720251392 bytes, 30703616 sectors
Disk model: SDDR-389
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: DE22E911-3163-4844-A95C-56175B710651
Device Start End Sectors Size Type
/dev/sdb1 2048 34815 32768 16M Linux filesystem
/dev/sdb2 34816 1785855 1751040 855M Linux filesystem
/dev/sdb3 1785856 29089791 27303936 13G Linux filesystem
/dev/sdb4 29089792 30701567 1611776 787M Linux swap
It looks as expected too.
According to [2] (wiki_Partitions) the boot partition start sector
should be 32768, but AFAIK it's fine if it's later, so that's good.
Automatic partitioning has a granularity of 1MB (decimal) which is then
combined with parted's default alignment on 1MiB (binary) boundaries, so
it is not easy to get exact results.
I already had a hunch why that may be and that's when I examined the
SDcard with `lsblk` and later with `fdisk`. Went into `fdisk`'s expert
menu and enabled the boot flag on partition 2 (`/boot`).
Plugged the SDcard into my Rock64 again and booted up and then it
succeeded \o/
IOW: It was so, so close from working ... but it needs the 'boot' flag.
Do you mean the "legacy BIOS bootable flag" (legacy_boot in parted) ?
Unfortunately partman does not manage it. IIRC the "$bootable{ }" flag
in recipes is translated into parted "boot" flag, but on GPT the "boot"
flag means the same as "esp" (this is a huge mess) and partman clears
them if the partition method is not "efi". It should not be hard to
write a patch to translate the "$bootable{ }" flag into the
"legacy_boot" flag instead of the "boot" flag on GPT.
I'll (later) do another install attempt to verify whether it actually
should NOT have created a boot partition or that I just mis-remembered.
All existing arm* recipes always created a separated ext2 /boot
partition, so I kept it in the new arm64 recipes. If this is not needed,
the arm64 recipes can be changed so that they create a separate /boot
partition only when partitioning with LVM, just like recipes for other
architectures.
