Re: Routing multiple IPv4 blocks
>> It can be done, but 1) it means that it's possible for hosts on RFC1918 >> addresses to reach the routable addresses directly without going via the >> router and vice-versa (which may or may not be a problem), 2) you'll >> need to think about how you want to arrange things if you use DHCP, and >> 3) it complicates things for firewall and nat rules. > > 1. I do not believe this should be a problem, as far as I am aware this > is routed based on MAC address (Layer 2), but IP addresses are a higher > layer (Layer 3). It means that your directly internet-accessible hosts have a way that they can reach your internal-network hosts without going through the firewall. Many network admins would consider this a problem. > 2. DHCP is simple, it is only for the private block (192.168.2.1/24) > which devices will use by default, global addresses from the /29 block > is assigned manually, this is because most containers are internal, > which the NAT is just so they can still access the internet, but not > expose themself fully (and before you say "why not use a global > address" that's fine, you have thought about how to arrange things for this > IPv4 addresses are expensive and I am lucky to have a /29, fwiw, you're using an expensive ISP which has ample spare addresses, there's a faorly good chance they'll give you more if asked. > 3. I don't think so, because I specify the "from" address as either from > 192.168.2.1/24 or the static block, which clearly distinguishes between > them. Also the "quick" rules are above the NAT, this should pick up and > pass out the traffic respectively before it even gets to NAT, I doubt > this is the issue and I believe it lies within the routing table. it's common to be able to use the network interface on which a packet is received as part of the decision whether to accept that packet. most example rulesets you'll find do that, so be aware if cribbing from other setups. >> 217.169.18.56 is a network address (mask it out against the netmask, >> the remaining "host bits" are all zeroes), you cannot use this (or the >> broadcast address) as a host address >> >> $ ipcalc 217.169.18.56/29 >> address : 217.169.18.56 >> netmask : 255.255.255.248 (0xfff8) >> network : 217.169.18.56 /29 >> broadcast : 217.169.18.63 >> host min : 217.169.18.57 >> host max : 217.169.18.62 >> hosts/net : 6 > > Ah my mistake, I totally forgot about the loopback address which would > be 217.169.18.56, this is from my own stupidity. > t's not a loopback, it's the network address. > But in theory, can I assign IPs from the /29 without having a default > gateway from that block, could I put the gateway as the /32 and keep all > 6 of the usable IPv4s? > > A router does not need 2 IPv4's, only one, so is it possible to keep one > or is it a requirement to have an IPv4 from the block assigned to the > router? hosts within that subnet need to be able to send ethernet paclets that reach the router. this is normally done by ARP which requires that the router has a host address (not a network or broadcast address) within the subnet. there are other ways to do it but they are fiddly, more fragile (requiring changes on every host if the router hardwarw address is changed), and really not recommended to go down that route unless you have a solid grasp of the basics. > > But the fact remains is, I believe all the addresses are bound to by the > router not according to what you've shown in your mail. > nmap'ing all the IPv4s in the block return the ports open by the > router. there's going to be some reason for this but it'll be easier to fix what's obviously a problem first and then go from there. > So it should be: > > inet alias 217.169.18.57 255.255.255.248 217.169.18.63 > > correct? yes, or you can leave off the broadcast address, it's set by default anyway. (remember to renumber the existing .57 host if you're going to use .57 for the router) -- Please keep replies on the mailing list.
Re: ip6-only ipsec tunnel over ip4
On 2023-07-26, Lyndon Nerenberg (VE7TFX/VE6BBM) wrote: > I need to set up an ipsec tunnel between a couple of ip6 networks, > but I only have an ip4 path between the two gateways. I don't want > any ip4 traffic inside the ipsec tunnel, so I'm a bit puzzled about > how to set this up. Once I have the end-points up, can I just point > the ip6 traffic and routes at enc0? All the example I can find > assume you're tunneling ip4 traffic through an ip4 tunnel. (Sorry, > but after three decades of trying, I still can't make heads nor > tails of ipsec :-P) IPsec normally uses flows rather than the route table. Just configure the tunnel between v6 addresses e.g. "from to peer ".
Re: ip6-only ipsec tunnel over ip4
I have an L2 tunnel ( eoip ) going across IPsec tunnel, I'm routing ip4 across it. You could try the same with ipv6. diana KI5PGJ On July 25, 2023 8:07:16 PM MDT, "Lyndon Nerenberg (VE7TFX/VE6BBM)" wrote: >I need to set up an ipsec tunnel between a couple of ip6 networks, >but I only have an ip4 path between the two gateways. I don't want >any ip4 traffic inside the ipsec tunnel, so I'm a bit puzzled about >how to set this up. Once I have the end-points up, can I just point >the ip6 traffic and routes at enc0? All the example I can find >assume you're tunneling ip4 traffic through an ip4 tunnel. (Sorry, >but after three decades of trying, I still can't make heads nor >tails of ipsec :-P) > >--lyndon >
ip6-only ipsec tunnel over ip4
I need to set up an ipsec tunnel between a couple of ip6 networks, but I only have an ip4 path between the two gateways. I don't want any ip4 traffic inside the ipsec tunnel, so I'm a bit puzzled about how to set this up. Once I have the end-points up, can I just point the ip6 traffic and routes at enc0? All the example I can find assume you're tunneling ip4 traffic through an ip4 tunnel. (Sorry, but after three decades of trying, I still can't make heads nor tails of ipsec :-P) --lyndon
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
Stuart Henderson wrote: > On 2023-07-25, Kevin wrote: > > Regarding the Zenbleed vulnerability itself, none of our AMD hosts are > > known to be vulnerable at this time as they are all running Milan and > > later CPUs. > > rather than going with "none are known to be vulnerable" they should > probably run the PoC program themselves and see whether strings from > other VMs show up Since they are emulating the behaviour of the DE_CFG register, they should allow (and ignore) setting that bit, because other operating systems are going to assume the same. Hypervisors gotta do stuff like that.
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
Kevin wrote: > Would this be worth putting a ticket into Vultr to get them to make > appropriate > updates on their side? You are the customer.
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
On 2023-07-25, Kevin wrote: > Regarding the Zenbleed vulnerability itself, none of our AMD hosts are > known to be vulnerable at this time as they are all running Milan and > later CPUs. rather than going with "none are known to be vulnerable" they should probably run the PoC program themselves and see whether strings from other VMs show up
Re: Installboot question
On 2023-07-25, Marcus MERIGHI wrote: > Hello, > > steve.shock...@shockley.net (Steven Shockley), 2023.07.25 (Tue) 16:34 (CEST): >> I have a machine with two ATA drives in a softraid mirror. For the Zen >> patch, do I run installboot on just sd2 (the softraid volume) or also sd0 >> and sd1 (the physical disks)? Thanks. > > # installboot -v sd2 > > installboot figures that out by itself. yep. iirc installboot won't even allow you to install on the physical disks in that situation, just the softraid mirror.
Re: Routing multiple IPv4 blocks
On 2023-07-25, Zack Newman wrote: > On 7/25/23 06:03, Stuart Henderson wrote: >> 217.169.18.56 is a network address (mask it out against the netmask, >> the remaining "host bits" are all zeroes), you cannot use this (or the >> broadcast address) as a host address > > I am sure you were not trying to be "technical"; but for people that > don't already possess the knowledge, I just wanted to say that there > are two exceptions to the rule that you shouldn't assign the network or > broadcast address to a host: /31 (https://www.rfc-editor.org/rfc/rfc3021) > and /32 networks. I also have a /29 network of globally routable IPv4 > addresses, and I use all 8 of those precious IPs by carving out 8 /32s > and assigning each one to a host. true, though Nx/32 won't let you route it to other hosts without a lot of hassle, and /31 may work or may not work depending on the other host's IP stack and other software in use (some things don't expect /31), and it doesn't actually give you any more available addresses unless you only have a routed /30. you can also put the all-0/all-1 addresses as /32 aliases and use them for NAT (i.e. nat-to, rdr-to, or binat-to, to a machine on an RFC1918-numbered network) while using the rest as normal on another nic. or there's a bodge if you don't need to talk to people on the surrounding addresses, where you set the netmask wider than you really have, say you have 192.0.2.80/28 from the ISP $ ipcalc 192.0.2.80/28 address : 192.0.2.80 netmask : 255.255.255.240 (0xfff0) network : 192.0.2.80 /28 broadcast : 192.0.2.95 host min : 192.0.2.81 host max : 192.0.2.94 hosts/net : 14 you could configure as /26 $ ipcalc 192.0.2.80/26 address : 192.0.2.80 netmask : 255.255.255.192 (0xffc0) network : 192.0.2.64 /26 broadcast : 192.0.2.127 host min : 192.0.2.65 host max : 192.0.2.126 hosts/net : 62 and actually use the 16 addresses .80-.95 (depending on how the routed subnet is aligned you may need to go to a wider prefix length, maybe as much as /23 if it starts on .0 or ends on .255). but none of these are things I think the OP should be concerned with at this time hence not suggesting them. :)
Re: Question on the latest errata
On 2023/07/25 21:24, Johannes Thyssen Tishman wrote: > Hi Stuart, > > > > 1. Could there be negative consequences of not running fw_update or > > > installboot before reboot? > > > > It means that you don't get the microcode updates, if any are available > > for your cpu. > > Until I run fw_update, installboot and reboot again right? To put it > differently, is the end result between > > # syspatch > # reboot > # fw_update > # installboot -v sd0 > # reboot > > and > > # syspatch > # fw_update > # installboot -v sd0 > # reboot > > any different? ah I see what you mean now - no difference, either of those will work. > PS. apologies for the poor formatting in my previous email. Forgott to > 'set tw=72' :S np :)
Re: Question on the latest errata
Hi Stuart, > > 1. Could there be negative consequences of not running fw_update or > > installboot before reboot? > > It means that you don't get the microcode updates, if any are available > for your cpu. Until I run fw_update, installboot and reboot again right? To put it differently, is the end result between # syspatch # reboot # fw_update # installboot -v sd0 # reboot and # syspatch # fw_update # installboot -v sd0 # reboot any different? > > 2. If no, is it still bad practice to run 'syspatch && reboot' as a > > cronjob? > > It depends whether you want to review patches before installing them, > for example to assess whether they're applicable to you, or the > potential risk of them breaking something. For some machines I do use > automatic updates (usually when there are multiple machines running a > service so it doesn't matter if one is down for a bit), for others it > would be more of a problem if it didn't come back up nicely afterwards > and there I'd prefer to run it by hand. Makes sense, thank you :) > regardless of whether the physical CPU on your VM host is an affected > AMD, this string won't match what fw_update is looking for, so the > microcode "firmware" package won't be installed anyway. Understood! Thank you for the explanation. PS. apologies for the poor formatting in my previous email. Forgott to 'set tw=72' :S
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
> > > Just applied the fix to the first affected AMD machine and all is well > > again. > > > > Would this be worth putting a ticket into Vultr to get them to make > > appropriate updates on their side? > > Yes (but I see you already did) > Here's the reply I got from Vultr about this: Thank you for contacting us. We are aware of OpenBSD instances dropping to ddb upon boot after the initial zenbleed patches went out. This was fixed as of the 015 patch that was released today: https://ftp.openbsd.org/pub/OpenBSD/patches/7.3/common/015_hvamdcpu.patch.sig If you have an OpenBSD instance that is still stuck at ddb and therefore cannot apply the 015 patch, please let us know, as there is a manual workaround we can do to get it to boot. After that, you can run syspatch again which should install that newest patch, and you should have no issues. Regarding the Zenbleed vulnerability itself, none of our AMD hosts are known to be vulnerable at this time as they are all running Milan and later CPUs. The CPU config provided to guests will say Rome, but that is provided for compatibility purposes and is not related to the actual host node CPU. We are continuing to monitor this vulnerability, and will be taking appropriate steps to mitigate it once the full impact has been determined.
Re: Installboot question
Hello, steve.shock...@shockley.net (Steven Shockley), 2023.07.25 (Tue) 16:34 (CEST): > I have a machine with two ATA drives in a softraid mirror. For the Zen > patch, do I run installboot on just sd2 (the softraid volume) or also sd0 > and sd1 (the physical disks)? Thanks. # installboot -v sd2 installboot figures that out by itself. Marcus
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
On Tue, Jul 25, 2023 at 10:42:25AM -0700, Kevin wrote: > On Tue, Jul 25, 2023 at 7:42 AM Theo de Raadt wrote: > > > It seems some of the smaller hypervisor companies didn't get the memo, > > and they are blocking the msr write to to set the chicken bit. > > > > They block it by raising an exception. > > They should IGNORE that bit if they allow setting it. > > > > I also have a strong suspicion some of them do not have the firmware > > fixes, and that the chickenbit-off state we read is true. > > > > Anyways, a brand new errata to skip setting the chickenbit on such > > hypervisors is going out the door right now. > > > > > I just fucking love you guys. > > Thank you. > > Just applied the fix to the first affected AMD machine and all is well > again. > > Would this be worth putting a ticket into Vultr to get them to make > appropriate updates on their side? Yes (but I see you already did)
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
I made a ticket with Vultr I believe they already know about it! I just fucking love you guys. Thank you. Just applied the fix to the first affected AMD machine and all is well again. Would this be worth putting a ticket into Vultr to get them to make appropriate updates on their side?
Re: Mounting an SD-card and an USB-stick
On Tue, Jul 25, 2023 at 06:08:00PM +0200, Karel Lucas wrote: > > Dear all, > > For a fresh install of openBSD, I want to mount an SD card or a USB stick on > an existing openBSD install, but don't know which device name to use. Maybe > someone can help me out? > You can check the device name to which they are attached by checking the dmesg or /var/log/messages. This is from attaching a card reader with multiple slots, but only one of them holding a card (sd4): $ dmesg ... umass0 at uhub0 port 12 configuration 1 interface 0 "Generic USB Storage" rev 2.10/12.09 addr 9 umass0: using SCSI over Bulk-Only scsibus5 at umass0: 2 targets, initiator 0 sd2 at scsibus5 targ 1 lun 0: removable sd3 at scsibus5 targ 1 lun 1: removable sd4 at scsibus5 targ 1 lun 2: removable sd4: 30608MB, 512 bytes/sector, 62685184 sectors sd5 at scsibus5 targ 1 lun 3: removable If in doubt, you can then check which partitions that disk holds using disklabel: $ disklabel sd4 ... #size offset fstype [fsize bsize cpg] c: 626851840 unused i: 62676992 8192 MSDOS In this case, a single MSDOS partition (i) that you can then mount: # mount /dev/sd4i /mnt Cheers Zé --
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
On Tue, Jul 25, 2023 at 7:42 AM Theo de Raadt wrote: > It seems some of the smaller hypervisor companies didn't get the memo, > and they are blocking the msr write to to set the chicken bit. > > They block it by raising an exception. > They should IGNORE that bit if they allow setting it. > > I also have a strong suspicion some of them do not have the firmware > fixes, and that the chickenbit-off state we read is true. > > Anyways, a brand new errata to skip setting the chickenbit on such > hypervisors is going out the door right now. > I just fucking love you guys. Thank you. Just applied the fix to the first affected AMD machine and all is well again. Would this be worth putting a ticket into Vultr to get them to make appropriate updates on their side?
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
Everything is working after the newest patch! Thank you all! On 7/25/23 11:18 AM, Jag Talon wrote: I ran into the same issue with the "2048.00 MB AMD High Performance, 2 vCPU" on my end. Fortunately I had a snapshot and I was able to roll back. Here's my dmesg output if that's helpful: OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2130558976 (2031MB) avail mem = 2046648320 (1951MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5b70 (9 entries) bios0: vendor Vultr bios0: Vultr VHP acpi0 at bios0: ACPI 3.0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET MCFG WAET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD EPYC-Rome Processor, 1996.53 MHz, 17-31-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD EPYC-Rome Processor, 1996.51 MHz, 17-31-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu1: smt 1, core 0, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 1 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured acpicmos0 at acpi0 "ACPI0010" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 vga1 at pci0 dev 1 function 0 "Bochs VGA" rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci1 at ppb0 bus 1 virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio0 at virtio0: address 56:00:04:81:d8:d4 virtio0: msix shared ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 vendor "Red Hat", unknown product 0x000e rev 0x00 pci3 at ppb2 bus 3 "Intel 6300ESB WDT" rev 0x00 at pci3 dev 1 function 0 not configured ppb3 at pci0 dev 2 function 2 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci4 at ppb3 bus 4 xhci0 at pci4 dev 0 function 0 vendor "Red Hat", unknown product 0x000d rev 0x01: apic 0 int 22, xHCI 0.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Red Hat xHCI root hub" rev 3.00/1.00 addr 1 ppb4 at pci0 dev 2 function 3 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci5 at ppb4 bus 5 virtio1 at pci5 dev 0 function 0 "Qumranet Virtio 1.x Storage" rev 0x01 vioblk0 at virtio1 scsibus1 at vioblk0: 1 targets sd0 at scsibus1 targ 0 lun 0: sd0: 61440MB, 512 bytes/sector, 125829120 sectors virtio1: msix per-VQ ppb5 at pci0 dev 2 function 4 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci6 at ppb5 bus 6 virtio2 at pci6 dev 0 function 0 vendor "Qumranet", unknown product 0x1045 rev 0x01 viomb0 at virtio2 virtio2: apic 0 int 22 ppb6 at pci0 dev 2 function 5 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci7 at ppb6 bus 7 virtio3 at pci7 dev 0 function 0 "Qumranet Virtio 1.x RNG" rev 0x01 viornd0 at virtio3 virtio3: msix shared ppb7 at pci0 dev 2 function 6 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci8 at ppb7 bus 8 ppb8 at pci0 dev 2 function 7 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci9 at ppb8
Re: Mounting an SD-card and an USB-stick
On Tue, 25 Jul 2023 18:08:00 +0200 Karel Lucas wrote: > Dear all, > > For a fresh install of openBSD, I want to mount an SD card or a USB > stick on an existing openBSD install, but don't know which device > name to use. Maybe someone can help me out? > Hello, a newbie trying to help a newbie, since I had to learn that too. To see all available devices to be mounted, use sysctl(8) to read a kernel variable: sysctl hw.disknames In my case it outputs: > hw.disknames=sd0:c9aecebcec28de24 So my I've got only sd0 to mount. If you have just plugged in a device, it will show up in the recent dmesg(8) output (use tail(1) to get the most recent lines): dmesg | tail However, you generally can't mount a whole device, but its partition. You can show them with disklabel(8) (as root): doas disklabel sd0 To mount partition i of device sd0 to /mnt/usb (directory must exist!), you would use: doas mount_msdos /dev/sd0i /mnt/usb Or some other mount command, depending on the file system that partition if formatted with. The above is for FAT. See mount(8) for details. Hope this helps. -- Maja
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
On Mon, Jul 24, 2023 at 11:37:12PM -0700, Kevin wrote:
> After applying today's zenbleed patches and running fw_update and
> installboot -v sd0, ALL of our AMD servers running 7.3 at Vultr that
> were--as part of the patch process--rebooted are now dead in the water and
> won't boot.
>
I experienced the same issue with Hetzner VPS. Booting previous kernel
did the trick for me.
OpenBSD 7.3 (GENERIC.MP) #2: Mon Jul 24 13:01:48 MDT 2023
r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4177379328 (3983MB)
avail mem = 4031373312 (3844MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5ab0 (11 entries)
bios0: vendor Hetzner version "2017" date 11/11/2017
bios0: Hetzner vServer
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC HPET MCFG WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC Processor, 2445.68 MHz, 17-31-00
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache,
512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
kernel: protection fault trap, code=0
Stopped at cpu_fix_msrs+0x1a4: wrmsr
ddb{0}> rebooting...
OpenBSD 7.3 (GENERIC.MP) #0: Wed Jul 12 05:09:49 MDT 2023
r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4177379328 (3983MB)
avail mem = 4031361024 (3844MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5ab0 (11 entries)
bios0: vendor Hetzner version "2017" date 11/11/2017
bios0: Hetzner vServer
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S5
acpi0: tables DSDT FACP APIC HPET MCFG WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC Processor, 2445.62 MHz, 17-31-00
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD EPYC Processor, 2446.02 MHz, 17-31-00
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: AMD EPYC Processor, 2445.66 MHz, 17-31-00
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,IBPB,IBRS,STIBP,SSBD,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB
64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu2: smt 0, core 2, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xb000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001
com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo
acpicmos0 at acpi0
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
"ACPI
Re: Routing multiple IPv4 blocks
An individual was kind enough to reach out and inform me that they believe I should have not said "I am sure you were not trying to be 'technical'..." but instead "I am sure you were trying not to be 'technical'..." as the former sounded like I was suggesting Stuart was giving bad advice by being lazy. In the event that was the interpretation by other people, most notably Stuart; then I apologize. The intent of what I was saying was merely to add a potentially relevant "technical" detail that for most people is _not_ relevant. For almost all things (short of FOL proofs), there are exceptions; so it is understandable and even desirable often times to be "loose" with the technical details. When one has gathered enough preliminary knowledge, then they can revisit some of those things with a more precise perspective (e.g., in physics one learns about Newtonian mechanics before relativity even though "technically" it is not quite correct or Ohm's law despite it rather obviously falling apart when resistance is 0 or even approaches 0). I said what I said because I didn't want it to be misconstrued as "one upping" Stuart with the rather obnoxious "actually" response (https://www.youtube.com/watch?v=GAyt3KUVkrY) which of course is exactly what I ended up doing. :( I do believe that stating network or broadcast addresses shouldn't be assigned to a host is a reasonable and perhaps correct thing since most people won't find themselves in the position of needing or even desiring to use /31 or /32 IPv4 networks.
Mounting an SD-card and an USB-stick
Dear all, For a fresh install of openBSD, I want to mount an SD card or a USB stick on an existing openBSD install, but don't know which device name to use. Maybe someone can help me out?
Installboot question
I have a machine with two ATA drives in a softraid mirror. For the Zen patch, do I run installboot on just sd2 (the softraid volume) or also sd0 and sd1 (the physical disks)? Thanks.
Re: Routing multiple IPv4 blocks
On 7/25/23 06:03, Stuart Henderson wrote: 217.169.18.56 is a network address (mask it out against the netmask, the remaining "host bits" are all zeroes), you cannot use this (or the broadcast address) as a host address I am sure you were not trying to be "technical"; but for people that don't already possess the knowledge, I just wanted to say that there are two exceptions to the rule that you shouldn't assign the network or broadcast address to a host: /31 (https://www.rfc-editor.org/rfc/rfc3021) and /32 networks. I also have a /29 network of globally routable IPv4 addresses, and I use all 8 of those precious IPs by carving out 8 /32s and assigning each one to a host.
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
I ran into the same issue with the "2048.00 MB AMD High Performance, 2 vCPU" on my end. Fortunately I had a snapshot and I was able to roll back. Here's my dmesg output if that's helpful: OpenBSD 7.3 (GENERIC.MP) #1125: Sat Mar 25 10:36:29 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2130558976 (2031MB) avail mem = 2046648320 (1951MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5b70 (9 entries) bios0: vendor Vultr bios0: Vultr VHP acpi0 at bios0: ACPI 3.0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET MCFG WAET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD EPYC-Rome Processor, 1996.53 MHz, 17-31-00 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD EPYC-Rome Processor, 1996.51 MHz, 17-31-00 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line 8-way L2 cache, 16MB 64b/line 16-way L3 cache cpu1: smt 1, core 0, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 1 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured acpicmos0 at acpi0 "ACPI0010" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 vga1 at pci0 dev 1 function 0 "Bochs VGA" rev 0x02 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci1 at ppb0 bus 1 virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio0 at virtio0: address 56:00:04:81:d8:d4 virtio0: msix shared ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci2 at ppb1 bus 2 ppb2 at pci2 dev 0 function 0 vendor "Red Hat", unknown product 0x000e rev 0x00 pci3 at ppb2 bus 3 "Intel 6300ESB WDT" rev 0x00 at pci3 dev 1 function 0 not configured ppb3 at pci0 dev 2 function 2 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci4 at ppb3 bus 4 xhci0 at pci4 dev 0 function 0 vendor "Red Hat", unknown product 0x000d rev 0x01: apic 0 int 22, xHCI 0.0 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Red Hat xHCI root hub" rev 3.00/1.00 addr 1 ppb4 at pci0 dev 2 function 3 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci5 at ppb4 bus 5 virtio1 at pci5 dev 0 function 0 "Qumranet Virtio 1.x Storage" rev 0x01 vioblk0 at virtio1 scsibus1 at vioblk0: 1 targets sd0 at scsibus1 targ 0 lun 0: sd0: 61440MB, 512 bytes/sector, 125829120 sectors virtio1: msix per-VQ ppb5 at pci0 dev 2 function 4 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci6 at ppb5 bus 6 virtio2 at pci6 dev 0 function 0 vendor "Qumranet", unknown product 0x1045 rev 0x01 viomb0 at virtio2 virtio2: apic 0 int 22 ppb6 at pci0 dev 2 function 5 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci7 at ppb6 bus 7 virtio3 at pci7 dev 0 function 0 "Qumranet Virtio 1.x RNG" rev 0x01 viornd0 at virtio3 virtio3: msix shared ppb7 at pci0 dev 2 function 6 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci8 at ppb7 bus 8 ppb8 at pci0 dev 2 function 7 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci9 at ppb8 bus 9 ppb9 at pci0 dev 3 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 23
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
Snapshots got that diff about 8 hours earlier. > For what it’s worth, my Vultr VPS machine is running snapshots and updated > without issue. > > Hope this helps as a clue! > > On Tue, Jul 25, 2023 at 10:45 AM Theo de Raadt wrote: > > > It seems some of the smaller hypervisor companies didn't get the memo, > > and they are blocking the msr write to to set the chicken bit. > > > > They block it by raising an exception. > > They should IGNORE that bit if they allow setting it. > > > > I also have a strong suspicion some of them do not have the firmware > > fixes, and that the chickenbit-off state we read is true. > > > > Anyways, a brand new errata to skip setting the chickenbit on such > > hypervisors is going out the door right now. > > > > > > -- > RD
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
For what it’s worth, my Vultr VPS machine is running snapshots and updated without issue. Hope this helps as a clue! On Tue, Jul 25, 2023 at 10:45 AM Theo de Raadt wrote: > It seems some of the smaller hypervisor companies didn't get the memo, > and they are blocking the msr write to to set the chicken bit. > > They block it by raising an exception. > They should IGNORE that bit if they allow setting it. > > I also have a strong suspicion some of them do not have the firmware > fixes, and that the chickenbit-off state we read is true. > > Anyways, a brand new errata to skip setting the chickenbit on such > hypervisors is going out the door right now. > > > -- RD
Huawei LTE USB stick not working
I've come across a somewhat older HUAWEI LTE Stick, it says HUAWEI E3372h-320. [full dmesg below] umsm0 at uhub0 port 6 configuration 1 interface 0 "HUAWEI_MOBILE HUAWEI_MOBILE" rev 2.00/1.02 addr 7 umsm0 detached umsm0 at uhub0 port 6 configuration 1 interface 0 "HUAWEI_MOBILE HUAWEI_MOBILE" rev 2.00/1.02 addr 7 ucom0 at umsm0 umsm1 at uhub0 port 6 configuration 1 interface 1 "HUAWEI_MOBILE HUAWEI_MOBILE" rev 2.00/1.02 addr 7 There is no network interface. It shows one ucom, but that seems to be a reporting interface only. When I cu(1) with the ucom there is a stream of rssi messages. I can't make it connect over ppp using this ucom. Any ideas how to make this one work? tilo dmesg and usbdevs -v: OpenBSD 7.3-current (GENERIC.MP) #1268: Fri Jun 30 10:27:20 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17087328256 (16295MB) avail mem = 16549789696 (15783MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xe6f40 (27 entries) bios0: vendor Insyde Corp. version "V1.07" date 09/05/2014 bios0: Acer Aspire VN7-791 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI FPDT MSDM ASF! HPET APIC MCFG SSDT BOOT LPIT ASPT DBGP SSDT SSDT SSDT SSDT DMAR acpi0: wakeup devices P0P1(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S3) HDEF(S4) PXSX(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz, 3292.61 MHz, 06-3c-03 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz, 3292.40 MHz, 06-3c-03 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz, 3292.45 MHz, 06-3c-03 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz, 3292.47 MHz, 06-3c-03 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 6MB 64b/line 12-way L3 cache cpu3: smt 1, core 1, package 0 cpu4 at mainbus0: apid 4 (application processor) cpu4: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz, 3292.50 MHz, 06-3c-03 cpu4: 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,
Re: ddb panic on 7.3 after applying 2023-07-24 zenbleed patches
It seems some of the smaller hypervisor companies didn't get the memo, and they are blocking the msr write to to set the chicken bit. They block it by raising an exception. They should IGNORE that bit if they allow setting it. I also have a strong suspicion some of them do not have the firmware fixes, and that the chickenbit-off state we read is true. Anyways, a brand new errata to skip setting the chickenbit on such hypervisors is going out the door right now.
Re: Upgrade: Unbound constraint let fw_update always fail
My unattended upgrade happend like that: - I took up unbound - sysupgrade - 1st fw_update (this probbly is okay) - reboot - installation of the sets - 2nd fw_update (this fails because unattended, local Unbound is down) - reboot - 3rd fw_update (this fails because unattended, local Unbound is down) - syspatch (this fails as well) I finally took up my dev environment and run fw_update & syspatch. If the first fw_update is enough to be sure about a sucessfull installation then case solved, just keeping the good stuff from the thread.. -- Daniele Bonini Jul 25, 2023 15:28:57 Daniele B. : > Thanks Steve, > > Jul 25, 2023 14:41:53 Steve Litt : > >> chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i >> resolv.conf >> >> I also don't understand why you start unbound manually instead of from >> computer initialization. It sounds like if unbound started before >> fw_update, there would be no problem > > I also would like the possibility to rewind my mindset to two years ago to > have the proper > technical answer when I need it.. However I try to answer you.. > > Basically I think while experimenting I found interesting the possibility to > have full > control over my dev environment and decide when to take up/down all my needs, > including the network.. > Indeed I was so happy about my findings that I decided to give to it also a > graphical interface > to make it more amousing. :D > > If you want to help, in my script to switch the dev environment down I miss > the possibility to take down Unbound > that one time launched is very hard to switch off, still my script doesn't do > that.. > > I think the suggestion to implement an ad-hoc network settings for the > unattended installation could > be interesting also to cover that few cases of disparate accesses to > Internet, indeed. But here you should > have a some more case studies than me. > > -- Daniele Bonini > > Jul 25, 2023 14:41:53 Steve Litt : > >> chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i >> resolv.conf >> >> I also don't understand why you start unbound manually instead of from >> computer initialization. It sounds like if unbound started before >> fw_update, there would be no problem.
Re: Upgrade: Unbound constraint let fw_update always fail
Thanks Steve, Jul 25, 2023 14:41:53 Steve Litt : > chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i > resolv.conf > > I also don't understand why you start unbound manually instead of from > computer initialization. It sounds like if unbound started before > fw_update, there would be no problem I also would like the possibility to rewind my mindset to two years ago to have the proper technical answer when I need it.. However I try to answer you.. Basically I think while experimenting I found interesting the possibility to have full control over my dev environment and decide when to take up/down all my needs, including the network.. Indeed I was so happy about my findings that I decided to give to it also a graphical interface to make it more amousing. :D If you want to help, in my script to switch the dev environment down I miss the possibility to take down Unbound that one time launched is very hard to switch off, still my script doesn't do that.. I think the suggestion to implement an ad-hoc network settings for the unattended installation could be interesting also to cover that few cases of disparate accesses to Internet, indeed. But here you should have a some more case studies than me. -- Daniele Bonini Jul 25, 2023 14:41:53 Steve Litt : > chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i > resolv.conf > > I also don't understand why you start unbound manually instead of from > computer initialization. It sounds like if unbound started before > fw_update, there would be no problem.
Re: Upgrade: Unbound constraint let fw_update always fail
Daniele B. said on Tue, 25 Jul 2023 11:29:09 +0200 (GMT+02:00) >Hello Stuart, thanks for this one.. > >Yes, I agree that the final solution could be only the replace my >listed nameserver. But do you remember I was using also the unmutable >flag on resolv.conf ? :D chattr -i resolv.conf && echo nameserver 8.8.8.8 >> resolv.conf && chattr +i resolv.conf I also don't understand why you start unbound manually instead of from computer initialization. It sounds like if unbound started before fw_update, there would be no problem. SteveT Steve Litt Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm
Re: Question on the latest errata
On 2023-07-25, Johannes Thyssen Tishman wrote: > Hi, > > I have a vps running OpenBSD 7.3 STABLE amd64 and I have a cronjob that runs > once a day to install new errata patches (if available) and reboot after > patching. With the last errata patches (amd firmware, wscons) I realized (too > late) that I should've followed the steps described on the errata file before > the system was rebooted. Luckily (I suppose) the server was able to boot, so I > ran fw_update and installboot and rebooted again. Now even though everything > seems to be running just fine, I wanted to make sure by asking here: > > 1. Could there be negative consequences of not running fw_update or > installboot > before reboot? It means that you don't get the microcode updates, if any are available for your cpu. > 2. If no, is it still bad practice to run 'syspatch && reboot' as a cronjob? It depends whether you want to review patches before installing them, for example to assess whether they're applicable to you, or the potential risk of them breaking something. For some machines I do use automatic updates (usually when there are multiple machines running a service so it doesn't matter if one is down for a bit), for others it would be more of a problem if it didn't come back up nicely afterwards and there I'd prefer to run it by hand. > 3. fw_update did not install anything. Is this a consequence of the early > reboot? Or is this perhaps the reason why the system was able to boot after > the > patch? For this recent erratum, 1) syspatch needs to be run to pick up the fw_update change (so that it knows to pick up the new amd-firmware package for AMD cpus), and so the new boot loaders with the AMD microcode loader are installed to /usr/mdec. 2) you must have an AMD CPU in order for that to match in fw_update anyway (matching the usual CPU identifier strings used by AMD on their processors). 3) the 'live' boot loader must be updated from /usr/mdec files via installboot. > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: QEMU Virtual CPU version 2.5+, 2844.97 MHz, 06-06-03 > cpu0: > FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF regardless of whether the physical CPU on your VM host is an affected AMD, this string won't match what fw_update is looking for, so the microcode "firmware" package won't be installed anyway. (also for the case of a VM, microcode loading would be done by the VM host not the guest)
Re: Upgrade: Unbound constraint let fw_update always fail
Hello Stuart, thanks for this one.. Yes, I agree that the final solution could be only the replace my listed nameserver. But do you remember I was using also the unmutable flag on resolv.conf ? :D I do not want to awake the lions and indeed I'm much happy about my *unbound system* but having a free to use failover network setting for the specific case of the unattended installation sounds enough attractive, isn it? Jul 25, 2023 11:00:27 Stuart Henderson : > On 2023-07-25, Daniele B. wrote: >> >> Hello, >> >> Just coming from my fresh upgrade to OpenBSD 7.3 and thanks again for >> it.. ;) >> >> No particular problem except my realization that with my settings >> (unbound started manually) fw_update goes to fail (all the three >> attempts) on each (unattended) upgrade. If fw_update happens to be a >> constraint for a successful upgrade, and luckily was not the case this >> time, bad times for sure.. >> >> Any suggestion about it? Thanks! > > List a nameserver other than just your local machine in resolv.conf.
Question on the latest errata
Hi, I have a vps running OpenBSD 7.3 STABLE amd64 and I have a cronjob that runs once a day to install new errata patches (if available) and reboot after patching. With the last errata patches (amd firmware, wscons) I realized (too late) that I should've followed the steps described on the errata file before the system was rebooted. Luckily (I suppose) the server was able to boot, so I ran fw_update and installboot and rebooted again. Now even though everything seems to be running just fine, I wanted to make sure by asking here: 1. Could there be negative consequences of not running fw_update or installboot before reboot? 2. If no, is it still bad practice to run 'syspatch && reboot' as a cronjob? 3. fw_update did not install anything. Is this a consequence of the early reboot? Or is this perhaps the reason why the system was able to boot after the patch? Thank you very much. Below the output of dmesg if necessary. Kind regards, Johnnes OpenBSD 7.3 (GENERIC) #2: Mon Jul 24 13:00:03 MDT 2023 r...@syspatch-73-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 2130554880 (2031MB) avail mem = 2046758912 (1951MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5b40 (9 entries) bios0: vendor SeaBIOS version "1.14.0-2" date 04/01/2014 bios0: QEMU Standard PC (i440FX + PIIX, 1996) acpi0 at bios0: ACPI 1.0 acpi0: sleep states S3 S4 S5 acpi0: tables DSDT FACP APIC HPET WAET acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: QEMU Virtual CPU version 2.5+, 2844.97 MHz, 06-06-03 cpu0: FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF cpu0: 64KB 64b/line 2-way D-cache, 64KB 64b/line 2-way I-cache cpu0: 512KB 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 1000MHz ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpihpet0 at acpi0: 1 Hz acpiprt0 at acpi0: bus 0 (PCI0) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0 com0 at acpi0 COM1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo acpicmos0 at acpi0 "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured "ACPI0010" at acpi0 not configured acpicpu0 at acpi0: C1(@1 halt!) pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00 pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, channel 0 wired to compatibility, channel 1 wired to compatibility pciide0: channel 0 disabled (no drives) atapiscsi0 at pciide0 channel 1 drive 0 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: removable cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 uhci0 at pci0 dev 1 function 2 "Intel 82371SB USB" rev 0x01: apic 0 int 11 piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x03: apic 0 int 9 iic0 at piixpm0 vga1 at pci0 dev 2 function 0 "Qumranet Virtio 1.x GPU" rev 0x01 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 vio0 at virtio0: address 52:54:5d:5f:e7:24 virtio0: msix shared virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00 vioblk0 at virtio1 scsibus2 at vioblk0: 1 targets sd0 at scsibus2 targ 0 lun 0: sd0: 51200MB, 512 bytes/sector, 104857600 sectors virtio1: msix shared virtio2 at pci0 dev 5 function 0 "Qumranet Virtio Memory Balloon" rev 0x00 viomb0 at virtio2 virtio2: apic 0 int 10 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 usb0 at uhci0: USB revision 1.0 uhub0 at usb0 configuration 1 interface 0 "Intel UHCI root hub" rev 1.00/1.00 addr 1 uhidev0 at uhub0 port 1 configuration 1 interface 0 "QEMU QEMU USB Tablet" rev 2.00/0.00 addr 2 uhidev0: iclass 3/0 ums0 at uhidev0: 3 buttons, Z dir wsmouse1 at ums0 mux 0 vscsi0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (55955f4fadaae104.a) swap on sd0b dump on sd0b fd0 at fdc0 drive 1: density unknown
Re: Upgrade: Unbound constraint let fw_update always fail
On 2023-07-25, Daniele B. wrote: > > Hello, > > Just coming from my fresh upgrade to OpenBSD 7.3 and thanks again for > it.. ;) > > No particular problem except my realization that with my settings > (unbound started manually) fw_update goes to fail (all the three > attempts) on each (unattended) upgrade. If fw_update happens to be a > constraint for a successful upgrade, and luckily was not the case this > time, bad times for sure.. > > Any suggestion about it? Thanks! List a nameserver other than just your local machine in resolv.conf.
Upgrade: Unbound constraint let fw_update always fail
Hello, Just coming from my fresh upgrade to OpenBSD 7.3 and thanks again for it.. ;) No particular problem except my realization that with my settings (unbound started manually) fw_update goes to fail (all the three attempts) on each (unattended) upgrade. If fw_update happens to be a constraint for a successful upgrade, and luckily was not the case this time, bad times for sure.. Any suggestion about it? Thanks! -- Daniele Bonini
