This is useful for upgrade and also to make tiny jail so they won't
depend on FreeBSD-utilities (where openssl was packaged before).
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D30081
We do not currently generate armv7 distribution sets, because we don't
build any installer images. However, having such sets available can be
useful for quickly installing a base system, particularly in the case
of creating an armv7 poudriere jail on arm64.
Add a configuration file for the generation of these distribution sets.
Reviewed by: manu, imp, gjb
MFC after: 3 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D29923
The mangling was present in the initial revision of the script, but its
purpose is not clear. It may have been to avoid defining make(1)
variables with a dash in the name, but this is permitted. Furthermore,
it results in invalid dependency information if a dependency's name
contains an underscore, causing e.g., libcompiler_rt-dev to depend on
libcompiler-rt, and resulting in warnings when installing base system
packages. Remove the mangling.
Reviewed by: manu
MFC after: 2 months
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29883
To support -DNO_ROOT work. The top-level installworld target creates a
new METALOG starting with `#mtree 2.0` so it needs to be first, to avoid
overwriting installkernel METALOG entries.
Reviewed by: gjb
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D29582
make "vital" a replaceable, which defaults to "false" and only set it for
the main clib, utilities and runtime packages, not their sub-packages
PR: 254174
Differential Revision: https://reviews.freebsd.org/D29224
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
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
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
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
Man pages can be big in total, add an options to split man pages
in -man packages so we produce smaller packages.
This is useful for small jails or mfsroot produced of pkgbase.
The option is off by default.
Reviewed by: bapt, Mina Galić <me@igalic.co>
Differential Revision: https://reviews.freebsd.org/D29169
MFC after: 2 weeks
They aren't needed and produce wrong package comments :
We use to have "runtime-dev package" instead of
"FreeBSD Base System (Development Files)" for example
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D29168
MFC after: 2 weeks
Pass UNAME_r override to make(1) for ports builds when building
ports for another branch.
MFC after: 3 days
MFC with: 0be274d373, 80ab50e1de, c883b6fd8c
Sponsored by: Rubicon Communications, LLC ("Netgate")
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.
MFC with: 1ca8842f3a
Submitted by: ehem_freebsd_m5p.com (original)
Differential Review: https://reviews.freebsd.org/D28979
Sponsored by: Rubicon Communications, LLC ("Netgate")
This had prevented the bootconfig step from determining if an ESP exists,
resulting in its unconditional setup. On BIOS-booted amd64, this wasn't
harmful, just unnecessary, but it resulted in failed installations on
non-EFI-supporting platforms like powerpc64.
MFC after: 3 days
In followup to 80ab50e1de,
export UNAME_r in Makefile.inc1 instead of Makefile.vm.
MFC after: 3 days
MFC with: 80ab50e1de
Sponsored by: Rubicon Communications, LLC ("Netgate")
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
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
Following 7b1d1a1658, the structure
for the reldoc target has significantly changed as result of the
ASCIIDoctor/Hugo migration. As the release notes related files
on the installation medium are inherently out of date, purge them
entirely.
Discussed within: re, doceng
No objection: re (silence), doceng (silence)
Timeout: 2 weeks
MFC after: 1 week
MFC to: stable/13, stable/12, and stable/11 only
Sponsored by: Rubicon Communications, LLC ("Netgate")
Add PBUILD_FLAGS and UNAME_r overrides to extra_chroot_setup()
to fix building ports for 14-CURRENT builds on 13.x.
MFC after: 3 days
MFC with: c511a5ab53
Sponsored by: Rubicon Communications, LLC ("Netgate")
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.
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC ("Netgate")
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
