Re: FreeBSD 13.0-RC4 and Nginx process "stuck" during restart

[Christos Chatzaras]

> On 31 Mar 2021, at 02:31, Jonathan T. Looney  wrote:
> 
> On Tue, Mar 30, 2021 at 12:01 PM Christos Chatzaras  > wrote:
> 
> Did you notice it with nginx too or something else? I also run monit, bind, 
> dovecot, postfix, mysql, php-fpm and pure-ftpd and didn't notice any restart 
> of these services to "stuck".
> 
> Yes, we noticed it in Nginx; however, we only saw it on a very small 
> percentage of servers. I think we might have seen one other instance with a 
> different process, but I can't remember for sure.
> 
> Jonathan


Hello,

With the patch I can't reproduce the issue. Can you please MFC it to 
13.0-STABLE and 13.0 ?
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: qlnxe driver not in 13.0 arm64

[Hans Petter Selasky]

On 3/30/21 8:31 PM, John-Mark Gurney wrote:

Daniel Morante via freebsd-stable wrote this message on Sun, Mar 28, 2021 at 
03:23 -0400:

I installed 13.0-RC3 ARM64 from the DVD ISO image
(FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso
).
There is no "if_qlnxe" kernel model present on the install media, or on
the system after installing.

Next I try to build a custom kernel. I add "device qlnxe" to the
configuration file as instructed in
https://www.freebsd.org/cgi/man.cgi?query=qlnxe&manpath=FreeBSD+13.0-current.


Running "make buildkernel KERNCONF=THUNDERX2" results in:

config: Error: device "qlnxe" is unknown

Is this module not available for ARM64 architecture?


Correct, this is only available for amd64.

HPS might have some more insight as to why it's amd64 only.

I have cc'd him.

It could be as simple as moving the qlnxe lines from files.amd64 to files,
but it does appear that qnlxe depends upon the Linux compat layer, which
may not be complete for arm64..



The LinuxKPI works for ARM64 aswell. Maybe the QLNXE driver is not 
tested for ARM64.


--HPS
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FreeBSD 13.0-RC4 and Nginx process "stuck" during restart

[Jonathan T. Looney]

On Wed, Mar 31, 2021 at 3:55 AM Christos Chatzaras 
wrote:

>
> With the patch I can't reproduce the issue. Can you please MFC it to
> 13.0-STABLE and 13.0 ?
>

Thanks for doing the testing! I've committed the MFC to stable/13. I'll
request re@ approval to pull it up to 13.0.

Jonathan
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: possibly silly question regarding freebsd-update

[tech-lists]

Hi,

On Tue, Mar 30, 2021 at 12:52:59PM -0500, Doug McIntyre wrote:

On Tue, Mar 30, 2021 at 05:54:03PM +0100, tech-lists wrote:

it just threw me that the thing-that-was-updated didn't update its
version information when queried. Absent sources, how can I tell it
was updated (apart from freebsd-version -u) ?


Comparing what the SA patch says it is doing at
https://security.freebsd.org/patches/SA-21:07/openssl-12.patch
appears to be only update the libcrypto library and not the openssl wrapper 
itself, you can
verify that after the 12.2-p5 patch was installed that the file

/lib/libcrypto.so.111

has been touched and is a newer date than what was on the machine prior to the 
patch.

Yes, this takes some knowledge of the specific patch, and what parts
contribute to what it is doing.

I don't know the specific decisions on when RELEASE backports security
patches vs. upgrading whole source trees.


Thanks for the clear explanation. 


--
J.


signature.asc
Description: PGP signature

Update to the 13.0-RELEASE schedule

[Glen Barber]

A small set of updates that we consider blocking the 13.0 release have
been brought to our attention.  As such, the 13.0-RELEASE schedule has
been updated to include a fifth release candidate (RC5).

The updated schedule is available on the FreeBSD Project website:

https://www.freebsd.org/releases/13.0R/schedule/

