Despite the documentation, "etcupdate extract" handles -D destdir (and its contribution to the default workdir)

[Mark Millard via freebsd-current]

# etcupdate -?
Illegal option -?

usage: etcupdate [-npBF] [-d workdir] [-r | -s source | -t tarball]
 [-A patterns] [-D destdir] [-I patterns] [-L logfile]
 [-M options]
   etcupdate build [-B] [-d workdir] [-s source] [-L logfile] [-M options]
 
   etcupdate diff [-d workdir] [-D destdir] [-I patterns] [-L logfile]
   etcupdate extract [-B] [-d workdir] [-s source | -t tarball] [-L logfile]
 [-M options]
   etcupdate resolve [-p] [-d workdir] [-D destdir] [-L logfile]
   etcupdate status [-d workdir] [-D destdir]

The "etcupdate extract" material does not show -D destdir as valid.


# man etcupdate
. . .
SYNOPSIS
 etcupdate [-npBF] [-d workdir] [-r | -s source | -t tarball]
   [-A patterns] [-D destdir] [-I patterns] [-L logfile]
   [-M options]
 etcupdate build [-B] [-d workdir] [-s source] [-L logfile] [-M options]
   tarball
 etcupdate diff [-d workdir] [-D destdir] [-I patterns] [-L logfile]
 etcupdate extract [-B] [-d workdir] [-s source | -t tarball] [-L logfile]
   [-M options]
 etcupdate resolve [-p] [-d workdir] [-D destdir] [-L logfile]
 etcupdate status [-d workdir] [-D destdir]
. . .

Again the "etcupdate extract" material does not show -D destdir as valid.

But I used it:

# etcupdate extract -D usr/obj/DESTDIRs/13_0R-CA7-for-chroot

and it created and filled in the workdir:

/usr/obj/DESTDIRs/13_0R-CA7-for-chroot/var/db/etcupdate/


I have not checked on if "etcupdate build" has a similar issue
vs. not.

===
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"

Re: FreeBSD-14.0-CURRENT-amd64-20210408-15dc713ceb5-245885-memstick.img fails to boot on Haswell-based laptop.

[Lev Serebryakov]

On 15.04.2021 22:19, Lev Serebryakov wrote:


calltrap()
--- trap 0x9
run_interrupt_driven_config_hooks()
boot_run_interrupt_driven_config_hooks()
mi_startup()

   It is 100% reproducible, and I cannot issue commands to kernel debugger, 
keyboard is dead.

   Enabling verbose boot helps, with verbose boot it boots to installer.

   Looks like some race condition.

   Is it known problem?


try to boot verbose


It is funny, but boot-verbose helps on battery and doesn't help with AC. I think, it is 
because with AC plugged in CPU is set to "performance" mode and delay from 
printing verbose information is not enough!


 Same panic with much more recent kernel, again, only if AC power is 
connected...

--
// Lev Serebryakov
___
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: No previous tree to compare against, a sane comparison is not possible. (was: Review D28062 …)

[Graham Perrin]

On 21/04/2021 18:19, John Baldwin wrote:

On 4/17/21 12:52 PM, Graham Perrin wrote:

2)

 line 2274

etcupdate -p

I get:

  > No previous tree to compare against, a sane comparison is not 
possible.


Hmm, how did you initially install this machine?  Release images should
generally include a pre-populated /var/db/etcupdate so that etcupdate
works.  If you don't have one of those, you will have to perform an
initial bootstrap of etcupdate (only once) by running 'etcupdate 
extract'.

If you do this before you update /usr/src then 'etcupdate' will later
work fine.  If you are doing this after you have already updated
/usr/src, you will need to run 'etcupdate diff' after 'etcupdate extract'
and fix any unexpected local differences in the generated patch, e.g.
by copying files from /var/db/etcupdate/current/etc to /etc.  Once
you have done this, 'etcupdate' will work fine on the next upgrade.

However, I'm curious how you didn't get the etcupdate bootstrap when
you initially installed.



Sorry for not replying sooner.

It's not an answer to your question, but might the thread at 
 
be relevant?


___
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

[Stefan Ehmann]

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"