Re: [7.3/i386] pf-badhost - Illegal instruction (core dumped)
Unfortunately it looks like sh -x does not trace into functions, and it is something inside "main" which is crashing: > > set -x or something. > Sorry, I should have started with that. > > test73# doas -u _pfbadhost pf-badhost -O openbsd > [ ... ] > + command -v typeset > + > /dev/null > + 2>&1 > + main -O openbsd > Illegal instruction > [ ... ] > Illegal instruction (core dumped) > > No blocklist changes... > Illegal instruction (core dumped) Both sh and ksh seem to behave that way, but bash will trace inside functions. Try calling the script with 'bash -x' and hopefully you can pinpoint which binary called by main() is crashing. -Andrew
curl-8.0.1 exists in two non-comparable versions (Someone forgot to bump a REVISION)
This happened when I ran 'pkg_add -u' after upgrading an i386 system from 7.2 to 7.3: andrew@bilbo:~$ doas pkg_add -u quirks-6.121 signed on 2023-04-22T01:10:43Z quirks-6.42->6.121: ok bash-5.2.15:libiconv-1.17->1.17: ok bash-5.2.15:gettext-runtime-0.21p1->0.21.1: ok bash-5.1.16->5.2.15: ok Couldn't find ngtcp2 in first signature Couldn't find nghttp3 in first signature Couldn't find ngtcp2_crypto_openssl in first signature Couldn't find www/nghttp3 in first signature Couldn't find net/ngtcp2 in first signature Error: curl-8.0.1 exists in two non-comparable versions Someone forgot to bump a REVISION curl-8.0.1,6,@nghttp2-1.49.0,c.96.2,crypto.50.0,nghttp2.0.20,pthread.26.2,ssl.53.0,z.7.0 vs. curl-8.0.1,6,@nghttp2-1.52.0,@nghttp3-0.9.0,@ngtcp2-0.13.1,c.97.0,crypto.50.2,nghttp2.0.21,nghttp3.0.1,ngtcp2.1.0,ngtcp2_crypto_openssl.0.0,pthread.27.0,ssl.53.2,z.7.0 curl-8.0.1:ngtcp2-0.13.1: ok curl-8.0.1:nghttp3-0.9.0: ok curl-8.0.1:nghttp2-1.49.0->1.52.0: ok Couldn't find nghttp3 in first signature Couldn't find ngtcp2 in first signature Couldn't find net/ngtcp2 in first signature Couldn't find www/nghttp3 in first signature Couldn't find ngtcp2_crypto_openssl in first signature Error: curl-8.0.1 exists in two non-comparable versions Someone forgot to bump a REVISION curl-8.0.1,6,@nghttp2-1.49.0,c.96.2,crypto.50.0,nghttp2.0.20,pthread.26.2,ssl.53.0,z.7.0 vs. curl-8.0.1,6,@nghttp2-1.52.0,@nghttp3-0.9.0,@ngtcp2-0.13.1,c.97.0,crypto.50.2,nghttp2.0.21,nghttp3.0.1,ngtcp2.1.0,ngtcp2_crypto_openssl.0.0,pthread.27.0,ssl.53.2,z.7.0 curl-8.0.1->8.0.1: ok iperf3-3.10.1->3.12: ok libsodium-1.0.18p1->1.0.18p1: ok par2cmdline-0.7.4p0->0.7.4p0: ok smartmontools-7.3->7.3p0: ok vim-9.0.0192-no_x11->9.0.1388-no_x11: ok xz-5.2.5p2->5.4.1: ok Read shared items: ok andrew@bilbo:~$ cat /etc/installurl https://cdn.openbsd.org/pub/OpenBSD It seems that it succeeded in the end, but what happened? Is there a 7.3-stable curl pkg with new dependencies but the same revision as 7.3? (Or maybe a 7.2-stable pkg, since I was apparently at 8.0.1 already?) Thanks, Andrew
Re: Unable to receive dhcplease from ISP
On Sat, Apr 1, 2023 at 10:25 PM Nick Holland wrote: > I can replicate that with my ISP if I follow your steps. > With my service, if I change the MAC address of the machine attached to > my cable modem, I have to power cycle the cable modem to get a new > DHCP lease. > > Not saying that is your problem, but you never indicated you power > cycled the modem...which I have found critical for the last 20+ years. Also, sometimes you have to release the old lease (on the previously-active device, of course), or wait for it to expire. Usually that would let me grab a new lease on a different device without power-cycling the modem, and would occasionally be necessary even after a modem reset. This used to be accomplished with 'dhclient -r', but I'm not sure how to do that with dhcpleased, even after reading the man pages... ENOTIMPLEMENTED or am I overlooking something? I also found dhcpleasectl's behavior of forcibly renewing a lease by default, but needing a flag to just show the lease info, rather backwards -- and was quite surprised that it didn't require root to renew. I may be in the minority though. -Andrew
Re: BiDi sfp in ix
On Wed, Jan 11, 2023 at 11:53 AM Hrvoje Popovski wrote: > Hi all, > > claudio@ suggested to try same setup with FreeBSD. So I've tried FreeBSD > and Linux and results are same, 1G BiDi from FS.COM coded for Cisco > won't work with Intel 82599 10G card. > If I boot FreeBSD and Linux with that sfp in 82599 or X710 card that > interface will be disabled at boot and won't show up in OS. > On OpenBSD i could see it but mac address is 00:00:00:00:00:00 > > I've tried all combinations with unsupported_sfp statements for FreeBSD > and Linux but I couldn't see that interface in OS. > If I put that sfp in card after boot status is no carrier whatever I do, > at least on FreeBSD. I'm still playing with Linux.. > > > it seems that I've missed out all football here :) Definitely seems like the "Intel NIC unsupported SFP" behavior, nothing specific to BiDi. (But thanks to everyone in this thread for educating me about BiDi! I doubt I'll be using it any time soon, but it's neat how it works, and I definitely see the appeal if you have a limited number of fibres.) Note that in Linux, it actually disables the card until you unload and reload the driver, for example: Dec 8 17:01:19 lambda kernel: [ 1428.680975] ixgbe :24:00.0 enp36s0f0: NIC Link is Down Dec 8 17:01:19 lambda systemd-networkd[83876]: enp36s0f0: Lost carrier Dec 8 17:01:24 lambda kernel: [ 1433.830686] ixgbe :24:00.0: failed to initialize because an unsupported SFP+ module type was detected. Dec 8 17:01:24 lambda kernel: [ 1433.832843] ixgbe :24:00.0: Reload the driver after installing a supported module. Dec 8 17:01:24 lambda kernel: [ 1433.852297] ixgbe :24:00.0: removed PHC on enp36s0f0 Dec 8 17:01:24 lambda systemd-networkd[83876]: enp36s0f0: Link DOWN That was with an Intel X520-DA2 (82599). I had to 'rmmod ixgbe' and then 'modprobe ixgbe' (optionally with 'allow_unsupported_sfp=1') to get the card active again, even with an Intel SFP+ module. Apparently there is a bit you can toggle in the EEPROM to make that setting permanent in all OSes: https://forums.servethehome.com/index.php?threads/patching-intel-x520-eeprom-to-unlock-all-sfp-transceivers.24634/page-3#post-324427 Note that this only applies to the 500 series cards (ix), the 700 series (ixl) have a different EEPROM that doesn't easily allow unsupported modules, although in my experience they do allow more modules, e.g. Finisar, and AFAIK don't require reloading the driver after swapping in a "supported" SFP. I'm not exactly sure how the vendor-lock works, but I think it looks at the "Vendor OUI" bits in the SFP's EEPROM. My FS.com generic 10GBASE-SR modules have 00:00:00 there, while an "Intel" one from FS has 00:1b:21, but still the FS vendor name and PN. I don't know if OpenBSD's 'ifconfig transceiver' reports all of that, but Linux 'ethtool -m ' does. -Andrew
Re: serial console works only if system is booted from it
On Mon, Jul 25, 2022 at 9:01 PM Todd C. Miller wrote: > > On Sun, 24 Jul 2022 23:50:11 -0700, Kastus Shchuka wrote: > > > Apparently, restarting getty on tty00 was not enough. > > After reboot, I got login prompt on tty00 line. > > Running "ttyflags -a" as root would probably also fix it without > the need for a reboot. This is probably worth a mention in the ttys(5) man page. It's one of those things that once you've worked through it, you know, but it's not at all obvious that HUP-ing init applies changes from every other column but NOT any flags changes. I think the wording NetBSD has [1] is decent: "Nota Bene: Sending SIGHUP to init(8) does not change the state of the various tty(4) device flags listed above; the ttyflags(8) program must be run for changes in those flags to take effect on the devices." I'm pretty sure I tried 'local' on some Dell servers but it didn't work for me, on either the physical port or IPMI Serial-over-LAN; 'softcar' did the trick in my case. Without that I get the same issue -- getty only works if the device is also the boot console. Thanks, -Andrew [1] http://man.bsd.lv/NetBSD-9.2/ttys
Re: No login prompt on console ttyC0 after boot when using "set tty com0"
On Wed, Jun 29, 2022 at 8:53 PM Ted Wynnychenko wrote: > > Hello > I was wondering if there is anything I could do to help figure this out. > I do not have the requisite knowledge to even begin to understand why the > kernel does not configure the vga output when boot.conf redirects to com0. Look for a "redirection after boot" setting in your BIOS and try disabling that. The behavior you've described of both physical and serial consoles working at the boot prompt _without_ 'set tty com0' seems to indicate the BIOS is still handling redirection from keyboard/video to serial, and my guess is that when OpenBSD initializes the port for a serial console, it causes something in the BIOS-linked local keyboard/vga to go wonky (wsdisplay at vga1 not configured). Note that in UEFI mode, "wsdisplay at vga1 not configured" would be expected, as efifb takes over: $ dmesg|egrep 'wsdisplay|fb|vga|com[0-9]' vga1 at pci7 dev 0 function 0 "Matrox MGA G200eR" rev 0x01 wsdisplay at vga1 not configured com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo com1: console efifb0 at mainbus0: 1280x1024, 32bpp wsdisplay0 at efifb0 mux 1 wsdisplay0: screen 0-5 added (std, vt100 emulation) You might give UEFI mode a try, to see if efifb works better than the vga console. Redirection after boot is probably the more important setting though. Note that the login prompt appearing on a console (spawning a getty as configured in /etc/ttys) and the bootloader/kernel console device are independent settings. -Andrew
Re: ikev2 fails with mschap-v2
On Wed, Feb 23, 2022 at 10:10 PM wrote: > > I honestly have no idea where the logs would even be stored or what > the daemon runs as under MacOS 12.2.1 (Monterey). I don't have a Monterey system handy, but at least under macOS Catalina, VPN connections use setkey and racoon, similar to FreeBSD. Parts of the FreeBSD handbook's chapter on IPsec VPN may be relevant. The global conf is in /etc/racoon.conf, which has some logging options (and the associated man pages are installed), and there's a /var/log/racoon.log. setkey [ -P ] -D looks useful, but may not apply if it's failing before establishing SA entries. It also uses pppd, at least for L2TP over IPsec; a handy feature of which is support for your own scripts at /etc/ppp/ip-{up,down}. -Andrew
Re: Server certs expired higher up the chain, imaps and https
On Thu, Sep 30, 2021 at 4:00 PM Sebastian Benoit wrote: > This is an issue with an expired root/intermediate certificate (DST Root X3) > in use by Let's Encrypt. > > [...] > An errata has just been published, you can install it using syspatch. Thanks for the quick patch! I can verify this fixes fetching with ftp(1) from https servers which use Let's Encrypt certificates. It looks like this is "workaround 2" as described in this OpenSSL blog [1]? I'm surprised this was even needed, as I thought this problem was "fixed" last year after the AddTrust External CA Root expiration. It seems to be a similar case of "while waiting for widespread acceptance of a new root, the intermediate is cross-signed". In that case the cert chain configured on your web server was: - host cert, signed by: - InCommon RSA Server CA (or several other intermediates), signed by: - USERTrust RSA Certification Authority, signed by: - AddTrust External CA Root (which expired 2020-05-30; recommended not to send the top-level root since it's in the client store and thus redundant). A few years before that expiration, they got a new USERTrust root into browser/OS certificate stores, and intermediates like InCommon were also signed by this new root. Browsers would ignore that last USERTrust intermediate cert since it wasn't needed, but OpenSSL before 1.1 would still consider it expired because of that intermediate. This seems to be a similar scenario, with: - host cert, signed by: - Let's Encrypt R3, signed by: - ISRG Root X1, signed by: - DST Root CA X3 (which just expired) Likewise, there's a new ISRG Root X1. The "alternate" or "short" chain on your server would consist of host + R3, but certbot etc. are defaulting to the "long" chain which adds the X1 intermediate. Unlike the USERTrust/AddTrust scenario, where the intermediate USERTrust cert expired the same time as the AddTrust root, the intermediate X1 cert doesn't expire until 2024-09-30. That seems to go against accepted standards of not issuing certificates expiring after the issuer expires, but maybe they got special dispensation. (And apparently Android doesn't care if the root expired, if everything else is valid? Also, apparently there was a different, older R3 intermediate which _also_ expired a couple days ago.) The immediate fix last year was to stop sending the unnecessary expired intermediate cert (i.e. only send host cert and InCommon RSA, not the USERTrust intermediate), but I thought a fix went into LibreSSL then to not consider a host "expired" if it was possible to generate a valid chain of trust, regardless of "extra" certs sent by the server? Indeed, Let's Encrypt's own documentation [2] thinks that only LibreSSL < 3.2.0 is affected, but that is not the case. LibreSSL 3.3.2 in OpenBSD 6.9 (before the new syspatch) still considered servers expired, as does the somewhat older version bundled in macOS. -Andrew [1] https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/ [2] https://community.letsencrypt.org/t/openssl-client-compatibility-changes-for-let-s-encrypt-certificates/143816
Re: X11 SIGSEGV on VirtualBox
On Fri, Jun 18, 2021 at 3:24 PM Chris Narkiewicz wrote: > > I'm trying to run xenodm on VirtualBox VM. > VirtualBox 6.1.16_Ubuntu r140961 running on Ubuntu 20.04 with Intel > card. VM uses VMSVGA display with NO 3D acceleration. > > Fresh OpenBSD 6.9 install, but I tried latest snapshot - same problem. > > When starting Xorg server, it crashes with SIGSEGV. Does anybody know > why it happens? How can I generate some actionable debug output, such > as stacktrace, to help identify root cause? See the "How to get a core file out of the X server?" section of the Xenocara README [1]. You can then load Xorg and the core file into gdb/lldb. I think ports egdb may do better in some cases? Others who are more knowledgeable can weigh in on that. Potential workarounds: use the "vesa" X driver instead of "vmware"? I think VBox supports that but I don't remember. Another option is efifb/wsfb, which of course requires configuring the VM for UEFI mode and reinstalling. Both probably have lower performance though. -Andrew [1] https://github.com/openbsd/xenocara
Re: i386 "panic: pci_make_tag: bad request" after acpi sleep states
The missing 256 MB memory is probably stolen by the onboard video; it may be possible to reduce this to a smaller amount via a BIOS setting. You might also try fiddling with any available ACPI settings, e.g. sleep states, etc. (IIRC my VIA Epia M had a setting for whether "sleep" meant S1 or S3.) And I kinda wonder if that unexplained 10-pin CN2 header might be a serial port? Although since it doesn't show up in dmesg, maybe not... I was about to ask if the ACPI dump differed between PXE vs. hdd boot, but then I realized that was impossible to check given the crash. :-) If you could boot another OS from both hdd and PXE, maybe compare ACPI dumps to see if the BIOS changes something? Another workaround would be to 'boot -c' and disable acpi0, but that of course doesn't help fix the bug. -Andrew
Re: Help: System hang/Lockup using snapshots on Intel i5 NUC?
On Thu, Mar 5, 2020 at 4:48 PM Why 42? The lists account. wrote: > The OpenBSD kernel tells me that there is a serial port / UART (com0 at > isa0 port 0x3f8/8 irq 4: ns16550 ...) but I've taken the NUC to pieces > and I cannot see anything on the board that looks like a serial port > header. I found this Intel documentation about a dual serial port header on the NUCs (and the necessary cable), but I don't know if it applies to your model: https://www.intel.com/content/www/us/en/support/articles/17881/intel-nuc.html If there's no such header on yours, perhaps that serial port is remotely accessible, e.g. with IPMI serial-over-LAN or Intel vPro remote access? -Andrew
Re: dhcpd and unbound on a small LAN
On Mon, Jan 6, 2020 at 9:26 AM Sonic wrote: > > You have it backwards, let dhcp use the information in unbound to > assign the reserved address: > === > host alice { > hardware ethernet 20:9e:02:f5:93:60; > fixed-address alice.home.lan; > option host-name "alice"; > } > === This is how I do it too, except simplified further by setting the use-host-decl-names option at a higher scope (see dhcpd.conf(5)); then you don't need "option host-name ..." for each host. > Start unbound before dhcpd in your rc.conf.local (ex): > === > unbound_flags="-c /var/unbound/etc/unbound.conf" > dhcpd_flags="em0" > === The order of directives in rc.conf.local does not matter, as the order of base daemons is hardcoded in /etc/rc (and does indeed start unbound before dhcpd); as a matter of fact, 'rcctl enable foo' will sort the file! (I personally dislike this behavior, since it moves comment lines away from the things they're commenting on, but I digress...) The only order that does matter is words within the pkg_scripts setting, which orders those relative to each other. > Make sure your resolv.conf points to unbound so that your system can > resolve the local dns names. If your uplink interface interface is configured as DHCP, this will need to be set in dhclient.conf, e.g. "supersede domain-name-servers 127.0.0.1". -Andrew
Re: Third server now locked up after reboot due to no keyboard attached
On Sun, Dec 15, 2019 at 12:28 PM Nick Holland wrote: > > 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". > > [...] > 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? Always a good idea. If you have console redirection configured in the BIOS, make sure redirection after boot is *disabled*, and configure the serial console in the bootloader instead. I've seen garbage characters produced by the BIOS console on some systems, but the OS and bootloader usually work better. > 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. Note that this is not yet implemented in the UEFI bootloader: https://github.com/openbsd/src/blob/43e343f8aa17502e68dbb74fa3dd463280c74fe5/sys/arch/amd64/stand/efi64/efiboot.c#L514-L519 (Compare pc_getshifts() in .../libsa/bioscons.c, which calls BIOS interrupts. Anyone know the UEFI equivalent?) -Andrew
Re: OpenBSD on AWS - pciide/wd issue
On Wed, Sep 4, 2019 at 12:56 PM Pavel Korovin wrote: > The logs showed where it stuck: > > pciide0:0:0: not ready, st=0x0, err=0x00 > wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying > pciide0:0:0: not ready, st=0x0, err=0x00 > wd0c: device timeout reading fsbn 0 (wd0 bn 0; cn 0 tn 0 sn 0), retrying I can reproduce this on my local Xen environment with the latest bsd.rd snapshot (OpenBSD 6.6-beta (RAMDISK_CD) #270: Wed Sep 4 11:46:05 MDT 2019); 6.5 works just fine. > For some reason, the boot volume was recognized also as > wd0 at pciide0 channel 0 drive 0: > and then as > sd0 at scsibus1 targ 0 lun 0: SCSI5 0/direct > > As a quick fix I disabled pciide/wd, the instance booted and runs fine. I noticed that in the problematic snapshot, pciide is listed in dmesg *before* any xen stuff, whereas in 6.5, xen0/xbf0/sd0 are listed first, and pciide comes later and says "channel 0 disabled (no drives)". I believe xbf(4) and xnf(4) disable any emulated devices (e.g. wd0, re0) when they load, so maybe they need to load first? Here's a "known good" dmesg from OpenBSD 6.5 + syspatches (up through 010_frag6ecn): OpenBSD 6.5 (GENERIC.MP) #5: Thu Aug 29 20:38:30 CEST 2019 r...@syspatch-65-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056964608 (1008MB) avail mem = 1015353344 (968MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb01f (12 entries) bios0: vendor Xen version "4.4.4_40-61.43.2" date 03/21/2019 bios0: Xen HVM domU acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC WAET SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2494.24 MHz, 06-17-06 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,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu0: 6MB 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 100MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz, 2493.89 MHz, 06-17-06 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,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 2, package 0 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpipci0 at acpi0 PCI0: _OSC failed acpicmos0 at acpi0 "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured pvbus0 at mainbus0: Xen 4.4 xen0 at pvbus0: features 0x705, 32 grant table frames, event channel 4 "vfb" at xen0: device/vfb/0 not configured "console" at xen0: device/console/0 not configured xbf0 at xen0 backend 0 channel 6: disk scsibus1 at xbf0: 2 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 4096MB, 512 bytes/sector, 8388608 sectors xnf0 at xen0 backend 0 channel 7: address 00:16:3e:79:85:28 xnf1 at xen0 backend 0 channel 8: address 00:16:3e:46:21:98 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) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x01: SMBus disabled vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) xspd0 at pci0 dev 3 function 0 "XenSource Platform Device" rev 0x01 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console 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 lpt0 at isa0 port 0x378/4 irq 7 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (70bae60fe9b7d0df.a) swap on sd0b dump on sd0b fd0 at fdc0 drive 0: density unknown fd1 at fdc0 drive 1: density unknown -Andrew
Re: TLS suddenly not working over IKED site-to-site - SOLVED?
On Thu, Dec 20, 2018 at 6:54 PM Theodore Wynnychenko wrote: > Then, I took the advice above, and disable ipcomp on the tunnel, and, BAHM, > https (and imaps) were working without an issue from openbsd, Windows 7, and > Macs! > > Just to be sure, I updated this am to the 12/19 amd64 snapshot. > > When I turn on ipcomp, https/imaps hangs for most connections; when I turn > ipcomp off, https/imaps works. I can confirm this behavior. I've set up a simple RSA key VPN as described at http://www.openbsd.org/faq/faq17.html#site2site, which does not include ipcomp by default, and everything works fine, including https. After reading this I decided to test enabling ipcomp, and sure enough, loading an https page across the VPN fails. With ipcomp I also see some "unprotected" packets when running tcpdump on enc0, e.g.: 13:32:19.600062 (authentic,confidential): SPI 0xee345270: 10.95.10.236.57254 > 10.95.0.233.443: P 273:518(245) ack 5604 win 455 (DF) (encap) 13:32:19.614996 (unprotected): SPI 0x5a04: 10.95.0.233.443 > 10.95.10.236.57254: . 5604:7052(1448) ack 518 win 252 (DF) (encap) I don't know why that is happening, but as everything seems to work well and perform decently without ipcomp, I'll be leaving it disabled. > I noticed that the last change to sys/netinet/ip_ipcomp.c (I am guessing this > is the code that is involved) in the log (I think) was about 3 months ago, > and at this point, I can't recall if my last updated (prior to the one where > the instability began) was before or after that change. > > I was going to try to recompile it with the change undone, but am not sure > how to do that, or even if it can be done for just that one part of sys. Yes, just use git or cvs (whatever you checked out the code with) to fetch an earlier revision of that file (not the whole repo) and then build a new kernel. Sometimes you'd need to also revert other related changes, but that does not appear to be the case here, assuming you're referring to [1]. Note that some previous commits did touch multiple files. > And, after removing ipcomp from iked.conf, my subjective observation is that > things load a lot faster than they seemed to in the past with ipcomp on; so, > I am happy with where I am. > > I was just posting my observations in case anyone else has a similar issue. Thank you for sharing. I had (I think) been using ipcomp in my old ikev1 (ipsec.conf/isakmpd) setup but had not yet gotten around to enabling it in the ikev2 setup. Based on this, I won't bother. -Andrew [1] https://github.com/openbsd/src/commit/4b5fa55
Re: openbsd 6.4 as guest VM on Xen cannot detect disk
I have no idea what is causing your backend timeout, but your VM config would be useful information, and take a look at xend.log etc. on the host for any related errors (if you have access to it). I'm running OpenBSD 6.4 just fine under Xen; however my Dom0 is only 4.4.4 (dmesg attached). Note that in your 6.0 dmesg, you have "wd0 at pciide0" vs. my "sd0 at scsibus1" via "scsibus1 at xbf0"; the man page for xbf(4) indicates it was added in 6.1, and that it takes over all virtual disks. As a workaround, you might try boot -c and disable xbf, which would presumably present your disk via the emulated IDE controller. -Andrew OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056964608 (1008MB) avail mem = 1015713792 (968MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb01f (12 entries) bios0: vendor Xen version "4.4.4_34-61.32.1" date 08/17/2018 bios0: Xen HVM domU acpi0 at bios0: rev 2 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC WAET SSDT SSDT acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2993.06 MHz, 06-17-06 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,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu0: 6MB 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 100MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, 2992.68 MHz, 06-17-06 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,SSSE3,CX16,SSE4.1,x2APIC,DEADLINE,HV,NXE,LONG,LAHF,MELTDOWN cpu1: 6MB 64b/line 16-way L2 cache cpu1: smt 0, core 2, package 0 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) acpicpu1 at acpi0: C1(@1 halt!) acpicmos0 at acpi0 "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured pvbus0 at mainbus0: Xen 4.4 xen0 at pvbus0: features 0x705, 32 grant table frames, event channel 4 "vfb" at xen0: device/vfb/0 not configured xbf0 at xen0 backend 0 channel 6: disk scsibus1 at xbf0: 2 targets sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed sd0: 4096MB, 512 bytes/sector, 8388608 sectors xnf0 at xen0 backend 0 channel 7: address 00:16:3e:79:85:28 xnf1 at xen0 backend 0 channel 8: address 00:16:3e:46:21:98 "console" at xen0: device/console/0 not configured 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) pciide0: channel 1 disabled (no drives) piixpm0 at pci0 dev 1 function 3 "Intel 82371AB Power" rev 0x01: SMBus disabled vga1 at pci0 dev 2 function 0 "Cirrus Logic CL-GD5446" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) xspd0 at pci0 dev 3 function 0 "XenSource Platform Device" rev 0x01 isa0 at pcib0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo com0: console 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 lpt0 at isa0 port 0x378/4 irq 7 vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at root scsibus3 at softraid0: 256 targets root on sd0a (70bae60fe9b7d0df.a) swap on sd0b dump on sd0b fd0 at fdc0 drive 0: density unknown fd1 at fdc0 drive 1: density unknown
Re: "Missing operating system" after i386 dual boot install
On Sat, Aug 4, 2018 at 7:00 PM Sijmen J. Mulder wrote: > After booting the PC pauses for a few seconds before displaying "Missing > operating system". > > What I've tried: > - "boot hd0a:/bsd" from the installation CD: works > - mark partition 0 active: works, brings up NT's bootloader > - "installboot -v wd0": no change > > Any ideas? Boot the install CD, and run 'machine boot hd0c'. This will boot the OpenBSD partition directly, without involving the MBR. (With 'machine boot', hd0a..hd0d are the fdisk partitions, not BSD disklabel entries, so e.g. 'machine boot hd0a' should boot NT.) If that works: the OpenBSD boot loader in its partition is fine, but the MBR is not loading it correctly. Installing new MBR code, e.g. 'fdisk -u wd0', may help. If it doesn't (unlikely, since NTLDR works with the PBR): there is a problem with the PBR, or with the BIOS's ability to boot from it. Using the NT loader menu may end up being a better solution for you, but this should sort out the direct-boot case. -Andrew
Re: spontaneous reboot during upgrade using bsd.rd on VIA C3.
I recently installed a 6.2-beta snapshot from mid-September on a VIA Epia M, and then upgraded to 6.2-RELEASE without any issue during the installation. There is a dmesg of this system included in [1]; it looks like you may have the same motherboard, or at least the BIOS identifies itself the same? However my BIOS is slightly newer (I think the last update VIA released was in 2009, despite the 2004 BIOS date!), so you may try updating yours; also, I have a C3 Ezra vs. your Nehemiah (this might be the important part). Yours: cpu0: VIA Nehemiah ("CentaurHauls" 686-class) 1.01 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,SEP,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE bios0 at mainbus0: date 03/11/04, BIOS32 rev. 0 @ 0xface0, SMBIOS rev. 2.2 @ 0xf0800 (26 entries) bios0: vendor Award Software International, Inc. version "6.00 PG" date 03/11/2004 bios0: VIA Technologies, Inc. VT8623-8235 Mine: cpu0: VIA C3 Ezra ("CentaurHauls" 686-class) 1 GHz cpu0: FPU,DE,TSC,MSR,MTRR,PGE,MMX,3DNOW bios0 at mainbus0: date 05/19/04, BIOS32 rev. 0 @ 0xfb210, SMBIOS rev. 2.2 @ 0xf0800 (26 entries) bios0: vendor Award Software International, Inc. version "6.00 PG" date 05/19/2004 bios0: VIA Technologies, Inc. VT8623-8235 If you build ramdisks to bisect the problem, adding "option DDB" to the kernel config (it's in GENERIC, but not RAMDISK{,_CD}) would probably be useful, so you can get a backtrace instead of an immediate halt/reboot. While installation went fine, there are a few outstanding issues with my system, in decreasing order of importance: * X immediately crashes on startup (this likely affects all CLE266 users... all 10 of them?). I submitted a fix at [1] but am still waiting for someone to look at it. * It reboots rather than powering off. * Suspend and hibernate do not work. * Reported temperatures via hw.sensors are about 10-15C lower than reality. I'll submit a proper bug report for the reboot & suspend stuff once I do more testing (e.g. acpi disabled, BIOS settings for S1 vs. S3 suspend, etc.). -Andrew [1] https://marc.info/?l=openbsd-tech&m=150719094005071&w=2 On Tue, Oct 17, 2017 at 1:56 PM, Mike Larkin wrote: > On Tue, Oct 17, 2017 at 06:24:42PM +0200, Remco wrote: >> I am not able to upgrade using bsd.rd on my VIA C3 system. >> >> Booting the i386 6.2 bsd.rd progresses to the "npx0 ..." line. >> After a short moment the system reboots and that's the end of the story. >> >> I did check the bsd.rd using signify and it checked out all right: >> $ signify -C -p /etc/signify/openbsd-62-base.pub -x SHA256.sig bsd.rd >> Signature Verified >> bsd.rd: OK >> >> >> I also have a USB stick with OpenBSD for i386 on it. >> I upgraded that to 6.2 on another machine and tried to boot it on my VIA >> system ... this works ! (both for bsd and bsd.sp) >> >> I'm not sure what to look at and what's so different between the ramdisk >> kernel and an ordinary kernel, so if this is of interest hopefully someone >> can give me a pointer. >> >> >> Here are the dmesg.boot for 6.1, and a diff against one of a GENERIC 6.2 >> kernel: >> > > It is unlikely any developer has a 13+ year old VIA C3 to test this on. > > My advice would be to find when bsd.rd stopped working, and then help us by > bisecting commits. The man pages explain how to build bsd.rd images. > > Once you find the commit that broke things (or a reasonably small timeframe > that > covers the problem commit), let us know and perhaps we can see what went > wrong. > > -ml > >> >> OpenBSD 6.1 (GENERIC) #291: Sat Apr 1 13:49:08 MDT 2017 >> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC >> cpu0: VIA Nehemiah ("CentaurHauls" 686-class) 1.01 GHz >> cpu0: FPU,V86,DE,PSE,TSC,MSR,SEP,MTRR,PGE,CMOV,PAT,MMX,FXSR,SSE >> real mem = 251088896 (239MB) >> avail mem = 233578496 (222MB) >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: date 03/11/04, BIOS32 rev. 0 @ 0xface0, SMBIOS rev. 2.2 @ >> 0xf0800 (26 entries) >> bios0: vendor Award Software International, Inc. version "6.00 PG" date >> 03/11/2004 >> bios0: VIA Technologies, Inc. VT8623-8235 >> acpi0 at bios0: rev 0 >> acpi0: sleep states S0 S1 S4 S5 >> acpi0: tables DSDT FACP >> acpi0: wakeup devices PCI0(S5) USB0(S5) USB1(S5) USB2(S5) USB3(S3) USB4(S3) >> USB5(S3) USB6(S3) LAN0(S5) AC97(S5) UAR1(S5) >> acpitimer0 at acpi0: 3579545 Hz, 24 bits >> acpiprt0 at acpi0: bus 0 (PCI0) >> acpiprt1 at acpi0: bus 1 (AGPB) >> acpicpu0 at acpi0: !C3(@900 io@0x415), !C2(@90 io@0x414), C1(@1 halt!) >> acpibtn0 at acpi0: PWRB >> "PNP0501" at acpi0 not configured >> "PNP0401" at acpi0 not configured >> "VIA3076" at acpi0 not configured >> bios0: ROM list: 0xc/0xe000 0xd/0x8000! 0xd8000/0x9800 >> cpu0 at mainbus0: (uniprocessor) >> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges >> cpu0: RNG AES >> pci0 at mainbus0 bus 0: configuration mode 1 (bios) >> pchb0 at pci0 dev 0 function 0 "VIA VT8623 PCI" rev 0x00 >> viaagp0 at pchb0: v2 >> agp0 at viaagp0: aperture at 0xe600,
Re: vmm issues - vioblk_notifyq: unsupported command 0x8
On Thu, Oct 12, 2017 at 6:42 PM, Mike Larkin wrote: >> oh. I didn't know that is how it was finding things. >> > > When booting it this way in qemu, qemu just reports the ID as "". > > So are you sure this is the way it is supposed to work? Yes... with some caveats. The Linux device manager (udev, I think? They've gone through several.) creates symlinks under /dev/disk/by-{id,label,path,uuid}/, so that you can use more permanent names in case the disk order (sda, sdb, etc.) changes; there are also library calls to open a device/partition by ID, UUID, etc., (via libblkid I believe, which lets you use things like LABEL=foo or UUID=abcd... as the block device passed to mount(8) or listed in fstab). The SUSE installer is "helpfully" attempting to use these IDs; e.g. with a SATA disk under VirtualBox, it uses a repo URL of 'hd:///?device=/dev/disk/by-id/ata-VBOX_HARDDISK_VB40007e3d-cdaea0a1-part2'. However, you are correct that qemu virtio disks do not report IDs (or report blank ones) -- at least by default (apparently with recent qemu, there is an option to set a drive's serial number, but it doesn't seem to be commonly used). I did a test installation of openSUSE under Proxmox VE (qemu/KVM) using virtio disks, and the only thing under /dev/disk/by-id is the emaulated IDE CD-ROM. -- nothing for /dev/vda or vdb. Notably, the installer configured its repo as 'hd:///?device=/dev/vda2' without me having to tell it that, as I had to under vmm. By comparison, the opensuse VM I installed under OpenBSD vmm *does* show some 'by-id' devices: /dev/disk/by-id: total 0 lrwxrwxrwx 1 root root 9 Oct 13 13:21 virtio-__LI_U_ -> ../../vdb lrwxrwxrwx 1 root root 10 Oct 13 13:21 virtio-__LI_U_-part1 -> ../../vdb1 lrwxrwxrwx 1 root root 10 Oct 13 13:21 virtio-__LI_U_-part2 -> ../../vdb2 (Currently /dev/vda is the VM's hard disk and vdb is the ISO... strange that there are only links for vdb, but not vda. Of course accessing via these symlinks works, since they point at the real device, but doing whatever library call to open 'virtio-__LI_U_-part2' would most likely fail, and obviously the correct symlinks did not exist during installation.) My best guess is that when udev gets a blank ID, it skips the by-id stuff, and thus the installer uses the real disk device, but since vmm doesn't implement that call, instead of marking the disk as not having an ID, invalid disk IDs somehow get used. -Andrew
Re: vmm issues - vioblk_notifyq: unsupported command 0x8
On Tue, Oct 3, 2017 at 3:49 AM, Jiri B wrote: >> > I was able to boot opensuse from that dvd, although later on I got an >> > error in the installer :/ >> >> This was because the installer couldn't locate the "dvd", correct? > > Unable to create repository > from URL 'hd:/?device=/dev/disk/by-id/virtio-_U_2_-part2'. > > > It would be nice to have IDE cdrom emulation. Sure, but that isn't actually needed to install openSUSE, and wasn't the problem here. The SUSE ISO images have a fake MBR added with isohybrid, so that you can dd them to a USB key and boot that unmodified. This is in fact why you got as far as you did, as the ISO "disk" looks like a disk with MBR partitions, which seabios happily boots. The reason the installation failed later is because it's attempting to use the disk ID to locate the installation repo, but that is unimplemented in vmm, as Mike Larkin has explained. If you manually set the installation source to the real disk device, it works. After a bit of trial and error, I successfully installed openSUSE Leap 42.3 under vmm with a VM configuration similar to yours. At the isolinux boot prompt, I entered: linux console=ttyS0,115200n8 install=hd:/?device=vda The install parameter is specific to SUSE and is documented at [1]. With the disk order you have, Linux sees /dev/vda as the ISO and /dev/vdb as the target disk. After installation finishes, you of course have to switch the disk order to boot from the virtual hard drive; fortunately grub2 still finds the disk. I may be missing something, but it appears there's currently no way to have vmm tell seabios to boot the second (or third, etc.) disk rather than the first? At some points the installation appeared to hang, but it always recovers after a bit and you can proceed. Sometimes the display gets screwed up, but a Ctrl+L always clears it up (pretty sure that one is a bug in the YaST ncurses interface rather than vmm, as I've also seen it installing openSUSE in text mode under Xen). This was my first time trying out vmm and it was very straightforward, once I figured out what were dumb mistakes on my part. vmm is already very capable and it is steadily improving! -Andrew [1] https://doc.opensuse.org/documentation/leap/startup/single-html/book.opensuse.startup/index.html#id2504
Re: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode
On Wed, Oct 11, 2017 at 11:01 AM, Stuart Henderson wrote: > What is not good is when you do have a RAID array, the controller is > in RAID mode, but OpenBSD doesn't understand the metadata, so it corrupts > data on the disk. > > This is a difficult area. We don't want to corrupt data, but then some > BIOS don't allow this option to be changed at all, and on others BIOS > only offer a choice between IDE and (unsupported) RAID, even though > it's an AHCI controller. Would a config flag for ahci(4) that when enabled, forces it to attach to the Intel RAID PCI IDs, work here, or would that have to be handled at a lower level? If so, users who have a broken BIOS or are willing to accept the risk of destroying their RAID metadata could enable the flag with UKC, but the defaults would remain safe.
Re: 6.1 fails to boot on a 486
On Fri, Sep 1, 2017 at 1:57 AM, Mike Larkin wrote: > On Fri, Sep 01, 2017 at 01:04:40AM -0500, Andrew Daugherity wrote: > > > > boot> hd0a:/bsd.61 > > cannot open hd0a:/etc/random.seed: No such file or directory > > booting hd0a:/bsd.61: 7678420+2057220+174556+0+1097728 > > [72+501520+501951]=0xb761b4 > > entry point at 0x2000d4 > > > > [ using 1003956 bytes of bsd ELF symbol table ] > > Copyright (c) 1982, 1986, 1989, 1991, 1993 > > The Regents of the University of California. All rights > reserved. > > Copyright (c) 1995-2017 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > > > OpenBSD 6.1 (GENERIC) #291: Sat Apr 1 13:49:08 MDT 2017 > > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC > > kernel: privileged instruction fault trap, code=0 > > Stopped at cpuid+0x12: cpuid > > ddb> trace > > cpuid(8000,d0d78ef0,d0d78ed8,0,7d) at cpuid+0x12 > > identifycpu(d0c7d8a0,d09fbb83,10,0,) at identifycpu+0x80d > > cpu_startup(d09cefed,d09d1680,16c,8,0) at cpu_startup+0xb9 > > main(d02004c6,d02004ce,0,0,0) at main+0x6a > > ddb> ps > >PID TID PPIDUID S FLAGS WAIT COMMAND > > ddb> > > > > > > Looks like it's trying to run the CPUID instruction, which this > > processor probably doesn't support. Maybe this was an accidental > > breakage, rather than intentionally dropping 486es? Time to examine > > the CVS logs, I guess. (A -current snapshot also fails in the same > > manner, so something happened between 6.0 & 6.1.) > > > > Looks like I broke this about a year ago: > > 1.592(mlarkin 14-Oct-16): > 1.592(mlarkin 14-Oct-16): cpuid(0x8000, regs); > 1.592(mlarkin 14-Oct-16): if (regs[0] >= 0x8006) > 1.592(mlarkin 14-Oct-16): cpuid(0x8006, > ci->ci_extcacheinfo); > > I did test this on 486, but apparently qemu's emulated 486 isn't really a > proper 486. I'll see what I can do to solve it for you. > > Thanks for reporting it. > > -ml > I was looking at that commit last night, and thinking it might be the one at issue here. My next step was going to be adding a '&& class == CPUCLASS_686' to that block [if (vendor == CPUVENDOR_INTEL)] to match the AMD block above it -- not sure if 686 is the correct restriction there, or 586, or something else like 'cpuid_level >= N' -- but any of those would probably resolve my issue. qemu isn't necessarily wrong if it was emulating a later 486 like the DX4 -- apparently those (and the Am5x86, and maybe even the DX2?) did support CPUID, just not the older 486DX/SX. And yes, I know 16MB RAM will be an issue. I just built a stripped-down 4.1 kernel (on a faster box, of course) which gained me about 6MB additional RAM and the ability to actually start X plus a couple xterms (on GENERIC it was still swapping madly an hour after startx and took about 45 seconds to recover after Ctrl+Alt+Backspace). I doubt that will be possible on 6.1, even with a small kernel -- besides, I'd have to build XF86_AGX myself if I wanted anything better than VGA. It's only for nostalgia reasons and the somewhat unique hardware (and its small size, meaning it's easily packed into a box o'stuff) that I've hung onto it anyway. Thanks for the forthcoming fix! -Andrew
6.1 fails to boot on a 486
I recently dug out of the closet my old IBM PS/2E, which had served as my firewall box from 2000ish-06, and was in fact the very first machine I ever installed OpenBSD on, to see if it still worked properly. It did (after changing the CMOS battery), but booted into OpenBSD 4.1... yeah, just a *bit* out of date there. The machine may not be of great use nowadays (I'd retired it when it couldn't keep up with my internet connection), but even as a retro-computing playground, running a 10-year-old/20-releases-ago version of OpenBSD is of no benefit. Let's rectify that! >> OpenBSD/i386 BOOT 3.31 boot> hd0a:/bsd61.rd cannot open hd0a:/etc/random.seed: No such file or directory booting hd0a:/bsd61.rd: 3208120+1332224+3342348+0+446464 [72+288736+277711]=0x87e694 entry point at 0x2000d4 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.1 (RAMDISK_CD) #289: Sat Apr 1 13:58:25 MDT 2017 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD fatal privileged instruction fault (0) in supervisor mode trap type 0 code 0 eip d03b1f7c cs d09f0008 eflags 10046 cr2 0 cpl 0 panic: trap type 0, code=0, pc=d03b1f7c The operating system has halted. Please press any key to reboot. Well, that's not good -- I didn't expect 6.1 to run particularly well on this, but I figured it would at least boot... how about 6.0? booting hd0a:/bsd60.rd: 3211188+1318224+2061312+0+442368 [72+298576+282894]=0x744144 entry point at 0x2000d4 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2016 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 6.0 (RAMDISK_CD) #1864: Tue Jul 26 12:57:09 MDT 2016 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD cpu0: Intel 486DX (486-class) real mem = 16183296 (15MB) avail mem = 8122368 (7MB) mainbus0 at root bios0 at mainbus0: date 03/31/93 pcibios at bios0 function 0x1a not configured bios0: ROM list: 0xc8000/0x1000 0xc9000/0x1000 0xca000/0x2000 cpu0 at mainbus0: (uniprocessor) isa0 at mainbus0 isadma0 at isa0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec com0 at isa0 port 0x3f8/8 irq 4: ns16450, no fifo com0: console pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard vga0 at isa0 port 0x3b0/48 iomem 0xa/131072 wsdisplay0 at vga0 mux 1: console (80x25, vt100 emulation), using wskbd0 wdc0 at isa0 port 0x1f0/8 irq 14 wd0 at wdc0 channel 0 drive 0: wd0: 16-sector PIO, LBA, 5729MB, 11733120 sectors wd0(wdc0:0:0): using BIOS timings npx0 at isa0 port 0xf0/16 irq 13 pcic0 at isa0 port 0x3e0/2 iomem 0xd/16384 pcic0 controller 0: has sockets A and B pcic0 controller 1: has sockets A and B pcmcia0 at pcic0 controller 0 socket 0 pcmcia1 at pcic0 controller 0 socket 1 pcmcia2 at pcic0 controller 1 socket 0 ep1 at pcmcia2 function 0 "3Com, 3C574-TX Fast EtherLink PC Card, A" port 0x340/32, irq 3: address 00:10:4b:5f:20:c0 tqphy0 at ep1 phy 0: 78Q2120 10/100 PHY, rev. 3 pcmcia3 at pcic0 controller 1 socket 1 ep2 at pcmcia3 function 0 "3Com, 3C574-TX Fast EtherLink PC Card, A" port 0x300/32, irq 9: address 00:60:08:93:80:48 tqphy1 at ep2 phy 0: 78Q2120 10/100 PHY, rev. 3 pcic0: irq 5, polling enabled softraid0 at root scsibus0 at softraid0: 256 targets root on rd0a swap on rd0b dump on rd0b erase ^?, werase ^W, kill ^U, intr ^C, status ^T Welcome to the OpenBSD/i386 6.0 installation program. (I)nstall, (U)pgrade, (A)utoinstall or (S)hell? Seems fairly normal. Did I miss something about 6.1 dropping 486 support? [/me checks i386.html... still says 486 or better!] Turns out that GENERIC can give us a little more useful information than RAMDISK_CD, as it drops into ddb: boot> hd0a:/bsd.61 cannot open hd0a:/etc/random.seed: No such file or directory booting hd0a:/bsd.61: 7678420+2057220+174556+0+1097728 [72+501520+501951]=0xb761b4 entry point at 0x2000d4 [ using 1003956 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.1 (GENERIC) #291: Sat Apr 1 13:49:08 MDT 2017 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC kernel: privileged instruction fault trap, code=0 Stopped at cpuid+0x12: cpuid ddb> trace cpuid(8000,d0d78ef0,d0d78ed8,0,7d) at cpuid+0x12 identifycpu(d0c7d8a0,d09fbb83,10,0,) at identifycpu+0x80d cpu_startup(d09cefed,d09d1680,16c,8,0) at cpu_startup+0xb9 main(d02004c6,d02004ce,0,0,0) at main+0x6a ddb> ps PID TID PPIDUID S FLAGS WAIT COMMAND ddb> Looks like it's trying to run the CPUID instruction, which this processor probably
Re: Getting Dell RAID status via SNMP
On Mon, Jul 24, 2017 at 12:10 AM, FUKAUMI Naoki wrote: > Hi, > > From: Jibby Jeremiah > Subject: Re: Getting Dell RAID status via SNMP > Date: Wed, 19 Jul 2017 15:03:21 -0400 > > > Darn. Well if you need more testers let me know. > > It seems your RAID card doesn't have cache, > > > mfii0 at pci3 dev 0 function 0 "Symbios Logic MegaRAID SAS3008" rev 0x02: > > msi > > mfii0: "PERC H330 Adapter", firmware 25.5.0.0019 > > then, I guess the "issue" will not happen. > > Here is new/WIP patch to support bio(4) for mfii(4). it doesn't fix the > "issue" yet, but it includes hot swap support from my patch for mfi(4) > http://marc.info/?l=openbsd-tech&m=149872410222552&w=2 > > Could you try attached patch? > Hi, Thanks for the patch, but it fails to build (also, I had to use 'patch -l' to get it to apply at all, due to ^M line endings, etc.): /usr/src/sys/dev/pci/mfii.c: In function 'mfii_makegood': /usr/src/sys/dev/pci/mfii.c:3068: error: 'MR_DCMD_CFG_FOREIGN_SCAN' undeclared (first use in this function) /usr/src/sys/dev/pci/mfii.c:3068: error: (Each undeclared identifier is reported only once /usr/src/sys/dev/pci/mfii.c:3068: error: for each function it appears in.) /usr/src/sys/dev/pci/mfii.c:3073: error: 'MR_DCMD_CFG_FOREIGN_CLEAR' undeclared (first use in this function) /usr/src/sys/dev/pci/mfii.c: In function 'mfii_makespare': /usr/src/sys/dev/pci/mfii.c:3125: error: 'MR_DCMD_CFG_MAKE_SPARE' undeclared (first use in this function) *** Error 1 in /usr/src/sys/arch/amd64/compile/GENERIC.MP (Makefile:947 'mfii.o') I got around that by copying those definitions from the FreeBSD mfi driver (patch is also attached, in case gmail decides to munge inline tabs): Add MR_DCMD_CFG definitions for *_SPARE and FOREIGN_* (taken from FreeBSD sys/dev/mfi/mfireg.h). --- sys/dev/ic/mfireg.h.bak Fri Jul 28 12:43:41 2017 +++ sys/dev/ic/mfireg.h Fri Jul 28 12:47:19 2017 @@ -139,6 +139,13 @@ #define MR_DCMD_CONF_GET 0x0401 #define MR_DCMD_CFG_ADD 0x0402 #define MR_DCMD_CFG_CLEAR 0x0403 +#define MR_DCMD_CFG_MAKE_SPARE 0x0404 +#define MR_DCMD_CFG_REMOVE_SPARE 0x0405 +#define MR_DCMD_CFG_FOREIGN_SCAN 0x04060100 +#define MR_DCMD_CFG_FOREIGN_DISPLAY 0x04060200 +#define MR_DCMD_CFG_FOREIGN_PREVIEW 0x04060300 +#define MR_DCMD_CFG_FOREIGN_IMPORT 0x04060400 +#define MR_DCMD_CFG_FOREIGN_CLEAR 0x04060500 #define MR_DCMD_BBU_GET_STATUS 0x0501 #define MR_DCMD_BBU_GET_CAPACITY_INFO 0x0502 #define MR_DCMD_BBU_GET_DESIGN_INFO 0x0503 I'll leave it to the experts to determine whether the numbers for MR_DCMD_CFG_MAKE_SPARE, etc. are in fact correct. I have the same PERC H330 HBA, and temporarily have a rather unique disk configuration in this server -- it has two disks, initially set up as RAID-1. For testing UEFI support, I broke the mirror, and configured the second disk as a passthrough disk, so as to have one disk with MBR and one with GPT. (Unfortunately, OpenBSD still doesn't boot in EFI mode on this server, only BIOS mode [1]. FreeBSD and Linux do work fine with EFI.) Right now it shows a degraded RAID-1 volume plus the passthrough disk. Obviously I plan to make a normal healthy RAID-1 before going live with it. After building a new kernel with the patch, I now have a new 'mfii0' entry in hw.sensors: hw.sensors.cpu0.temp0=26.00 degC hw.sensors.mfii0.drive0=degraded (sd0), WARNING hw.sensors.pchtemp0.temp0=26.50 degC hw.sensors.sdtemp0.temp0=25.62 degC hw.sensors.sdtemp1.temp0=26.25 degC (sdtemp was already working previously) Also bioctl works too, at least for reading status (haven't tried modifying the array): === bioctl sd0 output BEFORE sd0: , serial 007bbdf6cecf3d461e5c56708741 AFTER (bioctl -v) Volume Status Size Device mfii0 0 Degraded 499558383616 sd0 RAID1 WT 0 Failed 0 0:0.0 noencl <> 'unknown serial' 1 Online 500107862016 0:1.0 noencl 'unknown serial' Not sure about the 'unknown serial', but otherwise looks correct. Nice work! Sorry I don't have a card with cache (e.g. H730) to test on, but I haven't hit any problems with my H330 yet. -Andrew [1] https://marc.info/?l=openbsd-misc&m=146343624320665&w=2 With more recent kernels, the numbers on the "entry point" line are different, but the UEFI boot problem otherwise remains the same -- video corruption, followed by a reboot 10-15 seconds later. I just discovered that serial console support has recently been added to the UEFI bootloader, so I hopefully I'll be able to see boot messages from after the video goes wonky, and submit a more useful bug report. dmesg: OpenBSD 6.1 (GENERIC.MP) #1: Fri Jul 28 12:51:53 CDT 2017 andrew@obsd-r230:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80 real mem = 8395776000 (8006MB) avail mem = 8136630272 (7759MB) mpath0 at root scsibus0 at m
Re: Problems installing on Dell R830
I think the bootloader is seeing more RAM than is actually there. Regions 0-15 are contiguous, except for a 256kB hole at 640kB, and total 2.25GB (2304MB) memory. Not sure about regions 16 & 17, but they're tiny (~13MB). Region 18 is exactly 510GB, so we have 2.25 + 510 = 512.25 GB, or 256MB more memory than is actually installed in the system. And in relation to Mike's comment, that 510GB region starts at 4GB, so it does indeed go past 512GB. For comparison, here's my output from what should be very similar hardware -- a Dell R230 with 8GB: >> OpenBSD/amd64 BOOT 3.33 boot> machine memory Region 0: type 1 at 0x0 for 624KB Region 1: type 2 at 0x9c000 for 16KB Region 2: type 2 at 0xe for 128KB Region 3: type 1 at 0x10 for 2036884KB Region 4: type 2 at 0x7c625000 for 131104KB Region 5: type 1 at 0x8462d000 for 145860KB Region 6: type 4 at 0x8d49e000 for 4KB Region 7: type 1 at 0x8d49f000 for 2304KB Region 8: type 2 at 0x8d6df000 for 25132KB Region 9: type 4 at 0x8ef6a000 for 192KB Region 10: type 3 at 0x8ef9a000 for 312KB Region 11: type 1 at 0x8efe8000 for 96KB Region 12: type 2 at 0x8f00 for 16384KB Region 13: type 2 at 0xe000 for 262144KB Region 14: type 2 at 0xe00fd000 for 4KB Region 15: type 2 at 0xfd00 for 24576KB Region 16: type 2 at 0xfe00 for 68KB Region 17: type 2 at 0xfec0 for 4KB Region 18: type 2 at 0xfed0 for 4KB Region 19: type 2 at 0xfed1 for 32KB Region 20: type 2 at 0xfed18000 for 4KB Region 21: type 2 at 0xfed19000 for 4KB Region 22: type 2 at 0xfed84000 for 4KB Region 23: type 2 at 0xfee0 for 4KB Region 24: type 2 at 0xff40 for 12288KB Region 25: type 1 at 0x1 for 6029312KB Low ram: 624KB High ram: 2036884KB Total free memory: 8215080KB (pasted from a serial console, so no typos) I likewise have 2.25GB (2304MB) at the start, then 256MB in region 13 (the 4kB in region 14 overlaps this), and then 5.75GB (5888MB) in region 25 (regions 15-24 total ~36MB). Wait a minute, that also adds up to 256MB (+36MB) more RAM than I have installed (8.25 vs 8 GB), but my system boots fine. Now I'm more confused... I don't know what to make of the extra 256MB, but it's possible your system's crossing the 512GB boundary may be the issue. -Andrew
getty doesn't work on serial ports which aren't the boot console
I was setting up a new server where I wasn't sure whether com0 or com1 was the port I wanted, so I turned on both tty00 and tty01 in /etc/ttys to see which one to use in boot.conf. Edited the file, did the 'kill -HUP 1', and... nothing. getty processes are listening on tty00 and tty01, but both ports are stone dead. Tried cua00/cua01 in /etc/ttys on a lark, and it worked! Well, kinda... echo control isn't right, as passwords get echoed at the login prompt. Now that I knew which port was which, I configured boot.conf and rebooted. Bootloader & kernel messages work correctly on both com0 or com1, whichever is configured and connected to. Furthermore, using tty00/tty01 in /etc/ttys now works properly (including echo control), but ONLY on the port that was the boot console. To clarify: bootloader set tty com0: getty works on tty00, does not work on tty01 bootloader set tty com1: getty does not work on tty00, works on tty01 getty on cua00/cua01 works (but with echo issues) in all cases. This seems like possible serial line issues (carrier detect/DTR/DSR, etc.), but I don't know why. I've never had any problems with this null-modem cable before, and furthermore, one of the serial ports has no cable, but is connected internally to the IPMI/DRAC module and viewed via IPMI SoL [serial over LAN], so I couldn't change the cable pinout if I wanted. I also tried various combinations of flags mentioned in ttys(5) (local, softcar, etc.) to no effect. Does the kernel do something special regarding CD/DTR/DSR if the port is the boot console? I searched the list archives and found this thread from 2009, where others had the same problem, without any apparent resolution: https://marc.info/ ?l=openbsd-misc&m=123335745920052&w=2 Any ideas? Hardware details: Dell R230, with the cheapest DRAC option (or rather, I selected the "basic" DRAC which came standard). Fortunately with the iDRAC 8 on 13th-gen servers (Rn30 etc.), even the iDRAC8 Basic has a dedicated NIC (previously you had to get an "enterprise" option for that). The serial port ordering is configurable in the BIOS; I have it set so that com0 is the physical port and com1 is IPMI (I think the default was the opposite). Besides configuring IPMI SoL and boot serial console redirection (port, baud rate, turn off "redirection after boot") in the BIOS, I also had to turn off "RAC Serial" in the iDRAC settings, so that the port went to the host via IPMI rather than the RAC itself. Connecting from a client with 'ipmitool -I lanplus -H -U sol activate' works great. dmesg: OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error 80 real mem = 8395776000 (8006MB) avail mem = 8136646656 <(813)%20664-6656> (7759MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8ef68000 (43 entries) bios0: vendor Dell Inc. version "1.4.5" date 08/09/2016 bios0: Dell Inc. PowerEdge R230 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP BOOT SSDT SLIC HPET LPIT APIC MCFG WDAT SSDT DBGP DBG2 SSDT SSDT SSDT SSDT SSDT SSDT PRAD HEST BERT ERST EINJ DMAR FPDT SPCR acpi0: wakeup devices PEGP(S0) PEG0(S0) PEGP(S0) PEG1(S0) PEGP(S0) PEG2(S0) XHC_(S0) XDCI(S0) PXSX(S0) RP01(S0) PXSX(S0) RP02(S0) PXSX(S0) RP03(S0) PXSX(S0) RP04(S0) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz, 3696.00 MHz 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,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2, SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 369600 Hz cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz, 3696.00 MHz 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,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2, SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-6100 CPU @ 3.70GHz, 3696.00 M
EFI video corruption, reboot on Dell R230
Trying out the shiny new UEFI support without much luck on this hardware (Dell PowerEdge R230 1U server, BIOS 1.2.5, which is currently the latest). Using a snapshot install59.fs (May 6 was the most recent I've tried), the bootloader works fine, but after the kernel loads, it correct prints a single line: entry point at 0xf001000 [7205c766, 3404, 24448b12, 3680a304] and then all subsequent text is squished into a space about 4 pixels tall in the center of the screen, stretched horizontally, and colored purple, so it is completely unreadable. At a distance it looks like a purple line. Furthermore, about 10 seconds later the machine reboots. Since there doesn't appear to be any serial console support in the EFI bootloader I can't capture the unreadable kernel messages. 'machine video' reports only mode 0 (80x25). The bootloader screen is actually windowboxed (the monitor is running at 1024x768 at this point) but works fine. Video hardware is not Intel or Radeon but rather Matrox G200eR2 (apparently a 1998 GPU is back in embedded form?). FreeBSD & Linux do boot fine in UEFI mode, but I don't imagine that's much help, aside from ruling out defective hardware. I don't know if the card model even comes into play since it's probably something much earlier in the boot process at fault, but in case it helps, here is its PCI information (via FreeBSD): vgapci0@pci0:7:0:0: class=0x03 card=0x06a51028 chip=0x0534102b rev=0x01 hdr=0x00 vendor = 'Matrox Electronics Systems Ltd.' device = 'G200eR2' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 32, base 0x9100, size 16777216, enabled bar [14] = type Memory, range 32, base 0x9280, size 16384, enabled bar [18] = type Memory, range 32, base 0x9200, size 8388608, enabled Any suggestions? -Andrew
Re: problem mounting ext4 filesystem
On Tue, Jan 5, 2016 at 5:05 PM, Remi Locherer wrote: > Hi, > > I tried to mount an ext4 filesystem on OpenBSD which was created on > CentOS7. I get this: > > remi@mistral:~% doas mount -t ext2fs /dev/sd0m /mnt > mount_ext2fs: /dev/sd0m on /mnt: specified device does not match mounted > device > remi@mistral:~% dmesg | grep incomp > ext2fs: unsupported incompat features 0x2c2 > remi@mistral:~% > > Which feature is 0x2c2? Maybe I can disable this or re-create the filesystem > on Linux without this feature? It's a bitmask combination of features, see https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#The_Super_Block (entry 0x60, s_feature_incompat). Features supported in OpenBSD are described in src/sys/ufs/ext2fs/ext2fs.h, specifically the #define EXT2F_INCOMPAT_SUPP bit. It appears that there is some read-only ext4 support in OpenBSD, but not for your particular FS -- yours contains the bit 0x80 (INCOMPAT_64BIT, not even listed in OpenBSD, let alone in EXT4F_RO_INCOMPAT_SUPP). If you want to share the FS read/write between OpenBSD and Linux, it's probably easier to create it as ext2 rather than tracking down which ext4 features to disable. -Andrew
Re: nsd configuration problem
On Wed, Jun 24, 2015 at 1:06 PM, Graham Stephens wrote: > --- > On 24/06/2015 18:43, mxb wrote: >> Hey, >> this is a bit different from bind/named. >> >> nsd is a authoritative server ONLY. >> unbound is a caching server ONLY. >> >> I use those together on the same machine. >> nsd is handling all zones, unbound answers queries. >> >> nsd.conf: >> [port 5353, snip rest of cfg] >> >> unbound.conf: >> >> server: >> ## this one important to be able to query nsd >> do-not-query-localhost: no >> >> private-domain: "homelan.com" >> >> ## this one important to be able to query nsd >> local-zone: "78.168.192.in-addr.arpa." transparent >> >> ## forward to nsd >> forward-zone: >> name: "homelan.com" >> forward-addr: 127.0.0.1@5353 >> >> ## forward to nsd >> forward-zone: >> name: "78.168.192.in-addr.arpa" >> forward-addr: 127.0.0.1@5353 >> >> ## forward to google >> forward-zone: >> name: "." >> forward-addr: 8.8.8.8 This is similar to my setup, although I used stub-zone/stub-addr instead of forward-zone for my internal forward and reverse zones, as that seems to make more sense based on my reading of unbound.conf(5). (It says stub-zone is for authoritative servers, which nsd is, and forward-zone is for recursive servers. I'm not 100% sure I am correct here, however.) I also did not define a global forward-zone -- why not just use the system DNS servers? The important bits to actually make this work are the 'do-not-query-localhost: no' and 'local-zone: C.B.A.in-addr.arpa. transparent' options, needed to override unbound's default behavior of ignoring localhost and RFC1918 addresses. It took me a while to find this, until I discovered the proper keywords to Google for. I think this would be a good addition to the OpenBSD FAQ. While less common than a simple caching resolver, it's probably not too uncommon to have used BIND to serve a local zone and also act as a caching resolver, and having some guidance on "how to convert your BIND setup to unbound+nsd" would be nice. (Good guidance, not misleading and/or incorrect advice from ca***el.org!) nsd on a localhost high port, serving my old BIND zone files, and unbound forwarding to it for my zones was easy enough, but the two "magic" options letting unbound actually talk to nsd were somewhat less obvious. -Andrew
Re: dump & DUIDs;- raw character or block device?
On Thu, Apr 30, 2015 at 11:33 AM, Craig Skinner wrote: > > Thinking about DUIDs & my dump scripts & 5.7 being released soon, > does dump with DUIDs dump the raw character device, or the block device? > > /usr/src/sbin/dump/main.c notes: > /* Convert potential duid into a device name */ > But I don't know how to read the C code Sorry. It's the character device. The code in question is: /* Convert potential duid into a device name */ if ((diskfd = opendev(argv[i], O_RDONLY | O_NOFOLLOW, 0, &realpath)) >= 0) { argv[i] = strdup(realpath); [...] } The man page for opendev(3) lists its prototype as: int opendev(const char *path, int oflags, int dflags, char **realpath); and for dflags: The dflags are specified by OR'ing the following values: OPENDEV_PART attempt to open the raw partition during expansion OPENDEV_BLCK open the block device (default is character device) dump is calling opendev() with dflags=0 (defaults), so it's using the character device.
Re: File transfer from NetBSD to OpenBSD
On Sun, Mar 1, 2015 at 10:40 AM, wrote: > Hello there, > > Could anyone recommend which filesystem type to use when backing up a few > hundred GB of files from NetBSD onto a USB disk, planning to restore them > on an OpenBSD machine. I remember distantly that last time I tried with > FFS, it didn't work. > I assume NFS/scp/rsync is out of the question? I've successfully used FreeBSD FFS partitions in NetBSD, after adjusting the MBR partition type (A5/A6/A9) and disklabel (renamed sd0d to sd0h since NetBSD uses sd0c for "the entire BSD MBR partition" and sd0d for "the entire disk"), so I would expect it to work with these adjustments, but it is by no means guaranteed (this was several versions ago), and "caveat emptor" applies. tar is good and simple if you're restoring the whole thing right away, but if you want to easily get various individual files out of the backup or rearrange the structure, rsync to ext2 (or ffs, maybe) would be better.
Re: Xen PV DomU with OpenBSD?
On Sat, Feb 21, 2015 at 3:52 PM, Raimundo Santos wrote: > On 21 February 2015 at 10:31, Markus Kolb wrote: > > > > there isn't any support for Xen PV DomU in OpenBSD, isn't it? > > No, there is not such support. > > But you can run it in HVM mode without effort. Well, may be some effort in > XenServer, where there is no easy way to chose the type of emulated > hardware. > That's rather stupid, but apparently true[1]. I've only used Xen on Linux hosts (primarily SUSE) where it's easy to edit the VM config files. I did have to use model=e1000 for OpenBSD, as the rtl8139 (re0 on openbsd) didn't work properly; I just now tested model=virtio and that seems to work too, showing up as vio0. I also have to use bsd.sp as bsd.mp crashes on boot. Another "problem" when using Xen: the shutdown. Every OS that can not > communicate with xenstore will suffer from that. You will have to edit some > scripts in your environment to make it work with ACPI. > Thanks for the info. I hadn't run into this since on Xen I mostly run PV Linux guests, with the occasional HVM guest w/PV drivers (Linux, FreeBSD, Windows), and my OpenBSD usage has mostly been on physical hardware, but it bears noting: On HVM guests without PV drivers, 'xm shutdown ' will instantly kill the VM, without syncing, and similarly, 'xm reboot ' will instantly reset it. The newer 'xl' tool is more graceful and will refuse an 'xl {shutdown, reboot}' when there isn't guest PV support (you can still 'xl destroy', of course, or 'xl {shutdown, reboot} -F ' to send an ACPI power button/reset button event). To trigger an orderly shutdown on an OpenBSD guest, send an ACPI power button event: xm trigger power I discovered this solution via [2]. Also, when a serial console is configured on the OpenBSD guest, it shows up on the 'xm console'/virt-manager "Serial 1" view, which is nice, since you can copy/paste from that, unlike the emulated VGA console. This apparently requires 'serial=pty' in the VM config, but that's already the default in my setup. -Andrew [1] http://www.netservers.co.uk/articles/open-source-howtos/citrix_e1000_gigabit [2] https://github.com/ClusterLabs/resource-agents/commit/306dccb
Re: cursor problems with radeondrm(4) framebuffer - HD3200
On Thu, May 22, 2014 at 9:48 PM, Andrew Daugherity < andrew.daugher...@gmail.com> wrote: > 2) The cursor completely blocks out whatever letter it is positioned over > (command editing, vi, etc.)... I also noticed that my laptop does not show > highlighting in man pages -- everything is the same standard light-grey > color. Probably a related issue. > > This an MSI Wind U230L netbook, with Athlon Neo MV40 CPU + RS780/HD3200 > graphics. X works fine, at least what little bit I've tested. > [ dmesg in original message] > Anybody have any ideas on how to debug this further, or possible fixes? I did try the latest snapshot as of my message (i.e. ca. May 20), with no difference. -Andrew
cursor problems with radeondrm(4) framebuffer - HD3200
After installing 5.5, I was pleasantly surprised to see the high-res framebuffer with the classic sparc console font. However I have a couple minor issues with it: 1) No Shift+PgUp scrollback -- I understand this a case of ENOTIMPLEMENTED, and the recommendation for tmux, etc., so I'll not complain any further. It would be nice to have some day. :-) 2) The cursor completely blocks out whatever letter it is positioned over (command editing, vi, etc.). Every other framebuffer console I've used (including OpenBSD sparc and mac68k, I believe, but it's been a while since I've used those) behaved like xterm, where the letter under the cursor is displayed in reverse video, but that does not happen here. To make sure I had sane expectations, I tested a server with an embedded Radeon ES1000, and that one worked properly. After that comparison I also noticed that my laptop does not show highlighting in man pages -- everything is the same standard light-grey color. Probably a related issue. This an MSI Wind U230L netbook, with Athlon Neo MV40 CPU + RS780/HD3200 graphics. X works fine, at least what little bit I've tested. dmesg: OpenBSD 5.5 (GENERIC) #271: Wed Mar 5 09:31:16 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 1992585216 (1900MB) avail mem = 1931034624 (1841MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xfc2a0 (45 entries) bios0: vendor American Megatrends Inc. version "A1243AMS V1.1E" date 12/13/2011 bios0: Micro-Star International U230 acpi0 at bios0: rev 0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG SLIC OEMB HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) P0PC(S4) PCE5(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Athlon(tm) Neo Processor MV-40, 1600.33 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,SVM,EAPICSP,AMCR8,3DNOWP cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 32 4KB entries fully associative, 8 4MB entries fully associative mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz ioapic0 at mainbus0: apid 1 pa 0xfec0, version 21, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318180 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (P0P1) acpiprt2 at acpi0: bus -1 (PCE3) acpiprt3 at acpi0: bus 2 (PCE4) acpiec0 at acpi0 acpicpu0 at acpi0: PSS acpitz0 at acpi0: critical temperature is 120 degC acpiac0 at acpi0: AC unit online acpibat0 at acpi0: BAT1 model "MS-1243 " serial type LION oem "MSI Corp. " acpibtn0 at acpi0: LID0 acpibtn1 at acpi0: SLPB acpibtn2 at acpi0: PWRB acpivideo0 at acpi0: VGA_ acpivout0 at acpivideo0: LCD_ cpu0: PowerNow! K8 1600 MHz: speeds: 1600 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "AMD RS780 Host" rev 0x00 ppb0 at pci0 dev 1 function 0 "AMD RS780 PCIE" rev 0x00 pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 5 function 0 "ATI Radeon HD 3200" rev 0x00 drm0 at radeondrm0 radeondrm0: apic 1 int 18 azalia0 at pci1 dev 5 function 1 "ATI RS780 HD Audio" rev 0x00: msi azalia0: no supported codecs ppb1 at pci0 dev 4 function 0 "AMD RS780 PCIE" rev 0x00: msi pci2 at ppb1 bus 2 ral0 at pci2 dev 0 function 0 "Ralink RT3090" rev 0x00: apic 1 int 16, address 40:61:86:a3:b9:b8 ral0: MAC/BBP RT3090 (rev 0x3212), RF RT3020 (MIMO 1T1R) ppb2 at pci0 dev 5 function 0 "AMD RS780 PCIE" rev 0x00: msi pci3 at ppb2 bus 3 re0 at pci3 dev 0 function 0 "Realtek 8168" rev 0x03: RTL8168D/8111D (0x2800), msi, address 40:61:86:b2:ea:7a rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 2 ppb3 at pci0 dev 6 function 0 "AMD RS780 PCIE" rev 0x00: msi pci4 at ppb3 bus 4 ahci0 at pci0 dev 17 function 0 "ATI SBx00 SATA" rev 0x00: apic 1 int 22, AHCI 1.1 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: SCSI3 0/direct fixed naa.5000cca5f3e5328d sd0: 238475MB, 512 bytes/sector, 488397168 sectors ohci0 at pci0 dev 18 function 0 "ATI SB700 USB" rev 0x00: apic 1 int 16, version 1.0, legacy support ohci1 at pci0 dev 18 function 1 "ATI SB700 USB" rev 0x00: apic 1 int 16, version 1.0, legacy support ehci0 at pci0 dev 18 function 2 "ATI SB700 USB2" rev 0x00: apic 1 int 17 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "ATI EHCI root hub" rev 2.00/1.00 addr 1 ohci2 at pci0 dev 19 function 0 "ATI SB700 USB" rev 0x00: apic 1 int 18, version 1.0, legacy support ohci3 at pci0 dev 19 function 1 "ATI SB700 USB" rev 0x00: apic 1 int 18, version 1.0, legacy support ehci1 at pci0 dev 19 function 2 "ATI SB700 USB2" rev 0x00: apic 1 int 19 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "ATI EHCI root hub" rev 2.00/1.00 a
bioctl + ami panic "Non dma-reachable buffer" on 5.0/amd64
2MB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 7 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 7 ioapic1 at mainbus0: apid 8 pa 0xfec8, version 20, 24 pins ioapic1: misconfigured as apic 0, remapped to apid 8 ioapic2 at mainbus0: apid 9 pa 0xfec83000, version 20, 24 pins ioapic2: misconfigured as apic 0, remapped to apid 9 acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PALO) acpiprt2 at acpi0: bus 2 (DOBA) acpiprt3 at acpi0: bus 3 (DOBB) acpiprt4 at acpi0: bus 4 (PBLO) acpiprt5 at acpi0: bus 8 (VPR0) acpiprt6 at acpi0: bus 5 (PBHI) acpiprt7 at acpi0: bus 6 (PXB1) acpiprt8 at acpi0: bus 7 (PXB2) acpiprt9 at acpi0: bus 9 (PICH) acpicpu0 at acpi0 acpicpu1 at acpi0 ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel E7520 Host" rev 0x09 ppb0 at pci0 dev 2 function 0 "Intel E7520 PCIE" rev 0x09 pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 "Intel IOP332 PCIE-PCIX" rev 0x06 pci2 at ppb1 bus 2 ami0 at pci2 dev 14 function 0 "Dell PERC 4e/Di" rev 0x06: apic 8 int 14 ami0: Dell 16c, 32b, FW 5B2D, BIOS vH435, 256MB RAM ami0: 1 channels, 0 FC loops, 1 logical drives scsibus0 at ami0: 40 targets sd0 at scsibus0 targ 0 lun 0: SCSI2 0/direct fixed sd0: 69880MB, 512 bytes/sector, 143114240 sectors scsibus1 at ami0: 16 targets safte0 at scsibus1 targ 6 lun 0: SCSI2 3/processor fixed ppb2 at pci1 dev 0 function 2 "Intel IOP332 PCIE-PCIX" rev 0x06 pci3 at ppb2 bus 3 ppb3 at pci0 dev 4 function 0 "Intel E7520 PCIE" rev 0x09 pci4 at ppb3 bus 4 ppb4 at pci0 dev 5 function 0 "Intel E7520 PCIE" rev 0x09 pci5 at ppb4 bus 5 ppb5 at pci5 dev 0 function 0 "Intel 6700PXH PCIE-PCIX" rev 0x09 pci6 at ppb5 bus 6 em0 at pci6 dev 7 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: apic 9 int 0, address 00:18:8b:2e:2d:c2 ppb6 at pci5 dev 0 function 2 "Intel 6700PXH PCIE-PCIX" rev 0x09 pci7 at ppb6 bus 7 em1 at pci7 dev 8 function 0 "Intel PRO/1000MT (82541GI)" rev 0x05: apic 9 int 1, address 00:18:8b:2e:2d:c3 ppb7 at pci0 dev 6 function 0 "Intel E7520 PCIE" rev 0x09 pci8 at ppb7 bus 8 uhci0 at pci0 dev 29 function 0 "Intel 82801EB/ER USB" rev 0x02: apic 7 int 16 uhci1 at pci0 dev 29 function 1 "Intel 82801EB/ER USB" rev 0x02: apic 7 int 19 uhci2 at pci0 dev 29 function 2 "Intel 82801EB/ER USB" rev 0x02: apic 7 int 18 ehci0 at pci0 dev 29 function 7 "Intel 82801EB/ER USB2" rev 0x02: apic 7 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb8 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0xc2 pci9 at ppb8 bus 9 vga1 at pci9 dev 13 function 0 "ATI Radeon VE" rev 0x00 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) radeondrm0 at vga1: apic 7 int 18 drm0 at radeondrm0 pcib0 at pci0 dev 31 function 0 "Intel 82801EB/ER LPC" rev 0x02 pciide0 at pci0 dev 31 function 1 "Intel 82801EB/ER IDE" rev 0x02: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility atapiscsi0 at pciide0 channel 0 drive 0 scsibus2 at atapiscsi0: 2 targets cd0 at scsibus2 targ 0 lun 0: ATAPI 5/cdrom removable cd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 pciide0: channel 1 disabled (no drives) usb1 at uhci0: USB revision 1.0 uhub1 at usb1 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 "Intel UHCI root hub" rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 "Intel UHCI root hub" rev 1.00/1.00 addr 1 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec mtrr: Pentium Pro MTRR support uhub4 at uhub0 port 3 "Dell product 0xa001" rev 2.00/0.00 addr 2 uhidev0 at uhub3 port 2 configuration 1 interface 0 "Avocent APC AP5631" rev 1.10/1.00 addr 2 uhidev0: iclass 3/1 ukbd0 at uhidev0: 8 modifier keys, 6 key codes, country code 33 wskbd1 at ukbd0 mux 1 wskbd1: connecting to wsdisplay0 uhidev1 at uhub3 port 2 configuration 1 interface 1 "Avocent APC AP5631" rev 1.10/1.00 addr 2 uhidev1: iclass 3/1, 3 report ids ums0 at uhidev1 reportid 1: 5 buttons, Z dir wsmouse0 at ums0 mux 0 uhid0 at uhidev1 reportid 2: input=2, output=0, feature=0 uhid1 at uhidev1 reportid 3: input=1, output=0, feature=0 vscsi0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (07d4420bed41129f.a) swap on sd0b dump on sd0b Thanks, Andrew Daugherity
Re: Release IP-adress OpenBSD 3.8
On Tue, Jan 6, 2009 at 3:11 PM, Stuart Henderson wrote: > Release is an optional part of DHCP but some servers won't reassign the > IP address to a client with another MAC unless it happens. In that case > the best option is probably to try another DHCP client from ports/packages. > > At least in the current OpenBSD version you have a couple of options; > the ISC client allows this with the -r flag, and the WIDE client allows > it with SIGUSR2. It's good to know that the isc-dhcp-client from ports lets you do this; it would be nice if the dhclient in base had this functionality. If it's a matter of "we don't have time -- submit a patch", I'd be happy to port that functionality (disclaimer: assuming the code isn't extremely hairy; I haven't delved into it yet), but I don't want to waste my time if it's not likely to be accepted. My reason for needing this is that my ISP (actually, I know of several like this) is like the server you describe, in that it refuses to hand out another DHCP lease if I have an active lease for a different MAC address. After releasing that lease, I can then obtain a new one. This is most likely to happen if I swap out the box acting as my firewall/router, swap ethernet cards (or which ethernet card my DSL modem is connected to), or switch between using an OpenBSD box and a hardware router, etc. Without the DHCPRELEASE functionality, the only option is to wait until the old lease expires. Luckily my current ISP gives leases of 1 hour (maybe 2, don't remember for sure) rather than a full day. And granted, I don't do this very often, as once my firewall is set up I tend to leave it alone (aside from applying errata) but during initial setup, and/or when trying to debug why my net connection isn't working right, it does come in handy. Andrew
Re: Can OpenBSD run in 24 MB of RAM?
On Wed, Sep 3, 2008 at 10:00 PM, <[EMAIL PROTECTED]> wrote: > I've searched the FAQ and the Web for any guidance on what the minimum RAM > is for OpenBSD, with and without X. > > I just acquired a Compaq Armada 1125 laptop that maxes out at 24 MB of > RAM, and I'm wondering whether or not it's feasible to run OpenBSD on it. > My router for several years was an IBM "PS/2E", model 9533 with a 50MHz 486 SLC2 + 25MHz 387SX FPU(not a typo) and 16MB RAM. I haven't run anything newer than about 3.8 or 3.9 on it, but it worked fine then, including the install. I'm sure I've posted in more detail about it before -- check the archives. Heck, I even ran X on it as a "see if it works" thing, but it wasn't good for anything more than opening a couple xterms. The reason I abandoned it is that when faster connections became available, the CPU couldn't keep up. It would only pass about 2Mbit of traffic before the interrupts from the ethernet cards (16-bit PCMCIA, essentially ISA) consumed 90% CPU.
Re: First install: Grub doesn't find partitions
On 10/28/07, Bertram Scharpf <[EMAIL PROTECTED]> wrote: > grub> root (hd1,^I >Possible partitions are: > Partition num: 0, Filesystem type is ext2fs, partition type 0x83 > Partition num: 1, Filesystem type unknown, partition type 0x82 > Partition num: 4, Filesystem type is ext2fs, partition type 0x83 > Partition num: 5, No BSD sub-partition found, partition type 0xa6 > Partition num: 6, Filesystem type unknown, partition type 0x8e > > grub> root (hd1,5,a) > > Error 5: Partition table invalid or corrupt > > grub> rootnoverify (hd1,5,a) > > grub> cat / > > Error 17: Cannot mount selected partition > > Here is a `sfdisk' (Linux) output: > > /dev/hdb1 : start=1, size=32255, Id=83 > /dev/hdb2 : start=32256, size= 2096640, Id=82 > /dev/hdb3 : start= 2128896, size=117974304, Id= 5 > /dev/hdb4 : start=0, size=0, Id= 0 > /dev/hdb5 : start= 2128897, size= 4194287, Id=83 > /dev/hdb6 : start= 6323185, size= 37748591, Id=a6, bootable > /dev/hdb7 : start= 44071777, size= 76031423, Id=8e > I think this is your problem -- the OpenBSD partition needs to be a primary partition (hda1-hda4 in Linux terminology, or (hd0,1) - (hd0,3) in GRUB language, and you have it as an extended partition (hdb6). This is not supported. Reallocated your fdisk partitions so the OpenBSD partition is a primary partition and reinstall (you may have to resize your extended partition, ID=5, to make room). Andrew
Re: : How can i boot a bsd.rd from windows 2000 ?
On 10/15/07, Rodrigo V. Raimundo <[EMAIL PROTECTED]> wrote: > Em Sex, 2007-10-12 C s 09:57 +0200, Raimo Niskanen escreveu: > > Can grub actually boot a bsd kernel. I thought it was in a > > different binary format than Linux kernels. > > Grub can boot *BSD kernel and can detect in what binary format it is. > But in case it dont recognite the binary there is a --type=openbsd > parameter that can be used with the "kernel" command. > > > Does grub pass kernel arguments to the bsd kernel in the > > right way. > > It is not possible to pass kernel parameters from grub to /bsd* I have not had success booting an OpenBSD kernel directly from GRUB. Specifying --type=openbsd allows GRUB to load the kernel, but the kernel then dies with "panic: /boot too old: upgrade!" This happens both with bsd and bsd.rd from the most recent snapshot. NetBSD does boot successfully from GRUB, and with netbsd-4 and -current, kernel arguments work as well. Kernel args don't really apply to FreeBSD since for booting FBSD "directly" with GRUB you use "kernel /boot/loader" and the loader takes over from there. I'm sure OpenBSD could be made to boot from GRUB but I don't imagine that's very high on anyone's list. Andrew
Re: trouble setting up a freebsd program
First, read through the compat_freebsd (8) man page. Some points to note: -The 'ldd' command being run in your excerpts is most likely the OpenBSD /usr/bin/ldd, which is not going to work properly with binaries compiled for other OSes. You need a FreeBSD 'ldd' binary; preferably as /emul/freebsd/usr/bin/ldd. (Note that the ldd examples in the compat_freebsd(8) man page refer to running ldd on a FreeBSD system.) Symlinking that to something like /usr/local/bin/ldd-freebsd, so you can then invoke it as 'ldd-freebsd', avoiding any confusion, is also a good idea. -I assume you have the emulators/freebsd_lib port/pkg already installed. I don't see usr/bin/ldd in the PLIST, so you may want to grab that from a FreeBSD 4.11 machine or FTP archive (since that is the version of libraries in the freebsd_lib pkg). -FreeBSD programs and files don't have to live under /emul/freebsd, but it's a good idea. If they include files also in the OpenBSD system, they must go there so they don't clobber the OpenBSD files. Most of the same concepts also apply to Linux emulation. -Andrew
Re: OpenBSD todo list?
On 4/11/06, Ted Unangst <[EMAIL PROTECTED]> wrote: > rewrite units. it can convert euros to dollars at an awesome rate of > 94 cents per euro, but can't convert temperature. What's worse is it *does* recognize 'degF' and 'degC' units, but the conversion between them only does the multiply/divide by 9/5, but not the add/subtract 32 part, so it gives incorrect results. While this inability is mentioned in the man page, it would be better to not include 'degF' at all than to have it be incorrect. Most equations would use SI units anyway, right? (When I first discovered the degF/degC units grep'ing through the units library, my first thought was that the man page was outdated and it did handle them now; unfortunately that is not the case.) Similarly, currencies fluctuate enough to not be worth including. Unfortunately, this limitation of multiplicative scales only most likely runs rather deep, and would probably require a large amount of work to fix. -Andrew
Re: mergemaster
On 1/8/06, Jonathan Weiss <[EMAIL PROTECTED]> wrote: > I would really appreciate having mergemaster in the base system. > Or at least a mention of it in the upgrade FAQ [ http://www.openbsd.org/faq/upgrade38.html ]. Even just something like "Some people find the sysutils/mergemaster port useful for updating /etc; pay particular attention to the -r and -t options in mergemaster(1)." would be nice. I only found out about it through this list, after having done my first upgrade (3.4 -> 3.5) with a rather time-consuming recursive diff of /etc. Needless to say, I was a bit perturbed. "You mean OpenBSD has mergemaster just like FreeBSD and I didn't have to do that long diff perusal?" -Andrew
Re: flash on OpenBSD
On 12/26/05, Han Boetes <[EMAIL PROTECTED]> wrote: > Hi, > > I just read this article: > > http://www.kaourantin.net/2005/12/flash-player-8-for-linux-update.html > > Via OSNews. > > If there ever was a chance to lobby for support of flash on > OpenBSD it is now and there. Doesn't the Linux flash work under OpenBSD/i386 now (using a Linux browser such as www/opera)? Would this new version change that? A native version (or better, source code) would be nice, but let's face it, it's not bloody likely.
Re: Alpha Disklabel Question
On 12/16/05, Nick Holland <[EMAIL PROTECTED]> wrote: > On i386, that statement is STILL wrong, though you will be digging up > either some unusual historic hardware or some really unusual devices for > there to be an issue. Still, that's just wrong. > > On i386, it is NOT "63 sectors", it is "one (logical) track". On modern > (>500M) hard disks, one logical track is 63 sectors, but that was not > always the case, and I don't think it has to be the case now for "small" > storage devices. This is true -- I have a 32MB USB key which reports its (fake) geometry as 'sd2: 31MB, 31 cyl, 64 head, 32 sec, 512 bytes/sec, 64000 sec total'. Funny thing is, the FAT partition on it still starts at a 63-sector offset. I suppose I could repartition it to gain an extra 16kB if I really wanted to. :-) I was about to enclose dmesg/fdisk/disklabel, but I see you have already described a similar device (also 32 sec/track) in 14.17. -Andrew
Re: LOGIN FAILURES ON ttyC0
On 11/28/05, Federico Giannici <[EMAIL PROTECTED]> wrote: > eric wrote: > > On Mon, 2005-11-28 at 12:59:18 +0100, Federico Giannici proclaimed... > > > > > >>Isn't "ttyC0" the console? I'm sure that nobody is trying to log from > >>the console... > > > > > > It is the first virtual terminal on x86 architectures. Logs don't lie, so > > you might want to track it down, or see if you're flubbing passwords. > > OK, but what I want to know is: is it the PHYSICAL console of the PC? > I have it in front of me, so I can see that nobody is using it! Yes, it's the local keyboard/display. ttyC0, ttyC1, ttyC2, etc. are the "virtual" consoles accessed from the keyboard by Ctrl-Alt-F1, C-A-F2, CA-F3, etc. A serial console would be tty00, tty01, etc. ssh logins, xterms, etc., will be ttyp0 etc. As has already been advised, check your logs, particularly authlog and secure. Andrew
Re: OpenBSD official media
On 11/5/05, Marco Peereboom <[EMAIL PROTECTED]> wrote: > You mean because hppa, mac68k, m88k and sparc, just to name a few, have > outstanding DVD devices available. > > Come on now, THINK before typing. Of those, only sparc is currently shipping on CD. If you can find a SCSI DVD-ROM drive (they do exist), you should* be able to boot from it. Sun does ship Solaris on DVD since Solaris 8, after all. * Of course, vendor brain-damage could always interfere with your plans, so I guarantee nothing. -A
Re: gettytab tweak quick question
On 11/4/05, Mike Keller <[EMAIL PROTECTED]> wrote: > I am trying to display a login banner prior to login. > With freebsd, this can be done by adding > :if=/pathtosomefile: to the default setting of > gettytab. I did a man on gettytab and saw that > OpenBSD's implementation does not support "if". > Anyone been successful in doing this? I am trying to > display /etc/issue in the console right above the > login prompt. I am already displaying it with ssh > connections. > > Thanks! > > Looks like you'll have to change the input message: imstr NULL Initial (banner) message. The "default" entry in /etc/gettytab already sets this (displaying the system, hostname, and tty name), so modify it to say whatever you want. As you have already discovered, sshd_config has its own banner option which is independent of getty. -Andrew
Re: OT: 10 things i hate most on unix
At first I thought perhaps my sarcasm detector (now _there's_ a real useful invention!) was broken, but apparently this guy is serious. To put a new twist on the old aphorism: Those who do not understand the "UNIX Hater's Handbook" are doomed to reinvent it poorly. (Or maybe plagiarize it poorly, I can't tell.) If you haven't read it, it's worth taking a look at. Very much tongue-in-cheek, of course, and due to its age, not entirely correct now (being written prior to the rise of Linux and *BSD). If nothing else, read dmr's anti-foreword and the appendix where Thompson, Kernhigan, and Ritchie "admit" UNIX and C were April Fool's pranks. Nick's "taking himself seriously" bit and subsequent deconstruction reminded me of this publication (I mean this as a compliment, really!). I still keep the K&R C book on my shelf (long live 1TBS!). It's the 2nd ed. though... being young enough to learn C as ANSI C, I find the earlier style of code positively icky, and I think the "ansify" commits in the CVS logs agree with me. :-) Speaking of going off-topic... -Andrew
Re: device timeout when mounting cd
On 10/27/05, Stephen Nelson <[EMAIL PROTECTED]> wrote: > Any more ideas? > > I have found a PR4570 which seems to be a similar problem. > Interestingly, this was with an nForce4 chipset, whereas my chipset is > Intel. I completely missed that you're running amd64 (I saw Intel Xeon, and thought i386). You might try an i386 kernel (maybe the bsd.rd installer, as you don't want to mix libs between i386 and amd64) to see if the CD-ROM works there. If it works under i386, then it looks like a bug somewhere in the amd64 kernel, and might be worth filing a bug over (or perhaps adding comments to PR4570). More data is good. If you can swap the drive, that would be a good test. Also, testing other BSDs can't hurt -- NetBSD, OpenBSD, and FreeBSD share some code, Net and Open more so than Free; although they've diverged quite a bit, sometimes drivers (and bugfixes) are ported between them. Note that saying "but it works in NetBSD, fix it!" isn't likely to get you much help here, but "it's also broken in NetBSD" might help track down the bug. I'm not an OpenBSD developer, so if someone who is one chimes in, take their word over mine. :-) Andrew
Re: device timeout when mounting cd
On 10/27/05, Stephen Nelson <[EMAIL PROTECTED]> wrote: > Is there any way I can get the device to fall back to a legacy mode that > would allow me to get further? I've seen some CD-ROM drives claim to support UDMA2 but not work properly in UDMA mode. You could try setting the flags to disable DMA on it, see atapiscsi(4). 'boot -c' to enter UKC [see boot_config(8)]; 'change atapiscsi' and set the flags accordingly. This may or may not help, but it's worth a try. Definitely try a recent snapshot also. -Andrew
Re: iptables vs pf
On 10/19/05, Roger Neth Jr <[EMAIL PROTECTED]> wrote: > Hello, I put OpenBSD 3.8 snapshot on an old DEC 500pws with pf.conf > and it was okay on response. Then I redid my pf.conf with the tutorial > by Jeff Hansteen posted a couple of days ago. > I assume you meant the one posted by Peter N. M. Hansteen[1]? I'm not finding anything by a "Jeff Hansteen" in either the misc or pf mailing list archives. It does seem to be a rather useful document. -Andrew [1] http://marc.theaimsgroup.com/?l=openbsd-pf&m=112963309005279&w=2
Re: xorg with Nvidia Go5600 at 1600x1200
On 10/6/05, pirge <[EMAIL PROTECTED]> wrote: > Add this to your xorg.conf in the Device section for the nv driver: > > Option "FlatPanel" True > > and remove the Modes lines in the Screen section. It should default to > the largest res it can find. > Then double check the HorizSync and VertRefresh you have defined in > the Monitor section. Better yet, comment them out. As printed in your log, it already detects the panel size as 1600x1200, and it should autodetect suitable HSync/VSync ranges (and should also detect the sync ranges of any external monitor you connect, providing it's not a really ancient model lacking DDC support, although that may require restarting X to get proper values). Your 31.5 - 64.3 HorizSync range is artificially limiting your capabilities; the highest mode that range will support is [EMAIL PROTECTED] If for some reason letting it detect the sync ranges (by removing your explicit entries) fails, raise the upper bound to 75.0, which should support [EMAIL PROTECTED] Generally it's best to hard-code as few things as possible. My general procedure is to run "Xorg -configure" (or "XFree86 -configure"), and then make a few changes to the generated file as necessary. Much quicker and less painful than going through 20 screens of the xf86config tool. -Andrew
Re: wd0: soft error (corrected)
On 9/16/05, Christoph Fritz <[EMAIL PROTECTED]> wrote: > Hi > > I have two harddisks: > > wd0 at pciide0 channel 0 drive 0: > wd0: 16-sector PIO, LBA, 12982MB, 26588016 sectors > wd0(pciide0:0:0): using PIO mode 4, DMA mode 2 > wd1 at pciide0 channel 1 drive 0: > wd1: 16-sector PIO, LBA, 78533MB, 160836480 sectors > wd1(pciide0:1:0): using PIO mode 4, DMA mode 2 > > and as I copied some large files from wd0 to wd1 I get the following > errors. Do I need a new harddrive? > > wd0(pciide0:0:0): timeout >(snip) Since the errors are only appearing on wd0 and not wd1, which are both attached to the same controller (as per your full dmesg), I would strongly suspect the hard disk is at fault, rather than the controller or pciide drivers. Back up important data immediately, then run the manufacturer's diagnostics (usually these run from a DOS boot floppy, although they may require a Windows box to create this floppy) and see if the diagnostic software finds any errors. Every time I have seen this or similar kernel error messages it has been the drive at fault.
Re: Jose Nazario's dmesg explained for OpenBSD
On 9/5/05, Nick Holland <[EMAIL PROTECTED]> wrote: > The first "word" of most dmesg lines is a device driver, and in this > case, they all are: pchb, ppb, pci, vga, wsdisplay, pcib, pciide, wd. > And (get this!) they each have a man page! Is that cool or what? :) > > So, you want to learn about wsdisplay, "man 4 wsdisplay". IMO, this is one of the best features of the *BSDs. Once when ssh'd into a Linux box and failing to remember the proper module parameter syntax for parport and parport_pc, I thought something was seriously wrong with the system when 'man 4 parport' failed to return anything, until I remembered that they didn't have man pages for every driver in Linux. (I suppose you could argue that something *is* seriously wrong with that, albeit by design.) I eventually found what I was looking for, either somewhere in the kernel tree, or by running strings on parport.ko, but a man page would have been a lot nicer! > yeah, I probably should write up a "how to read a dmesg" article, > probably be a little long for the FAQ (or maybe not, I *do* get to make > those decisions!), but there are other places it could be put. We could > end up with a whole chorus of people on misc@ beating the snot out of > people who don't post dmesgs or snip them down to only the part THEY > think we need. Might be a good thing. :) 'Twould be nice. I can parse a dmesg pretty well, but there are some esoterica in it I'm not sure about, such as the stuff at the end of the dmesg like this: === a) biomask e74d netmask ff4d ttymask ffef b) pctr: no performance counters in CPU c) dkcsum: wd0 matched BIOS disk 80 d) root on wd0a e) rootdev=0x0 rrootdev=0x300 rawdev=0x302 === a) I suppose these are masks that work much like umask, but I have no idea how to parse them. b) pctr has a man page, ok, easy enough... it's telling me a 486 lacks a TSC.. c) no man page for dkcsum but I can guess that it's computing a checksum of each [sw]d? hard disk (its MBR?) and comparing it to the BIOS disk list, which goes 0x80, 0x81, etc. to pair them up, although I thought that at this point in the boot process we're not using the BIOS INT13 routines any more, so it's purely informational. Close? d) Obvious to any competent user, I'd hope. e) The major/minor device numbers in /dev. wd0a is 0,0; rwd0a is 3,0; rwd0c is 3,2. Might not be obvious to someone not familiar with mknod, etc. (Hell, an explanation of the difference between wd0a and rwd0a would be a good FAQ entry); using device names (like wd0a) may be an improvement, unless the in-kernel device table is minimal, in which case there's no need to bloat it out. Putting an article in the FAQ would be nice, even if it's just "most drivers have a man page in section 4", as that's the first place I look after the man pages, as is occasionally more useful, such as for ppp -- it gives a nice basic config, but both the ppp.conf example file and the man page are LONG. Which isn't necessarily bad, but sometimes simple instructions are better. I see a little blip about section 4 for devices in FAQ 9.1, but it doesn't mention the dmesg there. While I'm on it, I can throw up a couple dmesgen from vastly different i386 boxen (and maybe a mac68k) and comment them, subject to your correction of course, if you'd like. Andrew
Re: Shouldn't OpenBSD X11 come out with "-nolisten tcp" as default?
I think one major reason other OSes have done '-nolisten tcp' by default is to encourage people to use X11 forwarding via ssh instead of xhost/etc, as the xhost way transmits in cleartext. Of course it can be argued that the user should be left to decide that themselves, so there's two sides to every issue Personally, if it's a workstation behind a pf firewall, I don't care. If not (as in my box at work where I don't control the network), then yes, I'll do the little things that may or may not help but do not hurt (assuming my usage doesn't require them), like this, turning off daemons I don't use (which if I have to use RedHat, are legion), and "PermitRootLogin No" in sshd_config. And if this *is* the pf box I'm talking about, I won't be running xdm. :-) -A
Re: audio plays too fast
Forgot to cc the list. -- Forwarded message -- From: Andrew Daugherity <[EMAIL PROTECTED]> Date: Aug 15, 2005 4:56 PM Subject: Re: audio plays too fast To: Jernej Vodopivec <[EMAIL PROTECTED]> mpg123 has an option to resample on-the-fly, but this is still a nasty kludge. There's a similar problem with auvia(4) where rates other than 48kHz have bad static in the playback (unless somebody fixed this bug recently). Perhaps some bugs should be filed against auich and auvia (assuming they haven't been already)? -Andrew
Re: Network performance
On 5/26/05, Stuart Henderson <[EMAIL PROTECTED]> wrote: > --On 26 May 2005 12:11 +0200, Alexander Hall wrote: > > > Henning Brauer wrote: > >> * Philip Olsson <[EMAIL PROTECTED]> [2005-05-20 21:34]: > >>> More Mhz. Not crappy nics, get xl,fxp,dc etc. Or maybe gigabit nics > >>> like em(4). > >> > >> > >> xl is crap. > >> > >> sk is probably the best you can get currently. and they are > >> amazingly cheap. > > > > Can anyone comment on the fxp cards and driver? > > Reliable and not too heavy on the CPU (some chips/revisions have > microcode to do interrupt mitigation in /etc/firmware, grep -3 CPUSAV > /sys/dev/ic/fxp.c for a list). > I was about to say "or in the fxp(4) man page", but then I realized that particular xterm was an ssh session into my NetBSD box, so nevermind, grep away. (As an aside, I greatly appreciate the new ksh in 3.7 supporting bash-style PS1 prompts, like "[EMAIL PROTECTED]:\w$ ", which makes such confusion a thing of the past.) At least with 3Com and Intel cards I know I'm getting an xl or fxp card, and don't wonder whether they did like Linksys, DLink, etc., and added a + to the end of the model and used a completely different chipset. Of course, it seems most cheap cards are based on rtl8139 or something similar, and getting something better is hitting the jackpot. I've never encountered an sk card, but that's probably because I haven't gone shopping for gigabit stuff. If they really are that cheap, though, I might just have to start! While it wasn't under OBSD, I've had some bad experiences with early fxp hardware (eeproo 100/B). Don't know if it was the famous "receiver lock-up bug", but I definitely had kernel lock-ups resulting from them. Newer stuff seems to work fine. I've never had any problems with xl-based cards, but I trust Henning knows of what he speaks. I've found they perform decently (better than rl, but that's not saying a lot), but I'm not pushing the limits. I get ~80Mbit throughput shooting files around my LAN (which is not going through pf; my cable modem, which does, is a mere pittance in comparison), and that is "good enough" for me right now. Thanks for the history lesson, Nick. :-) I've never seen a 3C505 or 507-- didn't one of them actually use the same chip (82586) as an Intel NIC? Incidentally, the original 3c509 is a terrible performer (the 3c509b was better). Later NE2000 clones like the AT/LANTIC (DP83905) and RealTek8019 blow the 3c509 out of the water, at least in raw throughput. However, the 3c509 didn't have confusing jumpers or impossible-to-find DOS setup programs, which was a definite plus. I remember when 10Mbit ethernet was all the rage and having it on a PC was a novel idea, the university would only support/troubleshoot dorm connections if you had a 3c509 or SMC 8000 -- you were on your own with your JoeBlow NE2000. Lest that sound too heartless, remember these were the days of Win 3.1, Trumpet Winsock, and DOS packet drivers... (shudder) -Andrew
Re: High Interrupt usage on new amd 64 machine. Please help.
On 5/23/05, Richard D <[EMAIL PROTECTED]> wrote: > > The interrupt levels change a bit but still stay above 80% :( > > I think my motherboard is not fully supported. You think correctly. Specifically, the IDE controller in the ATI chipset is not supported, so OpenBSD is falling back to a generic IDE driver, which is functional, but lacks DMA transfers, which means your transfer rate is limited to about 3MB/sec and CPU usage is very high, as you have seen. These are the relevant sections of your dmesg log. For a supported IDE controller, it would note that DMA transfers were in use, rather than "16-sector PIO". > dmesg: > pciide0 at pci0 dev 17 function 0 vendor "ATI", unknown product 0x437a > rev 0x00: DMA (unsupported), channel 0 configured to native-PCI, > channel 1 configured to native-PCI > pciide0: using irq 10 for native-PCI interrupt > pciide0: channel 0 ignored (not responding; disabled or no drives?) > pciide0: channel 1 ignored (not responding; disabled or no drives?) > pciide1 at pci0 dev 18 function 0 vendor "ATI", unknown product 0x4379 > rev 0x00: DMA (unsupported), channel 0 configured to native-PCI, > channel 1 configured to native-PCI > pciide1: using irq 11 for native-PCI interrupt > pciide1: channel 0 ignored (not responding; disabled or no drives?) > pciide1: channel 1 ignored (not responding; disabled or no drives?) > pciide2 at pci0 dev 20 function 1 vendor "ATI", unknown product 0x4376 > rev 0x00: DMA (unsupported), channel 0 configured to compatibility, > channel 1 configured to compatibility > wd0 at pciide2 channel 0 drive 0: > wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors > wd1 at pciide2 channel 0 drive 1: > wd1: 16-sector PIO, LBA, 19569MB, 40079088 sectors > atapiscsi0 at pciide2 channel 1 drive 0 > scsibus0 at atapiscsi0: 2 targets > cd0 at scsibus0 targ 0 lun 0: SCSI0 > 5/cdrom removable Your best solution at this point (assuming you continue using the same motherboard) would be to get a PCI IDE card (such as Promise Ultra 100, etc.), which can be found for about $25 at online vendors, and will get you proper DMA transfers. -Andrew