Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

2021-06-07 Thread Thomas Mueller 
> In both cases, the entry is INcorrect. Juraj is correct. The swap entry is
> missing sw
> IOW the line MUST read as:

> /dev/gpt/Sea1-18noneswapsw  0   0

> or

> /dev/gpt/Sea1-18noneswapsw,trimonce 0   0

> as appropriate for the media referenced.

>-Chris

As my last message stated, I found the missing field in /etc/fstab and 
corrected it.

Then "mount -u /" worked smoothly.

Perhaps one field too few makes the system look to the next line, so the whole 
/etc/fstab is misinterpreted.

I also pointed out that, from previous messages on this list, that etcupdate 
was replacing mergemaster.

But UPDATING at the top of the src tree still specifies mergemaster, so that 
would need to be updated.

There needs to be better documentation on the newer etcupdate.

Parameters for etcupdate are somewhat different in FreeBSD than in NetBSD, so 
the documentation needs to be updated.

I don't want to mess up by doing the wrong thing in NetBSD or FreeBSD.

Tom

Re: kernel panic while copying files

2021-06-07 Thread Mark Johnston 
On Mon, Jun 07, 2021 at 11:01:09AM +0200, Gary Jennejohn wrote:
> I've seen this panic three times in the last two days:
> 
> [first panic]
> Unread portion of the kernel message buffer:
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 3; apic id = 03
> fault virtual address   = 0x801118000
> fault code  = supervisor write data, page not present
> instruction pointer = 0x20:0x808d2212
> stack pointer   = 0x28:0xfe00dbc8c760
> frame pointer   = 0x28:0xfe00dbc8c7a0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 28 (dom0)
> trap number = 12
> panic: page fault
> cpuid = 3
> time = 1622963058
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00dbc8c410
> vpanic() at vpanic+0x181/frame 0xfe00dbc8c460
> panic() at panic+0x43/frame 0xfe00dbc8c4c0
> trap_fatal() at trap_fatal+0x387/frame 0xfe00dbc8c520
> trap_pfault() at trap_pfault+0x4f/frame 0xfe00dbc8c580
> trap() at trap+0x253/frame 0xfe00dbc8c690
> calltrap() at calltrap+0x8/frame 0xfe00dbc8c690
> --- trap 0xc, rip = 0x808d2212, rsp = 0xfe00dbc8c760, rbp = 
> 0xfe00dbc8c7a0 ---
> zone_release() at zone_release+0x1f2/frame 0xfe00dbc8c7a0
> bucket_drain() at bucket_drain+0xda/frame 0xfe00dbc8c7d0
> bucket_cache_reclaim_domain() at bucket_cache_reclaim_domain+0x30a/frame 
> 0xfe00dbc8c830
> zone_reclaim() at zone_reclaim+0x162/frame 0xfe00dbc8c880
> uma_reclaim_domain() at uma_reclaim_domain+0xa2/frame 0xfe00dbc8c8b0
> vm_pageout_worker() at vm_pageout_worker+0x41e/frame 0xfe00dbc8cb70
> vm_pageout() at vm_pageout+0x21e/frame 0xfe00dbc8cbb0
> fork_exit() at fork_exit+0x7e/frame 0xfe00dbc8cbf0
> fork_trampoline() at fork_trampoline+0xe/frame 0xfe00dbc8cbf0
> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
> KDB: enter: panic
> 
> __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> 55   __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
>  pc_curthread)));
> 
> One difference was that in the second and third panics the fault virtual
> address was 0x0.  But the backtrace was the same.
> 
> Relevant info from the info.x files:
> Architecture: amd64
> Architecture Version: 2
> Version String: FreeBSD 14.0-CURRENT #33 main-n247184-1970d693039: Sat Jun
> 5 09:58:55 CEST 2021
> 
> CPU: AMD Ryzen 5 1600 Six-Core Processor (3194.09-MHz K8-class 
> CPU)
>   Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
>   AMD Features=0x2e500800
>   AMD 
> Features2=0x35c233ff
>   AMD Extended Feature Extensions ID EBX=0x1007
> 
> I have 16GiB of memory in the box.
> 
> The panic occurred while copying files from an internal SATA SSD to a
> SATA 8TB disk in an external USB3 docking station.  The panic seems to
> occur quite quickly, after only a few files have been copied.
> 
> swap is on a different internal disk.
> 
> I can poke around in the crash dumps with kgdb if anyone wants more
> information.

