Re: OpenBSD in a dual stack anycast DNS resolving setup
Kostas Zorbadelos writes: I want to thank anyone who contributed info both on and off-list. Regards, Kostas -- Kostas Zorbadelos twitter:@kzorbadelos http://gr.linkedin.com/in/kzorba () www.asciiribbon.org - against HTML e-mail & proprietary attachments /\
Re: Automatic "fsck -y" at Boot
Am Freitag, 16. Dezember 2011, 21:49:18 schrieb Henning Brauer: > in these cases - where "runs" is the top priority and manual > intervention is hard - you most probably want to run with ro / and an > mfs or three. This is one nice approach but doesn't cover features like user changeable settings and parameters, much less local error logs. > this is still a bit like "fixing" holey condoms with duct tape. You fixed the holey condoms issue by replacing them with 5mm thick kevlar. Your solution is certainly very l33t, but only few will want to use it ;) I agree that there are lots of situations where an automated fsck -y in the boot scripts is a bad idea (think of faulty RAM on a file server). I also agree that it's a good idea to use "fsck -p" as the safe default on a fresh install. There are, however, countless situations where "fsck -y" or similar is the most workable solution, and attacking people who use "fsck -y" after careful consideration as irresponsible cheapskates is neither helpful nor professional. Of all the experts here: how many of you have ever intervened in a failed "fsck -p" situation with anything else than an fsck and a barrage of "y" ?
Re: Odd Network Lockups
I just noticed the vether/tun/bridge in your systat output. To try and narrow things down, are you able to disable these to see if there's any improvement? On 2011-12-08, Nick Templeton wrote: > I think you're right Stuart, raising kern.maxclusters is only buying me time. > > The only sysctl values I've modified are: > net.inet.ip.forwarding=1 > ddb.panic=0 > kern.maxclusters=8192 > > netstat -m shows increasing values over time, here's the output from > this morning: > > 3510 mbufs in use: > 3479 mbufs allocated to data > 24 mbufs allocated to packet headers > 7 mbufs allocated to socket names and addresses > 3477/3522/8192 mbuf 2048 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 4096 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 8192 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 9216 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 12288 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 16384 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 65536 byte clusters in use (current/peak/max) > 8204 Kbytes allocated to network (95% in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > > ...and here it is from this evening: > > 3718 mbufs in use: >3687 mbufs allocated to data >24 mbufs allocated to packet headers >7 mbufs allocated to socket names and addresses > 3685/3734/8192 mbuf 2048 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 4096 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 8192 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 9216 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 12288 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 16384 byte clusters in use (current/peak/max) > 0/8/8192 mbuf 65536 byte clusters in use (current/peak/max) > 8628 Kbytes allocated to network (96% in use) > 0 requests for memory denied > 0 requests for memory delayed > 0 calls to protocol drain routines > > Here's the output from systat mbuf: > > 1 usersLoad 0.65 0.79 0.76 Wed Dec 7 18:15:12 > 2011 > > IFACE LIVELOCKS SIZE ALIVE LWM HWM CWM > System0 256 3716 242 >2k 36861867 > lo0 > em02k21 4 25621 > em12k20 4 25620 > em22k14 4 25614 > enc0 > vether0 > tun0 > bridge0 > pflog0 > > I did update the kernel at the same time as changing the bios settings, so > that > led me down the wrong path I think. Digging through /var/log/messages* it > looks > as though things changed when I upgraded from the October 6th snapshot to the > November 15th snapshot. When I was running this (and previous snapshots): > > OpenBSD 5.0-current (GENERIC.MP) #96: Thu Oct 6 16:12:43 MDT 2011 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > ...I had a bunch of these errors (but no network lockups): > > pf: state key linking mismatch! dir=OUT, if=em1, stored af=2, a0: > 76.126.243.211:25619, a1: 192.168.10.2:49200, proto=17, found af=2, a0: > 176.15.107.37:45022, a1: 239.190.175.222:61374, proto=17 > > After updating to this (and another update since): > > OpenBSD 5.0-current (GENERIC.MP) #133: Tue Nov 15 22:08:20 MST 2011 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > ...I now have these warnings (and the network lockups): > > WARNING: mclpools limit reached; increase kern.maxclusters > > -Nick > > On Tue, Dec 6, 2011 at 11:21 AM, Stuart Henderson > wrote: >> Have you adjusted any other sysctl values? >> >> What does netstat -m say? Run it once, then again after 30 mins or so. >> >> What does systat mbuf say? >> >> Did you update the kernel at the same time as changing bios settings? >> If so, what did you run before? (check /var/log/messages*) >> >> I doubt there's a legitimate reason to increase kern.maxclusters to >> 8192 on this system, best I think you can hope for with that is to make >> it run for a little longer before crashing. >> >> >> >> On 2011-12-06, Nick Templeton wrote: >>> You're right that I had an outdated BIOS, which I've now updated, but >>> upon further review I don't think that is/was the culprit. I've since >>> had the issue re-surface and this time I noticed many lines like this >>> in the dmesg (not sure how I missed it before): >>> >>> WARNING: mclpools limit reached; increase kern.maxclusters >>> >>> So I've upped kern.maxclusters to 8192, however, I'm not sure if I >>> really should need to. This machine is a firewall/router for my home >>> network running a few services (sshd, named, httpd, tomcat) for about >>> 5 users. There's also a machine that is running Transmission >>> BitTorrent client behind the firewall, maybe that could be the >>> culprit? >>> >>> -Nick >>> >>> On Fri, Dec 2, 2011 at 9:29 AM, Erling Westenvik >>> wrote: Y
Re: Where to buy Lemote FuLoong MIPS boxes?
On Fri, 16 Dec 2011 23:04:20 +0100 Steffen Daode Nurpmeso wrote: > Welly, welly, welly, welly, welly, welly, well! > > I dunno, but maybe Fritz simply misunderstood "A Clockwork > Orange" - completely, that is? > The same actor also played in "Caligula". > That one is much much better for your handwork, Fritz! > > And couldn't some cute Austrian restart selling OpenBSD in Austria, > now that Fritz no longer uses an austrian remailer?? > I feel so uncomfortable - as if Lada would no longer produce Nivas! > (Taiga in Austria, right?) Taiga and Niva is two different models, just for the record... -- With best regards, Gregory Edigarov
Re: OpenBGPD not reporting blackhole as nexthop from bgpctl output
On Sun, Dec 18, 2011 at 06:14:19PM -0600, Chris Wopat wrote:
> Claudio and crew,
>
> Unsure if this is a bug or intended. I was testing BGP triggered
> blackholes, one of the routers that will perform the blackhole has
> this rule in its bgpd.conf:
>
> match from group GROUP-IBGP community 1234:666 set { localpref 200
> origin igp nexthop blackhole }
>
>
> Looking exclusively at the bgpctl output makes it appear to be not
> working (186.4.134.249 is a blocked source, 10.171.0.66 is the router
> triggering the blackhole, it should NOT be the nexthop):
>
> # bgpctl show ip bgp detail 186.4.134.249
>
> BGP routing table entry for 186.4.134.249/32
> Nexthop 10.171.0.66 (via 10.171.7.166) from rr1 (10.171.0.16)
> Origin IGP, metric 0, localpref 200, internal, valid, best
> Last update: 00:01:42 ago
> Communities: 1239:66 3356: 4150:666 NO_EXPORT
> Originator Id: 10.171.0.66
> Cluster ID List: 10.171.0.16
>
>
> When you look at the actual routing table though, it is blackholed and
> is functioning properly:
>
> # netstat -nr | grep 186.4.134.249
> 186.4.134.249/32 127.0.0.1 UGB0 14 3316048 lo0
>
>
> Is this intended behavior?
>
Good question, it seems that the nexthop flags (reject/blackhole) are not
shown in the "show rib detail" output. I guess the via should print out
blackhole in your case.
The "bgpctl show fib" output will show the B flag (IIRC).
--
:wq Claudio
kernel panic (mii_phy_setmedia) on mac mini A1347
Hi,
I tried to install OpenBSD 4.9 on an Apple mac mini (new
generation).
Model : A1347
Core i5, thunderbolt Technology, HD 500Go
At
installation using 4.9 RELEASE :
It takes a long time to format slides.
At the reboot : i have a kernel panic just after "starting network"
So i
tried to use 5.0 RELEASE.
This time, it formats quickly. But it is the same
way : kernel panic when it starts the network.
The following message
appear :
Starting network
panic: mii_phy_setmedia
Stopped at
Debugger+0x4:popl %ebp
a "show panic" at the ddb prompt:
mii_phy_setmedia
I can't note "trace" message, i have no serial port on the mac... :(
So
you can see the trace message attached (picture)
and the "ps" message
attached (picture)
here is the dmesg issue : boot on bsd.rd :
OpenBSD
5.0 (RAMDISK_CD) #36: Wed Aug 17 10:27:31 MDT 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
RTC BIOS
diagnostic error a9
cpu0: Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz
("GenuineIntel" 686-class) 2.30 GHz
cpu0:
FPU,V86,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,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX
real
mem = 2047619072 (1952MB)
avail mem = 2007117824 (1914MB)
mainbus0 at
root
bios0 at mainbus0: AT/286+ BIOS, date 07/29/05, SMBIOS rev. 2.4 @
0xe (61 entries)
bios0: vendor Apple Inc. version
"MM51.88Z.0075.B00.1106271442" date 06/27/2011
bios0: Apple Inc.
Macmini5,1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0:
tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT
SSDT SSDT MCFG SSDT SSDT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT
compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running
at 99MHz
cpu at mainbus0: not configured
cpu at mainbus0: not
configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa
0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped
to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1
(P0P2)
acpiprt2 at acpi0: bus 5 (PEG1)
acpiprt3 at acpi0: bus 2
(RP01)
acpiprt4 at acpi0: bus -1 (RP02)
acpiprt5 at acpi0: bus 3
(RP03)
bios0: ROM list: 0xc/0xee00
memory map conflict
0xe00f8000/0x1000
memory map conflict 0xfed1c000/0x4000
memory map conflict
0xffed/0x3
pci0 at mainbus0 bus 0: configuration mode 1
(bios)
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
ppb0 at
pci0 dev 1 function 0 "Intel Core 2G PCIE" rev 0x09: apic 2 int 16
pci1 at
ppb0 bus 1
ppb1 at pci0 dev 1 function 1 "Intel Core 2G PCIE" rev 0x09:
apic 2 int 16
pci2 at ppb1 bus 5
ppb2 at pci2 dev 0 function 0 vendor
"Intel", unknown product 0x1513 rev 0x00
pci3 at ppb2 bus 6
ppb3 at pci3
dev 0 function 0 vendor "Intel", unknown product 0x1513 rev 0x00: apic 2
int 17
pci4 at ppb3 bus 7
vendor "Intel", unknown product 0x1513 (class
system subclass miscellaneous, rev 0x00) at pci4 dev 0 function 0 not
configured
ppb4 at pci3 dev 3 function 0 vendor "Intel", unknown product
0x1513 rev 0x00: apic 2 int 16
pci5 at ppb4 bus 8
ppb5 at pci3 dev 4
function 0 vendor "Intel", unknown product 0x1513 rev 0x00: apic 2 int
17
pci6 at ppb5 bus 9
ppb6 at pci3 dev 5 function 0 vendor "Intel", unknown
product 0x1513 rev 0x00: apic 2 int 18
pci7 at ppb6 bus 58
ppb7 at pci3 dev
6 function 0 vendor "Intel", unknown product 0x1513 rev 0x00: apic 2 int
19
pci8 at ppb7 bus 107
vga1 at pci0 dev 2 function 0 "Intel GT2+ Video"
rev 0x09
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
"Intel
6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
uhci0 at
pci0 dev 26 function 0 vendor "Intel", unknown product 0x1c2c rev 0x05:
apic 2 int 21
ehci0 at pci0 dev 26 function 7 "Intel 6 Series USB" rev
0x05: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel
EHCI root hub" rev 2.00/1.00 addr 1
"Intel 6 Series HD Audio" rev 0x05 at
pci0 dev 27 function 0 not configured
ppb8 at pci0 dev 28 function 0 "Intel
6 Series PCIE" rev 0xb5: apic 2 int 16
pci9 at ppb8 bus 2
bge0 at pci9 dev
0 function 0 "Broadcom BCM57765" rev 0x10, unknown BCM57765 (0x57785100):
apic 2 int 16, address 3c:07:54:0c:6b:b7
ukphy0 at bge0 phy 1: Generic IEEE
802.3u media interface, rev. 4: OUI 0x00d897, model 0x0024
"Broadcom SD
Host Controller" rev 0x10 at pci9 dev 0 function 1 not configured
ppb9 at
pci0 dev 28 function 2 "Intel 6 Series PCIE" rev 0xb5: apic 2 int 18
pci10
at ppb9 bus 3
ppb10 at pci10 dev 0 function 0 vendor "TI", unknown product
0x823e rev 0x01
pci11 at ppb10 bus 4
vendor "TI", unknown product 0x823f
(class serial bus subclass Firewire, rev 0x01) at pci11 dev 0 function 0
not configured
uhci1 at pci0 dev 29 function 0 vendor "Intel", unknown
product 0x1c27 rev 0x05: apic 2 int 19
ehci1 at pci0 dev 29 function 7
"Intel 6 Series USB" rev 0x05: apic 2 int 22
usb1 at ehci1: USB revision
2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
pcib0 at pci0
dev 31 function 0 "Intel HM65 LPC" rev
kernel panic (mii_phy_setmedia) on mac mini A1347 with trace and ps picture url
Hi,
I tried to install OpenBSD 4.9 on an Apple mac mini (new
generation).
Model : A1347 ;
Core i5, thunderbolt Technology, HD 500Go
At
installation using 4.9 RELEASE :
It takes a long time to format slides.
At the reboot : i have a kernel panic just after "starting network"
So i
tried to use 5.0 RELEASE.
This time, it formats quickly. But it is the same
way : kernel panic when it starts the network.
The following message
appear :
Starting network
panic: mii_phy_setmedia
Stopped at
Debugger+0x4:popl %ebp
a "show panic" at the ddb prompt:
mii_phy_setmedia
I can't note "trace" message, i have no serial port on the mac... :(
Here is the ps message : http://i43.tinypic.com/mkufyo.jpg
Here is the
trace message : http://i40.tinypic.com/25syfxf.jpg
here is the dmesg
issue : boot on bsd.rd :
OpenBSD 5.0 (RAMDISK_CD) #36: Wed Aug 17
10:27:31 MDT 2011
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/RAMDISK_CD
RTC BIOS
diagnostic error a9
cpu0: Intel(R) Core(TM) i5-2415M CPU @ 2.30GHz
("GenuineIntel" 686-class) 2.30 GHz
cpu0:
FPU,V86,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,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX
real
mem = 2047619072 (1952MB)
avail mem = 2007117824 (1914MB)
mainbus0 at
root
bios0 at mainbus0: AT/286+ BIOS, date 07/29/05, SMBIOS rev. 2.4 @
0xe (61 entries)
bios0: vendor Apple Inc. version
"MM51.88Z.0075.B00.1106271442" date 06/27/2011
bios0: Apple Inc.
Macmini5,1
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0:
tables DSDT FACP HPET APIC SBST ECDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT
SSDT SSDT MCFG SSDT SSDT SSDT
acpimadt0 at acpi0 addr 0xfee0: PC-AT
compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running
at 99MHz
cpu at mainbus0: not configured
cpu at mainbus0: not
configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 2 pa
0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped
to apid 2
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1
(P0P2)
acpiprt2 at acpi0: bus 5 (PEG1)
acpiprt3 at acpi0: bus 2
(RP01)
acpiprt4 at acpi0: bus -1 (RP02)
acpiprt5 at acpi0: bus 3
(RP03)
bios0: ROM list: 0xc/0xee00
memory map conflict
0xe00f8000/0x1000
memory map conflict 0xfed1c000/0x4000
memory map conflict
0xffed/0x3
pci0 at mainbus0 bus 0: configuration mode 1
(bios)
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
ppb0 at
pci0 dev 1 function 0 "Intel Core 2G PCIE" rev 0x09: apic 2 int 16
pci1 at
ppb0 bus 1
ppb1 at pci0 dev 1 function 1 "Intel Core 2G PCIE" rev 0x09:
apic 2 int 16
pci2 at ppb1 bus 5
ppb2 at pci2 dev 0 function 0 vendor
"Intel", unknown product 0x1513 rev 0x00
pci3 at ppb2 bus 6
ppb3 at pci3
dev 0 function 0 vendor "Intel", unknown product 0x1513 rev 0x00: apic 2
int 17
pci4 at ppb3 bus 7
vendor "Intel", unknown product 0x1513 (class
system subclass miscellaneous, rev 0x00) at pci4 dev 0 function 0 not
configured
ppb4 at pci3 dev 3 function 0 vendor "Intel", unknown product
0x1513 rev 0x00: apic 2 int 16
pci5 at ppb4 bus 8
ppb5 at pci3 dev 4
function 0 vendor "Intel", unknown product 0x1513 rev 0x00: apic 2 int
17
pci6 at ppb5 bus 9
ppb6 at pci3 dev 5 function 0 vendor "Intel", unknown
product 0x1513 rev 0x00: apic 2 int 18
pci7 at ppb6 bus 58
ppb7 at pci3 dev
6 function 0 vendor "Intel", unknown product 0x1513 rev 0x00: apic 2 int
19
pci8 at ppb7 bus 107
vga1 at pci0 dev 2 function 0 "Intel GT2+ Video"
rev 0x09
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
"Intel
6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
uhci0 at
pci0 dev 26 function 0 vendor "Intel", unknown product 0x1c2c rev 0x05:
apic 2 int 21
ehci0 at pci0 dev 26 function 7 "Intel 6 Series USB" rev
0x05: apic 2 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel
EHCI root hub" rev 2.00/1.00 addr 1
"Intel 6 Series HD Audio" rev 0x05 at
pci0 dev 27 function 0 not configured
ppb8 at pci0 dev 28 function 0 "Intel
6 Series PCIE" rev 0xb5: apic 2 int 16
pci9 at ppb8 bus 2
bge0 at pci9 dev
0 function 0 "Broadcom BCM57765" rev 0x10, unknown BCM57765 (0x57785100):
apic 2 int 16, address 3c:07:54:0c:6b:b7
ukphy0 at bge0 phy 1: Generic IEEE
802.3u media interface, rev. 4: OUI 0x00d897, model 0x0024
"Broadcom SD
Host Controller" rev 0x10 at pci9 dev 0 function 1 not configured
ppb9 at
pci0 dev 28 function 2 "Intel 6 Series PCIE" rev 0xb5: apic 2 int 18
pci10
at ppb9 bus 3
ppb10 at pci10 dev 0 function 0 vendor "TI", unknown product
0x823e rev 0x01
pci11 at ppb10 bus 4
vendor "TI", unknown product 0x823f
(class serial bus subclass Firewire, rev 0x01) at pci11 dev 0 function 0
not configured
uhci1 at pci0 dev 29 function 0 vendor "Intel", unknown
product 0x1c27 rev 0x05: apic 2 int 19
ehci1 at pci0 dev 29 function 7
"Intel 6 Series USB" rev 0x05: apic 2 int 22
usb1 at ehci1: USB revision
2.0
uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1
pcib0 at pci0
dev
Re: kernel panic (mii_phy_setmedia) on mac mini A1347 with trace and ps picture url
On Mon, Dec 19, 2011 at 04:10:16PM +0400, Wesley M. wrote: > > Here is the ps message : http://i43.tinypic.com/mkufyo.jpg > Here is the > trace message : http://i40.tinypic.com/25syfxf.jpg Have you tried to disable whatever it is on boot>? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: kernel panic (mii_phy_setmedia) on mac mini A1347 with trace and ps picture url
On Mon, 19 Dec 2011 10:33:56 -0200, Daniel Bolgheroni wrote: > On Mon, Dec 19, 2011 at 04:10:16PM +0400, Wesley M. wrote: >> >> Here is the ps message : http://i43.tinypic.com/mkufyo.jpg >> Here is the >> trace message : http://i40.tinypic.com/25syfxf.jpg > > Have you tried to disable whatever it is on boot>? i tried disable bge0, boot, i still have a kernel panic just after "Starting Network"
Re: kernel panic (mii_phy_setmedia) on mac mini A1347 with trace and ps picture url
On 2011/12/19 16:10, Wesley M. wrote:
> So i
> tried to use 5.0 RELEASE.
> This time, it formats quickly. But it is the same
> way : kernel panic when it starts the network.
>
> The following message
> appear :
> Starting network
> panic: mii_phy_setmedia
> Stopped at
> Debugger+0x4:popl %ebp
>
> a "show panic" at the ddb prompt:
> mii_phy_setmedia
You can try this patch. Apply, run 'cd /sys/dev/mii && make', then build
a new kernel. Obviously you will need to get the new kernel on to the
machine somehow; you can probably get it to boot with "boot -c",
"disable bge", "quit" - then you will need to either use a USB ethernet
device to get the source tree onto the machine, or copy a kernel built
on another machine via USB storage.
Index: brgphy.c
===
RCS file: /cvs/src/sys/dev/mii/brgphy.c,v
retrieving revision 1.93
diff -u -p -r1.93 brgphy.c
--- brgphy.c24 May 2010 21:23:23 - 1.93
+++ brgphy.c19 Dec 2011 12:43:02 -
@@ -174,6 +174,8 @@ static const struct mii_phydesc brgphys[
MII_STR_xxBROADCOM2_BCM5709S },
{ MII_OUI_xxBROADCOM2, MII_MODEL_xxBROADCOM2_BCM5709CAX,
MII_STR_xxBROADCOM2_BCM5709CAX },
+ { MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57765,
+ MII_STR_xxBROADCOM3_BCM57765 },
{ MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57780,
MII_STR_xxBROADCOM3_BCM57780 },
{ MII_OUI_BROADCOM2,MII_MODEL_BROADCOM2_BCM5906,
Index: miidevs
===
RCS file: /cvs/src/sys/dev/mii/miidevs,v
retrieving revision 1.116
diff -u -p -r1.116 miidevs
--- miidevs 21 Jan 2011 09:46:13 - 1.116
+++ miidevs 19 Dec 2011 12:43:02 -
@@ -159,6 +159,7 @@ model xxBROADCOM2 BCM5709C 0x003c BCM570
model xxBROADCOM2 BCM5761 0x003d BCM5761 10/100/1000baseT PHY
model xxBROADCOM2 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY
model xxBROADCOM3 BCM57780 0x0019 BCM57780 10/100/1000baseT PHY
+model xxBROADCOM3 BCM57765 0x0024 BCM57765 10/100/1000baseT PHY
model BROADCOM BCM5400 0x0004 BCM5400 1000baseT PHY
model BROADCOM BCM5401 0x0005 BCM5401 1000baseT PHY
model BROADCOM BCM5411 0x0007 BCM5411 1000baseT PHY
Actually I don't see any reason why not to commit this as-is.
It may not work but it's certainly not going to make things worse.
Any OKs for this?
> I can't note "trace" message, i have no serial port on the mac... :(
Yes you can, just re-type it from the text on-screen. But in this case
the ramdisk dmesg you included is enough.
Re: Automatic "fsck -y" at Boot
* Rudolf Leitgeb [2011-12-19 10:17]: > Am Freitag, 16. Dezember 2011, 21:49:18 schrieb Henning Brauer: > > in these cases - where "runs" is the top priority and manual > > intervention is hard - you most probably want to run with ro / and an > > mfs or three. > This is one nice approach but doesn't cover features like user changeable > settings and parameters, much less local error logs. gotta compromise for crippled systems. solvable with a little shell script run from cron and rc.shutdown. > > this is still a bit like "fixing" holey condoms with duct tape. > You fixed the holey condoms issue by replacing them with 5mm thick kevlar. > Your solution is certainly very l33t, but only few will want to use it ;) for the scenario i had in mind - servers in some data center - that is the one solution. > There are, however, countless situations where "fsck -y" or similar is the > most workable solution, and attacking people who use "fsck -y" after > careful consideration as irresponsible cheapskates is neither helpful nor > professional. I don't buy the "countless" at all, we're really only talking embedded here, and for embedded style use cases you'll have to adopt. that is the "special" case and not the norm. while i was mostly talking about a console and not fsck -y, i do believe that an automagic fsck -y is pretty damn stupid. > Of all the experts here: how many of you have ever intervened in a failed > "fsck -p" situation with anything else than an fsck and a barrage of "y" ? while we're really good in that and fsck almost always succeeds and fixes things up i have seen different. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: OpenBGPD not reporting blackhole as nexthop from bgpctl output
* Chris Wopat [2011-12-19 01:15]:
> Claudio and crew,
>
> Unsure if this is a bug or intended. I was testing BGP triggered
> blackholes, one of the routers that will perform the blackhole has
> this rule in its bgpd.conf:
>
> match from group GROUP-IBGP community 1234:666 set { localpref 200
> origin igp nexthop blackhole }
>
>
> Looking exclusively at the bgpctl output makes it appear to be not
> working (186.4.134.249 is a blocked source, 10.171.0.66 is the router
> triggering the blackhole, it should NOT be the nexthop):
>
> # bgpctl show ip bgp detail 186.4.134.249
>
> BGP routing table entry for 186.4.134.249/32
> Nexthop 10.171.0.66 (via 10.171.7.166) from rr1 (10.171.0.16)
> Origin IGP, metric 0, localpref 200, internal, valid, best
> Last update: 00:01:42 ago
> Communities: 1239:66 3356: 4150:666 NO_EXPORT
> Originator Id: 10.171.0.66
> Cluster ID List: 10.171.0.16
>
>
> When you look at the actual routing table though, it is blackholed and
> is functioning properly:
>
> # netstat -nr | grep 186.4.134.249
> 186.4.134.249/32 127.0.0.1 UGB0 14 3316048 lo0
>
>
> Is this intended behavior?
yes, it is.
I do admit indicating the blackhole nexthop in show rib would clear
things more up.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/
Re: kernel panic (mii_phy_setmedia) on mac mini A1347 with trace and ps picture url
Try this diff against -current. You'll have to apply
the patch from sys/dev/mii and run 'make' afterwards
to regenerate the headers.
Index: miidevs
===
RCS file: /cvs/src/sys/dev/mii/miidevs,v
retrieving revision 1.116
diff -u -p -r1.116 miidevs
--- miidevs 21 Jan 2011 09:46:13 - 1.116
+++ miidevs 19 Dec 2011 12:52:37 -
@@ -159,6 +159,7 @@ model xxBROADCOM2 BCM5709C 0x003c BCM570
model xxBROADCOM2 BCM5761 0x003d BCM5761 10/100/1000baseT PHY
model xxBROADCOM2 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY
model xxBROADCOM3 BCM57780 0x0019 BCM57780 10/100/1000baseT PHY
+model xxBROADCOM3 BCM57785 0x0024 BCM57785 10/100/1000baseT PHY
model BROADCOM BCM5400 0x0004 BCM5400 1000baseT PHY
model BROADCOM BCM5401 0x0005 BCM5401 1000baseT PHY
model BROADCOM BCM5411 0x0007 BCM5411 1000baseT PHY
Index: brgphy.c
===
RCS file: /cvs/src/sys/dev/mii/brgphy.c,v
retrieving revision 1.93
diff -u -p -r1.93 brgphy.c
--- brgphy.c24 May 2010 21:23:23 - 1.93
+++ brgphy.c19 Dec 2011 12:52:37 -
@@ -176,6 +176,8 @@ static const struct mii_phydesc brgphys[
MII_STR_xxBROADCOM2_BCM5709CAX },
{ MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57780,
MII_STR_xxBROADCOM3_BCM57780 },
+ { MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57785,
+ MII_STR_xxBROADCOM3_BCM57785 },
{ MII_OUI_BROADCOM2,MII_MODEL_BROADCOM2_BCM5906,
MII_STR_BROADCOM2_BCM5906 },
Re: kernel panic (mii_phy_setmedia) on mac mini A1347 with trace and ps picture url
Hi Stuart,
I tried this : boot -c at boot prompt (startup)
I have this message : "kbc cmd word write error" just after.
And i can't use keyboard at UKC Prompt :(
Wesley.
On Mon, 19 Dec 2011 12:51:58 +, Stuart Henderson
wrote:
> On 2011/12/19 16:10, Wesley M. wrote:
>> So i
>> tried to use 5.0 RELEASE.
>> This time, it formats quickly. But it is the same
>> way : kernel panic when it starts the network.
>>
>> The following message
>> appear :
>> Starting network
>> panic: mii_phy_setmedia
>> Stopped at
>> Debugger+0x4:popl %ebp
>>
>> a "show panic" at the ddb prompt:
>> mii_phy_setmedia
>
> You can try this patch. Apply, run 'cd /sys/dev/mii && make', then build
> a new kernel. Obviously you will need to get the new kernel on to the
> machine somehow; you can probably get it to boot with "boot -c",
> "disable bge", "quit" - then you will need to either use a USB ethernet
> device to get the source tree onto the machine, or copy a kernel built
> on another machine via USB storage.
>
> Index: brgphy.c
> ===
> RCS file: /cvs/src/sys/dev/mii/brgphy.c,v
> retrieving revision 1.93
> diff -u -p -r1.93 brgphy.c
> --- brgphy.c 24 May 2010 21:23:23 - 1.93
> +++ brgphy.c 19 Dec 2011 12:43:02 -
> @@ -174,6 +174,8 @@ static const struct mii_phydesc brgphys[
> MII_STR_xxBROADCOM2_BCM5709S },
> { MII_OUI_xxBROADCOM2, MII_MODEL_xxBROADCOM2_BCM5709CAX,
> MII_STR_xxBROADCOM2_BCM5709CAX },
> + { MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57765,
> + MII_STR_xxBROADCOM3_BCM57765 },
> { MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57780,
> MII_STR_xxBROADCOM3_BCM57780 },
> { MII_OUI_BROADCOM2,MII_MODEL_BROADCOM2_BCM5906,
> Index: miidevs
> ===
> RCS file: /cvs/src/sys/dev/mii/miidevs,v
> retrieving revision 1.116
> diff -u -p -r1.116 miidevs
> --- miidevs 21 Jan 2011 09:46:13 - 1.116
> +++ miidevs 19 Dec 2011 12:43:02 -
> @@ -159,6 +159,7 @@ model xxBROADCOM2 BCM5709C0x003c BCM570
> model xxBROADCOM2 BCM57610x003d BCM5761 10/100/1000baseT PHY
> model xxBROADCOM2 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY
> model xxBROADCOM3 BCM57780 0x0019 BCM57780 10/100/1000baseT PHY
> +model xxBROADCOM3 BCM57765 0x0024 BCM57765 10/100/1000baseT PHY
> model BROADCOM BCM5400 0x0004 BCM5400 1000baseT PHY
> model BROADCOM BCM5401 0x0005 BCM5401 1000baseT PHY
> model BROADCOM BCM5411 0x0007 BCM5411 1000baseT PHY
>
> Actually I don't see any reason why not to commit this as-is.
> It may not work but it's certainly not going to make things worse.
> Any OKs for this?
>
>> I can't note "trace" message, i have no serial port on the mac... :(
>
> Yes you can, just re-type it from the text on-screen. But in this case
> the ramdisk dmesg you included is enough.
Re: kernel panic (mii_phy_setmedia) on mac mini A1347 with trace and ps picture url
It's committed so wait for new snaps and you can avoid this step.
On 2011/12/19 17:10, Wesley M. wrote:
> Hi Stuart,
>
> I tried this : boot -c at boot prompt (startup)
> I have this message : "kbc cmd word write error" just after.
> And i can't use keyboard at UKC Prompt :(
>
> Wesley.
>
> On Mon, 19 Dec 2011 12:51:58 +, Stuart Henderson
> wrote:
> > On 2011/12/19 16:10, Wesley M. wrote:
> >> So i
> >> tried to use 5.0 RELEASE.
> >> This time, it formats quickly. But it is the same
> >> way : kernel panic when it starts the network.
> >>
> >> The following message
> >> appear :
> >> Starting network
> >> panic: mii_phy_setmedia
> >> Stopped at
> >> Debugger+0x4:popl %ebp
> >>
> >> a "show panic" at the ddb prompt:
> >> mii_phy_setmedia
> >
> > You can try this patch. Apply, run 'cd /sys/dev/mii && make', then build
> > a new kernel. Obviously you will need to get the new kernel on to the
> > machine somehow; you can probably get it to boot with "boot -c",
> > "disable bge", "quit" - then you will need to either use a USB ethernet
> > device to get the source tree onto the machine, or copy a kernel built
> > on another machine via USB storage.
> >
> > Index: brgphy.c
> > ===
> > RCS file: /cvs/src/sys/dev/mii/brgphy.c,v
> > retrieving revision 1.93
> > diff -u -p -r1.93 brgphy.c
> > --- brgphy.c24 May 2010 21:23:23 - 1.93
> > +++ brgphy.c19 Dec 2011 12:43:02 -
> > @@ -174,6 +174,8 @@ static const struct mii_phydesc brgphys[
> > MII_STR_xxBROADCOM2_BCM5709S },
> > { MII_OUI_xxBROADCOM2, MII_MODEL_xxBROADCOM2_BCM5709CAX,
> > MII_STR_xxBROADCOM2_BCM5709CAX },
> > + { MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57765,
> > + MII_STR_xxBROADCOM3_BCM57765 },
> > { MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57780,
> > MII_STR_xxBROADCOM3_BCM57780 },
> > { MII_OUI_BROADCOM2,MII_MODEL_BROADCOM2_BCM5906,
> > Index: miidevs
> > ===
> > RCS file: /cvs/src/sys/dev/mii/miidevs,v
> > retrieving revision 1.116
> > diff -u -p -r1.116 miidevs
> > --- miidevs 21 Jan 2011 09:46:13 - 1.116
> > +++ miidevs 19 Dec 2011 12:43:02 -
> > @@ -159,6 +159,7 @@ model xxBROADCOM2 BCM5709C 0x003c BCM570
> > model xxBROADCOM2 BCM5761 0x003d BCM5761 10/100/1000baseT PHY
> > model xxBROADCOM2 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY
> > model xxBROADCOM3 BCM57780 0x0019 BCM57780 10/100/1000baseT PHY
> > +model xxBROADCOM3 BCM57765 0x0024 BCM57765 10/100/1000baseT PHY
> > model BROADCOM BCM5400 0x0004 BCM5400 1000baseT PHY
> > model BROADCOM BCM5401 0x0005 BCM5401 1000baseT PHY
> > model BROADCOM BCM5411 0x0007 BCM5411 1000baseT PHY
> >
> > Actually I don't see any reason why not to commit this as-is.
> > It may not work but it's certainly not going to make things worse.
> > Any OKs for this?
> >
> >> I can't note "trace" message, i have no serial port on the mac... :(
> >
> > Yes you can, just re-type it from the text on-screen. But in this case
> > the ramdisk dmesg you included is enough.
Re: Automatic "fsck -y" at Boot
On Mon, 19 Dec 2011 13:52:40 +0100 Henning Brauer wrote: > while we're really good in that and fsck almost always succeeds and > fixes things up i have seen different. Same here, though I have to admit when there are lots to go through, I can't rememeber not doing an fsck -y. Usually the datas not that important and you can fix it up after (put the odd email back if needed etc..) Sync mounts should increase your chances too.
Re: Automatic "fsck -y" at Boot
Am Montag, 19. Dezember 2011, 13:52:40 schrieb Henning Brauer: > gotta compromise for crippled systems. solvable with a little shell > script run from cron and rc.shutdown. Wait: your solution would be to periodically remount some volume read/write, merge the changes and then drop back to ro ? You aren't serious, are you? > for the scenario i had in mind - servers in some data center - that is > the one solution. Agreed. Many posts ago, BTW, so why do you still bring it up? I specifically differentiated between devices that "store" and devices that "do". Data center servers which have baby sitters in an office nearby don't need automagic thingies. > I don't buy the "countless" at all, we're really only talking embedded > here, and for embedded style use cases you'll have to adopt. that is > the "special" case and not the norm. Embedded systems with configurable settings are a "special case"? Where were you during the last 10 years? > while i was mostly talking about a console and not fsck -y, i do > believe that an automagic fsck -y is pretty damn stupid. Guess what your home router does, and what (if you have one) your cell phone does? Also your car and your TV set? None of these drop you into a console after the 3rd power outage and people would laugh you out the door if you tried to sell such a product. > while we're really good in that and fsck almost always succeeds and > fixes things up i have seen different. And most likely the problems were not caused by fsck but by faulty hardware creating the mess to begin with. No serial console can fix faulty RAM chips, itchy power supplies or loose SATA cables, so it wouldn't help the proud owner of a "do" device one bit. As I have written before: I don't care whether the default install of OBSD comes with "fsck -p" or "fsck -y", but calling people who suggest "fsck -y" in certain situations cheapskates and stupid shows blatant ignorance.
Re: OpenSSH 6.0-beta testing issue
On Sun, Dec 18, 2011 at 22:47, Bryan wrote: > This is happening on OpenSSH for OpenBSD. > > LIttle backstory... > > I have an Motorola Droid that I use SSHDroidPro to connect to it from > various PCs (windows and OpenBSD) to transfer files. B I upgraded to > the Galaxy Nexus, and found that once I installed SSHDroidPro on it, I > could no longer connect. B I bought QuickSSHd, thinking that there was > some issue with the old application, but could still not connect.. > > I have traced the issue back to sometime between November 20th, and > December 16th. B How do I know that? B I had a VM from November 20th > that I could SSH from to my new phone, but on my laptop, running a > -current from December 16th fails. > > > And here is the output from the December 16th snapshot on my laptop: > > > $ ssh -vvv 192.168.1.46 > OpenSSH_6.0-beta, OpenSSL 1.0.0e 6 Sep 2011 > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 192.168.1.46 [192.168.1.46] port 22. > > *sticks for about 45 seconds* > > debug1: connect to address 192.168.1.46 port 22: Connection timed out > ssh: connect to host 192.168.1.46 port 22: Connection timed out > > And that it... B I can connect to the phone with PuTTY on a Windows > machine with no issues... > > But here's the kicker... I booted up my old Droid, just to use the > Wifi connection (plan on using it as a SIP), and used the December > 16th snapshot to try and SSH, and it connects to the DROID just fine. > I have changed the passwords from easy to more than 20 characters. B I > can ping the box, and the nmap scan B that I use on Windows shows that > port 22 is open (I can provide that if you need me to), but nothing I > can do will get it to connect to the Galaxy Nexus on my laptop... B I > wondered if there is something in the new 'Ice Cream Sandwich' Android > 4.0... > > I have contacted the developers of SSHDroidPro, and QuickSSHd to ask > them if they have had any issues, but I have not heard anything > back... There have been 4 changes made to OpenSSH between November 20th and December 16th. http://www.freshbsd.org/search?project=openbsd&q=ssh DroidSSHPro and QuickSSHd both utilize the Dropbear implementation of SSH, which looks like the guy took pieces from here and there, and cobbled together something, which might be why it isn't working. I am willing to test patches, if anyone wants to toss something over the fence... since I appear to be the only one having an issue. If you have a Galaxy Nexus, and use one of those apps to SSH, please give it a try with a later snapshot...
Re: kernel panic (mii_phy_setmedia) on mac mini A1347 with trace and ps picture url
Ok, thank's.
Therefore, i have a problem. I use mailserv project, and it works only on
4.8; 4.9 RELEASE. Not on 5.0
Is there a way for me to have a 4.9 with patches ?
In short, is it possible to have a patch to use with 4.9-stable ?
Thank you very much.
Wesley.
On Mon, 19 Dec 2011 13:21:20 +, Stuart Henderson
wrote:
> It's committed so wait for new snaps and you can avoid this step.
>
>
> On 2011/12/19 17:10, Wesley M. wrote:
>> Hi Stuart,
>>
>> I tried this : boot -c at boot prompt (startup)
>> I have this message : "kbc cmd word write error" just after.
>> And i can't use keyboard at UKC Prompt :(
>>
>> Wesley.
>>
>> On Mon, 19 Dec 2011 12:51:58 +, Stuart Henderson
>>
>> wrote:
>> > On 2011/12/19 16:10, Wesley M. wrote:
>> >> So i
>> >> tried to use 5.0 RELEASE.
>> >> This time, it formats quickly. But it is the same
>> >> way : kernel panic when it starts the network.
>> >>
>> >> The following message
>> >> appear :
>> >> Starting network
>> >> panic: mii_phy_setmedia
>> >> Stopped at
>> >> Debugger+0x4:popl %ebp
>> >>
>> >> a "show panic" at the ddb prompt:
>> >> mii_phy_setmedia
>> >
>> > You can try this patch. Apply, run 'cd /sys/dev/mii && make', then
>> > build
>> > a new kernel. Obviously you will need to get the new kernel on to the
>> > machine somehow; you can probably get it to boot with "boot -c",
>> > "disable bge", "quit" - then you will need to either use a USB
ethernet
>> > device to get the source tree onto the machine, or copy a kernel
built
>> > on another machine via USB storage.
>> >
>> > Index: brgphy.c
>> > ===
>> > RCS file: /cvs/src/sys/dev/mii/brgphy.c,v
>> > retrieving revision 1.93
>> > diff -u -p -r1.93 brgphy.c
>> > --- brgphy.c 24 May 2010 21:23:23 - 1.93
>> > +++ brgphy.c 19 Dec 2011 12:43:02 -
>> > @@ -174,6 +174,8 @@ static const struct mii_phydesc brgphys[
>> > MII_STR_xxBROADCOM2_BCM5709S },
>> >{ MII_OUI_xxBROADCOM2, MII_MODEL_xxBROADCOM2_BCM5709CAX,
>> > MII_STR_xxBROADCOM2_BCM5709CAX },
>> > + { MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57765,
>> > +MII_STR_xxBROADCOM3_BCM57765 },
>> >{ MII_OUI_xxBROADCOM3, MII_MODEL_xxBROADCOM3_BCM57780,
>> > MII_STR_xxBROADCOM3_BCM57780 },
>> >{ MII_OUI_BROADCOM2,MII_MODEL_BROADCOM2_BCM5906,
>> > Index: miidevs
>> > ===
>> > RCS file: /cvs/src/sys/dev/mii/miidevs,v
>> > retrieving revision 1.116
>> > diff -u -p -r1.116 miidevs
>> > --- miidevs21 Jan 2011 09:46:13 - 1.116
>> > +++ miidevs19 Dec 2011 12:43:02 -
>> > @@ -159,6 +159,7 @@ model xxBROADCOM2 BCM5709C 0x003c BCM570
>> > model xxBROADCOM2 BCM5761 0x003d BCM5761 10/100/1000baseT PHY
>> > model xxBROADCOM2 BCM5709S0x003f BCM5709S 1000/2500baseSX PHY
>> > model xxBROADCOM3 BCM577800x0019 BCM57780 10/100/1000baseT PHY
>> > +model xxBROADCOM3 BCM577650x0024 BCM57765 10/100/1000baseT PHY
>> > model BROADCOM BCM54000x0004 BCM5400 1000baseT PHY
>> > model BROADCOM BCM54010x0005 BCM5401 1000baseT PHY
>> > model BROADCOM BCM54110x0007 BCM5411 1000baseT PHY
>> >
>> > Actually I don't see any reason why not to commit this as-is.
>> > It may not work but it's certainly not going to make things worse.
>> > Any OKs for this?
>> >
>> >> I can't note "trace" message, i have no serial port on the mac... :(
>> >
>> > Yes you can, just re-type it from the text on-screen. But in this
case
>> > the ramdisk dmesg you included is enough.
Re: kernel panic (mii_phy_setmedia) on mac mini A1347 with trace and ps picture url
On 2011/12/19 17:43, Wesley M. wrote: > Ok, thank's. > Therefore, i have a problem. I use mailserv project, and it works only on > 4.8; 4.9 RELEASE. Not on 5.0 > Is there a way for me to have a 4.9 with patches ? > In short, is it possible to have a patch to use with 4.9-stable ? > > Thank you very much. The maximum extent I will use -stable is occasionally to backport important bug fixes from -current to -stable from the last release. (And I don't have enough space for VMs to do this at the moment either). A diff adding this to 4.9 is certainly possible but I won't be providing it..
Re: Automatic "fsck -y" at Boot
On Mon, 19 Dec 2011 14:39:42 +0100 Rudolf Leitgeb wrote: > Guess what your home router does, and what (if you have one) > your cell phone does? It loses unimportant data. Hennings points stand. One of the beauties of OpenBSD is it's init which is easy to follow and edit. To give such a feature to someone that can't mod /etc/rc would be potentially causing them and people on the mailing list grief. To edit /etc/rc someone would think first especially as they will have to remerge the diff on upgrades later but to twist a knob in a config file, often they don't.
Re: Automatic "fsck -y" at Boot
* Rudolf Leitgeb [2011-12-19 14:40]: > Am Montag, 19. Dezember 2011, 13:52:40 schrieb Henning Brauer: > > gotta compromise for crippled systems. solvable with a little shell > > script run from cron and rc.shutdown. > Wait: your solution would be to periodically remount some volume > read/write, merge the changes and then drop back to ro ? You aren't > serious, are you? sure I am. that is how many if not most of these devices work - giant ramdisk, config data is written back to permanent storage on request or scheduled. ever wondered why you need to do a "write config" on your switch? > > for the scenario i had in mind - servers in some data center - that is > > the one solution. > Agreed. Many posts ago, BTW, so why do you still bring it up? I specifically > differentiated between devices that "store" and devices that "do". not in the statements i responded to. > Data center servers which have baby sitters in an office nearby don't > need automagic thingies. you apparently don't have much experience with that... > > I don't buy the "countless" at all, we're really only talking embedded > > here, and for embedded style use cases you'll have to adopt. that is > > the "special" case and not the norm. > Embedded systems with configurable settings are a "special case"? > Where were you during the last 10 years? you might have missed that openbsd isn't primarily targeted as embedded OS... > > while i was mostly talking about a console and not fsck -y, i do > > believe that an automagic fsck -y is pretty damn stupid. > Guess what your home router does, I don't need to guess. I know. It doesn't do fsck -y. > and what (if you have one) > your cell phone does? Also your car and your TV set? None of these > drop you into a console after the 3rd power outage and people > would laugh you out the door if you tried to sell such a product. what is your point again? openbsd is not an embedded out of the box product, and if you want to use it as such, you gotta adjust yourself. > > while we're really good in that and fsck almost always succeeds and > > fixes things up i have seen different. > And most likely the problems were not caused by fsck but by faulty > hardware creating the mess to begin with. No serial console can fix > faulty RAM chips, itchy power supplies or loose SATA cables, so it > wouldn't help the proud owner of a "do" device one bit. I honestly don't remember wether I ever had a case where fsck -y did not succeed but the hardware was fine. i dunno. but you are so focussed on fsck, not me. there are a gazilion things that can go wrong that require console access. and yes, the majority of them is a fuckup by a human. > As I have written before: I don't care whether the default install of OBSD > comes with "fsck -p" or "fsck -y", but calling people who suggest "fsck -y" > in certain situations cheapskates and stupid shows blatant ignorance. i see an interesting pattern here. 1) pick a seemingly simple "solution" 2) getting told that there are better ones, but you prefer to ignore that, since you've already chosen 1) and cannot possibly have been wrong. automagic fsck -y is stupid. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Automatic "fsck -y" at Boot
On 19 December 2011 11:39, Rudolf Leitgeb wrote: > Am Montag, 19. Dezember 2011, 13:52:40 schrieb Henning Brauer: >> gotta compromise for crippled systems. solvable with a little shell >> script run from cron and rc.shutdown. > > Wait: your solution would be to periodically remount some volume > read/write, merge the changes and then drop back to ro ? You aren't > serious, are you? > This is *exactly* what these devices do (I'm not guessing). You don't want a cheap NAND flash with JFS2 mounted rw. >> for the scenario i had in mind - servers in some data center - that is >> the one solution. > > Agreed. Many posts ago, BTW, so why do you still bring it up? I specifically > differentiated between devices that "store" and devices that "do". > Data center servers which have baby sitters in an office nearby don't > need automagic thingies. > >> I don't buy the "countless" at all, we're really only talking embedded >> here, and for embedded style use cases you'll have to adopt. that is >> the "special" case and not the norm. > > Embedded systems with configurable settings are a "special case"? > Where were you during the last 10 years? > >> while i was mostly talking about a console and not fsck -y, i do >> believe that an automagic fsck -y is pretty damn stupid. > > Guess what your home router does, and what (if you have one) > your cell phone does? Also your car and your TV set? None of these > drop you into a console after the 3rd power outage and people > would laugh you out the door if you tried to sell such a product. > >> while we're really good in that and fsck almost always succeeds and >> fixes things up i have seen different. > > And most likely the problems were not caused by fsck but by faulty > hardware creating the mess to begin with. No serial console can fix > faulty RAM chips, itchy power supplies or loose SATA cables, so it > wouldn't help the proud owner of a "do" device one bit. > > As I have written before: I don't care whether the default install of OBSD > comes with "fsck -p" or "fsck -y", but calling people who suggest "fsck -y" > in certain situations cheapskates and stupid shows blatant ignorance.
Re: OpenSSH 6.0-beta testing issue
On 2011-12-19, Bryan wrote: > This is happening on OpenSSH for OpenBSD. > > LIttle backstory... > > I have an Motorola Droid that I use SSHDroidPro to connect to it from > various PCs (windows and OpenBSD) to transfer files. I upgraded to > the Galaxy Nexus, and found that once I installed SSHDroidPro on it, I > could no longer connect. I bought QuickSSHd, thinking that there was > some issue with the old application, but could still not connect.. > > I have traced the issue back to sometime between November 20th, and > December 16th. How do I know that? I had a VM from November 20th > that I could SSH from to my new phone, but on my laptop, running a > -current from December 16th fails. I find it hard to believe that this... > $ ssh -vvv 192.168.1.46 > OpenSSH_6.0-beta, OpenSSL 1.0.0e 6 Sep 2011 > debug1: Reading configuration data /etc/ssh/ssh_config > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 192.168.1.46 [192.168.1.46] port 22. > > *sticks for about 45 seconds* ...would have anything to do with the version of OpenSSH, it just looks like the TCP connection is failing (firewall? something else? consider what things might be different between the VM and your laptop). What happens if you "telnet 192.168.1.46 22"?
Re: Automatic "fsck -y" at Boot
On 2011-12-19, Rudolf Leitgeb wrote: > Am Montag, 19. Dezember 2011, 13:52:40 schrieb Henning Brauer: >> gotta compromise for crippled systems. solvable with a little shell >> script run from cron and rc.shutdown. > > Wait: your solution would be to periodically remount some volume > read/write, merge the changes and then drop back to ro ? You aren't > serious, are you? mount -uw /, edit edit edit, mount -ur /. I do this all sorts of places, have done for 10+ years, it works well. I still setup serial console wherever I can possibly get it though - if I have a crashing kernel I want to be able to reach ddb. If I break routing/IP addressing or miss a necessary syntax change, I want to be able to fix it. >> I don't buy the "countless" at all, we're really only talking embedded >> here, and for embedded style use cases you'll have to adopt. that is >> the "special" case and not the norm. > > Embedded systems with configurable settings are a "special case"? > Where were you during the last 10 years? Embedded is a special case for a general-purpose OS. How many manufacturers of these devices would even consider using standard system startup scripts?
Upgrading AMD64 4.9-stable to 5.0
Hi Misc@, I'm planning to upgrade an 4.9 AMD64-stable to 5.0. I've read FAQ Upgrade Guide, and I think there are no potential PITA. But I'd love to hear from others who has experience upgrading 4.9-stable to 5.0 AMD64. The server is a; OpenBSD 4.9-stable (kernel-amd64) #1: Sun May 22 05:08:40 WIT 2011 ad...@server.xyz.com:/kernel-amd64 real mem = 3486973952 (3325MB) avail mem = 3380129792 (3223MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xcfedf000 (39 entries) bios0: vendor Phoenix Technologies LTD version "1.3a" date 11/03/2009 bios0: Supermicro X7SBi acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP _MAR MCFG APIC BOOT SPCR ERST HEST BERT EINJ SLIC SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT acpi0: wakeup devices PXHA(S5) PEX_(S5) LAN_(S5) USB4(S5) USB5(S5) USB7(S5) ESB2(S5) EXP1(S5) EXP5(S5) EXP6(S5) USB1(S5) USB2(S5) USB3(S5) USB6(S5) ESB1(S5) PCIB(S5) KBC0(S1) MSE0(S1) COM1(S5) COM2(S5) PWRB(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-16 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU X3330 @ 2.66GHz, 2667.23 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,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG cpu0: 3MB 64b/line 8-way L2 cache cpu0: apic clock running at 333MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Xeon(R) CPU X3330 @ 2.66GHz, 2666.85 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,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG cpu1: 3MB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Xeon(R) CPU X3330 @ 2.66GHz, 2666.86 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,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG cpu2: 3MB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Xeon(R) CPU X3330 @ 2.66GHz, 2666.85 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,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE,NXE,LONG cpu3: 3MB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 5 pa 0xfecc, version 20, 24 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 2 (PXHA) acpiprt2 at acpi0: bus -1 (PEX_) acpiprt3 at acpi0: bus 5 (EXP1) acpiprt4 at acpi0: bus 13 (EXP5) acpiprt5 at acpi0: bus 15 (EXP6) acpiprt6 at acpi0: bus 17 (PCIB) acpicpu0 at acpi0: C3, PSS acpicpu1 at acpi0: C3, PSS acpicpu2 at acpi0: C3, PSS acpicpu3 at acpi0: C3, PSS acpibtn0 at acpi0: PWRB acpivideo0 at acpi0: IGD0 ipmi at mainbus0 not configured cpu0: Enhanced SpeedStep 2666 MHz: speeds: 2667, 2333, 2000 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 3200/3210 Host" rev 0x01 ppb0 at pci0 dev 1 function 0 "Intel 3200/3210 PCIE" rev 0x01: apic 4 int 16 (irq 5) pci1 at ppb0 bus 1 ppb1 at pci1 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09 pci2 at ppb1 bus 2 "Intel IOxAPIC" rev 0x09 at pci1 dev 0 function 1 not configured uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 16 (irq 5) uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 17 (irq 10) uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 4 int 18 (irq 11) ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 4 int 18 (irq 11) usb0 at ehci0: USB revision 2.0 uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb2 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: apic 4 int 16 (irq 5) pci3 at ppb2 bus 5 ppb3 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: apic 4 int 16 (irq 5) pci4 at ppb3 bus 13 em0 at pci4 dev 0 function 0 "Intel PRO/1000MT (82573E)" rev 0x03: apic 4 int 16 (irq 5), address 00:30:48:f8:cb:7a ppb4 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: apic 4 int 17 (irq 10) pci5 at ppb4 bus 15 em1 at pci5 dev 0 function 0 "Intel PRO/1000MT (82573L)" rev 0x00: apic 4 int 17 (irq 10), address 00:30:48:f8:cb:7b uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 23 (irq 10) uhci4 at pci0 dev 29 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 22 (irq 11) uhci5 at pci0 dev 29 function 2 "Intel 82801I USB" rev 0x02: apic 4 int 18 (irq 11) ehci1 at pci0 dev 29 function 7 "Intel 82801I USB" rev 0x02: apic 4 int 23 (irq 10) usb1 at ehci1: USB revision 2.0 uhub1 at usb1 "Intel EHCI root hub" rev 2.00/1.00 addr 1 ppb5 at pci0 dev 30 function 0 "Intel 82801BA Hub-to-PCI" rev 0x92 pci6 at ppb5 bus 17 vga1 at pci6 dev 3 function 0 "A
strange tcp rst with rdomain
Hello. I'm running multihomed OpenBSD server: vlan5/carp5 - default vlan2/carp2 and vlan4/carp4 are connected to other ISPs. when there's no rdomain thing, everything seems to be working, except all outgoing packets goes through vlan5/carp5. so, I did f2n0:/root#cat /etc/hostname.vlan2 vlan 2 vlandev trunk0 mtu 1300 up f2n0:/root#cat /etc/hostname.carp2 vhid 62 pass m1pass carpdev vlan2 X.X.X.X/26 rdomain 2 !/sbin/route -T 2 add 0.0.0.0/0 X.X.X.Z f2n0:/root#cat /etc/hostname.vlan4 vlan 4 vlandev trunk0 mtu 1300 up f2n0:/root#cat /etc/hostname.carp4 vhid 64 pass m1pass carpdev vlan4 Y.Y.Y.Y/26 rdomain 4 !/sbin/route -T 4 add 0.0.0.0/0 Y.Y.Y.Z f2n0:/root# also, I did f2n0:/root#grep -v ^# /etc/pf.conf set skip on lo pass in vlan2 rtable 2 pass in vlan4 rtable 4 pass "ping"is working good, packets go out via appropriate interface. however, ssh ends with "tcp rst", for example. how can the reason for that "tcp rst" might be detected? am I doing anything wrong with rdomains? Ilya Shipitsin
Re: Upgrading AMD64 4.9-stable to 5.0
I upgraded my sun blade 100 from 4.9 to 5.0; no issues but, it appears that the packages in 4.9 are not always upgradeable to those in 5.0 and most packages in 5.0 fail to install due to library dependencies. one would assume all 5.0 packages are created using the dev tools from 5.0 but this does not seem to be true. I do not have time to track down all these issues, so for me openbsd will always remain a fun toy, but no better. On Mon, Dec 19, 2011 at 12:52 PM, Insan Praja SW wrote: > Hi Misc@, > > I'm planning to upgrade an 4.9 AMD64-stable to 5.0. I've read FAQ Upgrade > Guide, and I think there are no potential PITA. But I'd love to hear from > others who has experience upgrading 4.9-stable to 5.0 AMD64. > > The server is a; > > OpenBSD 4.9-stable (kernel-amd64) #1: Sun May 22 05:08:40 WIT 2011 >ad...@server.xyz.com:/kernel-**amd64 > real mem = 3486973952 (3325MB) > avail mem = 3380129792 (3223MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xcfedf000 (39 entries) > bios0: vendor Phoenix Technologies LTD version "1.3a" date 11/03/2009 > bios0: Supermicro X7SBi > acpi0 at bios0: rev 2 > acpi0: sleep states S0 S1 S4 S5 > acpi0: tables DSDT FACP _MAR MCFG APIC BOOT SPCR ERST HEST BERT EINJ SLIC > SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT > acpi0: wakeup devices PXHA(S5) PEX_(S5) LAN_(S5) USB4(S5) USB5(S5) > USB7(S5) ESB2(S5) EXP1(S5) EXP5(S5) EXP6(S5) USB1(S5) USB2(S5) USB3(S5) > USB6(S5) ESB1(S5) PCIB(S5) KBC0(S1) MSE0(S1) COM1(S5) COM2(S5) PWRB(S3) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimcfg0 at acpi0 addr 0xe000, bus 0-16 > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU X3330 @ 2.66GHz, 2667.23 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,VMX,SMX,**EST,TM2,SSSE3,CX16,xTPR,PDCM,** > SSE4.1,XSAVE,NXE,LONG > cpu0: 3MB 64b/line 8-way L2 cache > cpu0: apic clock running at 333MHz > cpu1 at mainbus0: apid 1 (application processor) > cpu1: Intel(R) Xeon(R) CPU X3330 @ 2.66GHz, 2666.85 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,VMX,SMX,**EST,TM2,SSSE3,CX16,xTPR,PDCM,** > SSE4.1,XSAVE,NXE,LONG > cpu1: 3MB 64b/line 8-way L2 cache > cpu2 at mainbus0: apid 2 (application processor) > cpu2: Intel(R) Xeon(R) CPU X3330 @ 2.66GHz, 2666.86 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,VMX,SMX,**EST,TM2,SSSE3,CX16,xTPR,PDCM,** > SSE4.1,XSAVE,NXE,LONG > cpu2: 3MB 64b/line 8-way L2 cache > cpu3 at mainbus0: apid 3 (application processor) > cpu3: Intel(R) Xeon(R) CPU X3330 @ 2.66GHz, 2666.85 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,VMX,SMX,**EST,TM2,SSSE3,CX16,xTPR,PDCM,** > SSE4.1,XSAVE,NXE,LONG > cpu3: 3MB 64b/line 8-way L2 cache > ioapic0 at mainbus0: apid 4 pa 0xfec0, version 20, 24 pins > ioapic1 at mainbus0: apid 5 pa 0xfecc, version 20, 24 pins > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus 2 (PXHA) > acpiprt2 at acpi0: bus -1 (PEX_) > acpiprt3 at acpi0: bus 5 (EXP1) > acpiprt4 at acpi0: bus 13 (EXP5) > acpiprt5 at acpi0: bus 15 (EXP6) > acpiprt6 at acpi0: bus 17 (PCIB) > acpicpu0 at acpi0: C3, PSS > acpicpu1 at acpi0: C3, PSS > acpicpu2 at acpi0: C3, PSS > acpicpu3 at acpi0: C3, PSS > acpibtn0 at acpi0: PWRB > acpivideo0 at acpi0: IGD0 > ipmi at mainbus0 not configured > cpu0: Enhanced SpeedStep 2666 MHz: speeds: 2667, 2333, 2000 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 3200/3210 Host" rev 0x01 > ppb0 at pci0 dev 1 function 0 "Intel 3200/3210 PCIE" rev 0x01: apic 4 int > 16 (irq 5) > pci1 at ppb0 bus 1 > ppb1 at pci1 dev 0 function 0 "Intel PCIE-PCIE" rev 0x09 > pci2 at ppb1 bus 2 > "Intel IOxAPIC" rev 0x09 at pci1 dev 0 function 1 not configured > uhci0 at pci0 dev 26 function 0 "Intel 82801I USB" rev 0x02: apic 4 int 16 > (irq 5) > uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 4 int 17 > (irq 10) > uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 4 int 18 > (irq 11) > ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 4 int 18 > (irq 11) > usb0 at ehci0: USB revision 2.0 > uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 > ppb2 at pci0 dev 28 function 0 "Intel 82801I PCIE" rev 0x02: apic 4 int 16 > (irq 5) > pci3 at ppb2 bus 5 > ppb3 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: apic 4 int 16 > (irq 5) > pci4 at ppb3 bus 13 > em0 at pci4 dev 0 function 0 "Intel PRO/1000MT (82573E)" rev 0x03: apic 4 > int 16 (irq 5), address 00:30:48:f8:cb:7a > ppb4 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: apic 4 int 17
Re: Upgrading AMD64 4.9-stable to 5.0
On Mon, Dec 19, 2011 at 01:02:59PM -0500, Richard Thornton wrote: > it appears > that the packages in 4.9 are not always upgradeable to those in 5.0 and > most packages in 5.0 fail to install due to library dependencies. What? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Upgrading AMD64 4.9-stable to 5.0
Do a simple clean 5.0 install. One would assume any browser package in the packages folder would install. None do for me on sparc, but with a clean 4.9 install all 4.9 packages install. I am not a Unix specialist by any means but I do know how to type pkg_add . On Dec 19, 2011 1:15 PM, "Daniel Bolgheroni" wrote: > On Mon, Dec 19, 2011 at 01:02:59PM -0500, Richard Thornton wrote: > > it appears > > that the packages in 4.9 are not always upgradeable to those in 5.0 and > > most packages in 5.0 fail to install due to library dependencies. > > What? > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean.
Re: Upgrading AMD64 4.9-stable to 5.0
On 19 December 2011 16:02, Richard Thornton wrote: > I upgraded my sun blade 100 from 4.9 to 5.0; no issues but, it appears > that the packages in 4.9 are not always upgradeable to those in 5.0 and > most packages in 5.0 fail to install due to library dependencies. one > would assume all 5.0 packages are created using the dev tools from 5.0 but > this does not seem to be true. I do not have time to track down all these > issues, so for me openbsd will always remain a fun toy, but no better. > Richard: sun blade 100 is a sparc64 system, he was specifically asking for amd64. You clearly have no idea what you're doing, and instead of learning you go to public bashing, no one is forcing you to do anything, and we've provided excellent documentation about the upgrade process. What amazes me is that upgrading is one of best things about OpenBSD, devs put a lot of effort into doing it right, and yet there are types like who come and say whatever crap they feel like to. I've started using OpenBSD in 4.2 and been upgrading since them. I *never* had an issue. There are a lot of people out there doing since much much much older releases. Insan: As for the original question, no, you should have no problems. We all run a bunch of amd64 machines and upgrade it constantly, if not daily. Please report back if you have any troubles.
Re: Upgrading AMD64 4.9-stable to 5.0
On 19 December 2011 16:20, Richard Thornton wrote: > Do a simple clean 5.0 install. One would assume any browser package in the > packages folder would install. None do for me on sparc, but with a clean > 4.9 install all 4.9 packages install. I am not a Unix specialist by any > means but I do know how to type pkg_add . So stop spreading lies and read the documentation before taxing things as "toy".
Re: Upgrading AMD64 4.9-stable to 5.0
Richard Thornton writes: > I upgraded my sun blade 100 from 4.9 to 5.0; no issues but, it appears > that the packages in 4.9 are not always upgradeable to those in 5.0 and > most packages in 5.0 fail to install due to library dependencies. This sounds suspicously like you're mixing base and packages releases in some sort of unsupported combination. A wild guess -- trying to upgrade the packages not to 5.0, but rather packages matching a snapshot, perhaps? > one would assume all 5.0 packages are created using the dev tools from > 5.0 but this does not seem to be true. Once again, do not attempt to install packages built on and intende for -current on a system running -stable. > I do not have time to track down all these issues, so for me openbsd > will always remain a fun toy, but no better. Please go back and check what you did leading up to those errors. This sounds like the result of some fairly basic mistake, like trying to install -current packages on -stable. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
PF / Relayd Configuration for NFS failover
The current environment I'm working on is all virtual using VMWare Player 4.0.1. I'm attempting to simulate a highly available NFS frontend to multiple GlusterFS backend servers. The gluster servers are both Ubuntu 10.10 running GlusterFS 3.2.5. I've configured the NFS share for a test volume to use 32-bit inodes and port 5000. The production environment that I'm testing this for is all FreeBSD, so I can't use the gluster client. I have an OpenBSD 5.0 VM designated as the gluster load balancer. I would like to eventually use multiple OpenBSD servers running relayd/CARP/PFSync/PF for failover and load balancing, but am just messing with the basics for now. I jumped right in with attempting relayd, however I had issues with it crashing on UDP redirects and the race condition on ruleset changes. Currently, I'm just trying to get a PF ruleset working as a layer 3 proxy and will use relayd in the future once those issues are resolved. Here is my current ruleset (which isn't working): iface="vic0" my_ip="192.168.44.130" gluster_ip="192.168.44.128" set skip on lo pass on $iface pass in on $iface proto udp from any to $my_ip port 111 rdr-to $gluster_ip port 111 nat-to $my_ip pass in on $iface proto tcp from any to $my_ip port 5000 rdr-to $gluster_ip port 5000 nat-to $my_ip I have a FreeBSD 8.2 client in a VM using the command "mount -t nfs -o tcp,port=5000 192.168.44.130:/test /mnt" that keeps timing out. If i modify that IP to the gluster IP (192.168.44.128) it works and I can also mount directly from the OpenBSD server. I've included a line in the ruleset for UDP port 111 because I wasn't sure if portmap was causing problems. When analyzing tcpdump files in Wireshark, all I see are SYN packets from client to load balancer. I'm not actually seeing any packets traveling outbound that would indicate that the redirect/nat translation is even happening even though "pfctl -v -s rules" shows that the very last rule has matched packets. I would really appreciate any help on this and possibly any issues/resolutions I may run into when migrating to relayd (minus the ones I've already listed). Thanks, Joe
Re: Upgrading AMD64 4.9-stable to 5.0
On 2011-12-19, Richard Thornton wrote: > Do a simple clean 5.0 install. One would assume any browser package in the > packages folder would install. None do for me on sparc, but with a clean > 4.9 install all 4.9 packages install. I am not a Unix specialist by any > means but I do know how to type pkg_add . Please send a mail to ports@ detailing exactly what you are doing (what you're typing, what PKG_PATH is set to if you're using it, the contents of /etc/pkg.conf if you're using that) and what output you see. This is the first I've heard of any major problem with 5.0 release packages on any arch, if there is a problem obviously we need to know what went wrong so we can avoid it happening in future, but before digging into that we need to first rule out incorrect procedure.
Re: Upgrading AMD64 4.9-stable to 5.0
On Mon, 19 Dec 2011, Christiano F. Haesbaert wrote: On 19 December 2011 16:20, Richard Thornton wrote: Do a simple clean 5.0 install. One would assume any browser package in the packages folder would install. None do for me on sparc, but with a clean 4.9 install all 4.9 packages install. I am not a Unix specialist by any means but I do know how to type pkg_add . So stop spreading lies and read the documentation before taxing things as "toy". With most toys children are not expected to read documentation, you know. Regards, David
Re: uvm_fault in Dec. 15 amd64 snapshot
On Sun, Dec 18, 2011 at 18:50 -0800, James A. Peltier wrote:
> - Original Message -
> | Hi All,
> |
> | Today is our semester maintenance day and we've upgraded our backup
> | bridge firewall to the Dec. 15, 2011 snapshot available from
> | ftp.openbsd.org and I'm getting this odd error when I boot it up.
> | Oddly enough, this only happens when connected to the switch that
> | original one is connected to (we swap them out each semester).
> |
> | First, I use the upgrade method to go from snapshot to snapshot and
> | reboot
> | I run sysmerge to bring in the new configuration files from etc50.tgz
> | and xetc50.tgz ( I only have bsd* man* base* xbase* installed) and
> | reboot.
> |
> | So as you can see the standard running -current and I've done several
> | upgrades now.
> |
> | On my test switch (HP5304XL) it boots okay and I can reload the
> | firewall rules with no problem. When I connect it to my HP2910 where
> | the current firewall is running I cannot fully boot. If I press CTRL+C
> | during the starting network section it will continue to boot. If I
> | then run pfctl -e it states that PF is already enabled enabled but if
> | I run pfctl -Fr -f /etc/pf.conf I get the following.
> |
> | # uvm_fault(0x80d2ff40, 0x0, 0, 1) -> e
> | kernel: page fault trap, code=0
> | Stopped at pf_translate+0x154: cmpw %r13w,0(%rsi)
> | ddb{0}>
> |
> | keyboard is dead, no response at all from console. Any ideas?
>
> Okay, I've gotten some off list requests for more information, which
> I'm hoping I'll be able to get for those people, but I'm now outside
> of my maintenance window and will likely need to schedule another
> outage or figure out how to reproduce it again. The current bridge
> firewall running the following version does not exhibit the problem,
> but I'm not able to get a trace output at this time. Maybe it's
> still at least somewhat useful reference for updates that may have
> happened. ( Yeah right, from Aug 8th until now. Thousands of
> commits. ;) )
>
> OpenBSD 5.0 (GENERIC.MP) #57: Mon Aug 8 14:58:00 MDT 2011
> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
>
pf_translate+0x154 corresponds to the condition at pf.c:3765.
*pd->sport doesn't point to anything. pd->sport is set to point
to the extracted header in the pf_setup_pdesc. the problem is
that the header extraction happens based on the virtual_proto,
not proto, which can be different in the case of a fragment.
now, pf.c got it covered by the condition on line 3476 which
prevents pf_translate from running on fragments. the only
other invocation of pf_translate is in the if_pflog.c:407
where we don't check for fragments. therefore i think that
this is the problem.
the diff below should fix the problem. it also doesn't make
sense to do af translation if we didn't manage to get our
shit done in the pf_translate and in the subsequent block.
ok?
Index: if_pflog.c
===
RCS file: /cvs/src/sys/net/if_pflog.c,v
retrieving revision 1.45
diff -u -p -r1.45 if_pflog.c
--- if_pflog.c 21 Oct 2011 15:45:55 - 1.45
+++ if_pflog.c 19 Dec 2011 20:36:32 -
@@ -404,7 +404,8 @@ pflog_bpfcopy(const void *src_arg, void
if (pd.dport)
odport = *pd.dport;
- if ((pfloghdr->rewritten = pf_translate(&pd, &pfloghdr->saddr,
+ if (pd->virtual_proto != PF_VPROTO_FRAGMENT &&
+ (pfloghdr->rewritten = pf_translate(&pd, &pfloghdr->saddr,
pfloghdr->sport, &pfloghdr->daddr, pfloghdr->dport, 0,
pfloghdr->dir))) {
m_copyback(pd.m, pd.off, min(pd.m->m_len - pd.off, pd.hdrlen),
@@ -422,7 +423,7 @@ pflog_bpfcopy(const void *src_arg, void
pd.tot_len = min(pd.tot_len, len);
pd.tot_len -= pd.m->m_data - pd.m->m_pktdat;
- if (afto)
+ if (pfloghdr->rewritten && afto)
pf_translate_af(&pd);
mlen = min(pd.m->m_pkthdr.len, len);
upgrade OpenBSD
Hi list, the OpenBSD upgrade pages carry a warning at the top "Note: Upgrades are only supported from one release to the release immediately following it. Do not skip releases." What's the reason for this warning? I've had a look at the upgrade steps and the only thing that seems to assume a certain system configuration is the update of the configuration files using the patches. This shouldn't be a problem when using sysmerge though, should it? To be clear, I'm not intending to start a flame war about OpenBSD upgrade processes, I was just wondering why releases shouldn't be skipped. I'm looking to upgrade a machine running 4.6 to 5.0 and would obviously prefer to do this in one step instead of four. Thanks, Lars
Proper way to update system + ports?
I ran into an error trying to install Firefox (I think the latest version in Ports is 8.0.1) so I thought I might be updating incorrectly. First, this is the error I get when I try to install Firefox: # cd /usr/ports/www/mozilla-firefox/ # /home/jay/ports/install.sh /* the contents of install.sh are as follows: #!/bin/ksh make package BULK=yes make install make clean make clean=depends make clean=dist make clean=flavors */ ===> Checking files for firefox-5.0p3 >> Fetch >> http://releases.mozilla.org/pub/mozilla.org/firefox/releases/5.0/source/firefox-5.0.source.tar.bz2 ftp: Error retrieving file: 404 Not Found >> Fetch >> http://ftp.openbsd.org/pub/OpenBSD/distfiles/mozilla/firefox-5.0.source.tar.bz2 ftp: Error retrieving file: 404 Not Found >> Fetch >> ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/mozilla/firefox-5.0.source.tar.bz2 firefox-5.0.source.tar.bz2: No such file or directory. *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2702 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2091 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2309 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 1699 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2270 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2250 of /usr/ports/infrastructure/mk/bsd.port.mk). ===> Checking files for firefox-5.0p3 >> Fetch >> http://releases.mozilla.org/pub/mozilla.org/firefox/releases/5.0/source/firefox-5.0.source.tar.bz2 ftp: Error retrieving file: 404 Not Found >> Fetch >> http://ftp.openbsd.org/pub/OpenBSD/distfiles/mozilla/firefox-5.0.source.tar.bz2 ftp: Error retrieving file: 404 Not Found >> Fetch >> ftp://ftp.usa.openbsd.org/pub/OpenBSD/distfiles/mozilla/firefox-5.0.source.tar.bz2 firefox-5.0.source.tar.bz2: No such file or directory. *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2702 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2091 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2309 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 1699 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2270 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2250 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 1730 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/www/mozilla-firefox (line 2250 of /usr/ports/infrastructure/mk/bsd.port.mk). ===> Cleaning for firefox-5.0p3 ===> Cleaning for hicolor-icon-theme-0.12p1 ===> Cleaning for metaauto-1.0 ===> Cleaning for autoconf-2.13p2 ===> Cleaning for dbus-1.4.12v0 ===> Cleaning for libusb-0.1.12p4 ===> Cleaning for jpeg-8c ===> Cleaning for gperf-3.0.4 ===> Cleaning for libiconv-1.13p2 ===> Cleaning for gettext-0.18.1p0 ===> Cleaning for gmake-3.82 ===> Cleaning for nspr-4.8.7 ===> Cleaning for p5-XML-Parser-2.41 ===> Cleaning for groff-1.21p4 ===> Cleaning for unzip-6.0p0 ===> Cleaning for jasper-1.900.1p1 ===> Cleaning for intltool-0.41.1 ===> Cleaning for bzip2-1.0.6 ===> Cleaning for libgamin-0.1.10p4 ===> Cleaning for help2man-1.29p0 ===> Cleaning for autoconf-2.65 ===> Cleaning for autoconf-2.59p3 ===> Cleaning for tcl-8.5.9p0 ===> Cleaning for sqlite3-3.7.5 ===> Cleaning for nss-3.12.9 ===> Cleaning for tk-8.5.9p1 ===> Cleaning for db-4.6.21p4 ===> Cleaning for automake-1.9.6p8 ===> Cleaning for autoconf-2.61p3 ===> Cleaning for gdbm-1.8.3p0 ===> Cleaning for python-2.7.1p9 ===> Cleaning for libxml-2.7.8p3 ===> Cleaning for pcre-8.12p0 ===> Cleaning for glib2-2.28.8p1 ===> Cleaning for libIDL-0.8.14 ===> Cleaning for desktop-file-utils-0.18p0 ===> Cleaning for shared-mime-info-0.90 ===> Cleaning for zip-3.0 ===> Cleaning for libffi-3.0.9 ===> Cleaning for xz-5.0.3p1 ===> Cleaning for tiff-3.9.5 ===> Cleaning for xdg-utils-1.0.2p12 ===> Cleaning for libsigsegv-2.8 ===> Cleaning for m4-1.4.13 ===> Cleaning for bison-2.3 ===> Cleaning for png-1.5.4p0 ===> Cleaning for cairo-1.10.2p1 ===> Cleaning for gobject-introspection-0.10.8p8 ===> Cleaning for pango-1.28.4p2 ===> Cleaning for atk-2.0.1 ===> Cleaning for gdk-pixbuf-2.23.5 ===> Cleaning for cups-1.4.7p0 ===> Cleaning for gtk+2-2.24.5p0 ===> Cleaning for firefox-5.0p3 ===> Cleaning for firefox-5.0p3 ===> Dist cleaning for firefox-5.0p3 ===> Cleaning for firefox-5.0p3 For some reason it's trying to install some obscure version of Firefox ins
Re: Proper way to update system + ports?
James Hozier writes: > I ran into an error trying to install Firefox (I think the latest > version in Ports is 8.0.1) so I thought I might be updating > incorrectly. If you want such a recent firefox, use -current, not -stable. > First, this is the error I get when I try to install Firefox: > > # cd /usr/ports/www/mozilla-firefox/ > # /home/jay/ports/install.sh Nah. Use packages. ftp://ftp.usa.openbsd.org/pub/OpenBSD/5.0/packages/i386/firefox-5.0p3.tgz [snip] > For some reason it's trying to install some obscure version of > Firefox instead of the latest. You have a -stable ports tree. > I performed this on a default install of 5.0 after updating. Here's > how I update my system: [snip] There's no point in upgrading your full system every week. -stable only gets security updates. -- Jeremie Courreges-Anglas - GPG ID 0x06A11494
Re: upgrade OpenBSD
On 12/19/11 15:55, Lars Kotthoff wrote: Hi list, the OpenBSD upgrade pages carry a warning at the top "Note: Upgrades are only supported from one release to the release immediately following it. Do not skip releases." What's the reason for this warning? I've had a look at the upgrade steps and the only thing that seems to assume a certain system configuration is the update of the configuration files using the patches. This shouldn't be a problem when using sysmerge though, should it? To be clear, I'm not intending to start a flame war about OpenBSD upgrade processes, I was just wondering why releases shouldn't be skipped. I'm looking to upgrade a machine running 4.6 to 5.0 and would obviously prefer to do this in one step instead of four. Thanks, Lars The reason is that things could change from release to release, such that applying an OpenBSD 5.x upgrade might cause problems with OpenBSD 5.y. Now, it may be the case that a procedure could be the same in multiple updates, but having specific directions for each release gets people into the mind set of looking for an update guide rather than assume they just know. In your case, I'd save all relevant data to the machine and do a fresh install. Using a different disk means that you can mount the previous one and copy files as needed from it. --STeve Andre'
Re: uvm_fault in Dec. 15 amd64 snapshot
On Mon, Dec 19, 2011 at 21:46 +0100, Mike Belopuhov wrote:
> On Sun, Dec 18, 2011 at 18:50 -0800, James A. Peltier wrote:
> > - Original Message -
> > | Hi All,
> > |
> > | Today is our semester maintenance day and we've upgraded our backup
> > | bridge firewall to the Dec. 15, 2011 snapshot available from
> > | ftp.openbsd.org and I'm getting this odd error when I boot it up.
> > | Oddly enough, this only happens when connected to the switch that
> > | original one is connected to (we swap them out each semester).
> > |
> > | First, I use the upgrade method to go from snapshot to snapshot and
> > | reboot
> > | I run sysmerge to bring in the new configuration files from etc50.tgz
> > | and xetc50.tgz ( I only have bsd* man* base* xbase* installed) and
> > | reboot.
> > |
> > | So as you can see the standard running -current and I've done several
> > | upgrades now.
> > |
> > | On my test switch (HP5304XL) it boots okay and I can reload the
> > | firewall rules with no problem. When I connect it to my HP2910 where
> > | the current firewall is running I cannot fully boot. If I press CTRL+C
> > | during the starting network section it will continue to boot. If I
> > | then run pfctl -e it states that PF is already enabled enabled but if
> > | I run pfctl -Fr -f /etc/pf.conf I get the following.
> > |
> > | # uvm_fault(0x80d2ff40, 0x0, 0, 1) -> e
> > | kernel: page fault trap, code=0
> > | Stopped at pf_translate+0x154: cmpw %r13w,0(%rsi)
> > | ddb{0}>
> > |
> > | keyboard is dead, no response at all from console. Any ideas?
> >
> > Okay, I've gotten some off list requests for more information, which
> > I'm hoping I'll be able to get for those people, but I'm now outside
> > of my maintenance window and will likely need to schedule another
> > outage or figure out how to reproduce it again. The current bridge
> > firewall running the following version does not exhibit the problem,
> > but I'm not able to get a trace output at this time. Maybe it's
> > still at least somewhat useful reference for updates that may have
> > happened. ( Yeah right, from Aug 8th until now. Thousands of
> > commits. ;) )
> >
> > OpenBSD 5.0 (GENERIC.MP) #57: Mon Aug 8 14:58:00 MDT 2011
> > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> >
> >
>
> pf_translate+0x154 corresponds to the condition at pf.c:3765.
> *pd->sport doesn't point to anything. pd->sport is set to point
> to the extracted header in the pf_setup_pdesc. the problem is
> that the header extraction happens based on the virtual_proto,
> not proto, which can be different in the case of a fragment.
>
> now, pf.c got it covered by the condition on line 3476 which
> prevents pf_translate from running on fragments. the only
> other invocation of pf_translate is in the if_pflog.c:407
> where we don't check for fragments. therefore i think that
> this is the problem.
>
> the diff below should fix the problem. it also doesn't make
> sense to do af translation if we didn't manage to get our
> shit done in the pf_translate and in the subsequent block.
>
> ok?
>
ugh, typo has crawled into the diff...
in the meantime, i've confirmed that james is using logging facility.
Index: net/if_pflog.c
===
RCS file: /cvs/src/sys/net/if_pflog.c,v
retrieving revision 1.45
diff -u -p -r1.45 if_pflog.c
--- net/if_pflog.c 21 Oct 2011 15:45:55 - 1.45
+++ net/if_pflog.c 19 Dec 2011 23:13:55 -
@@ -404,7 +404,8 @@ pflog_bpfcopy(const void *src_arg, void
if (pd.dport)
odport = *pd.dport;
- if ((pfloghdr->rewritten = pf_translate(&pd, &pfloghdr->saddr,
+ if (pd.virtual_proto != PF_VPROTO_FRAGMENT &&
+ (pfloghdr->rewritten = pf_translate(&pd, &pfloghdr->saddr,
pfloghdr->sport, &pfloghdr->daddr, pfloghdr->dport, 0,
pfloghdr->dir))) {
m_copyback(pd.m, pd.off, min(pd.m->m_len - pd.off, pd.hdrlen),
@@ -422,7 +423,7 @@ pflog_bpfcopy(const void *src_arg, void
pd.tot_len = min(pd.tot_len, len);
pd.tot_len -= pd.m->m_data - pd.m->m_pktdat;
- if (afto)
+ if (pfloghdr->rewritten && afto)
pf_translate_af(&pd);
mlen = min(pd.m->m_pkthdr.len, len);
Re: Proper way to update system + ports?
--- On Mon, 12/19/11, Jeremie Courreges-Anglas wrote: > From: Jeremie Courreges-Anglas > Subject: Re: Proper way to update system + ports? > To: misc@openbsd.org > Date: Monday, December 19, 2011, 10:16 PM > James Hozier > writes: > > > I ran into an error trying to install Firefox (I think > the latest > > version in Ports is 8.0.1) so I thought I might be > updating > > incorrectly. > > If you want such a recent firefox, use -current, not > -stable. > > > First, this is the error I get when I try to install > Firefox: > > > > # cd /usr/ports/www/mozilla-firefox/ > > # /home/jay/ports/install.sh > > Nah. Use packages. > ftp://ftp.usa.openbsd.org/pub/OpenBSD/5.0/packages/i386/firefox-5.0p3.tgz I've ALWAYS used Packages since 4.x, but I've recently started to use Ports because Packages don't have security updates, i.e. the version of Tor in the 5.0 Packages right now is tor-0.2.1.30p0.tgz, which version has since been updated with a couple of serious security updates. The Tor in Packages as it is now, until the next 5.1 release, is insecure to use. This is why I thought the latest version of Firefox in Ports was the most secure, because Packages never get updated until the next cycle. I don't update to -current because it breaks sometimes, and I'm rather a -stable type user. I don't have the need for bleeding edge or latest and greatest...I can wait until the next release. So -current Ports are not compatible with -stable Ports, right? Or am I wrong in presuming this? > > [snip] > > > For some reason it's trying to install some obscure > version of > > Firefox instead of the latest. > > You have a -stable ports tree. > > > I performed this on a default install of 5.0 after > updating. Here's > > how I update my system: > > [snip] > > There's no point in upgrading your full system every week. > -stable only > gets security updates. > > -- > Jeremie Courreges-Anglas - GPG ID 0x06A11494 > > Ah, okay. But it would still be smart to update the Ports every so often with the new versions of software, right? I'm still a bit confused between the -current and -stable ports and if such a difference even exists.
Re: Proper way to update system + ports?
On Mon, Dec 19, 2011 at 3:25 PM, James Hozier wrote: > --- On Mon, 12/19/11, Jeremie Courreges-Anglas > wrote: > So -current Ports are not compatible with -stable Ports, right? > Or am I wrong in presuming this? > > Per FAQ 15.4.1: Do NOT check out a -current ports tree and expect it to work on a -release or -stable system.
Re: upgrade OpenBSD
* Lars Kotthoff [2011-12-19 21:57]: > the OpenBSD upgrade pages carry a warning at the top "Note: Upgrades are only > supported from one release to the release immediately following it. Do not > skip > releases." > > What's the reason for this warning? That's simple: from the previous release is the only thing we test. from older ones usually works, but as said, it doesn't get tested and thus might break. and then you'll have to deal with that. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: Proper way to update system + ports?
--- On Mon, 12/19/11, James Hartley wrote: > From: James Hartley > Subject: Re: Proper way to update system + ports? > To: "James Hozier" > Cc: misc@openbsd.org > Date: Monday, December 19, 2011, 11:44 PM > On Mon, Dec 19, 2011 at 3:25 PM, > James Hozier > wrote: > > > --- On Mon, 12/19/11, Jeremie Courreges-Anglas > > > wrote: > > So -current Ports are not compatible with -stable > Ports, right? > > Or am I wrong in presuming this? > > > > > Per FAQ 15.4.1: > > Do NOT check out a -current ports tree and expect it to > work on a -release > or -stable system. > > How do I know if I have checked out the -current ports tree or the -stable ports tree?
Re: Proper way to update system + ports?
On Mon, Dec 19, 2011 at 4:19 PM, James Hozier wrote: > > > --- On Mon, 12/19/11, Jeremie Courreges-Anglas > > > > > wrote: > > > So -current Ports are not compatible with -stable > > Ports, right? > > > Or am I wrong in presuming this? > > > > > > > > Per FAQ 15.4.1: > > > > Do NOT check out a -current ports tree and expect it to > > work on a -release > > or -stable system. > > > > > > How do I know if I have checked out the -current ports tree or > the -stable ports tree? > Study FAQ 5.3.3. If no tagname was explicitly provided in the CSV command used, then the head of the CVS tree (in this case -current) was downloaded.
Re: Proper way to update system + ports?
Hi, James Hartley wrote on Mon, Dec 19, 2011 at 04:36:24PM -0800: > On Mon, Dec 19, 2011 at 4:19 PM, James Hozier wrote: >> How do I know if I have checked out the -current ports tree or >> the -stable ports tree? > Study FAQ 5.3.3. If no tagname was explicitly provided in the CSV command > used, then the head of the CVS tree (in this case -current) was downloaded. Right, *if* the tree was checked out in one single piece, and if no parts of the tree were moved to other branches after the fact. Be wary about trees when you don't remember where you got them from, and how exactly, and what you changed. Each file might be from a different branch (even in the same directory) and each directory might be from a different server (even subdirectories of each other), and just because something is a subdirectory of something else doesn't mean the same relations hold on the server - or rather, on whatever servers are involved. More than once, i lost my way in forests spanning multiple servers and branches, mistaking them for clean trees... Here, look at this. What do you think, it that from a -current or a -stable OpenBSD-base tree? After showing you, i'm probably going to clean this up using cvs up -A. Yours, Ingo schwarze@eos $ cvs status mandoc.* === File: mandoc.1 Status: Up-to-date Working revision:1.43 Repository revision: 1.43/cvs/src/usr.bin/mandoc/mandoc.1,v Sticky Tag: OPENBSD_4_9 (branch: 1.43.2) Sticky Date: (none) Sticky Options: (none) === File: mandoc.c Status: Up-to-date Working revision:1.26 Repository revision: 1.26/cvs/src/usr.bin/mandoc/mandoc.c,v Sticky Tag: OPENBSD_5_0 (branch: 1.26.2) Sticky Date: (none) Sticky Options: (none) === File: mandoc.h Status: Up-to-date Working revision:1.43 Repository revision: 1.43/cvs/src/usr.bin/mandoc/mandoc.h,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) schwarze@eos $ grep -F /mandoc. CVS/Entries /mandoc.h/1.43/Sun Dec 18 19:47:03 2011// /mandoc.1/1.43/Tue Dec 20 01:09:33 2011//TOPENBSD_4_9 /mandoc.c/1.26/Tue Dec 20 01:09:54 2011//TOPENBSD_5_0
Re: Proper way to update system + ports?
--- On Tue, 12/20/11, James Hartley wrote: > From: James Hartley > Subject: Re: Proper way to update system + ports? > To: "James Hozier" > Cc: misc@openbsd.org > Date: Tuesday, December 20, 2011, 12:36 AM > On Mon, Dec 19, 2011 at 4:19 PM, > James Hozier > wrote: > > > > > --- On Mon, 12/19/11, Jeremie > Courreges-Anglas > > > > > > > wrote: > > > > So -current Ports are not compatible with > -stable > > > Ports, right? > > > > Or am I wrong in presuming this? > > > > > > > > > > > Per FAQ 15.4.1: > > > > > > Do NOT check out a -current ports tree and expect > it to > > > work on a -release > > > or -stable system. > > > > > > > > > > How do I know if I have checked out the -current ports > tree or > > the -stable ports tree? > > > > Study FAQ 5.3.3. If no tagname was explicitly > provided in the CSV command > used, then the head of the CVS tree (in this case -current) > was downloaded. > > So in my case, the command I used: # cvs -d$CVSROOT checkout -rOPENBSD_5_0 -P src ports included the -rOPENBSD_5_0 tag (-r) which indicates the -stable tree, right? And it applied to both src and ports so that I checked out the -stable version of both src and ports?
Re: Proper way to update system + ports?
Also, would it be a bad idea to use both Ports and Packages? For example since the mozilla-firefox Port isn't working, and I use Packages to install Firefox, would it conflict with other Ports that I use, or the dependencies the softwares might share?
Re: Proper way to update system + ports?
On Mon, Dec 19, 2011 at 5:17 PM, James Hozier wrote: > --- On Tue, 12/20/11, James Hartley wrote: > > > From: James Hartley > > Subject: Re: Proper way to update system + ports? > > To: "James Hozier" > > Cc: misc@openbsd.org > > Date: Tuesday, December 20, 2011, 12:36 AM > > On Mon, Dec 19, 2011 at 4:19 PM, > > James Hozier > > wrote: > > > > > > > --- On Mon, 12/19/11, Jeremie > > Courreges-Anglas > > > > > > > > > wrote: > > > > > So -current Ports are not compatible with > > -stable > > > > Ports, right? > > > > > Or am I wrong in presuming this? > > > > > > > > > > > > > > Per FAQ 15.4.1: > > > > > > > > Do NOT check out a -current ports tree and expect > > it to > > > > work on a -release > > > > or -stable system. > > > > > > > > > > > > > > How do I know if I have checked out the -current ports > > tree or > > > the -stable ports tree? > > > > > > > Study FAQ 5.3.3. If no tagname was explicitly > > provided in the CSV command > > used, then the head of the CVS tree (in this case -current) > > was downloaded. > > > > > > So in my case, the command I used: > # cvs -d$CVSROOT checkout -rOPENBSD_5_0 -P src ports > > included the -rOPENBSD_5_0 tag (-r) which indicates the -stable tree, > right? And it applied to both src and ports so that I checked out > the -stable version of both src and ports? > Correct. However, you can't seem to fully account for the status of the downloaded tree. So as Ingo, I would treat whatever you currently have on your system as suspect. Personally, I would recommend getting the tree again as you could be in the weeds wasting a lot of time. Likewise, if you study the check-in history for Firefox: http://www.openbsd.org/cgi-bin/cvsweb/ports/www/mozilla-firefox/Makefile You will see that the OPENBSD_5_0 tag at revision 1.187. Firefox 6.0 wasn't checked into the ports tree until 1.188. This means that for Firefox 5 is the only version available to OpenBSD 5.0-release & -stable. If you want a newer version, you will have to run -current. > Also, would it be a bad idea to use both Ports and Packages? You don't seem to understand how the packages/ports system works. The output of compiling ports is packages -- the very same packages which can be found on the mirrors. So there is nothing to be gained by compiling ports for -release or -stable unless there have been security fixes or other changes checked into the ports tree. The above link show both OPENBSD_5_0 & OPENBSD_5_0_BASE tags on revision 1.187 of the Makefile used to build the Firefox port so nothing has changed for 5.0-release or -stable since 5.0 was released. All changes to Firefox, versions 6.0, 7.0, & 8.0, have taken place in -current only.
Best agent at CHina --HARVEST LOG
Good day, friend,Muhammad IMRAN I am not sure your esteemed name, just know your company do business with China before. I am jolie ,manager of overseas Dept of Harvest logistics CHINA. If possible, Let us support to you at China. We are good at transportation by sea/by air/by train from China to your side, we can handle logistics business for you,in mailand of China. Share below cost with you here, if you need others destination, contact with us . If I bother you ,forgive me pls this time. Asia !! !! !! !! !! !! POL Dest. +100KGS +300KGS +500KGS +1,000KGS Valid till PVG !! !! !! !! !! End of DEC !! SIN 2.36 2.36 2.28 2.12 !! KUL 2.44 2.44 2.36 2.20 !! JKT 2.44 2.44 2.36 2.20 !! BKK 2.44 2.44 2.36 2.04 !! DPS 2.44 2.44 2.36 2.20 !! SGN 2.44 2.44 2.36 2.20 !! MNL 2.59 2.59 2.52 2.36 !! HAN 2.59 2.59 2.52 2.36 Remark Currency is USD Jolie zhang Overseas dept Shanghai Harvest International Logistics Co., Ltd Tel: 0086-21-63249293*803 Fax: 0086-21-63244312 ATT: sw...@harvest-log.comSkype: harvestlog1 Logis Website: www.harvest-log.com Trade Website: www.harvest-log.com/soupo Headoffice Address: Room 2108 ,Fude building ,No.,1688, North Sichuan Road,Hongkou District#,Shanghai, China we have 12 offices in Chinese mainland.they can help to handle local shipments.
misc@openbsd.org
Finanziamenti&Prestiti Assistenza alle Aziende in crisi Soluzioni per l'Azienda e la Famiglia Consulta il sito Finanziamenti&Prestiti per non ricevere ulteriori news clicchi qui NEW Zoner Photo Studio Free - is a free program for every step in the process of managing, editing, and sharing pictures. --- freephotostudio.com
Re: upgrade OpenBSD
On 12/19/11 15:55, Lars Kotthoff wrote: > Hi list, > > the OpenBSD upgrade pages carry a warning at the top "Note: Upgrades are only > supported from one release to the release immediately following it. Do not > skip > releases." > > What's the reason for this warning? I've had a look at the upgrade steps and > the > only thing that seems to assume a certain system configuration is the update > of > the configuration files using the patches. As Henning indicated...it's what we test. There are 17 platforms for OpenBSD. There's a lot to test for each release, testing upgrades from 4.8 to 5.0 just doubled our work...pointlessly. Documenting the two-release process just doubled MY work. And you want four steps. No. > This shouldn't be a problem when > using sysmerge though, should it? By that statement, I presume you audited the code for that? no, actually, I didn't believe that. :) > To be clear, I'm not intending to start a flame war about OpenBSD upgrade > processes, I was just wondering why releases shouldn't be skipped. I'm looking > to upgrade a machine running 4.6 to 5.0 and would obviously prefer to do this > in > one step instead of four. This REALLY falls under the category of, "if you gotta ask, don't. Just don't." The OpenBSD upgrade process is really simple (so simple, *I* could write the process! Come to think of it, I do!), but if you are asking "can I get away with ...", rather than understanding the process well enough to answer your own question, don't. Consider it punishment for not having kept the system up to date. You SHOULD have done those three missing updates anyway...now you have to do them all in one hour. :) And, if there's any question this isn't just a snarky answer (I'm not denying it is ALSO a snarky answer), if you look at the update instructions for any arbitrary version of OpenBSD, you will note there is more to it than just "run sysmerge". When you start jumping versions, you may see interesting issues from those steps...and little problems that will bite you in the ass and you won't be sure which step you skipped did it. Me? If I had console on the machine, I'd have no trouble taking your system directly from 4.6 to 5.0 (and the console would be just in case I got cocky and screwed up :). But then, I understand the process pretty well (we hope!). I understand it well enough that I suggest YOU take the advice. Nick.
Re: claimed 5.0 problems on sparc64 (was Re: Upgrading AMD64 4.9-stable to 5.0)
On 12/19/11 14:39, Stuart Henderson wrote: > On 2011-12-19, Richard Thornton wrote: >> Do a simple clean 5.0 install. One would assume any browser package in the >> packages folder would install. None do for me on sparc, but with a clean >> 4.9 install all 4.9 packages install. I am not a Unix specialist by any >> means but I do know how to type pkg_add . > > Please send a mail to ports@ detailing exactly what you are doing (what > you're typing, what PKG_PATH is set to if you're using it, the contents > of /etc/pkg.conf if you're using that) and what output you see. > > This is the first I've heard of any major problem with 5.0 release > packages on any arch, if there is a problem obviously we need to know > what went wrong so we can avoid it happening in future, but before > digging into that we need to first rule out incorrect procedure. Don't bother, he's doing something very wrong. This is a PEBKAC diagnostic issue, not an OpenBSD issue. Just happened to have a blade100 (the machine he named) sitting here, just loaded it up, but not into production yet, so blew it away (it was at -current, of course) and did exactly what he said: * simple 5.0 install from CD (only non-default was to use ntpd) * set PKG_PATH to my local mirror * pkg_add xxxterm * pkg_add firefox36 (didn't seem to be newer ones for sparc64) * pkg_add dillo * pkg_add conkeror * pkg_add midori * pkg_add kazehakase * pkg_add links+2.2p2 * pkg_add elinks * pkg_add w3m-0.5.3 * pkg_add links FINALLY! an error! conflict with links+. Package management system worked fine :) Other than links after links+, all installed fine. Starting them all at the same time on a blade100 with only 512M RAM was not my most productive move, but they all seemed to be trying to work, until something ran out of something and X blew me back to a command prompt :) (I gotta play with some of these alternate browsers) Personally, I think he's screwing up between sparc and sparc64. He's being VERY sloppy with the platform name_s_ in his posting, so I suspect it is safe to assume he's doing that elsewhere. Nick.
4096-byte sector size again
I have an Iomega Prestige 1TB disk, "USB 3.0 up to 5Gbit/s", OpenBSD 4.9 (GENERIC.MP) #794: Wed Mar 2 07:19:02 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP .. Dec 17 09:53:54 len /bsd: port 2 configuration 1 interface 0 "iomega LDHD-UP3" rev 2.10/0.04 addr 4 Dec 17 09:53:54 len /bsd: umass0: using SCSI over Bulk-Only Dec 17 09:53:54 len /bsd: scsibus2 at umass0: 2 targets, initiator 0 Dec 17 09:53:54 len /bsd: sd1 at scsibus2 targ 1 lun 0: SCSI3 0/direct fixed Dec 17 09:53:54 len /bsd: sd1: 953169MB, 4096 bytes/sec, 244011446 sec total Dec 17 09:53:54 len /bsd: cd1 at scsibus2 targ 1 lun 1: SCSI0 5/cdrom fixed (which of course has the built-in CD-ROM emulator containing Windows backup software.) The sectors are definitely 4k bytes. How can I re-partition it given that fdisk won't adjust the MBR? # fdisk -e sd1 Unable to read MBR (DOS partitions, not disklabel partitions. disklabel works just fine.) thanks --John
Re: correct netmask on carp interfaces
On Nov 24, 2011, at 8:40 PM, Henning Brauer wrote: > * Russell Garrison [2011-11-22 18:28]: >> I have set up my system accordingly and my advice is to set your carp >> primary IP to the proper network mask (especially if it is using the >> carp IP to provide a gateway to the connected network) and then any >> other IP/interfaces to /32 per subnet. > > if your carpdev has an IP and the IP(s) on the carp interface are in > the same subnet, is it best to have the real netmask on the carpdev > and all-ones netmasks on the carp interface, for the case where you're > carp slave. > > and the rule of thumb remains, one IP per subnet per rdomain in the > system with the real netmask, all others all-ones - aka /32 for the one > and only real protocol. I've tried to find any mentions in the documentation about aliases, all-ones, and IPv6. Is it correct to assume that one should NOT use /128 prefixes for IPv6 aliases? In the context of CARP: # ifconfig em0 em0: flags=8b43 mtu 1500 ... inet A.B.C.1 netmask 0xff00 broadcast XXX inet6 ABC::1 prefixlen 64 # ifconfig carp0 carp0: flags=8843 mtu 1500 ... carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100 inet A.B.C.2 netmask 0x inet6 ABC::2 prefixlen 64 In other words, using /32 for IPv4 aliases, but NOT /128 for IPv6 aliases? What made me believe this was the usage of /64 in http://www.openbsd.org/cgi-bin/man.cgi?query=hostname.if Take care Anders [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
