-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In a while I had not installed any package-upgrades, no idea how
dns-resolving became de-registered, when that was solved by manually
changing /etc/resolv.conf, sys-upgrade was a pure pleasure, it was so good,
boring myself to death almost in the
On 20/02/2021 00:08, Pete French wrote:
I suspect there are many variants on this out there! :-)
Well, guess what:
*
http://popeye.lapinbilly.eu/git/?p=zfsinstaller.git;a=blob;f=zfsinstall.sh;h=c63dfa803e1973006a752bd322e083217e97c67a;hb=HEAD
by the fact, this one has to be updated for 1
On 19/02/2021 22:30, Matthew D. Fuller wrote:
e.g., on one system BIOS-booting system, /boot/rewrite-bootcode.sh:
--
#!/bin/sh -x
for i in /dev/nda0 /dev/nda1; do
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ${i}
done
-
On Fri, Feb 19, 2021 at 10:26:15PM +0100 I heard the voice of
Kurt Jaeger, and lo! it spake thus:
>
> We do not need it automated. We need it to be described in enough
> detail that we can write that BOOTx64.efi to the proper place. If
> there are some steps to find out where to write it etc., fin
Hi,
On 19/02/2021 19:24, Kurt Jaeger wrote:
> I suspect that your 'zpool upgrade' enabled things that weren't enabled
> before. This caused the old boot blocks to no longer work.
Correct. That' s definitely the source of the booting issue.
> We should be bette
On Fri, Feb 19, 2021 at 2:42 PM David Marec wrote:
> On 19/02/2021 22:00, Warner Losh wrote:
> > We can't do that. gptzfsboot is for something else that we can't get rid
> > of: BIOS/CMS booting.
>
>
> My bad. I mean 'gptboot.efifat'.
>
>
> root@machine:~ # mdconfig -u 0 -f /boot/gptboot.efifat
>
On Fri, Feb 19, 2021 at 2:21 PM Kurt Jaeger wrote:
> Hi!
>
> > You can upgrade to 13 w/o hassle. The upgrade process doesn't
> automatically
> > upgrade the zpools. The only problem is if you also do a 'zpool upgrade'
> > which will change your zpool fe
On 19/02/2021 22:00, Warner Losh wrote:
We can't do that. gptzfsboot is for something else that we can't get rid
of: BIOS/CMS booting.
My bad. I mean 'gptboot.efifat'.
root@machine:~ # mdconfig -u 0 -f /boot/gptboot.efifat
root@machine:~ # mount -t msdosfs /dev/md0 /mnt
root@machine:~ # diff
Am 19.02.21 um 22:07 schrieb Warner Losh:
To avoid confusion and errors, I think a proper boot1.efifat should be put
back into the base system so that people don't have to track the above
recipe (which is likely to change).
There's no safe way to do this. The old process has been deprecated be
Hi!
> We can't do that. gptzfsboot is for something else that we can't get rid
> of: BIOS/CMS booting. It's never been used for EFI booting at all. There's
> no way to for EFI to use it, nor is there anyway for us to build it to just
> work. You have to copy BOOTx64.efi to your ESP. What we could
Hi!
> You can upgrade to 13 w/o hassle. The upgrade process doesn't automatically
> upgrade the zpools. The only problem is if you also do a 'zpool upgrade'
> which will change your zpool features. The fix is easy: upgrade your boot
> loader (bootx64.efi) on the
e better about upgrading boot blocks, but EFI is kinda new
> and
> > > kinda different than the other out-of-root-filesystem boot blocks
> we've had
> > > in the past, so there's still some rough edges.
> >
> > We run many systems at remote sites.
On Fri, Feb 19, 2021 at 1:41 PM David Marec
wrote:
> Hi,
>
> On 19/02/2021 19:24, Kurt Jaeger wrote:
>
> > I suspect that your 'zpool upgrade' enabled things that weren't enabled
> > before. This caused the old boot blocks to no longer work.
>
>
system boot blocks we've
> had
> > in the past, so there's still some rough edges.
>
> We run many systems at remote sites. If we can't remotely upgrade
> without drama from 12.x to 13.x, that would be a catastrophe.
>
> Any chance this can be fixed before 13.0-R
em boot blocks we've had
> > in the past, so there's still some rough edges.
>
> We run many systems at remote sites. If we can't remotely upgrade
> without drama from 12.x to 13.x, that would be a catastrophe.
>
> Any chance this can be fixed before 13.0-REL ?
rough edges.
We run many systems at remote sites. If we can't remotely upgrade
without drama from 12.x to 13.x, that would be a catastrophe.
Any chance this can be fixed before 13.0-REL ?
--
p...@opsec.eu+49 171 3101372Now what ?
On Fri, Feb 19, 2021 at 8:13 AM David Marec
wrote:
> I have just upgrade one machine from 12-stable to 13-stable.
>
> Everything runs fine until the main ZFS pool was upgraded.
>
> Then the box stopped booting.
>
> Thanks to a FreeBSD-13 Beta2 usb stick, I was able to fix t
I have just upgrade one machine from 12-stable to 13-stable.
Everything runs fine until the main ZFS pool was upgraded.
Then the box stopped booting.
Thanks to a FreeBSD-13 Beta2 usb stick, I was able to fix the issue by
copying `BOOTx64.efi` from the stick to the hard-drive.
Looking to
On 2021-Feb-12, at 23:03, Mark Millard wrote:
> Dewayne Geraghty dewayne at heuristicsystems.com.au wrote on
> Sat Feb 13 06:04:52 UTC 2021 :
>
>> The main list we used was:
>>
>> https://lists.freebsd.org/pipermail/svn-src-stable-12/
>>
>> but that appears dead.
>> . . .
>> https://lists.f
> On Feb 12, 2021, at 11:03 PM, Dewayne Geraghty
> wrote:
> As a change management task, I would hope that a mapping between svnlite
> and git would've become available for FreeBSD users, similar to the cvs
> to svnlite migration. I guess we need to create a test machine to
> figure out the co
> On Feb 12, 2021, at 5:31 PM, tech-lists wrote:
> As subject, where to get sources for 12-stable upgrade now? Is it still
> svn or is it git?
tl;dr: git is the source of truth, but there’s a bunch of details that might
matter.
The current source of truth is git repo
On Fri, 12 Feb 2021 at 23:11, tech-lists wrote:
>
> I saw on cgit that stable/12 was there. These older systems weekly
> update their sources via svn till now, in a cron job. At the time I wrote
> my message, I saw that svn still works, so was wondering which to use,
> which has the latest updates
On Sat, 13 Feb 2021 at 01:04, Dewayne Geraghty
wrote:
>
> Is there a timeline when svn for stable-12 /usr/src disappears?
stable/11 and stable/12 will exist in svn for at least as long as the
branches are supported - stable/12 expected EOL is June 30,2024. If
you're tracking stable you don't need
Dewayne Geraghty dewayne at heuristicsystems.com.au wrote on
Sat Feb 13 06:04:52 UTC 2021 :
> The main list we used was:
>
> https://lists.freebsd.org/pipermail/svn-src-stable-12/
>
> but that appears dead.
> . . .
> https://lists.freebsd.org/pipermail/svn-src-release/
>
> suspect also dead.
I
tech-lists tech-lists at zyxst.net wrote on
Sat Feb 13 04:11:46 UTC 2021 :
> Basically I'm asking "which is the source for truth now".
The official answer for 12 as I understand it: git,
where the commits are initially made before they are
converted into svn. (Thus svn is time delayed.)
But th
On 13/02/2021 1:11 pm, Mark Millard via freebsd-stable wrote:
>> As subject, where to get sources for 12-stable upgrade now? Is it still
>> svn or is it git?
>
> Probably your choice. But one thing that could
> bias towards svn is that the svn information
> spans identify
On Fri, Feb 12, 2021 at 06:11:25PM -0800, Mark Millard via freebsd-stable wrote:
But I've no clue if such would be important to what you might need
to do with 12.
you're right, I should have been more detailed.
My context is in looking after various 12-stable machines.
Basically I'm asking "
> As subject, where to get sources for 12-stable upgrade now? Is it still
> svn or is it git?
Probably your choice. But one thing that could
bias towards svn is that the svn information
spans identifying both the svn and the git
material but the git commit does not identify
the svn materia
Hi,
As subject, where to get sources for 12-stable upgrade now? Is it still
svn or is it git?
thanks,
--
J.
signature.asc
Description: PGP signature
On 1/23/2021 11:52 PM, John Kennedy wrote:
> On Sat, Jan 23, 2021 at 03:59:07PM -0500, mike tancsa wrote:
>> I noticed when doing a src upgrade on a test zfs machine, I didnt
>> get prompted to re-install the boot blocks after upgrading the pool post
>> first reboot.
On Sat, Jan 23, 2021 at 03:59:07PM -0500, mike tancsa wrote:
> I noticed when doing a src upgrade on a test zfs machine, I didnt
> get prompted to re-install the boot blocks after upgrading the pool post
> first reboot. I got a whole mess of feature upgrades just fine, but do
> I
Hi All,
I noticed when doing a src upgrade on a test zfs machine, I didnt
get prompted to re-install the boot blocks after upgrading the pool post
first reboot. I got a whole mess of feature upgrades just fine, but do
I not need to do a
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i
On Fri, Jul 10, 2020 at 02:25:02PM -0500, Kyle Evans wrote:
> > So one recipe doesn't even seem to make the freebsd-boot partition, so is
> > it
> > optional for a pure UEFI boot? Should we always gpart-bootcode it if it
> > exists
> > and upgrade BOOTx64.ef
On Fri, Jul 10, 2020 at 02:28:12PM -0500, Kyle Evans wrote:
> >
> > There was one question I forgot to ask:
> > Could I have known that my method of updating the ESP was not correct?
> > If so, where is this documented?
> >
>
> It is probably unlikely, to be honest. I don't know that we do a good
> On Jul 10, 2020, at 2:44 PM, Guido van Rooij wrote:
>
> On Fri, Jul 10, 2020 at 08:29:03PM +0200, Guido van Rooij wrote:
>> On Thu, Jul 09, 2020 at 08:24:54AM -0500, Kyle Evans wrote:
>>> On Thu, Jul 9, 2020 at 8:12 AM Guido van Rooij wrote:
>>>>
>
On Fri, Jul 10, 2020 at 1:44 PM Guido van Rooij wrote:
>
> On Fri, Jul 10, 2020 at 08:29:03PM +0200, Guido van Rooij wrote:
> > On Thu, Jul 09, 2020 at 08:24:54AM -0500, Kyle Evans wrote:
> > > On Thu, Jul 9, 2020 at 8:12 AM Guido van Rooij wrote:
> > > >
&g
On Thu, Jul 9, 2020 at 4:20 PM John Kennedy wrote:
>
> On Thu, Jul 09, 2020 at 08:24:54AM -0500, Kyle Evans wrote:
> > On Thu, Jul 9, 2020 at 8:12 AM Guido van Rooij wrote:
> > >
> > > I did a zpool upgrade -a to enable large_dnode and spacemap_v2.
> > >
On Fri, Jul 10, 2020 at 08:29:03PM +0200, Guido van Rooij wrote:
> On Thu, Jul 09, 2020 at 08:24:54AM -0500, Kyle Evans wrote:
> > On Thu, Jul 9, 2020 at 8:12 AM Guido van Rooij wrote:
> > >
> > > I did a zpool upgrade -a to enable large_dnode and spacemap_v2.
> >
On Thu, Jul 09, 2020 at 08:24:54AM -0500, Kyle Evans wrote:
> On Thu, Jul 9, 2020 at 8:12 AM Guido van Rooij wrote:
> >
> > I did a zpool upgrade -a to enable large_dnode and spacemap_v2.
> > After that, I did:
> > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2
On Thu, Jul 09, 2020 at 08:24:54AM -0500, Kyle Evans wrote:
> On Thu, Jul 9, 2020 at 8:12 AM Guido van Rooij wrote:
> >
> > I did a zpool upgrade -a to enable large_dnode and spacemap_v2.
> > After that, I did:
> > gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2
On Thu, Jul 9, 2020 at 8:50 AM Pete French wrote:
>
>
>
> On 09/07/2020 14:36, Kyle Evans wrote:
> > We haven't quite standardized on a good process yet, IMO, but for
> > right now the correct process is to just mount the ESP and replace
> > loader.efi with your system's updated /boot/loader.efi.
On 09/07/2020 14:36, Kyle Evans wrote:
We haven't quite standardized on a good process yet, IMO, but for
right now the correct process is to just mount the ESP and replace
loader.efi with your system's updated /boot/loader.efi. At some point
we'll standardize a mountpoint for the ESP and mount
e upgraded then ? I
> dont have any EFI machines...yet. But one day I will, and I was
> assuming that an upgrade would be done using the above lines too.
>
Nope. An EFI partition is just a "funky" MSDOS (FAT) one, really. Thus
the upgrade of the loader on one would be just a
rest, how should the ESP partition be upgraded then ? I dont
> have any EFI machines...yet. But one day I will, and I was assuming that
> an upgrade would be done using the above lines too.
>
We haven't quite standardized on a good process yet, IMO, but for
right now the correct process is
/loader.efi where loader.efi is /boot/loader.efi. You will
want to rebuild this as such, and that may fix part of your problem.
Out of interest, how should the ESP partition be upgraded then ? I dont
have any EFI machines...yet. But one day I will, and I was assuming that
an upgrade would be done using
On Thu, Jul 9, 2020 at 8:12 AM Guido van Rooij wrote:
>
> I did a zpool upgrade -a to enable large_dnode and spacemap_v2.
> After that, I did:
> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0
> gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada1
> and:
> gp
I did a zpool upgrade -a to enable large_dnode and spacemap_v2.
After that, I did:
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada1
and:
gpart bootcode -p /boot/boot1.efifat -i 1 ada0
gpart bootcode -p /boot/boot1.efifat -i 1
Hi!
It seems that clang-6 supplied with 11.2 cannot build clang-9 in stable/11 for
i386,
so buildworld is broken. Details are here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246274
___
freebsd-stable@freebsd.org mailing list
https://lists.freeb
Hi!
It seems that clang-6 supplied with 11.2 cannot build clang-9 in stable/9 for
i386,
so buildworld is broken. Details are here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246274
___
freebsd-stable@freebsd.org mailing list
https://lists.freebs
Hi,
On Wed, Apr 22, 2020 at 01:48:00PM -0700, Pete Wright wrote:
> On 4/22/20 1:15 PM, Wolfgang Zenker wrote:
>> I went from 12.1-STABLE r359345 to r360192 on an Acer C720 Notebook.
>> The system now crashes on loading /boot/modules/i915kms.ko
>> I build and install graphics/drm-kmod and graphics/
On 4/22/20 1:15 PM, Wolfgang Zenker wrote:
Hi,
I went from 12.1-STABLE r359345 to r360192 on an Acer C720 Notebook.
The system now crashes on loading /boot/modules/i915kms.ko
I build and install graphics/drm-kmod and graphics/drm-fbsd12.0-kmod
together with the kernel.
If i915kms.ko is loaded
Hi,
I went from 12.1-STABLE r359345 to r360192 on an Acer C720 Notebook.
The system now crashes on loading /boot/modules/i915kms.ko
I build and install graphics/drm-kmod and graphics/drm-fbsd12.0-kmod
together with the kernel.
If i915kms.ko is loaded via kld_list in /etc/rc.conf at boot, the scre
> On 9 Jan 2020, at 05:24, Rick Macklem wrote:
>
> The attached patch changes the xid to be a global for all "connections" for
> the krpc UDP client.
>
> You could try it if you'd like. It passed a trivial test, but I don't know why
> there is that "misfeature" comment means, so I don't know i
Braniss
Sent: Wednesday, January 8, 2020 12:08 PM
To: Rick Macklem
Cc: Richard P Mackerras; Adam McDougall; freebsd-stable@freebsd.org
Subject: Re: nfs lockd errors after NetApp software upgrade.
top posting NetAPP reply:
…
Here you can see transaction ID (0x5e15f77a) being used over
niqueness of this field.
rick
From: Daniel Braniss
Sent: Wednesday, January 8, 2020 12:08 PM
To: Rick Macklem
Cc: Richard P Mackerras; Adam McDougall; freebsd-stable@freebsd.org
Subject: Re: nfs lockd errors after NetApp software upgrade.
top posting NetA
Dougall; freebsd-stable@freebsd.org
Subject: Re: nfs lockd errors after NetApp software upgrade.
top posting NetAPP reply:
…
Here you can see transaction ID (0x5e15f77a) being used over port 886 and the
NFS server successfully responds.
44806952020-01-08 12:20:54 132.
top posting NetAPP reply:
…
Here you can see transaction ID (0x5e15f77a) being used over port 886 and the
NFS server successfully responds.
44806952020-01-08 12:20:54 132.65.116.111
132.65.60.56 NLM 0x5e15f77a (1578497914) 886
V4
Richard P Mackerras wrote:
>Hi,
>
>We had some bully type workloads emerge when we moved a lot of block
>storage from old XIV to new all flash 3PAR. I wonder if your IMAP issue
>might have emerged just because suddenly there was the opportunity with all
>flash. QOS is good on 9.x ONTAP. If anyone s
Hi,
We had some bully type workloads emerge when we moved a lot of block
storage from old XIV to new all flash 3PAR. I wonder if your IMAP issue
might have emerged just because suddenly there was the opportunity with all
flash. QOS is good on 9.x ONTAP. If anyone says it’s not then they last
looke
systems and notes they are "up" if they get
> replies to these pokes. It uses IP broadcast at some point.)
>
> Now, maybe switching to TCP will make the RPCs reliable enough that it will
> work, or maybe it won't? (It certainly sounds like the Netapp upgrade is
>
o realize that any network
unreliability
or partitioning could result in trouble.
The kernel RPC layer may do some retries of the RPCs (this is controlled by the
parameters set for the RPC), but at some point the protocol asks the NSM
(rpc.statd) if the machine is "up" and then uses
we haven’t had any issues with it for years, so you must have done
> something good
>
> cheers,
> danny
>
>
> rick
>
> cheers,
> danny
>
> rick
>
> Cheers
>
> Richard
> (NetApp admin)
>
> On Wed, 18 Dec 2019 at 15:46, Daniel B
18 Dec 2019 at 15:46, Daniel Braniss
mailto:da...@cs.huji.ac.il><mailto:da...@cs.huji.ac.il>>
wrote:
On 18 Dec 2019, at 16:55, Rick Macklem
mailto:rmack...@uoguelph.ca><mailto:rmack...@uoguelph.ca>>
wrote:
Daniel Braniss wrote:
Hi,
The server with the problems is runni
ith it for years, so you must have done
>> something good
>>
>> cheers,
>> danny
>>
>>>
>>> rick
>>>
>>> cheers,
>>> danny
>>>
>>>> rick
>>>>
>>>> Cheers
>&
nd we haven’t had any issues with it for years, so you must have done
> something good
>
> cheers,
> danny
>
>>
>> rick
>>
>> cheers,
>>danny
>>
>>> rick
>>>
>>> Cheers
>>>
>>> Richard
>>>
> (NetApp admin)
>>>
>>> On Wed, 18 Dec 2019 at 15:46, Daniel Braniss
>>> mailto:da...@cs.huji.ac.il>> wrote:
>>>
>>>
>>>> On 18 Dec 2019, at 16:55, Rick Macklem
>>>> mailto:rmack...@uoguelph.ca>> wrote:
>>&
Hi,
At ONTAP 9.3P6 there is a possible LACP group issue after upgrade. Have you
checked any LACP groups,
These should not be a problem but I assume network interfaces are at the
home ports, not on slower ports or something silly. It is marginally better
if the traffic goes direct to the node where
t;
>> On Wed, 18 Dec 2019 at 15:46, Daniel Braniss
>> mailto:da...@cs.huji.ac.il>> wrote:
>>
>>
>>> On 18 Dec 2019, at 16:55, Rick Macklem
>>> mailto:rmack...@uoguelph.ca>> wrote:
>>>
>>> Daniel Braniss wrote:
>>&
; mailto:rmack...@uoguelph.ca>> wrote:
>>
>> Daniel Braniss wrote:
>>
>>> Hi,
>>> The server with the problems is running FreeBSD 11.1 stable, it was working
>>> fine for >several months,
>>> but after a software upgrade of our NetAPP
;
> Cheers
>
> Richard
> (NetApp admin)
>
> On Wed, 18 Dec 2019 at 15:46, Daniel Braniss
> mailto:da...@cs.huji.ac.il>> wrote:
>
>
>> On 18 Dec 2019, at 16:55, Rick Macklem
>> mailto:rmack...@uoguelph.ca>> wrote:
>>
>> Daniel Braniss wrote:
Daniel Braniss
mailto:da...@cs.huji.ac.il>> wrote:
> On 18 Dec 2019, at 16:55, Rick Macklem
> mailto:rmack...@uoguelph.ca>> wrote:
>
> Daniel Braniss wrote:
>
>> Hi,
>> The server with the problems is running FreeBSD 11.1 stable, it was working
>>
t;
> Richard
> (NetApp admin)
>
> On Wed, 18 Dec 2019 at 15:46, Daniel Braniss wrote:
>
>>
>>
>> > On 18 Dec 2019, at 16:55, Rick Macklem wrote:
>> >
>> > Daniel Braniss wrote:
>> >
>> >> Hi,
>> >> The server
t; Hi,
> >> The server with the problems is running FreeBSD 11.1 stable, it was
> >> working fine for >several months,
> >> but after a software upgrade of our NetAPP server it’s reporting many
> >> lockd errors >and becomes catatonic,
> >> ...
> &
Wed, 18 Dec 2019 at 15:46, Daniel Braniss wrote:
>
>
> > On 18 Dec 2019, at 16:55, Rick Macklem wrote:
> >
> > Daniel Braniss wrote:
> >
> >> Hi,
> >> The server with the problems is running FreeBSD 11.1 stable, it was
> working fine for >se
> On 18 Dec 2019, at 16:55, Rick Macklem wrote:
>
> Daniel Braniss wrote:
>
>> Hi,
>> The server with the problems is running FreeBSD 11.1 stable, it was working
>> fine for >several months,
>> but after a software upgrade of our NetAPP server it
Daniel Braniss wrote:
>Hi,
>The server with the problems is running FreeBSD 11.1 stable, it was working
>fine for >several months,
>but after a software upgrade of our NetAPP server it’s reporting many lockd
>errors >and becomes catatonic,
>...
>Dec 18 13:11:02 moo-
Hi,
The server with the problems is running FreeBSD 11.1 stable, it was working
fine for several months,
but after a software upgrade of our NetAPP server it’s reporting many lockd
errors and becomes catatonic,
...
Dec 18 13:11:02 moo-09 kernel: nfs server fr-06:/web/www: lockd not responding
g on
behalf of Doug McIntyre
Sent: December 12, 2019 05:50
To: Mel Pilgrim
Cc: freebsd-stable@freebsd.org
Subject: Re: 11.3->12.1 upgrade, pwd db not rehashed after adding ntpd user?
On Wed, Dec 11, 2019 at 05:44:27PM -0800, Mel Pilgrim wrote:
> I used freebsd-update to upgrade several 11.3-p5
On Wed, Dec 11, 2019 at 05:44:27PM -0800, Mel Pilgrim wrote:
> I used freebsd-update to upgrade several 11.3-p5 systems to 12.1-p1.
> The etc update process added the ntpd/ntpd user/group. It showed the
> line changes in the plaintext passwd/group files, but the process
> appears
I used freebsd-update to upgrade several 11.3-p5 systems to 12.1-p1.
The etc update process added the ntpd/ntpd user/group. It showed the
line changes in the plaintext passwd/group files, but the process
appears to omit the pwd_mkdb step.
After the upgrade, ntpd fails to start:
# service
I upgraded our first machine from 11.2-p10 to 11.3-RELEASE from the
sources with GENERIC kernel.
I did not run "make delete-old" but some installed apps, like tmux,
cannot run anymore:
# tmux
Shared object "libevent-2.1.so.6" not found, required by "tmux"
Then I found some services are not run
On Fri, 26 Apr 2019 15:50-0500, Karl Denninger wrote:
> pkg:
> http://pkg.FreeBSD.org/FreeBSD:12:amd64/latest/All/dovecot-2.3.5.txz:
> Not Found
The most recent package is dovecot-2.3.5.2.txz.
Sometimes pkg has stale data in its cache.
Try running pkg update -f to refresh the cache.
--
Trond.
[\u@NewFS /home/karl]# pkg upgrade dovecot
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):
Installed packages to be UPGRADED:
dovecot: 2.3.4.1 -> 2.3.5
Number
On Mon, Apr 15, 2019 at 08:28:39AM +, Marcin Cieslak wrote:
> On Mon, 15 Apr 2019, Konstantin Belousov wrote:
>
> > On Mon, Apr 15, 2019 at 08:01:27AM +, Marcin Cieslak wrote:
> > >
> > > 50766 mysqld CALL _umtx_op(0x966eaa0,UMTX_OP_RESERVED0,0x18cab,0,0)
> > > 50766 mysqld RET _
On Mon, 15 Apr 2019, Konstantin Belousov wrote:
> On Mon, Apr 15, 2019 at 08:01:27AM +, Marcin Cieslak wrote:
> >
> > 50766 mysqld CALL _umtx_op(0x966eaa0,UMTX_OP_RESERVED0,0x18cab,0,0)
> > 50766 mysqld RET _umtx_op -1 errno 45 Operation not supported
> I believe these ops were remo
On Mon, Apr 15, 2019 at 08:01:27AM +, Marcin Cieslak wrote:
> Hello,
>
> for archival purposes I am running an ancient (__FreeBSD_version 602100)
> jail with mysqld inside.
>
> This was working fine when the jail host was running 10.4. After upgrade to
> 12.x
>
Hello,
for archival purposes I am running an ancient (__FreeBSD_version 602100)
jail with mysqld inside.
This was working fine when the jail host was running 10.4. After upgrade to 12.x
(r345375) mysqld process starts but it hangs before PID is created and the
socket opened.
Quick ktrace on
I’m probably just missing something, but I don’t see anything obviously wrong
and Google is not being helpful.
I have em0 and wlan0 bridged on my internal network, but wireless devices
cannot access wired devices and vice versa - except for the bridging host
itself. That used to work before I u
Lee Damon wrote on 2019/02/28 17:18:
I have three old FBSD 10 boxes that I need to upgrade. Ordinarily I do
this by building a new box with the latest OS then migrating services
and data. Unfortunately I don't have that option this time, the upgrade
has to happen in-place. My plan is
28.02.2019 23:18, Lee Damon wrote:
> I have three old FBSD 10 boxes that I need to upgrade. Ordinarily I do this
> by building a new box with the latest OS then migrating services and data.
> Unfortunately I don't have that option this time, the upgrade has to happen
> in-pla
Hi,
> On 28 Feb 2019, at 16:18, Lee Damon wrote:
>
> I have three old FBSD 10 boxes that I need to upgrade. Ordinarily I do this
> by building a new box with the latest OS then migrating services and data.
> Unfortunately I don't have that option this time, the upgrade
I have three old FBSD 10 boxes that I need to upgrade. Ordinarily I do
this by building a new box with the latest OS then migrating services
and data. Unfortunately I don't have that option this time, the upgrade
has to happen in-place. My plan is to go from 10 to 11 then from 11 to 12.
ailed to
start after the upgrade.
So is this a bug, or is there some policy that everything immediately
under /usr/local should be owned by root?
M.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/fr
On 18/01/2019 10:34, Thomas Steen Rasmussen wrote:
On 1/16/19 8:16 PM, Thomas Steen Rasmussen wrote:
On 1/16/19 6:56 PM, Steven Hartland wrote:
PS: are you going to file a PR ?
Yes here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235005
Hello all,
A quick follow up for the archi
On 1/16/19 8:16 PM, Thomas Steen Rasmussen wrote:
On 1/16/19 6:56 PM, Steven Hartland wrote:
PS: are you going to file a PR ?
Yes here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235005
Hello all,
A quick follow up for the archives:
Steven Hartland smh@ found the issue and creat
On 1/16/19 6:56 PM, Steven Hartland wrote:
PS: are you going to file a PR ?
Yes here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235005
You could also try setting net.pfsync.pfsync_buckets="1" in
/boot/loader.conf which reading the code should ensure all items are
processed in a
On 16/01/2019 17:33, Pete French wrote:
I have confirmed that pfsync is the culprit. Read on for details.
Excellent work. I;m home now, so won't get a chnace to out this into
practice until tomorrow unfortunately, but it's brilliant that you have
confirmed it.
I tried disabling pfsync and re
> I have confirmed that pfsync is the culprit. Read on for details.
Excellent work. I;m home now, so won't get a chnace to out this into
practice until tomorrow unfortunately, but it's brilliant that you have
confirmed it.
> I tried disabling pfsync and rebooting both nodes, they came up as
> MA
On 1/16/19 3:53 PM, Steven Hartland wrote:
I have confirmed that pfsync is the culprit. Read on for details.
I can't see how any of those would impact carp unless pf is now
incorrectly blocking carp packets, which seems unlikely from that commit.
Well I would agree, but nevertheless, here w
> I can't see how any of those would impact carp unless pf is now
> incorrectly blocking carp packets, which seems unlikely from that commit.
Just looking at the code it does seem unlikely, true - but my working
system does not run pf+pfsync and the non working one does, so it is
suspiciously in
1 - 100 of 1395 matches
Mail list logo
