compatdir appears to be for things like /usr/lib that have
/usr/lib/eabi as a subdirectory, so for /usr/lib/openssl it would
mean we have /usr/lib/openssl/eabi as a subdirectory. But that's not
what we have; we have /usr/lib/eabi/openssl.
Let's try using NetBSD.dist.compat.in instead, which appears to be
intended for this purpose, from what I can gather.
remove them as explicit part of all arm64 builds when they're only
(currently) used and consumed by llvm builds.
this fixes gcc builds and i don't think it breaks llvm ones though
i'm still waiting for that test.
The default is to execute the script (iscsid_volumes=YES), so if you have
any volumes defined, you should also start iscsid (iscsid=YES) to avoid
error messages.
This time using the updated tools from the net/iana-etc package, ensuring
we don't revert previous changes and pass the tests from tests/lib/libc/net/.
This way they match the mtree and make sense and don't cause editors
to ask to override read-only files when editing them.
Exception: Not sure /etc/bluetooth/protocols makes as much sense to
edit, but the mtree says 644, so if you want to change it, make sure
to change it in both places -- Makefile and mtree.
XXX pullup-8
XXX pullup-9
Previously we would:
1. Install /root/.cshrc and /root/.profile with mode FILESMODE=644 as
requested in src/etc/root/Makefile and as echoed in
/etc/mtree/special.
2. Create hard links at /.cshrc and /.profile through CONFIGLINKS.
3. Because LINKSMODE was unset and defaults to NOBINMODE=444, change
the mode to 444.
This scenario is confusing, and mtree objects to it, which is bad for
warning fatigue in a security-relevant mechanism. (There are also
several other files mtree objects to out of the box -- we should fix
those too.)
With this change we install the links with the same mode as the
original files, in agreement with the mtree. The files, .cshrc and
.profile, are intended to be editable configuration files, so 644
makes sense while 444 makes no sense and gets in the way of editors
like vi.
Discussed on tech-userlevel:
https://mail-index.netbsd.org/tech-userlevel/2022/08/29/msg013498.html
XXX pullup-8
XXX pullup-9
The previous commit introduced the ability to install a set of
bootable images as a normal part of a release build. While this made
it easy to install bootable images, the contents of a release build
depend on whether or not U-Boot packages are installed in /usr/pkgsrc,
which is the default location searched by installboot(8).
This commit requires users to explicitly list the bootable images to
be installed, which by default is none (i.e., prior behavior).
Release builds for arm platforms create compressed images in
${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg. However, in some
cases, e.g., armv7.img.gz, they are not bootable. Consequently, boot
blocks must be manually installed in the images, which is an extra
barrier for testing systems or adopting NetBSD. This has prompted
creation of external repositories, e.g., armbsd.org, to host a
collection of bootable images. However, this does not ease the burden
on developers compiling their own systems; for them, manual
installation of boot blocks is still required.
For arm platforms, etc/etc.evbarm/Makefile.inc contains the commands
used to create system images. Because installboot(8) can write boot
blocks directly to system images, a loop through possible boards can
create a series of bootable images during the normal build process.
In the case of many arm platforms, installboot(8) uses U-Boot boot
blocks, which are not part of the NetBSD source code. Developers can,
however, install as many U-Boot boot blocks as desired, either in the
default location of /usr/pkg/share/u-boot or in a set of directories
pointed to by the U-Boot search path, the INSTALLBOOT_UBOOT_PATHS
environment variable. For each board with an available boot block, a
board-specific bootable image will be created in
${RELEASEDIR}/${RELEASEMACHINEDIR}/binary/gzimg. If a boot block is
not available, which is the typical situation currently, no additional
image will be created.
This facility creates opportunities to build bootable images for any
number of boards within the scope of a standard release build.
However, that is not required and will not occur without the
intervention of installing U-Boot boot blocks prior to the build.
Remove support for building extsrc/:
1. Makefile: remove do-extsrc target.
2. build.sh: remove options -y and -Y extsrcdir.
3. distrib/sets: remove support for extsrc in various tools
including the options -L ext and -y, and the extsrc sets.
4. doc/BUILDING.mdoc: remove docs for extsrc/, EXTSRCSRCDIR, MKEXTSRC (etc)
5. bsd.own.mk and various Makefiles: remove support for extsrc/,
EXTSRCSRCDIR, MKEXTSRC.
As proposed on tech-kern and tech-userlevel on 2022-01-07
and followed up on 2022-08-21.
viocon* at virtio?
/dev/ttyVI??
Tested under qemu with:
qemu-system-aarch64 ... \
-device virtio-serial \
-chardev socket,path=/tmp/ttyVI00,server=on,wait=off,id=ttyVI00 \
-device virtconsole,chardev=ttyVI00,name=org.NetBSD.dev.ttyVI00 \
...
I updated MAKEDEV.conf to create /dev/ttyVI?? on all ports where it
looks likely to work based on:
(a) having pci or a non-pci virtio attachment,
(b) `qemu-system-$ARCH -M ?' mentioned something resembling the port,
and
(c) `qemu-system-$ARCH -device virtio-serial' launched without
complaining about the virtio-serial device.
(Criterion (c) excluded sparc and sparc64.)
Note that realpath can act differently for root than for other users
(where an ordinary user will see EACCESS root just barrels right through).
The tests adapt themselves, when run as root, less error cases can be
tested than when run as some other user.
in /etc/conf/raid/raidN (as well as in /etc/raidN.conf) (less
clutter in /etc).
Allow config files to exist for raids that are autoconfigured (just
skip anything autoconfigured) - this allows a (simplistic) recovery
mechanism if autoconf fails, and makes it simpler to enable/disable
autoconf at will, while keeping the raid working.
While here, add sh quoting where it is needed, and remove it from
where it is pointless.
unless changed by something - and has been since NetBSD 3) don't blindly
simply change it to a PATH that doesn't have /rescue in it at all.
This doesn't solve the "/rescue/tar execs /usr/bin/gzip" problem completely,
as if PATH is in the environment when /rescue/sh is started, that one will
override the shell's built in PATH, but this is better than nothing.
christos