pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Uwe Dippel
(I searched Google, but not much turned up.)

Since I upgraded to 4.7; what I get is:
# pwd
/etc
# cat pf.conf
# works?
# pfctl -f pf.conf.47
pfctl: DIOCBEGINADDRS: Operation not supported by device
# pfctl -f /etc/pf.conf
pfctl: DIOCXCOMMIT: Device busy

Huh?
(Actually I had used the original pf.conf, with the alterations for
anchors done. Then I got this; and it seems pfctl is doing some
nonsense: even a comment is not read and executed.)

# which pfctl
/sbin/pfctl
# md5 /sbin/pfctl

MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7
(this is amd64)

No changes of the hardware; I have no access to the machine.
Any hint will be appreciated,

Uwe


OpenBSD 4.7 (GENERIC.MP) #130: Wed Mar 17 20:48:50 MDT 2010
     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2146381824 (2046MB)
avail mem = 2079801344 (1983MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xec000 (78 entries)
bios0: vendor HP version "D19" date 07/16/2007
bios0: HP ProLiant ML350 G4p
acpi0 at bios0: rev 2
acpi0: tables DSDT FACP SPCR MCFG APIC
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Xeon(TM) CPU 3.20GHz, 3200.58 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,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,LONG
cpu0: 2MB 64b/line 8-way L2 cache
cpu0: apic clock running at 200MHz
cpu1 at mainbus0: apid 6 (application processor)
cpu1: Intel(R) Xeon(TM) CPU 3.20GHz, 3200.12 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,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,LONG
cpu1: 2MB 64b/line 8-way L2 cache
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Xeon(TM) CPU 3.20GHz, 3200.12 MHz
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,LONG
cpu2: 2MB 64b/line 8-way L2 cache
cpu3 at mainbus0: apid 7 (application processor)
cpu3: Intel(R) Xeon(TM) CPU 3.20GHz, 3200.12 MHz
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,CNXT-ID,CX16,xTPR,LONG
cpu3: 2MB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 8 pa 0xfec00000, version 20, 24 pins
ioapic1 at mainbus0: apid 9 pa 0xfec10000, version 20, 24 pins
ioapic1: misconfigured as apic 0, remapped to apid 9
ioapic2 at mainbus0: apid 10 pa 0xfec80000, version 20, 24 pins
ioapic3 at mainbus0: apid 11 pa 0xfec80400, version 20, 24 pins
acpiprt0 at acpi0: bus 1 (IP2P)
acpiprt1 at acpi0: bus 2 (IPXB)
acpiprt2 at acpi0: bus 6 (PCXA)
acpiprt3 at acpi0: bus 9 (PCXB)
acpiprt4 at acpi0: bus 5 (PTA0)
acpiprt5 at acpi0: bus 13 (PTB0)
acpiprt6 at acpi0: bus 16 (PTC0)
acpiprt7 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpicpu2 at acpi0
acpicpu3 at acpi0
acpitz0 at acpi0: critical temperature 31 degC
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel E7520 Host" rev 0x0c
ppb0 at pci0 dev 2 function 0 "Intel E7520 PCIE" rev 0x0c
pci1 at ppb0 bus 5
ppb1 at pci1 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09
pci2 at ppb1 bus 6
ppb2 at pci1 dev 0 function 2 "Intel PCIE-PCIE" rev 0x09
pci3 at ppb2 bus 9
rl0 at pci3 dev 2 function 0 "D-Link Systems 530TX+" rev 0x10: apic 11
int 0 (irq 3), address 00:11:95:5e:50:ba
rlphy0 at rl0 phy 0: RTL internal PHY
ppb3 at pci0 dev 4 function 0 "Intel E7520 PCIE" rev 0x0c
pci4 at ppb3 bus 13
ppb4 at pci0 dev 6 function 0 "Intel E7520 PCIE" rev 0x0c
pci5 at ppb4 bus 16
ppb5 at pci0 dev 28 function 0 "Intel 6300ESB PCIX" rev 0x02
pci6 at ppb5 bus 2
mpi0 at pci6 dev 3 function 0 "Symbios Logic 53c1030" rev 0x08: apic 9
int 0 (irq 10)
scsibus0 at mpi0: 16 targets, initiator 7
sd0 at scsibus0 targ 0 lun 0: <COMPAQ, BF1468A4CC, HPB5> SCSI3 0/direct
fixed
sd0: 140014MB, 512 bytes/sec, 286749488 sec total
sd1 at scsibus0 targ 2 lun 0: <COMPAQ, BF03688284, HPB3> SCSI3 0/direct
fixed
sd1: 34732MB, 512 bytes/sec, 71132000 sec total
sd2 at scsibus0 targ 5 lun 0: <COMPAQ, BD1468A4C5, HPB4> SCSI3 0/direct
fixed
sd2: 140014MB, 512 bytes/sec, 286749488 sec total
mpi0: target 0 Sync at 160MHz width 16bit offset 63 QAS 1 DT 1 IU 1
mpi0: target 2 Sync at 160MHz width 16bit offset 63 QAS 1 DT 1 IU 1
mpi0: target 5 Sync at 160MHz width 16bit offset 63 QAS 1 DT 1 IU 1
mpi1 at pci6 dev 3 function 1 "Symbios Logic 53c1030" rev 0x08: apic 9
int 1 (irq 10)
scsibus1 at mpi1: 16 targets, initiator 7
uhci0 at pci0 dev 29 function 0 "Intel 6300ESB USB" rev 0x02: apic 8 int
16 (irq 3)
uhci1 at pci0 dev 29 function 1 "Intel 6300ESB USB" rev 0x02: apic 8 int
19 (irq 5)
"Intel 6300ESB WDT" rev 0x02 at pci0 dev 29 function 4 not configured
"Intel 6300ESB APIC" rev 0x02 at pci0 dev 29 function 5 not configured
ehci0 at pci0 dev 29 function 7 "Intel 6300ESB USB" rev 0x02: apic 8 int
23 (irq 7)
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb6 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x0a
pci7 at ppb6 bus 1
bge0 at pci7 dev 2 function 0 "Broadcom BCM5705K" rev 0x03, BCM5705 A3
(0x3003): apic 8 int 17 (irq 11), address 00:15:60:0b:65:60
brgphy0 at bge0 phy 1: BCM5705 10/100/1000baseT PHY, rev. 2
vga1 at pci7 dev 3 function 0 "ATI Rage XL" rev 0x27
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
"Compaq iLO" rev 0x01 at pci7 dev 4 function 0 not configured
"Compaq iLO" rev 0x01 at pci7 dev 4 function 2 not configured
pcib0 at pci0 dev 31 function 0 "Intel 6300ESB LPC" rev 0x02
pciide0 at pci0 dev 31 function 1 "Intel 6300ESB IDE" rev 0x02: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
pciide0: channel 0 disabled (no drives)
atapiscsi0 at pciide0 channel 1 drive 1
scsibus2 at atapiscsi0: 2 targets
cd0 at scsibus2 targ 0 lun 0: <HL-DT-ST, CD-ROM GCR-8482B, 2.09> ATAPI
5/cdrom removable
cd0(pciide0:1:1): using PIO mode 4, Ultra-DMA mode 2
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
isa0 at pcib0
isadma0 at isa0
com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
com0: console
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
pms0 at pckbc0 (aux slot)
pckbc0: using irq 12 for aux slot
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: <PC speaker>
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
ugen0 at uhub2 port 1 "American Power Conversion Back-UPS RS 1000
FW:7.g8 .I USB FW:g8" rev 1.10/1.06 addr 2
vscsi0 at root
scsibus3 at vscsi0: 256 targets
softraid0 at root
root on sd0a swap on sd0b dump on sd0b

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33160
         priority: 0
         groups: lo
         inet 127.0.0.1 netmask 0xff000000
         inet6 ::1 prefixlen 128
         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
rl0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
         lladdr 00:11:95:5e:50:ba
         priority: 0
         media: Ethernet autoselect
         status: no carrier
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         lladdr 00:15:60:0b:65:60
         priority: 0
         groups: egress
         media: Ethernet 100baseTX full-duplex
         status: active
         inet 172.16.0.14 netmask 0xffffff00 broadcast 172.16.0.255
         inet6 fe80::215:60ff:fe0b:6560%bge0 prefixlen 64 scopeid 0x2
enc0: flags=0<> mtu 1536
         priority: 0
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33160
         priority: 0
         groups: pflog

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Philip Guenther-2
On Mon, May 31, 2010 at 6:20 AM, Uwe Dippel <[hidden email]> wrote:
> (I searched Google, but not much turned up.)

Was there a common thread to what did turn up?  My recall is that
basically every time people get "Operation not supported by device"
errors from pfctl, it's because their userland and kernel don't match.


> Since I upgraded to 4.7; what I get is:
> # pwd
> /etc
> # cat pf.conf
> # works?
> # pfctl -f pf.conf.47
> pfctl: DIOCBEGINADDRS: Operation not supported by device

That ioctl (DIOCBEGINADDRS) was removed between 4.6 and 4.7.  Ergo,
that is *NOT* a 4.7 pfctl binary.

> # which pfctl
> /sbin/pfctl
> # md5 /sbin/pfctl
> MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7
> (this is amd64)

$ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/base47.tgz ./sbin/pfctl
$ md5 sbin/pfctl
MD5 (sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4

Review your upgrade procedure, because it's clearly broken.


Philip Guenther

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Uwe Dippel
On 06/01/2010 05:32 AM, Philip Guenther wrote:

> Was there a common thread to what did turn up?  My recall is that
> basically every time people get "Operation not supported by device"
> errors from pfctl, it's because their userland and kernel don't match.

> Review your upgrade procedure, because it's clearly broken.

Thanks for your help, seriously. And I don't want to start arguing, not
at all, but this is one of my production boxes, without access, and I
have been running the boot.bsd.rd updates since 3.8 twice a year.
Being production, I diligently watched, and saw with my own eyes the
asterisks advancing. I can only say, I followed standard procedures; if
just for my own sanity.
I *am* losing the latter, because it seems that all files in /sbin are
identical to my box still on 4.6; though something has happened to them
yesterday:

(this is my 4.6-box, upgraded only on April 19th:)
$ ls -l /sbin/p*

-r-xr-xr-x  1 root  bin  492664 Apr 19 13:44 /sbin/pfctl
-r-xr-xr-x  1 root  bin  390264 Apr 19 13:44 /sbin/pflogd
-r-sr-xr-x  1 root  bin  210040 Apr 19 13:44 /sbin/ping
-r-sr-xr-x  1 root  bin  234616 Apr 19 13:44 /sbin/ping6

(This is my box upgraded yesterday, May 31st, to 4.7:)
# ls -l /sbin/p*

-r-xr-xr-x  1 root  bin  492664 May 31 20:28 /sbin/pfctl
-r-xr-xr-x  1 root  bin  390264 May 31 20:28 /sbin/pflogd
-r-sr-xr-x  1 root  bin  210040 May 31 20:28 /sbin/ping
-r-sr-xr-x  1 root  bin  234616 May 31 20:28 /sbin/ping6

So it did something, from where did it get the old files? I guess not
from a mistake on my side, because I accepted the upgrade path in the
Upgrade shell. Plus:
OpenBSD 4.7 (GENERIC.MP) #130: Wed Mar 17 20:48:50 MDT 2010
     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
I never copied any myself down here. As I mentioned, production, upgrade
twice per year through serial console.

And now my sanity seems to fade: I did the same to one of my i386-boxen,
and exactly the same happens there!! (Please, now I am starting to lose
ground under my feet!)
This is after the update to 4.7, i386, in front of the screen!:

(mnt is /altroot, mounted just now to check; since pfctl did the same
thing, again, here)
# ls -l /mnt/sbin/p*

-r-xr-xr-x  1 root  bin  422648 Apr 19 12:51 /mnt/sbin/pfctl
-r-xr-xr-x  1 root  bin  328440 Apr 19 12:51 /mnt/sbin/pflogd
-r-sr-xr-x  1 root  bin  180984 Apr 19 12:51 /mnt/sbin/ping
-r-sr-xr-x  1 root  bin  197368 Apr 19 12:51 /mnt/sbin/ping6
# ls -l /sbin/p*
-r-xr-xr-x  1 root  bin  422648 Jun  1 12:54 /sbin/pfctl
-r-xr-xr-x  1 root  bin  328440 Jun  1 12:54 /sbin/pflogd
-r-sr-xr-x  1 root  bin  180984 Jun  1 12:54 /sbin/ping
-r-sr-xr-x  1 root  bin  197368 Jun  1 12:54 /sbin/ping6

A mix-up of versions? I don't think so, because
$ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/base47.tgz ./sbin/pfctl
$ md5 sbin/pfctl
MD5 (sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4
exactly what you had.

Now I start to not exclude a bug any longer. Maybe under some
circumstances, the files are not overwritten, but touched; or whatnot.?

This leaves me with two questions:

1. How to debug what goes on?

2. (and more important for me): What to do? Should I tar xzvphf
{file}47.tgz; or try an new upgrade?

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Joachim Schipper-2
On Tue, Jun 01, 2010 at 04:07:47PM +0800, Uwe Dippel wrote:

> On 06/01/2010 05:32 AM, Philip Guenther wrote:
>
> >Was there a common thread to what did turn up?  My recall is that
> >basically every time people get "Operation not supported by device"
> >errors from pfctl, it's because their userland and kernel don't match.
>
> >Review your upgrade procedure, because it's clearly broken.
>
> Thanks for your help, seriously. And I don't want to start arguing,
> not at all, but this is one of my production boxes, without access,
> and I have been running the boot.bsd.rd updates since 3.8 twice a
> year.
> Being production, I diligently watched, and saw with my own eyes the
> asterisks advancing. I can only say, I followed standard procedures;
> if just for my own sanity.
> I *am* losing the latter, because it seems that all files in /sbin
> are identical to my box still on 4.6; though something has happened
> to them yesterday:
>
> (this is my 4.6-box, upgraded only on April 19th:)
> $ ls -l /sbin/p*
>
> -r-xr-xr-x  1 root  bin  492664 Apr 19 13:44 /sbin/pfctl
> -r-xr-xr-x  1 root  bin  390264 Apr 19 13:44 /sbin/pflogd
> -r-sr-xr-x  1 root  bin  210040 Apr 19 13:44 /sbin/ping
> -r-sr-xr-x  1 root  bin  234616 Apr 19 13:44 /sbin/ping6
>
> (This is my box upgraded yesterday, May 31st, to 4.7:)
> # ls -l /sbin/p*
>
> -r-xr-xr-x  1 root  bin  492664 May 31 20:28 /sbin/pfctl
> -r-xr-xr-x  1 root  bin  390264 May 31 20:28 /sbin/pflogd
> -r-sr-xr-x  1 root  bin  210040 May 31 20:28 /sbin/ping
> -r-sr-xr-x  1 root  bin  234616 May 31 20:28 /sbin/ping6
>
> So it did something, from where did it get the old files? I guess
> not from a mistake on my side, because I accepted the upgrade path
> in the Upgrade shell. Plus:
> OpenBSD 4.7 (GENERIC.MP) #130: Wed Mar 17 20:48:50 MDT 2010
>     [hidden email]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> I never copied any myself down here. As I mentioned, production,
> upgrade twice per year through serial console.
>
> And now my sanity seems to fade: I did the same to one of my
> i386-boxen, and exactly the same happens there!! (Please, now I am
> starting to lose ground under my feet!)
> This is after the update to 4.7, i386, in front of the screen!:
>
> (mnt is /altroot, mounted just now to check; since pfctl did the
> same thing, again, here)
> # ls -l /mnt/sbin/p*
>
> -r-xr-xr-x  1 root  bin  422648 Apr 19 12:51 /mnt/sbin/pfctl
> -r-xr-xr-x  1 root  bin  328440 Apr 19 12:51 /mnt/sbin/pflogd
> -r-sr-xr-x  1 root  bin  180984 Apr 19 12:51 /mnt/sbin/ping
> -r-sr-xr-x  1 root  bin  197368 Apr 19 12:51 /mnt/sbin/ping6
> # ls -l /sbin/p*
> -r-xr-xr-x  1 root  bin  422648 Jun  1 12:54 /sbin/pfctl
> -r-xr-xr-x  1 root  bin  328440 Jun  1 12:54 /sbin/pflogd
> -r-sr-xr-x  1 root  bin  180984 Jun  1 12:54 /sbin/ping
> -r-sr-xr-x  1 root  bin  197368 Jun  1 12:54 /sbin/ping6
>
> A mix-up of versions? I don't think so, because
> $ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/base47.tgz ./sbin/pfctl
> $ md5 sbin/pfctl
> MD5 (sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4
> exactly what you had.
>
> Now I start to not exclude a bug any longer. Maybe under some
> circumstances, the files are not overwritten, but touched; or
> whatnot.?
>
> This leaves me with two questions:
>
> 1. How to debug what goes on?
>
> 2. (and more important for me): What to do? Should I tar xzvphf
> {file}47.tgz; or try an new upgrade?

Just untarring the release should work, but it's still odd. At least the
md5sum of pfctl matches what I just downloaded, so that seems fine; did
you actually use *that* tarball, though? (Note that the "right" pfctl
binary is 500856 bytes long.)

Are you sure that you upgraded the right disk?

                Joachim

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Uwe Dippel
In reply to this post by Uwe Dippel
Joachim Schipper <joachim <at> joachimschipper.nl> writes:

 > Just untarring the release should work, but it's still odd. At least
 > the md5sum of pfctl matches what I just downloaded, so that seems
 > fine; did you actually use *that* tarball, though? (Note that the
 > "right" pfctl binary is 500856 bytes long.)
 >
 > Are you sure that you upgraded the right disk?

Yep.

When I untar the files (I have them locally on a webserver:
ftp://metalab.uniten.edu.my/pub/OpenBSD/4.7/
all files come out perfectly well, as above. I did the upgrades using
this URL; I am sure it were these files, because they only exist once
locally (the speed with which the updates were done is proof that I used
these local resources, downloaded by myself). In the Upgrade procedure I
only added the (internal) IP for that server, accepting all else. And it
can't be 4.6 that I used, kind of, because the installed (upgraded)
kernel is 4.7.
I need to repeat, this is a remote production machine with serial
access. I have no desire ever to do anything not along clear procedures,
and I followed the Upgrade Guide 4.6->4.7 meticulously (system
administration is part of my job description), even ticking off point
after point on the printout of the upgrade guide.
So something was done to the files, at least they have the new time
stamp, and some files have actually been installed correctly (kernels);
as the hashsums show. So, finally, I *was* in the right directory and
installed to the correct disk.
Here are the kernels, on the first machine, that has seemingly the
previous 'base' throughout:
# cksum -a sha256 bsd
SHA256 (bsd) =
e2af09ed48d1d94bec27aa4c18ffa6172d8435a190c3abecae53d26940ed9536
# cksum -a sha256 bsd.sp
SHA256 (bsd.sp) =
a34175b766d6ea9cefcc0903efa51c4dc3d87018b1e2f85c2333133ed25e9ff4

Now I wonder if the problem was with the untar? Maybe all sets have not
been installed properly? Next, I will have to identify for each and
every set, a sample file, and check if it is the previous one or the
recent one.

Very, very strange ...

Thanks so much, you did actually help me a step further,

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

TeXitoi-4
In reply to this post by Joachim Schipper-2
Joachim Schipper <[hidden email]> writes:

> On Tue, Jun 01, 2010 at 04:07:47PM +0800, Uwe Dippel wrote:
> > On 06/01/2010 05:32 AM, Philip Guenther wrote:
> >
> > >Review your upgrade procedure, because it's clearly broken.
> >
> > Thanks for your help, seriously. And I don't want to start arguing,
> > not at all, but this is one of my production boxes, without access,
> > and I have been running the boot.bsd.rd updates since 3.8 twice a
> > year.
> > Being production, I diligently watched, and saw with my own eyes the
> > asterisks advancing. I can only say, I followed standard procedures;
> > if just for my own sanity.
> > I *am* losing the latter, because it seems that all files in /sbin
> > are identical to my box still on 4.6; though something has happened
> > to them yesterday:
>
> Just untarring the release should work, but it's still odd. At least the
> md5sum of pfctl matches what I just downloaded, so that seems fine; did
> you actually use *that* tarball, though? (Note that the "right" pfctl
> binary is 500856 bytes long.)
>
> Are you sure that you upgraded the right disk?

I heard that some mirrors had corrupted tarball. Maybe it is related.

--
Guillaume Pinot               http://www.irccyn.ec-nantes.fr/~pinot/

+ Les grandes personnes ne comprennent jamais rien toutes seules, et
c'est fatigant, pour les enfants, de toujours leur donner des
explications... ; -- Antoine de Saint-Exupiry, Le Petit Prince

()  ASCII ribbon campaign      -- Against HTML e-mail
/\  http://www.asciiribbon.org -- Against proprietary attachments

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Stuart Henderson
On 2010-06-01, TeXitoi <[hidden email]> wrote:
>
> I heard that some mirrors had corrupted tarball.

Huh?

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

TeXitoi-4
Stuart Henderson <[hidden email]> writes:

> On 2010-06-01, TeXitoi <[hidden email]> wrote:
> >
> > I heard that some mirrors had corrupted tarball.
>
> Huh?

http://thread.gmane.org/gmane.os.openbsd.french/2168

(in french)

it was ports.tar.gz, here.

--
Guillaume Pinot               http://www.irccyn.ec-nantes.fr/~pinot/

+ Les grandes personnes ne comprennent jamais rien toutes seules, et
c'est fatigant, pour les enfants, de toujours leur donner des
explications... ; -- Antoine de Saint-Exupiry, Le Petit Prince

()  ASCII ribbon campaign      -- Against HTML e-mail
/\  http://www.asciiribbon.org -- Against proprietary attachments

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Gonzalo Rodriguez-2
In reply to this post by Uwe Dippel
Download again the tar files from official mirrors and try again the upgrade.

2010/6/1 Uwe Dippel <[hidden email]>:

> Joachim Schipper <joachim <at> joachimschipper.nl> writes:
>
>> Just untarring the release should work, but it's still odd. At least > the
>> md5sum of pfctl matches what I just downloaded, so that seems
>> fine; did you actually use *that* tarball, though? (Note that the
>> "right" pfctl binary is 500856 bytes long.)
>>
>> Are you sure that you upgraded the right disk?
>
> Yep.
>
> When I untar the files (I have them locally on a webserver:
> ftp://metalab.uniten.edu.my/pub/OpenBSD/4.7/
> all files come out perfectly well, as above. I did the upgrades using this
> URL; I am sure it were these files, because they only exist once locally
> (the speed with which the updates were done is proof that I used these local
> resources, downloaded by myself). In the Upgrade procedure I only added the
> (internal) IP for that server, accepting all else. And it can't be 4.6 that
> I used, kind of, because the installed (upgraded) kernel is 4.7.
> I need to repeat, this is a remote production machine with serial access. I
> have no desire ever to do anything not along clear procedures, and I
> followed the Upgrade Guide 4.6->4.7 meticulously (system administration is
> part of my job description), even ticking off point after point on the
> printout of the upgrade guide.
> So something was done to the files, at least they have the new time stamp,
> and some files have actually been installed correctly (kernels); as the
> hashsums show. So, finally, I *was* in the right directory and installed to
> the correct disk.
> Here are the kernels, on the first machine, that has seemingly the
> previous 'base' throughout:
> # cksum -a sha256 bsd
> SHA256 (bsd) =
> e2af09ed48d1d94bec27aa4c18ffa6172d8435a190c3abecae53d26940ed9536
> # cksum -a sha256 bsd.sp
> SHA256 (bsd.sp) =
> a34175b766d6ea9cefcc0903efa51c4dc3d87018b1e2f85c2333133ed25e9ff4
>
> Now I wonder if the problem was with the untar? Maybe all sets have not been
> installed properly? Next, I will have to identify for each and every set, a
> sample file, and check if it is the previous one or the recent one.
>
> Very, very strange ...
>
> Thanks so much, you did actually help me a step further,
>
> Uwe

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Uwe Dippel
From: Gonzalo Rodriguez [[hidden email]]
Subject: Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Download again the tar files from official mirrors and try again the upgrade.

Thanks, Gonzalo,

but the files (sets) are correct according to their SHA256.
I have actually advanced with the problem, and inspired by Joachim's
intervention.
It seems all sets of 4.7 were installed during the otherwise flawless upgrade,
except of base47.tar.
I selected randomly files from all tar-packages (sets) that changed from 4.6
to 4.7, and compared those installed in the machine upgraded to 4.7 with those
from the tar archives ('sets'). Except of base47, everything looks fine
(identical). Only, as far as I can make out now, all (??) files of base47 were
not installed.
It is late here, I'm going to sleep, but tomorrow I'll try the same on the
i386. And chances are, the same thing happened there as well. At least the
re-occurrence of the failure of pfctl suggests so, as of now.
I really wonder, under which circumstances the installer would fail to deposit
its files in the foreseen locations; for one, the first, archive (set)?

My question remains, since this is a production machine and I don't feel like
tinkering with it: Since it is one set that failed to upgrade: what is
recommended: a whole new upgrade, or just extraction of that set into the
machine?
(I am so happy that it basically works, The only thing failing regularly until
now is the communication with apcupsd, which was always flawless. It fails
with "apcupsd[18529]: apcserver: accept error. ERR=Software caused". I guess
it has to make with some out-of-sync files of the base46 set within a 4.7
machine. I hope so.)

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Stuart Henderson
In reply to this post by TeXitoi-4
On 2010-06-01, TeXitoi <[hidden email]> wrote:
> Stuart Henderson <[hidden email]> writes:
>
>> On 2010-06-01, TeXitoi <[hidden email]> wrote:
>> >
>> > I heard that some mirrors had corrupted tarball.
>>
>> Huh?
>
> http://thread.gmane.org/gmane.os.openbsd.french/2168
..
> it was ports.tar.gz, here.

ok, that's better. Rather than just throwing out "I heard that some
mirrors had corrupted tarball" it would have been better to give the
details so people have some idea if they might have been affected.
(Though note that the installer does warn you if the checksum of the
set doesn't match the checksum stored in the installer, so people
would have noticed quite clearly if this affected the main *47.tgz
files).

> (in french)

given the list it was posted on, I would be disappointed if it wasn't :)

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

udippel (Bugzilla)
In reply to this post by Joachim Schipper-2
Joachim Schipper <joachim <at> joachimschipper.nl> writes:

> Just untarring the release should work, but it's still odd. At least the
> md5sum of pfctl matches what I just downloaded, so that seems fine; did
> you actually use *that* tarball, though? (Note that the "right" pfctl
> binary is 500856 bytes long.)

Make this thread closed.
I manually 'upgraded' (only) the file /sbin/pfctl from exactly the archive used
at the upgrade 4.6->4.7 procedure, and everything 'pfctl' works fine.
This leaves us with the problem of the failed upgrade procedure, twice now.

Thanks to all contributors in this thread!

Uwe

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

Damon McMahon
In reply to this post by Uwe Dippel
2010/6/1  Uwe Dippel <[hidden email]>

> To: Philip Guenther <[hidden email]>
> Date: Tue, 01 Jun 2010 16:07:47 +0800
> Subject: Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
> On 06/01/2010 05:32 AM, Philip Guenther wrote:
>
>> Was there a common thread to what did turn up?  My recall is that
>> basically every time people get "Operation not supported by device"
>> errors from pfctl, it's because their userland and kernel don't match.
>
>> Review your upgrade procedure, because it's clearly broken.
>
> Thanks for your help, seriously. And I don't want to start arguing, not at
all, but this is one of my production boxes, without access, and I have been
running the boot.bsd.rd updates since 3.8 twice a year.
> Being production, I diligently watched, and saw with my own eyes the
asterisks advancing. I can only say, I followed standard procedures; if just
for my own sanity.
> I *am* losing the latter, because it seems that all files in /sbin are
identical to my box still on 4.6; though something has happened to them
yesterday:

[snip]

Probably no help, but I had similar happen to me upgrading 4.5->4.6 a
few months ago. Similar problem with pftcl after a diligent upgrade,
and like you I have been following the upgrade procedure diligently
since 3.something. I checked the timestamp on pfctl, it didn't seem
right so I built from source and installed and the issue went away, so
I assumed I had something wrong and thought nothing of it as generally
if OpenBSD f*cks up it's down to me and not the developers ;-)

I'd be interested to see if there's a common thread here, particularly
before I upgrade this box to 4.7 which (like yours) is a remote box
which will be upgraded over serial.

Reply | Threaded
Open this post in threaded view
|

Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT

udippel (Bugzilla)
Damon McMahon <damon.mcmahon <at> gmail.com> writes:


> Probably no help, but I had similar happen to me upgrading 4.5->4.6 a
> few months ago. Similar problem with pftcl after a diligent upgrade,
> and like you I have been following the upgrade procedure diligently
> since 3.something. I checked the timestamp on pfctl, it didn't seem
> right so I built from source and installed and the issue went away, so
> I assumed I had something wrong and thought nothing of it as generally
> if OpenBSD f*cks up it's down to me and not the developers

Thanks so much! You saved my upcoming weekend. So I am not hallucinating.
Of course, never expected the developers to solve *my* problems; only wanted to
exclude a bug hitting others.

You're better than me, and I only learned yesterday that the install-set files
come back with the time stamp of creation. Had I known this, a lot could have
been spared, because my second post already showed a lot of bad time stamps in
/sbin.

This 'strange' time stamp (see my earlier post) of "May 31 20:28" still prevails
in a number of files on my box:
# ls -lR | grep "May 31 20:28" | wc -l      
     153
, *after* I replaced the differing files in /sbin.
 
> I'd be interested to see if there's a common thread here, particularly
> before I upgrade this box to 4.7 which (like yours) is a remote box
> which will be upgraded over serial.

I guess so. By now I'll have the list of the files affecting amd64 and i386 in
these cases, and you should be able to correct everything using these lists.

Maybe interesting enough, this timestamp was *not* when I upgraded the sets. It
was the time when I upgraded the packages, respectively applied the patches.

But from now on I'll be mum (I hope I can!) on this topic until a complete
explanation is available.

Uwe