Comment 3 for bug 2011536

I'm a bit challenged with time in reviewing less obvious flash-kernel features as I need to wrap my head around the feature and a possible path to Debian (I can more easily review + sponsor hardware additions to the db)

For this particular feature: my memory is that f-k is mainly supposed to run on hardware as it might flash a mtd device, or write to a raw offset of a block device. It has environment variables to disable itself fully while e.g. generating pre-installed rootfs/images; an installer would then chroot into the newly installed / preinstalled rootfs and then run flash-kernel on the target hardware

While f-k mostly generate files, I don't think flash-kernel is particularly good in the mode of "please ignore the current environment and generate artifacts for the following hardware target without flashing them to non-OS managed locations", perhaps it grew such support recently though. I would expect this to be done with something like FK_FORCE_TARGET_MACHINE or something, and then EFI/chroot/device-tree checks should be ignored and the machine db would be used, except for flashing to real hardware

I'd recommend hashing this out in the devel/tip version of f-k in Ubuntu first, with some thoughts on how it would look in Debian, and then SRU-ing this