I tried to make it before 15.1-RC2, but I couldn't. Probably a good candidate for errata.

Also, note that PARTITIONS is not used in any other script, so there is no need to export (there has never been the need to export it either).

Hmm, I was about to submit a change that:

The files /boot/boot0 and /boot/boot0sio have 0444 permissions. chmod before when building unprivileged.

• Add more checks

Sorry for not testing this thoroughly, I just realized that in order for DISTRIBUTIONS to work, the variable must be exported (see inline). Otherwise the user should "manually" export it. If this is going to be the case, then the manual page should be updated to include export DISTRIBUTIONS in the example.

In D57311#1313282, @imp wrote:

boot0cfg ${NANO_BOOT0CFG} ${NANO_WORLDDIR}/${NANO_BOOTLOADER} doesn't look right. The only bare arg to boot0cfg is the disk, right?

I did this modification, mostly to allow using it in conjunction with mkimg (see the next review in the series). I cannot immediately see any downsides of also enabling a file for modification, I also didn't know whom to ask for a review, as boot0cfg's usage is slowly fading away.

OK, thank you! Let's not go the tar route.

In D57218#1311215, @imp wrote:

So minfree=1 or =2 will avoid n^2 behavior in block allocations. If it's a read-only image, then that doesn't matter, but if the final image does a lot of that minfree=0 could be a problem and at least needs an note somewhere.

In D57042#1312009, @senguptaangshuman17_gmail.com wrote:

_.cs8 MBDownload

In D57218#1311215, @imp wrote:

So minfree=1 or =2 will avoid n^2 behavior in block allocations. If it's a read-only image, then that doesn't matter, but if the final image does a lot of that minfree=0 could be a problem and at least needs an note somewhere.

In D57221#1311207, @imp wrote:

With the proviso that track boundaries are almost useless today, even for MBR which once upon a time was tied to track boundaries.

In D57220#1311210, @imp wrote:

ok, but maybe 16 is better encoded as a variable name.

Finally I was able to "unveil" the mystery of makefs' partition alignment. This was the actual issue: the -t ffs option should appear before the -o option. In my brief testing, I was finally able to produce an image that is partitioned exactly as the root-built one, doing it as an unprivileged user. While at it, I also fixed a number of other tangentially-related issues regarding non-privileged builds on NanoBSD (the rest of the stack). As well as preparing the ground for some changes that are yet to come as part of the GSoC project.

After testing this patch during this week's NanoBSD call, it worked, but it is still slow during populate_slice because it writes to the disk. @senguptaangshuman17_gmail.com would you mind also applying this patch:

