[Bug 254395] bsdinstall: fail script install after BETA3

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254395

Bug ID: 254395
   Summary: bsdinstall: fail script install after BETA3
   Product: Base System
   Version: 13.0-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: regression
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: and...@bsdnir.info
CC: curr...@freebsd.org

After BETA3 or RC1 (CURRENT add efi partition /boot/efi mount) script install
UEFI system fail checksum/extract base.txz

Old working `PARTITIONS="$DISKSLICE GPT { 260M efi , auto freebsd-ufs / }"`
if edit `PARTITIONS="$DISKSLICE GPT { 260M efi /boot/efi, auto freebsd-ufs /
}"` not fix

root /mnt and efi /mnt/boot/efi mount succesfull

bsdinstall_log

 * DEBUG: f_variable_set_defaults: Initializing defaults...
 * DEBUG: f_getvar: var=[debug] value=[1] r=0
 * DEBUG: f_getvar: var=[editor] value=[/usr/bin/ee] r=0
 * DEBUG: f_getvar: var=[ftpState] value=[auto] r=0
 * DEBUG: f_getvar: var=[ftpUser] value=[ftp] r=0
 * DEBUG: f_getvar: var=[hostname] value=[] r=0
 * DEBUG: f_getvar: var=[MEDIA_TIMEOUT] value=[300] r=0
 * DEBUG: f_getvar: var=[nfs_reserved_port_only] value=[NO] r=0
 * DEBUG: f_getvar: var=[nfs_use_tcp] value=[NO] r=0
 * DEBUG: f_getvar: var=[nfs_use_v3] value=[YES] r=0
 * DEBUG: f_getvar: var=[PKG_TMPDIR] value=[/var/tmp] r=0
 * DEBUG: f_getvar: var=[releaseName] value=[13.0-RC2] r=0
 * DEBUG: f_variable_set_defaults: Defaults initialized.
 * DEBUG: variable.subr: Successfully loaded.
 * DEBUG: f_include_lang: file=[/usr/libexec/bsdconfig/include/messages.subr]
lang=[]
 * DEBUG: dialog.subr: DIALOG_SELF_INITIALIZE=[1]
 * DEBUG: f_dialog_init: ARGV=[/tmp/installerconfig] GETOPTS_STDARGS=[dD:SX]
 * DEBUG: f_dialog_init: SECURE=[] USE_XDIALOG=[]
 * DEBUG: f_dialog_init: dialog(1) API initialized.
 * DEBUG: dialog.subr: Successfully loaded.
 * DEBUG: f_include: file=[/usr/share/bsdconfig/variable.subr]
 * DEBUG: Began Installation at Fri Mar 19 02:37:31 UTC 2021
 * ./boot/efi/: Can't restore time
 * tar: Error exit delayed from previous errors.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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"

www.freebsd.org E-mail Report MESSAGE REF: DN2PSAA

[freebsd . org- Admin]

___
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.0-RC2 / 14-CURRENT: Processes getting stuck in vlruwk state

[Mateusz Guzik]

To sum up what happened, Yamagi was kind enough to test several
patches and ultimately the issue got solved here
https://cgit.freebsd.org/src/commit/?id=e9272225e6bed840b00eef1c817b188c172338ee
. The patch also got merged into releng/13.0

