truncate(1) is not case-sensitive with regard to setting the size
of a file. makefs(8), however, does not honor upper-case values.
Update release-specific files and the release(7) manual page to
reflect this.
Submitted by: ehem_freebsd_m5p.com (original)
Differential Review: https://reviews.freebsd.org/D28979
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit fa04db4762)
Sync determining the git count with newvers.sh by adding the
--first-parent argument. This ensures uname(1) reflects the
file name for snapshots.
Reported by: Mark Millard
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit e5c6913a8d)
Using makefs instead reduces the privileges needed to build VM images,
simplifies the script (no need to copy files to a fresh image at the end),
and improves portability by allowing generation of cross-endian images.
As a result of the last, this patch also adds support for generation of
powerpc64 and powerpc64le VM images.
No other changes to the output. Tested and working for both amd64 and
powerpc64 targets.
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D28912
(cherry picked from commit 1ca8842f3a)
These images only ever worked on Apple Powermacs, which are now a very
old platform, and did so only for a very loose definition of "worked"
(they booted on a small subset of supported machines). Moreover, all
the machines they *did* boot on also would boot from a memstick made
by dd'ing an CD image to a flash drive. Since a flash drive prepared
in this way would also boot all the newer systems we support, the
memstick images were strictly less functional than the CD images, even
for booting from memory sticks.
Reviewed by: jhibbits
MFC after: 1 week
(cherry picked from commit 1af48800c2)
Remove tmpfs size limitation, this breaks make installworld and installation of some packages
Format generated fstab using tabs to make it consistent and readable
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D29283
(cherry picked from commit 5bffdafd6c)
Recent mkimg changes forces to have partitions given in explicit order.
This is so we can have the first partition starting at a specific offset
and the next ones starting after without having to specify an offset.
Switch the partition in the mkisoimage.sh script so the first one created
is the isoboot one.
PR: 254490
Reported by: Michael Dexter <editor@callfortesting.org
Tested by: Vincent Milum Jr <freebsd@darkain.com>
MFC after: Right now
(cherry picked from commit 90d2f7c413)
images.
Per hier(7), the ESP will be mounted at /boot/efi. On UFS systems,
any existing ESP will be reused and mounted there; otherwise, a new one
will be made. On ZFS systems, space for an ESP is allocated on all disks
in the root pool, but only the partition actually used to boot is set up
and mounted.
This makes future upgrades of the EFI loader easier (upgrade scripts can
just change /boot/efi) and also greatly simplifies the parts of the
installer involved in initialization of the ESP. It also makes the
installer's behavior correspond to the documentation in hier(7).
Reviewed by: imp, tsoome, bdragon
Approved by: re (gjb)
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D28897
(cherry picked from commit 0b7472b3d8)
(cherry picked from commit 2c26d77d98)
(cherry picked from commit e77cf2a4ab)
(cherry picked from commit e70eb40271)
release.sh: fix OSVERSION and UNAME_r overrides
Add PBUILD_FLAGS and UNAME_r overrides to extra_chroot_setup()
to fix building ports for 14-CURRENT builds on 13.x.
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit c511a5ab53)
(cherry picked from commit 6462113b70)
The 'reldoc' target includes release-related documentation on
installation medium. Since the switch from XML to ASCIIDoctor,
the file locations have moved, and it will take some time to sort
out how this target should work now.
Sponsored by: Rubicon Communications, LLC ("Netgate")
(cherry picked from commit 7b1d1a1658)
The ports tree is scheduled to be converted from Subversion to Git
after the currently-scheduled 13.0-RELEASE, so the source of truth
will be Subversion for the ports tree.
Implement a hack specifically for this case.
Sponsored by: Rubicon Communications, LLC (netgate.com)
Hard-code the GITROOT for the ports tree to use cgit-beta
until the ports repository is converted.
While here, remove $FreeBSD$ RCS IDs.
Sponsored by: Rubicon Communications, LLC (netgate.com)
We now have a u-boot port and config.txt for booting on all 64bits
variant of the RPI boards (RPI2v1.1, RPI3* and RPI4*) so use
the new u-boot-rpi-arm64 and the config_arm64.txt files.
Discussed with: karels, kevans
For platforms that don't have any of the memstick, cdrom, or dvdrom
release images (i.e. riscv64), the release-install target will trip up
when invoking md5(1) on the non-existent image files. Skipping this
allows the install to complete successfully.
Add two release flavors for RISC-V. First, the traditional "big-iron"
images, capable of generating distribution sets and VM images. Installer
images won't be built yet, but can be trivially enabled in the future
with the addition of riscv/make-memstick.sh.
Second, a GENERICSD embedded image. I've opted for this instead of
board-specific SD card images as it allows users to just dd the u-boot
they want. The RISC-V hardware ecosystem is still young, so a
configuration for e.g. the new PolarFire SoC Icicle Kit would likely see
very few users.
Reviewed by: gjb
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27045
RISC-V has the same booting requirements as arm64 (loader.efi, no legacy
boot options), so generated images for both architectures have the same
partition layout.
Reviewed by: gjb
Differential Revision: https://reviews.freebsd.org/D27044
Since the few existing RISC-V hardware platforms are single board
computers, we can piggyback off of arm/arm64's embedded build support
for generating SD card images.
I don't see a pressing need to change the naming in this file at this
time.
Reviewed by: gjb, manu
Differential Revision: https://reviews.freebsd.org/D27043
Both RPI2 and BEAGLEBONE are still popular and used arm boards.
Both u-boots can coexist as they are named differently and live in the
fat partition.
This leave us with only one image that can be used for both of those
boards and all the other ones supported by FreeBSD provided that you
install the correct u-boot on it.
Reviewed by: imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27283
All those board are impossible to buy nowadays and could boot using the
GENERICSD image after putting the correct u-boot on them.
Reviewed by: imp
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27282
Allwinner bootrom have an alternate location for u-boot at 128k.
Work was made recently in u-boot to relocate correctly if loaded from
there.
The advantage of this offset is that we can now use a GPT scheme.
A lot of projects CI can't do FreeBSD tests currently.
The main reason is that the project CI infrastructure is runned on Linux
and that our images aren't modifiable from a Linux hosts.
Add a basic image specific for this case (called BASIC-CI for a lack of a
better name).
The image have no package pre-installed.
It only have a few modification to have dhcp client runned on the default
interface and sshd started with option to be able to log on without a password
as root.
Sponsored by: The FreeBSD Foundation
Reviewed by: re (gjb@)
Differential Revision: https://reviews.freebsd.org/D25598
We create a UFS root filesystem using makefs(8), and later pass it to
mkimg(1) when creating the final image. The correct partition type is
freebsd-ufs; the freebsd parition type is for partitions containing a
BSD disklabel.
Reviewed by: emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26987
These images were switched to MBR in r281876 as a way to cope with a
hard-coded partition GUID in QEMU's default EFI firmware. Enough time
has passed that this is no longer a problem; QEMU versions >= 4.0
include a copy of edk2 EFI firmware that can detect the root filesystem
properly. Alternatively, sysutils/u-boot-qemu-arm64 can be used.
Switch back to building these images with a GPT partition table, and
re-enable the swap partition.
Reviewed by: gjb, emaste
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26986
The return code of write_partition_layout() doesn't bubble up, so an
invocation of make vm-release for an incorrect/unsupported target will
appear to succeed while make vm-install will fail due to missing
files. This isn't a common point of failure, but is worth handling
properly.
Upgrade this case to print a message to stderr, and exit in place. This
is okay to do since at this point in the execution of mk-vmimage.sh,
cleanup() has already been run.
Reviewed by: gjb
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D26985
De-duplicate the invocation of mkimg(1). No functional change.
Reviewed by: gjb
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26984
At some poing over the last week, the bootx64.efi file has grown
past the 800KB threshold, resulting in being unable to copy it to
the EFI/BOOT directory.
# stat -f %z efiboot.znWo7m
819200
# stat -f %z stand-test.PIEugN/EFI/BOOT/bootx64.efi
842752
The comment in the script that creates the ISOs suggests that 800KB
is the maximum allowed for the boot code, however I was able to
boot an ISO with a 1024KB boot partition. Additionally, I verified
against an ISO from OtherOS, where the boot EFI partition is 2.4MB.
Sponsored by: Rubicon Communications, LLC (netgate.com)
This was originally part of the initial commit, but after discussion in
D26399, I split it out into its own commit after the kernel config file.
Sponsored by: Tag1 Consulting, Inc.
Some IPMI implementations on arm64 are reportedly unable to load our
memstick installer images, but support the older ISO format. Start
generating these for arm64.
Unlike installer ISOs for other platforms, these images are UEFI-only.
Reviewed by: emaste
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D26452
Everywhere else we use objects ("scripts", generally) we do sepcify the
optional colon. Be consistent and do the same for directories.
PR: 249273
Submitted by: Martin <martin.jakob gmx com>
MFC after: 1 week
Prior to this commit, EC2 AMIs used a "dual-dhclient" tool which was
launched in place of dhclient and spawned both the base system dhclient
for IPv4 and the ISC dhclient from ports for IPv6.
Now that rtsold supports the "M bit" (managed configuration), we can go
back to having the base system dhclient spawned normally, and provide a
script to rtsold which spawns the ISC dhclient from ports when rtsold
decides that it is appropriate.
Thanks to: bz
MFC after: 1 week
Sponsored by: https://www.patreon.com/cperciva
The FreeBSD base system continues to expand. 4GB is now insufficient;
we passed 3 GB in May 2019; we passed 2 GB in August 2017. Over half
of the disk space used is in /usr/lib/debug/.
Without this change, instances boot but are unusable, since the first
thing which breaks when VM filesystems are too small is the "pkg install"
in the VM building process.