As usual, we will continue to consider critical bug fixes only for the
duration of this release cycle.

Thank you for your cooperation, and for your patience.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

Re: FreeBSD-13.0-RC1-amd64-disc1.iso unbootable on memstick

[Rodney W. Grimes]

> > Hi.
> > 
> > Are you shure you're using *.memstick.img?
> 
> I am shure I am NOT using memstick, as the subject says
> I am using:
>   FreeBSD-13.0-RC1-amd64-disc1.iso
> 
> 
> > *.iso are for optical drives.
> 
> Ah, not since 12.0, these are now "hybrid" type images that
> are designed to be written to either a dvd or memstick.
> 
> > If your memstick can perfectly (or at least enough for CD loader and
> > kernel) mimic optical drive, maybe with help by firmware, it would be
> > able to boot.
> > 
> > Otherwise, you should write FreeBSD-13.0-RC1-*-memstick.img with
> > dd. If you are using enough-sized memstick and amd64 arch PC,
> > FreeBSD-13.0-RC1-amd64-mrmstick.img should be preferred.
> > 
> > Note that if you downloaded smaller xz compressed image, you shoule
> > decompress it before writing.
> > 
> > If you are using *-memstick.img, something should need fixed.
> 
> I have tested the memstick image it works fine.
> 
> I have also done further investigation and this appears to be
> a Legacy/bios vs EFI mode issue.  All legacy only machines
> fail to boot with the above error, all dual mode machines
> must be forced into either EFI only, or dual mode/EFI first
> inorder to boot these images.  EFI only machines boot fine.
> 
> Is what it looks like is we have lost the ability to boot
> the .iso images in bios mode from a memory stick.  I have
> NOT done any testing on dvd media.
> 
> Further note all of this works fine upto and including BETA4
> on all my legacy bios machines, though I do see another
> environment that fails at BETA4 and continues to, but that
> is rather special, called ventoy:
>   https://www.ventoy.net/
> that environment is probably looking very much like a
> legacy BIOS system as to the way I have my ventoy setup.

This now works again at RC4.

> > On Sun, 7 Mar 2021 01:06:14 -0800 (PST)
> > "Rodney W. Grimes"  wrote:
> > 
> > > Glen,
> > >   Things get worse... I could at least boot the BETA4 .iso when
> > > I wrote it to a memstick.  I can NOT boot the RC1.  I have checked
> > > the sha512 of my image, wrote it twice, same results, I get:
> 
> I have now had Michael Dexter duplicate my findings, if he
> sets his machines to either legacy first, or legacy only
> he gets the same boot failures that I do when using the
>   FreeBSD-13.0-RC1-amd64-disc1.iso
> image.
> 
> > > 
> > > CD Loader 1.2
> > > 
> > > Bulding the boot loader arguments
> > > Looking up /BOOT/LOADER... File not found
> > > Looking up /boot/loader... File not found
> > > Boot failed
> > > 
> > > I have tried 2 different systems, all known to have booted and
> > > installed many many many FreeBSD's from prior .iso written to
> > > memstick.
> 
> Now expanded to 4 systems, 2 of which can do dual mode Legacy/EFI.

This issue is fixed in RC4, tested on:
Thankpads:  w530legacy & uefi
x230legacy & uefi
t400legacy
p61 legacy
Acer:   1410legacy

> > > Regards,
> > > Rod Grimes 
> > > rgri...@freebsd.org
> > Tomoaki AOKI
> Rod Grimes rgri...@freebsd.org
-- 
Rod Grimes rgri...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Update to the 13.0-RELEASE schedule

[The Doctor via freebsd-stable]

On Wed, Mar 31, 2021 at 03:58:51PM +, Glen Barber wrote:
> A small set of updates that we consider blocking the 13.0 release have
> been brought to our attention.  As such, the 13.0-RELEASE schedule has
> been updated to include a fifth release candidate (RC5).
> 
> The updated schedule is available on the FreeBSD Project website:
> 
> https://www.freebsd.org/releases/13.0R/schedule/
> 
> As usual, we will continue to consider critical bug fixes only for the
> duration of this release cycle.
> 
> Thank you for your cooperation, and for your patience.
> 
> Glen
> On behalf of: re@
> 