On 3/17/21, Yamagi  wrote:
> Hi,
> me and some other users in the ##bsdforen.de IRC channel have the
> problem that during Poudriere runs processes getting stuck in the
> 'vlruwk' state.
>
> For me it's fairly reproduceable. The problems begin about 20 to 25
> minutes after I've started poudriere. At first only some ccache
> processes hang in the 'vlruwk' state, after another 2 to 3 minutes
> nearly everything hangs and the total CPU load drops to about 5%.
> When I stop poudriere with ctrl-c it takes another 3 to 5 minutes
> until the system recovers.
>
> First the setup:
> * poudriere runs in a bhyve vm on zvol. The host is a 12.2-RELEASE-p2.
>   The zvol has a 8k blocksize, the guests partition are aligned to 8k.
>   The guest has only zpool, the pool was created with ashift=13. The
>   vm has 16 E5-2620 and 16 gigabytes RAM assigned to it.
> * poudriere is configured with ccache and ALLOW_MAKE_JOBS=yes. Removing
>   either of these options lowers the probability of the problem to show
>   up significantly.
>
> I've tried several git revisions starting with 14-CURRENT at
> 54ac6f721efccdba5a09aa9f38be0a1c4ef6cf14 in the hope that I can find at
> least one known to be good revision. No chance, even a kernel build
> from 0932ee9fa0d82b2998993b649f9fa4cc95ba77d6 (Wed Sep 2 19:18:27 2020
> +) has the problem. The problem isn't reproduceable with
> 12.2-RELEASE.
>
> The kernel stack ('procstat -kk') of a hanging process is:
> mi_switch+0x155 sleepq_switch+0x109 sleepq_catch_signals+0x3f1
> sleepq_wait_sig+0x9 _sleep+0x2aa kern_wait6+0x482 sys_wait4+0x7d
> amd64_syscall+0x140 fast_syscall_common+0xf8
>
> The kernel stack of vnlru is changing, even while the processes are
> hanging:
> * mi_switch+0x155 sleepq_switch+0x109 sleepq_timedwait+0x4b
> _sleep+0x29b vnlru_proc+0xa05 fork_exit+0x80 fork_trampoline+0xe
> * fork_exit+0x80 fork_trampoline+0xe
>
> Since vnlru is accumulating CPU time it looks like it's doing at least
> something. As an educated guess I would say that vn_alloc_hard() is
> waiting a long time or even forever to allocate new vnodes.
>
> I can provide more information, I just need to know what.
>
>
> Regards,
> Yamagi
>
> --
> Homepage: https://www.yamagi.org
> Github:   https://github.com/yamagi
> GPG:  0x1D502515
>


-- 
Mateusz Guzik 
___
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: Getting started with ktls

[tech-lists]

On Wed, Mar 17, 2021 at 08:39:02PM +, Rick Macklem wrote:


Make sure you've done the following:
ktls_ocf - is loaded
these sysctls are set to 1
kern.ipc.tls.enable
kern.ipc.mb_use_ext_pgs


[on stable/13]

% sysctl kern.ipc.tls.enable kern.ipc.mb_use_ext_pgs
kern.ipc.tls.enable: 1
kern.ipc.mb_use_ext_pgs: 1

% kldstat | grep ktls
71 0x0135300025520 ktls_ocf.ko
% 


% sysctl -a | fgrep kern.ipc.tls.stats
kern.ipc.tls.stats.ocf.retries: 0
kern.ipc.tls.stats.ocf.separate_output: 0
kern.ipc.tls.stats.ocf.inplace: 0
kern.ipc.tls.stats.ocf.tls13_gcm_crypts: 0
kern.ipc.tls.stats.ocf.tls12_gcm_crypts: 0
kern.ipc.tls.stats.ocf.tls11_cbc_crypts: 0
kern.ipc.tls.stats.ocf.tls10_cbc_crypts: 0
kern.ipc.tls.stats.switch_failed: 0
kern.ipc.tls.stats.switch_to_sw: 0
kern.ipc.tls.stats.switch_to_ifnet: 0
kern.ipc.tls.stats.failed_crypto: 0
kern.ipc.tls.stats.corrupted_records: 0
kern.ipc.tls.stats.active: 0
kern.ipc.tls.stats.enable_calls: 535
kern.ipc.tls.stats.offload_total: 0
kern.ipc.tls.stats.sw_rx_inqueue: 0
kern.ipc.tls.stats.sw_tx_inqueue: 0
kern.ipc.tls.stats.threads: 4
% 


now to try setting up the nfs thing
--
J.


signature.asc
Description: PGP signature

Re: On 14-CURRENT: no ports options anymore?

[Alastair Hogge]

