Search results

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

Glad to see that I'm not the only one. I'll submit a bug report either today or tomorrow. We use Chromium headless to convert live html pages to pdf: /usr/local/bin/chrome --headless --disable-gpu --run-all-compositor-stages-before-draw --print-to-pdf-no-header --print-to-pdf="test.pdf" {url}...

/usr/local/bin/chrome --headless results in the following error: [12506:-1942282240:1206/092602.673717:ERROR:property_cache.cc(46)] Check failed: it->second.response.has_value(). [bad_optional_access.cc : 39] RAW: Bad optional access Abort Seeing this error on multiple FreeBSD13.2-RELEASE...

We are attempting to implement two factor authentication (Google Authenticator) with Dovecot (mandated by our insurance company) and thought I'd share some info. Oddly enough, we are only required to use TFA for retrieving mail, not sending it, so this only applies to IMAP side of things. BTW...

I just turned up a Dell PE-R7525 that has this controller. We are running it in "NON-RAID" mode with two SAS and two SATA drives (2x ZFS mirror pools). No issues as far as I can tell.

The www/webkit2-gtk[3-4] ports have a really basic browser installed at /usr/local/bin/MiniBrowser-[4-5].

Did you add the appropriate entries to master.passwd and group? Last line in /etc/master.passwd should read something along the lines of: +::::::::: and /etc/group should have something like: +::0:

For dovecot, I think you want to use Oauth2, which is detailed here: https://doc.dovecot.org/configuration_manual/authentication/oauth2/ This has been on my todo list for some time, but it seems every time I start looking into it, the more confused it get. If anyone ever does a full...

Try adding nfsuserd_enable="YES" to your client's rc.conf.

Even better is with the new box I deployed using an Asus WS C246 Pro motherboard with two Intel onboard NICs. One identifies as igb0 and the other em0. Both are running at 1gb. Not complaining, just thought it was interesting that Asus would use different chipsets on the same motherboard...

I concur... I have this issue when I plug in a USB Serial adapter. I just end up unplugging/plugging in the USB keyboard to get it resolved.

I have a couple of terminals using ASRock Q1900B-ITX boards (Intel ATOM E3800) that couldn't switch between console and X since early 10.x (guessing??). As soon as X was started, going back to console mode would result in blank screen. Only way to recover was to either ssh into the terminal...

In loader.conf (if X11 is set for 1024x768): kern.vt.fb.default_mode="1024x768" man vt is your friend.

I'd like to add that I found that if you set the VT resolution the same as your X11 resolution, this seems to fix the switching issue.

We just moved/migrated our MM2 over to mail/sympa. We only had a handful of lists, so it wasn't too painful. List moderators like the interface better.

Add me to the list of Ubiquiti Unifi equipment users. Roaming/switching between access points is seamless, performance is good, and you can't beat the pricing. The Java based management system is also in ports.

Apologies, misunderstood your issue. If you are using net/isc-dhcp44-server, make sure that "-lf /var/db/dhcpd/dhcpd.leases" is set (should be by default in the rc.d startup script).

I ended up writing a small shell script that uses net/fping. I grep out the range(s) from dhcpd.conf and run fping -a -g $RANGE. I get the MAC address of each response via arp and then cross reference the MAC against the last entries in /var/db/dhcpd/dhcpd.leases. Script spits out IP, MAC...

To clarify, tar is reading and extracting to same gmirrored UFS partition. Drive walking is expected, just didn't think a single process would (should?) drag the system this much. I guess I am expecting some kind of behind-the-scenes I/O throttling to come into play. This is a simple...

9664M free and 12G inactive. Don't believe it's a memory issue. Something related to I/O.