Re: Shouldn't OpenBSD X11 come out with -nolisten tcp as default?

[Andrew Daugherity]

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: Jose Nazario's dmesg explained for OpenBSD

[Andrew Daugherity]

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: wd0: soft error (corrected)

[Andrew Daugherity]

On 9/16/05, Christoph Fritz [EMAIL PROTECTED] wrote:
 Hi
 
 I have two harddisks:
 
 wd0 at pciide0 channel 0 drive 0: Maxtor 91360U4
 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: IC35L080AVVA07-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: xorg with Nvidia Go5600 at 1600x1200

[Andrew Daugherity]

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: iptables vs pf

[Andrew Daugherity]

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-pfm=112963309005279w=2

Re: device timeout when mounting cd

[Andrew Daugherity]

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: device timeout when mounting cd

[Andrew Daugherity]

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: OT: 10 things i hate most on unix

[Andrew Daugherity]

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 KR 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: gettytab tweak quick question

[Andrew Daugherity]

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: OpenBSD official media

[Andrew Daugherity]

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: : How can i boot a bsd.rd from windows 2000 ?

[Andrew Daugherity]

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: High Interrupt usage on new amd 64 machine. Please help.

[Andrew Daugherity]

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: ST380011A
 wd0: 16-sector PIO, LBA48, 76319MB, 156301488 sectors
 wd1 at pciide2 channel 0 drive 1: WDC WD205AA
 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: ATAPI, DVD DD 2X16X4X16, G7L9 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

Re: Network performance

[Andrew Daugherity]

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: LOGIN FAILURES ON ttyC0

[Andrew Daugherity]

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: Alpha Disklabel Question

[Andrew Daugherity]

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: flash on OpenBSD

[Andrew Daugherity]

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: mergemaster

[Andrew Daugherity]

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: OpenBSD todo list?

[Andrew Daugherity]

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: trouble setting up a freebsd program

[Andrew Daugherity]

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: Can OpenBSD run in 24 MB of RAM?

[Andrew Daugherity]

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: Release IP-adress OpenBSD 3.8

[Andrew Daugherity]

On Tue, Jan 6, 2009 at 3:11 PM, Stuart Henderson s...@spacehopper.org 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

bioctl + ami panic Non dma-reachable buffer on 5.0/amd64

[Andrew Daugherity]

, 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: AMI, Host drive #00,  SCSI2 0/direct fixed
sd0: 69880MB, 512 bytes/sector, 143114240 sectors
scsibus1 at ami0: 16 targets
safte0 at scsibus1 targ 6 lun 0: PE/PV, 1x2 SCSI BP, 1.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: HL-DT-ST, CDRW/DVD GCC4244, B101 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: First install: Grub doesn't find partitions

[Andrew Daugherity]

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

cursor problems with radeondrm(4) framebuffer - HD3200

[Andrew Daugherity]

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: ATA, Hitachi HTS54502, PB2O 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 addr 1
piixpm0 

Re: cursor problems with radeondrm(4) framebuffer - HD3200

[Andrew Daugherity]

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

Re: File transfer from NetBSD to OpenBSD

[Andrew Daugherity]

On Sun, Mar 1, 2015 at 10:40 AM, etie...@magickarpet.org 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?

[Andrew Daugherity]

On Sat, Feb 21, 2015 at 3:52 PM, Raimundo Santos rait...@gmail.com wrote:

 On 21 February 2015 at 10:31, Markus Kolb open...@tower-net.de 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 vm' will instantly kill
the VM, without syncing, and similarly, 'xm reboot vm' 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 vm' 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 vm 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: dump DUIDs;- raw character or block device?

[Andrew Daugherity]

On Thu, Apr 30, 2015 at 11:33 AM, Craig Skinner skin...@britvault.co.uk 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: nsd configuration problem

[Andrew Daugherity]

On Wed, Jun 24, 2015 at 1:06 PM, Graham Stephens
gra...@thestephensdomain.com 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: problem mounting ext4 filesystem

[Andrew Daugherity]

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

EFI video corruption, reboot on Dell R230

[Andrew Daugherity]

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: Problems installing on Dell R830

[Andrew Daugherity]

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

[Andrew Daugherity]

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=123335745920052=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 MHz

Re: Getting Dell RAID status via SNMP

[Andrew Daugherity]

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=149872410222552=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=146343624320665=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 

Re: vmm issues - vioblk_notifyq: unsupported command 0x8

[Andrew Daugherity]

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: 6.1 fails to boot on a 486

[Andrew Daugherity]

On Fri, Sep 1, 2017 at 1:57 AM, Mike Larkin <mlar...@azathoth.net> 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

[Andrew Daugherity]

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 

Re: amd64 OpenBSD 6.2 doesn't see hard disks when controller in RAID mode

[Andrew Daugherity]

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: vmm issues - vioblk_notifyq: unsupported command 0x8

[Andrew Daugherity]

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: spontaneous reboot during upgrade using bsd.rd on VIA C3.

[Andrew Daugherity]

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=150719094005071=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: 

Re: "Missing operating system" after i386 dual boot install

[Andrew Daugherity]

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: openbsd 6.4 as guest VM on Xen cannot detect disk

[Andrew Daugherity]

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: TLS suddenly not working over IKED site-to-site - SOLVED?

[Andrew Daugherity]

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 on AWS - pciide/wd issue

[Andrew Daugherity]

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: Third server now locked up after reboot due to no keyboard attached

[Andrew Daugherity]

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: dhcpd and unbound on a small LAN

[Andrew Daugherity]

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: Help: System hang/Lockup using snapshots on Intel i5 NUC?

[Andrew Daugherity]

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: i386 "panic: pci_make_tag: bad request" after acpi sleep states

[Andrew Daugherity]

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: X11 SIGSEGV on VirtualBox

[Andrew Daugherity]

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: Server certs expired higher up the chain, imaps and https

[Andrew Daugherity]

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: ikev2 fails with mschap-v2

[Andrew Daugherity]

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: No login prompt on console ttyC0 after boot when using "set tty com0"

[Andrew Daugherity]

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: serial console works only if system is booted from it

[Andrew Daugherity]

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: BiDi sfp in ix

[Andrew Daugherity]

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

curl-8.0.1 exists in two non-comparable versions (Someone forgot to bump a REVISION)

[Andrew Daugherity]

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

[Andrew Daugherity]

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: [7.3/i386] pf-badhost - Illegal instruction (core dumped)

[Andrew Daugherity]

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