On 2021-03-18 18:07, Jamie Landeg-Jones wrote:
> "Hartmann, O."  wrote:
> 
>> On Sat, 13 Mar 2021 15:13:15 -0500
>> Michael Butler via freebsd-current  wrote:
>>
>> > On 3/13/21 3:00 PM, Hartmann, O. wrote:
>> > > On Sat, 13 Mar 2021 19:52:47 + (UTC)
>> > > Filippo Moretti via freebsd-current  wrote:
>> > >
>> > >>
>> > >> I had the same problem in console modeFiippo
>> > >>  On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser 
>> > >> 
>> > >> wrote:
>> > >>
>> > >>   Am 13.03.21 um 20:17 schrieb Hartmann, O.:
>> > >>> Since I moved on to 14-CURRENT, I face a very strange behaviour when 
>> > >>> trying to set
>> > >>> options via "make config" or via poudriere accordingly. I always get 
>> > >>> "===> Options
>> > >>> unchanged" (when options has been already set and I'd expect a dialog 
>> > >>> menu).
>> > >>> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is 
>> > >>> at FreeBSD
>> > >>> 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 
>> > >>> 2021 amd64).
>> >
>> > I ran into something similar where dialog4ports would dump core after an
>> > upgrade. Rebuilding the port (ports-mgmt/dialog4ports) solved it for me,
>> >
>> >imb
>>
>> Thanks, recompilig ports-mgmt/dialog4ports solved the problem! I was sure 
>> that after some
>> ncurses changes in 14-CURRENT I've rebuilt every single port on all 
>> 14-CURRENT systems
>> after that incident, bad luck.
> 
> This bit me a few years ago - in my case, the terminal type wasn't
> recognised. If dialog4ports
> doesn't run successfully, the error is ignored by the ports scripts.
> This was on a new
> install (hence the reason I hadn't yet installed my termcap), and it
> meant that before I
> noticed, quite a number of ports got installed without the options I wanted.
> 
> Since then, I've patched bsd.port.mk with:
> 
> --- bsd.port.mk.orig2017-06-06 17:38:00.0 +0100
> +++ bsd.port.mk 2017-06-08 01:31:36.320294000 +0100
> @@ -4729,8 +4729,8 @@
> trap "${RM} $${TMPOPTIONSFILE}; exit 1" 1 2 3 5 10 13 15; \
> ${SETENV} ${D4P_ENV} ${SH} ${SCRIPTSDIR}/dialog4ports.sh
> $${TMPOPTIONSFILE} || { \
> ${RM} $${TMPOPTIONSFILE}; \
> -   ${ECHO_MSG} "===> Options unchanged"; \
> -   exit 0; \
> +   ${ECHO_MSG} "===> ERROR: Options unchanged"; \
> +   exit 1; \
> }; \
> ${ECHO_CMD}; \
> if [ ! -e $${TMPOPTIONSFILE} ]; then \
> 
> I never submitted this patch, because the way it was written seemed
> intentional. Maybe this should be reviewed?

Something like that would be great, please can we get a more informative
message? I was bitten by this a few times recently.
___
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: Problem building x11/nvidia-driver; ref. n245494-6827435548d2

[Jung-uk Kim]

On 21. 3. 17., David Wolfskill wrote:
> My laptop is currently running main-n245489-15b82e00a164; after updating
> sources to n245498-096a84721670, I am performing a source-based update.
> 
> A simialr update on my build machine (which is headless, and thus does
> not use anything related to X11) was successful.
> 
> The laptop is set up to rebuild x11/nvidia-driver when the kernel
> is updated.
> 
> The buildkernel step on it fails with:
> 
> ...
> awk -f /usr/src/sys/conf/kmod_syms.awk nvidia-modeset.ko  export_syms | xargs 
> -J% objcopy % nvidia-modeset.ko
> ===> lib (all)
> ===> lib/libglvnd (all)
> ...
> ===> x11/driver (all)
> ===> x11/extension (all)
> ===> doc (all)
> make[6]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
> (${MK_MANSPLITPKG} == "no")
> make[6]: Fatal errors encountered -- cannot continue
> make[6]: stopped in 
> /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-460.56/doc
> *** Error code 1
> 
> Stop.
> 
> 
> On reviewing the list of files changed in 15b82e00a164..096a84721670, I
> note a couple of promising-looking candidates:
> 
>  share/mk/bsd.opts.mk|   1 +
>  share/mk/src.opts.mk|   1 -
> 
> Reviewing the commit log for share/mk/bsd.opts.mk, I see that the most
> recent entry is:
> 
> | commit 6827435548d257c672f934db5c6ff01012d96995
> | Author: Jung-uk Kim 
> | Date:   Tue Mar 16 14:16:10 2021 -0400
> | 
> | pkgbase: Fix building out-of-tree manual pages
> | 
> | c7e6cb9e08d6 introduced MK_MANSPLITPKG but it was not available for
> | building out-of-tree manual pages.  For example, x11/nvidia-driver fails
> | with the following error:
> | 
> | ===> doc (all)
> | make[3]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional 
> (${MK_MANSPLITPKG} == "no")
> | make[3]: Fatal errors encountered -- cannot continue
> | 
> | Move the definition from src.opts.mk to bsd.opts.mk to make it visible.
> 
> which looks ... apropos.
> 
> Indeed, it appears that the n245494-6827435548d2 change was intended to
> fix the issue that I am now just seeing.
> 
> But I readily confess that I have neither familairity nor expertise
> with share/mk/* (and that delving into it reminds me of "You are
> in a mazy twist of passages, all different")
> 
> So...  help?  What do I need to do to be able to build the kernel now?
> 
> (E.g., if I need to just skip building x11/nvidia-driver once, get
> everything installed, then build "normally" (with x11/nvidia-driver)
> -- that's fine; I just need a clue.)

cd /usr/src/share/mk && make install

Jung-uk Kim



OpenPGP_signature
Description: OpenPGP digital signature

Re: On 14-CURRENT: no ports options anymore?

[Jamie Landeg-Jones]

"Hartmann, O."  wrote:

> On Sat, 13 Mar 2021 15:13:15 -0500
> Michael Butler via freebsd-current  wrote:
>
> > On 3/13/21 3:00 PM, Hartmann, O. wrote:
> > > On Sat, 13 Mar 2021 19:52:47 + (UTC)
> > > Filippo Moretti via freebsd-current  wrote:
> > >   
> > >>   
> > >> I had the same problem in console modeFiippo
> > >>  On Saturday, March 13, 2021, 8:33:57 PM GMT+1, Stefan Esser 
> > >> 
> > >> wrote:
> > >>
> > >>   Am 13.03.21 um 20:17 schrieb Hartmann, O.:  
> > >>> Since I moved on to 14-CURRENT, I face a very strange behaviour when 
> > >>> trying to set
> > >>> options via "make config" or via poudriere accordingly. I always get 
> > >>> "===> Options
> > >>> unchanged" (when options has been already set and I'd expect a dialog 
> > >>> menu).
> > >>> This misbehaviour is throughout ALL 14-CURRENT systems (the oldest is 
> > >>> at FreeBSD
> > >>> 14.0-CURRENT #49 main-n245422-cecfaf9bede9: Fri Mar 12 16:08:09 CET 
> > >>> 2021 amd64).
> > 
> > I ran into something similar where dialog4ports would dump core after an 
> > upgrade. Rebuilding the port (ports-mgmt/dialog4ports) solved it for me,
> > 
> > imb
>
> Thanks, recompilig ports-mgmt/dialog4ports solved the problem! I was sure 
> that after some
> ncurses changes in 14-CURRENT I've rebuilt every single port on all 
> 14-CURRENT systems
> after that incident, bad luck.

This bit me a few years ago - in my case, the terminal type wasn't recognised. 
If dialog4ports
doesn't run successfully, the error is ignored by the ports scripts. This was 
on a new
install (hence the reason I hadn't yet installed my termcap), and it meant that 
before I
noticed, quite a number of ports got installed without the options I wanted.

Since then, I've patched bsd.port.mk with:

--- bsd.port.mk.orig2017-06-06 17:38:00.0 +0100
+++ bsd.port.mk 2017-06-08 01:31:36.320294000 +0100
@@ -4729,8 +4729,8 @@
trap "${RM} $${TMPOPTIONSFILE}; exit 1" 1 2 3 5 10 13 15; \
${SETENV} ${D4P_ENV} ${SH} ${SCRIPTSDIR}/dialog4ports.sh 
$${TMPOPTIONSFILE} || { \
${RM} $${TMPOPTIONSFILE}; \
-   ${ECHO_MSG} "===> Options unchanged"; \
-   exit 0; \
+   ${ECHO_MSG} "===> ERROR: Options unchanged"; \
+   exit 1; \
}; \
${ECHO_CMD}; \
if [ ! -e $${TMPOPTIONSFILE} ]; then \

I never submitted this patch, because the way it was written seemed 
intentional. Maybe this should be reviewed?

Cheers,
  Jamie

___
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: ThinkPad: reboots after successful shutdown -p

[Kostya Berger via freebsd-current]

 I had it and filed a bug report. It only happens in UEFI loader and that only 
on one of my machines, but not the other.

With kindest regards,
Kostya Berger



 On Wednesday, 17 March 2021, 19:38:57 GMT+3, Unbound 
 wrote:  
 
 On 2021-03-17 00:01, Xin Li via freebsd-current wrote:
> On 3/16/21 9:45 PM, Warner Losh wrote:
>> 
>> 
>> On Tue, Mar 16, 2021 at 10:18 PM Xin Li > > wrote:
>> 
>>    On 11/17/19 23:14, Xin Li wrote:
>>    > Hi,
>>    >
>>    > I recently noticed that if I do a 'shutdown -p' from -CURRENT, the
>>    > system would shut down and seemingly powered off, then it would
>>    restart
>>    > after about 5-10 seconds.
>>    >
>>    > Is this a known issue?  Arguably this is not necessarily a FreeBSD
>>    > issue, but it seems that the Windows 10 installation doesn't have the
>>    > problem, so I guess there might be some difference between our and
>>    > Windows's shutdown sequence.
>> 
>>    I've found a workaround for this, for the record, setting
>>    hw.efi.poweroff=0 would make the laptop to correctly shutdown.
>> 
>>    However I don't see anything wrong with sys/dev/efidev/efirt.c's
>>    implementation of EFI shutdown; it appears to be essentially the same 
>> as
>>    implemented in command_poweroff() in stand/efi/loader/main.c, but
>>    'poweroff' would work just fine in loader.efi.
>> 
>>    Can someone familiar with the code shed me some light here? :-)
>> 
>>    It looks like what Linux did was to prefer ACPI S5, unless it's not
>>    available or the system have HW_REDUCED flag in FADT, so if we do
>>    something similar it would fix the issue for me, but according to
>>    bugs.freebsd.org/233998  that's not
>>    the case for at least Conor's system
>>    (_S5 appears to be in the ACPI dump), so I think it's something else...
>> 
>> 
>> For me, interrupt storm on shutdown has been the causes of issues like
>> this...
>> 
>> Any chance you can eliminate that as a possibility?
> 
> Hmm, that's a good question -- is there a way to tell after the screen
> was turned off?
> 
> Before the screen was turned off, there doesn't appear to be interrupt
> storm.  The system was performing a typical FreeBSD shutdown procedure:
> All buffers synced, showed uptime, destroyed GELI devices, spin down the
> SATA devices, shutdown the cardreader (rtsx0), detached all USB devices
> (hidraw1, hidbus, usbhid1, ubt0, uhub0), screen turned slightly red for
> a very brief period (maybe side effect of turning off the backlight),
> then goes off.
> 
> I think most of FreeBSD drivers would turn off interrupt from the device
> before detaching, but I haven't looked into all of my devices; but from
> what I have seen on screen (captured a 60fps video and can share if that
> helps), there doesn't appear to be an interrupt storm before that.
> 
> Cheers,
FWIW this also happened to me a few weeks ago after a fresh install.
I've since wiped the disk and repurposed the hardware. So I can't now
reproduce it. But it wasn't a laptop. So it's not isolated to them.
Sorry I can't offer anything more. I just wanted to mention this to
indicate that it's not a _too_ terribly isolated case. It was Intel
CPU/graphics. In case that says anything to anyone. If it matters,
I can get/offer more info on the hardware.

--Chris
___
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"
  
___
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"