Re: user problems when upgrading to v15

[brian whalen]

Repeating the entire process:

I created a 13.2 vm with 6 cores and 8GB of ram.

Ran freebsd-update fetch and install.

Ran pkg install git bash ccache open-vm-tools-nox11

Used git clone to get current and ports source files.

Edited /etc/make.conf to use ccache

Ran make -j6 buildworld && make -j6 kernel

I then rebooted in single user mode and did the next steps saving output 
to a file with > filename.


etcupdate -p was pretty uneventful. It did  show the below and did not 
prompt to edit.


root@f15:~ # less etcupdatep
  C /etc/group
  C /etc/master.passwd

make installworld seemed mostly error free though I did see a nonzero 
status for a man page failed inn the man4 directory.


etcupdate -B only showed the below. This was my first build after install.

root@f15:~ # less etcupdateB
Conflicts remain from previous update, aborting.

If I type exit in single user mode to go multi user mode, the local user 
still works. After a reboot the local user still works. This local user 
can also sudo as expected. This wasn't the case for the previous build 
when I first reported this. However, if I run etcupdate resolve it is 
still presenting /etc/group and /etc/master/passwd as problems.


If this is is expected behavior for current then no big deal. I just 
wasn't sure.


Brian


On 8/30/2023 7:35 PM, Graham Perrin wrote:

On 31/08/2023 03:31, brian whalen wrote:

Understood. I guess I was expecting the update process of etcupdate 
-p && make installworld && etcupdate -B to not whack existing users 
or delete an existing root user's password. I accepted the remote and 
then recreated users and reset passwords and am retrying this.


BW


Thanks.

For clarity: did the routine /not/ prompt you to edit the file (in 
which, you would have seen conflict markers etc.)?



On 8/30/2023 7:21 PM, Graham Perrin wrote:

On 31/08/2023 03:00, brian whalen wrote:
… I ran etcupdate resolve accepting the remote option and saw 2 
issues.


The root user's password was deleted.

The non root user no longer existed.
Logically, remote does not include things such as your root user's 
password.

Call for 2023Q3 status reports

[Lorenzo Salvadore]

Dear FreeBSD Community,

The deadline for the next FreeBSD Status Report update is
September, 30th 2023 for work done since the last round of quarterly reports:
July 2023 - September 2023.
I would like to remind you that reports are published on a quarterly
basis and are usually collected during the last month of each quarter,
You are also welcome to submit them even earlier if you want, and the
earlier you submit them, the more time we have for reviewing.

Status report submissions do not need to be very long. They may be
about anything happening in the FreeBSD project and community, and
they provide a great way to inform FreeBSD users and developers about
work that is underway or has been completed. Report submissions are
not limited to committers; anyone doing anything interesting and
FreeBSD related can -- and should -- write one!

The following methods are available to submit your reports:

* submit a review on Phabricator and add the group "status" to the
  reviewers list. You should put your reports in the directory
  doc/website/content/en/status/report-2023-07-2023-09/
  (create it if it is missing);

* submit a pull request at .
  You should put your reports in the directory
  doc/website/content/en/status/report-2023-07-2023-09/
  (create it if it is missing);

* send an email to status-submissi...@freebsd.org including your report.

An AsciiDoc template is available at
.

We look forward to seeing your 2023Q3 reports!

Thanks,

Lorenzo Salvadore (on behalf of status@)

Occasional supend/sleep failure

[Graham Perrin]

I have a suspend.sh script that aims to take three cache devices offline 
before sleep of the computer:


% grep -v -e '# ' /etc/rc.suspend | uniq | grep -B 3 -A 2 suspend.sh
#!/bin/sh
#

/usr/local/sbin/suspend.sh

    echo "Usage: $0 [apm|acpi] [standby,suspend|1-4]"
% grep -v -e '# ' /usr/local/sbin/suspend.sh | uniq
#!/bin/sh

while mount | grep Transcend 2>&1; do
   zpool export Transcend
   sleep 5
done

zpool offline august gpt/cache1-august
zpool offline august gpt/cache2-august
zpool offline august gpt/cache3-august

sync

killall pulseaudio

while fstat | grep -e dsp -e mixer 2>&1; do
   fstat | grep -e dsp -e mixer | cut -w -f 3 | while read pid;
  do kill -15 "$pid"
   done
done

sysctl hw.snd.default_unit=1

%


Below, it seems that sleep fails if a device is not detached. (Possibly 
if the offlining does not succeed, although I did check pool status 
shortly before suspend.)


How can I more reliably ensure detachment before /etc/rc.suspend proceeds?

Alternatively (ideally) is it possible for /etc/rc.suspend to _not_ 
proceed if detachment does not occur?



Final lines in /var/log/messages before a forced stop of the computer:

