Re: NetBSD 8/9 freeze
On 04.03.2022 10:21, BERTRAND Joël wrote: Dima Veselov a écrit : On Thu, Mar 03, 2022 at 12:17:32PM +, Stephen Borrill wrote: On Wed, 2 Mar 2022, Dima Veselov wrote: I have two similar NetBSD boxes, one is under 9_STABLE and the other is old 8_STABLE. Sometimes one or another or even both get hit by something and OS freezes. It looks like hardware stops working, but OS do not catch panic. It means if ping is constantly running on console it would look like network went down. Any command or logging in would hang forever like it happens when disk do not respond. Providing a dmesg and information about things like firewalling would be a good start. I've seen things like this when attempting to use multiple bge NICs and also with IPFilter. There is no ipfilter nor npf running. One system use software RAID and the other have hardware RAID. Both have dynamic network configuration using net/zebra, as we use it on many other systems. dmesg follows. I see the same deadlock for a while on 8 and 9. LOCKDEBUG does provide usable information. Thanks for a hint. I have recompiled 9-STABLE kernel with DEBUG and LOCKDEBUG. Is it enough to run server with serial console or I can get something useful from GDB when the freeze will happen? -- Dima Veselov Physics R Establishment of Saint-Petersburg University
Re: groff issue after upgrade to NetBSD-9.2
At Fri, 4 Mar 2022 17:26:23 + (UTC), st...@prd.co.uk (Steve Blinkhorn) wrote: Subject: Re: groff issue after upgrade to NetBSD-9.2 > > Unpacking the textproc set overwrites files like > /usr/share/groff_font/devps/DESC and devps/download, and maybe other > files which have been adapted or expanded locally. The unpacking > process follows any symbolic link that devps has been set to rather > than overwriting the symbolic link with a hard directory. Fortunately > I have backups. Would this not be worth a warning in the installation > guide - it's a similar issue to /etc, where precious lolcalisations > risk being lost? Yeah, I would say most of those are not normally files that any end user would be expected to localise. I think the best you can hope for is, perhaps, in a future upgrade if/when syspkgs are used, that there may someday be some conflict detection for locally modified system files. That said, you could also add any system files you've customised to /etc/mtree/special.local and they'll be backed up, with complete daily automatic version control, into /var/backups by /etc/security. See "check_changelist" in security.conf(5). > I know thered is a move not to includee groff etc. in the main > distribution, but some of us use it extensively: I have substantial > software systems which emit *roff source files, it's not just a > manpage generator. Perhaps you would be a lot happier with a more modern troff? I would suggest trying out pkgsrc/textproc/heirloom-doctools Despite the name, these are quite modernised versions of the original true AT Troff and related tools from what was effectively the Documenter's Workbench. These tools even have a special "groff" compatability mode if indeed you depend on any Groff extensions. See https://n-t-roff.github.io/heirloom/doctools.html (There is also a port of old DWB-3 (3.3b) in pkgsrc/textproc/DWB, but it has not been modernised nearly so much.) One potentially huge advantage of using doctools over the base-system groff would be that you can much more easily customise (and test!) the tools and their configuration by applying local patches via pkgsrc. That said I've long argued for these heirloom-doctools to be used to replace the base system Groff, and I would still strongly suggest that be done. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpgQ8QLh5CkY.pgp Description: OpenPGP Digital Signature
Re: groff issue after upgrade to NetBSD-9.2
Answer: Unpacking the textproc set overwrites files like /usr/share/groff_font/devps/DESC and devps/download, and maybe other files which have been adapted or expanded locally. The unpacking process follows any symbolic link that devps has been set to rather than overwriting the symbolic link with a hard directory. Fortunately I have backups. Would this not be worth a warning in the installation guide - it's a similar issue to /etc, where precious lolcalisations risk being lost? I know thered is a move not to includee groff etc. in the main distribution, but some of us use it extensively: I have substantial software systems which emit *roff source files, it's not just a manpage generator. -- Steve Blinkhorn You wrote: > > This is on amd64, but I doubt that that's relevant. > > I have an extensive collection of fonts for PostScript, so > /usr/share/groff_font/devps is a symbolic link to a /fonts directory. It > has been so since NetBSD-1.x and before that on BSD/OS and before that > into the mists of time. > > I upgraded to NetBSD-9.2 several days ago, and suddenly my standard > document formats come out all wrong. The glyphs for the > variously-acquired (e.g. bought from Linotype) fonts do not seem to be > available, and the font metrics are wrong for the glyphs that do > appear. > > I have a practical solution for the moment: if I mount_nfs a backup > copy of the same fonts directory on a remote server and point > groff_font/devps at that instead, everything goes back to normal. > > Anyone have any insight into why migrating from 7.0 to 9.2 might cause > such a problem? > > -- > Steve Blinkhorn > > -- Steve Blinkhorn This email is for the addressee only. If you are not the addressee you should immediately delete this email from your system(s) and inform us. It may contain information that is confidential or otherwise privileged, and should not be copied or redistributed to recipients not originally specified as addressees without permission. S F Blinkhorn MA PhD CPsychol FBPsS, Managing Director, Psychometric Research & Development Ltd. PO Box 1143, St Albans, Herts, AL1 9UT, UK Registered in England No. 1909571 Registered Office: Verulam Point, Station Way, St Albans, Herts, AL1 5HE Phone: +44 (0)1727 841455 http://www.prd.co.uk
