A stray trailing space snuck in with one of the recent
changes, making r290550 and r290573 effectively no-op.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
issues on some EC2 instance types. Users may want to experiment with
removing this from loader.conf and measuring the performance impact on
the EC2 instances they are using.
- pkg(8) cannot be removed before subsequent reinvocations
- The PKG_CACHEDIR cannot be cleaned after the repo*.sqlite
has been removed
- pkg(8) cannot be removed as a precursor to any of the other
steps involved here
MFC after: 3 days
X-MFC-With: r285722
X-MFC-Before: 10.2-{BETA3,RC1} (whichever happens next)
Sponsored by: The FreeBSD Foundation
The true cause of the missing UFS/MSDOSFS labels has been
identified, and only affects stable/10 at the moment.
An request for commit to stable/10 will be pending RE approval
after this commit.
MFC after: 1 day
X-MFC-Note: never
X-MFC-Never: r285018, r285019, r285076, r285078, r285082
Sponsored by: The FreeBSD Foundation
the symlink from loader.rc.sample.
Fix paths relative to the CHROOTDIR.
MFC after: 3 days
X-MFC-With: r285076, r285078
X-MFC-Before: 10.2-BETA1
Sponsored by: The FreeBSD Foundation
UFS/MSDOSFS label issues on FreeBSD/arm builds, however
the real problem was addressed in r285076, which is due
to two separate issues, unrelated to md(4) stale device
existence.
MFC after: 3 days
X-MFC-With: r285076
X-MFC-Before: 10.2-BETA1
Sponsored by: The FreeBSD Foundation
FreeBSD/arm builds. The problem stems from the loader.rc file
not existing, as well as geom_label not being loaded at boot.
For now, add the geom_label_load entry to loader.conf, and
symlink loader.rc.sample to loader.rc, both of which allowed
my BeagleBone Black to boot fine with a UFS label reference in
fstab(5).
MFC after: 3 days
X-MFC-Before: 10.2-BETA1
Sponsored by: The FreeBSD Foundation
cannot possibly exist within the chroot(8) before the target
filesystem actually exists.
MFC after: 3 days
X-MFC-With: r285018
Sponsored by: The FreeBSD Foundation
written to disk with newfs(8) and newfs_msdosfs(8).
When iterating through snapshot builds in serial, it is possible for
a build failure to leave stale md(4) devices behind, in some cases, they
could have a UFS or MSDOS filesystem label assigned.
If the md(4) is not destroyed (or not able to be destroyed, as has
happened recently due to my own fault), the filesystem label that
already exists can interfere with a new md(4) device that is targeted to
have the same label.
This behavior, although admittedly a logic error in the wrapper build
scripts, has caused intermittent reports (in particular with the armv6
builds) of missing UFS/MSDOSFS labels, causing the image to fallback to
the mountroot prompt. This appears to only happen when the backing
md(4) device is destroyed before the calling umount(8) on the target
mount, after which the UFS/MSDOSFS label persists.
The workaround is this: If EVERYTHINGISFINE is set to non-empty value,
check for an existing ufs/rootfs and msdosfs/MSDOSBOOT filesystem label
in arm_create_disk(), and rm(1) them if they exist.
The EVERYTHINGISFINE variable is chosen because it is used in exactly
one other place - release/Makefile.mirrors - and there are big scary
warnings at the top of that file as well that it should *not* be used
under normal circumstances. This should not destroy a build machine
that also uses '/dev/ufs/rootfs' as the UFS label, and I have verified
in extensive local testing that the destroyed label is recreated when
the md(4) is unmounted/mounted, but this really should not be enabled
by anyone.
Having said all that, I absolutely *do* plan MFC this to stable/10 for
the 10.2-RELEASE cycle, as so far, I have only observed this behavior
on stable/10, but this is a temporary solution until I can unravel all
of the failure paths to properly trap them.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
machine images to the Google Compute Engine platform.
By default, gcutil/gsutil requires an Oauth2 login generated
from a URL that must be opened in a browser, a verification
code copied back to the terminal from which it was invoked,
etc., etc., making it near impossible for automation.
I've hacked together an evil solution to work around this,
so unless GCE_LOGIN_SKIP is set to a non-empty value, this
Makefile will not do anything useful.
As a result of this commit, remove the gce-package.sh script
that was never, nor will ever be, used.
MFC after: 3 days
X-MFC-Note: (hopefully)
Sponsored by: The FreeBSD Foundation
Remove the Azure-local vm_extra_create_disk(), since we no longer
need qemu-img to convert the final VHD image to an Azure-compatible
format.
Although the waagent utility is installed from ports, create the
symlink to /usr/sbin, pending investigation on where this is
hard-coded, so it can be reported upstream. In the meantime, this
is good enough.
MFC after: 3 days
X-MFC-Needs: r284269, r284270, r284271, r284655,
r284656, r284657, r284658, r284659
X-MFC-Note: Required for 10.2-RELEASE, marcel@ has
implicit approval for the required changes
Sponsored by: The FreeBSD Foundation
According to the manual page, '-m' should create the user home
directory, however rigorous testing suggests it does not, and
it is unclear if this is an implementation or expectation issue.
Sponsored by: The FreeBSD Foundation
Disabling soft updates journaling appears to resolve issues
with kernel panics, and may also be generally bad to have
enabled for SD cards.
Requested by: ian
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
pw(8) to set the correct /etc directory for the user/group
files.
Provided by: ian (thanks!)
MFC after: 3 days
X-MFC-with: r283894
Sponsored by: The FreeBSD Foundation
user in the userland for the target image, but creates the
user in the build chroot.
Before this is re-enabled, I want to figure out a clean way
to do this without requiring the overhead of third-party
utilities (such as qemu).
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Of note:
- This commit adds native FreeBSD/arm release build support without
requiring out-of-tree utilities.
- Part of this merge removes the WANDBOARD-{SOLO,DUAL,QUAD} kernel
configuration files, for which the IMX6 kernel configuration file
should be used instead.
- The resulting images have a 'freebsd' user (password 'freebsd'),
to allow ssh(1) access when console access is not available (VGA
or serial). The default 'root' user password is set to 'root'.
- The /etc/ttys file for arm images now enable both ttyv0 and ttyu0
by default.
Help from: many (boot testing, feedback, etc.)
Sponsored by: The FreeBSD Foundation
is necessary.
In arm_install_base(), chroot(8) when installing world
and kernel. Fix paths for fstab(5) and rc.conf(5).
Sponsored by: The FreeBSD Foundation
before attempting to mount(8) devfs. Also, create the
.OBJDIR for the 'release' target, so files end up in the
correct location.
In tools/arm.subr, fix the target device when creating the
gpart partition scheme.
Sponsored by: The FreeBSD Foundation
building arm images. This is similar to tools/vmimage.subr
used for building virtual machine disk images. By default,
only arm_create_disk() and arm_install_base() contain real
functionality here, and arm_install_uboot() must be overridden
in the arm/KERNEL.conf file.
In release.sh, make create_arm_armv6_build_release() do
something now.
In arm/BEAGLEBONE.conf, set IMAGE_SIZE, PART_SCHEME, FAT_SIZE,
FAT_TYPE, and MD_ARGS, as well as make arm_install_uboot()
functional.
Parts of this were taken from disecting a previous BEAGLEBONE
image, and other parts obtained from Crochet sources.
Sponsored by: The FreeBSD Foundation
sysutils/u-boot-beaglebone port:
- In arm/BEAGLEBONE.conf, set EMBEDDEDPORTS to the
sysutils/u-boot-beaglebone port.
- In arm/release.sh, remove BEAGLEBONE from setting WANT_UBOOT
- In tools/arm/crochet-BEAGLEBONE.conf, override the
beaglebone_check_uboot(), and set BEAGLEBONE_UBOOT to
/tmp/external/u-boot-beaglebone, and create symlinks to the
u-boot files in /usr/local/share/u-boot-beaglebone and the
uEnv.txt file in crochet/board/Beaglebone/files.
Sponsored by: The FreeBSD Foundation
In release.sh, allow overriding buildenv_setup() before
the handoff to arm/release.sh.
Copy arm/RPI-B.conf -> arm/RPI2.conf, set UBOOT_PORT and
the correct KERNEL, and add the buildenv_setup() override
to install the sysutils/u-boot-rpi2 port/package.
Copy tools/arm/crochet-RPI-B.conf -> tools/arm/crochet-RPI2.conf,
and set the correct entries for the RaspberryPi2 board.
Thanks to: loos@
Sponsored by: The FreeBSD Foundation
GPT scheme. UEFI needs to know the unique partition GUID
with GPT, which changes each time. Specifically, the QEMU
EFI BIOS file has this hard-coded.[1]
Since the GPT labels are now unavailable, unconditionally
label the root filesystem as 'rootfs' with newfs(8), since
it does not hurt anything anywhere else. For the arm64 case,
'/' is mounted from /dev/ufs/rootfs; for all other VM images,
'/' is mounted from /dev/gpt/rootfs.
Unfortunately, since the /dev/gpt/swapfs label is also lost,
set NOSWAP=1 for the arm64/aarch64 images. This is temporary,
until I figure out a scalable solution to this. But, a certain
piece of softare was written "very fast", and ended up living
for 15 years. We can deal with this for a week or so.
Information from: andrew, emaste [1]
Sponsored by: The FreeBSD Foundation
copy the userland from one md(4)-mounted filesystem to a clean
filesystem to prevent remnants of files that were added and
removed from resulting in an unclean filesystem. When newfs(8)
creates the first filesystem with journaled soft-updates enabled,
the /.sujournal file in the new filesystem cannot be overwritten
by the /.sujournal in the original filesystem.
To avoid this particular error case, do not enable journaled
soft-updates when creating the md(4)-backed filesystems, and
instead use tunefs(8) to enable journaled soft-updates after
the new filesystem is populated in vm_copy_base().
While here, fix a long standing bug where the build environment
/boot files were used by mkimg(1) when creating the VM disk
images by using the files in .OBJDIR.
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
* Remove vm_umount_base function which is currently unused.
* Add umount_loop function which loops attempting to unmount one filesystem.
* Replace calls to umount with calls to umount_loop.
* Don't attempt to unmount ${DESTDIR}/dev if it isn't mounted.
The looping is necessary because sometimes umount fails due to filesystems
being busy. The most common cause of such busyness is periodic(8) jobs
running `find / ...`.
Reviewed by: gjb