--- a/tools/tools/nanobsd/defaults.sh
+++ b/tools/tools/nanobsd/defaults.sh
@@ -739,7 +739,8 @@ populate_slice() {
        if [ -n "${dir}" -a -d "${dir}" ]; then
                echo "Populating ${lbl} from ${dir}"
                cd "${dir}"
-               find . -print | grep -Ev '/(CVS|\.svn|\.hg|\.git)/' | cpio ${CPIO_SYMLINK} -dumpv ${mnt}
+               find . -print | grep -Ev '/(CVS|\.svn|\.hg|\.git)/' |
+                   tar -cf - -T - | tar -xpvf - -C ${mnt}
        fi
        df -i ${mnt}
        nano_umount ${mnt}

Instead of using cpio, we use tar to streamline the entire copy operation; by streaming the files into a single continuous sequential write, we allow the operating system's write caching to work much more efficiently.
Please let me know if this works, so I can clean up this patch (and test the previous one).

In D56773#1309695, @zarychtam_plan-b.pwste.edu.pl wrote:

To be honest, I really doubt it was the intention to have the RFC 1918 address block in this example. You should ask Christos about it. An excellent pool for documentation and examples is one of the RFC 5737 blocks, for example, 192.0.2.0/24.

Although NetBSD is no longer a direct upstream for makefs(8), an equivalent patch was submitted to NetBSD first, to avoid introducing unnecessary differences between the two code bases (GNATS bin/60285).

In D57096#1308375, @dave_freedave.net wrote:

I think you have a race and will need to introduce locking or find a clever use of atomics for vofid->v_opens.

Address sugesstions:

• Rebase
• Bump date

Yes, this is much better. A "permanent" fix.
It has bitten us before (D49739#1134004).
Thank you!

Upstream has already applied the patch.

The equivalent fix has been reported upstream as: bin/60270 (GNATS)

Looks good.
I get an extra diff after freebsd-configure.sh and freebsd-namespace.sh:

diff --git a/crypto/openssh/krb5_config.h b/crypto/openssh/krb5_config.h
index d95deef0b087..21fde75751e9 100644
--- a/crypto/openssh/krb5_config.h
+++ b/crypto/openssh/krb5_config.h
@@ -1,5 +1,14 @@
+#define ENABLE_SK_INTERNAL /**/
 #define GSSAPI 1
 #define HAVE_DECL_GSS_C_NT_HOSTBASED_SERVICE 1
+#define HAVE_FIDO_ASSERT_SET_CLIENTDATA 1
+#define HAVE_FIDO_CRED_PROT 1
+#define HAVE_FIDO_CRED_SET_CLIENTDATA 1
+#define HAVE_FIDO_CRED_SET_PROT 1
+#define HAVE_FIDO_DEV_GET_TOUCH_BEGIN 1
+#define HAVE_FIDO_DEV_GET_TOUCH_STATUS 1
+#define HAVE_FIDO_DEV_IS_WINHELLO 1
+#define HAVE_FIDO_DEV_SUPPORTS_CRED_PROT 1
 #define HAVE_GSSAPI_GSSAPI_GENERIC_H 1
 #define HAVE_GSSAPI_GSSAPI_H 1
 #define HAVE_GSSAPI_GSSAPI_KRB5_H 1
diff --git a/crypto/openssh/ssh_namespace.h b/crypto/openssh/ssh_namespace.h
index 71b53d286dbf..c18171ba7807 100644
--- a/crypto/openssh/ssh_namespace.h
+++ b/crypto/openssh/ssh_namespace.h
@@ -399,6 +399,7 @@
 #define libcrux_ml_kem_ntt_ntt_at_layer_4_plus_ea Fssh_libcrux_ml_kem_ntt_ntt_at_layer_4_plus_ea
 #define libcrux_ml_kem_polynomial_ntt_multiply_d6_ea Fssh_libcrux_ml_kem_polynomial_ntt_multiply_d6_ea
 #define libcrux_ml_kem_polynomial_poly_barrett_reduce_d6_ea Fssh_libcrux_ml_kem_polynomial_poly_barrett_reduce_d6_ea
+#define libcrux_ml_kem_sampling_sample_from_binomial_distribution_a0 Fssh_libcrux_ml_kem_sampling_sample_from_binomial_distribution_a0
 #define libcrux_ml_kem_serialize_deserialize_ring_elements_reduced_1b Fssh_libcrux_ml_kem_serialize_deserialize_ring_elements_reduced_1b
 #define libcrux_sha3_generic_keccak_keccakf1600_80_04 Fssh_libcrux_sha3_generic_keccak_keccakf1600_80_04
 #define load_hostkeys                          Fssh_load_hostkeys

I'm only testing on aarch64 (extra ssh_namespace entries may appear).

Yes, thank you for the feedback and thank you for working on this.
I think from the user's perspective, this is much better!

I can understand we want to keep it as close as to what it currently is. And now I agree that this should be the way to go.
In the pull request you asked me if I had a different take on it: so, originally my approach was, given that they're all packages, regardless of their repo, a user could define something like:

PARTITIONS=DEFAULT
PACKAGES="FreeBSD-set-base FreeBSD-kernel-generic puppet" # Or PKG_LIST
#METHOD="packages" # This is the default

Not sure about the snapshot wording, but that's similar to what we've done in the past.
Thank you for creating this revision!

I had more time to test this change. I might change it to:

chmod "$mode" "$dir" && chmod -h "$mode" "$dir"

because it produces the "right" mtree, so that when it is a symbolic link, it takes the mode of the symbolic link itself and not the target (that is why I'm inclined to also add chmod -h so both, the target directory and the symlink have the desired mode).