etcupdate -p vs. root on zfs (and bectl use and such): no /usr/src/etc/master.passwd (for example)
FYI: The default bsdinstall result for auto ZFS that I tried has a separate zroot/usr/src dataset, which zfs mounts at /usr/src . UPDATING and such places indicate sequences like: (think etcupdate where it lists mergemaster and ignore -F and -Fi) make buildworld make buildkernel KERNCONF=YOUR_KERNEL_HERE make installkernel KERNCONF=YOUR_KERNEL_HERE [1] [3] mergemaster -Fp [5] NOTE: What /usr/src/etc/master.passwd here? (for example) make installworld mergemaster -Fi [4] make delete-old [6] etcupdate has the logic for handling -p: if [ -n "$preworld" ]; then # Build a limited tree that only contains files that are # crucial to installworld. for file in $PREWORLD_FILES; do name=$(basename $file) mkdir -p $1/etc >&3 2>&1 || return 1 cp -p $SRCDIR/$file $1/etc/$name || return 1 done Note the "$SRCDIR/$file". But for a boot -s after installing the kernel there is only zroot/ROOT/NAME and no zroot/usr/src zfs mount so /usr/src/ is empty. This leads to needing an additional step: zfs mount zroot/usr/src (The instructions do not deal with making / writable at this stage either.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
"etcupdate -p" vs. $OLDTREE?
After the set of updates to etcupdate (main-n246232-0611aec3cf3a .. main-n246235-ba30215ae0ef), I find that "etcupdate -B -p" is working as expected, but after the following "make installworld", a subsequent "etcupdate -B" chugs along for a bit, then stops, whining: No previous tree to compare against, a sane comparison is not possible. and inspection of the $WORKDIR before: freebeast(14.0-C)[1] ls -lT /var/db/s4/etcupdate/ total 260 -rw-r--r-- 1 root wheel 0 Apr 22 05:17:54 2021 added.files -rw-r--r-- 1 root wheel8556 Apr 22 05:17:54 2021 both.files drwxr-xr-x 2 root wheel 512 Apr 22 05:17:54 2021 conflicts drwxr-xr-x 7 root wheel 512 Apr 22 05:17:54 2021 current -rw-r--r-- 1 root wheel 212793 Apr 22 05:17:54 2021 log -rw-r--r-- 1 root wheel8556 Apr 22 05:17:54 2021 new.files drwxr-xr-x 7 root wheel 512 Apr 22 05:15:33 2021 old -rw-r--r-- 1 root wheel8556 Apr 22 05:17:54 2021 old.files drwxr-xr-x 4 root wheel 512 Apr 22 04:03:20 2021 preworld -rw-r--r-- 1 root wheel 0 Apr 22 05:17:54 2021 removed.files and after (the "make installworld"): freebeast(14.0-C)[2] ls -lT /var/db/s4/etcupdate/ total 36 -rw-r--r-- 1 root wheel 0 Apr 23 03:53:41 2021 added.files -rw-r--r-- 1 root wheel36 Apr 23 03:53:41 2021 both.files drwxr-xr-x 2 root wheel 512 Apr 23 03:53:41 2021 conflicts -rw-r--r-- 1 root wheel 198 Apr 23 03:53:41 2021 log -rw-r--r-- 1 root wheel36 Apr 23 03:53:41 2021 new.files drwxr-xr-x 7 root wheel 512 Apr 22 05:15:33 2021 old -rw-r--r-- 1 root wheel 8556 Apr 23 03:53:41 2021 old.files drwxr-xr-x 5 root wheel 512 Apr 23 03:53:41 2021 preworld -rw-r--r-- 1 root wheel 0 Apr 23 03:53:41 2021 removed.files shows the lack of a "current" subdirectory. After invoking "etcupdate extract", then "etcupdate -B": freebeast(14.0-C)[3] ls -lT /var/db/s4/etcupdate/ total 260 -rw-r--r-- 1 root wheel 0 Apr 23 03:58:59 2021 added.files -rw-r--r-- 1 root wheel8556 Apr 23 03:58:59 2021 both.files drwxr-xr-x 2 root wheel 512 Apr 23 03:58:59 2021 conflicts drwxr-xr-x 7 root wheel 512 Apr 23 03:58:59 2021 current -rw-r--r-- 1 root wheel 212793 Apr 23 03:59:00 2021 log -rw-r--r-- 1 root wheel8556 Apr 23 03:58:59 2021 new.files drwxr-xr-x 7 root wheel 512 Apr 23 03:57:58 2021 old -rw-r--r-- 1 root wheel8556 Apr 23 03:58:59 2021 old.files drwxr-xr-x 5 root wheel 512 Apr 23 03:53:41 2021 preworld -rw-r--r-- 1 root wheel 0 Apr 23 03:58:59 2021 removed.files Am I missing something? Thanks! Peace, david -- David H. Wolfskill da...@catwhisker.org The same folks who champion the "rights" of corporations to influence elections by money (as an exercise of free speech) are now also decrying corporations' speaking out against voter suppression laws...? Right. See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: "etcupdate -p" vs. $OLDTREE?
On Fri, Apr 23, 2021 at 1:10 PM David Wolfskill wrote: > After the set of updates to etcupdate (main-n246232-0611aec3cf3a .. > main-n246235-ba30215ae0ef), I find that "etcupdate -B -p" is working as > expected, but after the following "make installworld", a subsequent > "etcupdate -B" chugs along for a bit, then stops, whining: > > No previous tree to compare against, a sane comparison is not possible. > > > Same problem here while using /usr/src/tools/build/beinstall.sh: (...) Skipping blacklisted certificate /usr/share/certs/trusted/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem (/etc/ssl[0/1831]sted/ee1365c0.0) Skipping blacklisted certificate /usr/share/certs/trusted/Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.pem (/etc/ssl/blacklisted/dc45b0bd.0) Scanning /usr/local/share/certs for certificates... + [ -n etcupdate ] + update_etcupdate + /usr/src/usr.sbin/etcupdate/etcupdate.sh -s /usr/src -D /tmp/beinstall.MZ4oy8/mnt -F No previous tree to compare against, a sane comparison is not possible. + return 1 + [ 1 -ne 0 ] + errx 'etcupdate (post-world) failed!' + cleanup (...) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
How to delete comment spam from bugzilla?
Somebody, or more likely some bot, is posting comment spam in our bugzilla. How can we delete spammy comments ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How to delete comment spam from bugzilla?
Hello, From: Alan Somers Subject: How to delete comment spam from bugzilla? Date: Fri, 23 Apr 2021 09:31:01 -0600 > Somebody, or more likely some bot, is posting comment spam in our > bugzilla. How can we delete spammy comments ? I faced same situation before and was told to send mail to bugmeis...@freebsd.org. --- Yasuhiro Kimura ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: "etcupdate -p" vs. $OLDTREE?
On 4/23/21 6:59 AM, Olivier Cochard-Labbé wrote:
On Fri, Apr 23, 2021 at 1:10 PM David Wolfskill
wrote:
After the set of updates to etcupdate (main-n246232-0611aec3cf3a ..
main-n246235-ba30215ae0ef), I find that "etcupdate -B -p" is working as
expected, but after the following "make installworld", a subsequent
"etcupdate -B" chugs along for a bit, then stops, whining:
No previous tree to compare against, a sane comparison is not possible.
Same problem here while using /usr/src/tools/build/beinstall.sh:
(...)
Skipping blacklisted certificate
/usr/share/certs/trusted/Verisign_Class_1_Public_Primary_Certification_Authority_-_G3.pem
(/etc/ssl[0/1831]sted/ee1365c0.0)
Skipping blacklisted certificate
/usr/share/certs/trusted/Verisign_Class_2_Public_Primary_Certification_Authority_-_G3.pem
(/etc/ssl/blacklisted/dc45b0bd.0)
Scanning /usr/local/share/certs for certificates...
+ [ -n etcupdate ]
+ update_etcupdate
+ /usr/src/usr.sbin/etcupdate/etcupdate.sh -s /usr/src -D
/tmp/beinstall.MZ4oy8/mnt -F
No previous tree to compare against, a sane comparison is not possible.
+ return 1
+ [ 1 -ne 0 ]
+ errx 'etcupdate (post-world) failed!'
+ cleanup
(...)
Sorry, this should be fixed. beinstall.sh still has a bug in that it needs
this change:
diff --git a/tools/build/beinstall.sh b/tools/build/beinstall.sh
index 46c65d87e61a..fab21edc0fd5 100755
--- a/tools/build/beinstall.sh
+++ b/tools/build/beinstall.sh
@@ -133,7 +133,7 @@ update_mergemaster() {
update_etcupdate_pre() {
${ETCUPDATE_CMD} -p -s ${srcdir} -D ${BE_MNTPT} ${ETCUPDATE_FLAGS} ||
return $?
- ${ETCUPDATE_CMD} resolve -D ${BE_MNTPT} || return $?
+ ${ETCUPDATE_CMD} resolve -p -D ${BE_MNTPT} || return $?
}
update_etcupdate() {
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.1 from main?
Hi, On 4/22/21 6:00 PM, Alan Somers wrote: Because we have a policy of never releasing anything even a little bit backwards-incompatible in a minor release. I believe we have made backwards incompatible changes in minor branches in the fairly recent past, at least compiler changes and VM changes that affected video drivers. But I'm not sure, please correct me if I'm wrong. Cheers, Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.1 from main?
On Fri, Apr 23, 2021 at 11:35 AM Steve Wills wrote: > Hi, > > On 4/22/21 6:00 PM, Alan Somers wrote: > > Because we have a policy of never releasing anything even a little bit > > backwards-incompatible in a minor release. > > I believe we have made backwards incompatible changes in minor branches > in the fairly recent past, at least compiler changes and VM changes that > affected video drivers. But I'm not sure, please correct me if I'm wrong. > Userland guarantees are easier to achieve than private kernel interfaces. Compilers have been binary compatible always, though newer versions were pickier at times which caused some minor grief (though that had nothing to do with the video driver stuff). By and large, things are broadly compatible. in the minor releases. And that's a good thing since we need packages for fewer release trains. But it also means things can take longer to get into a release. It's a balancing act, really, that we set the balance for decades ago and we may benefit from a close re-examination to see if a different model would let us use resources better and/or deliver features more quickly. Warner ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: base compiler & build options
On 22 Apr 2021, at 13:20, Filippo Moretti via freebsd-current wrote: > > I run FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #24 > main-n246214-78ffcb86d98: Tue Apr 20 17:51:50 CEST 2021 > root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 > > will llvm12 be merged on main or should I get it manually? I'm working on it, but it might take a while. You could install the llvm12 package (or build the port if you have cycles to spare), and try to see what happens when you build world. Your mileage may vary... > In order to only build amd64 is it correct > toWITHOUT_LLVM_TARGET_ALLWITH_LLVM_TARGET_X86sincerelyFilippo From src.conf(5): WITHOUT_LLVM_TARGET_ALL Only build the required LLVM target support. This option is preferred to specific target support options. So you only need that option. The native target is always enabled. -Dimitry signature.asc Description: Message signed with OpenPGP
https://artifact.ci.freebsd.org/snapshot/stable-13/?C=M&O=D messed up dates and HASHID-only use make things extremely hard to find "in time order"
Using an example to illustrate problems finding artifacts, the problems not being limited to the example's specifics. I have historically used https://artifact.ci.freebsd.org/snapshot/ to do build-less approximate bisecting (and other things). Such use is very messed up since the git-related URL conventions chosen were put in place. The below illustrates an example of the mess for how things are currently presented. https://artifact.ci.freebsd.org/snapshot/stable-13/?C=M&O=D lists ac845558f7b626d9a31b8f6dab686c45d39dc5a0/ as having date/time 2021-Apr-10 18:43 . But: https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/?C=M&O=D lists: powerpc/ and arm/ as having date/times 2021-Apr-10 18:54 and 2021-Apr-10 18:50 yet lists... i386/ and arm64/ as having date/times 2021-Feb-19 19:00 and 2021-Feb-19 18:50 . But it gets worse: https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/powerpc/?C=M&O=D shows an empty directory. Same for: https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm/?C=M&O=D By contrast, https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/i386/?C=M&O=D shows i386/ with date/time 2021-Apr-10 18:43 but https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/i386/i386/?C=M&O=D shows all the file dates as 2021-Feb-19 19:00 . Going back to arm64/ I find a similar 2021-Feb-19 dating, although 21021-Feb does show up in more places: https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm64/?C=M&O=D shows aarch64/ with date/time 2021-Feb-19 18:50 and https://artifact.ci.freebsd.org/snapshot/stable-13/ac845558f7b626d9a31b8f6dab686c45d39dc5a0/arm64/aarch64/?C=M&O=D shows the files also having the date/time 2021-Feb-19 18:50 . In my view the choice to only use the hash-id for the commit in the url is a usability mistake and the url prefix should be of a form more like (for this example context): https://artifact.ci.freebsd.org/snapshot/stable-13/n??-HASHID/ where the ?? is from: git rev-list --first-parent --count (as used elsewhere by FreeBSD). (The HASHID might be just the 12 character prefix instead of the whole hash-id as well.) Such a convention would be more independent of dates possibly being touched on the file server and would make time ordered finding of things (such as for build-less approximate bisecting) far more reasonable. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
geli_groups vs. fstab
I was testing geli_groups with a setup similar to the example here:
https://reviews.freebsd.org/D12644
The entries in rc.conf only work if the devices are not also listed in /etc/
fstab. The rc-script processes fstab entries before trying to attach the
geli_groups.
As workaround, I've edited /etc/rc.d/geli and exchanged the loops
"for group in ${geli_groups}; do" and "for provider in ${devices}; do".
Now it works as expected for me.
The commit message says:
This is helpful when the providers being attached are not used for boot,
and therefore the existing code to first try the cached password when
tasting the providers during boot does not apply.
I'm not sure how the "cached password" mechanism works. My rc-change might
break it.
Disclaimer: Tested on 13.0-RELEASE, but the rc-script ist the same in in
current.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
