Hi Heinrich,
On Sat, 16 Dec 2023 at 14:08, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 12/16/23 19:45, Simon Glass wrote:
Hi Heinrich,
On Sat, 16 Dec 2023 at 07:50, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Hello Simon,
I have built sandbox_defconfig with PREBOOT='host bind 0 ../sct.img'
On the image I have an ESP with file EFI/BOOT/BOOTX64.EFI.
I would expect the sandbox to boot from the ESP.
But when starting the sandbox is does not boot. Instead it shows a menu with some Fedora related entry:
Fedora-Workstation-armhfp-31-1.9 Boot Options. 1: Fedora-Workstation-armhfp-31-1.9 (5.3.7-301.fc31.armv7hl)
This makes absolutely no sense on an x86_64 system. Could you, please, fix sandbox_defconfig to boot according to distroboot.
What sort of 'fix' are you thinking of? You should be able to discover all the options with 'bootflow scan' and then use 'bootflow select' or 'bootflow menu' to choose which one you want.
The Fedora thing is used for testing and development.
I want to autoboot the sandbox without manual intervention. This requires a sane state.
Well, stop doing that :-)
Really, sandbox is for development and CI testing. It is not designed to boot anything automatically.
If that Fedora thingy is only needed in CI, can't we put it into a config segment that only used by the CI scripts and have the sandbox in a generally usable state? Or can we let the Python tests add the otherwise not needed bootflow?
Yes, we could. We have some extra mmc devices which are manually enabled in tests.
But it is handy to be able to try out a distro without doing anything special. I suppose we could add a sandbox command to enable an mmc device in test.dts
If you have ideas / patches that is fine...it's just that I do want to be able to use sandbox for basic development and trying things out.
Regards, Simon