Re: Minimum install size
From: Aaron Mason Subject: Re: Minimum install size Date: Sat, 29 Apr 2023 11:49:26 +1000 > If you wanted to go super hard core, you could build crunchgen in src > and build a busybox-style setup FYI: This is what FuguIta does. Yoshihiro Kawamata https://fuguita.org
Re: Minimum install size
Yoshihiro Kawamata wrote: > From: Janne Johansson > Subject: Re: Minimum install size > Date: Fri, 28 Apr 2023 09:09:49 +0200 > > > Do not assume "desireable" and "possible" are always the same. > > My point was whether the wording "installable on 512MB of storage" is > appropriate to put in the OpenBSD 7.3 FAQ, and whether "desirable" and > "possible" are the same is outside the discussion. No, it is optimistic oversell by the faq authors It should be realistic & accurate, or it should say nothing at all.
Re: Minimum install size
From: Janne Johansson Subject: Re: Minimum install size Date: Fri, 28 Apr 2023 09:09:49 +0200 > Do not assume "desireable" and "possible" are always the same. My point was whether the wording "installable on 512MB of storage" is appropriate to put in the OpenBSD 7.3 FAQ, and whether "desirable" and "possible" are the same is outside the discussion. Yoshihiro Kawamata https://fuguita.org
Intel 10G X550T sr-iov virtual function driver
I recently migrated an OpenBSD vm running under qemu/kvm to a new server which has an Intel 10G X550T NIC (Intel Corporation Ethernet Converged Network Adapter X550-T2) and am passing a vf though to the vm. Unfortunately, it appears openbsd doesn't have a driver for this virtualized device? The dmesg output shows: vendor "Intel", unknown product 0x1565 (class network subclass ethernet, rev 0x0 0) I see in the current PCI device list: https://github.com/openbsd/src/blob/master/sys/dev/pci/pcidevs there is support for the native card itself (INTEL X550T id 0x1563) but nothing for the virtual function 0x1565. Are there any plans to support this card as a virtual function in a vm? Thanks much...
Re: Minimum install size
On Fri, Apr 28, 2023 at 5:11 PM Janne Johansson wrote: > > Den fre 28 apr. 2023 kl 06:12 skrev Yoshihiro Kawamata : > > > > In the OpenBSD FAQ, in the Installation Guide section, it says > > "OpenBSD can be installed in as little as 512MB, but using a device > > that small is something for advanced users". > > https://www.openbsd.org/faq/faq4.html#Partitioning > > > > In fact, the installation of only the kernel and base73.tgz required > > 629MB for i386 and 1GB for amd64. > > > > For example, if I delete the files under /usr/share/relink, I can > > get within 512MB, but this is not a desirable installation method, is > > it? > > Do not assume "desireable" and "possible" are always the same. > > -- > May the most significant bit of your life be positive. > If you wanted to go super hard core, you could build crunchgen in src and build a busybox-style setup - though such things would be super unsupported and you'd get to keep all the pieces if it breaks. -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
OpenBSD/i386 7.3 on a Macbook 2006
Hello, I’ve installed OpenBSD/i386 7.3 on a Macbook 2006. It works, but the fan is running at maximum all the time. Is there anything I can do to optimize the system for such machines? Here’s the output from dmesg and “sysctl hw.sensors”: http://paste.debian.net/1278825/ Regards, Martin
Re: hardware
That's been my motto as well. Except I recently picked up an R86s with older Mellanox ConnectX-3 10GbE SFPs, only to discover that OpenBSD only supports the newer ConnectX-4 and 5s :( I'd love to contribute in writing a driver in some way, but don't even know where to begin. On 4/28/23 13:55, Mihai Popescu wrote: Gustavo Rios wrote: What is the best supported servers by OpenBSD ? The older, the better! Take the oldest machine that will suit your needs. If it old enough, then someone: o released some (in)complete documentation o was pissed enough to start writing drivers and code for it o noticed bugs and reported them o ... already! Good luck!
Re: hardware
Gustavo Rios wrote: > What is the best supported servers by OpenBSD ? The older, the better! Take the oldest machine that will suit your needs. If it old enough, then someone: o released some (in)complete documentation o was pissed enough to start writing drivers and code for it o noticed bugs and reported them o ... already! Good luck!
Re: PC Engines APU platform EOL
On Wed, Apr 19, 2023 at 11:30 AM Martin Schröder wrote: > https://www.pcengines.ch/eol.htm > The end is near for APUs :-( It may be the end for open/free source as we know it. The market is moving to ARM for hardware. As for the software, Linux is preferred - a lot of code, a lot of options, very flexible, very configurable. There are other options of course, like RISC IV and BSDs, but those are just for research and fun (TM).
Re: 7.3: high network latency every couple of seconds. Carp?
Please ignore this duplicate post and reply to the other thread on this mailing list. I had used my private EMail account by accident. Regards Harri
7.3: high network latency every couple of seconds. Carp?
Hi folks,
Using 7.3 on a HA gateway ("redgatea" and "redgateb", one external
network, 2 internal networks, carp on all interfaces) I see a high
network latency for incoming network traffic every couple of seconds.
Trying to ping redgatea from redgateb over the pfsync interface, for
example:
redgateb # ping 192.168.23.2
PING 192.168.23.2 (192.168.23.2): 56 data bytes
64 bytes from 192.168.23.2: icmp_seq=0 ttl=255 time=0.585 ms
64 bytes from 192.168.23.2: icmp_seq=1 ttl=255 time=48.559 ms
64 bytes from 192.168.23.2: icmp_seq=2 ttl=255 time=153.323 ms
64 bytes from 192.168.23.2: icmp_seq=3 ttl=255 time=0.233 ms
64 bytes from 192.168.23.2: icmp_seq=4 ttl=255 time=0.230 ms
64 bytes from 192.168.23.2: icmp_seq=5 ttl=255 time=0.227 ms
64 bytes from 192.168.23.2: icmp_seq=6 ttl=255 time=1.001 ms
64 bytes from 192.168.23.2: icmp_seq=7 ttl=255 time=1.253 ms
64 bytes from 192.168.23.2: icmp_seq=8 ttl=255 time=0.224 ms
64 bytes from 192.168.23.2: icmp_seq=9 ttl=255 time=0.229 ms
64 bytes from 192.168.23.2: icmp_seq=10 ttl=255 time=0.231 ms
64 bytes from 192.168.23.2: icmp_seq=11 ttl=255 time=0.228 ms
64 bytes from 192.168.23.2: icmp_seq=12 ttl=255 time=0.267 ms
64 bytes from 192.168.23.2: icmp_seq=13 ttl=255 time=259.893 ms
64 bytes from 192.168.23.2: icmp_seq=14 ttl=255 time=364.299 ms
64 bytes from 192.168.23.2: icmp_seq=15 ttl=255 time=0.228 ms
64 bytes from 192.168.23.2: icmp_seq=16 ttl=255 time=0.230 ms
64 bytes from 192.168.23.2: icmp_seq=17 ttl=255 time=0.231 ms
64 bytes from 192.168.23.2: icmp_seq=18 ttl=255 time=1.349 ms
64 bytes from 192.168.23.2: icmp_seq=19 ttl=255 time=1.113 ms
64 bytes from 192.168.23.2: icmp_seq=20 ttl=255 time=0.232 ms
64 bytes from 192.168.23.2: icmp_seq=21 ttl=255 time=0.232 ms
64 bytes from 192.168.23.2: icmp_seq=22 ttl=255 time=0.225 ms
64 bytes from 192.168.23.2: icmp_seq=23 ttl=255 time=0.223 ms
64 bytes from 192.168.23.2: icmp_seq=24 ttl=255 time=0.224 ms
64 bytes from 192.168.23.2: icmp_seq=25 ttl=255 time=469.175 ms
64 bytes from 192.168.23.2: icmp_seq=26 ttl=255 time=571.747 ms
64 bytes from 192.168.23.2: icmp_seq=27 ttl=255 time=0.253 ms
64 bytes from 192.168.23.2: icmp_seq=28 ttl=255 time=0.225 ms
64 bytes from 192.168.23.2: icmp_seq=29 ttl=255 time=0.229 ms
64 bytes from 192.168.23.2: icmp_seq=30 ttl=255 time=0.227 ms
64 bytes from 192.168.23.2: icmp_seq=31 ttl=255 time=1.222 ms
64 bytes from 192.168.23.2: icmp_seq=32 ttl=255 time=0.995 ms
64 bytes from 192.168.23.2: icmp_seq=33 ttl=255 time=0.238 ms
64 bytes from 192.168.23.2: icmp_seq=34 ttl=255 time=0.238 ms
64 bytes from 192.168.23.2: icmp_seq=35 ttl=255 time=0.230 ms
64 bytes from 192.168.23.2: icmp_seq=36 ttl=255 time=0.230 ms
64 bytes from 192.168.23.2: icmp_seq=37 ttl=255 time=679.469 ms
64 bytes from 192.168.23.2: icmp_seq=38 ttl=255 time=781.050 ms
64 bytes from 192.168.23.2: icmp_seq=39 ttl=255 time=0.221 ms
64 bytes from 192.168.23.2: icmp_seq=40 ttl=255 time=0.240 ms
^C
--- 192.168.23.2 ping statistics ---
41 packets transmitted, 41 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.221/81.489/781.050/195.848 ms
There is no switch involved in this pfsync connection, just a
single cable from NIC to NIC.
I see the same performance problem for incoming traffic on all
other network interfaces of redgatea and redgateb, MASTER and
BACKUP, even on the external connection. For outgoing traffic
(eg if I try to ping a 3rd host *from* redgateb) there is a
performance impact, too, but it is much lower:
redgateb# ping 10.100.100.101
PING 10.100.100.101 (10.100.100.101): 56 data bytes
64 bytes from 10.100.100.101: icmp_seq=0 ttl=64 time=0.291 ms
64 bytes from 10.100.100.101: icmp_seq=1 ttl=64 time=0.241 ms
64 bytes from 10.100.100.101: icmp_seq=2 ttl=64 time=0.235 ms
64 bytes from 10.100.100.101: icmp_seq=3 ttl=64 time=0.246 ms
64 bytes from 10.100.100.101: icmp_seq=4 ttl=64 time=1.176 ms
64 bytes from 10.100.100.101: icmp_seq=5 ttl=64 time=1.479 ms
64 bytes from 10.100.100.101: icmp_seq=6 ttl=64 time=0.220 ms
64 bytes from 10.100.100.101: icmp_seq=7 ttl=64 time=0.231 ms
64 bytes from 10.100.100.101: icmp_seq=8 ttl=64 time=0.228 ms
64 bytes from 10.100.100.101: icmp_seq=9 ttl=64 time=0.229 ms
64 bytes from 10.100.100.101: icmp_seq=10 ttl=64 time=0.242 ms
64 bytes from 10.100.100.101: icmp_seq=11 ttl=64 time=0.230 ms
64 bytes from 10.100.100.101: icmp_seq=12 ttl=64 time=0.244 ms
64 bytes from 10.100.100.101: icmp_seq=13 ttl=64 time=0.236 ms
64 bytes from 10.100.100.101: icmp_seq=14 ttl=64 time=0.236 ms
64 bytes from 10.100.100.101: icmp_seq=15 ttl=64 time=0.231 ms
64 bytes from 10.100.100.101: icmp_seq=16 ttl=64 time=1.465 ms
64 bytes from 10.100.100.101: icmp_seq=17 ttl=64 time=1.089 ms
64 bytes from 10.100.100.101: icmp_seq=18 ttl=64 time=0.220 ms
64 bytes from 10.100.100.101: icmp_seq=19 ttl=64 time=0.220 ms
64 bytes from 10.100.100.101: icmp_seq=20 ttl=64 time=0.233 ms
64 bytes from 10.100.100.101: icmp_seq=21 ttl=64 time=0.222 ms
^C
--- 10.100.100.101 ping statistics ---
22 packets transmitted,
Re: A messed-up fresh install due to a careless user
Hello Stefan, Thanks for the clear-up. And now, it works! When I created the site set, I forgot to add /etc/rc.conf.local, where pf was set to be disabled. The reason was, as you see, pf. :-) So a simple “pfctl -d” solved the “problem”. Good to know that the fault actually wasn’t a careless user who installed the system, but rather a careless user who forgot to add a simple file to a tar archive. :-) Regards, Martin
Re: Minimum install size
Den fre 28 apr. 2023 kl 06:12 skrev Yoshihiro Kawamata : > > In the OpenBSD FAQ, in the Installation Guide section, it says > "OpenBSD can be installed in as little as 512MB, but using a device > that small is something for advanced users". > https://www.openbsd.org/faq/faq4.html#Partitioning > > In fact, the installation of only the kernel and base73.tgz required > 629MB for i386 and 1GB for amd64. > > For example, if I delete the files under /usr/share/relink, I can > get within 512MB, but this is not a desirable installation method, is > it? Do not assume "desireable" and "possible" are always the same. -- May the most significant bit of your life be positive.
Re: A messed-up fresh install due to a careless user
Hello Daniel, I'm writing my text to the top of the email. This is probably easier for you to read than inline quoting. On the reboot question, you can ctrl+z + reboot. This would not have a negative effect on the installation. This is exactly what the installer would do if you answer "r" for reboot. Also unplugging the USB stick has no negative effect at this point. The boot loader has been installed, otherwise your OpenBSD installation would not have started. And the boot loader is installed after all sets have been extracted. Therefore it's unlikely that files are missing. I can not tell why the network configuration has not been written. If you type "mail" as root, you should find an email with all the questions and answers that were used during the installation. Maybe this gives a clue. I tend to believe that the network was not configured using the installer. Best Regards, Stefan Odd Martin Baanrud wrote (2023-04-27 23:31 CEST): > Hello, > > I’m blind, and got sighted help to install OpenBSD on the machine which > should become a new router. > Unfortunately, I was stupid enough to detach the USB stick I booted from, > before I was to hit R for the reboot. > The result was that the last selection disappeared due to the detach message > from the kernel, and I didn’t manage to get it back. > The only way I thaught could be used for reboot was to hit ctrl+Z, and then > type reboot. > And it “worked”. > > When I connected the machine to the LAN afterwords, I didn’t get contact. > After trying a few things, I finally got an IP on it, with the correct > hostname. > (I connected a keyboard, logged in as root, and configured one of the > interfaces with ifconfig $if autoconf.) > I’ve good expereince doing so without braille. > > So the machine got an IP, but still no contact, either with ping or ssh. > I then realized that mandatory files has not been written, including the > hostname.if file for the NIC used durring install. > And I guess others too. :-) > > Which files are actually written when rebooting the corret way? > I’ve OpenBSD 7.3 installed on both a arm64 and a i386 machine. > Can I use the missing files from one of those? > I should be able to copy them to a USB stick, and mount it and get the files > in place without sighted help. > And the network interface can be configured with dhcp for now. > As soon as the machine is on the lan, I’ll ssh into it from a linux machine > with a braille display. > > Regards, Martin > > PS: I’ve now learned that one should reboot _BEFORE_ detaching any external > device when the installer is still running. :-) >
