Re: mount softdep — does it improve the situation for unexpected shutdowns?
I'm going to blame softdep: A long time ago when modifying large numbers of files on a machine with limited memory suddenly: the system became completely unresponsive, the disk light was on solid the poor little disk was rattling continuously. That went on for minutes. The same job on the same machine without softdep ran slowly and with lots of moderate disk rattle but it completed normally. My guess is that softdep ran out of buffers and purged every one of them. All at once. Never enabled softdep after that. Geoff Steckel
Loongson: Version 7.3 package information in 7.4 SHA256 file
Hi, (sorry for the misdirected subscribe mail this morning - I've recognised the error soon after sending, but could not cancel the message) I found a possible issue with the SHA256 file for the Loongson architecture for OpenBSD 7.4 That file contains the names and hashes of (some) 7.3 install packages (along with the correct 7.4 names and hashes). "sysupgrade" will try to download the 7.3 packages from the 7.4 installurl, and will fail. Removing the wrong 7.3 references fixes the file. Patch to create a fixed SHA256 file: --- SHA256.old Sun Nov 5 11:33:19 2023 +++ SHA256.new Sun Nov 5 11:33:42 2023 @@ -8,11 +8,7 @@ SHA256 (game74.tgz) = 358caf89d2a8b7d22aaa59e26ca34ad66c43e37de6e8579c64b25476b5371e59 SHA256 (man74.tgz) = 94782f99765a612ffa6a27fb11433f53088e3ca7fb90aee19be196a35e8cb997 SHA256 (miniroot74.img) = 749d275bc67355c742b1c25ff13508442d38fe7c2e8494bafdeff46d26025e2d -SHA256 (xbase73.tgz) = d5844b1f2c172e10496efc1baa8eeb355940956a907a9275f1f096833e260f09 SHA256 (xbase74.tgz) = dcaf6e3d636663319c765dae90212b9864ece9a5ad4e45656a221caf0a28a943 -SHA256 (xfont73.tgz) = 6bdf10f73be2cb2f5d83288ee882a49fa91a93244a5dfff3b6ffd77ca2650658 SHA256 (xfont74.tgz) = 9bd11d9d1213713b5c394a7259841aef52f6d237875002fd452d4cfd84e15a81 -SHA256 (xserv73.tgz) = 7140a67c48460a148f71e20aea677e5a20e0819eccb39fbbe1884210c253ebe4 SHA256 (xserv74.tgz) = 3cd38cd95760d71febc6c13213279081bdab2ec2facf4709f383dd6594af5c9c -SHA256 (xshare73.tgz) = d9eedf413cfce03eafc09f4a90e4d71f511fafcd90379ac2305ac9ae350d6c43 SHA256 (xshare74.tgz) = 014a306a6c98c6e55f682242a2ede50c3a98d2a0b426df974c3fdfae89913f1e Maybe this can be fixed on the mirror servers. Greetings Carsten Strotmann P.S.: if this was an attempt to check if there is anyone still using OpenBSD on Loongson, it worked. It's me ;)
Re: mount softdep — does it improve the situation for unexpected shutdowns?
Not quite sure how much has been discussed publically, but we don't currently have the manpower to handle lots of complicated parts, and it seems that softdep, in its current state, needs the hand of Kirk McKusick to work. So the current strategy has been to make the moving parts simpler (softdep, scheduler) in order to reduce the amount of bugs, so that hopefully we can make things faster again later once they're rock-solid. (in case you're wondering how softdep might be an issue, for instance there are lots of moving parts in swap, the buffecache, the page zeroer, that tend to run amok unless carefully tended, and until we get a better grasp on this, something akin to softdep is unlikely to come back)
Re: mount softdep — does it improve the situation for unexpected shutdowns?
Thanks! End of discussion ;-) (Except for a potential update of the man page.) Mike > Am 05.11.2023 um 19:39 schrieb Martin Schröder : > > Am So., 5. Nov. 2023 um 19:33 Uhr schrieb Mike Fischer > : >> However the default /etc/fstab does not make use of it. > >> From the 7.4 release notes: > -- > Make the softdep mount(8) option a no-op. Softdep was a > significant impediment to improving the vfs layer. > -- > > Methinks the man page could mention that. > > Best >Martin >
Re: mount softdep — does it improve the situation for unexpected shutdowns?
Am So., 5. Nov. 2023 um 19:33 Uhr schrieb Mike Fischer : > However the default /etc/fstab does not make use of it. >From the 7.4 release notes: -- Make the softdep mount(8) option a no-op. Softdep was a significant impediment to improving the vfs layer. -- Methinks the man page could mention that. Best Martin
mount softdep — does it improve the situation for unexpected shutdowns?
OpenBSD 7.4 amd64 I have just noticed that mount(8) has a softdep option for FFS file systems. And I saw this: https://en.wikipedia.org/wiki/Soft_updates where OpenBSD is mentioned. However the default /etc/fstab does not make use of it. We have been discussing how to deal with unexpected system crashes/loss of power/etc. and found that with a probability of significantly greater than zero such an event will cause inconsistent file systems, sometimes irreparable, with data loss or worse with lurking modified files that may be noticed much later. So I’d like to know if adding the softdep option for the FFS file systems in /etc/fstab would improve the situation? Is anyone using this? Is there a reason it is not used by default? I realise that no solution will be 100%. Backups, snapshots from a powered down machine (in the case of VMs), etc. will still be required. But at least improving the odds of surviving an unexpected reboot without file system sync would help, unless there are drawbacks I am not aware of. I did see https://marc.info/?l=openbsd-misc&m=157537250901987&w=2 are the comments there still valid (for VMs using SSD storage)? Personally I would not mind a bit of memory usage and speed impact in exchange for a more robust system. Thanks! Mike
Subscribe misc@openbsd.org
subscribe misc@openbsd.org
OpenBSD FDE: Protect with keydisk + passphrase
Hi misc, In the past, I used to mount a secondary drive into /mnt/, the keydisk protected by a password. Now I use FDE with a keydisk, but would like to protect the bootable system with a keydisk + passphase (something you have + something you know). Any chance doing this directly using bioctl ? -fm
Re: texlive and tlmgr
On Sun, Nov 05, 2023 at 10:44:36AM +0100, Luciano Ribichini wrote: > Hallo openbsd-mailinglist, > > 1) my name is Luciano, I am a long time linux user. > > 2) Currently I keep an eye on openbsd. > > 3) Thanks a lot for your work, really. > > 4) Having plenty of operating systems to choose from is a good thing. > > 5) Since I use TeX/LaTeX I ask: > > does Texlive work on openbsd, and does tlmgr work too? > > (I read that there are issues). Basically all you have to do is to install your preferred flavor of texlive from ports and it will just work.[1] If by texlive you mean the one supplied by https://tug.org/texlive, you can use the custom binary set build by Nelson Beebe. Instructions on how to do this can be found here: https://tug.org/texlive/custom-bin.html and you will find Nelson Beebe's binary sets for OpenBSD here: https://ftp.math.utah.edu/pub/texlive-utah/bin/ Once this is done, you can use texlive pretty much in the same way as under Linux and update it with tlmgr. This is what I do. Either way, you will have to install biber by yourself. > Thanks a lot again for your work > > Luciano Footnotes: [1] e.g. https://openports.pl/path/print/texlive/texmf,-full
Re: texlive and tlmgr
On Sun, 2023-11-05 at 10:44 +0100, Luciano Ribichini wrote: > Hallo openbsd-mailinglist, > > 1) my name is Luciano, I am a long time linux user. > > 2) Currently I keep an eye on openbsd. > > 3) Thanks a lot for your work, really. > > 4) Having plenty of operating systems to choose from is a good thing. > > 5) Since I use TeX/LaTeX I ask: > > does Texlive work on openbsd, Yes. https://openbsd.app/?search=texlive > and does tlmgr work too? I have no idea, and should advise against using it. All the different Linux and BSDs have their different packages and tlmgr would probably not cater to that. I've used texlive for ages, and experience no problems with the system specific package managers. Cheers! -- `I intend to live forever, or die trying'. --Groucho Marx
texlive and tlmgr
Hallo openbsd-mailinglist, 1) my name is Luciano, I am a long time linux user. 2) Currently I keep an eye on openbsd. 3) Thanks a lot for your work, really. 4) Having plenty of operating systems to choose from is a good thing. 5) Since I use TeX/LaTeX I ask: does Texlive work on openbsd, and does tlmgr work too? (I read that there are issues). Thanks a lot again for your work Luciano
smtpd[68513]: warn: lost processor: spamassassin exited abnormally
Hi folks, since OpenBSD 7.4 the spamassassin filter seems to be broken. On the first EMail opensmtpd dies with a message in maillog saying Nov 5 08:59:23 mhost smtpd[60460]: bcc4f33a095bb28e smtp connected address=xx.xx.xx.xx host=mail.example.com Nov 5 08:59:23 mhost filter-spamassassin[7782]: bcc4f33a095bb28e protocol report 0.7 Nov 5 08:59:23 mhost filter-spamassassin[7782]: exit Nov 5 08:59:23 mhost smtpd[68513]: warn: lost processor: spamassassin exited abnormally Nov 5 08:59:23 mhost smtpd[68513]: Exiting smtpd is configured according to /usr/local/share/doc/pkg-readmes/\ opensmtpd-filter-spamassassin (except for the tls option): xname = "mailhost.example.de" pki $xname cert "/etc/ssl/example.de/fullchain.pem" pki $xname key "/etc/ssl/example.de/privkey.pem" pki $xname dhe auto filter "spamassassin" proc-exec "filter-spamassassin" listen on all tls pki $xname filter "spamassassin" listen on socket filter "spamassassin" : : If I kick out the tls stuff, it is still broken. Can anybody reproduce this? Every helpful hint is highly appreciated. Harri
Re: smtpd[68513]: warn: lost processor: spamassassin exited abnormally
On 2023/11/05 09:59:14 +0100, Harald Dunkel wrote: > Hi folks, > > since OpenBSD 7.4 the spamassassin filter seems to be broken. On > the first EMail opensmtpd dies with a message in maillog saying > > Nov 5 08:59:23 mhost smtpd[60460]: bcc4f33a095bb28e smtp connected > address=xx.xx.xx.xx host=mail.example.com > Nov 5 08:59:23 mhost filter-spamassassin[7782]: bcc4f33a095bb28e protocol > report 0.7 > Nov 5 08:59:23 mhost filter-spamassassin[7782]: exit This seems to suggest that it's due the filter-protocol version bump. (+cc filter-spamassassin maintainers) I don't use filter-spamassassin and can't test, but since it doesn't seem to use link-auth it shouldn't care about this protocol change, so just bumping the version should be enough. Can you try the following diff to see if it helps? Index: Makefile === RCS file: /home/cvs/ports/mail/opensmtpd-filters/spamassassin/Makefile,v retrieving revision 1.8 diff -u -p -r1.8 Makefile --- Makefile26 Sep 2023 12:28:14 - 1.8 +++ Makefile5 Nov 2023 09:20:27 - @@ -4,7 +4,7 @@ V = 0.7 FILTER_NAME = spamassassin DISTNAME = filter-spamassassin-${V} HOMEPAGE = https://www.umaxx.net/ -REVISION = 0 +REVISION = 1 CATEGORIES = mail Index: patches/patch-filter-spamassassin_go === RCS file: patches/patch-filter-spamassassin_go diff -N patches/patch-filter-spamassassin_go --- /dev/null 1 Jan 1970 00:00:00 - +++ patches/patch-filter-spamassassin_go5 Nov 2023 09:20:36 - @@ -0,0 +1,14 @@ +handle the smtpd filter-protocol version 0.7 + +Index: filter-spamassassin.go +--- filter-spamassassin.go.orig filter-spamassassin.go +@@ -211,7 +211,7 @@ func run() { + for in.Scan() { + f := strings.Split(in.Text(), "|") + t, ver, ev, sid := f[0], f[1], f[4], f[5] +- if (t != "filter" && t != "report") || ver != "0.6" { ++ if (t != "filter" && t != "report") || ver != "0.7" { + l3.Err(fmt.Sprintln(sid, "protocol", t, ver)) + return + }