30m isn't enough for pkg anymore to extract packagesite.txz.
40m is fine for now but let's take a safer way as we don't know when pkg will need more.
Reported by: many
Approved by: re (gjb), andrew (mentor)
on performance, especially with SD cards on certain SoCs.
Requested by: trasz
Discussed with: ian, kientzle
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
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
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
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
