Re: file systems
On 05/26/17 10:35, Friedrich Locke wrote: > Hi folks, > > does anybody here run OBSD with a file system bigger than 10TB ? > How much time boot takes to bring the system up (i mean fsck) ? > Are you using ffs2 ? With softdep ? > > Thanks. Error #1: assuming someone else's experience will have anything at all to do with yours. When doing things like this, you need to just test it yourself with your data and see what happens. And as I always preach, "testing" doesn't stop at "I built it and it works!" Experiment with failure modes, look at how you move data to a new machine when you need to, etc. Your performance will depend greatly on your hw and your data. Error #2: When you create a single file system that big, you are usually Doing it Wrong (or at least, sub-optimally). You really should be "chunking" your data into more manageable chunks if at all possible. Some of the benefits to "chunking" your data: * If you can RO "full" file systems, your fsck time drops to zero for those. * You buy storage when you need it instead of in advance. Since storage almost always gets bigger and cheaper, delaying storage purchase makes a lot of sense. * Even with modern hw, a gigabyte of data takes a while to move. A terabyte takes a long time to move. * Someday, you will need to upgrade/replace the hardware. Chunking your data gives lots of options here, which might be the difference in doing a hw replacement/upgrade in a routine hw maintenance window vs. spending a very long weekend down. * When something bad happens, you may spend a lot less time recreating your data. Nick.
Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?
On 05/28/17 22:13, Tinker wrote: > Hi misc@, > > For pluggable devices such as USB NIC:s, is there any way to make > OpenBSD bind a particular device based on its MAC or USB serial number > or the like variable, to a particular interface or device filename? no but ... ... > (For storage devices there's the DUID-based mounting already though, so > I guess those are a non-issue.) right. so we'll ignore those...but that's a hint: there's more than one way to do things. > Some things in the OS are specified per interface/device name, e.g. PF > rules (e.g. "pass in proto tcp from any to cdce0 port 123 rdr-to cdce1 > ..", "match out on cdce0 from 192.168.0.0/16 to any nat-to cdce0"), so > having the interface numbers garbled on replug may be an unnecessary > reason to > reboot?http://www.providr.com/now/spartans-facts/26/?utm_source=fbkxd&utm_medium=spartan_d_f My thought would be to have an include file in your pf.conf that defines a macro to the desired interface to what it happens to be connected as this moment. So maybe a hotplugd(8) script that looks at the MAC address (or ... something else?) of whatever device was just plugged in and create an entry in /etc/pf/interfaces.inc something like ext=run0 or int=run1 as appropriate. Have an 'include "/etc/pf/interfaces.inc" ' in your pf.conf, and reload pf.conf when a hotplug event takes place. Nick.
Re: Can I bind USB/other interface/device number (e.g. cdceX) to particular MAC, USB serial number or the like?
On 06/01/17 20:50, Tinker wrote: > On 2017-06-02 00:45, Joe Gidi wrote: >> Good news! You can have this already. > > Yay! > >> Go run Linux. > > Em - > > Nay! > > No yay. Hope to see a solid solution to this problem on a non-crappy OS > soon. > Linux's (and Windows and Solaris and ...) attempts to "fix" this problem is one of the reasons I'd consider Linux (and Windows and ...) crappy. A complicated solution that creates far more problems than it ever solves, and usually at the worst times possible (i.e., disaster recovery, where you are trying to rebuild a failed system). The tools to deal with this are already in OpenBSD as I and Peter indicated. We don't need an "automatic" solution that penalizes everyone for an edge-case problem (and yes, I'd consider this an edge case. I can't imagine a serious, industrial firewall with USB interfaces). Nick.
Re: Can I use OpenBSD as a desktop system?
On 06/09/17 15:39, SOUL_OF_ROOT 55 wrote: > Can I use OpenBSD as a desktop system? You? No, I doubt it. Me, it's pretty much all I use as a home desktop system. But you didn't seem to want to give it a try to find out for yourself, or define what you mean by a "desktop system", or do some basic research, like maybe googling for "openbsd desktop". So it might be quite an uphill battle for you. You must be so ---> <--- smart to ride this ride. But, you are welcome, and invited, to give it a try. Prove me wrong! :) Nick.
Re: Feeding DHCP leases into unbound
On 06/22/17 05:47, Andreas Kusalananda Kähäri wrote: > Hi, > > I have unbound(8) and dhcpd(8) running on a router (OpenBSD 6.1-stable). > dhcpd currently hands out fixed addresses to my clients, but I'd like > these to be allocated dynamically from the common pool, while at the > same time being resolvable. > > Is there an existing solution for feeding the IP-addresses of the leases > that dhcpd hands out into the unbound configuration and reload it, or > would I have to write a script that parses the lease declarations in > /var/db/dhcpd.leases? > > I know about dnsmasq in ports which I believe serves as both DHCP and > DNS server, but I'd rather use the software in the base system if at all > possible. http://www.thismetalsky.org/projects/dhcp_dns This is abandonware, but it works really slick -- ran it on a Sparc20 I used as DHCP/DNS server for probably close to ten years. Problem is, it was for DJBDNS, not nsd(8)/BIND zone files. But, I had little trouble adapting it to create nsd(8)-compatible zone files. I'm not going to show my code because there are a few things that are too much "hey, it worked!" and not really done as they should be, but it parses the dhcpd.leases file very well and outputs good data...just a matter of dropping it in the desired formats and telling nsd to reload its data. Nick.
Re: Advice on partiotion scheme
On 07/01/17 06:15, pipfsta...@openmailbox.org wrote: > Hello, dear misc > > I want to use openbsd for daily tasks on my laptop, I'm planning to > build ports by hand and I want to try some development of the system > itself. > > At the moment I'm just playing around and I faced a little problem: > space allocated by default partitioning to /usr ran out in a blink of an > eye. Current df: And the reason is, you are doing something the default partition plan wasn't planning on you doing -- having a /usr/ports directory full of stuff. > $ df -h > Filesystem SizeUsed Avail Capacity Mounted on > /dev/sd0a 1005M 61.1M893M 6%/ > /dev/sd0k 98.8G3.2G 90.6G 3%/home > /dev/sd0d 3.9G724M3.0G19%/tmp > /dev/sd0f 2.0G2.0G -91.1M 105%/usr > /dev/sd0g 1005M177M778M19%/usr/X11R6 > /dev/sd0h 9.8G1.0G8.3G11%/usr/local > /dev/sd0j 2.0G850K1.9G 0%/usr/obj > /dev/sd0i 2.0G861M1.0G45%/usr/src > /dev/sd0e 18.3G 12.0M 17.3G 0%/var > > I want to reinstall OpenBSD from a snapshot and pick a custom partition > scheme. Based on the needs described above, what partitions should I > keep and what sizes should I peek? I know about the workaround with the > /usr partition by setting a few variables (WRKOBJDIR, ...) in > /etc/mk.conf, but I'm not sure if it's the best solution. May be just > give more space for /usr/? Also, is so much space for /var really > needed? It empty at the moment, will daily desktop usage/little OpenBSD > development fill it up? > > Also, I'm confused with such a small amount of space for /. Is 1G > enough? First of all, all Ingo's suggestions are right on. But I'm going to do something I rarely do: give a short answer. :) You don't even have to reload. Save your existing /home partition, and shrink it to maybe 20g, then restore it. Now you have lots of space to create a new /usr/ports, or whatever else you may need in the future. As for root being "only" 1G, actually, I'd call that kinda big. I've run systems for many years with 200MB root. There just shouldn't be much going there, and if there is, it usually indicates something has gone wrong, so an early warning is nice. (/dev is in /, so a common error is to end up trying to write to a device, but mistyping it and making a file there instead). /var ... "depends". If all you have is routine logs going there, than 1G is "big". If you have an app that has a database or a web app, suddenly your 18g may look small. What are you developing? Web apps? /var (holding /var/www) will suddenly be small. Guess I lied about the short answer... :-/ Nick.
Re: Restoring /altroot
On 07/14/17 09:00, Raimo Niskanen wrote: > Hi misc@. > > I wonder how to restore from an /altroot backup? > > (I missed that pax -r happily writes absolute paths and wrote over > /etc from a backup file of another machine) > > > Is it to dd(1) back all but the first 16 blocks - the reverse of what > daily(8) does? Is that all that is needed? don't... > (I missed to skip the first 16 blocks, and I used the block devices instead > of the character devices. The result was a vegetable, and would like to > understand which of my mistakes that were fatal.) yeah, that's why. It CAN work, but ... it is the hard way and it's error prone. better way: let's say sd1k is your /altroot... # mount /dev/sd1k /altroot now...it's just a normal file system on a normal place. Copy out whatever you want. umount it when done, please. Nick.
Re: Restoring /altroot
On 07/17/17 05:50, Raimo Niskanen wrote: > On Fri, Jul 14, 2017 at 10:46:14PM -0400, Nick Holland wrote: >> On 07/14/17 09:00, Raimo Niskanen wrote: >> > Hi misc@. >> > >> > I wonder how to restore from an /altroot backup? >> > >> > (I missed that pax -r happily writes absolute paths and wrote over >> > /etc from a backup file of another machine) >> > >> > >> > Is it to dd(1) back all but the first 16 blocks - the reverse of what >> > daily(8) does? Is that all that is needed? >> >> don't... >> >> > (I missed to skip the first 16 blocks, and I used the block devices instead >> > of the character devices. The result was a vegetable, and would like to >> > understand which of my mistakes that were fatal.) probably worth answering why this failed... 1) The first 16 blocks are where the disklabel is hiding on the first partition (usually, 'a'). Blindly copy over a disklabel from the wrong disk, you will blow away your current disklabel. BEST case (both disks have the exact same layout), you just changed the DDUID of your target disk. 2) writing to sd0a/wd0a instead of rsd0a/rwd0a just drops the data in the wrong place. This error probably saved your disklabel, so it's a good error to combine with the first. Didn't help anything, but kept the damage from being worse. >> yeah, that's why. It CAN work, but ... it is the hard way and it's >> error prone. >> >> better way: let's say sd1k is your /altroot... >> >> # mount /dev/sd1k /altroot >> >> now...it's just a normal file system on a normal place. Copy out >> whatever you want. umount it when done, please. >> >> Nick. > > Yes, thank you! That is the safe way. In this case I wanted to get rid > of all files that my pax fumbling had put there, so I wanted to clear the > root filesystem and copy back all from /altroot. But then I also would > have ro run installboot on the restored root filesystem, right? > > Is that the right(tm) way to do it? If you copy files from any backup back to root, yes, you will need to re-run installboot. This has to be done any time /boot could have moved to a new physical spot on the disk. If you really want to blow things completely away, give consideration to doing an "upgrade" (to either what you were running or most recent release, or even -current), then restoring your /etc/ directory, and re-running sysmerge afterwards (if you change versions). Nick.
Re: Minium System Requirements
On 07/22/17 13:45, Max Power wrote: > Hi guys, > I'm looking for on http://www.openbsd.org but... > Where Can I find the official documentation about the 'minimum system > requirements' about OpenBSD? > > Thanks. "less than your application needs". Really. You will have trouble finding an example machine of any platform that runs OpenBSD that won't work. Stupidly low-end limitations: * 80386 and before won't work (this was killed probably 15 years ago. No one noticed) * 486SX won't work (needs hw FPU) (This was plus or minus a release from the 80386 termination. Few people noticed). * 16M will probably not work anymore. Last I tried, it was in swap before the login prompt. * 32M will probably let you log in before swapping. But there will be swapping. * 64M is useful for SSH tunnels and simple firewall use. Now, if you are a new user to OpenBSD, if you are wanting to make a firewall for your home, I'd say a Pentium II or P3, 256M RAM, 40G disk, and a couple decent PCI NICs would be a good starting point. COULD you do it with a Pentium 1 system? yeah, but it will try your patience, and that's generally a bad idea for new users. You really want to say, "What happens if I do *THIS* wrong", totally hose the system, and rebuild it a few times to get comfortable with an OS, and that's hard to do if a reload takes half an hour or an hour or more. If you are looking to run a GUI and a browser, um...well, I'd say at least a dual core system with 2G RAM to start with...and I recently gave up on a three core 4G system, because Firefox, Chrome, and Thunderbird would drive it into swap after a few days up-time. But this is purely an application issue; I've got a PII system with 256M RAM that's quite useful with a gui as a terminal server. Bottom end "useful" systems I've found current use for: first generation Soekris systems with 64M RAM, 486-133mhz, 2G CF storage. They make nice OpenBSD protectors for things like Dell DRAC cards on systems in data centers. SSH to the box with ssh tunnels set up, now have full DRAC access to the machines, without exposing the very soft DRAC directly to the network. HOWEVER, be aware, OpenBSD is loaded with modern (i.e., CPU intensive) cryptography. It will WORK with very old processors, but you won't enjoy it. Nick.
Re: Need help securing SMTP (thunderbird says it's not encrypted)
On 07/27/17 08:56, Paul Covello wrote: ... > I can send and receive mail ok using Apple Mail on my mac. > Thunderbird is another story… I am warned when I set up the > account that SMTP is NOT encrypted. Thunderbird is a mail CLIENT. It knows nothing about what encryption your mail TRANSPORT is doing out on the 'net, but that's what you are showing us the config of. It's probably referring to your IMAP connection to your dovecot server. That's all it really knows about. Make sure you are talking SSL/TLS to dovecot, make sure dovecot is configured for that, and that you have PF letting the right port though. It MIGHT Be talking about outgoing mail...but a quick look at Thunderbird here shows that it defaults to port 465 for encrypted, and you are talking about 587. Nick.
Re: OpenBSD Traning Docs / How Tos
On 08/08/17 03:54, Mihai Popescu wrote: > Hello Tom, > > I am not an expert user of OpenBSD but I want to tell you the FAQ is > the first step. That is maintained by Nick Holland, ... I really hate to correct someone who says such nice things about my work, but ... I stepped aside a while back to wiggle priorities around in my life a bit. I am happy to report that Theo Buehler and T. J. Townsend have stepped up and done a great job of maintaining and improving the FAQ (and much of the rest of the website, and making contributions to the rest of the project as well). (I am, of course, still active in the OpenBSD community, but racking up more miles on my motorcycles, too...) Nick.
Re: how to know the state of the dd's progression
On 08/09/17 17:09, Gregor Best wrote: > Send a SIGINFO to dd. which ever so nicely is IN THE MAN PAGE. Nick.
Re: Hot Spare in Softraid?
On 08/12/17 15:02, Federico Giannici wrote: > On 08/12/17 20:48, noah pugsley wrote: >> On Sat, Aug 12, 2017 at 10:55 AM, Federico Giannici >> wrote: >>> Is it possible to set a "Hot Spare" chunk for a RAID1 Softraid? >>> From the "bioctl" man page seems that this functionality is available for >>> "RAID controllers" only. >>> Is it correct? >>> >>> Thanks. you can just leave a drive on-line and waiting to be added to an array. When you have a failure, you COULD have it happen on its own with appropriate monitoring and scripting, or you could wait until an optimal time to rebuild. Rebuilding is a performance impacting task, you might want some say about when it happens. >> I don't know about that, but from softraid(4) I know that: >> >> "RAID 1 >> A mirroring discipline. It copies data across more than one chunk to >> provide for data loss. Read performance is increased, though at the >> cost of write speed. Unlike traditional RAID 1, softraid supports the >> use of more than two chunks in a RAID 1 setup." >> >> So, why not a 3 disk mirror? > > Good point, but now I have two more questions: > > 1) What about the "cost of write speed"? Will writing times increase > further with another disk? Is it negligible? depends on your needs (and hw). Test, don't speculate. Yes, writes will be slower. Reads MAY be faster. But the performance loss may be trivial compared to the difficulty when you have a multiple disk failure. I've often wished hw raid controllers accepted three disk RAID1 configs. > 2) What happens when one of the three disk goes bad? Is it signaled in > any way? The softraid goes "degraded" or remains "Online" (I suppose the > latter)? Don't ask these questions of others, their answers may or may not apply to you, and YOU need to find them out yourself the easy way...before you find out the hard way. Practice RAID response and recovery. Nick.
Re: current/i386 does not boot
On 09/12/17 14:16, Jan Stary wrote: > On Sep 12 19:29:16, h...@stare.cz wrote: >> This is current/i386 from https://ftp.eu.openbsd.org/pub/OpenBSD >> The upgrade went just fine as always, but the installed /bsd >> just goes to a black screen at some point during the boot sequence; >> the machine does not answer to a ping. > > Ech, it's an amd64 machine. Sorry for the noise. > >> Here is a previous dmesg on the same machine: >> http://stare.cz/dmesg/intel-i7.20170827 > > And here is the amd64 dmesg. > http://stare.cz/dmesg/intel-i7.20170911 > > > To get a lesson out of this screwup: why exactly is it > that an i386 bsd.rd boots at this but an i386 bsd does not? well... short answer is the kernels are different. bsd.rd is smaller than the full kernel, AND has "built in" utilities...so there's a lot missing from bsd.rd. "Blank screen" sounds to me like drm issue. At the "boot>" prompt, you could try a "boot -c" then "disable inteldrm" at the ukc prompt. If it comes up, sounds like an unhappy regression from something that worked a couple weeks ago. (I see your working dmesg has inteldrm handling the display). However, before I say bug, I'm confused...you keep talking about i386 not booting, but it's amd64 that you have shown as having worked. So I'm a little confused here. What's the actual problem? old amd64 worked, new amd64 doesn't? old amd64 worked, new i386 doesn't? Is there any possibilities you got i386 and amd64 binaries mixed, maybe kernel i386 and amd64 X or other way around, such as by changing platforms by "upgrade"? (WRONG! re-install). Nick.
Re: current/i386 does not boot
On 09/13/17 02:21, Jan Stary wrote: > On Sep 12 21:48:04, n...@holland-consulting.net wrote: >> On 09/12/17 14:16, Jan Stary wrote: >> > On Sep 12 19:29:16, h...@stare.cz wrote: >> >> This is current/i386 from https://ftp.eu.openbsd.org/pub/OpenBSD >> >> The upgrade went just fine as always, but the installed /bsd >> >> just goes to a black screen at some point during the boot sequence; >> >> the machine does not answer to a ping. >> > >> > Ech, it's an amd64 machine. Sorry for the noise. >> > >> >> Here is a previous dmesg on the same machine: >> >> http://stare.cz/dmesg/intel-i7.20170827 >> > >> > And here is the amd64 dmesg. >> > http://stare.cz/dmesg/intel-i7.20170911 >> > >> > >> > To get a lesson out of this screwup: why exactly is it >> > that an i386 bsd.rd boots at this but an i386 bsd does not? >> >> well... short answer is the kernels are different. >> bsd.rd is smaller than the full kernel, AND has "built in" >> utilities...so there's a lot missing from bsd.rd. >> >> "Blank screen" sounds to me like drm issue. At the "boot>" prompt, you >> could try a "boot -c" then "disable inteldrm" at the ukc prompt. If it >> comes up, sounds like an unhappy regression from something that worked a >> couple weeks ago. (I see your working dmesg has inteldrm handling the >> display). >> >> However, before I say bug, I'm confused...you keep talking about i386 >> not booting, but it's amd64 that you have shown as having worked. So >> I'm a little confused here. What's the actual problem? >> >> old amd64 worked, new amd64 doesn't? >> old amd64 worked, new i386 doesn't? >> >> Is there any possibilities you got i386 and amd64 binaries mixed, maybe >> kernel i386 and amd64 X or other way around, such as by changing >> platforms by "upgrade"? (WRONG! re-install). > > It's an amd64 machine where current/amd64 has always worked. > The dmesg are at http://stare.cz/dmesg/intel-i7.* > > Yesterday, I "upgraded" the machine to current/i386. > That's where I observed that bsd.rd boots but bsd does not. > It was an i386 bsd.rd that booted and an i386 bsd that did not. > > After ealizing this, I upgraded again, this time to current/amd64 > - which works fine, like it always has. > > I believe you are right about the inteldrm. Usually, the boot sequence > switches to a smaller font once it gets to graphics. After the i386 upgrade, > it stayed 80x25 before it went black. That's hardly a bug report of course. Ok...if you "upgraded" i386 over amd64...all bets off. Too much can go wrong there. And in this case, the reason bsd.rd worked and the regular kernel doesn't /could/ be because the bsd.rd kernel is completely self-contained -- all tools are in the kernel. The regular kernel uses stuff on the disk, if it pulled in an amd64 program on an i386 kernel...well, unhappy things are expected. Now, if you did a fresh install of i386, then there might be an issue. Or it could be that it's never worked and no one ever tested before. Nick.
Re: i386 or amd64 from small Cloud instance ?
On 09/13/17 09:42, Joel Carnat wrote: > Hi, > > My Cloud instances are always small (1 ou 2 vCPU, far less than 4GB of > RAM). > > From what I saw, all the ports I need are available in i386 and amd64. > Every Cloud provider I checked are using KVM hypervisor. > > Regarding OS and ports performance, does it make sense to use i386 > rather than amd64 ? > Or is amd64 somehow better even on small configurations ? hm. I must have been napping. when did 4G RAM become small? Guess I should quit hoarding the 4G disks, eh? :) (says the guy who just noticed a 2G RAM machine currently has almost 1.3G swap in use) In a shared resource environment, the performance of i386 vs amd64 is not going to be noticeable compared to the impact other people sharing your physical CPUs, disks, and network resources. And if the performance was your concern, you wouldn't be talking about just one cpu systems. At this point, I think it is fair to say i386 has entered "legacy" state. I think it would be fair to say that the most active development is taking place on the amd64 platform and being pushed out to others. I think that's a better reason than performance. Nick.
Re: Serving multiple domains on one machine or IP address
On 09/19/17 01:17, Greg Garrison wrote:
> Hi,
>
> I am interested if I can serve multiple domains from one machine using
> HTTPD and possibly VMM and RELAYD. I would prefer if there was a
> solution just with HTTPD is order to KISS. If it is really painful I'll
> just role more servers.
>
> I am running OpenBSD on a VPS. I have 3 to 5 web sites (separate
> domains) that I want to serve. They are all very small traffic at this
> time. I would rather run them on one VPS than each on its own because it
> would be cheaper, until traffic increases. My VPS provider can provide
> three external IP addresses in the form of one + two aliases for a
> single (virtual) machine. Is it possible to configure HTTPD to reply to
> queries for site1 on IP1 and site2 on IP2 and site3 on IP3, for example.
yep. You can run them all on one IP address. I run eight on mine.
Name based hosting.
"man httpd.conf", look for "server name {...}"
Heck, look at the examples there. Did you look at the man page?
You can use multiple IP addresses, too. man page again provides all the
details.
Not quite so explicit in the man page -- you can even run multiple https
websites on one IP address. It Just Works. Most of my eight have a
Let's Encrypt cert.
> Additionally I notice that the default client HTTP error messages (e.g.
> 404 error) that HTTPD generates reveal that the server is running
> OpenBSD. This is not a big deal but if the error messages were
> configurable so that they could mask the server OS or could display an
> otherwise custom message I would see value in that. Does this capability
> exist with without recompiling HTTPD?
Not seeing that in the man page.
I see no benefit in hiding the OS name. Kinda like showing up at a
knife fight, and when asked what kind of knife you have, you answer,
"M1A1 Abrams". There's no harm in that. Custom 404 page? sometimes fun.
Nick.
Re: Increase swap size on a running instance
On 09/26/17 14:13, Greg Garrison wrote: > Hello, > > > Looking for help. I am trying to run an application that requires 2 GB > of swap. My VPS instance has 256 by default. For some reason the > application will not accept a swap file. It is possible to resize > partitions live to get a bigger swap space? First of all, let's be accurate: your app requires 2G more memory than you have. You are choosing to use swap. You will probably regret this. But hey, I'm having a cynical day. I didn't follow a boss's direct instructions today, probably saving his job. I feel cheated. So lemme help you aim that gun at your feet as you are requesting. This is either a question about your hosting provider or about OpenBSD. Can you build an OpenBSD system on your hosting provider as you want it? That's between you and them. Mine gives me a crap install, I just download a -current bsd.rd, bring up a console, reboot off that. Now that I've got bsd.rd running, I build the disk layout as I want it, in your case, with lots and lots of swap you will regret using, but also partition it up, like any good OpenBSD install. Now, if you are asking about resizing swap as an OpenBSD function...depends on how you laid out your disks. If you used all your space, nope, you are stuck. If you have unpartitioned space, then yes, you can create a new partition of type "SWAP", and use "swapon" to add it to your existing swap space while the system is running, and put it in /etc/fstab so it's used next time at boot. IF you want to change your swap partition itself, first, you need space. Then you want to remove it from swap (hope you aren't using it), then change your partitions, and add it back in as swap. man swapctl is your friend. (Don't get me wrong, I almost always set up machines with swap as a safety margin. I recently had a system start burning RAM and then swap at an obviously "this isn't gonna work!" rate, so I fairly quickly found a chunk of unused disk, made it a swap partition, and added 30G swap to the system. I then decided to stop my task and try again after maxing the machine out with the most RAM I could with junk on hand -- 4G, which was double what it had, and moving the swap to a different physical disk, so it would spend time only thrashing the disk for memory, not memory+task. The task took days to complete, but it did (using about 3G swap at its peak, iirc). My foot targeting issue is the phrase, "application that requires 2G swap". That's just wrong.) Nick.
Re: Crypto softraid is supported on GPT/UEFI boot and not just on BIOS/MBR boot, right?
On 09/28/17 05:58, ti...@openmailbox.org wrote: >> On Wed, Sep 27, 2017 at 05:02:06PM -, ti...@openmailbox.org >> wrote: > .. >>> What am I doing wrong, are there actually any installboot >>> arguments that could help me make it work? >> >> It looks like you're using GPT on both the physical and the >> softraid disk, correct? >> >> In my setup, I have GPT on the physical disk (sd0) but an MBR on >> the softraid volume. So perhaps try using an MBR on sd1 and see if >> that helps? I am poking in the dark here. No idea if that will work >> for you. > > An MBR has a max of 2TB so over time the whole MBR thing needs to be > discontinued, right, however this is a smaller disk so having MBR > inside the softraid would work indeed. By that logic, we should have quit using cheap disks when they went over 32MB. Or 120MB. Or 504MB. Or 128GB. Or ... I have MBRs on 4TB SoftRaid volumes, works fine. fdisk, make the "entire" disk (welllthe first 2TB) OpenBSD. disklabel, change the boundaries of the OpenBSD part to be the entire disk. Done. Nick.
Re: Resize partitions?
On 10/03/17 10:10, Niels Kobschaetzki wrote: > On 17/10/03 13:48, Niels Kobschaetzki wrote: >> Hi, >> >> I am running currently constantly into the problem that I do not >> have enough space left for installing packages and today even >> upgrading a snapshot failed because I had not enough space left. Is >> there a way to resize partitions? I guess probably not because >> there is no volume manager, right? I used originally the suggested >> layout by the installer. Any idea what could fill up the space on >> /? The partition is only 1GB in size and if I see it correctly only >> the base-system is installed there. Did base grew with the latest >> snapshots? > > I found the problem. It sat in front of the keyboard m) At some point > I created apparently by accident a huge file in /dev and that ate up > all the space in / One problem solved. Now to my other space-problems > where resizing would be a solution but maybe I just need to tidy up > more. and that's one reason we tell you to partition the heck out of your system. Best/worst story I heard along those lines was someone who typoed their backup script, and instead of writing to tape, wrote to a FILE in /dev. Unfortunately, they used one big partition, so there was plenty of space for this file...but of course, if the bad thing happened, the tape was blank. If you fill a 100M root partition, you clean up junk you left laying around. If you fill a 1G root partition, something went horribly wrong, and you find and fix the problem. Enlarging is NOT the answer there. Disks are stupid big these days. You can't get too small a disk for many applications. Leave most of your disk unpartitioned, and you can go back and "enlarge" anything you want at a later time (well...'cept for root. and 1G is a HUGE root partition). Just create a new partition, copy everything from the old to the new, change fstab, reboot. Nick.
Re: Automatically restarting services/daemons after crash
On 10/13/17 05:01, Mihai Popescu wrote: >> That's sensible, but if money or lives were on the line, I think It'd >> be better to have a running but potentially vulnerable service. > > Not OpenBSD related, but I was truly amazed people like you still > exist and still set up computers for others! > For you curiosity about user case, I preffer such a service not to be > started at all. > > Money(online bank accounts) should not be managed by broken software. > If they can't do this in a proper way, they should not start such a > service at all. > Life(medical, work) should not be risked behind this kind of services. > > I wonder, was it a joke what you've asked? I wish it was. I wish this really was a rarely seen attitude. While quite out of place in this community, the rest of the world is much more about "security last". Oh sure, if you ask, "security is important!" will be stated, but when you start asking questions, it will truly be the last priority. Absolutely f'in' last. Just this week, someone told me that OpenSSL was better than OpenSSH because OpenSSH is too difficult to Man-in-the-middle, "obviously not designed for Enterprise use". What do you say to things like that? (I said, "It was designed for security first"). Ah, the stories I could tell if it wasn't for the need to make a living. ["Enterprise grade"??? What's so good about that? That damn ship was broke almost every week! And broke twice a year in exactly the same way!] Nick.
Re: chronium ports
On 10/16/17 04:28, Tuyosi T wrote: > i build my openbsd snapshots machine from source > (kernel , userland and xenodm ) > > the PC complied from source works more correctly > as if ready made suite is not my just size , > tailered one is very fit , so i think . I think you think wrong. Just on your one example, you have to make up 18 hours of productivity to break even. Feel free to generate and post your own benchmarks, but I think logic pretty well dictates you won't get those 18 hours back before your next upgrade...IF there is any difference, and last I looked there is none. Not "just a little", but no difference in the code generated based on the details of the machine you are running on. Nick.
Re: Install process: couple of comments
On 10/16/17 18:38, Limaunion wrote: > On 10/16/2017 06:55 PM, Limaunion wrote: >> Hi! Last friday I upgraded my ALIX system from 6.0 to 6.2 using the PXE >> boot method. In previous years I used an internal FTP server to perform >> the upgrade, but for some reason this is not supported any more since a >> couple of releases. I mounted and published the ISO image using a >> raspberrypi and NGINX (HTTP method). During the install process I hit >> the following error 'unable to get a verified list of distribution >> sets'(*). I couldn't find much help from google but after some time I >> figured out that the install was looking for a file named index.txt, >> that is not included in the ISO. >> Maybe some of this information can be included to the install guide for >> those of us doing a local HTTP upgrade, and also it would be great to >> have the index.txt file included in the ISO. >> For the record, the kernel relinking (Relinking to create unique >> kernel...) took about 14 minutes in my ALIX board and it takes about 2.5 >> minutes the library reordering during the boot process. >> Just my .02 cents. >> J. >> >> (*): server: localhost, request: "GET /OpenBSD/i386/index.txt HTTP/1.0" >> > > I know about this, but its not crystal clear (at least for me): > > https://www.openbsd.org/faq/faq4.html > Note: If you intend to provide the sets over HTTP(s), place siteXX.tgz > in your source directory and include it in your index.txt. It will then > be an option at install time. > > Best regards. There are a few ways of doing things right. There is a near infinite number of doing things, if not wrong, at least "oddly". Mounting an ISO file as a file system and using that as the source of your files for a web install qualifies as "at least, oddly", defeating the purpose of both an ISO and a web install. In fact, you may well be over the "wrong" line on that. I don't think you will see any special documentation or file changes supporting that way of doing things. Nick.
Re: "switching console to com0"
On 10/17/17 00:03, Justin Mayes wrote: > Greetings all - what does one do when during the install you set the > default console to com0 and now your serial cable is not working? I > cannot login to set the default console back to use the keyboard and > monitor. Instead of the boot prompt where I can normally change > settings and/or enter single user mode I just get the message > "switching console to com0" immediately without any delay to enter > boot commands. Thanks for your time. man boot has this: boot.conf processing can be skipped, and the automatic boot cancelled, by holding down either Control key as boot starts. and as that's where the "set tty com0" command is, that will solve your problem. (I can rarely remember which key it is, so I often just hold down CTRL, ALT and SHIFT on one side of the keyboard.) (note: I'm assuming you are talking about amd64 or i386 platforms). Nick.
Re: "switching console to com0"
On 10/17/17 08:02, Nick Holland wrote: ... > man boot has this: > > boot.conf processing can be skipped, and the automatic boot > cancelled, by holding down either Control key as boot starts. > ... > (I can rarely remember which key it is, so I often just hold > down CTRL, ALT and SHIFT on one side of the keyboard.) That part is bad advice. Literally the second I hit "SEND", I remembered why one shouldn't casually hit the shift key during the boot. Shift during the execution of the first stage boot loader (biosboot(8)) forces it to use CHS reads instead of LBA reads. In many cases, it will still work. In some cases, no. So, "man boot", search for "boot.conf" if you can't remember "Control". Nick.
Re: Hyper-V Disk Performance
On 10/23/17 17:41, Daniel Boyd wrote: > Is there a recommended configuration for virtual disks in Hyper-V? I > have a virtual machine that I set up recently running 6.2 that has > *very* slow disk performance. It took well over an hour to untar > ports.tar.gz. The host server is a few years old, but it's running 3 > RAID-5 7200rpm drives, quad-core Xeon and 32 GB RAM... so not exactly a > slow machine. And this is the only Hyper-V VM it's hosting. actually...raid5 is slow on writes (write one block = read existing block. Read parity block. Write data, write parity. Hopefully, you have a write cache that's on and working), 7200rpm drives are slow by any standards these days. That's a heavy-lifting drive, not anything to mention in the same sentence as "not slow". (don't get me wrong, I got a lot of heavy-lifting drives. And I'm kinda slow. But I try to be realistic about it). > I've got the virtual disk configured as IDE / VHDX / Expanding (the > Hyper-V defaults). "expanding" means not preallocating the disk, I'm guessing? Again, not a performance choice. Your file system fragments are going to be fragmented. > The controller can be IDE or SCSI. The disk format > can be VHD or VHDX. And the disk can be configured as fixed or > expanding. I'm going to try converting the disk to fixed and > defragging my NTFS. > > Any thoughts on IDE vs SCSI and VHD vs VHDX? Neat thing: OpenBSD doesn't care much. You can change it at the hypervisor level, reboot, and see for yourself how it works. This isn't Windows or Linux which will have a cow if you change the disk type or controller type after load. (before DUIDs, you might have to change your /etc/fstab, but as long as you are using DUIDs, you should be in good shape there). But ... for unpacking ports, make sure that file system is mounted (at the OpenBSD level) with softdeps. Yes, it's really a huge difference for lots of tiny files, which is exactly what the ports tree is. This will matter more than hypervisor knobs, I suspect. Nick.
Re: Hyper-V Disk Performance
On 10/23/17 22:07, Daniel Boyd wrote: > On Oct 23, 2017, at 8:57 PM, Daniel Boyd > wrote: >>> But ... for unpacking ports, make sure that file system is >>> mounted (at the OpenBSD level) with softdeps. Yes, it's really a >>> huge difference for lots of tiny files, which is exactly what the >>> ports tree is. This will matter more than hypervisor knobs, I >>> suspect. >>> >>> Nick. >>> >> > > Also, out of curiosity, why is softdep not enabled by default? > Assume there must be some downside to having it on? > It was discussed a few times, as I recall. Short version is, it's more complex code. You don't add code and make things more reliable and more secure, and softdeps are definitely more code. It does use more RAM, and it can cause funny things to happen in failure situations. Myself, I've last had a problem with the softdep code probably 12 years ago...and I submitted a bug report and got a fix a day or so later. I've turned it off on a few machines when I thought I might be having an issue, and found out that no, it was always something else. Me? I'd make it the default. But it does do things "differently" than people sometimes expect. It reorders writes. It holds a lot of data in RAM before it gets to disk. That causes "issues" when you trip over power cords. If you are doing lots of tiny file writes, performance on other applications may suffer (that's been improved a lot over the years, but still noticable, iirc). Funny things happen that people don't expect if you run out of disk space or crash or unplug the computer. So ... if the absolutely safest, most reliable FS is your desire, don't use softdeps. If you want something that probably still beats the Linux file system of the month, and is a lot faster than the standard FS options, use softdeps. Nick. Nick.
Re: Hyper-V Disk Performance
On 10/23/17 21:57, Daniel Boyd wrote: ... > I have another vm running on my laptop under KVM that runs > substantially faster than the hyper-v vm. My laptop is far below the > hyper-v server in most respects performance-wise, but it does have an > SSD. I’d be curious to find out how much of that is raw disk IO > performance and how much is KVM vs Hyper-V and openbsd’s respective > drivers for each. Um. yeah. PURE disk intensive load...and an SSD vs. a slow RAID. Think about that a moment. The SSD is going to win...so big. SOOO big. I don't care what else you got backing it. The CPU won't matter for anything that will drive a SATA SSD, and the memory will barely be noticed for this task. It's all about write performance and seek time, and your SSD wins. A very scrawny laptop with a cheap SSD will run circles around all but the mightiest servers with spinning rust arrays when it comes to disk performance. It's just no contest. Nick.
Re: Lenovo 110s Laptop - bug or unsupported hardware?
On 10/27/17 23:33, J Vans wrote: > I decided to post this in misc because I am not sure if this a bug or > unsupported hardware. It is a Lenovo 110s laptop. > > Apm works on this machine. Suspend and resume work on this machine. > > When running X, and doing things that require a lot of memory (open > firefox and watch a youtube video + 3 or 4 more tabs + open evince > and open a sizeable PDF was my test) this machine freezes, and the > screen goes black. Sometimes this happens in 30 seconds, sometimes it > takes 10 minutes or more. I also tested with Chrome and Midori, and > got the same behavior. I also tested playing video locally and the > results were the same. On a few occasions it crashed while not doing > much, but for the most part if I keep memory usage low (i.e. use a > text based browser, for example) it does not crash. DDB is opening in > the background after the crash, but I cannot see it. I type ps, and > trace, but they do not show up in the messages after rebooting. I > have however been able to get several core dumps. They look identical > to eachother, which leads me to believe it is the same problem > happening in each crash. > > The above behavior is consistant across i3, Fvwm, and Cwm, with apmd > enabled or no, across all flag settings of apm, and > machdep.aperture=0, 1, and 2. > > Serial console is not an option on this machine but I have quite a > collection of core dumps. Any advice on trouble shooting this further > (or if it's unsupported hardware) would be appreciated. ... > $dmesg > OpenBSD 6.2-current (DEBUG) #2: Thu Oct 26 18:46:09 CDT 2017 > myu...@groo.my.domain:/usr/src/sys/arch/amd64/compile/DEBUG > real mem = 1970376704 (1879MB) > avail mem = 1900142592 (1812MB) chrome, firefox, and other bloatware on 2G RAM? In my experience with 4G RAM, it's just not enough. Are you sure you have entered the Swap Hell Zone? Nick.
Re: cloning to smaller hard disk
On 04/22/18 14:46, Tuyosi T wrote: > hi all . > i manage to clone bigger HDD(sd1) to smaller HDD(sd0) > > this is dangerous , so please test . > and there may be some errors , then please point them out . Ok, how do I put this nicely... PLEASE DON'T DO THIS KIND OF "documentation". Ok, you accomplished your task. Congrats, I'm proud of you. But your initial config was bad, your final config was bad, and your process was trivial and very specific to your config. Your "documentation" doesn't explain the WHY of what you do, or the VERY special (and wrong) case of your config that allowed this to work. It's not a teaching document. While I'm a big defender of free speech, this is not helpful in the way you probably intended. If your goal is training people to think before they follow stuff they find on the 'net, great, ok, I guess -- nothing teaches like a bullet in the foot. But I don't think that was your goal. Your initial system and final system were One Big Partition layouts -- Bad idea. And you copied over just the 'a' partition. Useless for the recommended OpenBSD config. And tar has trouble with really long paths. And really, your task is simple -- * Boot the system with the new disk attached. * Stop all processes you can that are changing important data on the disk. Can also be done by booting from bsd.rd. * If you booted from bsd.rd, you will probably need to /dev/MAKEDEV [sw]d1, as bsd.rd has only one sd and wd device. * fdisk (if needed) and disklabel your new disk. For simplicity, I'll assume same disklabel setup on the new disk and old. * newfs all the new partitions * for each FS, * Mount the new one somewhere * dump | restore each existing partition to the new partition. * umount the new partition. * Set up the boot code on the new disk. Interestingly, that's basically the process for any Unix-Like OS (ULOS). The last step (set up the boot code) will vary tremendously from ULOS to ULOS, and SELinux will require some voodoo that few understand to make things work after moving them in the name of security. Nick.
Re: Raid offline when newfs
On 04/29/18 20:23, Mimoza wrote: > > > Le 30/04/2018 à 00:01, Mimoza a écrit : >> Hi, >> I have a problem to create a second RAID 1 on my router an Soekris >> 6501-70 (http://www.soekris.com/products/net6501-1.html) > […] >> I can rebuild the offline device but he still offline … >> >> So, there any option or configuration to explain/solve that ? Something >> wrong with what i do ? >> >> Maybe something bad with the expansion card ? >> >> Thanks for any help. >> > > Well, i respond to myself but i foud the guilty. > My last question was the good way. I don't know why but the expansion > card do something wrong. I created the RAID system on another computer > and go back on router with the expansion card with the 2 HDD ready to > use and it's fine ! > > Sorry for the noise > Did you disable the RAID functionality of this card? If not, the BIOS probably tried to "rebuild" one disk onto the other, causing you all kinds of pain. softraid has to do everything for this to work properly. Nick.
Re: Troubleshooting rl instability on OpenBSD 6.1
On 04/30/18 18:04, Stuart Longland wrote: > On 01/05/18 03:00, Solene Rapenne wrote: >> >> Stuart Longland writes: >> >>> On 29/04/18 18:08, Solene Rapenne wrote: Stuart Longland writes: > Hi all, > > I've got an Advantech UNO-1150G industrial PC running OpenBSD 6.1 acting > as an ADSL router, public NTP server and DNS server. dmesg info: > >> OpenBSD 6.1 (GENERIC) #291: Sat Apr 1 13:49:08 MDT 2017 OpenBSD 6.1 isn't supported anymore, please upgrade. >>> >>> Upgrade what? The OS, the router? If I'm 100% certain that moving to >>> 6.2/6.3 will fix rl, then sure, but this answer is not helpful, as I've >>> been battling this problem for over a month. >> >> Maybe your issue is fixed in 6.2 or 6.3, who knows. 6.1 isn't supported >> anymore and you use it on a router connecting to the Internet. I can >> only recommend upgrading. >> > > It might conversely also be made worse by 6.2 or 6.3. In theory, it > shouldn't, but then again, in theory, I shouldn't have been getting this > problem either. > > An update of the OS will have to wait until I can purchase another CF > card to load with OpenBSD 6.3 and migrate the configuration. > > Alternatively, if the problem is hardware, I can just replace the whole > box. Updating OpenBSD on the existing one would be a waste of time. > > I need a way of ruling out the hardware as being an issue. Until then, > OpenBSD 6.1 stays, unless the debugging facilities in 6.2/6.3 are > drastically different that make troubleshooting this problem easier. > > I think I've tracked down the driver source here: > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/ic/rtl81x9.c > The log suggests it has not changed since the release of OpenBSD 6.1. > Here's the thing. There are rules to the game with every OS. With OpenBSD, if you have to stay up to date -- the support tail is only about a year long, and that is really only security issues. So, what are you after? A magic, secret sysctl, "sysctl rl.work.properly=1" ? Nope, no such thing. Sorry. A patch to fix it? Not going to happen against 6.1, 6.2, or even 6.3, most likely. -current is where development happens, only security issues and maybe some behavior regressions are ever pushed back to old releases...not operational improvements, new features, or new hw support. Now, rl chips were considered the worst pieces of network junk around until the ARM systems started sprouting networking chips. Don't get me wrong, I've used a lot of them, and had pretty good luck with them, but a lot of people I respect and who know better than me hate the #$%^ things. You say a couple things that catch my eye -- 1) 6.1 is over a year old, and you say you have been battling the problem for a month. So something changed. That's hinting hw, not sw. (typically. Or the load changed. or something). 2) you say you had "similar" problems with another OS. Similar to what, I'm not sure, but that sounds like you have a HW problem. Keep in mind, when it comes to networks, it's not just the computer -- the wire and the switch are also all suspect. But it boils down to this: if you want help on OpenBSD, you play by the rules and run either -current or at least a supported release (and if you contend it's an OS issue, you verify it still exists in -current!). If you don't need OpenBSD help...this isn't the place. And if you can say with certainty, "everything is the same", you will have no trouble adding debugging info and figure out your own problem. Nick.
Re: fdisk MBR contains more than one OpenBSD partition!
On 05/09/18 05:06, Rudolf Sykora wrote: > Hello misc, > > I wanted to use a MBR partition for backup purposes, > so I (almost) created (using fdisk) another OpenBSD MBR (A6) > partiotion, but then I got the message > > MBR contains more than one OpenBSD partition! > Write MBR anyway? [n] > > So am I doing it wrong? yep. In addition to "same disk backups"? [insert template rant here] ... Think of the fdisk partition as a way to mark off a part of the disk for OpenBSD. It should generally be one contiguous block. The beginning of *the* OpenBSD partition holds the disklabel, which is the important part for marking off OpenBSD disk (sub?)partitions. When you think about that, the reason for ONE OpenBSD partition starts becoming more clear. IF possible, just enlarge your existing OpenBSD partition to include the new disk space. disklabel, done. If not ... just make the fdisk partition something else, and create an OpenBSD partition in that space using disklabel, format it as normal. And don't ever us an OS on the machine of the type of the fdisk partition you picked. :) Nick.
Re: Is -current snapshot only used in current system?
On 05/16/18 05:42, Nan Xiao wrote: > Hi Peter & Otto, > > Thanks very much for your response! > > My laptop is very old: Fujitsu LifeBook T5010 > (https://www.pcmag.com/article2/0,2817,2352819,00.asp) . > > During booting, it shows: > >>>OpenBSD/amd64 BOOT 3.39 "very old" and "amd64" is the first warning sign. (or maybe it just means I need to upgrade my hw :) ) > Then it flashes one line (I can't see that line clearly, and it > should display load something), and the system will reboot again. > > The system will loop the above flow, reboot again and again. That's close (though not precisely what I recall, but it's been a few years) to what happens if you run amd64 on a 32 bit only proc. > Now I doubt it is related to partition issue, but not sure. > I divided the whole disk (MBR) into 2 partitions: > >>From offset 64, 4G swap, the left is mounted as '/'. > > This method at least works for OpenBSD 6.2. it's also possible your BIOS doesn't support loading data from "big" disks. Your new kernel might have landed higher than your BIOS can read. There are reasons your One Big Partition isn't recommended. > On Wed, May 16, 2018 at 5:07 PM, Otto Moerbeek wrote: >> On Wed, May 16, 2018 at 04:51:24PM +0800, Nan Xiao wrote: >> >>> Hi misc@, >>> >>> Greeting from me! >>> >>> Maybe a dumb question here. I want to use -current snapshot, and >>> my current OBSD is 6.3. So I download the newest -current bsd.rd, >>> and use it to upgrade. It prompts me the upgrade is success, but >>> the system can't boot. So I think this method only applies to system >>> is already -current, right? Because I can't find answer from >>> https://www.openbsd.org/faq/current.html, just want to confirm it. Nope. As long as you move FORWARD, all is good. -current is just a step along the way to next -release, the next -release is just a spot in the -current continuum. Nick.
Re: Snapshot upgrade to 6.2 -> 6.2 : kernel relink issue
On 05/20/18 12:32, Rick Ballard wrote:
> I can log to the console and have a functioning router/firewall.
>
> However, most commands fail:
>
> drmons0544w-142-166-18-133# vi test
> 4▒▒: not found/vim[1]:ELF▒
> /usr/local/bin/vim[2]: syntax error: `(' unexpected
third party package error. (/usr/local?)
>
> SSH exits immediately after I type in my password.
/usr/ problem?
> However, I can use ed, less, etc.
sound like root (/bin, /sbin) is good.
> Here is what I see on the console during the reboot:
> ...
>
> *em0: bound to 192.168.2.11 from 192.168.2.1 (a8:39:44:8f:68:20)*
>
> *reordering libraries:/usr/sbin/openssl[1]:ELF▒4▒?4: not found*
/usr problems
...
> *starting early daemons: syslogd pflogd unbound ntpd.*
$ which syslogd pflogd unbound ntpd
/usr/sbin/syslogd
/sbin/pflogd
/usr/sbin/unbound
/usr/sbin/ntpd
hm. But not sure how much griping of those /usr apps would make or
would get through the rc scripts.
> *starting RPC daemons:.*
>
> *savecore: no core dump*
>
> *acpidump: Can't find ACPI information*
> **
> *drmons0544w-142-166-18-133# dmesg*
$ which dmesg
/sbin/dmesg
> OpenBSD 6.3-current (RAMDISK_CD) #41: Sat May 19 22:45:21 MDT 2018
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD
> real mem = 1056833536 (1007MB)
> avail mem = 1021075456 (973MB)
> mainbus0 at root
> bios0 at mainbus0
> acpi at bios0 not configured
> mpbios0 at bios0: Intel MP Specification 1.4
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Genuine Intel(R) CPU @ 1.00GHz, 1000.12 MHz
> cpu0:
So my hunch is you screwed up your /usr partition during the upgrade,
which usually means this:
What really cool trick did you do that seemed like a great idea at the
time that most OpenBSD would not do and the developers would not have
thought worth planning for in the upgrade scripts?
I'm thinking symlinks of something to somewhere else, etc.
Nick.
Re: CVS Download: Timeout Error
On 07/09/18 12:54, MonsieurFugu wrote: > Hi OpenBSD forum, > > I'm new to OpenBSD and I'm running into an issue downloading the CVS > libraries and I cannot figure out the problem. source code, not libraries...but whatever. > I've downloaded the libs before but the vm I was using got corrupted, and > after following the same steps as before I keep getting this error: > > host$ cvs -qd anon...@anoncvs.fr.openbsd.org:/cvs checkout -rOPENBSD_6_3 -P > src > ssh: connect to host anoncvs.fr.openbsd.org port 22: Operation timed out > cvs [checkout aborted]: end of file from server (consult above messages if > any) pretty clear: something is blocking SSH traffic (port 22) between your computer and the CVS mirrors you tried. No SSH, no CVS over SSH. > I've gone through all the steps on this tutorial > (https://www.openbsd.org/anoncvs.html) and tried multiple mirrors but to no > avail. I've disabled the firewall in case that was the issue but it fixed "the" firewall. Which "the" firewall? :) > nothing. I'm able to use the ping command, however traceroute doesn't seem > to work. I can provide more info if needed. So...sounds like a lot of things are blocked. > Does anyone know how I can fix this? Unblock port 22? Or more likely, move to a non-port 22 blocking network. Lots of businesses block port 22 outbound, which you need. Nick.
Re: Ratgod leadership?
On 07/10/18 12:57, Email wrote: > [drivel snipped] Probably about 20 years ago, I had despaired of the "solution of the week!" of Linux, and figured, while it was cool that a bunch of people had put together a free Unix-like OS, the churn was too great to be practical for businesses expecting a low-maintenance solution. While reading through an on-line forum, I tripped across crap like the OP here posted (and much worse and more literate, of course) being said about this Theo de Raadt character. It wasn't intellectual disagreement on technical issues, it was childish name calling, leading to the "conclusion" that anything Theo did must be wrong. Well...anyone who generates THAT much blind hatred has to be checked out, they are obviously either onto (or into) something. So I read up on OpenBSD, LOVED the philosophy of "security matters", downloaded it, and never regretted it. Following the fantastic OpenBSD documentation, I accomplished more in three days with OpenBSD than I had in several years of poking at Linux. So, while obvious trolls like this are annoying...they also serve a purpose. I thank those mindless haters for pointing me in a very interesting direction a couple decades ago, and I'll thank this ass in particular for reminding me that I'm a bit behind in my project donations (I do miss the CDs). That has now been fixed. Nick.
Re: Installed current on top of FAT32 flash, Recover old filesystem??
On 07/14/18 15:16, Chris Bennett wrote: > I very carefully and surely tested which flash drive to use and then > pulled out the wrong one. > I stopped the install with halt and done nothing else. > Should I have yanked it, halted it or just said goodbye? > > ddrescue or something else or nothing else? It depends on when you stopped the install. If you had just done the disk layout, you could probably create (using OpenBSD) a FAT32 partition that covered the entire disk (where did your original start? you might have to recreate some history on an identical device here to find out) and see if your data is intact. It very well could be. If you completed the install...uh...you have got a problem. Still, there are tools around now that will find, with amazing success, particular types of files on "overwritten" media, though of course anything that was actually overwritten is not going to be recovered. Nick.
Re: Moving a system disk from one server to another
On 07/25/18 15:38, Jay Hart wrote: > Hello al, > > Just bought a new server and wanted to see what the practicality would be of > moving my disk from > one box to the other. Its a stock 6.3 install, fully patched, with a few > packages. The old > processor is a VIA based CPU running generic i386 kernel. The new box is > based on an Intel Celeron > J1900 64-bit CPU. > > My thought is it should move over and boot up on the stock generic i386 > kernel, at which time I > could update to 64-bit or just wait until 6.4 comes out and then update. > > Curious if you think this will work, or should I just do a clean install. Yes. No. Yes, you should be able to move the disk from one machine to the other (with suitable adapters), and after adjusting your network adapters, you should just take off and run. No. Do not try to "update" to 64 bit. Reload from scratch. OpenBSD treats i386 and amd64 as two DIFFERENT platforms. Would you take a SPARC64 or MacPPC disk and put it on a PC and just "update" to the new platform? NO! You would reinstall. And that's what you should do here. At which point...what are you trying to gain by moving a disk from the old system to the new one? Just put a new disk on the new system, load the platform of choice, and copy your key config files from the old one to the new one, and that way, your old system still exists. Nick.
Re: Equipment for OBSD based firewall
On 09/04/18 00:57, Joel Wirāmu Pauling wrote: > But - The thing that isn't mentioned here is basically Power Cost and > Consumption vs PPS(Packet Processing Speed). > > IMNSHO running on anything that doesn't ; > > A) Have passive Cooling > B) Is older than a couple of years (in intel/amd terms anything with a > TDPW above 65W) > > - is probably not a great idea. Mainly because the on-going cost of > supplying power to old junkers isn't worth what you can do with a > 'newish' junker. > > If you have free electricity, feel free to do what you like I guess. TDP is the MAXIMUM power draw. MAXIMUM (and of only the CPU) Your OpenBSD firewall isn't going to be running at the maximum power consumption on a P4 or newer processor very often or very long. For home use, you really care about idle power draw and the ability of the HW to do the job. Every era has its "The Answer Is" system, this year, it's PCengines and ARM/Octeon. Before, it was Soekris. People get stupid with that stuff. What's "greener", keeping something out of a landfill that draws 40w or something brand new that draws 15W? How many years do you have to run the 15W system to pay for the cost of it? How much is your time spent fighting with its quirks worth? Will it pay off before your ISP ups your downlink speed to the point where your barely-does-the-job HW is now "can't do the job"? Some old P3/P4 systems have very modest power consumptions when idle. Get yourself a wattmeter, and see what you have. After install, remove power from the CD/DVD, maybe some of the case fans, and maybe consider a USB flash drive to boot. Slow the clock speed, remove some RAM. Pull out the sound card/modem/whatever. And when things break, unless you just HAPPEN to have a serial terminal infrastructure laying around, an ol' keyboard and monitor used to debug your system will beat the heck out of finding a USB to Serial adapter and a null modem cable when you need it. Heck, I have a serial infrastructure in my life, and I'm really wondering if my serial-only firewall is worth the pain. I recently moved from a USB drive to a real hard disk because while it draws more power, it boots and works a LOT faster (kernel and library randomization is horrible on USB flash drives). I get the "I hate Intel" thing, but unfortunately, most of the non-Intel systems show why Intel (and AMD) own the serious computer market. Nick.
Re: Problems with a quad Realtek NIC
On 10/12/18 21:42, Martin Hanson wrote: >> It is preferable to just include the whole dmesg directly in the mail >> Better still, when it's a "sometimes works" problem, include a "diff -u" >> between the two (the context to show where the lines are added/removed). > > I have pasted a "diff -u" on https://paste FYI... I don't click on links for stuff that should be in-message. I suspect I'm not alone. But yes, I agree with Stuart, sounds like a HW problem. When things come and go without changing, that pretty well screams "hw". Different OSs may work around different hw bugs differently, but it's still a HW bug. In your case, looks like the BIOS isn't initializing the PCI-PCI bridges properly. > +ppb1 at pci1 dev 0 function 0 > vendor "ASMedia", unknown product 0x1184 rev 0x00 > +pci2 at ppb1 bus 2 > +ppb2 at pci2 dev 1 function 0 vendor "ASMedia", unknown product 0x1184 > rev 0x00: not configured by system firmware === > +ppb3 at pci2 dev 3 function 0 vendor "ASMedia", unknown product 0x1184 (man ppb) And yes, while Realteks used to be condemned and insulted, the new network devices on many ARM boards is making Realteks look good. At least their limitations are understood and dealt with well in SW. Most people don't need the absolute best HW. But in your case, you probably want those PCI-PCI bridges configured. :) Nick.
Re: migrate users from old system
On 10/16/18 10:39, Markus Rosjat wrote: > hi all, > > > what is the right way to do a migration of users from one system to > another? I did the following but it seems to get some problems with > permissions on the files and directories. > > 1. copy passwd, group, master.passwd to new machine yep. > 2. clean up files (some users doent exist anymore) how did you do this? > > 3. use pwd_mkdb to create a new db IF you use vipw to remove users that no longer exist, when you exit, it will sync everything for you. If not, make a token edit with vipw, then save it. > this gave no errors but after migrating some files with rsync to the new > machine it seems that some directories not read- /writeable (for example > by openLDAP) even all the permissions are set correct. If you rsync through an intermediary machines, i.e., an rsync backup system, make sure you use the --numeric-ids option, otherwise, it will try to sync the names (rather than numeric IDs) of the things it can -- and totally scramble the things it can't. If you are going directly from the old machine to the new machine, make sure you copy over the passwd, master.passwd and group files first. Also -- assuming there was an OS upgrade, copying over the user and group files just broke all new system users, so re-run sysmerge. Nick.
Re: macppc - Booting with a SATA PCI drive
On 10/25/18 14:51, Katherine Rohl wrote: > I’m trying to run OpenBSD and Tiger on one hard drive on a Mac G4 > tower. I’ve successfully installed 6.4 onto the drive and I can still > boot from Tiger, so that’s good. I then copied ofwboot to the Tiger > partition (since it’s the first HFS+ partition). > > I have an Silicon Image 3112-based PCI SATA controller that’s > recognized by OF. Unfortunately, I can’t remember how to tell Open > Firmware to boot from a SATA drive attached to a PCI controller so I > can specify the OpenBSD boot image! > > Does anyone know how to find out the partition’s location in the > device tree so I can boot to BSD? I’m not good with Open Firmware, > unfortunately. I’m more of a Classic person, with my Mac usually in > OS 9. You have much greater faith in Apple firmware doing things with non-Apple HW than I do. :) Apple built their firmware to boot MacOS from MacHW, and anything beyond that that actually works is more good luck than their intent. I'm not saying it's impossible, it's just not guaranteed. And it might be buggy if it does try to work. I'd suggest just booting off your IDE disk and use your SATA disk as non-boot space. Or perhaps a SATA to IDE adapter and attach it to the factory IDE port. Nick.
Re: performance of intel multithreading
On 11/05/18 23:51, Kihaguru Gathura wrote: > Hi, > > From a security standpoint, > which platform will offer better performance huh? What's your priority, security or performance? > solution in web and database now that OpenBSD > multithreading is switched off for Intel? > > > (Fujitsu PRIMEPOWER 250 - Version F - 2 X SPARC64 V 1.98 GHz) a very old, SCSI based computer. > or > (Fujitsu PRIMERGY RX300 S6 - 2 X Xeon 6 core 12 thread E5620 2.4 > GHz) A not quite as old SATA/SAS system (but still hardly new). If you have both, do your own benchmarks. If you have one and no budget to buy something ...um... modern, use it. If you have neither, buy something ELSE. My guess is that the Intel powered system will outrun the SPARC system in raw performance in every measure you make. Probably won't even need to use a stopwatch to compare. And a modern laptop will embarrass both of them, multi-threading or not. I'd not put a SCSI system into production as you won't find too many drives less than ten years old, and they are tiny, power hungry, and slow by modern disk standards. At least the SAS based system, you can get new drives for, or even stock it with SSDs and really have fun. Security? Eh. I suspect you aren't getting ROM updates for either. If someone pops your system security and tries to run a binary on it, the UltraSPARC will probably give them a bigger surprise. But if you are running web services, you are probably running apps written by someone without any idea what they are doing in an interpreted language like PHP, and the exact same exploits will take out either platform, because the exploits will be at a much higher level than the processor. Nick.
Re: performance of intel multithreading
On 11/07/18 11:34, Kihaguru Gathura wrote: > Hi, > > > On Wednesday, November 7, 2018, Nick Holland > wrote: >> On 11/05/18 23:51, Kihaguru Gathura wrote: >>> Hi, >>> >>> From a security standpoint, >>> which platform will offer better performance >> >> huh? What's your priority, security or performance? >> > > Security is the Priority. > >> If you have one and no budget to buy something ...um... modern, use it. > > I have the PrimePower 250 > >> UltraSPARC will probably give them a bigger surprise. > > Please explain further if possible. Most attackers are what we call script kiddies -- they don't know what they are doing, but they have a script, they throw it at a target and it either works and they move in or it doesn't, and they move on to the next target (or often, their magic cracking kit does it for them). For these people, "computers" are all IBM PC descended and all powered by Intel processors. Something not running Windows or Linux and not running on an Intel chip will be a huge deterrent IF they get into your system and try to run their binary tool kits. Now, someone who knows their mouse from their keyboard...no. And a state sponsored attacker that's after YOU personally? No. But they will have to hand you over to the next tier guys. :) The analogy I've used often is much of computer security logic, if applied to your household security, would involve putting the door to your house on a different side than your neighbors's doors and putting the door knob on the opposite sideand maybe painting the door purple. And sure enough, the guy wandering down the street with instructions saying "Door on front of house, color brown, handle on left side" will totally miss the door of your house and your house will be "secure" even if the door is unlocked. And fortunately, 99.9% of the attackers out there are going to be stopped by your oddly placed backwards purple door. The problem is...there are tens of thousands of attackers, so quite a few aren't going to be confused by this. > But if you are >> running web services, you are probably running apps written by someone >> without any idea what they are doing in an interpreted language like >> PHP, and the exact same exploits will take out either platform, because >> the exploits will be at a much higher level than the processor. > > Self written services in C language. Now, who do you think is a better programmer, the people who put together OpenBSD or you? Not to show you any disrespect, but honestly, I'm putting my money on the OpenBSD devs. Most likely, OpenBSD won't be the entry point for your attacker. A lot of the brilliant work that the OpenBSD devs have done may HELP your system survive a flaw in your program, but your program is still more likely to be the entry point (or data exfiltration point) than the OS is, so your Plat X vs. Plat Y decision is probably not the big thing to worry about. Nick.
Re: OpenBSD migration
On 11/17/18 15:13, Martin Sukany wrote: > Hi, > > I want to migrate OpenBSD 6.4 (stable) from VM to bare metal. I see, as > usual, two options: > > 1) install everything from scratch > 2) create some flashimage (I did such thing on Solaris few years ago) > and apply the image on new hw. > > I'd be glad for any personal experience / recommendations. > > NOTE: Server is not so important so downtime is not a problem here I'm going to suggest option 3... 3) Restore from backup. You got a backup, right? You think it works, right? Here's /THE/ time to find out. I have done image migrations (dd partition->file, dd file->partition), I've done complete rebuilds, and they all work if done properly. OpenBSD is easier than most other OSs, regardless of how you do it, if you understand all the pieces. But really, this is when you get to test your backup. And, this should be the lowest down-time -- you can fully test the new system (AND FIX YOUR BACKUP PROCESS) before you flip the switch. Nick.
Re: With all this CPU/hardware mess, any advice on what to use for an organization?
On 11/20/18 11:43, Chris Bennett wrote: > I am almost certainly going to be replacing with a new server for an > organization I am a member of. > With all of this mess with Meltdown, Spectre, insecure motherboard > chips,etc. > I am pretty clueless on exactly what is going to be a secure set of > server hardware. > Intel, well no. > AMD? I have read about problems with non-CPU chips being compromised. > Another architecture? I have never used anything other than Intel/AMD. > > The server will run httpd, mailserver, PostgreSQL and somehow a good way > for well encrypted messaging at times. all on one server? And as someone who has run a number of mail servers for a number of companies ... don't. Just don't. Running your own mail server is a good way to accomplish nothing except wasting a lot of time and making people hate you. > It is very likely to run out of Austin, Texas. > I think that having a direct connection would be best, but would a > proper setup make collocation OK? You are using poorly defined buzzwords. What you mean by a "direct connection", "proper setup", "collocation" and what I mean are likely very different. > This isn't going to be my server, I will just be in charge. That's > completely new for me. > Any advice is really welcome, everywhere I read anything, hardware seems > broken and insecure. Pretty much all new HW is optimized in ways that we are now learning (and has been known for a long time) introduce security problems. However, most of the problems boil down to having malicious software running in the control of someone else on the same physical machine YOUR code is running on. In short: No news. Really. If someone that wanted to do you evil lived in the same house as you, you would not be comfortable, right? What if you put up walls (virtualization) that have proven to to be about as robust as paper? That make you feel any better? Probably not. Virtualization has been proven -- over and over -- not terribly secure. Now we got cross-virtualization platforms ways of stealing data from other processes. Important? yes. But in the big picture, it's similar to Yet Another buffer overflow. So...split your tasks on different physical systems as much as possible. If your webserver is serving static pages, it's probably pretty robust. If it's running Wordpress or any other "any idiot can manage the web page" apps or dynamic web pages for other reasons, it should be a machine of its own and have no other important data on it. Your primary goal should be to keep the bad guys off your computer in every sense. And again...nothing new here. But if security is your concern, you want real hw you control in every sense. Unfortunately, if you have performance requirements, your choices are AMD and Intel. Older Intel and AMD chips aren't getting any support to deal with these problems, so your choices are incredibly old chips which are probably not in the most reliable hardware, and a whole bunch of other old, unreliable, and slow hardware platforms. But be realistic. Your bosses will probably mandate a VM on someone else's hw, a wordpress website, one box for everything, and that you give him the root password which he'll e-mail to himself to keep it "secure". Your most likely breach points will be an easily guessed password (usually, a manager's), a bug in a web content management system, or someone believing that "secure e-mail" is a thing. In other words, Same Old Shit. It probably won't be breached by a Spectre or Meltdown-like attack. But it MIGHT be. Obsessing about them is generally missing the real day-to-day risks. Nick.
i386/amd64 boot (and pxeboot) compatibility
Hi, For a long time, the /boot and pxeboot of i386 would boot amd64's kernel and amd64's would boot i386's kernel. My tftp server had both amd64 and i386 bsd.rd files named "bsdamd64.rd" and "bsdi386.rd", snapshots downloaded daily. But recently, I discovered I could not PXE boot i386's bsd.rd from the amd64 pxeboot. I then grabbed a spare laptop, and confirmed this problem happened the other way as well -- an amd64 installed machine could not boot i386 from the amd64 /boot file. I also see the i386 and amd64 boot files have different version numbers now. So...I'm kinda inclined to guess this is not an accident, but figured I'd ask just in case it is. Nick.
i386 kernel relinking
Question about kernel randomization and relinking...
It seems to take a fair amount of RAM, at least for systems that
are forced to run i386. And I mean real RAM -- swap doesn't seem
to cut it.
I discovered that several machines I was intending on using for
minimal purposes just couldn't complete relinking. So I built a
VM and started playing with the RAM.
Built with 1G RAM, default was a 1.2G swap, worked fine.
Reduced to 256MB RAM, Kernel failed to relink. As with my old
junk.
The magic number seemed to be between 320MB (failed) and 384MB
(worked) of RAM. Ok, fine.
Kernel relinking is important, I get that. Probably time to
start tossing old junk. I get that, too. I'm not complaining
about the forcible retirement of some of my old junk. I'm just
curious why swap didn't "fix" this problem.
But that VM failed at 320MB RAM, even though it had 1.2G of swap,
mostly unused (MOSTLY. Yes, it was going into swap). Is there a
semi-layperson's explanation of this? Or is this a "if you got
to ask, you won't understand" kind of thing?
And here's the relink log from my VM, but the ones from my physical
boxes looked pretty similiar.
$ cat relink.log
(SHA256) /bsd: OK
LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
0 0 0 0 0
mv newbsd newbsd.gdb
ctfstrip -S -o newbsd newbsd.gdb
strip: there are no sections to be copied!
rm -f bsd.gdb
mv -f newbsd bsd
mv: newbsd: No such file or directory
*** Error 1 in /usr/share/relink/kernel/GENERIC.MP (Makefile:1131 'newbsd')
I also found that a 320MB machine could not build the kernel from scratch.
Nothing used much memory until the ld step, which started using large amounts
of memory and some swap, and errored out the same way:
LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
ld -T ld.script -X --warn-common -nopie -o bsd ${SYSTEM_HEAD} vers.o ${OBJS}
textdatabss dec hex
0 0 0 0 0
mv bsd bsd.gdb
ctfstrip -S -o bsd bsd.gdb
strip: there are no sections to be copied!
Thanks!
Nick.
Re: i386 kernel relinking
On 2020-04-10 10:10, Stefan Sperling wrote:
> On Fri, Apr 10, 2020 at 09:35:16AM -0400, Nick Holland wrote:
>> Question about kernel randomization and relinking...
>>
>> It seems to take a fair amount of RAM, at least for systems that
>> are forced to run i386. And I mean real RAM -- swap doesn't seem
>> to cut it.
>>
>> I discovered that several machines I was intending on using for
>> minimal purposes just couldn't complete relinking. So I built a
>> VM and started playing with the RAM.
>>
>> Built with 1G RAM, default was a 1.2G swap, worked fine.
>> Reduced to 256MB RAM, Kernel failed to relink. As with my old
>> junk.
>>
>> The magic number seemed to be between 320MB (failed) and 384MB
>> (worked) of RAM. Ok, fine.
>
> FWIW, my soekris net5501 with 256MB of RAM and 512MB swap does manage
> to relink a kernel (on 6.6 + syspatches).
Whoops. Guess I should have mentioned, that was -current, as of
yesterday
OpenBSD 6.7-beta (GENERIC.MP) #110: Thu Apr 9 01:20:52 MDT 2020
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
real mem = 334970880 (319MB)
avail mem = 313077760 (298MB)
and probably a couple weeks ago for the real (old) hw.
I'm curious if your Soekris can handle 6.7-beta.
Nick.
>
> # ls -l relink.log
> -rw-r--r-- 1 root wheel - 507B Apr 10 13:33 relink.log
> # cat relink.log
> (SHA256) /bsd: OK
> LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
> ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
> ${OBJS}
> textdatabss dec hex
> 11815507267748 1101824 13185079c93037
> mv newbsd newbsd.gdb
> ctfstrip -S -o newbsd newbsd.gdb
> rm -f bsd.gdb
> mv -f newbsd bsd
> install -F -m 700 bsd /bsd && sha256 -h /var/db/kernel.SHA256 /bsd
>
> Kernel has been relinked and is active on next reboot.
>
> SHA256 (/bsd) =
> a940ce989d708e5b87a1186ee81bd624066baeabe67b8405b52e4fa2988b565
>
>
> # dislabel -pm wd0
> #size offset fstype [fsize bsize cpg]
> a: 353.0M 64 4.2BSD 2048 16384 5624 # /
> b: 511.1M 722944swap# none
> c: 15280.0M0 unused
> d: 444.8M 1769728 4.2BSD 2048 16384 7116 # /tmp
> e: 607.7M 2680576 4.2BSD 2048 16384 9685 # /var
> f: 1703.0M 3925216 4.2BSD 2048 16384 12958 # /usr
> g: 505.8M 7412896 4.2BSD 2048 16384 8060 # /usr/X11R6
> h: 1632.9M 8448736 4.2BSD 2048 16384 12958 # /usr/local
> i: 1381.2M 11792960 4.2BSD 2048 16384 12958 # /usr/src
> j: 5282.4M 14621632 4.2BSD 2048 16384 12958 # /usr/obj
> k: 2850.9M 25439936 4.2BSD 2048 16384 12958 # /home
>
Maintenance: (man|cvsweb).openbsd.org, (openbsd|obsdacvs).cs.toronto.edu
hi. The following servers will likely be inaccessible at times or completely, April 14, from 7am to 8pm Eastern Daylight Time (UTC-4) (yes -- 13 hour window) for site network maintenance. * man.openbsd.org * cvsweb.openbsd.org * obsdacvs.cs.toronto.edu * openbsd.cs.toronto.edu Nick.
Re: dynamic dns updates for clients in my home network?
On 2020-04-25 15:00, bofh wrote: > Hi, > I searched through the archives and saw a couple of discussions about using > Dnsmasq from a long time ago. > > Is that the best way to let the stuff in my home to have valid dns entries > in my home network? > > How difficult is it to get the OpenBSD provided dhcpd and unbound to do > this? > > Thanks. https://web.archive.org/web/20160310223857/http://www.thismetalsky.org/files/dhcp_dns/dhcp_dns/ This person wrote a little perl script that parsed the dhcpd lease file and wrote a Dan Bernstein TinyDNS data file. A number of years ago, he put an ISC license on it...and apparently since took it off his website. I managed to rework it to put out NSD compatible zone files, I think this is much preferable to running a package for this, but your opinion may vary. I'd show my code, but it currently runs as root, and that's just wrong (it should probably use nsd-control(8) to reload nsd. My code should probably also create a reverse DNS file, but I've not missed that enough to worry about it). I've been using this script, first As Is, but now with NSD for over 15 years. Nick.
Re: OpenBSD insecurity rumors from isopenbsdsecu.re
On 2020-05-07 10:00, i...@aulix.com wrote: > Dear OpenBSD fans, > > Can you please comment negative appraisal from the following > website: > > https://isopenbsdsecu.re/quotes/ > > I did not want to hurt anyone, just looking for a secure OS and > OpenBSD looked very nice to me before I have found this website. Rule of life #1: when lots of people hate you, you are either doing something very wrong...or very right. People don't waste their time on people who are average-ish. That's actually how I found OpenBSD -- reading through a once popular chat website, saw people spending a lot of time throwing a lot of hate and personal attacks at Theo and his team. Well, by my figuring, anyone who gets that much venom tossed at them needs a looking at! That was 22+ years ago. No regrets. You have to decide for yourself if OpenBSD is very right or very wrong for you (not a lot of people in the middle, and that's fine.) Looking at the quotes, I see... * Jealousy * competitors * broad, general statements * Blablabla * People with a self contradictory titles. * people hiding behind pseudonyms * People that have All The Answers, just waiting for someone to do what they say. * Name callers * "No shit Sherlock"ers * "OpenBSD sucks, I like your website!" * "OpenBSD does what it set out to do, I like your website" * People "removing all doubt" (as in, "Better to be thought a fool than to open your mouth and remove all doubt") * "if it isn't popular, it's not good"er * unbacked claims. * another, this one thinks only about fighting the past wars. * more unbacked claims, this one, totally anonymous. * A person wanting YOU to find exploits in OSs. Guess they are all pretty secure if they aren't finding them themselves. Seriously, if you understand OpenBSD's work, you would take many of those quotes as complements. OpenBSD's security mitigations broke a "secure" language? Maybe you should check your assumptions. Elsewhere on that website, he mocks OpenBSD for calling someone "inaccurate jerks" -- I happened to click on that, since it didn't exactly roll off the tongue, and what is the actual context? Theo saying, "No, that's not a hardware problem, that's an OpenBSD problem and it should be fixed". You were not supposed to look at the context, I guess. The line about "Insults" is actually someone mock- complaining about doas not insulting users like sudo does.The more stuff I click on, the more I start to think, this is an irony site! This guy LOVES OpenBSD! Well, fudge. I just wasted a lot of time writing this!) Nick.
Re: fw_update verify firmware?
On 2020-05-14 11:08, i...@aulix.com wrote: >> If that binary code was on a ROM, would it be less malicious? > > Cannot more recent and up to date binary code be more malicious than > old one in the ROM? This has nothing to do with OpenBSD. That can be true for any kind of code update, whether it exists in RAM on a device that's loaded by the OS at boot time, EEPROM that can be reprogrammed by software, or a chip that has to be physically swapped out. I actually had Adaptec give me a firmware update with a time bomb in it, and didn't bother to tell me that after X days, it would brick my adapter and prevent me from updating/downdating it. If it had been stored in RAM, I might have been able to recover it, but since it was flashed into EEPROM and prevented the machine from booting, the card had to be replaced...and my customer had an outage. > Please take into account, I am a very noob in security area and it is > just my IMHO. Please read your own statement. You aren't qualified to assert your opinion in this group, humble or not. It's not our job to turn you into a security expert. If you value the work that OpenBSD does to protect your security, use it. If you don't, use something else. Please. We aren't here to win you over. Some of us are kinda tired of your flood of queries asking for yet another opinion on often and widely discussed topics. > Anyway there was another distro like LibertyBSD which was an OpenBSD > without some already seldom blobs like firmwares. And another OpenBSD > fork is declared to be going to appear: Hyperbola (it is Linux based > yet for now), completely pure from BLOBs too. ...and you won't find much modern hardware that it works on. You can achieve your goal (including the "not working on your hardware" feature) with OpenBSD by just removing the contents of the /etc/firmware directory. If the firmware isn't needed on your machine. it's not loaded. Concern about firmware binaries is not incorrect, but it is horribly missing a lot of points about how modern computers work. It's kinda like putting six bullets in a revolver, and obsessing about the third one. Yes, sure...that third one may blow a hole in your head or protect you from the rabid wolf, but the other five could do very much the same. And in most cases, you have far bigger security concerns than malicious firmware. Here's a free security lesson: If I want to take control of your machine, I'll use the easiest route; that won't be malicious firmware. Oh, btw...if I recall properly, a lot of CPU security fixes are distributed as firmware microcode updates that have to be loaded by the OS. So... being inappropriately paranoid about firmware could compromise your security. Nick.
Re: Kernel relinking on old boxen at every boot
On 2020-05-25 11:35, ULF wrote: ... > My question is: > > considering that an opt out option has been already turned down, could at > least old architectures be benefited of a "delay" option e.g. like tune2fs > sets a fsck every n-th boot, could KARL, just for very old machines be > tuned, say, to be applied every 10/20 boots? oh, please no. So you want my old machine to USUALLY boot in a minute or so...but once in a while, you want it to take many times that long with no real warning that "don't panic, this reboot will take many times the usual amount"? No...we got Linux machines that do that...very horribly unpleasant. It also disables the primary advantage of KARL -- If you find a way to tickle a bug in the OpenBSD kernel, PROBABLY the first result will be to crash the kernel (due to other safety things). You WANT it to come up on a different kernel NEXT TIME, not after a bunch more crashes while the attacker figures out how to turn a crash-bug into an exploit-bug.. If you really want to kill this security feature, don't pretend it's still there helping you...turn it off and know it's off. KARL is really easy to disable IF that's what you really want to do. You probably want to kill the library relinking, too (if your disks don't suck, I find the library re-linking more painful than the kernel relinking. If your disks suck (i.e., USB thumb drive), they are both painful). Also easy. I, toolike running old hw, but I'd rather OpenBSD be made as good as possible for modern stuff so people can do real work on it than to be crippled by trying to optimize for a bunch of us old hw collectors. We can disable KARL and library re-linking if we want to -- and that's how it should be, build for the productive masses, leave the edge cases to the nut-jobs like us. :) Nick.
Re: sysupgrade confused by additional disk?
On 2020-05-25 10:21, Why 42? The lists account. wrote: ,,, > At some point I added a second (larger) disk to hold my user data (i.e. > home). It seems that this new disk took over the name sd0 and the OpenBSD > system disk itself became known as sd1. yep. Things like that are where the duids came in. > The OpenBSD OS still boots and runs without issue, however this change > seems to have confused sysupgrade. After it downloads and reboots I now > get prompted to choose I)nstall, U)grade, etc. If I recall correctly, > this step used to run automatically without any intervention. Is that > right? While OpenBSD itself is great about using duids, those are defined in the 'a' partition of the boot disk..which is usually the first disk. But in your case, the "first disk" doesn't include the 'a' partitionand the /etc/fstab file...which is probably causing the upgrade kernel to choke. > My first thought was I could fix the issue by using sysctl to reassign > the disk name to uuid mapping (i.e. the hw.disknames values) ... No, that won't work -- the disks are assigned at boot. > Any other suggestions as to how to fix this? > > Thinking some more about it, shouldn't sysupgrade just use those very > disk uuid values to identify its targets in the first place ... thus > avoiding the whole issue in the first place? think about that a moment. You are running OpenBSD. You run sysupgrade, it pulls down all the new tgz files. And it ... REBOOTS. I think you are asking that the old kernel passes info to the newly rebooted kernel. It's probably doable, or could fail earlier to let you know you have a problem, but I'm driving myself batty thinking about the multi-platform and edge cases. The best solution for YOU I can think of would be to put a small 'a' partition on your sd0 for root, and have your system boot from that, but use sd1 for all the rest of the system file systems. Or just do traditional upgrades. Nick.
Re: EFI boot on Dell PowerEdge R610
On 2020-05-28 05:15, Johan Hattne wrote: > On 2020-05-28 00:56, Johan Hattne wrote: >> On 2020-05-28 00:43, YASUOKA Masahiko wrote: >>> Hi, >>> >>> On Wed, 27 May 2020 22:32:58 -0700 >>> Johan Hattne wrote: I've been trying to boot the 6.7 installation media from USB via EFI on a Dell PowerEdge R610. The screen goes blank and then the thing resets (so no kernel output or anything). I can boot the same stick via BIOS. I've been searching for a while without results. Firmware settings look sane to me. Is this something anybody has seen before? Any hint on where I could even start looking for problems would be very much appreciated! >>> >>> I'd like you to try the diff attached with the following message. >>> >>> https://marc.info/?l=openbsd-tech&m=158280719421562&w=2 >> >> Thanks a lot, Yasuoka! Is there any chance you could provide a compiled >> BOOTX64.EFI? I don't have an amd64 build environment at the moment. > > After a bit of off-list discussion, Yasuoka concluded that above diff > won't help here. To clarify the issue: there is no output at all before > the machine resets, in particular there is no prompt from the EFI boot > program. > > // Johan > Have you tried firmware updates? That machine is many years old, I'd not be the slightest bit surprised if the firmware was buggy and didn't boot much of anything in EFI mode other than Windows and maybe Linux. Nick.
Re: Mounting encrypted drive on boot
On 2020-06-02 19:27, Chris Narkiewicz wrote: > My setup consist of OpenBSD 6.7 with full drive encryption using > softraid, configured as described in FAQ: > > /dev/sd0a - encrypted volume > /dev/sd1 - decrypted > > I have additional need to mount an encrypted /var volume on boot. > This volume is separate drive attached to be VPS "machine". > > I want to mount this drive automatically on boot by adding > relevant entries to /etc/fstab, but before this can be done, > softraid device must be configured using bioctl. I don't think there is a good answer to your question *as asked*, so we just have to come up with a new question and solve your problem. :) I am GUESSING your real problem is "I didn't make /var big enough" You can add a second disk. And you did. I would look closely at what partitions you have on /dev/sd1c. Got a /home? Move that to your second drive, move the /var to your old /home. Or..what is the real problem with /var? Maybe /var/www? Move THAT to your second drive, leave /var (which is kinda important on boot for a lot of reasons!) on sd1. But in general, work out a way to keep /var on your primary boot drive, and put something that isn't needed in the first moments of boot on the secondary drive. Some other ideas that could be moved: /usr/local /usr/src /usr/bin /usr/ports /home Most of those would provide a good basic /var If you over-built some other partition, copy the data off, make it smaller, reload, and use the freed space for a /var. Nick.
Re: OpenBSD Readonly File System
On 2020-06-11 12:07, Strahil Nikolov wrote:
> I always thought that 'sync' mount option is enough to avoid
> corruption of the FS. Am I just "fooling" myself ?
As "sync" is the default...yes, I think you are.
File systems are complicated. Making them work robustly is even
more complicated. And the ways hardware (including power) fails
is often difficult to comprehend from a high-level language
standpoint ("I just wrote fifty bytes to the end of the file,
what's the big deal?"). All things considered, FFS works
amazingly well.
Back to the OP's question -- I'm curious why he's having trouble
I just don't have. The vast majority of the time, my firewalls
and other OpenBSD systems just come back on their own without
intervention. When I'm moving or otherwise maintaining an
OpenBSD system, I often just yank the power cord and let the
thing fsck itself on reboot. I'm not going to say it ALWAYS
comes back without intervention, but I'd guess well over 90%
of the time, they just come up without help.)
So... I'd look at what's going on more than try to change the
basic operation of OpenBSD. Why are you writing to disk so much
that your file systems end up being trashed?
Some ideas I'd try before making a Franken-system:
* Log to another system over the network via syslog so less
writing happens locally.
* use the noatime mount option -- that reduces a lot of
unneeded writes.
* Faster disks -- How about a small SSD? They spend less
time writing, and often have enough on-board capacitance to
complete writes after a power interruption.
* experiment with softdeps. Supposedly, it helps keep the
/FILE SYSTEM/ consistent. My experience is it tends to
truncate files on unexpected power-downs, but in MOST cases,
I'd rather have a zero byte file that has obviously been
mangled than one that looks ok. I almost always use softdeps,
maybe that's why my systems almost always come back after a
power interruption?
I have no hard facts to back up any of those helping a
system come up on its own after a impolite powerdown, but
they all seem like they might. And I do most of them, and
my results seem to be better than the OP's, so maybe?
Nick.
Re: OpenBSD Readonly File System
On 2020-06-13 12:56, Todd C. Miller wrote: > On Sat, 13 Jun 2020 12:12:05 -0400, Nick Holland wrote: > >> On 2020-06-11 12:07, Strahil Nikolov wrote: >> > I always thought that 'sync' mount option is enough to avoid >> > corruption of the FS. Am I just "fooling" myself ? >> >> As "sync" is the default...yes, I think you are. > > Actually, by default only metadata is written synchronously. The > "sync" mount option causes data to be written synchronously too. > Of course, the disk *itself* has a cache so even with synchronous > writes you can't be sure the data has actually made it to the platter. > > So yes, I agree that sync mounts are not really enough to help here. > You are probably correct that softdep is better for this kind of > thing since it does a better job of keeping the filesystem in a > consistent state, at the cost of missing data when there is an > unclean shutdown. In theory, the on-device cache can still cause > issues when you lose power though. Thanks for the correction! The really embarrassing thing is I even checked the man page, but started from the incorrect assumption that "async" and "sync" were the only two choices and read what I expected, not what is actually on the page. Nick.
Re: Suggestions re error: "USB read failed" accessing Infinite Noise TRNG?
On 2020-06-23 06:20, Why 42? The lists account. wrote: > > Hi All, > > Has anyone ever tried the Infinite Noise TRNG hardware random number generator > with OpenBSD? Actually...no. Never felt any reason to. > It's a USB stick that contains hardware to generate random numbers. See: > https://github.com/13-37-org/infnoise > > I had a couple of these working with ArchLinux and would like to try using > them with OpenBSD. > > Using either 6.6 or 6.7 the device is recognised at boot time: >> uftdi0 at uhub0 port 2 configuration 1 interface 0 "13-37.org Infinite Noise >> TRNG" rev 2.00/10.00 addr 3 ucom0 at uftdi0 portno 1 so ... looks like is is pretending to be a serial port. ucom0. ... > With libftdi1-1.4p2 installed I was able to compile the associated software > using the supplied "Makefile.freebsd". So a pretty easy start ... FreeBSD? I'd be more surprised if this worked than if it didn't. > This creates an executable "driver" called infnoise which can be run as a > daemon e.g. "driver" that runs as a "daemon". I'm not entirely sure what that would mean, to be honest. >> doas ./infnoise -h >> Usage: infnoise [options] ... >> -s, --serial - use specified device ^^^ Might want to play with that option. Or not. ... > Any suggestions? Where am I going wrong? Maybe I shouldn't have taken that > shortcut with the freebsd makefile? Or a security issue? First of all..what are you wanting this thing to do? Provide random data? how about just reading /dev/cuaU0? And then...why not just use /dev/random? Or are you wanting this device to contribute to the OpenBSD random number generator by stirring the entropy pool? Are you expecting this /FreeBSD/ driver to reach into the /OpenBSD/ entropy pool and give it a good stir directly from ... userland? That sounds a bit scary. However, I'd start by questioning the basic premise that OpenBSD needs more entropy to seed its random number generator. The OpenBSD developers have spent a lot of time (and written some really good descriptions) on the topic. Many DIFFERENT things in OpenBSD *use* random numbers (so even if you knew what the next "Random" number returned was going to be -- you don't know if what task will be the one getting it!) and many DIFFERENT things in OpenBSD agitate the entropy pool (so you aren't likely to know what the next number returned will be), so you don't stand much of a prayer of predicting the next result from a call to /dev/random. Not only is the PRNG well stirred, a lot of modern hw has on-chip true RNG noise sources which do basically the same as your little USB plug, and OpenBSD uses at least a few of them. Combine that with a lot of "incredibly difficult to predict" things like hardware I/O and lots of /dev/random data being used by things OTHER than your app...I really doubt you will find much benefit to adding an external noise source to OpenBSD. Nick.
Re: Dual boot problem
On 2020-06-27 21:50, Greg Thomas wrote: > Hey folks, I'm trying to avoid buggin y'all, but I'm down to my last two > tasks, setting up dual boot with Windows 10 and setting up OpenVPN. I'm > currently trying to troubleshoot "Loading ERR M" while using Windows > BCD. I can boot no problem when selecting my boot drive while starting up > my Thinkpad X220. > > I installed a couple of weeks ago using pretty much all defaults. ... > nihilanon# fdisk sd0 > Disk: sd0 geometry: 121601/255/63 [1953525168 Sectors] > Offset: 0 Signature: 0xAA55 > Starting Ending LBA Info: > #: id C H S - C H S [ start:size ] > --- > 0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused > *3: A6 0 1 2 - 121600 254 63 [ 64: 1953520001 ] OpenBSD I'm not seeing a windows partition here. And it appears your OpenBSD partition is using the entire disk. Oh. Your computer has three disks in it...your Windows install is on a second/third disk? I don't think that is going to work. from your dmesg: sd0 at scsibus1 targ 0 lun 0: naa.5000c500b98a130c sd0: 953869MB, 512 bytes/sector, 1953525168 sectors, thin sd1 at scsibus1 targ 1 lun 0: naa.500a07510369b769 sd1: 488386MB, 512 bytes/sector, 1000215216 sectors, thin sd2 at scsibus1 targ 2 lun 0: naa.5002538844584d30 sd2: 244198MB, 512 bytes/sector, 500118192 sectors, thin ERR M basically means that biosboot(8), which is "tagged" with the physical location of /boot(8) on the disk, doesn't see the marker that indicates that what it is pointing at is actually /boot. The windows 10 boot loader is pulling from a disk other than sd0, the pbr is pointing at something "correct" if it were sd0, but the Windows boot loader is trying to pull it from whatever the new default disk is. Maybe. There may be some bcdedit magic that can say "boot from this other disk" which might solve your problem, but I have no idea. A lame way of doing this might be to shrink your Windows partition by 1G, and install your OpenBSD root partition there, and the rest on sd0. Nick.
Re: nsd Will Not Start At Boot
On 2020-07-07 15:28, ken.hendrick...@l3harris.com wrote: ... > Unbound is still not working. > > I have a hunch, but cannot find it in the man pages, > that somehow they have to talk to each other. Is this true? depends on what you want them to do. A DNS resolver and an authoritative DNS server are two different things. You may want your resolver to talk to your server for some applications, other times, no. I.e., exactly like two people in a room. Maybe they have NEED to talk, maybe they shouldn't talk to each other. Getting the job done properly depends on picking the right model. :) > I tried a very simple unbound.conf file, and it didn't work. > The very simple config file was from [snip] The unbound config file that ships with OpenBSD Just Works as a stand-alone resolver listening on localhost. Start there. THEN make your changes you need. > Any ideas? Any help? What should I be reading?? Unfortunately, the classic texts on DNS usually are based on ISC BIND, which horribly munges the roles of authoritative DNS and DNS resolver into one unified application, so going from there to separated functions is difficult. I learned the separated model from Dan Bernstein's website, but in looking it over, unfortunately, it is very much based on his DJBDNS package, which is brilliant, but unmaintained for the last 15+ years and no longer compatible with many modern Internet "features" everyone expects today, and uses its own file formats, which were great, but not a standard way to communicate DNS info. http://cr.yp.to/djbdns/separation.html Still...most of his points are valid, and he's worth a read. Everyone's favorite error: Your DNS resolver has to bind to an IP address. Your authoritative DNS server has to bind to an IP address. They both listen on port 53 (UDP and TCP). You can't connect both your server and your resolver to the same IP address. Won't work. First gets it, second gets a port in use error. But remember -- extra external IP addresses on your server are easily added, and your machine has a huge number of potential localhost addresses (127.0.0.0/8) for internal use. Between those and PF, you can pretty well make any kind of magic I've ever thought of. Nick.
Re: mfs reported full, but empty
On 2020-08-19 17:47, Vincent wrote: > Hello, > > > After several days, I have to reboot my machine because of mfs full. This is > not the first time. > I have few mfs on this machine, but I observe that this is always a full > filesystem on /tmp after +40 days of uptime. > But on other mfs, I have very low filesystem activity. > > > Am I the only one having such problem ? yes. and no. :) Normal Unix Behavior, and nothing to do with MFS. (I think) (for the record, I use mfs extensively some systems I run that get a significant benefit from it, have done so for many many years. Only problem I've ever run into is being that MFS systems shine when for with lots of tiny files, it's the ONLY time I've ever run out of i-nodes before running out of disk space. Not really an MFS problem, of course.) ... > obsd-fw/tmp# du -h /tmp > 1.0K /tmp/.X11-unix > 1.0K /tmp/.ICE-unix > 1.0K /tmp/vi.recover > 11.0K /tmp > obsd-fw/tmp# df -h /tmp > Filesystem Size Used Avail Capacity Mounted on > mfs:71474 991M 991M -49.5M 105% /tmp > obsd-fw/tmp# uptime > 7:22PM up 57 days, 17:58, 1 user, load averages: 0.08, 0.16, 0.15 > obsd-fw/tmp# ps aux | grep mfs > root 71474 0.0 12.4 1049016 1016980 ?? S 22Jun20 1:25.23 > /sbin/mount_mfs -o rw -s 1024m swap /tmp see... "du" and "df" show two different things. "df" shows how much unallocated space you have. It's very accurate. You can create a file as big as "df" shows you have available. "du" shows how much space normal files have taken up. It's also very accurate. It will show you how much space will be freed up if you delete those files. However, you can have Unix do some seemingly strange stuff, at least strange for those of us who cut our teeth on single-user systems. Unix lets programs do funny stuff, like delete an open file. That removes the file handle (what "du" looks at), but does not release disk space (what df looks at) until ALL tasks that have it open, close it. (man 3 unlink In fact, I'm pretty sure one task can create a file, open it, unlink (rm -- but the name there is wonderfully descriptive -- remove a link (the directory entry) from a file) it, and then write and read temp data to that file...and one can continue to do that until the task exits...look ma, self-cleaning tmp files! I'm pretty sure something like that is happening with you. I was able to reproduce your "problem" easily. I have a little machine here that has a 100MB /tmp, I created a 70MB text file, and tried to edit it with vi. Well...vi quickly discovered it couldn't create its vi.recover file, /tmp showed 100% utilization, but "du" could not show me where the last ~27mb of disk space went. As soon as I exited vi, the space came back. One big clue: since you are hitting 105%, that means the offending process is running as root -- I could only take /tmp to 100% as a non-root user, but if invoked as root, 105% (as expected). So the first lesson is, whatever you are doing, 1G /tmp is not big enough. Probably more scary, though -- you have a root process spewing lots of data into /tmp. I don't normally see that...so I'm inclined to think you are running something incorrectly or "solved a problem" by running it as root. Might be totally legit and just needs more tmp space, but my very first thought is "YOU ARE DOING SOMETHING WRONGLY!" Next time you see this happen, before rebooting, ps -aux and look at all your root processes and kill them one by one until you suddenly see your disk space come back. That was your offender. Nick.
Re: system slow down strangeness
On 2020-09-08 04:16, Gregory Edigarov wrote: > Hello, > > from around two weeks ago I am observing the overall system slow down. > Everything work stable, > but nearly every X application takes forever to open a window. > also I am using tiling wm, and when workspace is switched, > it takes a long time for the system to redraw a screen. > I also noticed that some console scripts like ansible-doc > are also starting slower then usual. > > this system only has 8 Gb RAM temporarily, > but top says: > > Memory: Real: 1764M/5673M act/tot Free: 2183M Cache: 3284M Swap: 0K/32G > > so I do not think it is a memory issue. > > was just fine before, so wondering what has happen. > OpenBSD 6.8-beta (GENERIC.MP) #59: Fri Sep 4 22:46:14 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP well...that's less than two weeks old. So I'm guessing either you had the problem and figured, "let's upgrade, see if that fixes it" (not a bad plan), or you are a regular upgrader (also good). Can you say if the problem started with an upgrade? Or did it occur between upgrades? ... > sd0 at scsibus1 targ 0 lun 0: Any possibility you have a bad disk? A few times in my life, I have seen a bad disk that would have issues reading from the drive, but succeed after a few retries, before it threw an error back to the OS. It would then reset its retry counter, and have the same problem on the next read...and the one after that. Result: horrible performance, but it "worked". (granted, I've been doing computer support for almost 40 years now and I can think of two cases of this happening that left me scratching my head for a long time, and maybe a couple others similar to this that I don't recall so vividly, so not exactly a common problem...but not unheard of, either.) ... Nick.
Re: Case of the missing softraid
On 2020-10-03 17:45, tera torn wrote: > Hello, > > I've been a happy user of OpenBSD softraid RAID 1 mirroring, and I'm > attemtping to migrate data off of a degraded RAID 1 mirror. > > I've booted before from the 6.7 install USB (amd64) and this degraded > chunk was detected and the volume was brought up and my data was > there. > > I'm not sure what's happened but now when I boot the same media I'm > unable to detect the softraid volume. > > softraid0 is listed by the kernel, but no additional sd device is > configured for the softraid volume. That is always shown, whether softraid is used on the system or not. > Is there a way to debug this? or detect or correct disk corruption so > that this chunk is properly recognized again? The dmesg will give some clues as to what is going on. Hopefully, for Some Reason, the drive just isn't showing up to the machine, the dmesg will show that. Next step, if it is in the dmesg, see if you can get an fdisk and disklabel out of it...does that look sane? > Can the chunk be manually mounted as an ffs volume? it should still > contain a normal ffs filesystem somewhere right? kinda. But rebuilding that would probably be more work than fixing the real problem. > Looking for any way to recover the data in this chunk! Any help > greatly appreciated. I think you need to start with figuring out WHY the volume vanished. Let's hope it's an electrical or mechanical problem. Nick.
Re: Startx doesn't find screens
On 2020-10-25 10:35, d.verdi wrote: > Hi to everybody, > I'm facing this problem after the complete installation of OpenBSD 6.7: > if I try to launch startx, an error occur and tells that "no screens found". ... > The Xorg.0 log file content is the below: ... > Check that you have set 'machdep.allowaperture=1' > in /etc/sysctl.conf and reboot your machine > refer to xf86(4) for details MIGHT help. ... > [ 47.358] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support > [ 47.358] (EE) wsfb(0): no way to get depth info: Inappropriate ioctl for > device > [ 47.358] (II) UnloadModule: "wsfb" > [ 47.358] (EE) Screen(s) found, but none have a usable configuration. ... > The dmesg content is the below: thanks! > OpenBSD 6.7 (GENERIC.MP) #182: Thu May 7 11:11:58 MDT 2020 previous release... ... > vga1 at pci1 dev 0 function 0 vendor "NVIDIA", unknown product 0x0df8 rev 0xa1 > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ... > > Thank you very much for the support > Dav > One -- 6.8 was just released. Don't install an old release. Two -- you seem to have a board that hasn't been seen much in the wild by OpenBSD developers...and an nvidia at that. 6.8 *might* help with that. Or better, a snapshot. But if this is an add-in card, I'd suggest reinstalling it to your local trash can or maybe a windows machine and and getting a better supported, non-nvidia card installed. Nick.
Re: problem to copy a (possibly large) file over a network device
On 7/31/19 3:45 AM, Rudolf Sykora wrote: > Dear list, [probably irrelevant stuff snipped] > I actually wanted to do a backup of the subtree with rsync over the > network, but that didn't work, spitting sth. like > > rsync error: unexplained error (code 255) at io.c(820) [sender=3.1.3] > [sender] _exit_cleanup(code=10, file=io.c, line=820): about to call > exit(255) ... Well, that looks broke. Not supposed to do that. > As I have no idea what can cause this behaviour, I am asking for any > help. Well, looking at the version of OpenBSD that you are using ... oh. Well, your dmesg shows ... hmm. Looking at your rsync command line I see ... well... Your environment is ... hm. no idea about that either. Not much to work with you on here other than you got an error message you probably shouldn't have got. As for your follow up, no, there is no setting deliberately set to, "don't work properly" you need to change to "work correctly" in OpenBSD. Nick.
Re: Multiple video cards in X?
On 6/28/19 5:01 AM, Joe M wrote:
(yes, over a month ago...)
> Hello,
>
> I have multiple video cards (AMD Radeon) cards working with OpenBSD.
> I have 2 monitors connected to each card (HDMI and DVI ports).
>
> The issues are that I can use only fvwm and I cannot move x windows
> across the video cards. I can move x windows across monitors
> connected to the same video card though.
>
> I tried to hack around the Xenocara codebase to figure out if I can
> fix it. During my adventures, I realized that though Xenocara can be
> modified to support this, the issue is in the radeon driver
> (radeondrm, I think). At that point, I gave up as I did not have the
> bandwidth to figure out how radeondrm works.
>
> It took me quite a lot of time to figure out the correct
> configuration. I was hoping that I could get cwm to work. But, I
> could not. Only fvwm works. I did not bother to dig through why.
>
> joe:10114$ cat /etc/X11/xorg.conf
>
> # get the xorg.conf.firstcard and xorg.conf.secondcard to work #
> startx # uses xorg.conf # cd /etc/X11; start -- :1 -config
> xorg.conf.secondcard # to get the second card working # once both of
> them work, below is bringing them together to show all monitors at
> the same time
>
> # leave out the monitor sections as the X fills up the holes
>
> Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen
> 0" Screen 1 "Screen 1" RightOf "Screen 0" EndSection
>
> Section "Screen" Identifier "Screen 0" Device "Card 0" EndSection
>
> Section "Device" Identifier "Card 0" Driver "radeon" BusID
> "PCI:1:0:0" #Option "Monitor-HDMI-0" "HG281D" Option "Monitor-DVI-0"
> "AL2223W" EndSection
>
> Section "Monitor" Identifier "AL2223W" Option "LeftOf" "HDMI-0"
> EndSection
>
> Section "Screen" Identifier "Screen 1" Device "Card 1" EndSection
>
> Section "Device" Identifier "Card 1" Driver "radeon" BusID
> "PCI:11:0:0" EndSection
>
> joe:10131$ tail -5 /home/j/.xsession
>
> # cwm cannot spawn multiple cards # exec /usr/X11R6/bin/cwm exec
> fvwm
>
> Hope it helps.
Quite a bit, if nothing else, just gave me hope and a starting
place!
Here's what I ended up with as a MINIMAL xorg.conf that seems to work
for me, with the same quirks you describe:
==
Section "ServerLayout"
Identifier "Default Layout"
Screen 0 "Screen 0"
Screen 1 "Screen 1" Above "Screen 0"
EndSection
Section "Screen"
Identifier "Screen 0"
Device "Card 0"
EndSection
Section "Screen"
Identifier "Screen 1"
Device "Card 1"
EndSection
Section "Device"
Identifier "Card 0"
Driver "radeon"
BusID "PCI:3:0:0"
EndSection
Section "Device"
Identifier "Card 1"
Driver "radeon"
BusID "PCI:4:0:0"
EndSection
==
I added some monitor sections and not only did it work exactly
as it does with this, I couldn't make it do anything better or
different.
Key parts:
* the BusID lines seem critical. Otherwise, just get first card.
* a "Screen" appears to be all monitors attached to one Device.
* My primary video card ("Screen 0" is attached to two monitors
on my desk, the secondary video card ("Screen 1") is attached to
two monitors above them. Hence, the "Screen 1" Above "Screen 0"
I found Fluxbox seems to work with all four monitors as you
described fvwm doing. The mouse can move appropriately between
all four monitors, but tasks can only go side-to-side in one
"screen" (two monitors). This, I was actually excited about, as
I wanted to be able to have multiple INDEPENDENT desktops between
monitors. Ok, I got it between PAIRS of monitors. Doesn't suck.
What DOES suck is some of the apps I wanted on both screens...don't.
Firefox and Chrome both refuse to start a new instance in the other
screen. Not the end of the world, there are more browsers out there,
I suspect I can run iridium or something similar in one "screen" and
a cousin in the other.
My "screens" are slightly dissimilar -- screen 0 is two 1920x1200
monitors, screen 1 is two 1920x1080 monitors. No issues noted.
The login box and the ssh key box are centered between two monitors.
Annoying, but not a show stopper. In general, while two monitors on
one card seem
Re: Recommended web and database server specification
On 8/14/19 9:20 PM, Aaron Mason wrote: > Hi Tito > > Can you tell us more about the database? How often will its data be > changed, added to, etc? How much data do you have? How complex are > your DB queries? These answers will help determine the RAM and > processor requirements for the database. > > As for the web server daemon itself, I think Reyk Floeter would be the > best placed to answer that question - also paging Nick Holland for > more hardware expertise. > > On Thu, Aug 15, 2019 at 12:57 PM Tito Mari Francis Escano > wrote: >> >> Hi to everyone at misc, >> >> I'm recently working on an OpenBSD-based PHP7 web application with >> PostgreSQL-backend for a local government agency and was wondering what >> would you recommend as the acceptable server specification. This web >> application won't reach the Google or Facebook level of visits per day, >> but I was hoping to prepare this be deployed and run for quite a long >> time and ready for about 60,000 visits per day at most. >> >> Your advise and recommendation would be greatly appreciated. Thanks so much. heh. got called out, doesn't take much to make me start talking. :)
Re: Recommended web and database server specification
On 8/14/19 9:20 PM, Aaron Mason wrote: > Hi Tito > > Can you tell us more about the database? How often will its data be > changed, added to, etc? How much data do you have? How complex are > your DB queries? These answers will help determine the RAM and > processor requirements for the database. > > As for the web server daemon itself, I think Reyk Floeter would be the > best placed to answer that question - also paging Nick Holland for > more hardware expertise. > > On Thu, Aug 15, 2019 at 12:57 PM Tito Mari Francis Escano > wrote: >> >> Hi to everyone at misc, >> >> I'm recently working on an OpenBSD-based PHP7 web application with >> PostgreSQL-backend for a local government agency and was wondering what >> would you recommend as the acceptable server specification. This web >> application won't reach the Google or Facebook level of visits per day, >> but I was hoping to prepare this be deployed and run for quite a long >> time and ready for about 60,000 visits per day at most. >> >> Your advise and recommendation would be greatly appreciated. Thanks so much. Dang, somehow, I've got a bad habit of hitting CTRL-ENTER at the end of lines, and that's "SEND" on some mail clients. Did that twice in the 24 hours on two different mail clients. sigh. ANYWAY... 60,000 hits per day isn't the question. Rarely does load come in evenly spread out, usual things are spikey -- after school, after work, before work, whatever. So the scaling question is "how many hits per second can you expect peak?" and "how much delay will your users tolerate at that peak moment?" And really, you need to test your own app in your own environment with your expected peak load. IF your bosses are insisting on "buy once for five years", you are going to horribly overspend. They are damn fools. But, they are also "The Boss", so you live by 'em. You will save a lot of money by buying something that will PROBABLY work for a year or so, and replace it *IF* it turns out to be undersized. If you want to do it right, take an old pc with a standard SATA disk, build it out as a web server, and load test it with your peak expected load with your application being used in a realistic way. If it works, get a faster server with more memory and use SSDs, and you will be in great shape. Nick.
Re: obsd web server
On 9/1/19 5:49 PM, Gustavo Rios wrote:
> Hi folks,
>
> i would like to confgiure my obsd server as a web server.
>
> I would like to configure my web server to handle multiple domains
> without having to set each domain one by one.
>
> I mean:
> Every request for www.x.com is mapped into the root directory
> /var/web/www.x.com
>
> Got the idea ? If a new server is required, All i needed to do would
> create a directory inside /var/web with the full access string :
>
> mkdir /var/web/www.newdomain.com
>
> And i should not need to manipulate config files.
>
> Thanks in advance
I don't think that's doable as you request, nor do I think it is a
noble goal. , Unless you have a really really unusual use case, you
will have per-site specific settings -- for example, HTTPS
certificates.
HOWEVER, with some trivial scripting, you can easily accomplish something
that appears to be what you request. When you have a lot of similar
things to manage, think scripts. :) Here's a primitive and untested
concept:
newweb:
#!/bin/ksh
mkdir -m755 /var/www/$1
chown (whomwever) /var/www/$1
cat >>/etc/httpd <<__ENDSITE
server "$1" {
alias "www.$1"
listen on $ext_addr port 80
log style combined
log access $1.access
log error $1.error
root /$1
}
__ENDSITE
/etc/rc.d/httpd reload
Now, in real life, you would want to flesh out that config a bit
more, and you would probably want to save a copy of the httpd.conf
file, and check if httpd errored, and if so, restore the old copy.
Lots of other error checking would be appropriate as well.
You could also just do something more sophisticated, like create
an httpd.d directory and create a template domain.conf file in
there for each one, and just add an "include" line in your
httpd.conf for each new domain. Now when you decide that all your
domains are NOT just alike, you can easily rev the ones that are
different.
Nick.
Re: handling snapshot installation in production environment
On 9/2/19 6:48 AM, Marcus MERIGHI wrote: > Hello Joerg, > > just passing on my user experience...: > > streckf...@dfn-cert.de (Joerg Streckfuss), 2019.09.02 (Mon) 10:15 (CEST): >> Furthermore I'm not sure which snapshot should I run. Almost every day >> there will be a fresh one. > > you seem to be watching closely, therefore you will notice a time when > there are no new daily snapshots for a couple of days. this is usually > when the next release is tagged/built. additionally you can monitor > ports@ to see when the ports tree gets locked for the next release. Careful with this ... While this is what I used to do (which is kinda odd, since I only run snapshots!), in recent releases, especially since the CD production was cut out of the release process, the time between "tagging" and resumed development and new snapshots has dropped a LOT to the point that it's difficult to catch. I think Ian's tip is a bit safer. Nick.
Re: authpf unable to exit ssh without control C
On 9/15/19 7:31 AM, shadrock uhuru wrote: > hi everyone > i can login with authpf but unable to exit or control D out of the ssh > session > the only way out is to control C which also kills any other ordinary ssh > user connected to the server > my authpf user has authpf as its login shell and login class, > is this normal behaviour ? > shadrock > If I understand your request, you want someone to log into your system, which brings up authpf, and you want them to be able to do something to exit to a shell prompt on that server and still leave the authpf rules in place? That's not the way authpf was designed. The idea is that when authpf is invoked, it activates certain rules, presumably regarding the IP address in question, and when authpf exits, it removes those changes. Connect to authpf, now you can access the web site, or FTP or whatever it is you need, terminate authpf, and no one else at your IP can do those things. If you are letting these same users access the shell prompt, your usage is not as paranoid as authpf was designed to deal with, it's probably not the right tool for the job, or your expectations are wrong. I run a private IRC server, which is blocked on the 'net by PF, but as all the users are people I know in real life and friends, I trust them to be able to activate their own IP addresses, so I just wrote a simple (and surely insecure) script to add that user's IP address to the PF table that permits them access to the system. What this doesn't do (and I'm not sure how you expect to do this) is clear the connections when they leave. In my case, I don't care -- the odds that after Fred gets a new IP address that his old IP address will end up in the hands of someone wanting to have access to my IRC server for malicious reasons (and they find it!) is pretty small. But that might not be your use case. If you need to close those openings...you had best think hard about how you expect that to happen. Nick.
Re: How can I remove sets installed by sysupgrade?
On 9/17/19 12:23 PM, Marc Espie wrote: > On Tue, Sep 17, 2019 at 02:31:59PM -, Stuart Henderson wrote: >> (To be clear, I think installing a restricted subset of the OS for >> security reasons is pointless here, but can be really helpful when you >> have to deal with limited space in partitions - and those just saying >> "storage is cheap" are ignoring the often very real cost of getting >> to the machine to replace the storage :) > > Ditto. > > We still run on somewhat cramped machines, and even replacing an SD card > with a bigger model might sometimes be an issue because of various reasons. > > ... or stuff with utterly outdated controler formats, where you may > get in situations that your SCSI3 disk buys it and that's it, no more > full installs for you. > Ditto followed by a single quote? We also work great on some really slow storage, like USB flash drives. Leaving out x*tgz, and compXX.tgz are big time savers when upgrading a flash based install. On the other hand, KARL and library randomization are also killing those solutions...so I guess it might be time to move on? Nick.
Re: How can I contribute code to openbsd
subject fixed, hopefully. :) On 9/28/19 7:05 PM, cc wrote: > > Hello, > > > I recently started to study openbsd. I am a computer major student. How can I > contribute to openbsd? > while ! dead; do DoSomething. submission="sucks" # Accept this. It's probably true. while [[ $submission == "sucks" ]]; do SubmitIt AcceptCriticism learn if [[ $criticism == "no way" ]]; do break # not everything is appropriate. fi reviseBasedOnCriticism done # Congrats, your submission was accepted! done # not dead yet. People usually screw up on accepting that their first submission sucks. And they really get confused when they are told what to fix and resubmit it, "why doesn't the committer just do it?" That's where the "learn" step comes in -- the committer is trying to help you get a point your submissions DON'T suck initially. Find something you want to fix or improve...do it, and enter the loop. :) Nick.
Re: A sad raid/fsck story
On 10/3/19 10:01 AM, sven falempin wrote: > Dear readers, > > I was running a OpenBSD (6.4) device, with a raid mirror array. > One of the disk failed, so the system ask me to fsck, Probably not quite that simple. More likely, the disk failed, that took the system down hard, and it needed an fsck on reboot. Which is normal, RAID or otherwise. > which I did before checking the raid status manually ( :'( ) , > THEN I rebooted and softraid told me: one of the hard drive is dead. > > But fsck already destroyed a few file on the mirror. that seems unlikely. that's not what fsck does -- fsck's job is to repair a file system. If it removes a file, the file is already damaged. > Probably a user error, nevertheless, In openbsd 'simply work' mindset, > maybe the /etc/rc could warn or even perform some bioctl check on raid > array when first fsck / mount > fails. I'm not seeing what this has to do with RAID, soft or otherwise. If your system needed an fsck, it needed it whether it was a simple drive or a RAID array. If you need an fsck, you are likely to have lost data. > ( Lost data recovered from backup ) And again...nothing to do with either fsck or RAID -- you have to have a backup. RAID doesn't change that. Nick.
Re: A sad raid/fsck story
On 10/4/19 8:37 AM, sven falempin wrote: ... > How [do I] check the state of the MIRROR raid array , to detect large > amount of failures on one of the two disk ? > > Best. > fsck has NOTHING to do with the status of your drives. It's a File System ChecKer. Your disk can be covered with unreadable sectors but if the file system on that disk is intact, fsck reports no problem. Conversely, your disks can be fine, but your file system can be scrambled beyond recognition; bad news from fsck doesn't mean your drive is bad. To check the status of the disks, you probably want to slip a call to bioctl into /etc/daily.local: # bioctl softraid0 Volume Status Size Device softraid0 0 Online 7945693712896 sd2 RAID1 0 Online 7945693712896 0:0.0 noencl 1 Online 7945693712896 0:1.0 noencl This is a happy array. If you have a bad drive, one of those physical drives is going to not be online. Nick.
Re: BACK TO BASICS
On 10/9/19 11:19 AM, openbsd.s...@0sg.net wrote: > Here's what I think. ...[bla bla bla]... > Amirite ? ;) I don't know. Let's see your work. I don't care what your theoretical arguments are, I want to see results. Nick.
Re: Misc i386 questions
On 10/13/19 12:39 AM, Sean Kamath wrote: > Doh! > > set tty com0 > > Alix is coming along OK now. Still have questions about i386 and > SCSI. . . > > Sean > > >> On Oct 12, 2019, at 23:13, Sean Kamath >> wrote: >> >> Hi. >> >> In my odyssey to get larger disks on my Alix machines, I bought >> some 16G CompactFlash cards. I put install65.fs on a card and tried >> to boot it on the Alix, but it just reboots after it loads the >> kernel. >> >> Meanwhile, the VM I used to dd the install65.fs file to the CF card >> is running 6.0, so figured I should update it (with a reinstall, >> rather than updates). I tried to boot bsd.rd and install 6.5, but >> it didn’t see the SCSI drive on the VM (but 6.0 did with no >> issue). I even downloaded install65.iso and tried to install on a >> brand new VM (VMware Fusion 11.5 on a Mac running Mojave) with a >> SCSI drive, but nope. IDE drives are seen just fine. >> >> So. . . did I just miss something about i386 and SCSI support? What SCSI hw are you emulating in your VM? What happens if you change that? And to be clear -- when you say it doesn't see the SCSI drive, how are you not seeing it (i.e., what did you do to "see it" and what was the result?). Nick.
misc@openbsd.org
On 2019-10-29 23:50, Clark Block wrote: > Will Theo de Raadt and other OpenBSD developer answer this topic ( [...link to drivel deleted...] What, are you looking for someone to provide comments on your term paper? Ok, You did cite a reference, not proper bibliography format. It's been a long time, but I thought they did teach proper citing of references in sixth grade. Bonus points for reading a book. Lost points for only one source. But nothing you have said qualifies as profound for anything above primary school level. Nothing indicates you actually KNOW anything about the topics you write. Dude. You post meaningless crap on this list and yet show no evidence of actually being an OpenBSD user. You think you have great ideas about how things should be done? Prove it. DO something. Don't talk about it. If your desire in life is to argue about the number of angels that can dance on the head of a pin or "best programming languages" or "desktop experience", please, go elsewhere. Nick.
Re: OpenBSD and solid state disks
On 2019-11-02 16:10, Raymond, David wrote: > I recently installed OpenBSD on a Lenovo X1 Carbon with a solid state > drive and it works great. yep. > My question is whether OpenBSD addresses the special characteristics > of solid state drives, especially those having to do with longevity > and reliability. Just Use them, and plan on replacing them when they need to be replaced, or at least demoting them to "when this fails, I won't cry" uses. In other words, treat them JUST LIKE EVERY OTHER DRIVE. If I hand you a five year old magnetic drive, would you put it in a mission critical application? Probably not. If you have five year old hardware in a mission critical application, you should be looking at replacement. Treat your SSDs exactly the same way, you will have no problems. Used very hard, SSDs last many years. Used like most people use a laptop, you will be replacing for other reasons (capacity, hw it is in is uselessly old, etc.) long before the drives wear out. The obsession with SSD write fatigue is silly. All drives can (and do) fail, you must have a plan to deal with that, and in my experience with SSDs, write fatigue is NOT the primary killer, it's just a predictable one. Nick.
Re: Home NAS
On 2019-11-17 11:39, Jean-François Simon wrote: > Hi, > > I found it, there exist glastree which is available from ports. > > Nice small "poor man's" backup as the author qualifies, > though makes incremental backup through hard links: > > # if yesterday does not exist or today is newer, copy the file > # else hard link the file to yesterday rsync --link-dest -- it's been in rsync for well over 10 years at this point. Little wrapper shell script and away you go... Nick.
Re: Deleting softraid Devices Fujitsu Sparc
On 2019-11-27 11:23, Kihaguru Gathura wrote:
> Hi,
>
> An error while deleting softraid device follows
>
> --
> Available disks are: sd0 sd1 sd2.
> Which disk is the root disk? ('?' for details) [sd0] ?
> sd0: FUJITSU, MAT3073N SUN72G, 0602
> serial.FUJITSU_MAT3073N_SUN72G_000506B00RAR_AAN0P5200RAR (68.4G)
> sd1: FUJITSU, MAT3073N SUN72G, 0602
> serial.FUJITSU_MAT3073N_SUN72G_000506B00SSL_AAN0P5200SSL (68.4G)
> sd2: OPENBSD, SR RAID 1, 006 (68.4G)
> Available disks are: sd0 sd1 sd2.
> Which disk is the root disk? ('?' for details) [sd0] !
> Type 'exit' to return to install.
> www# bioctl -d sd2
> bioctl: Can't locate sd2 device via /dev/bio
>
>
> The aim is to remove the device from the system and then:
>
> # dd if=/dev/zero of=/dev/rsd0c bs=1m count=1
> # dd if=/dev/zero of=/dev/rsd1c bs=1m count=1
>
> to reuse the disks.
>
> Thanks,
>
> Kihaguru
>
The install kernels have very minimal disk support. In the case of
amd64/i386, it's one wd device -- wd0, not sure about sparc64, but
I'd bet a cheap lunch that sd2 is not there. :)
After booting your install kernel, do this:
# cd /dev
# sh MAKEDEV sd0 sd1 sd2
or whatever you need to accomplish your task at hand.
NOW you will be able to do what you wish. Yes, the installer script
does this for you. And yes, this is a common issue regardless of
platform.
Nick.
Re: Installing OpenBSD -current snapshots
On 2019-11-27 21:29, Edgar Pettijohn wrote: > On Wed, Nov 27, 2019 at 08:05:30PM -0600, Clay Daniels wrote: >> I have successfully installed OpenBSD 6.6 release and would like to give >> the Current Snapshots a try. I went to a mirror, and to: >> >> Index of /pub/OpenBSD/snapshots/amd64/ >> >> I saw install66.fs (probably for usb memstick) and install66.iso (surely >> for a cd/dvd) at ~450Mb. I picked the install66.fs, wrote it to a usb >> thumbdrive, and it starts the install. When i get into the install it asks >> where are the file sets? Humm, maybe it gets these online and it tries to >> do this but no luck. It was late last night, and I checked to see if it had >> written anything to my disk, which it had not, and went to bed. This >> evening I'm looking a bit deeper at the snapshot directory and I suspect I >> need to provide the install with base66.tzg at ~239Mb. NO! [snip misleading stuff] > I noticed this also, but hadn't had time to figure out if I had messed up or > the installer had. As a general rule I assume its me that messed up. Its odd > if you mount the install66.fs you can see the pub/amd64 directory, but during > installation it can't seem to find the directory regardless of what I have > tried. > > Edgar First of all...nothing at all to do about snapshots -- the OpenBSD installation process has remained amazingly stable over the last 20 years. New options here and there, but overall, very similar. Unless something changed in the last few days, installing a snapshot is identical to installing 6.6. The installXX.iso and installXX.fs are complete, stand-alone installation kits. Everything you need is on them. You can boot from them, and all the installation files are right there. Look Ma! No network needed! ...well...unfortunately there is the issue of firmware files, which are legally not feasible to put on the install media, so you will need network for most machines eventually. But let's ignore that for now. :) Once the system has booted on the install kernel, you have three devices you are working with: 1) the install kernel's internal "RAM disk" that is part of bsd.rd which you booted from, 2) your target disk 3) the USB drive with the install files on it. The reason you can't see the install files on the USB stick from the install kernel is they aren't mounted. You didn't boot from the entire USB stick, you booted from ONE TINY LITTLE bsd.rd file, that just happened to be sitting on the big USB stick...but as far as bsd.rd is concerned, the USB stick isn't part of the booted environment (yet). You aren't booting from a "Live Media". You are booting from a tiny kernel with a built in file system that's sitting on the same inert file system as the install files. Read that over and over until you understand what I'm saying, not what you are assuming is going on. It's really important to understand. It's very different from many Linux installation processes -- you are running off a file only 10MB in size which is now completely in RAM. That file JUST HAPPENED to come from a USB stick that's much bigger. So, when it comes to answering where your install files are, they are on a disk, but it's NOT a mounted disk. It's on your USB drive that's not mounted now, and won't be after installation, but could be useful shortly. Your next problem is...WHICH disk? On a minimal system, it would be the next sd device after your install disk -- assuming you are installing to sd0, your USB stick might be sd1. HOWEVER, if you have a flash media reader on your system, who knows where it is. One trick would be to unplug your USB drive and plug it back in and look at the white-on-blue console message that come up at you. Yes, you are unpluging your boot device, sounds bad, but read what I wrote earlier, it's no longer using that -- the boot has completed, and it's running from RAM now, it's completely ignoring that USB drive. So let's say you do this and you see it's sd4. Tell the installer the files are coming from a file system not currently mounted and when it asks, tell it "sd4" Nick.
Re: Installing OpenBSD -current snapshots
On 2019-11-29 02:26, Clay Daniels wrote: > Nick, thanks for straightening me out about what is actually going on here > with the install. I see that there is now a fresh snapshot with today's > date, not the one I downloaded and ran yesterday. This might tend to keep > one busy. I'm not sure I would not be better off doing what Bruno & Marc > suggested and run sysupgrade. Thanks to them for the advice. sysupgrade does upgrades of existing systems. Very slick. However, it isn't for fresh installs, and if you have convenient console access, it's not the preferred way of doing it. And based on the questions here, NO WAY. You need to understand what's going on before you start doing unattended upgrades. It also (by default) assumes network upgrades, and if you are wanting everything on local media, there are existing better solutions. And yes, following current is a never-ending quest. However, problems are relatively rare and usually not a big deal, and generally fixed on the next snapshot. > If I do decide to put the filesets on the the install thumbdrive, I see a > total of 26 files in the directory. Obviously some are not necessary like > the floppy or both the .fs & .iso (just one needed), nor the test > instructions, etc. > So which files do I REALLY need on my usb thumbdrive to get a complete > install, x included? STOP STOP STOP STOP. You need to re-read what I wrote and the install part of the FAQ some more times. The install66.fs file is an image with the *entire install set included*. You do not want to add things. You COULD do some voodoo to add stuff to the miniroot66.fs, but PLEASE DON'T...you would just be re-inventing the install66.fs, poorly and with more difficulty. > > Please excuse the "top-posting". That's the only way my darn google mail > does reply's. Kind of irritating, to me and the reader too. Bottom posting was invented for those who can't write in complete thoughts with context. You know, like most of the computer world. :-/ Nick. > Clay > > > > > On Thu, Nov 28, 2019 at 12:34 PM Nick Holland > wrote: > >> On 2019-11-27 21:29, Edgar Pettijohn wrote: >> > On Wed, Nov 27, 2019 at 08:05:30PM -0600, Clay Daniels wrote: >> >> I have successfully installed OpenBSD 6.6 release and would like to give >> >> the Current Snapshots a try. I went to a mirror, and to: >> >> >> >> Index of /pub/OpenBSD/snapshots/amd64/ >> >> >> >> I saw install66.fs (probably for usb memstick) and install66.iso (surely >> >> for a cd/dvd) at ~450Mb. I picked the install66.fs, wrote it to a usb >> >> thumbdrive, and it starts the install. When i get into the install it >> asks >> >> where are the file sets? Humm, maybe it gets these online and it tries >> to >> >> do this but no luck. It was late last night, and I checked to see if it >> had >> >> written anything to my disk, which it had not, and went to bed. This >> >> evening I'm looking a bit deeper at the snapshot directory and I >> suspect I >> >> need to provide the install with base66.tzg at ~239Mb. >> >> NO! >> >> [snip misleading stuff] >> > I noticed this also, but hadn't had time to figure out if I had messed >> up or >> > the installer had. As a general rule I assume its me that messed up. Its >> odd >> > if you mount the install66.fs you can see the pub/amd64 directory, but >> during >> > installation it can't seem to find the directory regardless of what I >> have >> > tried. >> > >> > Edgar >> >> First of all...nothing at all to do about snapshots -- the OpenBSD >> installation process has remained amazingly stable over the last 20 >> years. >> New options here and there, but overall, very similar. Unless something >> changed in the last few days, installing a snapshot is identical to >> installing 6.6. >> >> The installXX.iso and installXX.fs are complete, stand-alone installation >> kits. Everything you need is on them. You can boot from them, and all >> the installation files are right there. Look Ma! No network needed! >> ...well...unfortunately there is the issue of firmware files, which are >> legally not feasible to put on the install media, so you will need network >> for most machines eventually. But let's ignore that for now. :) >> >> Once the system has booted on the install kernel, you have three devices >> you are working with: >> 1) the install kernel's internal "RAM disk" that is part of bsd.rd which >> you booted from, >
Re: Softdep and noatime
On 2019-11-30 08:12, Raymond, David wrote: > I am switching to OpenBSD from Linux and I have questions about the > use of softdep and noatime in mounting disks. I have a variety of > systems with a mix of SSDs and rotating disks. > > Softdep seems to have some advantages in speeding file access, but it > is not the default. Are there any downsides in using softdep? it's more complicated, and thus, will have more bugs. My personal experience: I'd trust softdep more than any modern Linux filesystem, BUT its still more complicated, and thus will have more bugs than the default FFS. > On SSDs in particular, is it worth setting noatime to reduce the > number of disk writes? Nothing to do with SSDs, as your quest to minimize writes on SSDs is demonstrated stupid and pointless. SSDs fail much more often for reasons other than write fatigue, Optimizing for write fatigue is like protecting your ship against icebergs hitting the propeller. VERY VERY few applications use atime, and yet, it requires an update to the directory for EVERY SINGLE ACCESS. Ouch. So, it's a non-trivial performance gain if you turn it off. That's a great reason to turn it off. Not SSDs. HOWEVER...if you don't need performance and you can't point to a real benefit, as always, keep it on the default. Nick.
Re: Third server now locked up after reboot due to no keyboard attached
On 2019-12-14 14:28, Alfred Morgan wrote: > I have now another machine running OpenBSD not recover from a reboot. I > thought I was having hardware issues with my two other servers (both zbox) > and now this third one (Dell) with totally different hardware is having the > same problem getting stuck at the boot> prompt. The problem goes away and > boots continue normally if I attach a USB keyboard in all three cases. I > feel like this problem started showing up around OpenBSD 6.4. Is this a > known issue? certainly not a universal issue...(i.e., I haven't experienced it) > When there is no keyboard attached the boot> prompt shows a box with a > question mark in it looking like an unknown character. Picture showing this > on bootx64 3.46: > https://photos.app.goo.gl/7HAqQic6GArLGzaXA Well...yeah. If the boot loader echoed anything, it's behaving As Desired -- a char at the command line means "STOP ALL BOOTING, I have something special I want you to do". The boot loader is entirely depenedent upon the firmware (BIOS), the kernel isn't loaded, OpenBSD isn't running. There's not a lot that OpenBSD can do about this -- the boot loader could "eat" all chars sitting in the buffer, but that would make interrupting the boot process just a little more difficult when you DO want to stop it. However, I think there are a few things you might be able to do to solve your problem... 1) BIOS upgrade. Long shot, but maybe? 2) BIOS config option? Also a long shot, but since I'd call this a boot firmware bug, maybe some combination of USB related options would fix this? 3) a boot.conf file should fix -- simply putting "boot" in /etc/boot.conf should override anything in the keyboard buffer. Need to "control" the boot? plug in a keyboard and hold down either CTRL key, and you will be given the boot> prompt. Nick. > Here is the dmesg from my latest Dell server: > > OpenBSD 6.6 (GENERIC.MP) #3: Thu Nov 21 03:20:01 MST 2019 > r...@syspatch-66-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/ > GENERIC.MP > real mem = 8487182336 (8094MB) > avail mem = 8217251840 (7836MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe (71 entries) > bios0: vendor Dell Inc. version "A02" date 11/14/2014 > bios0: Dell Inc. OptiPlex 3020M ...
Re: cvs checkout of src,ports and xenocara gives duplicate key msg
On 2019-12-15 09:42, putridsou...@gmail.com wrote: > I recently did a checkout of the src,ports and xenocara > repositories and was greeted by the following message on > each checkout. After this the command proceeds smoothly. > Also doing "echo $?" gives "0" so it's not a error. > > cvs server: duplicate key found for 'y' > > A quick search online tied this message to file corruption. > On further testing, the message repeated itself. Can anyone > indicate if this has something to do with my hard disk or > anoncvs server. You left out an incredible amount of information and context here, so I'm going to say there's a PEBKAC here somewhere. Now, if you want to tell us in detail what you are doing and what is actually happening. Otherwise, best I can say is something ain't right. Nick.
Re: Hyperbola Gnu Linux changing to Bsd
On 2019-12-30 14:31, SOUL_OF_ROOT 55 wrote: ... > What are the opinions of the OpenBSD developers about Hiperbola GNU/Linux? Just my opinion... A linux distribution (repacking other people's stuff) that I never heard of is going to abandon their old work and users in favor of actually making a new operating system, which will involve actually making code and making it work "some day". What could go wrong? Other than their rather twisted definition of "free", which has been sufficiently hashed and rehashed, I don't see anything there to think about. There's no product. Just a lot of words. And most of them are stupid words. I just spot checked one of the "license problems" they think they spotted in the OpenBSD tree. http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/landisk/include/endian.h?rev=1.2 What exactly are they planning on licensing in that? When they have something to show...let's be real, I'll probably ignore that, too. There's nothing about their goals and objectives that interests me at all. Nick.
Re: Hardware for Access Point on OpenBSD
On 2020-01-01 13:42, Zé Loff wrote: > > On Wed, Jan 01, 2020 at 08:54:46AM -0700, List wrote: >> Hi *, >> I am currently building a home router based upon OpenBSD. >> I therefore need some kind of WIFI Hardware. This piece of hardware >> needs to be connected over usb. >> Do you have any suggestions or recommendations ? As far as I can see >> it's pretty hard to find an antenna which is connected via USB an runs >> on a supported chipset. It is easy to get your hands on a >> realtek-chipset driven device. But urtw(4) doesn't support Host AP >> mode. Only ones that do are: athn(4), ral(4), ath(4). >> Finding those is hard. >> >> Maybe you guys know things I couldn't find ? >> >> g, >> Stephan >> > > In all honesty, and I've tried what you are aiming for a couple of times > in the past, it's just easier to get a dedicated AP (or a cheap wifi > router with a cable on the ethernet switch, which is usually bridged > with the wifi interface) and connect to an OpenBSD router which will > do all the necessary packet filtering (including keeping the AP/router's > firmware from reaching the internet, if needed be). IMHO this will be > stabler and faster than trying to find an adequate wifi board. And > these days you're bound to get nice perks like multiple SSIDs and > 802.11ac speeds (or whatever the latest 802.11* protocol is), which > AFAIK aren't available on OpenBSD yet. Also, note that (if I am not > mistaken) ural(4) are the only USB Wi-Fi interfaces that can handle Host > AP mode, and they only do 802.11b/g which is kind of slow by today's > standards. Agreed. Not only does the SW/HW work better, usually the best place to put an AP is not the best place to put a router. My AP is in my attic, my router is in my basement, with one chunk of CAT6 between them. Putting an important radio receiver next to a bunch of RF-noisy computers doesn't work so hot. :) Nick.
Re: Boot fail using internal SATA port, success using USB port.
On 2020-01-05 12:29, hkew...@cock.li wrote: > summary: OpenBSD installs to internal HDD from external USB but fails > to load after the first reboot. If the HDD is removed from the internal > port and is connected via a "SATA to USB" cable it boots succesfully. > > I am a new and inexperienced user, excuse my ignorance. > > All the details and things I have tried so far: > > -All relevant UEFI options configured to legacy mode. careful with this. Just because it says it supports legacy mode doesn't mean the BIOS was extensively tested in legacy mode. I'd try both modes, just for giggles. > -minirootXX.fs copied to USB using rufus. > -USB boot using legacy mode. > -In install: whole disk mbr-auto config. see above. :) > -After reboot DELL logo is displayed 3 times. On the 3rd time it stays > static. > --Using gpt format instead results in an infinite boot loop. oh. you did try GPT. nevermind. > -Starting UEFI-menu(f2) or diagnostics(f5) or boot-menu(f12) appear to > initiate but then stay static. The UEFI appears to be completely > "bricked". There is no way to proceed. > --Resetting UEFI using CMOS and booting with the HDD in internal port > still renders UEFI "bricked" although it gives a PXE option because it > is enabled by default in the now reset UEFI. > --Merely performing a "clean" on diskpart(win7) to the HDD and plugging > it back "unbricks" the UEFI. > --Merely removing the HDD "unbricks" the UEFI. > -Connecting HDD using "SATA to USB" cable(even without CMOS reset) > works and OpenBSD boots. > -Installing Windows 7(in the same manner OpenBSD was) works and boots > from the internal SATA port. > > Deduction: There seems to be something not allowing OpenBSD to boot > from the internal SATA port, in addition to it rendering the laptop > unusable until the HDD is removed, cleaned or connected via USB port. > > I have taken the time to write all the UEFI configuration I use. Please > check it if you think the problem stems from there. ouch. However, the effort is appreciated. > hardware: DELL Latitude e5440 Pretty sure I've tested one of those, they work. As I recall, the E5440 is a few years old, and if I recall properly, the battery wasn't very long-lived in it. And the Dells of that vintage had a really wacked default -- someone decided it would be best to default to "RAID" for disk mode. Yes, on a one drive laptop. For safety reasons, OpenBSD (and many other non-windows OSs) disable disk access if the disk controller is in RAID mode rather than ACHI or "legacy" mode. So ... is it possible the CMOS battery is bad on your machine? This would explain a "Power up, set up machine, install, reboot -- ok". "power off, power back on later, won't successfully boot" (the kernel would load, but be unable to access the disks and then panic). I'm not convinced this is the problem, but might be. Nick.
Re: Odd /tmp behavior
On 2020-01-07 14:06, Karel Gardas wrote: > > > On 1/7/20 7:38 PM, Jordan Geoghegan wrote: >> > Using softdep on /tmp is a silly idea. > > Why? To naive eyes it may look like a natural solution: e.g. before temp > file is even created (on drive), it may be deleted which means there is > no meta-data change hence speedup of operation on /tmp. In case of > classical ffs, you will need to create file (sync meta-data update), > save some data (async), delete file (sync meta-data update). But > honestly still need to read the code... > I'm not going to go nearly as far as to say it's a silly idea (as I do it myself) but ... be aware softdep is funky. Weird stuff happens when Softdeps are working as designed. When you do things out of order, things happen...well, out of order. So ... create file delete file create file delete file create file delete file create file delete file create file delete file sounds perfectly safe, as long as "file" is smaller than available disk space, right? Softdeps...no so much. This can actually result in running out of disk space, as the deletes may not happen until after the creates. Another place where softdeps will sometimes bite you is when you unpack tar balls that overwrite existing files -- simple thought process says, "as long as you have enough space to cover the growth, fine". Softdeps might surprise you. You may get an "out of disk space" error, and a minute later, see much more space than you thought you could ever need to accomplish the task, once the deletions have time to take effect. So ... make sure you have lots of extra disk space...if things are snug, it's a bad place to use softdeps. Nick.
automounter (amd) local file system issue
Hiya. I'd like to use amd(8) to automatically mount and dismount local file systems. The file systems in question are big, lots of complicated links, lots of files, and take a while to fsck if the power goes out unexpectedly, and are used relatively rarely (maybe an hour a day). Sounds like a perfect job for amd(8)! The file systems in question are mounted to /v/1 and /v/2 I've got the following set up: $ cat /etc/rc.conf.local amd_flags=-l syslog -x all -c 10 -w 10 lockd_flags= portmap_flags= $ cat /etc/amd/master /v amd.v $ cat /etc/amd/amd.v 1 type:=ufs;dev:=/dev/sd2i 2 type:=ufs;dev:=/dev/sd2j ANDit works! start the system up, I get this: $ df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/sd2a 101167620381275728421%/ /dev/sd2h 1031983648 9803800 0%/home /dev/sd2f 413682820 3929968 0%/tmp /dev/sd2d 8264188 2369920 548106030%/usr /dev/sd2e 2065116 2104 1959760 0%/usr/local /dev/sd2g 4136828 64920 3865068 2%/var amd:365830 0 0 100%/v $ ls /v/1/ [...expected output from files and directories on that file system...] $ df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd2a 505838 8360239694617%/ /dev/sd2h 515991824 4901900 0%/home /dev/sd2f 206841410 1964984 0%/tmp /dev/sd2d 4132094 1280264 264522633%/usr /dev/sd2e 1032558 1052979880 0%/usr/local /dev/sd2g 2068414 32572 1932422 2%/var amd:92953 0 0 0 100%/v /dev/sd2i 2106117872 298739480 170207250415%/tmp_mnt/dbu/v/1 Success!! well...no. Seems it never umounts the amd file systems. And that is basically the point of this exercise -- to increase the odds that a FS isn't mounted when the power goes out. Am I doing something wrong? Do I have inaccurate expectations of what amd(8) does with local file systems? Nick. OpenBSD 6.6-current (GENERIC.MP) #599: Sat Jan 11 18:52:00 MST 2020 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2038652928 (1944MB) avail mem = 1964462080 (1873MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebd30 (52 entries) bios0: vendor American Megatrends Inc. version "1020" date 12/15/2014 bios0: PowerSpec V400 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT MSDM MCFG LPIT SLIC HPET SSDT SSDT SSDT UEFI acpi0: wakeup devices XHC1(S3) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) CPU J2900 @ 2.41GHz, 2417.12 MHz, 06-37-08 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Pentium(R) CPU J2900 @ 2.41GHz, 2416.67 MHz, 06-37-08 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Pentium(R) CPU J2900 @ 2.41GHz, 2416.69 MHz, 06-37-08 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Pentium(R) CPU J2900 @ 2.41GHz, 2416.68 MHz, 06-37-08 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SS
Re: automounter (amd) local file system issue
On 2020-01-12 15:39, Antoine Jacoutot wrote: > Sounds like something is keeping your fs busy. Could be gio-kqueue, do you > have glib2 installed? That would be my first guess, too -- it's not unmounting because it shouldn't. But ... this is a VERY single purpose machine (backups via rsync --link-dest), and the only third party package is rsync and my scripts to do the backups. X is installed, but not running. $ pkg_info intel-firmware-20191115p0v0 microcode update binaries for Intel CPUs inteldrm-firmware-20181218 firmware binary images for inteldrm(4) driver quirks-3.216exceptions to pkg_add rules rsync-3.1.3 mirroring/synchronization over low bandwidth links vmm-firmware-1.11.0p2 firmware binary images for vmm(4) driver I was careful to access the amd mounts by ls , while sitting in my home directory, which is NOT part of the amd, so I didn't have a task under a doas or su camped out on the amd vols. I've tesed a lot of ways, but I just did an upgrade to -current and immediately "looked" at the amd mount, so even my backup scripts haven't run. Plus -- as a control, /v/2 has absolutely nothing on it, and it behaves the same way. Not that something couldn't camp out on the empty file system, but not much reason for something to do so. Thanks for looking! Nick. > — > Antoine > >> On 13 Jan 2020, at 06:01, Nick Holland wrote: >> >> Hiya. >> >> I'd like to use amd(8) to automatically mount and dismount local file >> systems. The file systems in question are big, lots of complicated >> links, lots of files, and take a while to fsck if the power goes out >> unexpectedly, and are used relatively rarely (maybe an hour a day). >> Sounds like a perfect job for amd(8)! >> >> The file systems in question are mounted to /v/1 and /v/2 >> >> I've got the following set up: >> >> $ cat /etc/rc.conf.local >> amd_flags=-l syslog -x all -c 10 -w 10 >> lockd_flags= >> portmap_flags= >> >> $ cat /etc/amd/master >> /v amd.v >> >> $ cat /etc/amd/amd.v >> 1 type:=ufs;dev:=/dev/sd2i >> 2 type:=ufs;dev:=/dev/sd2j >> >> >> ANDit works! >> >> start the system up, I get this: >> >> $ df >> Filesystem 512-blocks Used Avail Capacity Mounted on >> /dev/sd2a 101167620381275728421%/ >> /dev/sd2h 1031983648 9803800 0%/home >> /dev/sd2f 413682820 3929968 0%/tmp >> /dev/sd2d 8264188 2369920 548106030%/usr >> /dev/sd2e 2065116 2104 1959760 0%/usr/local >> /dev/sd2g 4136828 64920 3865068 2%/var >> amd:365830 0 0 100%/v >> >> $ ls /v/1/ >> [...expected output from files and directories on that file system...] >> >> $ df >> Filesystem 1K-blocks Used Avail Capacity Mounted on >> /dev/sd2a 505838 8360239694617%/ >> /dev/sd2h 515991824 4901900 0%/home >> /dev/sd2f 206841410 1964984 0%/tmp >> /dev/sd2d 4132094 1280264 264522633%/usr >> /dev/sd2e 1032558 1052979880 0%/usr/local >> /dev/sd2g 2068414 32572 1932422 2%/var >> amd:92953 0 0 0 100%/v >> /dev/sd2i 2106117872 298739480 170207250415%/tmp_mnt/dbu/v/1 >> >> Success!! >> well...no. Seems it never umounts the amd file systems. And that is >> basically the point of this exercise -- to increase the odds that a FS >> isn't mounted when the power goes out. >> >> Am I doing something wrong? Do I have inaccurate expectations of >> what amd(8) does with local file systems? >> >> Nick. >> >> OpenBSD 6.6-current (GENERIC.MP) #599: Sat Jan 11 18:52:00 MST 2020 >>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> real mem = 2038652928 (1944MB) >> avail mem = 1964462080 (1873MB) >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebd30 (52 entries) >> bios0: vendor American Megatrends Inc. version "1020" date 12/15/2014 >> bios0: PowerSpec V400 >> acpi0 at bios0: ACPI 5.0 >> acpi0: sleep states S0 S3 S4 S5 >> acpi0: tables DSDT FACP APIC FPDT MSDM MCFG LPIT SLIC HPET SSDT SSDT SSDT >> UEFI >> acpi0: wakeup devices XHC1(S3) PXSX(S4) P
Re: automounter (amd) local file system issue
On 2020-01-15 11:05, Strahil Nikolov wrote: > On January 13, 2020 5:40:06 AM GMT+02:00, Nick Holland > wrote: >>On 2020-01-12 15:39, Antoine Jacoutot wrote: >>> Sounds like something is keeping your fs busy. Could be gio-kqueue, >>do you have glib2 installed? >> >>That would be my first guess, too -- it's not unmounting because it >>shouldn't. But ... this is a VERY single purpose machine (backups >>via rsync --link-dest), and the only third party package is rsync >>and my scripts to do the backups. X is installed, but not running. >> >>$ pkg_info >>intel-firmware-20191115p0v0 microcode update binaries for Intel CPUs >>inteldrm-firmware-20181218 firmware binary images for inteldrm(4) >>driver >>quirks-3.216exceptions to pkg_add rules >>rsync-3.1.3 mirroring/synchronization over low bandwidth links >>vmm-firmware-1.11.0p2 firmware binary images for vmm(4) driver >> >>I was careful to access the amd mounts by ls , while >>sitting in my home directory, which is NOT part of the amd, so I >>didn't have a task under a doas or su camped out on the amd vols. >> >>I've tesed a lot of ways, but I just did an upgrade to -current and >>immediately "looked" at the amd mount, so even my backup scripts >>haven't run. >> >>Plus -- as a control, /v/2 has absolutely nothing on it, and it >>behaves the same way. Not that something couldn't camp out on the >>empty file system, but not much reason for something to do so. >> >>Thanks for looking! >> >>Nick. >> >> >>>  >>> Antoine >>> >>>> On 13 Jan 2020, at 06:01, Nick Holland >>wrote: >>>> >>>> Hiya. >>>> >>>> I'd like to use amd(8) to automatically mount and dismount local >>file >>>> systems. The file systems in question are big, lots of complicated >>>> links, lots of files, and take a while to fsck if the power goes out >>>> unexpectedly, and are used relatively rarely (maybe an hour a day). >>>> Sounds like a perfect job for amd(8)! >>>> >>>> The file systems in question are mounted to /v/1 and /v/2 >>>> >>>> I've got the following set up: >>>> >>>> $ cat /etc/rc.conf.local >> >>>> amd_flags=-l syslog -x all -c 10 -w 10 >>>> lockd_flags= >>>> portmap_flags= >>>> >>>> $ cat /etc/amd/master >> >>>> /v amd.v >>>> >>>> $ cat /etc/amd/amd.v >>>> 1 type:=ufs;dev:=/dev/sd2i >>>> 2 type:=ufs;dev:=/dev/sd2j >>>> >>>> >>>> ANDit works! >>>> >>>> start the system up, I get this: >>>> >>>> $ df >>>> Filesystem 512-blocks Used Avail Capacity Mounted on >>>> /dev/sd2a 101167620381275728421%/ >>>> /dev/sd2h 1031983648 9803800 0%/home >>>> /dev/sd2f 413682820 3929968 0%/tmp >>>> /dev/sd2d 8264188 2369920 548106030%/usr >>>> /dev/sd2e 2065116 2104 1959760 0%/usr/local >>>> /dev/sd2g 4136828 64920 3865068 2%/var >>>> amd:365830 0 0 100%/v >>>> >>>> $ ls /v/1/ >>>> [...expected output from files and directories on that file >>system...] >>>> >>>> $ df >>>> Filesystem 1K-blocks Used Avail Capacity Mounted on >>>> /dev/sd2a 505838 8360239694617%/ >>>> /dev/sd2h 515991824 4901900 0%/home >>>> /dev/sd2f 206841410 1964984 0%/tmp >>>> /dev/sd2d 4132094 1280264 264522633%/usr >>>> /dev/sd2e 1032558 1052979880 0%/usr/local >>>> /dev/sd2g 2068414 32572 1932422 2%/var >>>> amd:92953 0 0 0 100%/v >>>> /dev/sd2i 2106117872 298739480 170207250415% >>/tmp_mnt/dbu/v/1 >>>> >>>> Success!! >>>> well...no. Seems it never umounts the amd file systems. And that >>is >>>> basically the point of this exercise -- to increase the odds that a >>FS >>>> isn't mounted when the power goes out. >>>> >>>> Am I doing something wrong? Do I have inaccurate expectations of >>>> what amd(8) does with local file systems? >>>> >>>> Nick. >>>> ... > Hi Nick, > > Can you test removing '-w 10' from the daemon's flags in order to test with > the default 2min timeout. > > I have a vague feeling that 10 seconds is way too short... You are right -- that was something I tried so I quit having to wait 5+ minutes every time I tried something different, so I stuffed absurdly short timeouts in place for testing, but there was no change. I've reverted those changes, and (as I expected), it is still not unmounting. New: $ cat /etc/rc.conf.local amd_flags=-l syslog -x all lockd_flags= portmap_flags= (the -x all was added to see if amd logged any dismount attempts or why they failed...nothing) So thanks, but ... no change. :-/ Nick.
Re: Server 5 SSD/best practice
On 2020-02-20 11:22, Oliver Marugg wrote: > Hi > > I’ve got a Supermicro 5028D desktop server with 5 identical SATA SSDs, > there is no HBA no RAID card in. The purpose of the server is intended > as web/smtp and some vmm vms (os plus /home & /var storage). > What are your suggestions or best practices configuring the device > arrangement (eg. sofraid(4), bio(4),bioctl(4) OS 2x on 2x ssd raid1, > data 3xssd raid5 or 1x single ssd for OS and 4x ssd raid5/10 or better > ideas)? > > many thanks > -oliver > set it up as you need it... If you think your description is anything close to specific for specific recommendations, you need to get out more. Everything you said could vary in demand by many orders of magnitude, except for the model number the server...a curious thing to be specific about. E-mail is one of those things that's really hard to get a good backup of, as it changes minute by minute and is considered fairly important, so I'd consider a three disk RAID1 for the mail store, as a disk system failure invariably means "lost data", even with frequent backups. Three disk RAID1 gives you a simple disk structure that can tolerate a disk failure and still provide redundancy. (some people will tell you that RAID1 is only two disks. These people are wrong, but often include HW RAID controller makers. Three disk RAID1 examples are in the man pages). As for the rest...it's a matter of how much space you need and how much down time you can tolerate, and how you are set up to deal with that downtime. And I'm assuming you aren't combining external and internal services on one box. I suspect that's a bad assumption. And even after much careful analysis it's a bit of a guess. Sometimes you guess wrong. So keep your design flexible and be willing and able to say, "Well, this isn't working, let's rebuild it with the knowledge we now have". This idea that you have to have the perfect build the first time out is ... well, just wrong. Nick.
Re: openbsd.org - certain https URLs downgraded to http in redirection
Sorry, took a look at this a while back when I didn't have time to fully work through it...and then forgot about it. ;-/ On 2020-02-12 04:34, Aham Brahmasmi wrote: > Namaste misc, > > Overview: > Certain https URLs on openbsd.org get downgraded to http in redirection. > > Steps: > When navigating to https://www.openbsd.org/cgi-bin/man.cgi [1] from a > browser, one ends up on http://man.openbsd.org/cgi-bin/man.cgi. > > Same with https://www.openbsd.org/cgi-bin/cvsweb [1], which ends up on > http://cvsweb.openbsd.org/cgi-bin/cvsweb/. I Google for "openbsd man", I end up with a link to httpS://man.openbsd.org. and it takes me to man.openbsd.org via httpS. I duckduckgo.com for "openbsd man", same thing. (yay. I just used a website as a verb.) Google does seem to show a link for httpS://cvsweb.openbsd.org, but tosses the browser at http://cvsweb.openbsd.org. DuckDuckGo does not and does what you would expect and hope. Looking at the page source for the google return, it DOES appear to be sending the browser to http://, so everything is working as designed. Is there a problem? Yes -- google is aware https:// those sites exists, but doesn't actually send users to them. Apparently your favorite search engine does as well. Perhaps it isn't as privacy friendly as you are thinking it is. The problem isn't with the websites, it's with where the search engine is sending the user. You want it changed so that when someone clicks on a link, they go somewhere OTHER than where that link sends them? I understand your goal (everything should be HTTPS!!), but I don't really like the idea of "click here, go elsewhere". Want https? great. use it. There are times when it's handy to NOT be obsessed with https (i.e., clock is hosed on your computer). So ... unless some developer I really respect (which is just about all of them1) tells me to change this, I'm not planning on changing the behavior of the machines. Nick.
Re: upgrade i386 kernel to amd64
On 2020-03-02 18:14, Justin Muir wrote: > Hello all, > > Running GENERIC i386 kernel on on a 64-bit amd machine. Just wondering > whether an upgrade amd64 is warranted. Any opinions? yes. At this point, most OpenBSD development starts on amd64 systems, then moves to other platforms. Plus, the AMD64 platform offers some magic tricks that help improve security, and I do believe generally better package support. amd64 systems have been around for over 15 years. i386 is really almost a "legacy" platform now. If you gotta use it, ok...but otherwise, no. The only reason I can think of to run i386 code on an amd64 system is if your i386 system failed and you moved the disk to an amd64 capable system. > If so, just upgrade system? Re-compile kernel? Other options? DO NOT UPGRADE. No idea what you are even dreaming of by "recompiling the kernel", that makes the bad idea of an upgrade look good (it isn't). Reinstall from scratch. Good time to look at how you used disk and partition better this time. Nick.
Re: disklabel fs types, where can I find the whole list of supported types?
On 10/05/15 06:47, Benny Lofgren wrote:
...
Personally, I think it would be a good thing to bring back slices to the
vocabulary. That would emphasize the distinction between physical disk
partitions as they appear in the PC-centric hardware world and logical
partitions/slices that are a subdivision *within* a disk partition.
no. You are going from an ambiguity that can be solved by adding ONE
well-understood word ("fdisk partitions" "disklabel partitions") to
adding a new word that you have a definition of that may or may not be
shared by the world.
iirc (and don't bother to check or correct -- it does not matter) one
BSD refers to fdisk partitions as slices, and disklabel partitions as
partitions. Congrats, you just did it backwards from another group and
*added* to the confusion. Or didn't, depending on my memory.
The best answer to confusion is writing clearly, even if that involves a
few more words (oh the horror).
Nick.
