Bug#1078871: installer: reserve first 16 MiB space in default recipes for ARM devices?
Hi,
"Diederik de Haas" <didi.debian@cknow.org> wrote (Sun, 20 Oct 2024 16:28:41 +0200):
> The 'cs21' device is a (different) Rock64 (rk3328):
>
> ```
> diederik@cs21:~$ ls -lh /boot/
> total 242M
> ...
> -rw-r--r-- 1 root root 285K sep 30 21:08 config-6.1.0-26-arm64
> drwxr-xr-x 4 root root 16K jan 1 1970 efi
> drwxr-xr-x 2 root root 4,0K okt 9 18:02 extlinux
> drwxr-xr-x 5 root root 4,0K okt 9 18:03 grub
> -rw-r--r-- 1 root root 30M okt 9 18:02 initrd.img-6.1.0-26-arm64
> -rw-r--r-- 1 root root 83 sep 30 21:08 System.map-6.1.0-26-arm64
> -rw-r--r-- 1 root root 32M sep 30 21:08 vmlinuz-6.1.0-26-arm64
> ```
>
> I have 4 kernels installed, but listing them all isn't useful.
>
> And now the partition stuff:
>
> ```
> root@cs21:~# parted -s /dev/mmcblk1 print
> Model: MMC NCard (sd/mmc)
> Disk /dev/mmcblk1: 61.9GB
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
>
> Number Start End Size File system Name Flags
> 1 32.8kB 16.8MB 16.7MB primary
> 2 16.8MB 256MB 239MB fat16 primary boot, esp
> 3 256MB 61.9GB 61.6GB ext4 primary
>
> root@cs21:~# lsblk -o +PARTFLAGS,FSTYPE /dev/mmcblk1
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS PARTFLAGS FSTYPE
> mmcblk1 179:0 0 57.6G 0 disk
> ├─mmcblk1p1 179:1 0 16M 0 part
> ├─mmcblk1p2 179:2 0 228M 0 part /boot/efi vfat
> └─mmcblk1p3 179:3 0 57.4G 0 part / ext4
> ```
>
> And 'quartz64a' is a Pine64 Quartz64 Model A (rk3566):
>
> ```
> root@quartz64a:~# parted -s /dev/mmcblk1 print
> Model: MMC A3A562 (sd/mmc)
> Disk /dev/mmcblk1: 124GB
> Sector size (logical/physical): 512B/512B
> Partition Table: gpt
> Disk Flags:
>
> Number Start End Size File system Name Flags
> 1 32.8kB 3670kB 3637kB loader1_part
> 2 8389kB 12.6MB 4194kB loader2_part
> 3 12.6MB 16.8MB 4194kB trust_part
> 4 16.8MB 134MB 117MB efi_part
> 5 134MB 124GB 124GB ext4 root_part legacy_boot
>
> root@quartz64a:~# lsblk -o +PARTFLAGS,FSTYPE /dev/mmcblk1
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS PARTFLAGS FSTYPE
> mmcblk1 179:0 0 115.2G 0 disk
> ├─mmcblk1p1 179:1 0 3.5M 0 part
> ├─mmcblk1p2 179:2 0 4M 0 part
> ├─mmcblk1p3 179:3 0 4M 0 part
> ├─mmcblk1p4 179:4 0 112M 0 part
> └─mmcblk1p5 179:5 0 115.1G 0 part / 0x4 ext4
> ```
>
> FTR: I cannot think of any reason why the device type would matter.
> And the Quartz64-A has those other partitions, but doesn't use them.
> Just some other experiment with the 'official' Rockchip partition
> layout.
>
> And I just changed the 'legacy_boot' flag to 'boot' on the SDcard with
> which I did my test, which then (apparently) also triggers the 'esp'
> flag and it booted with that too.
> So it looks like it just needs some indication (flag) of what the boot
> device is, but it doesn't (seem to) matter which one.
Hmm, I'm irritated now:
here you have a device|installation, which has the legacy_boot flag
installed, but it did not work|boot despite of this. And you changed that
legacy_boot flag into a boot flag, and that made the problem go away?
(so the device boots fine).
So, why should we then do some work to implement the setting of the
legacy_boot flag on arm64?
And here, from another mail:
"Diederik de Haas" <didi.debian@cknow.org> wrote (Mon, 21 Oct 2024 10:26:28 +0200):
> On Sun Oct 20, 2024 at 8:49 PM CEST, Pascal Hambourg wrote:
> > > So it looks like it just needs some indication (flag) of what the boot
> > > device is, but it doesn't (seem to) matter which one.
> >
> > Weird. Does it have to be on the boot/root partition or can it be on any
> > other partition ?
>
> It appears to not matter if it's 'boot' or 'legacy_boot', but it (ofc?)
> needs to be set on the partition with the kernel as that needs to be
> started for the rest of the boot process.
> My guess is that on the tested system it tried to do something with TFTP
> as it couldn't find a kernel as the '[legacy_]boot' flag was not set,
> thus couldn't find a kernel thus tried another option (tftp).
Here you also imply, that both boot or legacy_boot flag do the job.
So, can I understand this, as there is no need to set the legacy_boot flag,
but just adjust the situations, where the 'boot' flag is being set?
Or do we explicitely want to support both the legacy_boot and the boot flag,
because we know that some systems are buggy and one needs the first
and other need the latter flag?
Sorry, or did I lost track somewhere?
(I was some days offline lately)
Holger
--
Holger Wansing <hwansing@mailbox.org>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Reply to: