Re: [net/rtorrent] no manual page (manpage) for rtorrent.
sylvain.sab...@free.fr writes: > Ever since I've used this software, which must get > back to 6.4 or so, the manual page has been missing. The manpage was removed years ago by upstream. Sad but true. The current documentation for rtorrent is only accessible as a wiki: https://github.com/rakshasa/rtorrent/wiki
Re: FVWM terminal emulator transparency issue in -current
On Mon, Feb 15, 2021 at 05:03:55PM -0600, Luke Small wrote: > I'm running fvwm window manager and I just switched to -current. Roxterm is > totally messed up, won't do transparent background and I tried > xfce4-terminal and it says it won't do transparent backgrounds because > compositing is disabled Sure first-world problems, but I REALLY want > fvwm to do transparent terminal emulators! You can just run a compositor. xcompmgr(1) is in the X install. I personally use compton from the package of the same name. picom (also in packages) is supposed to be a successor to compton. They allow more compositor tricks than xompmgr. I've never got application's transparency settings to work well, so my .kshrc (set in ENV in .profile) contains lines calling transset-df from the package of the same name: [ -n "$XTERM_VERSION" ] && transset-df --id "$WINDOWID" 0.85 > /dev/null [ -n "$KITTY_WINDOW_ID" ] && transset-df --id "$WINDOWID" 0.85 > /dev/null
Re: home printer
The Epson Workforce Pro WF-6090 monochrome laser printer works well. It sells for about $300. Wifi can be disabled. It works on USB and network. Here is my printcap: lp|local line printer:\ :lp=/dev/lp:sh:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: rp|remote line printer:\ :lp=:rm=epson:rp=lp:sh:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: where epson is defined in /etc/hosts For me, the latest snapshot (kern.version=OpenBSD 6.9-beta (GENERIC.MP) #337: Mon Feb 15 10:43:38 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP) changes the permissions on /dev/ulpt0 back to crw--- whereas previous snapshots had not. (Maybe irrelevant, but after I did sysupgrade -s, the installer halted at the prompt for me after relinking and I had to reboot, which has never happened to me after sysupgrade -s.) The latest snapshot of course is doing the right thing with the permissions. To then enable users to print, chmod g+rw /dev/ulpt0 (or wherever /dev/lp points) and add users to the group. I didn't get printing to work on the cheaper Epson all-in-one Workforce WF-2630, but YMMV. The Xerox Workcentre 3215 prints over Ethernet, and I was able to scan over USB. For printing over USB, I've always had to physically remove and re-insert the USB cable to avoid printing literal Postscript commands, as opposed to what I really wanted to print. Similarly, new scan jobs with saned failed for me unless I removed and re-inserted the USB cable. I haven't tried scanning again with the Xerox in a few months though. I changed the admin code on the Xerox and later tried to access it. I stored it in a password manager. I know I've re-entered it correctly. In any case, the printer doesn't like what I'm typing and no longer allows access to the web interface. Xerox makes it impossible to reset without calling out a Xerox technician for $300. Of course, the web interface isn't really necessary anyway, so I'm not going to pay them. . . .
Re: Happy Hacking keyboard not working anymore
Hi, From: Norman Golisz Date: Fri, 12 Feb 2021 10:21:05 +0100 > Hi, > > after upgrading to the latest snapshot my keyboard (Happy Hacking > Keyboard) stopped working. I am useing Happy Hacking keyboard model:PD-KB400B and upgraded OpenBSD current by http://ftp.riken.jp/pub/OpenBSD/snapshots/amd64/bsd.rd a few minutes ago. Now, my OpenBSD box works fine and I can use Happy Hacking keyboard. Is your keyboard or USB port broken? > Unfortunately, I can't provide you a dmesg, neither of the previous > (working) snapshot, nor of the current one, due to the lack of a > keyboard. At the very least, I took a picture of my screen displaying > the error messages. > > The last working snapshot has been from 3 to 4 weeks ago. (Sorry, I can't > be more specific than that!) > > Let me know if I can be of help. > > Norman Could you reinstall OpenBSD 6.8 release on your PC? -- ASOU Masato
[net/rtorrent] no manual page (manpage) for rtorrent.
Ever since I've used this software, which must get back to 6.4 or so, the manual page has been missing. I had found a fix for this on the FreeBSD commits back then. In the meantime, here is the webpage I've used as a reference : https://linux.die.net/man/1/rtorrent
Re: 6.8 and Procmail/Formail: anyone still using them?
Hi, You are correct! The contents of my .forward!! pcengine$ cat .forward "|/usr/local/bin/procmail -f -" And yes, all my filtering is defined in my .procmailrc file. Sorry for any confusion! Cheers, Steve W. On 15/02/2021 11:30 a.m., Austin Hook wrote: Hi Steve, I wonder if in your email (below) you have your lines slightly out of order: My .procmailrc: "|/usr/local/bin/procmail -f -" I am thinking that is your .forward file. and Not sure if this is your problem or not.? But I have quite a large .procmailrc file (200 lines) that makes? a historical archive of every incoming email, I gather that you put all your procmail filtering directly into your .procmailrc file. I think it was usually the case that Or is this is a reference to a something.rc file in the ~/Procmail directory? My .procmailrc file looks like this: # Turn off extra words in log file set to yes for debugging VERBOSE=no # For debugging uncomment this line LOGABSTRACT=all # Tell procmail where to store your mail. This changes depending on # which Unix mail client you use. # Pine uses $HOME/mail # Mutt and Elm use $HOME/Mail MAILDIR=$HOME/mail #This directory must exist!!! # Use a seperate directory to store recipes and logs PMDIR=$HOME/Procmail # Tell procmail where to put the log file LOGFILE=$PMDIR/procmail.log # Add recipe files here # To add more recipe files just add an INCLUDERC=$PMDIR/filename.rc # line for each file #INCLUDERC=$PMDIR/testing.rc INCLUDERC=$PMDIR/lists.rc # Finally if the above recipes fail to move your mail put it in your # inbox :0: # Above is a zero (0) not the letter O. $DEFAULT Austin PS: I solved my problem with your help above. Thanks! It has to do with the differences in how the new smtpd process deals with aliases which are pipes to programs or scripts. It does not handle complex command line equivalents with definitions of environment variables preceding the invocation of the program being called up. I wonder if it even handles the typical command lines that have the kind of "if this succeds, then do that also, but if any invoked process fails do the other" -- the usual && or || connectors one often sees in major shell scripts. That kind of usage in the .forward file is what screws up a lot of custom scripts I wrote for myself years ago. I haven't had a chance yet to look to see if procmail still recommends that kind of .forward file. Later I will submit a report to misc@ or ports@ The .forward file used to recommended by procmail to look like this: "|IFS=' ' && exec /usr/local/bin/procmail -f- || exit 75 #austin" That caused an error "cannot expand alias" ( or something like that -- neatly misleading --- as usual in debugging problems... ) :-) Still have to find time to study the newer replacement folks are recommending for procmail. I gather most everyone else has left procmail in the dust On Wed, 27 Jan 2021, Steve Williams wrote: Hi, I am using procmail under 6.8 successfully.? I did have problems with it when upgrading to (I think) 6.4. If you look for the mail list archives for "OpenBSD 6.4 smtpd local mail delivery missing "From " when .forward (procmail)" My .procmailrc: "|/usr/local/bin/procmail -f -" Not sure if this is your problem or not.? But I have quite a large .procmailrc file (200 lines) that makes? a historical archive of every incoming email, filtering maillist emails, etc. Thanks, Steve W. On 26/01/2021 10:43 a.m., Austin Hook wrote: Wonder if anyone is still using Procmail/Formail under 6.8 for presorting incoming mail before it hits one's main inbox. Also wondering if folks send the remainimg mail, after filtering, to /var/mail/*user*, or to ~/mbox or to ~mail/mbox. Any advantage to be had, or any mere consensus, regardless of advantages? I also use whitelisting extensively, and any such "From: emailaddresses" get priority. Does anyone else? Myself: Having problems with Procmail/formail, after upgrading from 5.3 to a new server running 6.8. Would like to hear of anyone else's experience. Thanks, Austin Hook Milk River, Alberta
FVWM terminal emulator transparency issue in -current
I'm running fvwm window manager and I just switched to -current. Roxterm is totally messed up, won't do transparent background and I tried xfce4-terminal and it says it won't do transparent backgrounds because compositing is disabled Sure first-world problems, but I REALLY want fvwm to do transparent terminal emulators! -Luke
Re: sysupgrade failure logs
On 2/15/21 7:21 PM, Judah Kocher wrote: Hello Theo, I never for a moment intended to convey that anyone "owed" me support of any kind for my outside-the-box use of this tool. While I don't understand your vitriolic response to someone else's application of your software for their own personal use in a way you do not condone, you are certainly entitled to be as outraged as you please. I remain grateful for the work you and others put into the OpenBSD operating system. It has been made clear on multiple occasions that use of sysupgrade with anything other than default responses is heretical and cancel-culture worthy but I don't mind breaking things while experimenting and do not blame anyone else when this happens, nor do I particularly care if anyone else is bothered by it as long as no actual harm is being done. If anyone cares to read my original query from an intellectually honest perspective I think they would be hard pressed to respond as you have. I never claimed my "sysupgrade use was completely normal" nor did I blame the sysupgrade tool for the issue I am attempting to diagnose. I did not mention my usage of it because logically it does not seem to be relevant and I was concerned it would become an excuse for people to fly off the handle. I only had and still only have one question. Does sysupgrade leave any kind of logging behind which could help me to pinpoint why it is failing on one system while working on another apparently identical system? If the answer is no, that's easy enough to say. If the answer is yes, that's also easy enough if anyone is willing to share where those logs would be found. If the answer is, "Maybe, but no one owes you that information" that is also perfectly true while kind of pointless to even bother saying, although a world where people only offer help to others when there is a financial obligation would be a dismal place indeed. I did not and do not expect anyone else to solve my problem for me. If you have reason to believe that my "mis-"usage of sysupgrade has anything at all to do with this issue, I'd be curious to know how you would explain it working on 4 out of 6 systems. Since it seems unlikely that the exact same tool would work two different ways on two identical systems then logically I would assume that some subtle difference exists between them and was hopeful that any records of the sysupgrade process would help me identify that difference. I have been using this script on these and other less similar systems ever since the sysupgrade tool was released with no issues, and therefore I think it's reasonable to to conclude that using it this way, while not officially sanctioned, has nothing to do with what's going on in this particular case. Thank you again for your work on OpenBSD, including sysupgrade. To everyone else on the mailing list, I do not apologize for asking a question but I do apologize for the drama it provoked. Judah On 2/14/21 6:44 PM, Theo de Raadt wrote: You are outside the box, by changing tons of stuff. People who operate inside the box won't be able to help you. And it is even less likely when you are dishonest in the original email. You claimed your sysupgrade use was completely normal, but it isn't. It is far from normal. When we get reports like this where people "touch the insides", both Florian and I regret that sysupgrade ever arrived in the system. We want to delete sysupgrade. Or, every month or so change the internals so that it will delete some people's machines. Does sysupgrade recommend what you do? No. But you do it. Do you understand the concept of "you own all the pieces"? The drama was there, but not of Theo, but mine and someone else who kinda derailed this splitting this topic in separate threads "deleting sysupgrade" and "not deleting sysupgrade", however, It might be better to use stable for unattended systems, while just having 'syspatch && pkg_add -u' script in cron for systems that are not intended to be so much interactively used. If sysupgrade(8) does not mention any logging done by it it likely doesnt, and as 'whereis sysupgrade' shows it is at /usr/sbin/sysupgrade, and its a shell script which can be viewed by an unprivilleged user using something like less. And it is not that long to investigate or improve on your own. As for your use of it, you might be better with your own custom way of upgrading, that you can handle and log on your own. Just my 2 cents. Keep it Simple Stupid. P.S. Sorry, but I've never used mailing lists before (since few days ago) and I just sent this reply to bugs instead of here.
Re: not deleting sysupgrade, was: sysupgrade failure logs
On 2/15/21 6:23 PM, Luke A. Call wrote: On 2021-02-15 09:33:03+, Ottavio Caruso wrote: On 14/02/2021 23:44, Theo de Raadt wrote: When we get reports like this where people "touch the insides", both Florian and I regret that sysupgrade ever arrived in the system. We want to delete sysupgrade. If this is not just a provocative statement, +1 from me. I've never liked unattended, automatic, Debian-style system upgrades. A lot of things can go wrong. I think I stay in the box, and definitely appreciate sysupgrade (etc). It has made my openbsd use more secure and easier (given that I am not near your level of expertise here), so, thanks for it being there. Luke Call http://lukecall.net Noobs like me would not be able to run snaps without sysupgrade.. Think of such noobs. But even I understand that running snaps is not for unattended systems, but only ones I interact with mostly. I might just suggest that OP rather make primitive scripts for unattended boxes syspatch pkg_add -u Keep it Simple Stupid, sysupgrade always works for me.
Re: sysupgrade failure logs
> On Sun, 14 Feb 2021 16:44:37 -0700 > "Theo de Raadt" wrote: > >> You are outside the box, by changing tons of stuff. >> >> People who operate inside the box won't be able to help you. >> >> And it is even less likely when you are dishonest in the original >> email. You claimed your sysupgrade use was completely normal, but it >> isn't. >> >> It is far from normal. >> >> When we get reports like this where people "touch the >> insides",both Florian and I regret that sysupgrade ever >> arrived in the system. >> >> We want to delete sysupgrade. Or, every month or so change the >> internals so that it will delete some people's machines. >> >> Does sysupgrade recommend what you do? No. But you do it. Do you >> understand the concept of "you own all the pieces"? >> > > I am confident that I can speak for for ... a non-zero number of > people who use sysupgrade the way it says to on the box and would miss > it if it went away. > > -- > > Edward Ahlsen-Girard > Ft Walton Beach, FL > Edward, Please increase your non-zero people number by one! I like sysupgrade Jay
Re: sysupgrade failure logs
Hello, Does sysupgrade leave any kind of logging behind which could help me to pinpoint why it is failing on one system while working on another apparently identical system? You should get emails: Subject: hostname upgrade response file Subject: hostname upgrade log Subject: hostname rc.sysmerge output Subject: hostname rc.firsttime output If you don't get them, my best guess would be that the system didn't boot the upgrade kernel. In that case check the /etc/boot.conf first. For example $ cat /etc/boot.conf boot prevents the upgrade kernel from being used. (Because of that I have a simple "mv /etc/boot.conf /etc/boot.conf-Temp-sysupgrade", "mv /etc/boot.conf-Temp-sysupgrade /etc/boot.conf" in my Ansible upgrade script.)
Re: sysupgrade failure logs
On Mon, Feb 15, 2021 at 12:21:11PM -0500, Judah Kocher wrote: > Hello Theo, > > I never for a moment intended to convey that anyone "owed" me support of any > kind for my outside-the-box use of this tool. You couldn't be bothered to even send a dmesg or a copy of the script with the first email. OK, say you forgot. I do sometimes. Where was your immediate reply with those missing and always required items? >While I don't understand your > vitriolic response to someone else's application of your software for their > own personal use in a way you do not condone, you are certainly entitled to > be as outraged as you please. Read the tech@ archives. Such a simple script is constantly being criticized, give it new features, etc... This script was a gift. I ran systems for years without it. Don't like the default script? Open it up and modify to meet your special needs. Don't know how to write the code? Learn it. If you don't understand what this script does, you REALLY need to learn more about installs and upgrades. > I remain grateful for the work you and others > put into the OpenBSD operating system. It has been made clear on multiple > occasions that use of sysupgrade with anything other than default responses > is heretical and cancel-culture worthy You appreciate the work, but you already know the default responses? Then you are being rude. > but I don't mind breaking things > while experimenting and do not blame anyone else when this happens, nor do I > particularly care if anyone else is bothered by it as long as no actual harm > is being done. This is part of learning and a good attitude. > > If anyone cares to read my original query from an intellectually honest > perspective I think they would be hard pressed to respond as you have. I > never claimed my "sysupgrade use was completely normal" nor did I blame the > sysupgrade tool for the issue I am attempting to diagnose. I did not mention > my usage of it because logically it does not seem to be relevant and I was > concerned it would become an excuse for people to fly off the handle. I only > had and still only have one question. > > Does sysupgrade leave any kind of logging behind which could help me to > pinpoint why it is failing on one system while working on another apparently > identical system? Read the script before posting the questions about logging. > > If the answer is no, that's easy enough to say. If the answer is yes, that's > also easy enough if anyone is willing to share where those logs would be > found. If the answer is, "Maybe, but no one owes you that information" that > is also perfectly true while kind of pointless to even bother saying, > although a world where people only offer help to others when there is a > financial obligation would be a dismal place indeed. > Much of the world is indeed a dismal place. It's part of human nature. > I did not and do not expect anyone else to solve my problem for me. If you > have reason to believe that my "mis-"usage of sysupgrade has anything at all > to do with this issue, I'd be curious to know how you would explain it > working on 4 out of 6 systems. Since it seems unlikely that the exact same > tool would work two different ways on two identical systems then logically I > would assume that some subtle difference exists between them and was hopeful > that any records of the sysupgrade process would help me identify that > difference. I have been using this script on these and other less similar > systems ever since the sysupgrade tool was released with no issues, and > therefore I think it's reasonable to to conclude that using it this way, > while not officially sanctioned, has nothing to do with what's going on in > this particular case. I really find your method puzzling. I ran into financial troubles and had to drop a server running -current. So I added a second hard drive to boot onto in case a new snapshot broke the system on the server running -current. I also do not understand while you are running -current and automating installation on 6 systems. Does your script verify functionality on the first system before moving on to the others? Are you caching both the snapshot and package files on the first server? Then using those files only to update the other 5 systems. If not, then you are pretty much guaranteeing at some point that you will have 6 different systems running different snapshots and packages. That seems like a bad idea. If all 6 systems go down, how will you fix that mess? Please, please, please, format your messages to be readable! Use some newlines. Please leave the politically correct responses for elsewhere. Read the different lists. Everyone gets told on or off list when they do something stupid. Learn from it. When you know a helpful answer to someone's question, answer it. Port something. Submit a diff, even if it's a bad one. Chris Bennett > > Thank you again for your work on OpenBSD, including sysupgrade. > > To everyone else
Re: sysupgrade failure logs
On Sun, 14 Feb 2021 16:44:37 -0700 "Theo de Raadt" wrote: > You are outside the box, by changing tons of stuff. > > People who operate inside the box won't be able to help you. > > And it is even less likely when you are dishonest in the original > email. You claimed your sysupgrade use was completely normal, but it > isn't. > > It is far from normal. > > When we get reports like this where people "touch the > insides", both Florian and I regret that sysupgrade ever > arrived in the system. > > We want to delete sysupgrade. Or, every month or so change the > internals so that it will delete some people's machines. > > Does sysupgrade recommend what you do? No. But you do it. Do you > understand the concept of "you own all the pieces"? > I am confident that I can speak for for ... a non-zero number of people who use sysupgrade the way it says to on the box and would miss it if it went away. -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: 6.8 and Procmail/Formail: anyone still using them?
Hi Steve, I wonder if in your email (below) you have your lines slightly out of order: > My .procmailrc: > "|/usr/local/bin/procmail -f -" I am thinking that is your .forward file. and > Not sure if this is your problem or not.? But I have quite a large .procmailrc > file (200 lines) that makes? a historical archive of every incoming email, I gather that you put all your procmail filtering directly into your .procmailrc file. I think it was usually the case that Or is this is a reference to a something.rc file in the ~/Procmail directory? My .procmailrc file looks like this: # Turn off extra words in log file set to yes for debugging VERBOSE=no # For debugging uncomment this line LOGABSTRACT=all # Tell procmail where to store your mail. This changes depending on # which Unix mail client you use. # Pine uses $HOME/mail # Mutt and Elm use $HOME/Mail MAILDIR=$HOME/mail #This directory must exist!!! # Use a seperate directory to store recipes and logs PMDIR=$HOME/Procmail # Tell procmail where to put the log file LOGFILE=$PMDIR/procmail.log # Add recipe files here # To add more recipe files just add an INCLUDERC=$PMDIR/filename.rc # line for each file #INCLUDERC=$PMDIR/testing.rc INCLUDERC=$PMDIR/lists.rc # Finally if the above recipes fail to move your mail put it in your # inbox :0: # Above is a zero (0) not the letter O. $DEFAULT Austin PS: I solved my problem with your help above. Thanks! It has to do with the differences in how the new smtpd process deals with aliases which are pipes to programs or scripts. It does not handle complex command line equivalents with definitions of environment variables preceding the invocation of the program being called up. I wonder if it even handles the typical command lines that have the kind of "if this succeds, then do that also, but if any invoked process fails do the other" -- the usual && or || connectors one often sees in major shell scripts. That kind of usage in the .forward file is what screws up a lot of custom scripts I wrote for myself years ago. I haven't had a chance yet to look to see if procmail still recommends that kind of .forward file. Later I will submit a report to misc@ or ports@ The .forward file used to recommended by procmail to look like this: "|IFS=' ' && exec /usr/local/bin/procmail -f- || exit 75 #austin" That caused an error "cannot expand alias" ( or something like that -- neatly misleading --- as usual in debugging problems... ) :-) Still have to find time to study the newer replacement folks are recommending for procmail. I gather most everyone else has left procmail in the dust On Wed, 27 Jan 2021, Steve Williams wrote: > Hi, > > I am using procmail under 6.8 successfully.? I did have problems with it when > upgrading to (I think) 6.4. > > If you look for the mail list archives for "OpenBSD 6.4 smtpd local mail > delivery missing "From " when .forward (procmail)" > > My .procmailrc: > > "|/usr/local/bin/procmail -f -" > > Not sure if this is your problem or not.? But I have quite a large .procmailrc > file (200 lines) that makes? a historical archive of every incoming email, > filtering maillist emails, etc. > > Thanks, > Steve W. > > > On 26/01/2021 10:43 a.m., Austin Hook wrote: > > Wonder if anyone is still using Procmail/Formail under 6.8 for presorting > > incoming mail before it hits one's main inbox. > > > > Also wondering if folks send the remainimg mail, after filtering, to > > /var/mail/*user*, or to ~/mbox or to ~mail/mbox. Any advantage to be had, > > or any mere consensus, regardless of advantages? > > > > I also use whitelisting extensively, and any such "From: emailaddresses" > > get priority. Does anyone else? > > > > Myself: Having problems with Procmail/formail, after upgrading from 5.3 to > > a new server running 6.8. Would like to hear of anyone else's experience. > > > > Thanks, > > > > Austin Hook > > Milk River, Alberta >
Re: sysupgrade failure logs
Judah > I did not and do not expect anyone else to solve my problem for me. Your dishonesty is consistant. We supply it all as software. You can study it and find your problem. Blaming me solves nothing.
Re: sysupgrade failure logs
Hello Theo, I never for a moment intended to convey that anyone "owed" me support of any kind for my outside-the-box use of this tool. While I don't understand your vitriolic response to someone else's application of your software for their own personal use in a way you do not condone, you are certainly entitled to be as outraged as you please. I remain grateful for the work you and others put into the OpenBSD operating system. It has been made clear on multiple occasions that use of sysupgrade with anything other than default responses is heretical and cancel-culture worthy but I don't mind breaking things while experimenting and do not blame anyone else when this happens, nor do I particularly care if anyone else is bothered by it as long as no actual harm is being done. If anyone cares to read my original query from an intellectually honest perspective I think they would be hard pressed to respond as you have. I never claimed my "sysupgrade use was completely normal" nor did I blame the sysupgrade tool for the issue I am attempting to diagnose. I did not mention my usage of it because logically it does not seem to be relevant and I was concerned it would become an excuse for people to fly off the handle. I only had and still only have one question. Does sysupgrade leave any kind of logging behind which could help me to pinpoint why it is failing on one system while working on another apparently identical system? If the answer is no, that's easy enough to say. If the answer is yes, that's also easy enough if anyone is willing to share where those logs would be found. If the answer is, "Maybe, but no one owes you that information" that is also perfectly true while kind of pointless to even bother saying, although a world where people only offer help to others when there is a financial obligation would be a dismal place indeed. I did not and do not expect anyone else to solve my problem for me. If you have reason to believe that my "mis-"usage of sysupgrade has anything at all to do with this issue, I'd be curious to know how you would explain it working on 4 out of 6 systems. Since it seems unlikely that the exact same tool would work two different ways on two identical systems then logically I would assume that some subtle difference exists between them and was hopeful that any records of the sysupgrade process would help me identify that difference. I have been using this script on these and other less similar systems ever since the sysupgrade tool was released with no issues, and therefore I think it's reasonable to to conclude that using it this way, while not officially sanctioned, has nothing to do with what's going on in this particular case. Thank you again for your work on OpenBSD, including sysupgrade. To everyone else on the mailing list, I do not apologize for asking a question but I do apologize for the drama it provoked. Judah On 2/14/21 6:44 PM, Theo de Raadt wrote: You are outside the box, by changing tons of stuff. People who operate inside the box won't be able to help you. And it is even less likely when you are dishonest in the original email. You claimed your sysupgrade use was completely normal, but it isn't. It is far from normal. When we get reports like this where people "touch the insides", both Florian and I regret that sysupgrade ever arrived in the system. We want to delete sysupgrade. Or, every month or so change the internals so that it will delete some people's machines. Does sysupgrade recommend what you do? No. But you do it. Do you understand the concept of "you own all the pieces"?
Re: relayd.conf prefork > 3, relayd does not answer
Hello, mcmer-open...@tor.at (Marcus MERIGHI), 2021.02.07 (Sun) 18:28 (CET): > I just saw a reason to crank relayd.conf(5)s "prefork" from its default > of 3 to 12. > After restarting relayd I could not connect anymore. PEBKAC: The "prefork" directive followed the table definitions, which is the wrong order according to relayd.conf(5). As soon as I moved it up things worked. I suspect that "prefork 3" worked even in the wrong position because it is the default value that does not change anything. Sorry for the noise, Marcus
Re: Deleting sysupgrade, was: sysupgrade failure logs
On 2021-02-15 09:33:03+, Ottavio Caruso wrote: > On 14/02/2021 23:44, Theo de Raadt wrote: > > When we get reports like this where people "touch the insides", both > > Florian and I regret that sysupgrade ever arrived in the system. > > We want to delete sysupgrade. > > If this is not just a provocative statement, +1 from me. > I've never liked unattended, automatic, Debian-style system upgrades. A lot > of things can go wrong. I think I stay in the box, and definitely appreciate sysupgrade (etc). It has made my openbsd use more secure and easier (given that I am not near your level of expertise here), so, thanks for it being there. Luke Call http://lukecall.net
Deleting sysupgrade, was: sysupgrade failure logs
On 14/02/2021 23:44, Theo de Raadt wrote: When we get reports like this where people "touch the insides", both Florian and I regret that sysupgrade ever arrived in the system. We want to delete sysupgrade. If this is not just a provocative statement, +1 from me. I've never liked unattended, automatic, Debian-style system upgrades. A lot of things can go wrong. -- Ottavio Caruso
Re: Intel wifi ipw showing up but not working
On Sun, Feb 14, 2021 at 02:23:08PM +0100, Riccardo Mottola wrote: > Hi Stuart and others,, > > > Stuart Henderson wrote: > > > > > I installed the firmware with fw_update. I try to bring the interface > > > up, I can set the nwid, but it never connects. > > What do you type to bring the interface up? > > If you are using /etc/hostname.ipw0 and "sh /etc/netstart ipw0", what > > are the contents of the file? > > I am typing "ifconfig ipw0 up" as root (or sudo) and then directly starting > the interface with dhclient. > > > > I set the WEP password and it does not get saved if I check back with > > > ifconfig. > > WEP password definitely won't get displayed back if you check as non-root. > > I don't recall if it is displayed for root or not. > > It is not - I was confused with another BSD which does, as root, display > back the used key. > > > What does "ifconfig ipw0" say? > > > > Is there an "RF kill" (wifi on/off) switch on the laptop, if so did you > > try toggling it? > > Actually, that was the solution. The laptop has both a "soft" button with > Fn-F8 and a HW toggle, I forgot about the latter. I am not accustomed to > having "both". (Add to that that it is invisible gray and acts the opposite, > sliding right "kills" and not "activates" but the icon hints to right with > an antenna not a off-antenna) > > I am used that on other laptops, the toggle issues a send connect/disconnect > of the device, here it seems that the device is up but with no antenna. > > > If I try to scan, nothing is shown, I get no errors on the console/dmesg. > > > > I tried enabling debug and I see: > > > > ifconfig debug ipw0 list > > ifconfig: SIOCDIFADDR: Device not configured > > Syntax for that is "ifconfig ipw0 debug", if you get any messages they'll > > appear in dmesg and/or /var/log/messages > > > Thanks for the pinpoint. Now with the correct settings I finally see the LED > on. The interface comes up and finally says "active" when it attaches to the > correct SSID. A scan shows all network, so I believe the radio is fine. > > dhclient however fails to get an address. It waits a few instants and then > prints "no link". > > That is very strange, if with ifconfig I got the interface to active and > thus connected. Am I overseeing again something obvious? > > Riccardi > > Sounds like a wrong key, or the wrong type of crypto. Are you the AP is using WEP? Perhaps you need 'wpakey' instead of 'nwkey'? If you want more help, please show commands you are typing and their output. It is much easier to provide help when we can see what you are seeing, instead of trying to guess what happened based on your verbal description.
Re: update to docs/faq for partition sizes ?
Got it. If i sort out the answer (since i noticed a spare xtra-partition i had made) i will go ahead and followup... thx, h. On Mon, Feb 15, 2021 at 3:28 AM Otto Moerbeek wrote: > On Mon, Feb 15, 2021 at 01:57:23AM -0800, harold felton wrote: > > > howdee, > > > > this is totally not critical, but i will go ahead and ask: > > > > assuming that i have added the following to /etc/mk.conf... > > DEBUG=-g > > KEEPKERNELS=yes > > SUDO=doas > > WARNINGS=-Wall > > > > how big do i need the /usr/obj partition to be ? > > DEBUG=-g makes things way bigger. KEEPKERNELS is also leaving more > cruft afaik. > > You are not compiling with standard options, so how should we know? > > -Otto > > > > i do not remember specifically adjusting the /usr/xxx partitions > > when i was initially installing this system - but i clearly changed > > something... > > because the answer for 'df -h' is as follows: > > Filesystem SizeUsed Avail Capacity Mounted on > > /dev/sd0a 986M121M816M13%/ > > /dev/sd0k 18.8G1.5G 16.3G 8%/home > > /dev/sd0d 3.9G 10.0K3.7G 0%/tmp > > /dev/sd0f 5.8G2.8G2.7G51%/usr > > /dev/sd0g 986M236M701M25%/usr/X11R6 > > /dev/sd0h 15.7G286K 14.9G 0%/usr/local > > /dev/sd0j 5.8G4.9G636M89%/usr/obj > > /dev/sd0i 1.9G1.2G618M67%/usr/src > > /dev/sd0e 11.6G8.8M 11.0G 0%/var > > /dev/sd0l 1.9G344K1.8G 0%/var/log > > /dev/sd0m 9.7G1.3M9.2G 0%/var/www > > /dev/sd0n 27.1G2.0K 25.8G 0%/xtra > > > > i will include the dmesg below, altho i doubt it is critical other than > > to note that the size of my sd0 is 120Gb... > > > > i was also going to ask about a bunch of warnings that i saw scroll by > > "dwarf2 only supports one compilation unit" or something... > > i didnt think that these warning were important since i noticed that > freebsd > > had already dealt with them around 2016-2018 when compiling golang... > > (see: https://github.com/golang/go/issues/14705) > > > > anyways - i was going to try and learn how to use the debugger, etc... > > and thought it would be useful to have all the symbols and code > available... > > i got thru the https://man.openbsd.org/release step-2 and was trying to > > do the 'make build' of base when i ran-out-of-space... > > > > i have a feeling that i would have been fine only compiling non-debug, > > but figured this question might be an faq-type answer that i could ask... > > > > ok - heres my current dmesg (was running -current from a few days back > > until i had just-compiled the -current system i ran out of space on) > > > > fyi - this is a pcengines apu4d4 - if that helps... > > tia, h. > > > > > > > > OpenBSD 6.9-beta (GENERIC.MP) #0: Sat Feb 13 09:41:26 PST 2021 > > hfeltonad...@fw.hfelton.net:/sys/arch/amd64/compile/GENERIC.MP > > real mem = 4259868672 (4062MB) > > avail mem = 4115427328 (3924MB) > > random: good seed from bootblocks > > mpath0 at root > > scsibus0 at mpath0: 256 targets > > mainbus0 at root > > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8a040 (13 entries) > > bios0: vendor coreboot version "v4.12.0.6" date 10/29/2020 > > bios0: PC Engines apu4 > > acpi0 at bios0: ACPI 6.0 > > acpi0: sleep states S0 S1 S4 S5 > > acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET > > acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) > UOH1(S3) > > UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) > > acpitimer0 at acpi0: 3579545 Hz, 32 bits > > acpimcfg0 at acpi0 > > acpimcfg0: addr 0xf800, bus 0-64 > > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > > cpu0 at mainbus0: apid 0 (boot processor) > > cpu0: AMD GX-412TC SOC, 998.29 MHz, 16-30-01 > > cpu0: > > > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > > cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB > > 64b/line 16-way L2 cache > > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully > associative > > cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully > associative > > cpu0: smt 0, core 0, package 0 > > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > > cpu0: apic clock running at 99MHz > > cpu0: mwait min=64, max=64, IBE > > cpu1 at mainbus0: apid 1 (application processor) > > cpu1: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 > > cpu1: > > >
Re: update to docs/faq for partition sizes ?
On Mon, Feb 15, 2021 at 01:57:23AM -0800, harold felton wrote: > howdee, > > this is totally not critical, but i will go ahead and ask: > > assuming that i have added the following to /etc/mk.conf... > DEBUG=-g > KEEPKERNELS=yes > SUDO=doas > WARNINGS=-Wall > > how big do i need the /usr/obj partition to be ? DEBUG=-g makes things way bigger. KEEPKERNELS is also leaving more cruft afaik. You are not compiling with standard options, so how should we know? -Otto > > i do not remember specifically adjusting the /usr/xxx partitions > when i was initially installing this system - but i clearly changed > something... > because the answer for 'df -h' is as follows: > Filesystem SizeUsed Avail Capacity Mounted on > /dev/sd0a 986M121M816M13%/ > /dev/sd0k 18.8G1.5G 16.3G 8%/home > /dev/sd0d 3.9G 10.0K3.7G 0%/tmp > /dev/sd0f 5.8G2.8G2.7G51%/usr > /dev/sd0g 986M236M701M25%/usr/X11R6 > /dev/sd0h 15.7G286K 14.9G 0%/usr/local > /dev/sd0j 5.8G4.9G636M89%/usr/obj > /dev/sd0i 1.9G1.2G618M67%/usr/src > /dev/sd0e 11.6G8.8M 11.0G 0%/var > /dev/sd0l 1.9G344K1.8G 0%/var/log > /dev/sd0m 9.7G1.3M9.2G 0%/var/www > /dev/sd0n 27.1G2.0K 25.8G 0%/xtra > > i will include the dmesg below, altho i doubt it is critical other than > to note that the size of my sd0 is 120Gb... > > i was also going to ask about a bunch of warnings that i saw scroll by > "dwarf2 only supports one compilation unit" or something... > i didnt think that these warning were important since i noticed that freebsd > had already dealt with them around 2016-2018 when compiling golang... > (see: https://github.com/golang/go/issues/14705) > > anyways - i was going to try and learn how to use the debugger, etc... > and thought it would be useful to have all the symbols and code available... > i got thru the https://man.openbsd.org/release step-2 and was trying to > do the 'make build' of base when i ran-out-of-space... > > i have a feeling that i would have been fine only compiling non-debug, > but figured this question might be an faq-type answer that i could ask... > > ok - heres my current dmesg (was running -current from a few days back > until i had just-compiled the -current system i ran out of space on) > > fyi - this is a pcengines apu4d4 - if that helps... > tia, h. > > > > OpenBSD 6.9-beta (GENERIC.MP) #0: Sat Feb 13 09:41:26 PST 2021 > hfeltonad...@fw.hfelton.net:/sys/arch/amd64/compile/GENERIC.MP > real mem = 4259868672 (4062MB) > avail mem = 4115427328 (3924MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8a040 (13 entries) > bios0: vendor coreboot version "v4.12.0.6" date 10/29/2020 > bios0: PC Engines apu4 > acpi0 at bios0: ACPI 6.0 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET > acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) > UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-64 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD GX-412TC SOC, 998.29 MHz, 16-30-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB > 64b/line 16-way L2 cache > cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT > cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB > 64b/line 16-way L2 cache > cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative > cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative > cpu1: smt 0, core 1, package 0 > cpu2 at mainbus0:
update to docs/faq for partition sizes ?
howdee, this is totally not critical, but i will go ahead and ask: assuming that i have added the following to /etc/mk.conf... DEBUG=-g KEEPKERNELS=yes SUDO=doas WARNINGS=-Wall how big do i need the /usr/obj partition to be ? i do not remember specifically adjusting the /usr/xxx partitions when i was initially installing this system - but i clearly changed something... because the answer for 'df -h' is as follows: Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0a 986M121M816M13%/ /dev/sd0k 18.8G1.5G 16.3G 8%/home /dev/sd0d 3.9G 10.0K3.7G 0%/tmp /dev/sd0f 5.8G2.8G2.7G51%/usr /dev/sd0g 986M236M701M25%/usr/X11R6 /dev/sd0h 15.7G286K 14.9G 0%/usr/local /dev/sd0j 5.8G4.9G636M89%/usr/obj /dev/sd0i 1.9G1.2G618M67%/usr/src /dev/sd0e 11.6G8.8M 11.0G 0%/var /dev/sd0l 1.9G344K1.8G 0%/var/log /dev/sd0m 9.7G1.3M9.2G 0%/var/www /dev/sd0n 27.1G2.0K 25.8G 0%/xtra i will include the dmesg below, altho i doubt it is critical other than to note that the size of my sd0 is 120Gb... i was also going to ask about a bunch of warnings that i saw scroll by "dwarf2 only supports one compilation unit" or something... i didnt think that these warning were important since i noticed that freebsd had already dealt with them around 2016-2018 when compiling golang... (see: https://github.com/golang/go/issues/14705) anyways - i was going to try and learn how to use the debugger, etc... and thought it would be useful to have all the symbols and code available... i got thru the https://man.openbsd.org/release step-2 and was trying to do the 'make build' of base when i ran-out-of-space... i have a feeling that i would have been fine only compiling non-debug, but figured this question might be an faq-type answer that i could ask... ok - heres my current dmesg (was running -current from a few days back until i had just-compiled the -current system i ran out of space on) fyi - this is a pcengines apu4d4 - if that helps... tia, h. OpenBSD 6.9-beta (GENERIC.MP) #0: Sat Feb 13 09:41:26 PST 2021 hfeltonad...@fw.hfelton.net:/sys/arch/amd64/compile/GENERIC.MP real mem = 4259868672 (4062MB) avail mem = 4115427328 (3924MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8a040 (13 entries) bios0: vendor coreboot version "v4.12.0.6" date 10/29/2020 bios0: PC Engines apu4 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-64 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.29 MHz, 16-30-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.14 MHz, 16-30-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB
