It seems to be incompatible with the OVMF.fd (of unknown provenance)
in use by the Cirrus-CI config. We will soon have a known OVMF build
via a port/package (see review D19869) and we can switch back to q35
once packages are available.
Discussed with: bcran
Update ci-qemu-test.sh
o Update the path to the OVMF file, which is now in /usr/local/share/uefi-edk2-qemu.
o Use the more modern q35, pc-q35-3.0 (Q35 + ICH9, 2009) QEMU machine
instead of the default, obsolete pc, pc-i440fx-3.0 (i440FX + PIIX, 1996).
For example this adds ACPI support.
o Specify the system firmware using the newer pflash drive syntax instead
of bios.
o Remove extra, unneeded devices by passing -nodefaults.
o Change text to talk about 'firmware' instead of 'bios', since UEFI
isn't a BIOS.
Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D20074
ufs partition as p2, and put the zfs partition at p3, to test the ability
of the zfs probe code to find a zfs pool on something other than the first
partition.
tools/boot/install-boot.sh was assuming that if a device was passed in,
it should operate on the current system and run efibootmgr etc. to
update the boot manager. However, rootgen.sh passes a md(4) device and
not a fixed disk.
Add a -u option to install-boot.sh to tell it to update the system
in-place and run efibootmgr etc.
Also, source install-boot.sh in rootgen.sh to allow it to find and
call make_esp_file etc. And pass the loader file to make_esp_file instead
of a directory name.
Reported by: ian
Reviewed by: ian,imp,tsoome
Differential Revision: https://reviews.freebsd.org/D19992
See r346250 and followup commits and mailing list discussion.
We currently fail to boot properly in the absense of boot-time entropy.
Sponsored by: The FreeBSD Foundation
the temporary image in $TMPDIR.
Allow the script to be run from the src/tools/boot directory by using make
-V SRCTOP to find the top of the tree, because this script is handy for
quick smoke-testing of loader changes, as well as being useful in CI testing.
Also, use a temp directory in $TMPDIR to assemble the boot image, and write
the boot log file to $TMPDIR. Arrange to have the temporary image clean
itself up, but leave the log file in $TMPDIR for post-mortem analysis of
failures when the script is run interactively.
Differential Revision: https://reviews.freebsd.org/D19876
Currently, the installer uses pre-created 800KB FAT12 filesystems that
it dd's onto the ESP partition.
This changeset improves that by having the installer generate a FAT32
filesystem directly onto the ESP using newfs_msdos and then copying
loader.efi into /EFI/freebsd.
For live installs it then runs efibootmgr to add a FreeBSD boot entry
in the BIOS.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D17947
Use userboot.so from the test directory if possible, fall back to .OBJDIR.
This avoids a problem that we've had since userboot coexistence was added,
where userboot.so alone no longer exists in the .OBJDIR but is instead just
a link installed later.
This is purely to make it easier to tweak them locally; the machine I have
for testing takes forever to do 50,000 pw strengthening iterations, and
we're not testing the strength of geli's anti-pw-guessing logic here
(especially given that our test passphrase is "passphrase", except that
I tend to tweak that also, to 'x', because typing is hard).
Some day these should be settable as cmdline args. But then, some day this
whole script should probably get a rewrite. :)
Cope for the fact that laoder.efi, not being boot1, doesn't read
/boot.config by setting boot_serial and force the serial console.
Also add sysctl so we can display the boot method.
Provide a variable, do_boot1_efi, if you want to use boot1 for
testing. But since it's transient, it's just a variable and not
available on the command line.
This extends the test suite to generate images for every combination of:
amd64: mbr/gpt geli/nogeli ufs/zfs legacy/uefi/both
Except for mbr+geli, which is not currently possible.
Reviewed by: imp (previous version)
Sponsored by: Klara Systems
Differential Revision: https://reviews.freebsd.org/D15846
128MiB still works for Legacy booting, however. Go ahead and do 256MiB
for all amd64 boxes, since the number of such boxes < 256MiB is
vanishingly small.
We want to use the versions of the bootcode we just built, rather than
ones from whatever happens to be in /boot on the test machine
These were incorrectly added by me in r334888
We require some --globals due to custom loader extensions in our
environment. Add everything required for this to tools/boot so that other
interested parties can get up and go with linting our scripts and not get a
bunch of false-positives.
Print a qemu line to a shell script to ease testing each image
Start to support multiple architectures (still very green)
Create /etc/rc that echos success and halts the system for better
automation (also include halt)
Create /etc/fstab on a per-boot type to test loader's passing root
to kernel.
This lets me run a test, connect to it with telnet and get either a
timeout, or a report of success.
Sponsored by: Netflix
interactive console rather than the video port. qemu has issues with X
on my mac at the moment and this is the easiest path forward.
Sponsored by: Netflix