I rather that than a buggy realease.

Good show.

I will continue to test on my workstation running
a Supermicro X10sL7-f

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b  
We cannot change human failings by ridding ourselves of machines.  -unknown
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Update to the 13.0-RELEASE schedule

[Rainer Duffner]

> Am 31.03.2021 um 17:58 schrieb Glen Barber :
> 
> A small set of updates that we consider blocking the 13.0 release have
> been brought to our attention.  As such, the 13.0-RELEASE schedule has
> been updated to include a fifth release candidate (RC5).
> 
> The updated schedule is available on the FreeBSD Project website:
> 
> https://www.freebsd.org/releases/13.0R/schedule/
> 
> As usual, we will continue to consider critical bug fixes only for the
> duration of this release cycle.
> 
> Thank you for your cooperation, and for your patience.
> 
> Glen
> On behalf of: re@
> 



The truth is that a lot people don’t really start testing until the later 
release candidates.

So, having more of these release candidates with just refinements is a good 
thing, IMHO.



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Update to the 13.0-RELEASE schedule

[Lars Liedtke]

We don't even start before .1 is out.

Am 31.03.21 um 19:24 schrieb Rainer Duffner:
>
>> Am 31.03.2021 um 17:58 schrieb Glen Barber :
>>
>> A small set of updates that we consider blocking the 13.0 release have
>> been brought to our attention.  As such, the 13.0-RELEASE schedule has
>> been updated to include a fifth release candidate (RC5).
>>
>> The updated schedule is available on the FreeBSD Project website:
>>
>> https://www.freebsd.org/releases/13.0R/schedule/
>>
>> As usual, we will continue to consider critical bug fixes only for the
>> duration of this release cycle.
>>
>> Thank you for your cooperation, and for your patience.
>>
>> Glen
>> On behalf of:re@
>>
>
>
> The truth is that a lot people don’t really start testing until the later 
> release candidates.
>
> So, having more of these release candidates with just refinements is a good 
> thing, IMHO.
>
>
>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

-- 
---
punkt.de GmbH
Lars Liedtke
.infrastructure

Kaiserallee 13a 
76133 Karlsruhe

Tel. +49 721 9109 500
https://infrastructure.punkt.de
i...@punkt.de

AG Mannheim 108285
Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

FreeBSD 13.0-RC4 with filesystem quotas

[Christos Chatzaras]

Hello,

I create a bug report here about "mount" command not showing quotas enabled 
after a reboot.

More information here:

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


Can someone running 13.0-RC4 with quotas enabled to check if he can reproduce 
it?

Kind regards,
Christos Chatzaras
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?

[Doug Ambrisko]

On Fri, Mar 26, 2021 at 10:22:53AM -0400, Ed Maste wrote:
| On Thu, 25 Mar 2021 at 15:09, Chris  wrote:
| >
| > I can only state that I use it only occasionally, and that when I do. I
| > have had no problems with it. I'm glad that it's there when I need it.
| 
| Thanks for the reply. Can you comment on your use cases - in
| particular, did you use mirror, stripe, or raid5? If the first two
| then gmirror, gconcat, gstripe, and/or graid are suitable
| replacements.
| 
| I'm not looking to deprecate it just because it's old, but because of
| a mismatch between user and developer expectations about its
| stability.

It would be nice if graid got full support for RAID5 alteast I'm not sure
how much the others are used for that are not fully supported (RAID4,
RAID5, RAID5E, RAID5EE, RAID5R, RAID6, RAIDMDF) according to the man
page.  I started to hack in RAID5 full support and try to avoid writes
if members didn't change.  This limits our VROC support.

Thanks,

Doug A.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"