Are you running with invariants configured in the kernel?  If not,
please try to reproduce this in a kernel with

options INVARIANT_SUPPORT
options INVARIANTS

configured.

A stack trace with line numbers would also be helpful.

Re: What happen to mailing list archives?

2021-06-07 Thread Baptiste Daroussin 
On Mon, Jun 07, 2021 at 12:30:46AM -0700, Mark Millard wrote:
> On 2021-Jun-6, at 13:25, Mark Millard  wrote:
> 
> > Baptiste Daroussin  wrote on
> > Date: Sun, 6 Jun 2021 10:53:49 +0200 :
> > 
> >> What has happended:
> >> plan A: we migrated everything off mailman/pipermail seamlessly with 
> >> redirection
> >> and so on. We patched the new archiver to produce the same file names has
> >> pipermail
> >> 
> >> Plan A worked fine up to a limit, there was plenty of hand edition in the 
> >> past,
> >> we we decided to move to plan B which is what is happening now.
> >> 
> >> Plan B: We keep a frozen version of the archives up to the migration date 
> >> under
> >> the pipermail directory and have the new archives created in the archives
> >> directory.
> >> 
> >> All the pipermail archives have been restored as they were. The new 
> >> archives
> >> receives in their index a new link to point people to the pipermails 
> >> archive if
> >> looking for older archives.
> >> 
> >> this has been done a couple of hours ago (before Steve emails) during a 
> >> window,
> >> of ~ 10 hours, the mailing lists which slow traffic aka the one which 
> >> didn't
> >> received any email since the migration ended up with an empty "archives"
> >> directory (aka a 404), a file with explanation and redirection to 
> >> pipermail has
> >> been installed there.
> >> 
> >> Some work is still needed for the mailing lists which has been transformed 
> >> as
> >> readonly, this will be done in the next couple of days
> > 
> > It is too bad that a reference to a "no examples yet"
> > month, such as, (at the time I write this):
> > 
> > https://lists.freebsd.org/archives/freebsd-toolchain/2021-June/date.html
> > 
> > does not show at least (Date view specific example):
> > 
> > • Other periods:[ Previous, Date view ] [ List of Folders ]
> > • Other: [ Actives mailing lists ] [ Archives from mailman's time ]
> > 
> > when there are prior months available in
> > https://lists.freebsd.org/archives/ or show at least just:
> > 
> > • Other: [ Actives mailing lists ] [ Archives from mailman's time ]
> > 
> > when no prior months are available there.
> > 
> 
> Looks like there are missing months.
> 
> Using freebsd-hackers as an example:
> 
> https://lists.freebsd.org/archives/freebsd-hackers/index.html
> shows the oldest month being "May 2021".
> 
> But . . .
> 
> https://lists.freebsd.org/pipermail/freebsd-hackers/
> shows the most recent month being "September 2020".
> 
> So: 2020-Oct through 2021-Apr are completely missing.
> 
> Then, going for more detail for 2020-Sep and 2021-May . . .
> 
> https://lists.freebsd.org/archives/freebsd-hackers/2021-May/date.html
> shows "Starting Tue May 18 2021 - 21:07:44 UTC".
> 
> https://lists.freebsd.org/pipermail/freebsd-hackers/2020-September/date.html
> shows "Ending: Tue Sep 15 14:12:20 UTC 2020".
> 
> So there are about 2 more half-months missing.
> 
> Some other lists have other date ranges, some similar,
> some not.

This missing month are being populated right now

Best regards,
Bapt

Re: Files in /etc containing empty VCSId header

2021-06-07 Thread Ian Lepore 
On Mon, 2021-06-07 at 13:53 -0600, Warner Losh wrote:
> On Mon, Jun 7, 2021 at 12:26 PM John Baldwin  wrote:
> 
> > On 5/20/21 9:37 AM, Michael Gmelin wrote:
> > > Hi,
> > > 
> > > After a binary update using freebsd-update, all files in /etc
> > > contain
> > > "empty" VCS Id headers, e.g.,
> > > 
> > >  $ head  /etc/nsswitch.conf
> > >  #
> > >  # nsswitch.conf(5) - name service switch configuration file
> > >  # $FreeBSD$
> > >  #
> > >  group: compat
> > >  group_compat: nis
> > >  hosts: files dns
> > >  netgroup: compat
> > >  networks: files
> > >  passwd: compat
> > > 
> > > After migrating to git, I would've expected those to contain
> > > something
> > > else or disappear completely. Is this expected and are there any
> > > plans
> > > to remove them completely?
> > 
> > I believe we might eventually remove them in the future, but doing
> > so
> > right now would introduce a lot of churn and the conversion to git
> > had enough other churn going on.
> > 
> 
> We'd planned on not removing things that might be merged to stable/12
> since
> those releases (12.3 only I think) will be built out of svn. We'll
> likely
> start to
> remove things more widely as the stable/12 branch reaches EOL and
> after.
> 
> Warner

It would be really nice if, instead of just deleting the $FreeBSD$
markers, they could be replaced with the path/filename of the file in
the source tree.  Sometimes it's a real interesting exercise to figure
out where a file on your runtime system comes from in the source world.
All the source tree layout changes that happened for packaged-base
makes it even more interesting.

-- Ian

Re: Files in /etc containing empty VCSId header

2021-06-07 Thread Warner Losh 
On Mon, Jun 7, 2021 at 12:26 PM John Baldwin  wrote:

> On 5/20/21 9:37 AM, Michael Gmelin wrote:
> > Hi,
> >
> > After a binary update using freebsd-update, all files in /etc contain
> > "empty" VCS Id headers, e.g.,
> >
> >  $ head  /etc/nsswitch.conf
> >  #
> >  # nsswitch.conf(5) - name service switch configuration file
> >  # $FreeBSD$
> >  #
> >  group: compat
> >  group_compat: nis
> >  hosts: files dns
> >  netgroup: compat
> >  networks: files
> >  passwd: compat
> >
> > After migrating to git, I would've expected those to contain something
> > else or disappear completely. Is this expected and are there any plans
> > to remove them completely?
>
> I believe we might eventually remove them in the future, but doing so
> right now would introduce a lot of churn and the conversion to git
> had enough other churn going on.
>

We'd planned on not removing things that might be merged to stable/12 since
those releases (12.3 only I think) will be built out of svn. We'll likely
start to
remove things more widely as the stable/12 branch reaches EOL and after.

Warner

Re: Files in /etc containing empty VCSId header

2021-06-07 Thread John Baldwin 

On 5/20/21 9:37 AM, Michael Gmelin wrote:

Hi,

After a binary update using freebsd-update, all files in /etc contain
"empty" VCS Id headers, e.g.,

 $ head  /etc/nsswitch.conf
 #
 # nsswitch.conf(5) - name service switch configuration file
 # $FreeBSD$
 #
 group: compat
 group_compat: nis
 hosts: files dns
 netgroup: compat
 networks: files
 passwd: compat

After migrating to git, I would've expected those to contain something
else or disappear completely. Is this expected and are there any plans
to remove them completely?


I believe we might eventually remove them in the future, but doing so
right now would introduce a lot of churn and the conversion to git
had enough other churn going on.

--
John Baldwin

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

2021-06-07 Thread Chris 

On 2021-06-06 23:49, Graham Perrin wrote:

On 07/06/2021 07:10, Juraj Lutter wrote:

Bacause swap entry is in inapropriate format.

The line should read:

/dev/gpt/Sea1-18noneswapsw  0   0


Very well spotted, Juraj, but maybe a typo in your correction.

A clearer view of the original  where the device 
given to swap is:


/dev/gpt/Sea1-08

In both cases, the entry is INcorrect. Juraj is correct. The swap entry is
missing sw
IOW the line MUST read as:

/dev/gpt/Sea1-18noneswapsw  0   0

or

/dev/gpt/Sea1-18noneswapsw,trimonce 0   0

as appropriate for the media referenced.

--Chris

kernel panic while copying files

2021-06-07 Thread Gary Jennejohn 
I've seen this panic three times in the last two days:

[first panic]
Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 3; apic id = 03
fault virtual address   = 0x801118000
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x808d2212
stack pointer   = 0x28:0xfe00dbc8c760
frame pointer   = 0x28:0xfe00dbc8c7a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 28 (dom0)
trap number = 12
panic: page fault
cpuid = 3
time = 1622963058
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00dbc8c410
vpanic() at vpanic+0x181/frame 0xfe00dbc8c460
panic() at panic+0x43/frame 0xfe00dbc8c4c0
trap_fatal() at trap_fatal+0x387/frame 0xfe00dbc8c520
trap_pfault() at trap_pfault+0x4f/frame 0xfe00dbc8c580
trap() at trap+0x253/frame 0xfe00dbc8c690
calltrap() at calltrap+0x8/frame 0xfe00dbc8c690
--- trap 0xc, rip = 0x808d2212, rsp = 0xfe00dbc8c760, rbp = 
0xfe00dbc8c7a0 ---
zone_release() at zone_release+0x1f2/frame 0xfe00dbc8c7a0
bucket_drain() at bucket_drain+0xda/frame 0xfe00dbc8c7d0
bucket_cache_reclaim_domain() at bucket_cache_reclaim_domain+0x30a/frame 
0xfe00dbc8c830
zone_reclaim() at zone_reclaim+0x162/frame 0xfe00dbc8c880
uma_reclaim_domain() at uma_reclaim_domain+0xa2/frame 0xfe00dbc8c8b0
vm_pageout_worker() at vm_pageout_worker+0x41e/frame 0xfe00dbc8cb70
vm_pageout() at vm_pageout+0x21e/frame 0xfe00dbc8cbb0
fork_exit() at fork_exit+0x7e/frame 0xfe00dbc8cbf0
fork_trampoline() at fork_trampoline+0xe/frame 0xfe00dbc8cbf0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic

__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55   __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
   pc_curthread)));

