"xpt_config still waiting" solved: bad disk
Hi.. I just wanted to report a bug with FreeBSD 8.2-RELEASE-p5, as packaged with FreeNAS 8.0.3. A hard drive failed in a strange way, in that it was detected by the computer's BIOS and firmware, but did not reply to information requests from the kernel. The boot process stopped with a series of timeout messages, ending with the message: run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config Removing the affected hard drive fixed the problem; the other 5 identical drives (3TB Hitachi SATA) in the system were unaffected, and that SATA port was tested with a working drive and was ok. So, the problem is hard to reproduce without a drive damaged this particular way, but if you could allow booting to continue after this error is triggered, that'd be helpful for future users. Thanks. -- freebsd-sta...@ch.pkts.ca -- just another bug reporter _______ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
php5 port compile problem (start again)
Hi, When I last asked about problems portinstalling php5 I was given this advice: > When compiling php 5 recently here is what i had to do > i used the port in /usr/ports/lang/php5-extensions it gives you > options for what kind of support you want (socket, ftp, etc) and it > also installs php. You will probably have to recompile apache as well > (I did) but it was the best way i could get it to work. and > What I found was that you need bind9 for php5, so install bind9 and your > problem is solved. I found that trying to install the php5-extensions it failed in the same place during php5 compilation so, biting the bullet, I installed the bind9 port today - but no luck! Note that I tried with the php5-cgi port this time: ext/standard/dns.o(.text+0x1a36): In function `zif_dns_get_record': : undefined reference to `res_ninit' ext/standard/dns.o(.text+0x1a9c): In function `zif_dns_get_record': : undefined reference to `res_nmkquery' ext/standard/dns.o(.text+0x1ace): In function `zif_dns_get_record': : undefined reference to `res_nsend' ext/standard/dns.o(.text+0x1c5a): In function `zif_dns_get_record': : undefined reference to `res_nclose' *** Error code 1 Stop in /usr/ports/www/php5-cgi/work/php-5.0.2. *** Error code 1 Stop in /usr/ports/www/php5-cgi. Now what do I do? cheers, -- Joel Hatton -- Security Analyst| Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland| WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4.x can't read 5.x dump?
Hi, I'm backing up a 5.x machine at the moment with this command: dump -0Lau -b128 -f - /var | gzip -2 | ssh FreeBSD4 dd of=aacd0s1f.gz After the dump finishes, I try to read the file on the 4.x destination: # gzip -dc aacd0s1a.gz | restore -ivf - Verify tape and initialize maps Tape is not a dump tape I can scp the file back to the 5.x machine and it loads just fine, so what gives? This type of failure is somewhat scary for me right now, given that I may have to restore files to another destination that may not be 5.x based. thanks, -- Joel Hatton -- Security Analyst| Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland| WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.1-RC2 available
Scott Long wrote: > FreeBSD 6.1-RC2 is available for download. This is the last RC before > the release. Thanks, Scott. I've been running RELENG_6 (synching periodically) on my amd64 iNET2340 from FreeBSD Systems for some time now with no problems. (Though I have given up trying to get JDK 1.5 to build -- what a pain.) Any chance for an update to the 6.1 release schedule? http://www.freebsd.org/releases/6.1R/schedule.html Also, is the 6.1 Open Issues page accurate? There are several issues listed there which your email did not cover. http://www.freebsd.org/releases/6.1R/todo.html Thanks again, Matt _______ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sshd on 5.4-STABLE broken!?
> Is this of any help? I can produce the complete debugging information > if that is of interest. > Pressing return three times instead of ctrl-c > if password is requested, produces an additional > debug3: PAM: sshpam_thread_cleanup entering > and exits sshd Holger, FWIW, I posted this question on freebsd.misc the other day, in an attempt to tackle the same issue in a different way - maybe someone here can help along these lines? I'd like to know the correct way to incorporate skey support into my sshd binary on R5.3. From /usr/src/crypto/openssh/INSTALL, I can see that the argument I need is --with-skey=PATH and I know that the makefiles are under /usr/src/secure, but I'm guessing that I should be able to add an entry to a top-level Makefile or Makefile.local, maybe even to /etc/make.conf before compiling and installing? My theory is that perhaps without PAM it will be ok? -- Joel Hatton -- Security Analyst| Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland| WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Incorrect super block--help!
> Hey, newb BSDer here with a question > > I've got a brand new 5.4 install. I'm trying to mount the CDROM. As root, > I type: > > mount /dev/acd0 /cdrom > > and I get "incorrect super block" error message after a bit of CD activity, > and no mount. I've tried a CD-RW I burned (the FreeBSD install disk I > installed from) and an old copy of SimCity 2000, neither worked, same error > message. > > I'm stuck. Any ideas? The drive could have just started to fail. Sounds unlikely, but it's the kind of error you might see. Does it work with another OS, or can you substitute another drive and try that way? joel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Incorrect super block--help!
> You're trying to mount it as a rw disc and as a UFS file system > > mount -r -t cd9660 /dev/acd0 /cdrom > > Mark Space wrote: > > Hey, newb BSDer here with a question > > > > I've got a brand new 5.4 install. I'm trying to mount the CDROM. As > > root, I type: > > > > mount /dev/acd0 /cdrom > > Of course, this is dead right and ignore my previous response. You'll find that the cdrom drive is almost certainly in /etc/fstab as the other responder mentioned - to mount it with the default fstab options (which should work just fine): mount /cdrom The way you tried will indeed attempt to mount the device by default as a rw UFS file system. Sorry for the wrong steer. joel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 6.0 RC1 usbd.conf (and installation comments)
> Just a few words on that point ... after some use of mergemaster, it > seems to me that a big part of /etc have to be update blindly for most > users (things in rc.d, and some other places where there's files that > haven't to changed or that are system script that most users won't > modify.) > > I hadn't time to add a possibility for mergemaster to perform blind > updates of such files[1], but it seems not so complicated to do so. > > Does anyone else thinks that's an interesting idea ? > > [1] : providing a list of directories and/or files to mergemaster for > which blind updates could be perform, for example ... Interesting, but for mine it sounds like more complexity than needed. I'd be happy with a simple option to automatically replace any files with newer CVS ID, and just make sure I took a backup of /etc before beginning. cheers, joel -- Joel Hatton -- Security Analyst| Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland| WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysinstall options
Frank Tegtmeyer <[EMAIL PROTECTED]> writes: | I thought that the -RELEASE system is made from the -STABLE cvs | branch so that this is in effect the same. Is this wrong? No and yes. RELEASE is taken from STABLE, but that doesn't mean that STABLE is RELEASE. When a new release is being made, it is always tested rigorously. STABLE is a branch undergoing constant development, meaning that there's no guarantee of its stability. It might contain development code that could be unstable. Not really bad, but not rock solid. Tracking RELEASE is a lot more stable. If you have, say, RELENG_4_7 in your supfile, you get security fixes for 4.7-RELEASE. This doesn't happen very often unless many security holes are found. This is the way to go if you are dependent on stability. If you track RELENG_4 (= STABLE) you get more new features, but sometimes at the cost of stability. -- SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: ATA failure with 4.6.2 & 250GB drive?
Hi Scott, > OK, swapped out the cable (from an 80- to 40-wire one, as it happened, > although that should make no difference on a UDMA33 controller). Same > errors appeared again while the backups were running. FWIW, I have had _major_ problems (ie drive failure) when trying to use an 80 wire cable on a UDMA33 board with an ATA66 drive - I would recommend never using 80 wire cables on controllers that don't support UDMA66 or better. The reverse, using 80 wire cables on UDMA66 (or better) controllers with ATA33 drives is ok, however, and I've done that successfully. Once bitten, twice shy :) regards, -- joel -- AusCERT, ITS, Uni of Qld, Australia -- hotline: [+61] [07] 33654417 my opinions in this email are not endorsed by AusCERT or Uni of Qld this message may not be onforwarded without my expressed permission ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with 4.10 and mysql
> Could I ask how you are running MySQL in your jail? I have installed MySQL > in a jail environment on 4.10, but it won't start due to: > > Bind on unix socket: Permission denied In answer to my own question, I discovered that the permissions on my jailed /tmp were incorrect. Changing to the correct 1777 allows mysql to run just fine. -- Joel Hatton -- Security Analyst and FIRST Representative | Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT| Fax: +61 7 3365 7031 The University of Queensland | WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
tripwire port broken in 5.3b7
Hi, Is there any chance that tripwire will be fixed in the near future, or should I investigate a substitute? And if so, which one? Otherwise, has anyone tried just compiling the source unchanged? thanks, -- Joel Hatton -- Security Analyst| Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland| WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
X applications crashing under 5.3BETA7 and X.org
I have a problem with applications crashing. Xterm will launch and run ok, but any attempt to mouse select text will cause an immediate crash with this output on the console: xterm: warning, error event received: X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 18 (X_ChangeProperty) Atom id in failed request: 0x17f Serial number of failed request: 131 Current serial number in output stream: 133 If I attempt to run a gui app like wish, it won't launch and produces this error: %wish8.4 X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 18 (X_ChangeProperty) Atom id in failed request: 0x1a5 Serial number of failed request: 12 Current serial number in output stream: 15 I'm running 5.3 on the server and desktop, with X forwarded over an ssh tunnel. I don't experience this issue when performing the same operation but with a Microsoft Windows/XWin32 desktop. Is this an issue with the X.org Xserver on the 5.3 workstation? Let me know what other detail I can provide if needed. cheers, joel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: X applications crashing under 5.3BETA7 and X.org
> On Tue, 2004-10-19 at 10:13 +1000, [EMAIL PROTECTED] wrote: > > I have a problem with applications crashing. Xterm will launch and run ok, > > but any attempt to mouse select text will cause an immediate crash with > > this output on the console: > > > > xterm: warning, error event received: > > X Error of failed request: BadAtom (invalid Atom parameter) > > Major opcode of failed request: 18 (X_ChangeProperty) > > Atom id in failed request: 0x17f > > Serial number of failed request: 131 > > Current serial number in output stream: 133 > > > > Hi, > > this isn't a Xorg issue it's just a X11 forwarding issue. > Newer OpenSSH versions don't use trusted X11 forwarding by default which > results in the above error if you try to cut & paste. > Just use trusted X11 forwarding and all should be fine. > > Either ssh -Y server-hostname or add "ForwardX11Trusted yes" to your ssh > config file. > > > -- > Sascha > Thanks, Sascha. Works perfectly now. I'd never even heard of trusted X11 forwarding before... -- Joel Hatton -- Security Analyst| Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland| WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Where to get 5.3 Stable
> [EMAIL PROTECTED] writes: > > Everyone keep on saying they have problem running 5.3 stable. But is > > 5.3 stable really out? I can't find it anywhere. > > 5.3-RELEASE isn't out yet, but you can get 5.3-STABLE by cvsup'ing > the RELENG_5 tag. > As RELENG_5_3 has been branched, I have been tracking this release - I presume this is the same as RELENG_5 until 5.3 RELEASE is frozen (already?), but will then only change for security patches. (Someone please correct me if this is an incorrect assumption) joel ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
php5 port compile problem
Hi, After a make update in /usr/src today (about an hour ago): ext/standard/dns.lo(.text+0x1c6c): In function `.L163': : undefined reference to `res_ninit' ext/standard/dns.lo(.text+0x1cd8): In function `.L163': : undefined reference to `res_nmkquery' ext/standard/dns.lo(.text+0x1d0a): In function `.L163': : undefined reference to `res_nsend' ext/standard/dns.lo(.text+0x1e9a): In function `.L163': : undefined reference to `res_nclose' *** Error code 1 Stop in /usr/ports/lang/php5/work/php-5.0.2. *** Error code 1 Stop in /usr/ports/lang/php5. ** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portinstall88483.0 make DEPENDS_TARGET=package ** Fix the problem and try again. ** Listing the failed packages (*:skipped / !:failed) ! lang/php5 (linker error) ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed Hope this is the right place to bring this up? joel -- Security Analyst| Hotline: +61 7 3365 4417 AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 The University of Queensland| WWW: www.auscert.org.au Qld 4072 Australia | Email: [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: php5 port compile problem
Hi Xander, Thanks for the info, but do you mean the bind9 port? I'm not excited about installing a port for bind when it is in the base distro already, but... joel > I know this problem! I encountered it a few months ago when php5 was this > beta. > > What I found was that you need bind9 for php5, so install bind9 and your > problem is solved. > > Greets, > > Xander > - Original Message - > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday 29 October 2004 8:03 > Subject: php5 port compile problem > > > > Hi, > > > > After a make update in /usr/src today (about an hour ago): > > > > ext/standard/dns.lo(.text+0x1c6c): In function `.L163': > > : undefined reference to `res_ninit' > > ext/standard/dns.lo(.text+0x1cd8): In function `.L163': > > : undefined reference to `res_nmkquery' > > ext/standard/dns.lo(.text+0x1d0a): In function `.L163': > > : undefined reference to `res_nsend' > > ext/standard/dns.lo(.text+0x1e9a): In function `.L163': > > : undefined reference to `res_nclose' > > *** Error code 1 > > > > Stop in /usr/ports/lang/php5/work/php-5.0.2. > > *** Error code 1 > > > > Stop in /usr/ports/lang/php5. > > ** Command failed [exit code 1]: /usr/bin/script -qa > > /tmp/portinstall88483.0 make DEPENDS_TARGET=package > > ** Fix the problem and try again. > > ** Listing the failed packages (*:skipped / !:failed) > >! lang/php5 (linker error) > > ---> Packages processed: 0 done, 0 ignored, 0 skipped and 1 failed > > > > Hope this is the right place to bring this up? > > > > joel > > -- > > Security Analyst| Hotline: +61 7 3365 4417 > > AusCERT - Australia's national CERT | Fax: +61 7 3365 7031 > > The University of Queensland| WWW: www.auscert.org.au > > Qld 4072 Australia | Email: [EMAIL PROTECTED] > > ___________ > > [EMAIL PROTECTED] mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > > > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
No Subject
subscribe freebsd-stable To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
confirm 369af32a61b4d4bdfe09e1321b2a02b883e70c6f
Your membership in the mailing list freebsd-stable has been disabled due to excessive bounces The last bounce received from you was dated 19-Oct-2013. You will not get any more messages from this list until you re-enable your membership. You will receive 2 more reminders like this before your membership in the list is deleted. To re-enable your membership, you can simply respond to this message (leaving the Subject: line intact), or visit the confirmation page at http://lists.freebsd.org/mailman/confirm/freebsd-stable/369af32a61b4d4bdfe09e1321b2a02b883e70c6f You can also visit your membership page at http://lists.freebsd.org/mailman/options/freebsd-stable/archive%40jab.org On your membership page, you can change various delivery options such as your email address and whether you get digests or not. As a reminder, your membership password is afagab If you have any questions or problems, you can contact the list owner at freebsd-stable-ow...@freebsd.org
confirm fd94bdfa8fe3f874c105c6491de85ea17a1ce475
Your membership in the mailing list freebsd-stable has been disabled due to excessive bounces The last bounce received from you was dated 19-Oct-2013. You will not get any more messages from this list until you re-enable your membership. You will receive 1 more reminders like this before your membership in the list is deleted. To re-enable your membership, you can simply respond to this message (leaving the Subject: line intact), or visit the confirmation page at http://lists.freebsd.org/mailman/confirm/freebsd-stable/fd94bdfa8fe3f874c105c6491de85ea17a1ce475 You can also visit your membership page at http://lists.freebsd.org/mailman/options/freebsd-stable/archive%40jab.org On your membership page, you can change various delivery options such as your email address and whether you get digests or not. As a reminder, your membership password is afagab If you have any questions or problems, you can contact the list owner at freebsd-stable-ow...@freebsd.org
You have been unsubscribed from the freebsd-stable mailing list
Re: [REVISED] FreeBSD 11.4-RC1 Now Available
On 5/22/20 11:52 PM, Glen Barber wrote: > list of changes since 11.3-RELEASE is available in the releng/11.4 > release notes: > > https://www.freebsd.org/releases/11.4R/relnotes.html > > Please note, the release notes page is not yet complete, and will be > updated on an ongoing basis as the 11.4-RELEASE cycle progresses. How about "the release notes page is not yet available"? That URL gives a 404 :) /Eirik _______ 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"
Regression in SCSI tape detection at boot in 7.2-RELEASE?
Sometime between the 7.2-PRERELEASE cycle started and 7.2-RELEASE, boot-time probing of tape drives (at least a Quantum DLT8000 and a Quantum SDLT600) started generating error messages, such as these: ahc1: port 0xd800-0xd8ff mem 0xfe1fe000-0xfe1fefff irq 25 at device 1.1 on pci2 ahc1: [ITHREAD] aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs ... Waiting 5 seconds for SCSI devices to settle (probe21:ahc1:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe21:ahc1:0:6:0): CAM Status: SCSI Status Error (probe21:ahc1:0:6:0): SCSI Status: Check Condition (probe21:ahc1:0:6:0): UNIT ATTENTION asc:29,2 (probe21:ahc1:0:6:0): SCSI bus reset occurred (probe21:ahc1:0:6:0): Retrying Command (per Sense Data) (probe21:ahc1:0:6:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe21:ahc1:0:6:0): CAM Status: SCSI Status Error (probe21:ahc1:0:6:0): SCSI Status: Check Condition (probe21:ahc1:0:6:0): UNIT ATTENTION asc:28,0 (probe21:ahc1:0:6:0): Not ready to ready change, medium may have changed (probe21:ahc1:0:6:0): Retrying Command (per Sense Data) sa0 at ahc1 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-4 device sa0: 160.000MB/s transfers (80.000MHz DT, offset 120, 16bit) This is happening for both stand-alone and loader drives, regardless of whether there is a tape in the drive at boot time. There is no problem with using the drive - no further messages are log- ged and the drive operates properly. Does anyone have any idea what is causing this, and where I should look to try to track it down? Terry Kennedy http://www.tmk.com te...@tmk.com New York, NY USA ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 6 and MySQL with DBs on a NAS
Hi, I was wondering if anyone else had encountered this issue and/or come up with what needs to be done to resolve it: I currently have MySQL 5.0.22 built from ports on a FreeBSD 6.1 machine with the DB data residing on a NetApp share connected via NFS. A strange thing happens often after a few hours or a couple of days, some tables that are very active start to crash for no apparent reason as far as I can tell. Example output from check table tablename: ++---+--+---+ | Table | Op| Msg_type | Msg_text | ++---+--+---+ | dbname.tablename | check | warning | Table is marked as crashed | | dbname.tablename | check | error| Found key at page 18259968 that points to record outside datafile | | dbname.tablename | check | error| Corrupt | ++---+--+---+ Upon moving the DB data to a local drive, the system operates flawlessly and has done so for many weeks, but I really need to keep these data on the networked share. The problem didn't happen when I was using FreeBSD 4.11, it only started after upgrading to FreeBSD 6.0 or 6.1. A poster on a MySQL mailing list suggested perhaps it could be a file locking issue at the OS level and so I post my inquiry here. I've seen this happen on FreeBSD 6.0 and 6.1 with MySQL 4.1.x and MySQL 5.0.x built from ports. Has anyone else seen this and if so has a resolution been found? -- Mark P. Hennessy _______ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6 and MySQL with DBs on a NAS
I wasn't able to find anyone seeing a similar problem as what I describe. I'm using FreeBSD 6.1, MySQL 5.0.21 built from ports and a NetApp share provided over NFS. Has anyone else ever seen the issue as described in the e-mail below? -- Mark P. Hennessy "Alexey Karagodov" <[EMAIL PROTECTED]> wrote: there was some problems with NFS on FreeBSD 6 ... try to google problem related to NFS or search this mailing list 2006/6/27, [EMAIL PROTECTED] <[EMAIL PROTECTED] >: Hi, I was wondering if anyone else had encountered this issue and/or come up with what needs to be done to resolve it: I currently have MySQL 5.0.22 built from ports on a FreeBSD 6.1 machine with the DB data residing on a NetApp share connected via NFS. A strange thing happens often after a few hours or a couple of days, some tables that are very active start to crash for no apparent reason as far as I can tell. Example output from check table tablename: ++---+--+---+ | Table | Op| Msg_type | Msg_text | ++---+--+---+ | dbname.tablename | check | warning | Table is marked as crashed | | dbname.tablename | check | error| Found key at page 18259968 that points to record outside datafile | | dbname.tablename | check | error| Corrupt | ++---+--+---+ Upon moving the DB data to a local drive, the system operates flawlessly and has done so for many weeks, but I really need to keep these data on the networked share. The problem didn't happen when I was using FreeBSD 4.11, it only started after upgrading to FreeBSD 6.0 or 6.1. A poster on a MySQL mailing list suggested perhaps it could be a file locking issue at the OS level and so I post my inquiry here. I've seen this happen on FreeBSD 6.0 and 6.1 with MySQL 4.1.x and MySQL 5.0.x built from ports. Has anyone else seen this and if so has a resolution been found? -- Mark P. Hennessy ___________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to " [EMAIL PROTECTED]" _______ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ThinkPad X1 Carbon Gen 4 unable to boot 13.0-RC1
On 3/19/21 7:59 PM, Mathias Picker wrote: Fred Hall via freebsd-stable writes: I have a ThinkPad X1 Carbon Gen 4 (20FCS0NB00) which has happily run FreeBSD 11 and 12, but which can't boot 13.0-RC1 from memstick or via freebsd-update. In both cases the boot process locks up on the line "hwpstate_intel0: on cpu0" If running freebsd-update, a work around is to add hint.hwpstate_intel.0.disabled="1" in loader.conf. See the note under the Eighth Generation (2020) in https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon I was quite surprised to find the lack of support for hwpstate_intel in 13 when it apparently worked under 11 and 12. Does anyone know the status of hwpstate_intel on ThinkPads? I’m running 13 -STABLE from 10 days ago on a Thinkpad Yoga 3rd gen, and hwpstate_intel works fine, never had a problem. mathiasp:~% sysctl dev.hwpstate_intel dev.hwpstate_intel.7.epp: 15 dev.hwpstate_intel.7.%parent: cpu7 dev.hwpstate_intel.7.%pnpinfo: dev.hwpstate_intel.7.%location: dev.hwpstate_intel.7.%driver: hwpstate_intel dev.hwpstate_intel.7.%desc: Intel Speed Shift dev.hwpstate_intel.6.epp: 15 dev.hwpstate_intel.6.%parent: cpu6 dev.hwpstate_intel.6.%pnpinfo: dev.hwpstate_intel.6.%location: dev.hwpstate_intel.6.%driver: hwpstate_intel dev.hwpstate_intel.6.%desc: Intel Speed Shift [snip] The gen3 is using sudo dmesg|grep -i cpu CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU) [snip, snip] mathiasp:~% uname -a FreeBSD Danton 13.0-STABLE FreeBSD 13.0-STABLE #2 stable/13-n244845-f21c0366f53: Wed Mar 10 20:53:26 CET 2021 root@Danton:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Cheers, Mathias Thanks for the feed back. Good to know most people won't encounter the problem. Perhaps it is a bios issue specific to the model. I did update to the latest bios version but that made no difference. I have chosen to rollback to 12.2 as it works perfectly for me. Cheers, Fred ___________ 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-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: ThinkPad X1 Carbon Gen 4 unable to boot 13.0-RC1
On 3/20/21 10:26 AM, Kevin Oberman wrote: On Sat, Mar 20, 2021 at 8:35 AM Fred via freebsd-stable < freebsd-stable@freebsd.org> wrote: On 3/19/21 7:59 PM, Mathias Picker wrote: Fred Hall via freebsd-stable writes: I have a ThinkPad X1 Carbon Gen 4 (20FCS0NB00) which has happily run FreeBSD 11 and 12, but which can't boot 13.0-RC1 from memstick or via freebsd-update. In both cases the boot process locks up on the line "hwpstate_intel0: on cpu0" If running freebsd-update, a work around is to add hint.hwpstate_intel.0.disabled="1" in loader.conf. See the note under the Eighth Generation (2020) in https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon I was quite surprised to find the lack of support for hwpstate_intel in 13 when it apparently worked under 11 and 12. Does anyone know the status of hwpstate_intel on ThinkPads? I’m running 13 -STABLE from 10 days ago on a Thinkpad Yoga 3rd gen, and hwpstate_intel works fine, never had a problem. mathiasp:~% sysctl dev.hwpstate_intel dev.hwpstate_intel.7.epp: 15 dev.hwpstate_intel.7.%parent: cpu7 dev.hwpstate_intel.7.%pnpinfo: dev.hwpstate_intel.7.%location: dev.hwpstate_intel.7.%driver: hwpstate_intel dev.hwpstate_intel.7.%desc: Intel Speed Shift dev.hwpstate_intel.6.epp: 15 dev.hwpstate_intel.6.%parent: cpu6 dev.hwpstate_intel.6.%pnpinfo: dev.hwpstate_intel.6.%location: dev.hwpstate_intel.6.%driver: hwpstate_intel dev.hwpstate_intel.6.%desc: Intel Speed Shift [snip] The gen3 is using sudo dmesg|grep -i c CPU: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz (1992.08-MHz K8-class CPU) [snip, snip] mathiasp:~% uname -a FreeBSD Danton 13.0-STABLE FreeBSD 13.0-STABLE #2 stable/13-n244845-f21c0366f53: Wed Mar 10 20:53:26 CET 2021 root@Danton:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Cheers, Mathias Thanks for the feed back. Good to know most people won't encounter the problem. Perhaps it is a bios issue specific to the model. I did update to the latest bios version but that made no difference. I have chosen to rollback to 12.2 as it works perfectly for me. Cheers, Fred There are two long tickets about this. Take a look at tickets 248659 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248659> and 253288 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253288>. This problem appeared in 13-current in Jan 2020 and I first saw it on my new Lenovo L15 that summer. It appears specific to Lenovo laptops. It appears that similar issues have been seen with Linux. Thank for the links to the bug reports, it would appear to be the same issue. I tested my wife's X1 Carbon Gen 3 and it worked fine. Perhaps a bios bug with the processor in my 4th gen. CPU: Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz (2808.11-MHz K8-class CPU) In the 24 hours I tested 13.0, I also had some X windows failures while waking up from suspend which never happens with 12.2. Oh well, no worries. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 _______ 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-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
Hi, Did you mean 12.1-p5 or 12.2-p5 ? I'm asking because you refer to both 12.1-p5 and 12.2-p5 (typo?). If you meant 12.2-p5: Perhaps the FreeBSD security team did not bump the version, but "only" backported the patches to version 1.1.1h ? Regards, Ruben On 3/30/21 3:35 PM, tech-lists wrote: Hi, Recently there was https://lists.freebsd.org/pipermail/freebsd-security/2021-March/010380.html about openssl. Upgraded to 12.2-p5 with freebsd-update and rebooted. What I'm unsure about is the openssl version. Up-to-date 12.1-p5 instances report OpenSSL 1.1.1h-freebsd 22 Sep 2020 Up-to-date stable/13-n245043-7590d7800c4 reports OpenSSL 1.1.1k-freebsd 25 Mar 2021 shouldn't the 12.2-p5 be reporting openssl 1.1.1k-freebsd as well? thanks, ___________ 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 terrible performance in KVM
Hello List, I hope some other folks out there running FreeBSD on KVM as well. I set up a base VM while doing so I noticed that the disk operations are very slow. Many times I edit a file in vim or try to run a command there is a huge lag. I use UFS as the root filesystem. To have something to compare it with I have tested it against an OpenBSD 6.6 VM on the same host, same hardware. both have 1 vCPU and 1GB of ram, 20GB virtual disk (they are exactly on the same physical disk no raid or anything to have a fair comparison). Here is an example simple file search time for a non-existent file: FreeBSD 13 time find / -name cacert.pem real 0m30.656s user 0m0.516s sys 0m3.938s Second run even worse real 2m38.618s user 0m0.711s sys 0m6.882s While on the OpenBSD VM I get time find / -name cacert.pem real 0m2.258s user 0m0.290s sys 0m1.970s The amount of data is about the same on both systems but I would not consider this a "slight" performance degradation. If the base system is so slow then imagine putting Apache and other servers on top of it. Did anyone run into this? Unless there is a definitive solution I will opt out to using other BSD variants. _______ 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 terrible performance in KVM
Hello, I have reinstalled it with GPT/ZFS and your right it's much better. Same search taking 3-6 seconds so I have deleted now all my old UFS based FreeBSD images. I wonder how I didn't notice this earlier because I had 12.0, 12.2 base images and now that I retested them they had the exact same issues. I guess after the stuff is loaded into memory it doesn't matter anymore. This must be something related to the virtual disk access. I was not thinking on using ZFS due to the higher memory recommendations, some of these VMs I using them for tiny tasks like DNS server and I don't give them more than 256, 512MB of ram. Also I don't take advantage of snapshotting either since it's a VM and it's either snapshotted or I just have base images and copy them when creating new VMs. Well UFS is on it's way out anyway. ‐‐‐ Original Message ‐‐‐ On Saturday, April 24, 2021 3:03 PM, Jeff Love j...@burgh.net wrote: > I'm running 12.2 and 13.0 on KVM using virtio and zfs. I am not having > disk I/O issues. > Jeff Love > On 4/24/21 5:25 AM, dashdruid via freebsd-stable wrote: > >> Hello List, >> I hope some other folks out there running FreeBSD on KVM as well. I set up a >> base VM while doing so I noticed that the disk operations are very slow. >> Many times I edit a file in vim or try to run a command there is a huge lag. >> I use UFS as the root filesystem. To have something to compare it with I >> have tested it against an OpenBSD 6.6 VM on the same host, same hardware. >> both have 1 vCPU and 1GB of ram, 20GB virtual disk (they are exactly on the >> same physical disk no raid or anything to have a fair comparison). >> Here is an example simple file search time for a non-existent file: >> FreeBSD 13 >> time find / -name cacert.pem >> real 0m30.656s >> user 0m0.516s >> sys 0m3.938s >> Second run even worse >> real 2m38.618s >> user 0m0.711s >> sys 0m6.882s >> While on the OpenBSD VM I get >> time find / -name cacert.pem >> real 0m2.258s >> user 0m0.290s >> sys 0m1.970s >> The amount of data is about the same on both systems but I would not >> consider this a "slight" performance degradation. If the base system is so >> slow then imagine putting Apache and other servers on top of it. Did anyone >> run into this? >> Unless there is a definitive solution I will opt out to using other BSD >> variants. >> 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" > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > 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-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Quote products details
Dear Sales Manager, This is Grace, the Sales Manager of Stock Pile LTD, Thailand. We are an US based B2B Platform. We are in the process of gathering various types of trade-able goods for various international markets like USA, UK, India, Germany, Australia and various other Asian & European countries. We offer great interest to do a purchase agreement with your company. Please get back to us with the following information 1,Minimum Order 2,Payment Terms 3,Product Specification 4,Delivery Time 5,Country Of Origin 6,Sample Availability 7,Is Your Price Negotiable? We would need a quick reply. Brst Regards, Grace Macfede Amata Nakorn Industrial Estate 700/553, Moo 7, T.Don Hua Roh, A.Maung, Chonburi, 2, Thailand ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Daniel Kelles invited you to check out Dropbox
Hi there, Daniel Kelles wants you to try Dropbox! Dropbox lets you bring all your photos, docs and videos with you anywhere and share them easily. Get started here. https://www.dropbox.com/l/s6jN8bqyJT9Q0CzL3huhhr?text=1 Thanks! - The Dropbox Team To stop receiving invites from Dropbox, please go to https://www.dropbox.com/l/19oo1DfxJGE4l8upN3sduj?text=1 Dropbox, Inc., PO Box 77767, San Francisco, CA 94107 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
business leads
Hey, You are receiving this email because we wish you to use our email marketing service. We wish to be your email marketing partner, we can grow your business 2-5 times than now. If you would require more information please send us an email and we would be glad to discuss the project requirements with you soon. Looking forward to your positive response. Kind Regards John Email: pottl...@aliyun.com - This e-mail message and its attachments (if any) are intended solely for the use of the addressee(s) hereof. In addition, this message and the attachments (if any) may contain information that is confidential, privileged and exempt from disclosure under applicable law. If you are not the intended recipient of this message, you are prohibited from reading, disclosing, reproducing, distributing, disseminating or otherwise using this transmission. Delivery of this message to any person other than the intended recipient is not intended to waive any right or privilege. If you have received this message in error, please promptly notify the sender and immediately delete this message from your system. If you don't wish our future news letter, pls send address to ttick...@aliyun.com for removal. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Получите надежного помощника для Вашего бизнеса
Нужен перевод хорошего качества? Ждем Вашего звонка! Вот уже больше 6 лет переводческое агентство Гельвеция предлагает услуги юридическим и физическим лицам: письменные, устные переводы, а также синхрон. За данный период успешно реализовали более 5000 проектов, а агентство объединило более 2000 профессиональных переводчиков. Каждый год наша компания имеет возможность подтвердить лидерские позиции в области переводческих услуг высокопрестижными премиями и сертификатами. Получите удовольствие - оцените преимущества очень простой и выгодной схемы работы: - бесплатное консультирование и подтверждение заказа наиболее удобным для Вас способом - в офисе, посредством звонка, по e-mail; - внесение предоплаты и исполнение заказа; - передача готового перевода и доплата второй части от суммы договора. Наши заказчики рады рекомендовать наше агентство за: •частые розыгрыши дорогих подарков: туры в экзотические страны, сертификаты СПА-салона, iPad, другие гаджеты. •возможность оплаты за перевод online – посредством кошелька KIWI, Вам не нужно идти в отделение банка; •возможность вычитывания важных документов носителем языка; •приятные бонусы в течение первых 3 месяцев обращений – целый пакет привилегий и скидок на услуги нашего агентства; •БЕСПЛАТНОЕ пробное исполнение: Вы нисколько не теряете; •возможность исполнения срочного перевода любого объема; •готовность обслуживать постоянных заказчиков по удобной схеме без предварительной оплаты; •высокое качество выполнения каждого заказа – от небольшого до крупного; •очень широкий ряд языковых возможностей: переводы на/с 57 языков; •нотариальное заверение переведенной документации; Мы никогда не делили своих клиентов на тех, кто заказывает большие объемы, и всех других. Мы только переводим. И ценим каждого клиента! Профессионализм и опыт наших переводчиков, среди которых огромное количество языковых носителей, позволяют нам делать переводы любого уровня сложности в самом высоком качестве. Ждем Вашей заявки по тел-ну: +7 /705/ 8737112 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Wells Fargo contact information has been updated
___ 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"
/usr/lib/libc.a contains .debug_info on FreeBSD 12.0-RC3
Hi, I just installed FreeBSD 12.0-RC3 amd64 and noticed /usr/lib/libc.a is much larger than the one on 11.2-RELEASE. # ar x /usr/lib/libc.a # file jemalloc_ctl.o jemalloc_ctl.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), with debug_info, not stripped # ls -lh jemalloc_ctl.o -rw-r--r-- 1 root wheel 834K Dec 10 14:44 jemalloc_ctl.o Is this expected? ___ 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"
Enjoy the health benefits of safe, scalar light healing for your entire family
Dear Subscriber, Tom Paladino, a scalar light researcher and healer, is able to significantly improve the health of your entire family with scalar light healing. Scalar light is a remote healing modality that only requires your photograph in order to eradicate germs from your body and deliver the nutrients necessary for optimal physical and mental health. The purpose of this communication is to offer you and your entire family scalar light healing without obligation. You may submit as many as 25 photographs of your family members and friends in order to experience the scalar light healing session. Click here ( https://www.scalarlight.com/GD1 ) to register for the 15 day scalar light healing session. There is absolutely no obligation to receive this offer. Why we are contacting you? We are contacting you today as part of our compliance with the General Data Protection Regulations (GDPR) which came into force on 25th May 2018. Tom assures that the best date protection and compliance data policies are in practice in order to assure your privacy. Our privacy policy explains how we collect and use personal data. The data that we possess includes your name and email address. The GDPR classifies information such as your name and email address as personal data. The lawful basis we use for this processing is "Legitimate Interest" for "direct marketing". It is recommended that companies using this basis conduct a "Legitimate Interests Assessment" (LIA), which we have done. You subscribed to our offer for a no-obligation scalar light healing session or heard about us and subsequently subscribed to our newsletter. To register for the 15 day scalar light healing session please click here ( https://www.scalarlight.com/GD1 ). You may submit as many as 25 photographs of family members and friends in order to receive our no-obligation scalar light healing session. To confirm your acceptance to receive emails as well as the no obligation scalar light healing sessions, please confirm ( https://www.scalarlight.com/optin.html?B4431F14E8BBABBF1F013A87EDA9ED2164A5206EE5CC1E4B0243DA7938FE1898 ). You can unsubscribe ( https://www.scalarlight.com/unsubscribe.html ) at any time. You have the right to opt out of future communications and the quickest way to do this is to use the unsubscribe link at the bottom of this email. Thank you. Tom Paladino 1767 Lakewood Ranch Blvd #231 Lakewood Ranch, Florida 34211 805-364-3051 or 800-345-9851 supp...@scalarlight.com If you do not wish to receive further emails from us, click here to unsubscribe ( https://www.scalarlight.com/unsubscribe.html ). You can read our Privacy Policy here. If you have any questions about this email, please contact supp...@scalarlight.com. ___________ 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"
Nvidia driver cannot compile on FreeBSD 12.0
Hi all I tried to install NVIDIA-FreeBSD-x86_64-418.56 display driver but I get following compilation error: # make install===> src (install)===> src/nvidia (install)cc -O2 -pipe -DNV_VERSION_STRING=\"418.56\" -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I../common/inc -I. -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c nvidia_acpi.c -o nvidia_acpi.oIn file included from nvidia_acpi.c:12:./os-interface.h:27:10: fatal error: 'stdarg.h' file not found#include ^~1 error generated. My OS:# uname -aFreeBSD unga 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64 I used to have a previous version of Nvidia driver running well on FreeBSD 11.2 on the same machine. Any idea? Best regardsUnga ___________ 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"
Confirm your Twitter account, RICKON ZIEMSKI
RICKON ZIEMSKI, Confirm your email address to complete your Twitter account. It's easy - just click on the button below. Click on the link below or copy and paste it into a browser: https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Faccount%2Fconfirm_user_email%2F4128034383%2F4C86D-8FBE7-144682%3Ft%3D1%26cn%3DZW1haWxfY29uZmlybV9pbml0%26sig%3Dc5eed0287fd435e109b820a66866ca13e87b0460%26al%3D1%26iid%3D11a89e250b5e493e8a272eb67ec4a9d8%26ac%3D1%26autoactions%3D1446827952%26uid%3D4128034383%26nid%3D244%2B308&t=1&cn=ZW1haWxfY29uZmlybV9pbml0&sig=a3d2b7cb120a7163ef75b74fbd6acec0d530c57f&iid=11a89e250b5e493e8a272eb67ec4a9d8&uid=4128034383&nid=244+308 ___________ 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"
Confirm your Twitter account, COLLETTE WALFORD
COLLETTE WALFORD, Confirm your email address to complete your Twitter account. It's easy - just click on the button below. Click on the link below or copy and paste it into a browser: https://twitter.com/i/redirect?url=https%3A%2F%2Ftwitter.com%2Faccount%2Fconfirm_user_email%2F4144794677%2F29BCD-FF964-144702%3Ft%3D1%26cn%3DZW1haWxfY29uZmlybV9pbml0%26sig%3D719c749dc34435fe6a3df0fe92d23f25628e5a7b%26al%3D1%26iid%3D8eec6d5ba7584724949b02764469fcf5%26ac%3D1%26autoactions%3D1447021300%26uid%3D4144794677%26nid%3D244%2B308&t=1&cn=ZW1haWxfY29uZmlybV9pbml0&sig=cf308a1adeb336c2a718f0b6577225ae34ff2f29&iid=8eec6d5ba7584724949b02764469fcf5&uid=4144794677&nid=244+308 ___________ 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"
Your recovery email address changed
Your recovery email address changed Hi VNS娱乐城876502.com注册送88元,网上最火爆的游戏平台,超好赢钱游戏, The recovery email for your Google Account maxhill...@gmail.com was recently changed. *Don't recognize this activity?* Review your recently used devices <https://accounts.google.com/AccountChooser?Email=maxhill...@gmail.com&continue=https://security.google.com/settings/security/activity/nt/1476661749530?rfn%3D2%26rfnc%3D1%26et%3D4%26asae%3D2%26anexp%3Dire-control> now. Best, The Google Accounts team This email can't receive replies. For more information, visit the Google Accounts Help Center <https://support.google.com/accounts/answer/2450236>. You received this mandatory email service announcement to update you about important changes to your Google product or account. © 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA ___________ 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-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
CAM status: Command timeout
Hello, After updating to 11.1 my home server can't boot with errors like (ada0:ata2:0:0:0): WRITE_DMA48. ACB: 35 00 50 29 10 40 6c 00 0c 00 (ada0:ata2:0:0:0): CAM status: Command timeout (ada0:ata2:0:0:0): Retrying command for all 6 sata hdd(stripe from 2 raidz) ACB different from boot to boot Sometimes it even can boot, but in few minutes will hang with same errors. Hardware: Supermicro X8DTN+-F / 6xWD1502FYPS-02W3B0 /2xE5649 HDDs connected to sata ports on baseboard. If I add hint.ata.2.mode=PIO4 hint.ata.3.mode=PIO4 hint.ata.4.mode=PIO4 hint.ata.5.mode=PIO4 to device.hints I'm able to boot but performance of IO becomes really disappointing. Also, if I add something like "find / -name something" to zfs rc script, than boots fine. If I roll back system to 11.0 all works fine again. Any advise on debuging of this issue? Also raised bug report some time ago for this issue https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221704 _______ 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: CAM status: Command timeout
22 сентября 2017 г., 02:35, "Keith Hellman" написал: > On Wed, Sep 20, 2017 at 11:06:11PM +0000, freebsd-stable List wrote: > >> Sometimes it even can boot, but in few minutes will hang with same errors. >> >> Hardware: Supermicro X8DTN+-F / 6xWD1502FYPS-02W3B0 /2xE5649 >> HDDs connected to sata ports on baseboard. >> If I add >> hint.ata.2.mode=PIO4 >> hint.ata.3.mode=PIO4 >> hint.ata.4.mode=PIO4 >> hint.ata.5.mode=PIO4 >> to device.hints I'm able to boot but performance of IO becomes really >> disappointing. >> Also, if I add something like "find / -name something" to zfs rc script, >> than boots fine. > > Boots fine but hangs in a few minutes? Or all is good to go? Here is a > thught: it could be the find / ... command is causing enough delay to > let some hardware "settle down" and behave more reasonably. Can you > replace the find cmd with an equivalent sleep(1) command of like > duration and get the same results? > >> If I roll back system to 11.0 all works fine again. > > Seemingly minor deltas in the system could have had the needed delay > as an implicit part of the system... > > Just my 2c Nope, it can't boot fine at all, or init will get segfault or ttys or just system becomes unresponsive and I can't even login, so this heppens during start of services. I've also tried to disable all "non-base" services, but without success. As for trying just sleep - it doesn't helps. Seems that find helps because of caching by system triggered by find. > -- > Keith Hellman #include > khell...@mcprogramming.com from disclaimer import standard > khell...@mines.edu gpg key 9FCF40FD > freenode.net as mrtuple > > "The First Python function ever written (takes place in the Garden of Eden)" > > Guido sayeth "I will write def foo():" > "Hmm, I could use an import, or two", > Satan said, in a whirl, "Why not write it in Perl?", > and the second function ever written - def foo_you(): > > -- Python Limmerick Contest submission by cappy2112 > http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/d7a780beaff2e88a ___ 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: kern.sched.quantum: Creepy, sadistic scheduler
On Tue, 17 Apr 2018 09:05:48 -0700 Freddie Cash wrote: > # Tune for desktop usage > kern.sched.preempt_thresh=224 > > Works quite nicely on a 4-core AMD Phenom-II X4 960T Processor > (3010.09-MHz K8-class CPU) running KDE4 using an Nvidia 210 GPU. For interactive tasks, there is a "special" tunable: % sysctl kern.sched.interact kern.sched.interact: 10 # default is 30 % sysctl -d kern.sched.interact kern.sched.interact: Interactivity score threshold reducing the value from 30 to 10-15 keeps your gui/system responsive, even under high load. ___________ 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: removable storage usability, devd, hald and X11-desktop in general
On Sat, 19 May 2018 20:35:59 +0200 Harry Schmalzbauer wrote: Hi, > Biggest question: How are useres expected to handle removable media? > > I'm a happy user of autofs(5) in several environments (mostly for NFS > mounts), but I'm not aware of any helper tool which enables _users_ > to unmount before pulling the UFD. > I've heard of PC-BSD and Lumina (see later why I haven't really tried > out the modern "light" desktops) and I think I remember having read > they utilize devd(8). But again, how to unmount? There is a nice little daemon: sysutils/dsbmd (see https://freeshell.de/~mk/projects/dsbmd.html and /usr/local/etc/dsbmd.conf.sample) with a simple GUI sysutils/dsbmc and cli (sysutils/dsbmc-cli) clients. It supports automounting using devd and/or polling and automatic or manual unmounting. _______ 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: git, $FreeBSD$ and mergemaster
> On Dec 23, 2020, at 9:04 PM, Kyle Evans wrote: > > On Wed, Dec 23, 2020 at 8:02 PM Jonathan Chen wrote: >> >> Hi, >> >> With the transition to git, I'm now getting a lot of prompts for >> differences against an empty $FreeBSD$, eg: >> >> *** Displaying differences between installed version and ./.cshrc: >> >> --- /.cshrc 2020-09-03 19:14:19.258107000 +1200 >> +++ ./.cshrc 2020-12-24 14:52:16.751245000 +1300 >> @@ -1,4 +1,4 @@ >> -# $FreeBSD: stable/12/bin/csh/dot.cshrc 363525 2020-07-25 11:57:39Z pstef $ >> +# $FreeBSD$ >> # >> # .cshrc - csh resource script, read at beginning of execution by each shell >> # >> >> While I can simply run a "mergemaster -F" to get past this particular >> update, how will mergemaster operate in the future when there are >> changes in /etc if it can't inspect the $FreeBSD$ tag anymore? >> > > mergemaster only uses it as an optimization, if they're unexpanded > throughout then it falls back to diff(1) -- i.e. it's slower without. Is this a permanent change with git? I’d miss being able to see a path, date and some indication of revision in config files and anything else that’s text-based. Charles > Thanks, > > Kyle Evans > _______ > 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-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
MII media status race condition causing fictitious link down
Hello, As I've sent a couple of patches to add support for Thinkpad USB-C gen2 to if_ure(4), I came across a very strange link random state change, causing dhclient to think the link went effectively down, which is not the case. First I thought that if_ure(4) doesn't play well with the new chip of the dock, but after lot of debugging, it turns out to be a nasty race condition in mii bus code [1]. I'm sending this mail to raise awareness about this issue. Apparently it exists since long time (I even remember having had this issue in the past on my older Thinkpad). [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252165 Regards, -- Ali Abdallah | SUSE L3 Engineer GPG fingerprint: 51A0 F4A0 C8CF C98F 842E A9A8 B945 56F8 1C85 D0D5 _______ 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: Consistency of pkg db on UFS
On 12.12.2020 09:44, techyNotes wrote: > Hi Ali Hi > > I had a similar problem with my HP Elitebook couple of days ago with UFS > option. I had been experimenting with various modes and setup options > including the file system ZFS and UFS. I would have installed and reinstalled > Freebsd 12.2 more than 20 times! > > I guess the issue lies in the Installation process. Just before the final > step of rebooting it takes sometime (more than when installing with ZFS > option) to complete the installation closure tasks. This was not completed or > you did not wait until the point the message popped up to reboot the system! > > To verify if this is the case, check your loader.conf and/or rc.conf it would > be empty. The options you selected during the install process would not be > recorded in these files. > > SOLUTION: I just reinstalled again with the option of UFS and waited on the > last before step patiently and then finally rebooted upon the alter message > of REBOOT option from the installer. I'm no speaking about the installer, but an already installed system. I don't believe there is a solution to the described issue, the blocks of a newly installed package can make it to the disk and to the fs metadata, but the information about it written by the package manager to its database/plain file might not make it to the disk in case of power failure/panic, so you would end up with an installed package that the package manager itself doesn't know about! The issue can happen on any filesystem, not only on UFS. Regards, Ali ___ 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-Announce] FreeBSD Errata Notice FreeBSD-EN-21:02.extattr
On Jan 29, 2021, at 4:09 AM, Martin Simmons wrote: > >>>>>> On Fri, 29 Jan 2021 02:34:06 + (UTC), FreeBSD Errata Notices said: >> >> 2) To update your system via a source code patch: >> >> The following patches have been verified to apply to the applicable >> FreeBSD release branches. >> >> a) Download the relevant patch from the location below, and verify the >> detached PGP signature using your PGP utility. >> >> [FreeBSD 11.4] >> # fetch >> https://www.google.com/url?q=https://security.FreeBSD.org/patches/EN-12:02/extattr.patch&source=gmail-imap&ust=161255012400&usg=AOvVaw3tedBjh5jzyUuP3xiGTtZQ >> # fetch >> https://www.google.com/url?q=https://security.FreeBSD.org/patches/EN-12:02/extattr.patch.asc&source=gmail-imap&ust=161255012400&usg=AOvVaw3t5fFBc0ZeO4PkEwhRNHS9 >> # gpg --verify extattr.patch.asc > > There is a typo in the URLs (12 instead of 21). Thanks for the report. I've published an updated URI. Apologies! Gordon _______ 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: Setting for displaying utf8 characters on all vt consoles results in panic on 14-CURRENT and 13.0-ALPHA3
> On 1. Feb 2021, at 05:35, Yasuhiro Kimura wrote: > > From: Yasuhiro Kimura mailto:y...@utahime.org>> > Subject: Setting for displaying utf8 characters on all vt consoles results in > panic on 14-CURRENT and 13.0-ALPHA3 > Date: Mon, 01 Feb 2021 11:41:35 +0900 (JST) > >> To display utf8 characters on all vt console I did following settings. >> >> 1. Download GNU Unifont BDF file >> >> (http://unifoundry.com/pub/unifont/unifont-13.0.05/font-builds/unifont-13.0.05.bdf.gz) >> 2. gunzip unifont-13.0.05.bdf.gz >> 3. vtfontcvt unifont-13.0.05.bdf unifont.fnt >> 4. cp unifont.fnt /usr/share/vt/fonts >> 5. Add 'allscreens_flags="-f 8x16 unifont.fnt"' to /etc/rc.conf >> 6. Add 'hw.vga.textmode=0' to /boot/loader.conf.local >> 7. shutdown -r now >> >> On 12.2-RELEASE and 11.4-RELEASE it works as is expected. But on >> 14-CURRENT(man) and 13.0-ALPHA3(stable/13) it result in kernel panic. >> >> Screen shot of 14-CURRENT. >> https://www.utahime.org/FreeBSD/panic.20210201.14-CURRENT.png >> >> 14-CURRENT(main): >> yasu@rolling-vm-freebsd1[1006]% uname -a >> FreeBSD rolling-vm-freebsd1.home.utahime.org 14.0-CURRENT FreeBSD >> 14.0-CURRENT #0 main-n244517-f17fc5439f5: Mon Feb 1 10:55:51 JST 2021 >> ro...@rolling-vm-freebsd1.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC >> amd64 >> >> 13.0-ALPHA3(stable/13): >> yasu@rolling-vm-freebsd5[1005]% uname -a >> FreeBSD rolling-vm-freebsd5.home.utahime.org 13.0-ALPHA3 FreeBSD 13.0-ALPHA3 >> #0 stable/13-c256214-g40cb0344eb2: Mon Feb 1 11:30:28 JST 2021 >> ro...@rolling-vm-freebsd5.home.utahime.org:/usr0/freebsd/src/obj/usr0/freebsd/src/git/amd64.amd64/sys/GENERIC >> amd64 > > I submitted this problem to Bugzilla. > > Bug 253147 - Setting for displaying utf8 characters on all vt consoles > results in panic on 14-CURRENT and 13.0-ALPHA3 > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253147 > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253147> > > --- > Yasuhiro Kimura Should be fixed on current now. thanks, toomas ___ 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: where to upgrade 12-stable now, svn still, or git?
> 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 material. For example, via: https://svnweb.freebsd.org/base/stable/12/lib/?sortby=rev&sortdir=down&view=log is the following . . . QUOTE Revision 369260 - Directory Listing Modified Fri Feb 12 21:02:48 2021 UTC (4 hours, 49 minutes ago) by dim test_inf_inputs: Use atf_tc_expect_fail() instead of atf_tc_skip() Reviewed By:lwhsu Differential Revision: https://reviews.freebsd.org/D28396 (cherry picked from commit 4d2edf3af1dbd8a3e7cf1b22343a1ecfc2dd41ba) Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >= 10 This sprinkles a few strategic volatiles in an attempt to defeat clang's optimization interfering with the expected floating-point exception flags. Reported by:lwhsu PR: 244732 (cherry picked from commit ac76bc1145dd7f4476e5d982ce8f355f71015713) Git Hash: f2a88e744701de1b37d7463828f2147f96e39d58 Git Author: arichard...@freebsd.org END QUOTE So both -r369260 and git hash-ids are indicated. By contrast, the cgit commit's display does not identify the svn side's -r369260 : QUOTE diff options context: space: mode: author Alex Richardson2021-01-29 09:28:40 + committer Dimitry Andric2021-02-12 20:50:28 + commit f2a88e744701de1b37d7463828f2147f96e39d58 (patch) tree0db8207a810f40d7f82c2033f8377ed38ce08ba2 parent 9525ccc84e337f4261425fc8fbf9f0de18500a1b (diff) downloadsrc-f2a88e744701de1b37d7463828f2147f96e39d58.tar.gz src-f2a88e744701de1b37d7463828f2147f96e39d58.zip test_inf_inputs: Use atf_tc_expect_fail() instead of atf_tc_skip()stable/12 Reviewed By:lwhsu Differential Revision: https://reviews.freebsd.org/D28396 (cherry picked from commit 4d2edf3af1dbd8a3e7cf1b22343a1ecfc2dd41ba) Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >= 10 This sprinkles a few strategic volatiles in an attempt to defeat clang's optimization interfering with the expected floating-point exception flags. Reported by:lwhsu PR: 244732 (cherry picked from commit ac76bc1145dd7f4476e5d982ce8f355f71015713) END QUOTE Matching up stable revisions with releng/12.3/ or release/12.3.0/ in the future would be easier starting from svn material in the first place and would provide identification for git as well. But I've no clue if such would be important to what you might need to do with 12. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: where to upgrade 12-stable now, svn still, or git?
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 that is complicated because the official builds for releng, release, and even snapshots, are still based on svn (not git) for 12 and still use rDD numbering from svn and will be for the life of 12 (and 11). (There is no svn branch for 13 and later.) So, tracking relationships to official builds is easier from the svn side of things and it also provides pointers back to git. To me that makes answers to "which is the source for truth now" problematical: it would be hard to avoid mixing the criteria from what I can tell. (But, I'm unlikely to deal with before 13 and so likely will be able to avoid the issue myself.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___________ 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: where to upgrade 12-stable now, svn still, or git?
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 should have mentioned this area in my reply to tech-lists. This part of things is more git based now, probably meaning more use of https://svnweb.freebsd.org/ to look at commits/check-ins is needed in order to see the modern cross-references between svn and git. (Such is not available from the git side.) (Older history in svn does not have git references as far as I know.) > I suspect that > > https://lists.freebsd.org/pipermail/dev-commits-src-branches/2021-January/thread.html > > is the stable-12 equivalent but are incremental patch releases also > available here? That covers stable/11 , stable/12 , and stable/13 . But no list that I know of covers any releng/* or release/* commit activity. For the git side of things, one has to look at the likes of branches via cgit (or whatever) via the likes of: https://cgit.freebsd.org/src/log/?h=releng/12.2 https://cgit.freebsd.org/src/log/?h=releng/13.0 Something like release/12.2.0 seems to be via a tag on a commit. So https://cgit.freebsd.org/src/log/?h=releng/12.2 lists it but https://cgit.freebsd.org/src/log/?h=stable/12 does not. (There are commits to releng/12.2 after the release/12.2.0 tag.) Of course, for 12 there still is: https://svnweb.freebsd.org/base/release/12.2.0/ https://svnweb.freebsd.org/base/releng/12.2/ as a svn side view of things that has the modern cross references to git included. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___________ 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"
[pf] stable/12: block by OS broken
Hi, It appears that some change between 939430f2377 (December 31) and b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the following rule: block in quick proto tcp from any os "Linux" to any port ssh would get interpreted as: block drop in quick proto tcp from any to any port = 22 (and block all SSH connection instead of just the ones initiated from Linux). Cheers, OpenPGP_signature Description: OpenPGP digital signature
Re: where to upgrade 12-stable now, svn still, or git?
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.freebsd.org/pipermail/svn-src-release/ >> >> suspect also dead. > > I should have mentioned this area in my reply to tech-lists. > This part of things is more git based now, probably > meaning more use of https://svnweb.freebsd.org/ to look > at commits/check-ins is needed in order to see the modern > cross-references between svn and git. (Such is not available > from the git side.) > > (Older history in svn does not have git references as > far as I know.) > >> I suspect that >> >> https://lists.freebsd.org/pipermail/dev-commits-src-branches/2021-January/thread.html >> >> is the stable-12 equivalent but are incremental patch releases also >> available here? > > > That covers stable/11 , stable/12 , and stable/13 . But no list > that I know of covers any releng/* or release/* commit activity. That last sentence is false as of today for releng/13.0 : https://lists.freebsd.org/pipermail/dev-commits-src-branches/2021-February/thread.html lists 7 releng/13.0 entries, the first being: git: 00abeecb4a25 - releng/13.0 - pf: Slightly relax pf_rule_addr validation Kristof Provost > For the git side of things, one has to look at the likes of > branches via cgit (or whatever) via the likes of: > > https://cgit.freebsd.org/src/log/?h=releng/12.2 > https://cgit.freebsd.org/src/log/?h=releng/13.0 > > Something like release/12.2.0 seems to be via a tag > on a commit. So https://cgit.freebsd.org/src/log/?h=releng/12.2 > lists it but https://cgit.freebsd.org/src/log/?h=stable/12 > does not. (There are commits to releng/12.2 after the > release/12.2.0 tag.) > > Of course, for 12 there still is: > > https://svnweb.freebsd.org/base/release/12.2.0/ > https://svnweb.freebsd.org/base/releng/12.2/ > > as a svn side view of things that has the modern > cross references to git included. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: [pf] stable/12: block by OS broken
On 2/17/21 22:35, Kristof Provost wrote: > On 18 Feb 2021, at 6:01, Xin Li wrote: > > Hi, > > It appears that some change between 939430f2377 (December 31) and > b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the > following rule: > > block in quick proto tcp from any os "Linux" to any port ssh > > would get interpreted as: > > block drop in quick proto tcp from any to any port = 22 > > (and block all SSH connection instead of just the ones initiated from > Linux). > > Thanks for the report. I think I see the problem. > > Can you test this patch? > > |diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c > index 593a38d4a360..458c6af3fa5e 100644 --- a/sys/netpfil/pf/pf_ioctl.c > +++ b/sys/netpfil/pf/pf_ioctl.c @@ -1623,7 +1623,7 @@ > pf_rule_to_krule(const struct pf_rule *rule, struct pf_krule *krule) /* > Don't allow userspace to set evaulations, packets or bytes. */ /* kif, > anchor, overload_tbl are not copied over. */ - krule->os_fingerprint = > krule->os_fingerprint; + krule->os_fingerprint = rule->os_fingerprint; > krule->rtableid = rule->rtableid; bcopy(rule->timeout, krule->timeout, > sizeof(krule->timeout)); | > > With any luck we’ll be able to include the fix in 13.0. Thanks, I'll try this on a -CURRENT box which is exhibiting the same issue and report back as soon as possible. Cheers, OpenPGP_signature Description: OpenPGP digital signature
Re: [pf] stable/12: block by OS broken
On 2/17/21 22:57, Xin Li wrote: > On 2/17/21 22:35, Kristof Provost wrote: >> On 18 Feb 2021, at 6:01, Xin Li wrote: >> >> Hi, >> >> It appears that some change between 939430f2377 (December 31) and >> b4bf7bdeb70 (today) on stable/12 have broken pf in a way that the >> following rule: >> >> block in quick proto tcp from any os "Linux" to any port ssh >> >> would get interpreted as: >> >> block drop in quick proto tcp from any to any port = 22 >> >> (and block all SSH connection instead of just the ones initiated from >> Linux). >> >> Thanks for the report. I think I see the problem. >> >> Can you test this patch? >> >> |diff --git a/sys/netpfil/pf/pf_ioctl.c b/sys/netpfil/pf/pf_ioctl.c >> index 593a38d4a360..458c6af3fa5e 100644 --- a/sys/netpfil/pf/pf_ioctl.c >> +++ b/sys/netpfil/pf/pf_ioctl.c @@ -1623,7 +1623,7 @@ >> pf_rule_to_krule(const struct pf_rule *rule, struct pf_krule *krule) /* >> Don't allow userspace to set evaulations, packets or bytes. */ /* kif, >> anchor, overload_tbl are not copied over. */ - krule->os_fingerprint = >> krule->os_fingerprint; + krule->os_fingerprint = rule->os_fingerprint; >> krule->rtableid = rule->rtableid; bcopy(rule->timeout, krule->timeout, >> sizeof(krule->timeout)); | >> >> With any luck we’ll be able to include the fix in 13.0. > > Thanks, I'll try this on a -CURRENT box which is exhibiting the same > issue and report back as soon as possible. And I can confirm that this fixed the issue on -CURRENT, thanks for the quick fix! Cheers, OpenPGP_signature Description: OpenPGP digital signature
Re: git to svn update frequency ?
mike tancsa mike at sentex.net wrote on Thu Feb 18 10:33:14 UTC 2021 : > On 2/17/2021 12:10 PM, Warner Losh wrote: > > On Feb 17, 2021, at 6:05 AM, mike tancsa wrote: > >> I noticed on a box that I update RELENG_12 via git there are more > >> recent commits then if I use svnlite to track. Are they only > >> periodically updated ? If so, how frequently do they get refreshed ? > >> e.g. I see the new OpenSSL version in git, but not when I update via > >> svnlite. > > Yes. There is a lag for a number of reasons. The updates happen on a > > batched basis (it’s a script I wrote) and then there’s a delay in > > replication to the main subversion servers. I believe that the rate is on > > the scale of hourly, but lwhsu will have to answer that detail. > > > Hi Warner & Li-Wen, > > I think something might be broken somewhere ? The last update is > from ~ 36 hrs ago and there have been many commits to the git repo since > for RELENG_12. > > # svnlite update > Updating '.': > At revision 369283. > # You are referencing 12, not 13 . . . https://cgit.freebsd.org/src/log/?h=releng/12.0 shows the most recent releng/12.0 in git is from 2021-Jan-28: Commit message (Expand) Author Age Files Lines Add UPDATING entries and bump version.releng/12.0 Gordon Tetlow 2020-01-28 2 -1/+17 Are you confusing stable/12 and releng/12.0 or possibly releng/12.0 and releng/13.0 ? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___________ 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: git to svn update frequency ?
On 2021-Feb-18, at 05:33, Mark Millard wrote: > mike tancsa mike at sentex.net wrote on > Thu Feb 18 10:33:14 UTC 2021 : > >> On 2/17/2021 12:10 PM, Warner Losh wrote: >>> On Feb 17, 2021, at 6:05 AM, mike tancsa wrote: >>>>I noticed on a box that I update RELENG_12 via git there are more >>>> recent commits then if I use svnlite to track. Are they only >>>> periodically updated ? If so, how frequently do they get refreshed ? >>>> e.g. I see the new OpenSSL version in git, but not when I update via >>>> svnlite. >>> Yes. There is a lag for a number of reasons. The updates happen on a >>> batched basis (it’s a script I wrote) and then there’s a delay in >>> replication to the main subversion servers. I believe that the rate is on >>> the scale of hourly, but lwhsu will have to answer that detail. >>> >> Hi Warner & Li-Wen, >> >>I think something might be broken somewhere ? The last update is >> from ~ 36 hrs ago and there have been many commits to the git repo since >> for RELENG_12. >> >> # svnlite update >> Updating '.': >> At revision 369283. >> # > > You are referencing 12, not 13 . . . > > https://cgit.freebsd.org/src/log/?h=releng/12.0 > > shows the most recent releng/12.0 in git is from 2021-Jan-28: > > Commit message (Expand) Author Age Files Lines > Add UPDATING entries and bump version.releng/12.0 Gordon Tetlow > 2020-01-28 2 -1/+17 > > > Are you confusing stable/12 and releng/12.0 or > possibly releng/12.0 and releng/13.0 ? Dumb of me to show releng/12.0 instead of releng/12.2 , I guess. But I luck out: releng/12.2 was only one day more recent . . . https://cgit.freebsd.org/src/log/?h=releng/12.2 shows: Commit message (Expand) Author Age Files Lines Add UPDATING entry and bump versionreleng/12.2 Ed Maste2021-01-29 2 -1/+17 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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/stable and zpool upgrade
On Friday, 19 February 2021 12:24:24 CST Kurt Jaeger wrote:
> > > Unfortunately it contains an old version of the boot loader:
> [...]
> > We should be 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. 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 ?
>
Informed by reading the bsdinstall(8) scripts, I've been creating my own
boot1.efifat thusly:
#!/usr/bin/env sh
TMPDIR=/mnt
rm -f /boot/boot1.efifat
newfs_msdos -F 32 -c 1 -L EFISYS -C 200m /boot/boot1.efifat
MD=$(mdconfig -f /boot/boot1.efifat)
mount -t msdosfs /dev/${MD} ${TMPDIR}
mkdir -p ${TMPDIR}/efi/boot ${TMPDIR}/efi/freebsd
cp -a /boot/loader.efi ${TMPDIR}/efi/boot/bootx64.efi
cp -a /boot/loader.efi ${TMPDIR}/efi/freebsd/
umount ${TMPDIR}
mdconfig -d -u ${MD}
Then I use `gpart bootcode -p /boot/boot1.efifat ...` as usual.
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).
--
Greg
___
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"
13.0-BETA3 frequent file system (UFS) hangs
Hi, on Sunday I upgraded a lightly loaded web server (Nginx+PHP-FPM+MariaDB) from 12.2-RELEASE-p3 to 13.0-BETA3. The server has been hanging every few hours (between 2-12). Until now the only remedy I found was a reboot. When the issue appears I can still read from the file system, I was able to touch a (new) file, but not delete it. load: 0.49 cmd: rm 78200 [biowr] 7.31r 0.00u 0.28s 1% 2192k mi_switch+0xc1 _sleep+0x1cb bwait+0x6e bufwrite+0x206 ffs_update+0x2d0 ffs_syncvnode+0x552 softdep_prelink+0x14b ufs_remove+0x85 VOP_REMOVE_APV+0x27 kern_funlinkat+0x2d5 sys_unlink+0x28 amd64_syscall+0x10c fast_syscall_common+0xf8 The system is UFS only. /dev/da0s1a on / (ufs, local, noatime, journaled soft-updates, writes: sync 19483 async 3361, reads: sync 24501 async 4191, fsid 374666591e63cded) For some of the reboots I see the following in the log before rebooting: Feb 21 15:21:57 web01 kernel: Waiting (max 60 seconds) for system process `vnlru' to stop... done Feb 21 15:21:57 web01 kernel: Waiting (max 60 seconds) for system process `syncer' to stop... Feb 21 15:21:57 web01 kernel: Syncing disks, vnodes remaining... 20 fsync: giving up on dirty (error = 35) 0xf80003815b70: type VCHR Feb 21 15:21:57 web01 kernel: usecount 1, writecount 0, refcount 1074 seqc users 0 rdev 0xf80004c3f000 Feb 21 15:21:57 web01 kernel: hold count flags () Feb 21 15:21:57 web01 kernel: flags () Feb 21 15:21:57 web01 kernel: v_object 0xf800030d0c60 ref 0 pages 45500 cleanbuf 1071 dirtybuf 1 Feb 21 15:21:57 web01 kernel: lock type mntfs: EXCL by thread 0xfe00c33fc000 (pid 24, syncer, tid 100097) Feb 21 15:21:57 web01 kernel: 9 5 0 0 done Is this related to the thread "FreeBSD 13.0-BETA2 and slow IO" ? I have a stable/13 kernel on there now, but that also hung once already. Do I need to disable SU/SUJ or put a main kernel on there to get it stable? Thanks, Florian OpenPGP_signature Description: OpenPGP digital signature
Re: lots of "no such file or directory" errors in zfs filesystem
On 2021-Feb-23 11:30:58 -0600, Chris Anderson wrote: >nope, it led a pretty boring life. that zfs filesystem was created on that >server and has been on the same two mirrored disks for its lifetime. Does the server have ECC RAM? Possibly it's a bitflip somewhere before the data got to disk. >prior to the upgrades) the server does have a relatively modest amount of >ram (2GB). dunno if that makes it more likely that these kinds of issues >get triggered. Low amounts of RAM are going to increase the IO load but shouldn't otherwise impact the filesystem consistency. I have a FreeBSD test system that's running ZFS in <1GB RAM and rebuilding itself daily for multiple years and haven't run into any ZFS corruption issues. -- Peter Jeremy signature.asc Description: PGP signature
Re: When did pkg(8) drop support for 12-stable?
(Warner is only CC'd here.) Warner Losh imp at bsdimp.com wrote on Wed Feb 24 01:04:13 UTC 2021 : > On Tue, Feb 23, 2021, 4:51 PM Chris wrote: > > > Given this is a pkg(8) error, I brought it up on ports@ > > but it was suggested I (also?) bring it up here on stable@ > > > > OK awhile back I installed a copy of 12 stable from the > > usb stick image. I tweaked it to my wishes then got called > > away and haven't been able to get back to it until the other > > day. This is still a fresh install which has a populated /usr/src. > > So I > > svnlite co svn://svn.freebsd.org/ports/head /usr/ports > > followed by a > > cd /usr/ports/ports-mgmt/pkg/ && make install clean > > which returns > > make > > /!\ ERROR: /!\ > > > > Ports Collection support for your FreeBSD version has ended, and no ports > > are > > guaranteed to build on this syst > em. Please upgrade to a supported release. > > > > No support will be provided if you silence this message by defining > > ALLOW_UNSUPPORTED_SYSTEM. > > > > *** Error code 1 > > > > Stop. > > Err what? Ok while I think this was from stable 12.1, it's still still 12, > > and it's on stable. So what gives? > > > > 12.1 has reached EOL now that 12.2 has been out a while. >From release/12.1.0/ : "Tag releng/12.1@r354233 as release/12.1.0 (12.1-RELEASE)" I think that implicit in Warner's response is that versions of stable/12/ that are not after r354233 are also EOL. One needs to have stable/12/ material from after -r354233 in order for it to be supported. He might even mean that stable/12/ material from before: "Tag releng/12.2@r366954 as release/12.2.0 (12.2-RELEASE)" would also be considered as not supported. To be safe you should be using stable/12/ material from on or after -r366954 in order to have a supported context. (I'm not sure if anything is explicit about the status of stable/12/ material between releng/12.1@r354233 and releng/12.2@r366954 .) Since you did not provide the output from the likes of "uname -apKU" (or some rough equivalent) I've no direct clue which version you were trying. But you should be able to compare to the above to see which range the material is from. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: When did pkg(8) drop support for 12-stable?
On 2021-Feb-23, at 18:08, Chris wrote: > On 2021-02-23 17:42, Mark Millard wrote: >> (Warner is only CC'd here.) >> Warner Losh imp at bsdimp.com wrote on >> Wed Feb 24 01:04:13 UTC 2021 : >>> On Tue, Feb 23, 2021, 4:51 PM Chris wrote: >>> > Given this is a pkg(8) error, I brought it up on ports@ >>> > but it was suggested I (also?) bring it up here on stable@ >>> > >>> > OK awhile back I installed a copy of 12 stable from the >>> > usb stick image. I tweaked it to my wishes then got called >>> > away and haven't been able to get back to it until the other >>> > day. This is still a fresh install which has a populated /usr/src. >>> > So I >>> > svnlite co svn://svn.freebsd.org/ports/head /usr/ports >>> > followed by a >>> > cd /usr/ports/ports-mgmt/pkg/ && make install clean >>> > which returns >>> > make >>> > /!\ ERROR: /!\ >>> > >>> > Ports Collection support for your FreeBSD version has ended, and no ports >>> > are >>> > guaranteed to build on this syst >>> em. Please upgrade to a supported release. >>> > >>> > No support will be provided if you silence this message by defining >>> > ALLOW_UNSUPPORTED_SYSTEM. >>> > >>> > *** Error code 1 >>> > >>> > Stop. >>> > Err what? Ok while I think this was from stable 12.1, it's still still 12, >>> > and it's on stable. So what gives? >>> > >>> 12.1 has reached EOL now that 12.2 has been out a while. >>> From release/12.1.0/ : >> "Tag releng/12.1@r354233 as release/12.1.0 (12.1-RELEASE)" >> I think that implicit in Warner's response is that >> versions of stable/12/ that are not after r354233 are >> also EOL. One needs to have stable/12/ material from >> after -r354233 in order for it to be supported. >> He might even mean that stable/12/ material from before: >> "Tag releng/12.2@r366954 as release/12.2.0 (12.2-RELEASE)" >> would also be considered as not supported. >> To be safe you should be using stable/12/ material from >> on or after -r366954 in order to have a supported >> context. >> (I'm not sure if anything is explicit about the status >> of stable/12/ material between releng/12.1@r354233 >> and releng/12.2@r366954 .) > A HUGE thanks for all of this, Mark. This is EXACTLY what I needed. > > # uname -apKU > FreeBSD fbsd12dev 12.1-STABLE FreeBSD 12.1-STABLE r363918 GENERIC amd64 > amd64 1201522 1201522 > which pretty well confirms what you deduced. > I'm still a bit confused. It seems to me that it didn't _used_ > to be that way. But my brain isn't using ECC. So a couple of > bits may be flipped. The implication of all of stable/12/ being supported would be support of stable/12/ from on or after its creation: QUOTE Revision 339434 - Directory Listing Modified Fri Oct 19 00:09:24 2018 UTC (2 years, 4 months ago) by gjb Copied from: head revision 339432 Copy head@r339432 to stable/12 as part of the 12.0-RELEASE cycle. Additional post-branch commits will follow. END QUOTE Such does not seem likely to me. What would be the point of dropping 12.0-RELEASE support and 12.1-RELEASE support if such stable/12/ history was covered, some of that history being minor variations on the 12.0-RELEASE or 12.1-RELEASE ? Note: Despite some claims in other messages, svn -r363918 is not 12.1-RELEASE ( not -r354233 ) and -r363918 is shown as (only) in stable/12/ by svn. Your claim of 12-STABLE was correct, just not detailed enough. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: Drastic slowdown for geli attach
On Wednesday, 24 February 2021 23:34:06 CST Kevin Oberman wrote: > Sometime around the first week of this month (February) the time to do a > geli attach on my 13.0-ALPHA3 amd64 system sharply increased. It started > taking about 10 seconds. Prior to this, it took about 3-4 seconds. I have > not seen any issues with the disc after it attaches, I am simply concerned > that the longer time may be indicative of a deeper issue. > Just for reference, I have not experienced this with 13.0-BETA3. > The system is a ThinkPad L15 with a CometLake i5-10210U and a Seagate > ST2000LM007-1R8174 2T HDD. > I have 13.0-BETA3 on a HP laptop (HP EliteBook 850 G1) and on a small low-power PC (Gigabyte J1900N-D3V). No issues of any kind so far. I know this doesn't help you directly, but at least it's a data point. -- Greg ___________ 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: How do I know if my 13-stable has security patches?
4 |\ | * Update vendor/openzfs to master-9312e0fd1vendor/openzfs Martin Matuska 4 days 36 -247/+716 * | Fix build after 2c7dc6bae9fd. Alexander Motin 4 days 1 -0/+4 * | Refactor CTL datamove KPI. Alexander Motin 4 days 12 -162/+94 * | jail: Add pr_state to struct prison Jamie Gritton 4 days 2 -51/+65 * | vfs: shrink struct vnode to 448 bytes on LP64 Mateusz Guzik 4 days 1 -1/+12 * | jail: fix build after the previous commit Mateusz Guzik 4 days 1 -1/+1 * | jail: Change the locking around pr_ref and pr_uref Jamie Gritton 4 days 6 -235/+232 * | sctp: improve computation of an alternate net Michael Tuexen 5 days 1 -36/+49 * | sctp: clear a pointer to a net which will be removed . . . (all the prior history) . . . and an empty vs. non-empty status is easier to tell apart. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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"
Trying do mount a slice containing a mounted partition makes the filesystem unreadable
Dear All, I think I found a bug that is similar to an already reported one, but I am not sure. Description: when a BSD partition is mounted to / (suppose /dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I receive a ``strange'' error message, and from that moment the mounted filesystem becomes unreadable. This problem appears: - on a memstick built from 11.4-STABLE r369279, - on the ``official'' 12.2-RELEASE memstick, both tested on amd64. Fun fact: the problem does _not_ appear if the already-mounted filesystem is mounted from /dev/ufs/label instead of /dev/da0s2a. Steps to reproduce on 12.2-RELEASE == 1- download the official memstick image for 12.2-RELEASE-amd64 and flash it into a USB pen drive 2- edit /boot/loader.conf on the memstick adding the following lines (needed to boot successfully on my test system): kern.vty=sc kern.cam.boot_delay=1 kern.cam.scsi_delay=1 3- edit /etc/fstab on the memstick and change the root device from /dev/ufs/FreeBSD_Install to /dev/da0s2a 4- boot the memstick and open a shell 5- # mount /dev/da0s2 /mnt mount: /dev/da0s2: No such file or directory <--- strange message! 6- the filesystem is now unreadable! For example, trying to run some binaries not yet in the cache: # man /usr/bin/man: Device not configured If I try to reboot, the console is flooded by: > vm_fault: pager read error, pid 1 (init) This problem also appears on a memstick built from 11.4-STABLE r369279. The error messages are different, but the outcome is the same. Expected behavior = If the root partition is mounted from /dev/ufs/label (i.e. you skip step 3 above) the culprit mount command (step 5 above) gives the following error message: > mount: /dev/da0s2: Operation not permitted and the system remains healty and stable. Am I seeing PR 222948: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222948 or is it something else? Thank you in advance and best regards, -- Arrigo http://rigo.altervista.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: Trying do mount a slice containing a mounted partition makes the filesystem unreadable
Hello Helge, Kevin, and thank you for replying. On Sat, Feb 27, 2021 at 09:21:39AM +0100, Helge Oldach wrote: > Kevin P. Neal wrote on Sat, 27 Feb 2021 03:04:35 +0100 (CET): > > On Fri, Feb 26, 2021 at 06:25:05PM +0100, Helge Oldach wrote: > > > Arrigo Marchiori via freebsd-stable wrote on Fri, 26 Feb 2021 17:02:35 > > > +0100 (CET): > > > > Description: when a BSD partition is mounted to / (suppose > > > > /dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I > > > > receive a ``strange'' error message, and from that moment the mounted > > > > filesystem becomes unreadable. > > > > > > Actually you are mounting the same location on disk twice under > > > different file systems which is a bad idea. > > > > > > For example: > > > > > > # gpart show -p ada0s2 > > > =>0 250064341 ada0s2 BSD (119G) > > > 0 241172480 ada0s2a freebsd-ufs (115G) > > > 2411724808891861 ada0s2b freebsd-swap (4.2G) > > > > > > Note the "0" offset for both ada0s2 and ada0s2a. When you mount, both > > > "look" like a proper, distinct UFS but actually it's the same location > > > on disk so UFS will get confused if you have both mounted rw. It should > > > go well however if only one is mounted rw and the other(s) ro. I believe that the memstick images may not organized as you pointed out. The standard behavior of mkimg(1) is to leave a small gap between the beginning of the slice and the beginning of the first partition. But I will be able to confirm on Monday, when I will be back to the office. > > Wait, really? It seems like the ro mount wouldn't see any blocks (or other > > unit of data) cached by the rw mount. So the ro mount would see an > > inconsistent filesystem and I personally would expect a crash or other > > misbehavior. > > Of course the ro "view" will show inconistencies. That's actually what > one asks for if doing such bad things as mounting volumes twice. However > it shouldn't crash as the rw mount of / maintains consistency. On the memstick, the root filesystem is mounted read-only. I apologize, I should have told it explicitly. The ``invalid'' attempt is to mount it read-write (no mode is indicated on the command line). I did not try the mount command in read-only mode. I can try this on Monday as well. IMHO it is important to note that everything works as expected when the partition is mounted from /dev/ufs/label: the mount attempt is not permitted and nothing else happens. Even if mounting an already-mounted partition is an invalid action, I do not think that it should render a system unstable. I understand that ``the root user should be allowed to do anything'', even shoot themselves in the foot. But on the other hand, there are features such as kern.geom.debugflags that explicitly avoid it. I hope I could explain myself clearly. Best regards, -- Arrigo http://rigo.altervista.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: Trying do mount a slice containing a mounted partition makes the filesystem unreadable
Hello Helge, and thank you for replying again. On Sat, Feb 27, 2021 at 03:43:52PM +0100, Helge Oldach wrote: > Arrigo Marchiori via freebsd-stable wrote on Sat, 27 Feb 2021 14:00:24 +0100 > (CET): > > On the memstick, the root filesystem is mounted read-only. I > > apologize, I should have told it explicitly. The ``invalid'' attempt > > is to mount it read-write (no mode is indicated on the command line). > > Try to make it r/w mounted (which I suspect you are attempting to > achieve): > > mount -uw / Ok, I will try this. But just for the record: I am not try to achieve anything. I gave the ``invalid'' mount command by mistake (I wanted to mount a partition from another disk and wrote "da0" instead of "da1") and I saw that the system became unstable. I thought that this should not happen and I reported it here. Best regards, -- Arrigo http://rigo.altervista.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: Trying do mount a slice containing a r/o mounted partition makes the filesystem unreadable
Dear All, On Sat, Feb 27, 2021 at 04:34:52PM +0100, Arrigo Marchiori via freebsd-stable wrote: > Hello Helge, and thank you for replying again. > > On Sat, Feb 27, 2021 at 03:43:52PM +0100, Helge Oldach wrote: > > > Arrigo Marchiori via freebsd-stable wrote on Sat, 27 Feb 2021 14:00:24 > > +0100 (CET): > > > On the memstick, the root filesystem is mounted read-only. I > > > apologize, I should have told it explicitly. The ``invalid'' attempt > > > is to mount it read-write (no mode is indicated on the command line). > > > > Try to make it r/w mounted (which I suspect you are attempting to > > achieve): > > > > mount -uw / > > Ok, I will try this. > > But just for the record: I am not try to achieve anything. I gave the > ``invalid'' mount command by mistake (I wanted to mount a partition > from another disk and wrote "da0" instead of "da1") and I saw that the > system became unstable. I thought that this should not happen and I > reported it here. I have two updates. 1- the da0s2a slice starts 16 (blocks?) after the beginning of da0s2. bsdlabel(8) output (copied by hand): # /dev/da0s2: 8 partitions: # size offsetfstype[fsize bsize bps/cpg] a: 1491200 164.2BSD 0 0 0 c: 1491216 0unused 0 0 # "raw" part, don't edit 2- if I mount the partition rw, then the mount command _always_ fails with error "operation not permitted" and the system _always_ remains stable. This is independent from mounting from /dev/ufs/label or /dev/da0s2a. Therefore I can change the description of this problem report as: 8<8<8<8<8<8<8<- When a BSD partition is mounted _read_only_ to / (suppose /dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I receive a ``strange'' error message, and from that moment the mounted filesystem becomes unreadable. - If the partition is mounted from /dev/ufs/label, then mount(8) reports "Operation not permitted" and the system remains stable. This is the expected behavior IMHO. - If the partition is mounted read_write, from any special device, then mount(8) reports: - "Operation not permitted" if I try to mount the slice rw, - the same strange error message if I try to mount the slice ro, and the system remains stable. - The "strange error message" is "invalid argument" on 11.4-STABLE. 8<8<8<8<8<8<8<- Now to the question: is this worth a PR? Was it already reported? Or is it just something that ``should not happen'' because root should be allowed to shoot themselves in the foot? Thank you in advance and best regards, -- Arrigo http://rigo.altervista.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: FreeBSD 13.0-BETA2 and slow IO
Kevin Oberman rkoberman at gmail.com wrote on Mon Mar 1 07:11:32 UTC 2021 : > On Sun, Feb 28, 2021 at 12:49 PM Christos Chatzaras > wrote: > > > Did someone test if this is fixed in BETA4? > > > > Just tried to "make extract" on firefox and I am still seeing transfer > rates around 1.7M when I would expect more like 50M. If I see the same > thing others are, it runs for a while at >40MB and abruptly drops to > 1.5-20M for some random time varying from a few seconds to minutes before > jumping back to >40MB. Is this what others are seeing? I'll note that someone submitted: https://lists.freebsd.org/pipermail/freebsd-bugs/2021-March/100124.html against 13.0-BETA4 for the UFS journaled soft-updates related performance issue(s). They compared something to 12.1-RELEASE for illustration. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: Trying do mount a slice containing a r/o mounted partition makes the filesystem unreadable
Dear All, On Tue, Mar 02, 2021 at 10:55:15AM +0200, Andriy Gapon wrote: > On 02/03/2021 09:50, Arrigo Marchiori via freebsd-stable wrote: > > Dear All, > > > > On Sat, Feb 27, 2021 at 04:34:52PM +0100, Arrigo Marchiori via > > freebsd-stable wrote: > > > >> Hello Helge, and thank you for replying again. > >> > >> On Sat, Feb 27, 2021 at 03:43:52PM +0100, Helge Oldach wrote: > >> > >>> Arrigo Marchiori via freebsd-stable wrote on Sat, 27 Feb 2021 14:00:24 > >>> +0100 (CET): > >>>> On the memstick, the root filesystem is mounted read-only. I > >>>> apologize, I should have told it explicitly. The ``invalid'' attempt > >>>> is to mount it read-write (no mode is indicated on the command line). > >>> > >>> Try to make it r/w mounted (which I suspect you are attempting to > >>> achieve): > >>> > >>> mount -uw / > >> > >> Ok, I will try this. > >> > >> But just for the record: I am not try to achieve anything. I gave the > >> ``invalid'' mount command by mistake (I wanted to mount a partition > >> from another disk and wrote "da0" instead of "da1") and I saw that the > >> system became unstable. I thought that this should not happen and I > >> reported it here. > > > > I have two updates. > > > > 1- the da0s2a slice starts 16 (blocks?) after the beginning of da0s2. > > bsdlabel(8) output (copied by hand): > > # /dev/da0s2: > > 8 partitions: > > # size offsetfstype[fsize bsize bps/cpg] > > a: 1491200 164.2BSD 0 0 0 > > c: 1491216 0unused 0 0 # "raw" part, don't > > edit > > > > 2- if I mount the partition rw, then the mount command _always_ fails > > with error "operation not permitted" and the system _always_ remains > > stable. This is independent from mounting from /dev/ufs/label or > > /dev/da0s2a. > > > > Therefore I can change the description of this problem report as: > > > > 8<8<8<8<8<8<8<- > > > > When a BSD partition is mounted _read_only_ to / (suppose > > /dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I > > receive a ``strange'' error message, and from that moment the mounted > > filesystem becomes unreadable. > > > > - If the partition is mounted from /dev/ufs/label, then mount(8) > > reports "Operation not permitted" and the system remains stable. > > This is the expected behavior IMHO. > > > > - If the partition is mounted read_write, from any special device, > >then mount(8) reports: > > - "Operation not permitted" if I try to mount the slice rw, > > - the same strange error message if I try to mount the slice ro, > >and the system remains stable. > > > > - The "strange error message" is "invalid argument" on 11.4-STABLE. > > > > 8<8<8<8<8<8<8<- > > > > Now to the question: is this worth a PR? Was it already reported? Or > > is it just something that ``should not happen'' because root should be > > allowed to shoot themselves in the foot? > > > > Thank you in advance and best regards, > > I think that this is worth a PR. Just reported: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254005 > I think that even when mounting read-only the underlying GEOM object should be > marked for exclusive use. > I vaguely recall that UFS has some quirk in this respect to allow for > modifications by fsck. That is supposed to be limited to the root filesystem. > Maybe it should further be limited to certain boot stages to prevent > foot-shooting after a system is fully booted. Thank you and best regards, -- Arrigo http://rigo.altervista.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: Filesystem operations slower in 13.0 than 12.2
>175 block output operations > 4412 messages sent >2536379 messages received > 0 signals received > 385527 voluntary context switches >369 involuntary context switches > > -- > > Differences between 13.0 and 14-CURRENT maybe related to debugging features. > > But 13.0-BETA4 is slower than 12.2. Does someone have more information about > this? Again, I expect that the "time -l" figures may point in different directions for "portsnap extract" vs. "rm -fr /usr/ports" in your context. The question may need to be split because the answers may be different. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: Filesystem operations slower in 13.0 than 12.2
0 messages received >> 0 signals received >>354648 voluntary context switches >> 322 involuntary context switches >> >> -- >> >> FreeBSD 13.0-BETA2 (2021-02-12) >> >> 497.88 real76.06 user 120.03 sys >> 49032 maximum resident set size >>22 average shared memory size >> 3 average unshared data size >>91 average unshared stack size >> 12288156 page reclaims >>23 page faults >> 0 swaps >> 29890 block input operations >>621229 block output operations >> 4412 messages sent >> 2536379 messages received >> 0 signals received >> 1004790 voluntary context switches >> 251 involuntary context switches >> >> -- >> >> FreeBSD 13.0-BETA4 (2021-02-26) >> >> 163.81 real71.93 user 107.32 sys >> 49032 maximum resident set size >>21 average shared memory size >> 3 average unshared data size >>89 average unshared stack size >> 12288156 page reclaims >> 5 page faults >> 0 swaps >> 716 block input operations >> 868 block output operations >> 4412 messages sent >> 2536379 messages received >> 0 signals received >>355244 voluntary context switches >> 277 involuntary context switches >> >> -- >> >> FreeBSD 14-CURRENT (2021-03-04) >> >> 255.43 real74.94 user 148.90 sys >> 49032 maximum resident set size >>23 average shared memory size >> 3 average unshared data size >>96 average unshared stack size >> 12288156 page reclaims >>23 page faults >> 0 swaps >> 31207 block input operations >> 175 block output operations >> 4412 messages sent >> 2536379 messages received >> 0 signals received >>385527 voluntary context switches >> 369 involuntary context switches >> >> -- >> >> Differences between 13.0 and 14-CURRENT maybe related to debugging features. >> >> But 13.0-BETA4 is slower than 12.2. Does someone have more information about >> this? > > Again, I expect that the "time -l" figures may point in > different directions for "portsnap extract" vs. > "rm -fr /usr/ports" in your context. The question may > need to be split because the answers may be different. > While I still think explicit "rm -fr" figures would be good to show, I no longer read so much into the messages sent and received figure differences. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: Filesystem operations slower in 13.0 than 12.2
Konstantin Belousov kostikbel at gmail.com wrote on Fri Mar 5 23:12:13 UTC 2021 : > On Sat, Mar 06, 2021 at 12:27:55AM +0200, Christos Chatzaras wrote: . . . > > Command: /usr/bin/time -l portsnap extract (these tests done with 2 > > different idle servers but with same 4TB HDDs models) > > > > FreeBSD 12.2p4 > > > >99.45 real34.90 user59.63 sys > > 100.00 real34.91 user59.97 sys > >82.95 real35.98 user60.68 sys > > > > FreeBSD 13.0-RC1 > > > > 217.43 real75.67 user 110.97 sys > > 125.50 real63.00 user96.47 sys > > 118.93 real62.91 user96.28 sys > . . . > In the portsnap results for 13RC1, the variance is too high to conclude > anything, I think. I'll note that there are other reports of wide variance in transfer rates observed during an overall operation such as "make extract". The one I'm thinking of is: https://lists.freebsd.org/pipermail/freebsd-stable/2021-March/093251.html which is an update to earlier reports, but based on more recent stable/13. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253968 comment 4 has some more notes about the context. The "make extract" for firefox likely is not as complicated as the portsnap extract example's execution structure. Might be something to keep an eye on if there are on-going examples of over time. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ 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"
geli broken in 13.0-BETA4 and later
Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 (releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - RK3399, arm64) has changed so that a geli-encrypted partition (using AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on 13.0-BETA4. I've verified that the garbage seems consistent between reboots and isn't impacted by enabling the big cores in 7ba4d0f82955. There's nothing useful reported via geli debugging. I've tried updating to releng/13.0 60e8939aa85b and it's still broken. My suspicion is f76393a6305b - whilst that just talks about AES-GCM, it does a reasonable job of roto-tilling the entire armv8crypto stack. I notice that there are a fixes to f76393a6305b that don't seem to have made it into releng/13.0 and I will continue to investigate. -- Peter Jeremy signature.asc Description: PGP signature
Re: geli broken in 13.0-BETA4 and later
On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable wrote: >Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >RK3399, arm64) has changed so that a geli-encrypted partition (using >AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on >13.0-BETA4. I've confirmed that the problem is f76393a6305b - reverting that commit fixes the problem in releng/13.0. I've further verified that the bug is still present in main (14.x) at 028616d0dd69. -- Peter Jeremy signature.asc Description: PGP signature
Re: geli broken in 13.0-BETA4 and later on armv8
[Adding arm@ and making it clearer that this is armv8-only] On 2021-Mar-06 20:26:19 +1100, Peter Jeremy wrote: >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable > wrote: >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >>RK3399, arm64) has changed so that a geli-encrypted partition (using >>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on >>13.0-BETA4. > >I've confirmed that the problem is f76393a6305b - reverting that >commit fixes the problem in releng/13.0. > >I've further verified that the bug is still present in main (14.x) >at 028616d0dd69. -- Peter Jeremy signature.asc Description: PGP signature
Re: geli broken in 13.0-BETA4 and later on armv8
On 2021-Mar-06 10:39:02 -0800, Oleksandr Tymoshenko wrote: >Peter Jeremy via freebsd-current (freebsd-curr...@freebsd.org) wrote: >> [Adding arm@ and making it clearer that this is armv8-only] >> >> On 2021-Mar-06 20:26:19 +1100, Peter Jeremy >> wrote: >> >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable >> > wrote: >> >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >> >>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >> >>RK3399, arm64) has changed so that a geli-encrypted partition (using >> >>AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on >> >>13.0-BETA4. >> > >> >I've confirmed that the problem is f76393a6305b - reverting that >> >commit fixes the problem in releng/13.0. >> > >> >I've further verified that the bug is still present in main (14.x) >> >at 028616d0dd69. > >Could you test this patch and let me know if it fixes the issue? > >https://people.freebsd.org/~gonzo/patches/armv8crypto-xts-fix.diff Yes, it does. Thank you very much. --- Peter Jeremy signature.asc Description: PGP signature
Re: Filesystem operations slower in 13.0 than 12.2
g. SMART shows no errors and reasonable values for > everything. No indication of a HW problem. The system performs well unless I > do something that tries a bulk disk data move. Building world takes about 75 > minutes. I just have a very hard time building big ports. Almost like things were stuck-sleeping and then the sleep(s) finished? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: Filesystem operations slower in 13.0 than 12.2
VM_CNT_INC(v_intrans);
>>> if (VM_OBJECT_SLEEP(object, &object->handle, PSWP,
>>> "swread", hz * 20)) {
>>> printf(
>>> "swap_pager: indefinite wait buffer: bufobj: %p, blkno: %jd, size: %ld\n",
>>> bp->b_bufobj, (intmax_t)bp->b_blkno,
>>> bp->b_bcount);
>>> }
>>> }
>>> VM_OBJECT_WUNLOCK(object);
>>> . . .
>>>
>>> where:
>>>
>>> #define VM_OBJECT_SLEEP(object, wchan, pri, wmesg, timo)\
>>> rw_sleep((wchan), &(object)->lock, (pri), (wmesg), (timo))
>>>
>>> and:
>>>
>>> #define rw_sleep(chan, rw, pri, wmesg, timo)\
>>> _sleep((chan), &(rw)->lock_object, (pri), (wmesg), \
>>> tick_sbt * (timo), 0, C_HARDCLOCK)
>>>
>>> (I do not claim to be able to interpret the implications
>>> of the code that leads to the messages. But seeing some
>>> of the code might prompt a thought by someone that knows
>>> the code's context and operation.)
>>>
>>> > . . .
>>> > Backing off to Mar. 4 was not an improvement. My untar did seem better
>>> > for a couple of minutes, but then the display froze again for 30 seconds
>>> > and disk performance dropped to <1M.
>>
>> You were able to see the disk performance drop while
>> the display was frozen?
>>
>
> No, but it refreshed the display when it un-froze and the refreshed display
> showed a one-minute history that showed that data was still transferring
> during the pause.
>
>> It might not be the best for monitoring but I'll ask
>> this in terms of top output: Does Inact, Laundry,
>> Wired, Free, or other such show anything fairly unique
>> for around the problematical time frame(s)?
>
> These all look pretty normal. Free memory stays at 13G throughout hte
> operatioin.
>
>>> > then things got really bad and behaved in a manner that was baffling to
>>> > me. The screen froze again, but stayed frozen after half a minute. I
>>> > clicked on a couple of buttons in Firefox to no effect and then hit
>>> > ctrl-q to quit. After the long pause, I pressed the power button to try
>>> > to force a shutdown. Suddenly, it started unwinding everything I had done
>>> > during the freeze. My browser did the updates from my mouse clicks
>>> > including quitting. It then switched to a different workspace from
>>> > ctrl-alt-right and did a clean shutdown.
>>> >
>>> > Do I also have a graphics issue? Examining log files show no indication
>>> > that anything was happening. SMART shows no errors and reasonable values
>>> > for everything. No indication of a HW problem. The system performs well
>>> > unless I do something that tries a bulk disk data move. Building world
>>> > takes about 75 minutes. I just have a very hard time building big ports.
>>
>> Almost like things were stuck-sleeping and then the
>> sleep(s) finished?
> Exactly!
Multi-socket (and possibly multi-core) PowerMacs have
not historically had the times used for controlling
sleeping that can be used across FreeBSD's cpus well
matched in any FreeBSD build without extra patches.
They suffer threads being stuck-sleeping for periods
not intended. This leads to fans running wild and
obvious problems during shutdown having timeouts,
though there are more consequences than are so
obvious.
That is where I got the idea for the question: some
similarity to operational problems that I've seen
when not using my patches that provide a work around
matching the times better in my contexts.
(I'm told the type of issue is not limited to PowerMacs,
but PowerMacs are the only PowerPCish machines I've
had access to. Doing the most accurate time matching
gets into platform specific operations, no general
solution for such accuracy. Similarly, only platform
specifics might scale to lots of sockets/cores well,
even without trying to be as well matched. My workaround
is generic to the range of PowerMacs that I've had
access to but is not as accurate about matching the
times.)
For your context: how many sockets? Cores per socket?
Any other information that might be relevant to
matching times across sockets/cores? I suppose that
the board matters, not just the processor(s) in the
sockets. But what all would be appropriate information?
I do not know.
I'm not sure if the kern.hz=100 results fit with this
idea or not. (Such was never involved in my PowerMac
experiments.)
It is only somewhat suggestive evidence as stands. But
time mismatches across socket/cores might be a
direction for investigation? (Not that I've a great
idea for how to investigate such.)
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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"
ThinkPad X1 Carbon Gen 4 unable to boot 13.0-RC1
I have a ThinkPad X1 Carbon Gen 4 (20FCS0NB00) which has happily run FreeBSD 11 and 12, but which can't boot 13.0-RC1 from memstick or via freebsd-update. In both cases the boot process locks up on the line "hwpstate_intel0: on cpu0" If running freebsd-update, a work around is to add hint.hwpstate_intel.0.disabled="1" in loader.conf. See the note under the Eighth Generation (2020) in https://wiki.freebsd.org/Laptops/Thinkpad_X1_Carbon I was quite surprised to find the lack of support for hwpstate_intel in 13 when it apparently worked under 11 and 12. Does anyone know the status of hwpstate_intel on ThinkPads? Cheers, Fred ___________ 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-RC3 Now Available
Hello, I see the RC3 in the "Latest News" but not here: https://www.freebsd.org/releases/13.0R/schedule/ I hope I'm writing to the proper channels/list about this. Regards, meka signature.asc Description: PGP signature
Re: Filesystem operations slower in 13.0 than 12.2
On 2021-Mar-22, at 22:51, Kevin Oberman wrote: > On Mon, Mar 22, 2021 at 8:19 AM Adrian Chadd wrote: >> On Mon, 15 Mar 2021 at 14:58, Kevin Oberman wrote: >> >> > > >> > > It appears that the messages are associated with reading >> > > the disk(s), not directly with writing them, where the >> > > reads take more than "hz * 20" time units to complete. >> > > (I'm looking at main (14) code.) What might contribute >> > > to the time taken for the pending read(s)? >> > > >> > The reference to hz * 20 woke up a few sleeping memory cells. I forgot that >> > I cleaned up my loader.conf. It was largely a copy of the one on my >> > decade-old T520. I commented out "kern.hz=100". I don't recall the details, >> > but I think it was actually from an even older system, my T42 from before I >> > retired. >> > >> > In any case, restoring this setting has greatly improved the situation. I >> > now have really bad disk I/O performance on large disk to disk activity >> > (untarring the firefox distro) instead of terrible performance and the >> > system freezes have vanished, though I do see pauses in response to clicks >> > or text entry, but the display remains active and the pauses are short... 1 >> > to 15 seconds, I'd guess. No, I have no idea what this indicates. >> >> ... which drive controller is this? Is it just a laptop ATA disk? >> >> > I'm still not seeing the performance I was seeing back in February when 40 >> > MB/s for extended intervals was common and I once untarred firefox.tar.gz2 >> > in under a minute and performance seldom dropped below 1.4 MB/s. >> >> Did you find a resolution? I wonder if setting kern.hz is kicking >> some process(es) to get some time more frequently due to bugs >> elsewhere in the system (interrupts, IPI handling, wake-ups, etc) >> >> >> >> -adrian > No resolution. This is a Lenovo L15 ThinkPad with a 2TB ATAPI drive. I've not found documentation indicating the "which drive controller" answer. That may have to be answered from boot messages or boot -v messages or other such on FreeBSD. (I've no access to such a machine.) You might want to put a copy of such a log someplace that folks could look at it. There may be commands that some folks would like to see the output of. (I'm not all that likely to be one that could put such to use but other folks might be able to.) Intel® Celeron®? 10th Generation Intel CoreTM i3? i5? i7? > The current drive is a Seagate. All testing has been done since I got it > back from Lenovo in late January. I can read or write the drive at reasonable > rates that exceed 50 MB/s. Extracting a tar distribution file is painful. I > have had firefox extracts take over a half hour. Worse, if I do other > operations while the extract is taking place, I often see a 30 second (and, > occasionally 60 second) display freezes I thought that you had reported that use of kern.hz=100 had lead to "the system freezes have vanished" and "pauses are short... 1 to 15 seconds". Did more testing show that to not be always the case? > as well as log reports that of "swap_pager: indefinite wait buffer:" Unfortunately, I do not know how to investigate what is leading to those message being generated. Figuring that out would seem to be important but I do not know what to monitor to at least potentially eliminate some possibilities. One possible thing to look at is something like "gstat -spod" output spanning the time of the untar. It would at least indicate if a large queue backlog was accumulating on the device. And the ms/r and ms/w columns would give a clue if commands are sitting in the queues for long periods. (The "d" may be a waste: no BIO_DELETEs possible? Also, the r/s vs. ms/r are not rescaled reciprocals but distinct measurements. Similarly for: the w/s vs. ms/w.) Given the "indefinite wait buffer" messages, I expect the ms/r and/or ms/w figures to be large at least some of the time. Knowing how large may be of use to someone. But I can not eliminate anything with such information. > This is a bit odd as I have 20G of RAM and am pretty close to no swap space > activity, but, of course, paging does occur. With 20 GiBytes of RAM, what is going on at the time that leads to paging activity? I'm thinking of just untarring the firefox file, not building firefox or such. Can you test such an untar in a context that is not otherwise paging (nor swapping)? If yes, is the behavior different in any readily noticeable way? > This system is CometLake and graphics are not supported on 12. I am no
qlnxe driver not in 13.0 arm64
I installed 13.0-RC3 ARM64 from the DVD ISO image (FreeBSD-13.0-BETA4-arm64-aarch64-dvd1.iso <http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.0/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? _______ 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
On 30/03/21 15:35, tech-lists wrote: Hi, Recently there was https://lists.freebsd.org/pipermail/freebsd-security/2021-March/010380.html about openssl. Upgraded to 12.2-p5 with freebsd-update and rebooted. What I'm unsure about is the openssl version. Up-to-date 12.1-p5 instances report OpenSSL 1.1.1h-freebsd 22 Sep 2020 Up-to-date stable/13-n245043-7590d7800c4 reports OpenSSL 1.1.1k-freebsd 25 Mar 2021 shouldn't the 12.2-p5 be reporting openssl 1.1.1k-freebsd as well? No, as you can see in the commit in the official git [1] while for current and stable the new upstream version of openssl was imported for the release the fix was applied without importing the new release and without changing the reported version of the library. So with 12.2p5 you do get the fix but don't get a new version of the library. [1] https://cgit.freebsd.org/src/commit/?h=releng/12.2&id=af61348d61f51a88b438d41c3c91b56b2b65ed9b -- Guido Falsi _______ 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
On 30/03/21 17:38, tech-lists wrote: On Tue, Mar 30, 2021 at 05:22:30PM +0200, Guido Falsi via freebsd-stable wrote: No, as you can see in the commit in the official git [1] while for current and stable the new upstream version of openssl was imported for the release the fix was applied without importing the new release and without changing the reported version of the library. So with 12.2p5 you do get the fix but don't get a new version of the library. [1] https://cgit.freebsd.org/src/commit/?h=releng/12.2&id=af61348d61f51a88b438d41c3c91b56b2b65ed9b On this url, near the top, there's this: "Fix multiple OpenSSL vulnerabilities. Add UPDATING and bump version." next to that, we have "releng/12.2". So, I'm expecting the version information pertaining to opensslto be bumped. Is this expectation unreasonable? I'm not a developer. The "bumping verion" part refers to bumping the FreeBSD version, that's the p4 -> p5 part of the patch, last hunk referring to file sys/conf/newvers.sh -- Guido Falsi ___ 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
To test it with a custom kernel, would I only need to add these lines
(https://cgit.freebsd.org/src/tree/sys/conf/files.amd64#n279-306)?
|dev/qlnx/qlnxe/ecore_cxt.c optional qlnxe pci \ compile-with
"${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_dbg_fw_funcs.c optional qlnxe pci \
compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_dcbx.c optional qlnxe
pci \ compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_dev.c optional
qlnxe pci \ compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_hw.c
optional qlnxe pci \ compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_init_fw_funcs.c optional qlnxe pci \ compile-with
"${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_init_ops.c optional qlnxe pci \
compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_int.c optional qlnxe
pci \ compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_l2.c optional
qlnxe pci \ compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_mcp.c
optional qlnxe pci \ compile-with "${LINUXKPI_C}"
dev/qlnx/qlnxe/ecore_sp_commands.c optional qlnxe pci \ compile-with
"${LINUXKPI_C}" dev/qlnx/qlnxe/ecore_spq.c optional qlnxe pci \
compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/qlnx_ioctl.c optional qlnxe
pci \ compile-with "${LINUXKPI_C}" dev/qlnx/qlnxe/qlnx_os.c optional
qlnxe pci \ compile-with "${LINUXKPI_C}"|
On 3/30/21 3:00 PM, Hans Petter Selasky wrote:
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
<http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.0/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
smime.p7s
Description: S/MIME Cryptographic Signature
powerpc64le is missing in: https://www.freebsd.org/platforms/
When I looked at https://www.freebsd.org/platforms/ I noticed that "64-bit little-endian PowerPC" powerpc64le is not listed. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______ 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
I tried to move the lines, but maybe I did something wrong since it failed to build. make[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/usr/src/arm64.aarch64/sys/THUNDERX2 15 errors The full output is here: http://venus.morante.net/downloads/unibia/freebsd/misc/arm64/qlnxe_13.0-RC4-arm64.log On 3/30/21 2: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 <http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/13.0/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.. # # GENERIC -- Generic kernel configuration file for FreeBSD/arm64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (https://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD$ cpu ARM64 ident GENERIC makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options NUMA# Non-Uniform Memory Architecture support options PREEMPTION # Enable kernel thread preemption options VIMAGE # Subsystem virtualization, e.g. VNET options INET# InterNETworking options INET6 # IPv6 communications protocols options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 options ROUTE_MPATH # Multipath routing support options TCP_OFFLOAD # TCP offload options TCP_HHOOK # hhook(9) framework for TCP options TCP_RFC7413 # TCP Fast Open options SCTP_SUPPORT# Allow kldload of SCTP options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options QUOTA # Enable disk quotas for UFS options MD_ROOT # MD is a potential root device options NFSCL # Network Filesystem Client options NFSD# Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options TMPFS # Efficient memory filesystem options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options EFIRT # EFI Runtime Services support options COMPAT_FREEBSD32# Compatible with FreeBSD/arm options COMPAT_FREEBSD11# Compatible with FreeBSD11 options COMPAT_FREEBSD12# Compatible with FreeBSD12 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options S
Re: Update to the 13.0-RELEASE schedule
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: Deprecating base system ftpd?
My vote is for no. Reasoning is simple... at what point does it stop? By continuously moving stuff from base to ports, FreeBSD slowly becomes just a Kernel. 😉 On 4/3/2021 4:39 PM, Ed Maste wrote: I propose deprecating the ftpd currently included in the base system before FreeBSD 14, and opened review D26447 (https://reviews.freebsd.org/D26447) to add a notice to the man page. I had originally planned to try to do this before 13.0, but it dropped off my list. FTP is not nearly as relevant now as it once was, and it had a security vulnerability that secteam had to address. I'm happy to make a port for it if anyone needs it. Comments? ___ 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" smime.p7s Description: S/MIME Cryptographic Signature
Re: Deprecating base system ftpd?
> On Apr 4, 2021, at 8:05 PM, Daniel Morante via freebsd-stable > wrote: > > My vote is for no. > > Reasoning is simple... at what point does it stop? By continuously moving > stuff from base to ports, FreeBSD slowly becomes just a Kernel. 😉 That’s a +1 here, both for the “keep it” and for the comment above regarding complete OS vs. kernel and a teeny userland. Ideally, we’d modernize ftpd to support TLS. The PITA with ports solutions is you immediate run into the issue of which of the many ftp daemons is going to fit your needs and not require some non-trivial amount of configuration. The stock ftpd ‘just works’ for local user accounts and has a simple method for blocking of swaths of users from using it if that sort of restriction is needed. This reminds me of Apple removing the telnet client. Sure, most people don’t *need* telnet, but it’s handy to have, both as a simple test tool and as a way to get into old crufty network gear that never moved on to ssh. Charles > > On 4/3/2021 4:39 PM, Ed Maste wrote: >> I propose deprecating the ftpd currently included in the base system >> before FreeBSD 14, and opened review D26447 >> (https://reviews.freebsd.org/D26447) to add a notice to the man page. >> I had originally planned to try to do this before 13.0, but it dropped >> off my list. FTP is not nearly as relevant now as it once was, and it >> had a security vulnerability that secteam had to address. >> >> I'm happy to make a port for it if anyone needs it. Comments? >> ___ >> 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" >> > signature.asc Description: Message signed with OpenPGP
Re: FreeBSD 13.0-RC5 Now Available
I don't know, ask yourself that, you did the same thing On 4/4/21 6:21 PM, Glen Barber wrote: Is it necessary to quote the*entire* email (including checksums)? Glen Sent from my phone. Please excuse my brevity and/or typos. ___ 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: Deprecating base system ftpd?
> On Apr 5, 2021, at 3:01 PM, Patrick M. Hausen wrote: > > Hi all, > > I absolutely freaked out when Apple removed the telnet and ftp clients > from Mac OS and I needed to reinstall them via MacPorts. Yep, and what I think many miss IRT to the stock ftpd is that it’s dumb simple and “just works”. For web hosting stuff I generally use something like Proftpd or vsftpd, and, IMHO, that’s when you should have to expend brain power to choose something from ports - when your use-case (supporting hosting customers, virtual users, etc.) requires a non-trivial ftp implementation. Also I can count on my left hand the number of web hosting customers I’ve run into that actually use scp for sftp or even know what that is. They’re using the same ftp client they’ve always used (ws-ftp quite often) and the last thing they want to do is learn something new. > People who manage any larger collection of networking gear *depend* > on these outdated but simple services. Client and server side alike. I frequently work with people who have limited budgets, and I don’t think I’m alone in that. Ebay is chock full of high-volume sellers turning over old networking gear that is amazingly good stuff that’s just outdated. I can grab a 48 port GigE switch with 10gb/s uplink ports for under $200. The market is gigantic, and putting old stuff to use on an internal network with proper safeguards is not totally crazy. Customers can have multiple fully-loaded spares on-site for less than what a year of SmartNet coverage would cost. My server platform of choice when I want a “support server” for this old stuff has always been FreeBSD. Stock tftpd and ftpd are wonderful, and anyone professing that those two tiny daemons are “bloat” just hasn’t used Linux. > TFTP is not going away, neither is FTP. I'm dead serious. Remote media > via Supermicro IPMI in 2021? SMB1. Firmware updates for my UPS? FTP. > Scanner/printer/fax all-in-one thingy? Uploads received fax transmissions > via FTP. PBX? Uploads usage reports via FTP. This stuff is here to stay. > In local networks, of course. Preach! And plenty of VoIP gear too! There are absolutely real world uses for these simple daemons, and I trust some stock FreeBSD daemon like this more than something I might fetch from ports - both in terms of knowing it’s had some kind of auditing/maintenance by qualified people and that it’s going to have an accurate manpage, sane defaults, and remain relatively simple/minimal. I think as everyone has moved to the cloud and devops and all that they forget about sysadmins standing up servers as simple utility boxes that support a bunch of other gear. > But still even on "the Internet", FTP is the most used method for customers > of static website hosting. You cannot teach these people what an SSH key is. > Just my experience, but backed by a load of customer interactions over more > than 20 years … I think some people mean well, and they imagine that if we just tell people to move to some monstrosity like Filezilla the problem is solved, but realistically it’s just a good way to lose paying customers. Charles > > Kind regards, > Patrick > -- > punkt.de GmbH > Patrick M. Hausen > .infrastructure > > Kaiserallee 13a > 76133 Karlsruhe > > Tel. +49 721 9109500 > > https://infrastructure.punkt.de > i...@punkt.de > > AG Mannheim 108285 > Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein > signature.asc Description: Message signed with OpenPGP
Re: Deprecating base system ftpd?
On 2021-04-05 02:05, Daniel Morante via freebsd-stable wrote: > My vote is for no. > > Reasoning is simple... at what point does it stop? By continuously moving > stuff from base to ports, FreeBSD slowly becomes just a Kernel. 😉 I strongly agree with this consideration. --- Andrea Brancatelli _______ 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"
Portsnap no updates since 3/31/2021 ?
I have several servers running 11.4 and 12.2 that do nightly portsnap updates and the last time they've seen anything new is 3/31/2021, since then, nothing. This seems highly unusual since seems like there was always SOMETHING updated daily now nothing. -- inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP: https://pgp.inoc.net/rblayzor/ ___ 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: Portsnap no updates since 3/31/2021 ?
> On Apr 6, 2021, at 7:10 AM, Gary Palmer wrote: > > On Tue, Apr 06, 2021 at 06:49:17AM -0400, Robert Blayzor via freebsd-stable > wrote: >> I have several servers running 11.4 and 12.2 that do nightly portsnap >> updates and the last time they've seen anything new is 3/31/2021, since >> then, nothing. >> >> This seems highly unusual since seems like there was always SOMETHING >> updated daily now nothing. > > git transition > > https://wiki.freebsd.org/git <https://wiki.freebsd.org/git> Is portsnap still going to be supported? I was noticing my local ports tree (which autoupdates every night with portsnap) was looking pretty dated, so I started googling and found talk on the forums that portsnap was going away (this was late 2020) and folks were suggesting svnlite and fetching updates via svn. Based on that, I just nuked my ports tree and grabbed it again via git, which seems to have worked. What’s odd is that looking at that wiki entry, this port should have been up to date if I was using portsnap: https://www.freshports.org/multimedia/plexmediaserver-plexpass/ <https://www.freshports.org/multimedia/plexmediaserver-plexpass/> But portsnap kept insisting that I was up to date even though I was seeing version 1.21.3.4015… Anyhow, if anyone can confirm portsnap status, I’d love to know what the official line is and whether I should expect to see it around for awhile. Is the git transition impacting freebsd-update at all? etcupdate? Thanks, Charles > > Regular service should resume soon > > Regards, > > Gary > _______ > 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-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?
ata. IOW, it can be helpful in a potentially large number of situations for some users, especially for data recovery, but that is a different purpose from that for which the other GEOM RAID commands were written to serve. Again, IMO, gstripe(8), gmirror(8), graid3(8), and graid5(8) from sysutils/graid5 should be improved, not eliminated. Anything gvinum(8) is *supposed* to be able to do, but often cannot do without violating other system functions, can be done well by these other GEOM commands. A special note is needed here regarding gcache(8) and graid3(8). The documentation of gcache parameters for sector size for physical devices and gcache logical devices is very unclear, such that a user must have the device nodes and space on them available to create test cases and do so, whereas a properly documented gcache(8) would obviate the need to set up such experiments. There is similar lack of clarity in various size specifications for blocks, sectors, records, etc. in many of the man pages for native GEOM commands. While you are looking into this situation, please also consider that deprecation and elimination of the veritably ancient ccd and ccdconfig are long overdue. Even the man pages state that these device nodes are *not* robust and data can be easily lost. The fact that NetBSD separately maintains some version of ccd and ccdconfig should be considered irrelevant in deciding to deprecate and/or eliminate the supporting code from the source tree. > >I plan to add a deprecation notice after a short discussion period, >assuming no reasonable justification is made to retain it. The notice >would suggest graid and ZFS as alternatives, and would be merged in >advance of FreeBSD 13.1. Then, gvinum would be removed in advance of >FreeBSD 14.0. > >Please follow up if you have experience or input on vinum in FreeBSD, >including past use but especially if you are still using it today and >expect to continue doing so. Given the panics and other problems with gvinum(8), I cannot recommend that anyone use it. After experimenting with it, I ended up using ZFS, gmirror(8), graid5(8), and gconcat(8) to meet my needs. In sum, I recommend maintaining and enhancing to some degree the native GEOM support and letting unfinished and/or unmaintained support for gvinum(8), ccd(8) (and ccd(4)), and ccdconfig(8) be abandoned. Please reverse the deprecation for sysutils/graid5, which actually works as specified, and complete its man page. Please also add a scrub function to it. RAID5, whether by hardware or by software, has known limitations, but for some purposes it is not only adequate, but is a better choice than ZFS. GEOM-based RAID support is also much for versatile and flexible than hardware RAID, so let's keep it available as an option. At the same time, the poorly supported, obsolete, and incompatible-with- other-system-components stuff should rightly be eliminated from the source tree. The few known bugs with the native GEOM commands can and should be fixed. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ****** ___________ 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"