Aug 31 17:37:01 mowa219-gjp4-8570p-freebsd kernel: ugen1.8:  
at usbus1 (disconnected)
Aug 31 17:38:46 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_close_locked:352[1]: Closing access to gpt/cache1-august.
Aug 31 17:38:46 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_detach:315[1]: Detaching from gpt/cache1-august.
Aug 31 17:38:46 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_detach:326[1]: Destroying consumer for gpt/cache1-august.
Aug 31 17:38:53 mowa219-gjp4-8570p-freebsd kernel: acpi0: suspend 
request timed out, forcing sleep now
Aug 31 17:38:56 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_close_locked:352[1]: Closing access to gpt/cache2-august.
Aug 31 17:38:56 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_detach:315[1]: Detaching from gpt/cache2-august.
Aug 31 17:38:56 mowa219-gjp4-8570p-freebsd kernel: 
vdev_geom_detach:326[1]: Destroying consumer for gpt/cache2-august.



Extract from /var/log/console.log after the next start:

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: Enter full pathname 
of shell or RETURN for /bin/sh:

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: # mount -uw /
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: # zfs mount -a
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: # zpool status -x
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:   pool: august
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:  state: ONLINE
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: status: One or more 
devices has been taken offline by the administrator.
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:  Sufficient 
replicas exist for the pool to continue functioning in a

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:  degraded state.
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: action: Online the 
device using 'zpool online' or replace the device with

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:  'zpool replace'.
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:   scan: scrub 
repaired 0B in 11:06:38 with 0 errors on Mon Jun 12 01:56:37 2023

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: config:
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: NAME 
STATE READ WRITE CKSUM
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: august   
ONLINE   0 0 0
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: ada0p3.eli 
ONLINE   0 0 0

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:  cache
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: gpt/cache2-august  
OFFLINE  0 0 0
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: gpt/cache3-august  
ONLINE   0 0 0
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: gpt/cache1-august  
OFFLINE  0 0 0

Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel:
Aug 31 18:29:26 mowa219-gjp4-8570p-freebsd kernel: errors: No known data 
errors

Re: net/mpd5 on stable/14 - COMPAT_FREEBSD12 required?

[Herbert J. Skuhra]

On Wed, 30 Aug 2023 15:46:46 +0200, "Herbert J. Skuhra" wrote:
> 
> On Wed, 30 Aug 2023 15:29:28 +0200, "Herbert J. Skuhra" wrote:
> > 
> > Hi,
> > 
> > after updating from stable/13 to (main and later to) stable/14
> > net/mpd5 only connects to my ISP (VDSL with VLAN) if I enable "options
> > COMPAT_FREEBSD12" in my kernel. Without I get only:
> > 
> > Aug 30 15:08:06 gw mpd[59876]: [L1] PPPoE connection timeout after 9 seconds
> > Aug 30 15:08:06 gw mpd[59876]: [L1] Link: DOWN event
> > Aug 30 15:08:06 gw mpd[59876]: [L1] LCP: Down event
> > Aug 30 15:08:06 gw mpd[59876]: [L1] Link: reconnection attempt 1 in 7 
> > seconds
> > Aug 30 15:08:14 gw mpd[59876]: [L1] Link: reconnection attempt 1
> > Aug 30 15:08:14 gw mpd[59876]: [L1] PPPoE: Connecting to ''
> > Aug 30 15:08:23 gw mpd[59876]: [L1] PPPoE connection timeout after 9 seconds
> > Aug 30 15:08:23 gw mpd[59876]: [L1] Link: DOWN event
> > Aug 30 15:08:23 gw mpd[59876]: [L1] LCP: Down event
> > [..]
> > 
> > I guess the problem is:
> > 
> > Without "COMPAT_FREEBSD12" vlanproto = 0x. If I run "ifconfig
> > vlan31 vlanproto 802.1q" mpd5 works.
> 
> Maybe this commit is related:
> 
> commit afbb64f1d85b7d8c2938031c3567946b5d10da4f
> Author: Alexander V. Chernikov
> Date:   Sun Apr 11 17:47:03 2021 +0100
> 
> Fix vlan creation for the older ifconfig(8) binaries.
> 
> Reported by:allanjude
> MFC after:  immediately
> 
> ?

On stable/13 (GENERIC without COMPAT_FREEBSD12):

# ifconfig vlan99 create
 ==> vlanproto: 0x
# ifconfig vlan99 vlan 99 vlandev igb0
 ==> vlanproto: 802.1q
# ifconfig vlan99 destroy
# ifconfig vlan99 create vlan 99 vlandev igb0
 ==> vlanproto: 802.1q

On stable/14 or main (GENERIC without COMPAT_FREEBSD12):

# ifconfig vlan99 create
 ==> vlanproto 0x
# ifconfig vlan99 vlan 99 vlandev igb0
 ==> vlanproto 0x#
# ifconfig vlan99 create vlan 99 vlandev igb0
 ==> vlanproto: 802.1q

I guess that's why the following lines in my /etc/rc.conf no longer
work on stable/14 or main (without COMPAT_FREEBSD12):

cloned_interfaces="vlan99"
ifconfig_vlan99="vlan 99 vlandev igb0"

I have to replace the ifconfig line with:

ifconfig_vlan99="vlan 99 vlandev igb0 vlanproto 802.1q"

It also works if I remove the following lines in sys/net/if_vlan.c:

1110 #ifdef COMPAT_FREEBSD12
1113 #endif

2265 #ifdef COMPAT_FREEBSD12
2268 #endif

--
Herbert