One difference was that in the second and third panics the fault virtual
address was 0x0.  But the backtrace was the same.

Relevant info from the info.x files:
Architecture: amd64
Architecture Version: 2
Version String: FreeBSD 14.0-CURRENT #33 main-n247184-1970d693039: Sat Jun
5 09:58:55 CEST 2021

CPU: AMD Ryzen 5 1600 Six-Core Processor (3194.09-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x800f11  Family=0x17  Model=0x1  Stepping=1
  AMD Features=0x2e500800
  AMD 
Features2=0x35c233ff
  AMD Extended Feature Extensions ID EBX=0x1007

I have 16GiB of memory in the box.

The panic occurred while copying files from an internal SATA SSD to a
SATA 8TB disk in an external USB3 docking station.  The panic seems to
occur quite quickly, after only a few files have been copied.

swap is on a different internal disk.

I can poke around in the crash dumps with kgdb if anyone wants more
information.

-- 
Gary Jennejohn

Re: What happen to mailing list archives?

2021-06-07 Thread Mark Millard via freebsd-current 
On 2021-Jun-6, at 13:25, Mark Millard  wrote:

> Baptiste Daroussin  wrote on
> Date: Sun, 6 Jun 2021 10:53:49 +0200 :
> 
>> What has happended:
>> plan A: we migrated everything off mailman/pipermail seamlessly with 
>> redirection
>> and so on. We patched the new archiver to produce the same file names has
>> pipermail
>> 
>> Plan A worked fine up to a limit, there was plenty of hand edition in the 
>> past,
>> we we decided to move to plan B which is what is happening now.
>> 
>> Plan B: We keep a frozen version of the archives up to the migration date 
>> under
>> the pipermail directory and have the new archives created in the archives
>> directory.
>> 
>> All the pipermail archives have been restored as they were. The new archives
>> receives in their index a new link to point people to the pipermails archive 
>> if
>> looking for older archives.
>> 
>> this has been done a couple of hours ago (before Steve emails) during a 
>> window,
>> of ~ 10 hours, the mailing lists which slow traffic aka the one which didn't
>> received any email since the migration ended up with an empty "archives"
>> directory (aka a 404), a file with explanation and redirection to pipermail 
>> has
>> been installed there.
>> 
>> Some work is still needed for the mailing lists which has been transformed as
>> readonly, this will be done in the next couple of days
> 
> It is too bad that a reference to a "no examples yet"
> month, such as, (at the time I write this):
> 
> https://lists.freebsd.org/archives/freebsd-toolchain/2021-June/date.html
> 
> does not show at least (Date view specific example):
> 
>   • Other periods:[ Previous, Date view ] [ List of Folders ]
>   • Other: [ Actives mailing lists ] [ Archives from mailman's time ]
> 
> when there are prior months available in
> https://lists.freebsd.org/archives/ or show at least just:
> 
>   • Other: [ Actives mailing lists ] [ Archives from mailman's time ]
> 
> when no prior months are available there.
> 

Looks like there are missing months.

Using freebsd-hackers as an example:

https://lists.freebsd.org/archives/freebsd-hackers/index.html
shows the oldest month being "May 2021".

But . . .

https://lists.freebsd.org/pipermail/freebsd-hackers/
shows the most recent month being "September 2020".

So: 2020-Oct through 2021-Apr are completely missing.

Then, going for more detail for 2020-Sep and 2021-May . . .

https://lists.freebsd.org/archives/freebsd-hackers/2021-May/date.html
shows "Starting Tue May 18 2021 - 21:07:44 UTC".

https://lists.freebsd.org/pipermail/freebsd-hackers/2020-September/date.html
shows "Ending: Tue Sep 15 14:12:20 UTC 2020".

So there are about 2 more half-months missing.

Some other lists have other date ranges, some similar,
some not.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

2021-06-07 Thread Graham Perrin 

On 07/06/2021 07:10, Juraj Lutter wrote:

Bacause swap entry is in inapropriate format.

The line should read:

/dev/gpt/Sea1-18noneswapsw  0   0


Very well spotted, Juraj, but maybe a typo in your correction.

A clearer view of the original  where the 
device given to swap is:


/dev/gpt/Sea1-08

Re: Updating to FreeBSD-current, can't mount -uw / : update: seemingly solved

2021-06-07 Thread Juraj Lutter 



> On 7 Jun 2021, at 02:15, Thomas Mueller  wrote:
> 
> I updated a FreeBSD-current to the newest FreeBSD-current/14, buildworld took 
> 11:15 (hours:minutes), buildkernel was also successful, I even appeared to be 
> successful with "dhclient re0".
> 
> UPDATING file says to boot single-user after buildkernel and installkernel, 
> but then mount -u / or mount -uw / does not work as it did in previous times.
> 
> Results were
> 
> mount -uw / or mount -u / produces 
> fstab: /etc/fstab:2: Inappropriate file type or format
> fstab: /etc/fstab:2: Inappropriate file type or format

Bacause swap entry is in inapropriate format.

The line should read:

/dev/gpt/Sea1-18noneswapsw  0   0

otis

—
Juraj Lutter
o...@freebsd.org