This option was previously not available and required postprocessing of a `tar-kernel-initrd` output.
Comparison with `iso-efi`:
`iso-efi` only loads the kernel at boot, and the root filesystem is mounted from the actual boot media (eg, a CD-ROM - physical or emulated). This can often cause trouble (it has for us) for multiple reasons:
- the linuxkit kernel might not have the correct drivers built-in for the hardware (see #3154)
- especially with virtual or emulated CD-ROMs, performance can be abysmal: we saw the case where the server IPMI allowed using a ISO stored in AWS S3 over HTTP...you can imagine what happens when you start doing random I/O on the root fs in that case.
- The ISO image has the root device name baked in (ie, `/dev/sr0`) which fails if for some reason the CD-ROM we're running from doesn't end up using that device, so manual tweaking is required (see #2375)
`iso-efi-initrd`, on the other hand, packs the root filesystem as an initramfs (ie similar to what the raw output does, except that in this case we're preparing an ISO image), so both the kernel and the initramfs are loaded in memory by the boot loader and, once running, we don't need to worry about root devices or kernel drivers (and the speed is good, as everything runs in RAM).
Also, the generated ISO can be copied verbatim (eg with `dd`) onto a USB media and it still works.
Finally, the image size is much smaller compared to `iso-efi`.
IMHO, `iso-efi-initrd` could be used almost anywhere `iso-efi` would be used, or might even supersede it. I can't think of a scenario where one might explicitly want to use `iso-efi`.
Points to consider:
- Not tested under aarch64 as I don't have access to that arch. If the automated CI tests also test that, then it should be fine.
- I'm not sure what to put inside `images.yaml` for the `iso-efi-initrd` image. As it is it works of course (my personal image on docker hub), but I guess it'll have to be some more "official" image. However, that cannot be until this PR is merged, so it's kind of a chicken and egg situation. Please advise.
- I can look into adding the corresponding `iso-bios-initrd` builder if there is interest.
Signed-off-by: Davide Brini <waldner@katamail.com>
In alpine version 3.12, the open-vm-tools package got split into new
smaller sub-packages. The implication of this is that features such as
reporting of hostname and ip address to vCenter stopped working.
Signed-off-by: Edvin Eriksson <edvin.erikson@leovegas.com>
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
This commit removes Notary and Content Trust.
Notary v1 is due to be replaced with Notary v2 soon.
There is no clean migration path from one to the other.
For now, this removes all signing from LinuxKit.
We will look to add this back once a new Notary alternative
becomes available.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
- Disable the devmapper snapshotter. We are not using it
- Cherry-pick and upstream commit to be able to disable
the devmapper integration tests
Signed-off-by: Rolf Neugebauer <rn@rneugeba.io>
This commit removes the container backend for QEMU.
QEMU and it's tools are available on all platforms.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
U-Boot sets the variable fdtfile to the correct file name for the
detected hardware revision. Use this in the boot script to load either
the 3-b or 3-b-plus DTB
Signed-off-by: Richard Connon <richard@connon.me.uk>
Update the u-boot image included in the mkimage-rpi3 image to support
detecting newer hardware versions and setting the fdtfile variable
accordingly
Shallow clone the u-boot repository during docker build to improve build
efficiency
Signed-off-by: Richard Connon <richard@connon.me.uk>
Update Raspberry Pi firmware used in mkimage-rpi3 to the latest stable
version to support newer hardware models such as the 3B+
Signed-off-by: Richard Connon <richard@connon.me.uk>
With the current firmware being pulled for the RPi3, recent revisions of
the RPi hardware, such as the 3 B+ will fail to boot.
The issue is exhibited as when RPi 3 B+ receives power and attempts to
boot, the power LED will turn off and the ACT LED will flash 8 times.
According to elinux.org troubleshooting guide[0] this correlates to an
SDRAM initialisation error that can be fixed by updating the firmware.
After updating this firmware the power light stays on, and UBoot can be
seen booting.
[0] - https://elinux.org/R-Pi_Troubleshooting#Green_LED_blinks_in_a_specific_pattern
Signed-off-by: Sachi King <nakato@nakato.io>
