Re: OpenBSD's brilliant design
I've since been advised that a show of appreciation is better expressed through donations. And they're coming - you have my word. Tony On Mon, Jul 30, 2012 at 11:44 PM, Tony wrote: > Dear Theo, > > This was not meant as a troll, sorry if it came off like that. > > It was more a show of appreciation for what you've achieved over the years > as well as a request for more topics to write about in my thesis. > > Thank you for everything. Hope I get to meet you in real life some day - > drinks are on me! > > Tony > > > On Mon, Jul 30, 2012 at 8:21 PM, Theo de Raadt wrote: > >> > I'm about to write an article on OpenBSD's brilliant design, mainly to >> make >> > things clearer to myself as well as my coworkers - all of whom have been >> > using FreeBSD for the past 15 years. All of whom have recently >> converted to >> > OpenBSD due to the need for something simpler to base our million-dollar >> > webapps on. >> >> Everyone, please don't fall for the troll. If you must respond, talk to >> him privately. >> >> If any of you want misc@ to be useful mailing list -- guess what -- it >> starts by you making it useful.
Re: OpenBSD's brilliant design
Dear Theo, This was not meant as a troll, sorry if it came off like that. It was more a show of appreciation for what you've achieved over the years as well as a request for more topics to write about in my thesis. Thank you for everything. Hope I get to meet you in real life some day - drinks are on me! Tony On Mon, Jul 30, 2012 at 8:21 PM, Theo de Raadt wrote: > > I'm about to write an article on OpenBSD's brilliant design, mainly to > make > > things clearer to myself as well as my coworkers - all of whom have been > > using FreeBSD for the past 15 years. All of whom have recently converted > to > > OpenBSD due to the need for something simpler to base our million-dollar > > webapps on. > > Everyone, please don't fall for the troll. If you must respond, talk to > him privately. > > If any of you want misc@ to be useful mailing list -- guess what -- it > starts by you making it useful.
OpenBSD's brilliant design
Hello! I'm about to write an article on OpenBSD's brilliant design, mainly to make things clearer to myself as well as my coworkers - all of whom have been using FreeBSD for the past 15 years. All of whom have recently converted to OpenBSD due to the need for something simpler to base our million-dollar webapps on. Here are the outlines. I'd appreciate some feedback. I hope it doesn't offend anybody: - OpenBSD's brilliant design Breath of fresh air in a world otherwise filled with clutter What happens when the right people take charge Perfection is achieved, not when there's nothing left to add, but when there's nothing left to take away Sexy blue dmesg Clear and appealing project goals Its website Well thought out and timeless (ask anyone: wolffolins.com, wearebuild.com, orangeriet.no, grandpeople.org) As other websites strive to attain the latest trends (read: fads) Remained the same for over a decade - shows that OpenBSD is willing to stand for what it believes in FreeBSD ASCII nightmare (boot loader, sysinstall) Satanic logo What happens when a project accepts ideas from people with no sense of correctness or good design Its website http://lists.freebsd.org/pipermail/freebsd-questions/2012-April/240174.html - Thanks! Tony
Thank you
MSNBC works now. I'm in London so this means I can see the MSNBC site. Thank you.
Following -current through a semi-automatic process: a strategy for encouraging user involvement?
Summary: I want to turn my main system into a semi-automatic follower of "-current" and I think this strategy may useful to the project. Is this something that is already being done? My rationale here is that it's a good thing for OpenBSD users who have the technical skills to follow development as closely as possible, Running from a tightly synchronized copy of "-current" enables the user to produce the most useful bug reports in a timely manner. Seeing a list of CVS updates also helps the user to understand how the project is ticking. While not a system expert, I've got a lot of application development skills to offer but I'm also lazy enough to want to script the laborious process of following "-current". I've searched for automated update tools for "-current" but I don't see what I think should be there. What I have in mind is a layered set of tools that keeps the /usr/src, /usr/xenocara and /usr/ports trees up to date by regular synchronization, then builds a kernel if a successful sync occurs. I have enough slack time to make this easy on my main system. The idea is that the system regularly (nightly) synchronizes all three main source directories, then rebuilds and installs the latest GENERIC kernel if synchronization is successful. As owner I can decide whether or not to reboot into the new kernel. I then have the option of starting a rebuild of the userland to synchronize it with the kernel. The same procedure can perhaps try to sync the installed packages (# pkg-add -u). Perhaps also an automated script to rebuild installed packages from the synchronized ports tree. This would enable users like me to quickly check our bugs against the latest build with kernel, userland and ports all synchronized thus encouraging us to make a bug report in the knowledge that it will be useful. If there is an RSS feed for the "Following current" page that can be folded in. I've got a prototype that tries to do most of these steps. Am I reinventing the wheel? Does this kind of thinking fit in with OpenBSD project requirements? Please let me know. I'm interested in helping OpenBSD in any way I can. Up to now I've followed Snapshots, but I find that less than satisfactory because from that point of view the development process is removed and rather opaque. My scripts enable me to watch the workflow across the project, and give me a feeling of involvement that I could not get from upgrading from binary image every few days.
Re: nonexistent tables in pf.conf
Jan Stary wrote: >There is a difference between an empty table and a nonexistent table, >and there is a difference between a table not existing at load time >and table being deleted. Exactly what difference in behavior is expected? This seems too much like NULL pointer exceptions in Java, where the value of the expression is a crashed program.
Re: Intel E3-1270 and AES-NI
On Tue, Apr 3, 2012 at 10:49 PM, mxb wrote: > > On Apr 3, 2012, at 4:31 PM, Tony Sarendal wrote: > > > On Tue, Apr 3, 2012 at 3:41 PM, Jonathan Gray wrote: > > > >> On Tue, Apr 03, 2012 at 03:09:37PM +0200, Tony Sarendal wrote: > >>> When testing new boxes with Intel E3-1270 cpu I don't see AES on the > >> cpu's > >>> in dmesg. > >>> Does this mean that the aes-ni stuff isn't used on these ? I was a bit > >>> curious to see if it had any effect on ipsec performance. > >> > >> According to > >> > >> > http://ark.intel.com/products/52276/Intel-Xeon-Processor-E3-1270-%288M-Cache-3_40-GHz%29 > >> > >> it does support it. So it sounds like a problem with the bios. It > would > >> be printing along with the other cpuid flags in the cpu part > >> of dmesg were it enabled. And if the cpuid says it is not present, > >> it is not used. > >> > > > > You are star. It was disabled in bios. > > > > Cheers. > > > > Sometimes you even need to flash BIOS to have it. > > Worked fine here. Performance boost depended a lot on packet size, a full speed one direction tcp data transfer got a 30% boost from enabling aes-ni. Small packet size, 200 byte mtu in sending direction, gave around 5% boost. The test box has been doing 400Mbps of large frame data transfer for a day or so now. One interesting thing was that running with SP kernel two low-latency, high-speed, tcp tranfers could starve userland badly enough to drop bgp sessions where as with MP kernel the box remained responsive no matter how many tcp sessions I shot through it. /T
Re: Intel E3-1270 and AES-NI
On Tue, Apr 3, 2012 at 3:41 PM, Jonathan Gray wrote: > On Tue, Apr 03, 2012 at 03:09:37PM +0200, Tony Sarendal wrote: > > When testing new boxes with Intel E3-1270 cpu I don't see AES on the > cpu's > > in dmesg. > > Does this mean that the aes-ni stuff isn't used on these ? I was a bit > > curious to see if it had any effect on ipsec performance. > > According to > > http://ark.intel.com/products/52276/Intel-Xeon-Processor-E3-1270-%288M-Cache-3_40-GHz%29 > > it does support it. So it sounds like a problem with the bios. It would > be printing along with the other cpuid flags in the cpu part > of dmesg were it enabled. And if the cpuid says it is not present, > it is not used. > You are star. It was disabled in bios. Cheers.
Intel E3-1270 and AES-NI
When testing new boxes with Intel E3-1270 cpu I don't see AES on the cpu's in dmesg. Does this mean that the aes-ni stuff isn't used on these ? I was a bit curious to see if it had any effect on ipsec performance. Regards Tony test3.pio# dmesg OpenBSD 5.1-current (GENERIC.MP) #258: Mon Apr 2 12:25:25 MDT 2012 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8566009856 (8169MB) avail mem = 8315633664 (7930MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeadc0 (107 entries) bios0: vendor American Megatrends Inc. version "1.1a" date 09/28/2011 bios0: Supermicro X9SCI/X9SCA acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP APIC SSDT MCFG HPET SPMI EINJ ERST HEST BERT acpi0: wakeup devices PS2K(S1) PS2M(S1) UAR1(S4) UAR2(S4) BR20(S1) EUSB(S4) USBE(S4) PEX4(S4) PEX5(S4) PEX6(S4) PEX7(S4) GBE_(S4) P0P1(S4) P0P2(S4) P0P3(S4) P0P4(S4) PEX0(S4) SLPB(S0) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E31270 @ 3.40GHz, 3392.78 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,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX,NXE,LONG,LAHF cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E31270 @ 3.40GHz, 3392.30 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,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX,NXE,LONG,LAHF cpu1: 256KB 64b/line 8-way L2 cache cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E31270 @ 3.40GHz, 3392.30 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,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX,NXE,LONG,LAHF cpu2: 256KB 64b/line 8-way L2 cache cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E31270 @ 3.40GHz, 3392.30 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,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX,NXE,LONG,LAHF cpu3: 256KB 64b/line 8-way L2 cache cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Xeon(R) CPU E31270 @ 3.40GHz, 3392.30 MHz cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX,NXE,LONG,LAHF cpu4: 256KB 64b/line 8-way L2 cache cpu5 at mainbus0: apid 3 (application processor) cpu5: Intel(R) Xeon(R) CPU E31270 @ 3.40GHz, 3392.30 MHz cpu5: 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,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX,NXE,LONG,LAHF cpu5: 256KB 64b/line 8-way L2 cache cpu6 at mainbus0: apid 5 (application processor) cpu6: Intel(R) Xeon(R) CPU E31270 @ 3.40GHz, 3392.30 MHz cpu6: 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,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX,NXE,LONG,LAHF cpu6: 256KB 64b/line 8-way L2 cache cpu7 at mainbus0: apid 7 (application processor) cpu7: Intel(R) Xeon(R) CPU E31270 @ 3.40GHz, 3392.30 MHz cpu7: 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,PCLMUL,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,XSAVE,AVX,NXE,LONG,LAHF cpu7: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 7 (BR20) acpiprt2 at acpi0: bus 3 (PEX4) acpiprt3 at acpi0: bus 4 (PEX5) acpiprt4 at acpi0: bus 5 (PEX6) acpiprt5 at acpi0: bus 6 (PEX7) acpiprt6 at acpi0: bus 1 (P0P1) acpiprt7 at acpi0: bus -1 (P0P2) acpiprt8 at acpi0: bus -1 (P0P3) acpiprt9 at acpi0: bus -1 (P0P4) acpiprt10 at acpi0: bus 2 (PEX0) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpicpu4 at acpi0: C3, C1, PSS acpicpu5 at acpi0: C3, C1, PSS acpicpu6 at acpi0: C3, C1, PSS acpicpu7 at acpi0: C3, C1, PSS acpibtn0 at acpi0: SLPB acpibtn1 at acpi0: PWRB ipmi at mainbus0 not configured cpu0: Enhanced SpeedStep 3392 MHz: speed
4.9, set reassemble no + block log + fragments = panic
Good evening, the last two days we have experienced panics sequentially across all of our peering boxes. After one day of coffee, thinking and reading, I found this in 4.9. (5.0+ looks good): target49# ifconfig vlan69 vlan69: flags=8843 mtu 1500 lladdr 00:0c:29:38:f3:c5 priority: 0 vlan: 69 priority: 0 parent interface: em1 groups: vlan status: active inet6 fe80::20c:29ff:fe38:f3c5%vlan69 prefixlen 64 scopeid 0x5 inet 192.168.69.49 netmask 0xff00 broadcast 192.168.69.255 target49# cat /etc/pf.conf set skip on lo set reassemble no block in log quick target49# sender51# tcpdump -n -i vlan69 -v tcpdump: listening on vlan69, link-type EN10MB tcpdump: WARNING: compensating for unaligned libpcap packets 20:55:58.958739 192.168.69.1.10562 > 192.168.69.49.1234: udp 2000 (frag 58745:1480@0+) (ttl 64, len 1500) 20:55:58.958745 192.168.69.1 > 192.168.69.49: (frag 58745:528@1480) (ttl 64, len 548) ^C Mar 20 20:57:17 target49 /bsd: uvm_fault(0x80d1b0e0, 0x0, 0, 1) -> e Mar 20 20:57:17 target49 /bsd: fatal page fault in supervisor mode Mar 20 20:57:17 target49 /bsd: trap type 6 code 0 rip 80245557 cs 8 rflags 10246 cr2 0 cpl 5 rsp 8bba0b40 Mar 20 20:57:17 target49 /bsd: panic: trap type 6, code=0, pc=80245557 Mar 20 20:57:17 target49 /bsd: Starting stack trace... Mar 20 20:57:17 target49 /bsd: panic() at panic+0xf5 Mar 20 20:57:17 target49 /bsd: trap() at trap+0x6fd Mar 20 20:57:17 target49 /bsd: --- trap (number 6) --- Mar 20 20:57:17 target49 /bsd: pf_change_ap() at pf_change_ap+0x57 Mar 20 20:57:18 target49 /bsd: pf_translate() at pf_translate+0x27d Mar 20 20:57:18 target49 /bsd: pflog_bpfcopy() at pflog_bpfcopy+0x233 Mar 20 20:57:18 target49 /bsd: bpf_catchpacket() at bpf_catchpacket+0xd8 Mar 20 20:57:18 target49 /bsd: bpf_mtap_pflog() at bpf_mtap_pflog+0x8f Mar 20 20:57:18 target49 /bsd: pflog_packet() at pflog_packet+0x223 Mar 20 20:57:18 target49 /bsd: pf_test_fragment() at pf_test_fragment+0x502 Mar 20 20:57:18 target49 /bsd: pf_test() at pf_test+0x7ef Mar 20 20:57:18 target49 /bsd: ipv4_input() at ipv4_input+0x22a Mar 20 20:57:18 target49 /bsd: ipintr() at ipintr+0x51 Mar 20 20:57:18 target49 /bsd: netintr() at netintr+0xda Mar 20 20:57:18 target49 /bsd: softintr_dispatch() at softintr_dispatch+0x5d Mar 20 20:57:18 target49 /bsd: Xsoftnet() at Xsoftnet+0x28 Mar 20 20:57:18 target49 /bsd: --- interrupt --- Mar 20 20:57:18 target49 /bsd: end of kernel Mar 20 20:57:18 target49 /bsd: end trace frame: 0x6a7, count: 242 Mar 20 20:57:18 target49 /bsd: 0x8: Mar 20 20:57:18 target49 /bsd: End of stack trace. Mar 20 20:57:18 target49 /bsd: End of stack trace. Mar 20 20:57:18 target49 /bsd: dump to dev 4,1 not possible Mar 20 20:57:18 target49 /bsd: rebooting... Ignore the timestamps, the box panics immediately after getting the fragmented packet. I could reproduce it on vmware 4.9-stable with GENERIC/GENERIC.MP, so no dmesg attached. Regards Tony
Re: What generates the OpenBSD page?
John Tate wrote: >Don't enter a logical debate with me. I am not interested. Kinda says it all, don't your think?
Re: Narcicism?
Something about gladly making fools suffer as opposed to gladly suffering fools. Actually they are a lot kinder and gentler than I would be. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of John Tate Sent: Thursday, December 01, 2011 1:28 AM To: misc Subject: Narcicism? I think I've found a bug in the OpenBSD crowd. They bug the hell out of me and my little mistakes. I am not talking about people who actually have a solution, but I can't seem to ask anything on this list without parrots coming along picking on me. I think some people just hang out here because it's the most anal bunch of hackers ever, in recorded history. What are your experiences? Is it true that occasionally we attract people who either love bullying or are just lazy and pretending to be one of the clever? It just figures some of these people sit on the list, and email you poorly researched crap with no answers contain. If you hate a question, it truly doesn't belong, bug me. But if you just can't answer a question, ignore it. John Tate. Note: Yes, it's not my list. -- www.johntate.org
Re: USB WD HDD 1.5Tb read/write for files larger than 2048mb
Vitali wrote: >I had some big movie files, development directories and so on which I ... Vital information missing: File system on the USB drive Guessing: The USB Drive is FAT32 which has a size limit of 2G on individual files
Re: Burning DVDs
You might try reading your own message. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of John Tate Sent: Monday, November 14, 2011 9:19 AM To: Fubar Cc: Richard Toohey; misc Subject: Re: Burning DVDs I have dvd+rw tools and cdrecord still gives me this message... cdrecord: This version of cdrecord does not include DVD-R/DVD-RW support code. cdrecord: If you need DVD-R/DVD-RW support, ask the Author for cdrecord-ProDVD. cdrecord: Free test versions and free keys for personal use are at ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ On Tue, Nov 15, 2011 at 2:04 AM, John Tate wrote: > Make install does nothing in /usr/ports/sysutils/dvd+rw-tools/, and > the ports is the tarball from > ftp://ftp.openbsd.org/pub/OpenBSD/5.0/ports.tar.gz - it does not error > there is simply no output. It does compile. I honestly think something > has been missed. As for my confused posts, well, it happens I'm not > perfect, but it has little baring on anything. > > On Mon, Nov 14, 2011 at 10:49 PM, Rod Whitworth wrote: >> On Mon, 14 22:07:06 +1100, John Tate wrote: >> >>>This has no 'make install' for some odd reason. I clearly should >>>become a packager. >> >> I don't see that happening soon given your confused posts here. >> It seems to be about time you did some learning. >> packages are provided and are installed by using pkg_add(1). They are >> pre-compiled and packaged for you. >> You don't need make install unless you are compiling ports and raw >> beginners are advised to use packages not ports. >> In fact the only people who should be compiling ports are those who are >> 1) competent in the art, 2) are doing it to test patches or upgrades >> reported by maintainers or 3) have the skills in (1) and need to >> upgrade to a published port for some technical reason and who know how >> to make sure that their kernel and userland are recent enough to match >> the new port version. >> >>> >>>On Mon, Nov 14, 2011 at 4:31 PM, Richard Toohey >>> wrote: On 14/11/2011, at 6:13 PM, John Tate wrote: > Device seems to be: Generic mmc2 DVD-R/DVD-RW. > > cdrecord: This version of cdrecord does not include DVD-R/DVD-RW support code. > cdrecord: If you need DVD-R/DVD-RW support, ask the Author for cdrecord-ProDVD. > cdrecord: Free test versions and free keys for personal use are at > ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ > > Apparently this support code has been in cdrtools since 2009, the site > it tells me to go to tells me I don't need it. It's like bureaucracy, > lol. > > I could build their cdrtools, but the port must be ancient or something. > > Perhaps I could become a packager. Another port, gtk-gnutella, isn't > even worth having if its not maintained. > > John Tate. > http://openports.se/sysutils/dvd+rw-tools http://openports.se/search.php?so=dvd >> >> *** NOTE *** Please DO NOT CC me. I subscribed to the list. >> Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. >> >> Rod/ >> --- >> This life is not the real thing. >> It is not even in Beta. >> If it was, then OpenBSD would already have a man page for it. >> >> >> > > > > -- > www.johntate.org > -- www.johntate.org
Re: Burning DVDs
Out of curiosity, WHY should any make install in ports actually DO anything? Seems like the object of ports is to make packages and packages are installed by pkg_add. If you want to be something, say a packager, it helps if you have at least a slight clue what it is all about. -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of John Tate Sent: Monday, November 14, 2011 9:04 AM To: Fubar Cc: Richard Toohey; misc Subject: Re: Burning DVDs Make install does nothing in /usr/ports/sysutils/dvd+rw-tools/, and the ports is the tarball from ftp://ftp.openbsd.org/pub/OpenBSD/5.0/ports.tar.gz - it does not error there is simply no output. It does compile. I honestly think something has been missed. As for my confused posts, well, it happens I'm not perfect, but it has little baring on anything. On Mon, Nov 14, 2011 at 10:49 PM, Rod Whitworth wrote: > On Mon, 14 22:07:06 +1100, John Tate wrote: > >>This has no 'make install' for some odd reason. I clearly should >>become a packager. > > I don't see that happening soon given your confused posts here. > It seems to be about time you did some learning. > packages are provided and are installed by using pkg_add(1). They are > pre-compiled and packaged for you. > You don't need make install unless you are compiling ports and raw > beginners are advised to use packages not ports. > In fact the only people who should be compiling ports are those who are > 1) competent in the art, 2) are doing it to test patches or upgrades > reported by maintainers or 3) have the skills in (1) and need to > upgrade to a published port for some technical reason and who know how > to make sure that their kernel and userland are recent enough to match > the new port version. > >> >>On Mon, Nov 14, 2011 at 4:31 PM, Richard Toohey >> wrote: >>> On 14/11/2011, at 6:13 PM, John Tate wrote: >>> Device seems to be: Generic mmc2 DVD-R/DVD-RW. cdrecord: This version of cdrecord does not include DVD-R/DVD-RW support code. cdrecord: If you need DVD-R/DVD-RW support, ask the Author for cdrecord-ProDVD. cdrecord: Free test versions and free keys for personal use are at ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ Apparently this support code has been in cdrtools since 2009, the site it tells me to go to tells me I don't need it. It's like bureaucracy, lol. I could build their cdrtools, but the port must be ancient or something. Perhaps I could become a packager. Another port, gtk-gnutella, isn't even worth having if its not maintained. John Tate. >>> >>> http://openports.se/sysutils/dvd+rw-tools >>> >>> http://openports.se/search.php?so=dvd >>> > > *** NOTE *** Please DO NOT CC me. I subscribed to the list. > Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. > > Rod/ > --- > This life is not the real thing. > It is not even in Beta. > If it was, then OpenBSD would already have a man page for it. > > > -- www.johntate.org
Re: bgpctl shiw rib out displaying incorrect information
On Fri, Sep 16, 2011 at 2:34 PM, Claudio Jeker wrote: > On Wed, Aug 31, 2011 at 04:37:49PM +0200, Tony Sarendal wrote: > > On Wed, Aug 31, 2011 at 4:24 PM, Josh Hoppes > wrote: > > > > > Why are you using "set nexthop self" and then trying to change that > > > with the filter "allow quick to 172.29.1.52 set nexthop 172.29.1.200". > > > If you don't want your nexthop to be yourself don't tell bgpd to do > > > that. > > > > > > > > To show a bug in bgpctl/bgpd (or where ever it may be). > > Dont you want to be able to trust the information bgpctl gives you ? > > > > Yes there is a bug in bgpd. The problem is that set nexthop self was > sticky and overriding the other set nexthop that came after. > > The following diff should solve those issues. > -- > :wq Claudio > Looks fine when I apply it to the test boxes. Cheers. /Tony
Re: bgpctl shiw rib out displaying incorrect information
On Wed, Aug 31, 2011 at 4:24 PM, Josh Hoppes wrote: > Why are you using "set nexthop self" and then trying to change that > with the filter "allow quick to 172.29.1.52 set nexthop 172.29.1.200". > If you don't want your nexthop to be yourself don't tell bgpd to do > that. > > To show a bug in bgpctl/bgpd (or where ever it may be). Dont you want to be able to trust the information bgpctl gives you ? Regards Tony
Re: bgpctl shiw rib out displaying incorrect information
On Wed, Aug 31, 2011 at 11:01 AM, Andre Keller wrote: > Hi > > Am 31.08.2011 10:23, schrieb Tony Sarendal: > > Sender says next hop = 172.29.1.100, receiver says .51. > > show rib out in this case shows incorrect nexthop. > > Well thats kind of the point of having set nexthop self in the config... > > You are missing the point, completely. bgpctl show rib out displays incorrect information. Regards Tony
Re: bgpctl shiw rib out displaying incorrect information
On Wed, Aug 31, 2011 at 9:51 AM, Patrick Lamaiziere wrote: > Le Wed, 31 Aug 2011 07:19:15 +0200, > Tony Sarendal a icrit : > > Hi, > > > current1# cat /etc/bgpd.conf > > AS 65001 > > network 10.0.1.0/24 > > > > current1# bgpctl show rib nei 172.29.1.52 out > > flags: * = Valid, > = Selected, I = via IBGP, A = Announced > > origin: i = IGP, e = EGP, ? = Incomplete > > > > flags destination gateway lpref med aspath origin > > AI*> 10.0.1.0/24 172.29.1.200 100 0 i > > So you announce (A) via IBGP (I) the route 10.0.1.0/24, looks good no?. > > > current2# bgpctl show rib nei 172.29.1.51 in > > flags: * = Valid, > = Selected, I = via IBGP, A = Announced > > origin: i = IGP, e = EGP, ? = Incomplete > > > > flags destination gateway lpref med aspath origin > > I*> 10.0.1.0/24 172.29.1.51100 0 i > > And you receive the route via IBGP (I), looks good too. > > Where is the problem? > Sender says next hop = 172.29.1.100, receiver says .51. show rib out in this case shows incorrect nexthop. Regards Tony
bgpctl shiw rib out displaying incorrect information
current1# cat /etc/bgpd.conf
AS 65001
network 10.0.1.0/24
neighbor 172.29.1.52 {
remote-as 65001
set nexthop self
descr "current2"
local-address 172.29.1.51
}
allow quick to 172.29.1.52 set nexthop 172.29.1.200
allow to any
allow from any
current1# bgpctl show rib nei 172.29.1.52 out
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
AI*> 10.0.1.0/24 172.29.1.200 100 0 i
current1#
current2# bgpctl show rib nei 172.29.1.51 in
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i = IGP, e = EGP, ? = Incomplete
flags destination gateway lpref med aspath origin
I*> 10.0.1.0/24 172.29.1.51100 0 i
current2#
current2# cat /etc/bgpd.conf
AS 65001
network 10.0.2.0/24
neighbor 172.29.1.51 {
remote-as 65001
set nexthop self
local-address 172.29.1.52
descr "current1"
}
allow to any
allow from any
Tested on -current, see the same on 4.9.
Regards Tony
Re: Apache Killer - Does it affect OpenBSD's patched version of Apache?
frantisek holop wrote: >but for me it's really time to move on. Bye.
Re: isakmpd and INVALID_COOKIE
On Fri, Jul 8, 2011 at 4:09 PM, Stuart Henderson wrote: > On 2011-07-08, Tony Sarendal wrote: > >> > If you're running isakmpd from 4.8 or 4.9 with IKE you want to pull > >> > up src/sbin/isakmpd/dh.c to r1.14 otherwise you will certainly > >> > see problems from time to time. > >> > > > > Is this a cosmetic thing or does it affect connectivity ? > > dh.c r1.14 affects stability. Between 4.7 and 4.8 isakmpd switched > from internal to openssl DH; an openssl function wasn't padding with > leading 0's where it was expected that they would, so there was junk > at the end of the key, causing key mismatches. > Sounds like a candidate to our issues that we are seeing on both 4.8 and 4.9. We see it quite easily as we run gre tunnels with bgp inside them using ipsec to encrypt gre. We are seeing the connectivity issue antyhing from a few times a day to a few times a week. And the time I caught it while it was going on things started working immediately after some bi-directional ike traffic. Regards Tony
Re: isakmpd and INVALID_COOKIE
On Mon, Jul 4, 2011 at 4:12 PM, rancor wrote: > Ah =) Thanks! > > // rancor > > 2011/7/4 Stuart Henderson : > > On 2011-07-02, rancor wrote: > >> Hi. > >> > >> I have two separate ipsec tunnels from 4.9 boxes and both are > >> generating this message i /var/log/messages once every hour or two > >> Jul 2 08:14:54 isakmpd[28247]: message_recv: invalid > >> cookie(s) 57603c2 > >> Jul 2 08:14:54 isakmpd[28247]: dropped message from > >> x.x.x.x port 500 due to notification type INVALID_COOKIE > >> > >> The tunnels works perfect but I still wounder why I got this message. > >> > >> This is my ipsec.conf on host x > >> ike esp transport from x.x.x.x to y.y.y.y psk > >> > >> and on host y > >> ike esp transport from y.y.y.y to x.x.x.x psk > >> > >> Any idea? > >> > >> Best regards rancor > >> > >> > > > > If you're running isakmpd from 4.8 or 4.9 with IKE you want to pull > > up src/sbin/isakmpd/dh.c to r1.14 otherwise you will certainly > > see problems from time to time. > Is this a cosmetic thing or does it affect connectivity ? We are having issues with gaps in connectivity on our ipsec links with a basic ike setup, an issue we're starting to look into now. Regards Tony
Re: I don't get where the load comes from
Joel Carnat wrote: >But one thing that didn't convinced me is that, if I shutdown apmd and >configure hw.setperf=100, the load drops down to 0.30-0.20. >I don't get how "A high load is just that: high. It means you have a lot >of processes that sometimes run." can show load variation depending on >CPU speed only. Actually that should convince you that the numbers do not mean much. You are measuring the difference between just barely being counted and just barely not being counted.
Re: I don't get where the load comes from
Joel Carnat wrote >well, compared to my previous box, running NetBSD/xen, the same services >and showing about 0.3-0.6 of load ; I thought a load of 1.21 was quite much. Different systems will agree on the spelling of the word load. That is about as much agreement as you can expect. Does the 0.3-0.6 really mean 30-60 percent loaded? 1.21 tasks seems kinda low for a multi-tasking system.
Re: MAXDSIZ
Thank you very much for the feedback. Is that related to the following: --- Provided a bus_dmamap_sync() implementation for the amd64 IOMMU. It fixes bigmem. --- from: http://www.openbsd.org/plus49.html Thanks On Mon, Apr 4, 2011 at 8:53 AM, Janne Johansson wrote: > I guess someone listened to you. > > http://marc.info/?l=openbsd-cvs&m=130176586700354&w=2 > > Next step: > http://www.openbsd.org/faq/faq5.html > > > 2011/3/30 Tony Berth > >> Thank you for that clarification >> >> >> On Wed, Mar 30, 2011 at 2:52 PM, Janne Johansson wrote: >> >>> >>> >>> 2011/3/30 Tony Berth >>> >>>> which translates that the physical 4G limitation is still in place? >>>> >>> >>> Yes, as shown by the 2nd or third line in the dmesg while booting, >>> somewhere close to 3.5-4G is used only. The MAXDSIZ is how much virtual >>> memory an app may eat, swap included. >>> >>> >>> -- >>> To our sweethearts and wives. May they never meet. -- 19th century >>> toast >>> >> >> > > > -- > To our sweethearts and wives. May they never meet. -- 19th century toast
Re: MAXDSIZ
I can't??? So the limit of 4G physical memory still exists? And why was this statement made from 4.4 release? Thanks On Wed, Mar 30, 2011 at 12:39 PM, Janne Johansson wrote: > > > 2011/3/30 Tony Berth > >> currently not but this machine will be a DB server (Postgresql + Mysql) >> and >> it was aksed if we could go beyond the 8G. >> >> In any case, for now, if I can address 8G physical memory is fine. >> >> > ..which you cant. > > > -- > To our sweethearts and wives. May they never meet. -- 19th century toast
Re: MAXDSIZ
currently not but this machine will be a DB server (Postgresql + Mysql) and it was aksed if we could go beyond the 8G. In any case, for now, if I can address 8G physical memory is fine. Thanks for your feedback Tony On Mon, Mar 28, 2011 at 6:59 PM, Ted Unangst wrote: > No, are you having a problem with 8GB? > > On Mar 28, 2011, at 8:59 AM, Tony Berth wrote: > > > Dear OBSD list members, > > > > in the meanwhile, are any changes to the following: > > > > ... > > Make amd64 machines be able to use more than 4G ram, and crank the > MAXDSIZ > > to allow allocations/mmap() up to 8G. > > ... > > > > as this was reported on: > > > > ... > > http://www.openbsd.org/plus44.html > > ... > > > > For example to extend it, let's say, to 16GB? > > > > Thanks > > > > Tony
MAXDSIZ
Dear OBSD list members, in the meanwhile, are any changes to the following: ... Make amd64 machines be able to use more than 4G ram, and crank the MAXDSIZ to allow allocations/mmap() up to 8G. ... as this was reported on: ... http://www.openbsd.org/plus44.html ... For example to extend it, let's say, to 16GB? Thanks Tony
Re: is SHA256 file used or not ?
Methinks this project is somehow about good code, not good moods. > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Mihai Popescu > Sent: Tuesday, February 08, 2011 9:19 AM > To: misc > Subject: Re: is SHA256 file used or not ? > > Hi Henning, > > It looks like you are in a bad mood. Please read my entire post and > don't cut and paste out of context. > Man, if you do not want to answer, please don't. You have spent a lot > of time bitching and no time to give a damn clear answer. > It's not my problem that you attract idiots ( I failed to see who are > "we" from "we keep attracting idiots..."). Maybe you should read about > how a documentation can or cannot help. > > Hapilly, Otto and Philip did participate with good answers.
Re: Dynamic web hosting and OpenBSD
Marcos Laufer wrote > > Is this a prank message? > starting my very own Obviously I take security seriously, and therefore will be using OpenBSD exclusively. One thing is bothering me though. I hope you friendly folks would help me. ---to quote a rabbit "He don't know me do he?"
Re: nfsv4?
Benny LC6fgren wrote: > Oh come on, surely you can't fail to realize that there are actually > benefits to having all your data on one place, always? Especially if > you > have an environment where you might need to access it from several > different platforms. > > Not only in terms of user friendliness but also to avoid the problem of > having to cope with several versions of the same data, or even the > problem of the data producer and consumer not being the same. And those > were just some examples where a central networked file system comes in > really handy. > If I have an enemy I REALLY want him to bunch everything up. Makes a much more convenient target.
Re: redistributing routes
On Sat, Oct 23, 2010 at 8:45 PM, Tony Sarendal wrote: > > > On Sat, Oct 23, 2010 at 8:02 PM, Henning Brauer wrote: > >> * Tony Sarendal [2010-10-23 19:03]: >> > How does OpenBSD handle the same prefix being in both bgpd and ospfd ? >> >> in general? OSPF routes have priority over BGP routes. that's >> implemented kernel routing table side and the daemons setting the >> priority field to their respective priorities when inserting their >> routes. >> >> > Does this mean that bgpd and ospfd can happily co-exist on the same box ? > > As an example: > Prefix A shows up in BGP, later it shows up in OSPF, > even later it is withdrawn from OSPF. Will the prefix in BGP now be in the > fib ? > > OSPF being the winner is not optimal in my case, but being predictable > is good enough. > > > I connect devices to the core network using two core routers and >> > redistributing >> > BGP->OSPF would be happening on both of them. >> >> that I dunno OTOH >> >> > Being able to redist BGP->OSPF and not connecting ospfd to the fib would > do what I want. Unfortunately the manpage for ospfd.conf doesn't seem to > support > this setup. > > fib-update (yes|no) > If set to no, do not update the Forwarding Information Base, > a.k.a. the kernel routing table. The default is yes. Setting > fib-update to no will implicitly set the stub router option to > ensure that no traffic tries to transit via this router. > > I mean this would do what I want if bgpd and ospfd can't co-exist. Regards Tony
Re: redistributing routes
On Sat, Oct 23, 2010 at 8:02 PM, Henning Brauer wrote:
> * Tony Sarendal [2010-10-23 19:03]:
> > How does OpenBSD handle the same prefix being in both bgpd and ospfd ?
>
> in general? OSPF routes have priority over BGP routes. that's
> implemented kernel routing table side and the daemons setting the
> priority field to their respective priorities when inserting their
> routes.
>
>
Does this mean that bgpd and ospfd can happily co-exist on the same box ?
As an example:
Prefix A shows up in BGP, later it shows up in OSPF,
even later it is withdrawn from OSPF. Will the prefix in BGP now be in the
fib ?
OSPF being the winner is not optimal in my case, but being predictable
is good enough.
> I connect devices to the core network using two core routers and
> > redistributing
> > BGP->OSPF would be happening on both of them.
>
> that I dunno OTOH
>
>
Being able to redist BGP->OSPF and not connecting ospfd to the fib would
do what I want. Unfortunately the manpage for ospfd.conf doesn't seem to
support
this setup.
fib-update (yes|no)
If set to no, do not update the Forwarding Information Base,
a.k.a. the kernel routing table. The default is yes. Setting
fib-update to no will implicitly set the stub router option to
ensure that no traffic tries to transit via this router.
Regards Tony
Re: redistributing routes
On Sat, Oct 23, 2010 at 6:16 PM, Stuart Henderson wrote: > On 2010-10-23, Tony Sarendal wrote: > > rtlabel label > > Add the prefix with the specified label to the kernel > routing > > table. > > I think this should be: > > Add the prefix to the kernel routing table with the specified label. > > Index: bgpd.conf.5 > === > RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v > retrieving revision 1.112 > diff -u -p -r1.112 bgpd.conf.5 > --- bgpd.conf.5 13 Oct 2010 21:04:13 - 1.112 > +++ bgpd.conf.5 23 Oct 2010 16:12:36 - > @@ -1432,9 +1432,9 @@ times to the > .Em AS path . > .Pp > .It Ic rtlabel Ar label > -Add the prefix with the specified > -.Ar label > -to the kernel routing table. > +Add the prefix to the kernel routing table > +with the specified > +.Ar label . > .Pp > .It Ic weight Ar number > The > > > ...maybe we could also add something like, "Can be used to > redistribute routes to another routing protocol daemon", > or maybe we should leave that for people to figure out themselves. > > How does OpenBSD handle the same prefix being in both bgpd and ospfd ? I connect devices to the core network using two core routers and redistributing BGP->OSPF would be happening on both of them. Regards Tony
Re: redistributing routes
On Sat, Oct 23, 2010 at 3:07 PM, Henning Brauer wrote: > * Tony Sarendal [2010-10-23 14:29]: > > rtlabel label > > Add the prefix with the specified label to the kernel > routing > > table. > > > > Is this an error in the page or me reading it wrong ? > > debatable... this could be worded better. with rtlabel foo, bgpd will > add the label foo to all routes it inserts. > > > If this works as expected, is this the recommended way of doing it ? > > i don't see anything wrong with that approach. > > Very good. Thanks. Regards Tony
Re: redistributing routes
On Sat, Oct 23, 2010 at 2:05 PM, Insan Praja SW wrote: > Hi Tony, > > On Sat, 23 Oct 2010 18:44:46 +0700, Tony Sarendal > wrote: > > Is there a way to redistribute routes from BGP to OSPF using bgpd and ospfd >> ? >> >> > on bgpd.conf you might want to do this: > > match from $peer1 inet prefix xxx.xxx.xxx.xxx/xx prefixlen bla_bla set > rtlabel from_bgpd > > on ospfd.conf you do this: > > redistribute rtlabel from_bgpd > > > I have a network where the core concists of openbsd devices using bgpd to >> distribute >> routing information. At present we need to use static routing if we >> connect >> devices that >> do not support BGP. >> >> Regards Tony >> >> > Good Luck, > I was considering an approach like that, but the bgpd man page suggests that it wouldnt work. ATTRIBUTE SET AS path attributes can be modified with set. set can be used on network statements, in neighbor or group blocks, and on filter rules. Attribute sets can be expressed as lists. The following attributes can be modified: ... rtlabel label Add the prefix with the specified label to the kernel routing table. Is this an error in the page or me reading it wrong ? If this works as expected, is this the recommended way of doing it ? Regards Tony
redistributing routes
Is there a way to redistribute routes from BGP to OSPF using bgpd and ospfd ? I have a network where the core concists of openbsd devices using bgpd to distribute routing information. At present we need to use static routing if we connect devices that do not support BGP. Regards Tony
Re: i386 and amd64 snapshots - kernel SHA256 mismatch
Frank Bax wrote: > > Marco Peereboom wrote: > > On Sat, Oct 16, 2010 at 01:08:25AM +, JC Choisy wrote: > >> That being out of the way, you got me wondering what good is > >> any integrity check which failure is OK. > > > > It is only meant to help uptight people having some sort of false > sense > > of integrity/security. It really is for release only because > snapshots > > are a moving target. In my opinion the whole check is a giant waste > of > > time because every damn time the snaps are out of sync for a reason > or > > another people come whining to the list about something that is > > irrelevant. > > > Am I correct in assuming that the code before this integrity check is > not able to distinguish between release and snapshot? Imagine the fun&games when the snapshots work and the release does not. Do people bother to think anymore?
Re: undeadly article
Personally, I liked the article. Small change in perspective changes an ordeal into an adventure. Jacob Meuser wrote: > On Wed, Aug 18, 2010 at 04:28:57PM +0300, Mihai Popescu B.S. wrote: > > Hello, > > > > My post was not intended as a direct hit for the article. I told my > > opinion to misc@ because undeadly ask for subscription, no more > > anonymous coward post. Am I wrong ? > > > > I target airport behaviour with my comment. I use the airport for 6 > > flight until now, no problem at all with security teams. I was quick > > and polite in answers and the time with them was short. Most of them > > have the "nose" to see what they are dealing with. > > bullshit. sorry, but that is not true. "Smart" security will inevitably outsmart itself. Add respect to polite in the brew. He inspects you. You inspect him. You respect each other. Works better. > > I regularly get picked on by "authority", but it's alwasy just been > a pointless hassle. I'll never forget the time a cop stopped me > in my own neighborhood, in the rain, for walking against a signal, > when his car was the only moving vehicle within a half mile. the > best part was when he dropped his papers in a puddle. > > > If you start > > playing, they will answer accordingly, not because you look like a > > suspect, it is more like an answer. > > the only playing was their own game. after all, it is they who > choose to start the games. If they are wasting your time they will keep it up. If you are wasting their time they will drop you in a hurry. The best tactic is when you are obviously suppressing a laugh. > > > Have fun ! (but not in sensible areas). > > but see, if authority can't take that you're laughing because their > questions and assumptions *really are* ridiculous ... > > the lady in the office where jcr was "held" when we met him was > in charge of the place. and it's clear why she was in charge. > she was sharp and no-nonsense. of course, you want such people > in charge of such places. > > even after we got out of that office I still had to deal with > another person who inspected my bags. with this uy though, I > shared a good laugh, even though he was pretty thorough. Watch how a person laughs. Even more a window into the soul than the eyes. Customs tends to be sharper than security. They probably do have a sense of humor, but it is never shared with "outsiders". > > -- > jake...@sdf.lonestar.org > SDF Public Access UNIX System - http://sdf.lonestar.org
Re: mount ffs as msdos, system hangs
frantisek holop wrote: > my "whining", is a comparison of experiences with others, > questions if someone can reproduce a particular problem > i am having, whether it is considered a problem at all, > and so on. a practice i thought about as the first step > of bug reporting and as such a perfectly valid subject > for a mailing list of this type. me and my assumptions. The responses to your whining indicate otherwise. > i dont understand why some people take problems reported > so personally, as if a personal attack, and/or also > interpreting it as a demand for an instant fix or > i dont know what. it is not, wake up please. Methinks you misinterpret who is being attacked. According to your interpretation, what was your purpose, if any, in your postings? > as for "go read the sources" every time there is a problem, > even the developers are not familiar on the source level > with every single part of the kernel and the system. > they will go and ask the guy who knows it the best. > i dont get it why is it expected of us, the users. However those developers are not only capable of reading some of the source, they have WRITTEN some of it.
Re: mount ffs as msdos, system hangs
frantisek holop wrote: > to know the road ahead, ask those coming back. You mean the ones who like it so much they travel it twice?
Re: mount ffs as msdos, system hangs
frantisek holop wrote: > the borderline between the useful and useless error checking > is sometimes a bit fuzzy i think. Not THAT fuzzy. Foreign file systems NEVER get prime attention. When you do stupid things the results are rather predictable and you compound your error by trying to blame everybody else for your own singular lack of sanity.
Re: Hardware Spec Search Engine?
Christian Weisgerber wrote: > > Somewhat embarrassingly, OpenBSD has never had a working Firewire > implementation. > As I understand it, only the malware writers are embarrassed. You don't need a back door when the front door is missing. Any time all of system memory is open to Read/Write access by hardware (with the assist of local BIOSes etc), ...
Re: PTY allocation error
Nick Holland wrote: > > On 07/12/10 03:11, czark...@gmail.com wrote: > ... > > This is not about Theo personally, it's about everyone in this > thread. > > > > Peter did't pretend to get a custommer support, neither he said > someone is > > obliged to answer his question. He simply wanted someone familiar > with pty > > allocation to give him an advice. > > They did, "don't do this". > > > If you don't want or don't know how to help him, why just not ignore > the > > message? > > Why do you think saying "don't do this" is not helping him? It is > certainly more productive than helping him continue down his wrong > path. > > Nick. The most UNFRIENDLY thing anyone can do to me is to help me persist in some momentary delusion that cannot lead to anything worthwhile.
Re: Silent boot?
Eric S Pulley wrote: ... and I hate systems that hide that information from me, but that's just me. Nope. Not just you. A system that hides stuff has to be an order of magnitude more correct just to break even.
wd0i: device fault reading fsbn ...
Hi, dmesg keeps displaying following entry: wd0i: device fault reading fsbn 4146624 of 4146624-4146655 (wd0 bn 85997799; cn 5353 tn 29 sn 27), retrying pciide1:0:0: recal drive fault there are 2 IDE HDs connected. Should I derive that the HD is dead? Thanks
Re: 1 out of 3 hunks failed--saving rejects to kerberosV/src/lib/krb5/crypto.c.rej
Ingo Schwarze wrote: > > Hi Tony, > > Tony Berth wrote on Mon, Jun 21, 2010 at 08:11:31PM +0200: > > > but FAQ5 is about 'Building the System from Source' which I don't > want! > > I just want to patch an existing system! > > http://www.openbsd.org/faq/faq10.html#Patches > > Note that this one doesn't talk about cvs checkout at all, > but recommends different ways to get the RELEASE sources. > > > Instead of > > '# cd /usr; cvs checkout -P -rOPENBSD_4_7 src' > > I applied > > '# cd /usr; cvs checkout -P src' > > in order to get the current tree but patch001 still gives the same > error! > > None of these is RELEASE. > > If you want to understand what these two commands do, follow Nick's > advice > and read FAQ 5. Granted, that's not required for patching your system, > but > maybe you want to understand what you are doing and why it fails... > > Sometimes, it *is* useful to read a bit more than the bare minimum > required to type the right commands, in order to be able to understand > your own errors and become able to help yourself. > > Yours, > Ingo Maybe I'm just being dense, but HOW can you patch a system without "building from source"? ... unless you have binary patches for all the architectures and that gets much more complicated if you have combinations of patches ...
Re: 1 out of 3 hunks failed--saving rejects to kerberosV/src/lib/krb5/crypto.c.rej
but FAQ5 is about 'Building the System from Source' which I don't want! I just want to patch an existing system! Instead of '# cd /usr; cvs checkout -P -rOPENBSD_4_7 src' I applied '# cd /usr; cvs checkout -P src' in order to get the current tree but patch001 still gives the same error! On Mon, Jun 21, 2010 at 5:12 PM, Nick Holland wrote: > Tony Berth wrote: > >> did the following: >> >> after navigating to: http://openbsd.org/anoncvs.html#starting >> >> applied: >> >> # *cd /usr; cvs checkout -P -rOPENBSD_4_7 src* >> > ... > now, as I suggested, go read FAQ5 and find out what this does. > > (and yes, I guessed right. :) > > Nick.
Re: 1 out of 3 hunks failed--saving rejects to kerberosV/src/lib/krb5/crypto.c.rej
did the following: after navigating to: http://openbsd.org/anoncvs.html#starting applied: # *cd /usr; cvs checkout -P -rOPENBSD_4_7 src* using *cvsroot=anon...@anoncvs.fr.openbsd.org:/cvs* Then downloaded: ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.7.tar.gz and applied: cd /usr/src patch -p0 < 001_kerberos.patch as referred in: ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.7/common/001_kerberos.patch Thanks Tony On Sat, Jun 19, 2010 at 6:40 AM, Nick Holland wrote: > On 06/18/10 09:42, Tony Berth wrote: > > when trying to patch a new i386 installation with the first patch I get > the > > following: > ... > > Patching file kerberosV/src/lib/krb5/crypto.c using Plan A... > > Hunk #1 succeeded at 3463 (offset 12 lines). > > Hunk #2 failed at 3543. > > Hunk #3 succeeded at 3607 (offset 7 lines). > > 1 out of 3 hunks failed--saving rejects to > > kerberosV/src/lib/krb5/crypto.c.rej > > done > > you did something wrong. > You didn't tell us what you did, so that's the most I can^Wwill say. > For giggles, I just tested it against the 4.7 source, and (surprise!) > it worked just fine. > > So, start with faq5, starting at the top, and work your way through at > least to 5.4 (10.15 would be a good read after 5.1-5.4) and see if you > can find what variation from the proper process that you felt was > harmless or what command you typed in blindly without understanding > what it meant and how it interacted with other things. > > (and yes, I have a pretty good idea what you did, and understanding > faq5.html will set you straight. Assuming you can pick and chose > which parts you read is how you got in trouble. It is a dense read, > but pretty important to understanding what you were trying to do here. > It is worth the time to understand...) > > Nick. > > /nfs1/test $ patch -p0 <001_kerberos.patch > Hmm... Looks like a unified diff to me... > The text leading up to this was: > -- > |Apply by doing: > | cd /usr/src > | patch -p0 < 001_kerberos.patch > | > |Rebuild and install the Kerberos 5 library: > | cd lib/libkrb5 > | make obj > | make depend > | make > | make install > | > |And then rebuild and install the Kerberos 5 KDC: > | cd ../../kerberosV/libexec/kdc > | make obj > | make depend > | make > | make install > | > | > |Index: kerberosV/src/lib/krb5/crypto.c > |=== > |RCS file: /cvs/src/kerberosV/src/lib/krb5/crypto.c,v > |retrieving revision 1.10 > |diff -p -u -p -u -r1.10 crypto.c > |--- kerberosV/src/lib/krb5/crypto.c6 Oct 2006 07:09:10 - > 1.10 > |+++ kerberosV/src/lib/krb5/crypto.c30 Mar 2010 17:17:43 - > -- > Patching file kerberosV/src/lib/krb5/crypto.c using Plan A... > Hunk #1 succeeded at 3451. > Hunk #2 succeeded at 3531. > Hunk #3 succeeded at 3600. > done
1 out of 3 hunks failed--saving rejects to kerberosV/src/lib/krb5/crypto.c.rej
when trying to patch a new i386 installation with the first patch I get the following: # patch -p0 < 001_kerberos.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Apply by doing: | cd /usr/src | patch -p0 < 001_kerberos.patch | |Rebuild and install the Kerberos 5 library: | cd lib/libkrb5 | make obj | make depend | make | make install | |And then rebuild and install the Kerberos 5 KDC: | cd ../../kerberosV/libexec/kdc | make obj | make depend | make | make install | | |Index: kerberosV/src/lib/krb5/crypto.c |=== |RCS file: /cvs/src/kerberosV/src/lib/krb5/crypto.c,v |retrieving revision 1.10 |diff -p -u -p -u -r1.10 crypto.c |--- kerberosV/src/lib/krb5/crypto.c6 Oct 2006 07:09:10 - 1.10 |+++ kerberosV/src/lib/krb5/crypto.c30 Mar 2010 17:17:43 - -- Patching file kerberosV/src/lib/krb5/crypto.c using Plan A... Hunk #1 succeeded at 3463 (offset 12 lines). Hunk #2 failed at 3543. Hunk #3 succeeded at 3607 (offset 7 lines). 1 out of 3 hunks failed--saving rejects to kerberosV/src/lib/krb5/crypto.c.rej done - Thanks Tony
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
Jacob Meuser wrote: we have users that say they follow the install and upgrade guides to the letter and they get fucked. there is a problem. they don't even know /usr/obj exists. What they say. What they did. Two different things. There's lots of things they do not know about. I fail to understand why it is important to warn them about /usr/obj and not warn them about /usr/src. Surely there's lots of other things they need to be warned about. Enough warnings and you might even attain Microsoft Windows.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
Jacob Meuser wrote: On Sat, Jun 05, 2010 at 05:13:19AM -0400, Tony Abernethy wrote: > All I need to break any automated system you devise is to have some programs that I compile myself and use the system directories to hold the sources etc. > then you are on your own, not someone who is "just following the directions". you'd know that it doesn't apply to you. but whatever. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org --- It is essential that I understand the difference. (Although I have some difficulty in understanding how anybody could possibly actually be "just following the directions".) As soon as I depart from the directions, everything downstream is my responsibility. The developers are not and can not be responsible for guessing what I have or have not squirreled away wherever. On this silly thread, the upgrade did actually function as it should. Some unmentioned stuff AFTER the upgrade put things in the state BEFORE the upgrade. I can imagine scenarios where that is EXACTLY the results I would want, but that was not the case for this silly thread. For this silly thread, there is nothing that I see in the OpenBSD system that needs any fixing. (but some people who know better may/will disagree) Until and unless selecting "all" also gets the sources, I must assume that setting up the system for following -stable is a separate process.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
Jacob Meuser wrote: On Sat, Jun 05, 2010 at 01:49:46AM -0400, Tony Abernethy wrote: > Jacob Meuser wrote: > ... > > > On 5/06/2010, at 7:31 AM, Nick Holland wrote: > a patch to the upgrade guide would be wrong. > The problem is the patching process (a special case of the userland build > process) assumes a clean obj dir. This has nothing to do with upgrades. If > you try to rebuild the same userland utility more than once for /any/ > reason without clearing the obj dir, you can run into problems. Clearing > the obj directory as part of the upgrade is like flushing your toilet based > on the date -- may help, but after a while, things start to stink. It isn't > the general (or proper) solution. > > > I'm still curious how anything left in /usr/obj can be anything > > but a possible problem after updating system binaries and sources > > to a new release. especially for people who are just "following > > the directions as they are written." > > > > -- > > jake...@sdf.lonestar.org > > SDF Public Access UNIX System - http://sdf.lonestar.org > > ANYTHING left in /usr/obj will be a possible problem. > ANYTHING left ANYWHERE will be a possible problem anytime anything assumes > (or has/likes to assume) that it is working with a clean slate. > "Fixing" minor problems (and bending everything else out of shape) > does NOT make for better systems. > For me, I prefer things (upgrade/update/whatever) that do as little > collateral damage as possible. (And anytime you want/need to find out > what went wrong you do NOT clean up everything first.) so Tony, tell me, how does 'rm -rf /usr/obj/*', after installing new binaries and new sources code (from a tarball - not an insignificant part of the issue, and exactly what the directions say to do) create collateral damage? you're already past the point of no return anyway, right? maybe I worded it wrongly but that's what I'm asking. is telling people to 'rm -rf /usr/obj/*' after they have completed the update really a necessary part of the upgrade process. no. but I bet if it would say that in the upgrade guide, this stupid thread would never have happened. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org >-- Ok, my take on this mess. If not this stupid thread, then some other stupid thread. You do not 'rm -rf /usr/obj/*' AFTER the update. You do the 'rm -rf /usr/obj/*' BEFORE you stick strange stuff into /usr/obj. Collateral damage is anything that gets in the way of finding out exactly what is or exactly what happened. This whole mess seems to be because some unstated something AFTER the update was claimed to be as a result of the update. How often should /tmp be obliterated? When you say "after installing new sources", what exactly is left on the system? The new sources presumably are there, but what else is there and does it matter? The answer requires a directory listing of everything on the system that did not come from the new sources. Anything short of that and you cannot state what it is that you did. All I need to break any automated system you devise is to have some programs that I compile myself and use the system directories to hold the sources etc.
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
IF YOU DON'T KNOW WHAT YOUR ARE DOING, INSTALL A NEW SNAPSHOT Theo de Raadt wrote: > > Miod, Dale, Kurt, Kettenis and I am quite often the first people to > deal with bumping systems forward over bumps. Some bumps are so > difficult that after they are done the rest of us jump over them using > snapshots. When they happen, WE -- THE DEVELOPERS -- USE THE > SNAPSHOTS! They happen in lots of releases. Why would we use > snapshots, because we are stupid? Or are we smart enough to not waste > our time doing things the hard way? > IF YOU DON'T KNOW WHAT YOUR ARE DOING, INSTALL A NEW SNAPSHOT (Me, I never know what I am doing, but he KNOWS what he's talking about)
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
Jacob Meuser wrote: ... > > On 5/06/2010, at 7:31 AM, Nick Holland wrote: a patch to the upgrade guide would be wrong. The problem is the patching process (a special case of the userland build process) assumes a clean obj dir. This has nothing to do with upgrades. If you try to rebuild the same userland utility more than once for /any/ reason without clearing the obj dir, you can run into problems. Clearing the obj directory as part of the upgrade is like flushing your toilet based on the date -- may help, but after a while, things start to stink. It isn't the general (or proper) solution. > I'm still curious how anything left in /usr/obj can be anything > but a possible problem after updating system binaries and sources > to a new release. especially for people who are just "following > the directions as they are written." > > -- > jake...@sdf.lonestar.org > SDF Public Access UNIX System - http://sdf.lonestar.org ANYTHING left in /usr/obj will be a possible problem. ANYTHING left ANYWHERE will be a possible problem anytime anything assumes (or has/likes to assume) that it is working with a clean slate. "Fixing" minor problems (and bending everything else out of shape) does NOT make for better systems. For me, I prefer things (upgrade/update/whatever) that do as little collateral damage as possible. (And anytime you want/need to find out what went wrong you do NOT clean up everything first.)
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
patrick keshishian wrote: > > On Fri, Jun 4, 2010 at 7:49 PM, Jacob Meuser > wrote: > > I'm still curious how anything left in /usr/obj can be anything > > but a possible problem after updating system binaries and sources > > to a new release. especially for people who are just "following > > the directions as they are written." > > Do you not agree barring broken makefiles and unreliable system clock > (as someone pointed out), object files and binaries (in obj/) should > have been rebuilt? > > --patrick ?? odds that OP found a bad date and "fixed" it (silently) ??
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
Might be better to read and comprehend ``man patch'' before assuming limitations on the scope of patch's reach. > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Uwe Dippel > Sent: Friday, June 04, 2010 11:23 AM > To: misc@openbsd.org > Subject: Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade > base47, on i386 and amd64 > > Jacob Meuser sdf.lonestar.org> writes: > > > oh good grief. you had a dirty /usr/obj. > > > > just look at the pfctl snippet of the log you posted. do you see > pfctl > > being built? do you see pfctl being installed from /usr/obj? > > Oh, yes. So the blame is on my side, I guess. Mea culpa maxima! > I didn't know that the object directories need to be cleaned manually. > Until > yesterday, I would have taken a bet that the object directories lie > within the > source trees (/usr/xenocaram /usr/src), and be cleaned when cleaning > the > sources. Now I am aware that I need to know the location of the object > directories and clean them manually. > I was totally unaware that, in case of a patch, the installer would > take the > next best file of the correct name from there; irrespective of the > underlying > version. > Though I feel in good company. I guess, a great number of people on > this list > were in a similar situation. Knowing the 'social contract' of OpenBSD, > I only > have to blame myself for ignorance. > Still, may I suggest, that the next Upgrade Guide gets an extra line, > with a > remark pointing out the existence of /usr/obj; and the suggestion to > clean it? > Also, with respect to the 'errata', the patches, they describe in > detail what > needs to be done. Maybe here, it could as well be suggested, that > before > applying the first patch of a new version of OpenBSD, /usr/obj should > be > cleaned, or be verified to be clean? > > Thanks for the various people who helped me patiently at analysing this > problem > to the very end! > > Uwe
Re: Installer bug? - Upgrade 4.6 to 4.7 failed to upgrade base47, on i386 and amd64
Uwe Dippel wrote: > drill it down to some 70 files being of the previous > version. > It might be tiring, but what evidence do you want? The error message(s) you are suppressing (or maybe didn't see) About the only way you can get some files but not all files from a tarball is some fatal error in the extraction of the tarball. Any such error tends to give an error message. I don't think this list likes to play guessing games as to exactly what mistakes you have made or what evidence you are suppressing.
Re: traffic management
Why? (There, I said it.) -Original Message- From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of irix Sent: Tuesday, June 01, 2010 7:38 PM To: misc@openbsd.org Subject: Re: traffic management Hello Misc, But at least you can say why? >no kidding. As we've told "irix" before, it will not happen. -- Best regards, irix mailto:i...@ukr.net
BUYcott not Boycott Arizona
Greetings Are you in support of Arizona and its Laws? How about BUYcotting Arizona? DO NOT mistake this for a boycott! We are running a website http://www.arizonabuycott.com and would appreciate your participation as we will be creating a budget for a distinctive ONE TIME mailing directly to travel agents throughout the USA over 5,000 copies. This additionally to the 60,000 we will print, distribution date 7/1/2010. Businesses can create a free listing or enhance their listing for as little as $29. Individuals are invited to post their comments and support on the âVoice Your Opinionsâ page. Links below you will see to the degree that we are appreciated as wellwith other links to more info as needed. http://www.arizonabuycott.com Current copy http://www.aztourist.com/index.php?option=com_content&view=article&id=218&Itemid=122 We are also growing exponentially with our Facebook account. Our âfriends,â adding 100 weekly who look forward to our event notices every other day, for the same reason they pick the paper up, and keep it. With a click of a mouse an announcement can go out to our 2800 ish friends, and still growing. Lets us submit your events/offerings to thousands of our friends AZ Tourist Friends... http://www.facebook.com/aztouristnews Warm Regards, Tony Venuti Publisher AZ Tourist News 520-622-7008
Re: State of multiprocessing and multithreading in OpenBSD
Stas Miasnikou wrote: > Marco Peereboom wrote: > > Wouldn't it be adorable if people learned to program FSMs instead of > > java in those fancy universities? > > Seconded. > Do you seriously expect programmers to learn to program?
Re: State of multiprocessing and multithreading in OpenBSD
Peter N. M. Hansteen wrote: > pe...@bsdly.net (Peter N. M. Hansteen) writes: > > > I would think that would be a fair question to ask the person who > told > > you PF is garbage because it is multithreaded: > > eh, "because it is *not* multithreaded:" > Now watch when application programmers use multithreaded stuff because they think it will somehow solve all their problems. If you ***CAN*** ***EVER*** make such a typo, do you really think that they even stand a chance? Couple this with wrong-way branches on equal comparisons (edges), and you do not even need to get into error-recovery stuff to find a mess.
Re: State of multiprocessing and multithreading in OpenBSD
Lars Nooden wrote: > > On Wed, 5 May 2010, Geoff wrote: > > There's a paper from Berkeley showing how a threaded program can > > never be fully debugged and should be presumed to be broken, > > probably fatally broken. > > Geoff, can you post the URL or any details that might help finding and > retrieving that particular article or ones like it? > > /Lars http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf first choice googling: threads berkeley Choice quote: (quoting Sutter and Laurs) "humans are quicly overwhelmed by concurrency and find it much more difficult to reason about concurrent than sequential code. Even careful people miss possible interleavings among even simple collections of partially ordered operations." Other than some stunts with data binding I don't think I've seen anything that is competent to handle partial orders. And that one breaks down horribly if storage cells take on more than one value during execution.
Re: unreferenced files from MySQL.
Andreas Gerdd wrote: > > Hello. > I noticed some unreferenced files from MySQL in my daily output mail; > However, i don't have anything in /tmp or /var/tmp to check/fix the > problem with fsck. > > Does this mean i lost some data from the database(s)? > > How may i fix or remove the reported bad files? Short answer: Ignore them. They are remnants of TEMPORARY tables which are supposed to vanish when connection is dropped. > > Here's the output: > > OpenBSD 4.6-stable (GENERIC.MP) #2: Mon Apr 19 08:20:01 PDT 2010 > r...@test.domain.com:/usr/src/sys/arch/i386/compile/GENERIC.MP > > 1:32AM up 14:57, 0 users, load averages: 0.99, 0.47, 0.24 > > Backing up root=/dev/rwd0a to /dev/rwd0d: > 33129+1 records in > 33129+1 records out > 271393792 bytes transferred in 13.506 secs (20093240 bytes/sec) > ** /dev/rwd0d > ** Last Mounted on / > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 2602 files, 64653 used, 65178 free (394 frags, 8098 blocks, 0.3% > fragmentation) > > MARK FILE SYSTEM CLEAN? yes > > > * FILE SYSTEM WAS MODIFIED * > > Checking subsystem status: > > disks: > Filesystem 1K-blocks Used Avail Capacity Mounted on > /dev/wd0a 25966212930611737452%/ > /dev/wd0i 519646 6493658 0%/tmp > /dev/wd0e15486368 3657428 1105462225%/usr > /dev/wd0f36116632138044 34172758 0%/var > /dev/wd0h10323146 11208 9795782 0%/var/vmail > /dev/wd0g 170281220150524 161616636 0%/var/www > > Last dump(s) done (Dump '>' file systems): > > mail: > -Queue ID- --Size-- Arrival Time -Sender/Recipient--- > E083791EB7 880 Sat Apr 24 10:26:31 i...@mydomain.com > (connect to 42.22.192.55 [42.22.192.55]:10024: > Invalid argument) > testm...@yahoo.com > > -- 1 Kbytes in 1 Request. > > network: > NameMtu Network Address Ipkts IerrsOpkts > Oerrs Colls > lo0 3320030718 030718 > 0 0 > lo0 33200 127/8 127.0.0.130718 030718 > 0 0 > lo0 33200 ::1/128 ::1 30718 030718 > 0 0 > lo0 33200 fe80::%lo0/64 fe80::1%lo0 30718 030718 >0 0 > bge0150000:19:b9:f9:0d:9560140 441720 > 0 0 > bge01500 69.197.4.202/26 69.197.4.202 60140 4 > 41720 0 0 > bge01500 fe80::%bge0/64 fe80::219:b9ff:fef9:d95%bge060140 > 441720 > 0 0 > bge01500 72.20.55.89/29 72.20.55.89 60140 441720 > 0 0 > bge01500 72.20.55.90/29 72.20.55.90 60140 441720 > 0 0 > bge01500 72.20.55.91/29 72.20.55.91 60140 441720 > 0 0 > bge01500 72.20.55.92/29 72.20.55.92 60140 441720 > 0 0 > bge01500 72.20.55.93/29 72.20.55.93 60140 441720 > 0 0 > bge01500 72.20.55.94/29 72.20.55.94 60140 441720 > 0 0 > bge1* 150000:19:b9:f9:0d:960 00 > 0 0 > enc0* 1536 0 00 > 0 0 > pflog0 332000 00 > 0 0 > > Checking filesystems: > ** /dev/rwd0a (NO WRITE) > ** Last Mounted on / > ** Root file system > 2602 files, 64653 used, 65178 free (394 frags, 8098 blocks, 0.3% > fragmentation) > ** /dev/rwd0i (NO WRITE) > ** Last Mounted on /tmp > UNREF FILE I=3 OWNER=_mysql MODE=100600 > SIZE=0 MTIME=Apr 24 10:36 2010 > CLEAR? no > > UNREF FILE I=4 OWNER=_mysql MODE=100600 > SIZE=0 MTIME=Apr 24 10:36 2010 > CLEAR? no > > UNREF FILE I=5 OWNER=_mysql MODE=100600 > SIZE=0 MTIME=Apr 24 10:36 2010 > CLEAR? no > > UNREF FILE I=6 OWNER=_mysql MODE=100600 > SIZE=0 MTIME=Apr 24 10:36 2010 > CLEAR? no > > UNREF FILE I=7 OWNER=_mysql MODE=100600 > SIZE=0 MTIME=Apr 24 10:36 2010 > CLEAR? no > > 8 files, 3 used, 259820 free (20 frags, 32475 blocks, 0.0% > fragmentation) > ** /dev/rwd0e (NO WRITE) > ** Last Mounted on /usr > 314304 files, 1828714 used, 5914470 free (62566 frags, 731488 blocks, > 0.8% > fragmentation) > ** /dev/rwd0f (NO WRITE) > ** Last Mounted on /var > 1117 files, 69019 used, 17989297 free (505 frags, 2248599 blocks, 0.0% > fragmentation) > ** /dev/rwd0h (NO WRITE) > ** Last Mounted on /var/vmail > 133 files, 5604 used, 5155969 free (193 frags, 644472 blocks, 0.0% > fragmentation) > ** /dev/rwd0g (NO WRITE) > ** Last Mounted on /var/www > 5502 files, 75262 used, 85065348 free (244 frags, 10633138 blocks, > 0.0% fragmentation) > > Thanks. MySQL (at least the one I've got running -current) keeps Files for ISAM tables in /var/mysql and files for TEMPORARY (ISAM) tables in /var like so: # ls -l /tmp/#sql* -rw-rw 1 _mysql wheel 0 Apr 25 06:02
list of applied patches (v 4.6)
is it possible to list the patches already applied in a v 4.6 installation? Thanks Tony
Re: Generic Discuss about CPU resource scheduling
Aaron Lewis wrote: > Yeah , looping time depends the complexity of that loop , i've learned > that , > We use a O(n) to present such complexity of a program. > Counterexample: Simple solution to 9 body problem Any much quicker solution to same problem. Do you really have an O(n) solution to a sort?, to solving a Linear Program?
Re: Generic Discuss about CPU resource scheduling
Otto Moerbeek wrote: > > On Sun, Apr 18, 2010 at 09:35:42PM +0800, Aaron Lewis wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > > > Hi, > > I'm reading Operating System Concepts (7th Edition) , Written by > > Abraham , Peter & Greg. > > > > In chapter 5.3 , it talks about a schedule algorithm: SJF > > SJF means shortest jobs schedules firstly. > > > > To compare different process , thy use a process running time. > > > > e.g > > P1 takes 6 secs to run > > P2 takes 3 seconds > > P3 takes 10 secs > > > > Then we should put those tasks in array like this: > > P2 => P1 => P3 > > > > That looks much reasonable , but my question is , how does an OS > know > > that a process will takes longer time to finish its life ? > > I think it's impossible to let OS know exactly how long a process > will > > take to run. > > > > > > So far in my experience , i think there's a few ways to compare > > Process running time: > > > > Forgive me if i have a poor experience on OS ;-) > > > > I) Number of Loops in a Program , can be detected by compiler > > As long as you have any loops , you are slower than any straight > ahead > > program > > > > II) Length of Program , longer code takes longer time sometimes , > not a > > good way. > > > > > > Anyone wants to share some experience with me ? > > You cannot tell in general, that's a basic result from CS. But you can > measure previous runs and do predictions based on that, in some cases > at least. I hope I'm not answering a homework assignment... > > -Otto > In general you cannot predict, however there are many (long) jobs with very predictable times to completion: sorts, merges, most anything that processes thousands of records in one batch operation. (and ties up various resources for the duration --- thein is the gotcha) I would not trust counting instructions, loops, subroutine calls as being usefully predictive of execution time. The fun thing about scheduling algorithms is that any one of them is usually theoretically capable of giving the worst possible overall performance.
Re: OpenBSD culture?
Donald Allen wrote: > So you believe civility and correctness are mutually exclusive? > Interesting. > Hardly, but if I am given a choice, I will take correctness. You seem to be under the impression that either correctness is irrelevant or that somehow civility implies correctness. As for mutual exclusivity, seems like intelligence and your brain have said condition.
Re: OpenBSD culture?
Donald Allen wrote: > > On Fri, Apr 16, 2010 at 4:16 AM, Artur Grabowski > wrote: > > On Thu, Apr 15, 2010 at 10:52 PM, Donald Allen > wrote: > > > >> Thanks for the compliment, but I'm a *lot* older than nine. > > > > Yet you still believe that it's ok for guests to tell the hosts how > to > > behave in their home. > > Your analogy doesn't go far enough. Better: guests in a home being > asked for contributions and also being insulted, both by the hosts. > > > Amazing. What culture are you from? > > One that values civility. That means that you prefer systems that can do anything wrong just as long as they talk nice to you. Me, I prefer systems that actually work, and a wee bit of seeming rudeness is a very small price to pay.
Re: OpenBSD culture?
VICTOR TARABOLA CORTIANO wrote: > > Please do not take my mesages out of context. Removing sentences, and > twisting what I said can be very convenient to put me in the wrong > whithout factual evidence. > I do not please. Since no message can be completely within context, that implies that your are logically always in the wrong. The context is that you are in an OpenBSD mailing list. All your blathering is out of that context and you are by your own logic in the wrong. Please get yourself right (out of here)
Re: OpenBSD culture?
Marco Peereboom wrote: > See I told you logic wouldn't work for you. > > Since _my_ definition of freedom for software is different, I > > reach different conclusions. Right. It didn't.
Re: OpenBSD culture?
VICTOR TARABOLA CORTIANO wrote: > > Logic works the same for everyone, since it's an abstract > field, but apparently you did not study it. It weems that you did not learn it.
Re: OpenBSD culture?
Zachary Uram wrote: > > Sorry a lot of people got upset by my message. I will try to learn > OpenBSD on my own since that is the way to do it here. > That is the way to learn most anything that actually matters. I don't think that people were so much upset as they prefer to gladly make fools suffer than to gladly suffer fools. They're actually very nice people. (I have yet to get my just deserts:-)
Re: OpenBSD culture?
I am POSITIVE you are a troll. > -Original Message- > From: Zachary Uram [mailto:net...@gmail.com] > Sent: Wednesday, April 14, 2010 7:58 PM > To: Tony Abernethy > Cc: Bret S. Lambert; misc@openbsd.org > Subject: Re: OpenBSD culture? > > As does yours. Try being positive instead of negative. > > Zach > > <>< http://www.fidei.org ><> > > > > On Wed, Apr 14, 2010 at 8:50 PM, Tony Abernethy > wrote: > > Zachary Uram wrote: > >> > >> Your attitude proves my point. I was not trolling. Grow up! > >> > > Another of the type of statement guaranteed to be false.
Re: OpenBSD culture?
Zachary Uram wrote: > > You get lost. You seem to think the project exists as an end unto > itself. Develop the most wonderful kernel and userspace in the world > but if no one uses it what is the point? Since your attitude to new > users is "get lost" that reflects very poorly on yourself and > indirectly OpenBSD. > You seem to be under the misconception that you alone are the rest of the universe. Did it ever occur to you that the developers just might be doing what they are doing for their own purposes? How many people get to have an operating system that does exactly as their whims dictate?
Re: OpenBSD culture?
Zachary Uram wrote: > > Your attitude proves my point. I was not trolling. Grow up! > Another of the type of statement guaranteed to be false.
Re: problems with carp based firewall - all connections are suspended after falling back from failover
On Sat, Apr 10, 2010 at 9:44 AM, tom baecker wrote:
> Hello,
>
> I've setup a openbsd-ha firewall, based on the
> http://www.openbsd.org/faq/pf/carp.html.
>
> If the master goes down - the backup system become the Master rule.
> All established connections are in sync and stay active - so thats
> perfect.
> But if the original Master system comes back again and fall back to
> the Master state - all established connections are broken, maybe they
> not successfully synced to the old master?
>
> Is there a way to prevent fallback, so the backup system stay in
> Master rule after failover?
> Maybe also I've a wrong setup.
>
> Primary setup:
> /etc/hostname.carp0:
> inet 10.1.1.1 255.255.255.0 10.100.255.255 vhid 1 pass bbb
> /etc/hostname.carp1:
> inet 10.1.2.1 255.255.255.0 10.68.255.255 vhid 2 pass aaa
> /etc/hostname.carp2:
> inet 10.1.3.1 255.255.255.0 10.101.10.255 vhid 3 pass xxx
> /etc/hostname.pfsync0
> up syncdev em1
>
> net.inet.carp.preempt=1
> net.inet.ip.forwarding=1
> net.inet.carp.log=7
>
> pf.conf
> # allow pfsync
> pass quick on em1 proto pfsync
> # allow carp
> pass quick on { em0, em2, em3 } proto carp keep state
>
>
> Standby setup:
> /etc/hostname.carp0:
> inet 10.1.1.1 255.255.255.0 10.100.255.255 vhid 1 advskew 100 pass bbb
> /etc/hostname.carp1:
> inet 10.1.2.1 255.255.255.0 10.68.255.255 vhid 2 advskew 100 pass aaa
> /etc/hostname.carp2:
> inet 10.1.3.1 255.255.255.0 10.101.10.255 vhid 3 advskew 100 pass xxx
> /etc/hostname.pfsync0
> up syncdev em1
>
> net.inet.carp.preempt=1
> net.inet.ip.forwarding=1
> net.inet.carp.log=7
>
> pf.conf
> # allow pfsync
> pass quick on em1 proto pfsync
> # allow carp
> pass quick on { em0, em2, em3 } proto carp keep state
>
>
>
>
> A failover and fallback gives me the follow entrys in the message log:
>
> the master goes down:
> Apr 9 16:02:05 fw-bkp /bsd: carp1: state transition: BACKUP -> MASTER
> Apr 9 16:02:05 fw-bkp /bsd: carp0: state transition: BACKUP -> MASTER
> Apr 9 16:02:05 fw-bkp /bsd: carp2: state transition: BACKUP -> MASTER
> the master comes back:
> Apr 9 16:25:07 fw-bkp /bsd: carp0: state transition: MASTER -> BACKUP
> Apr 9 16:25:07 fw-bkp /bsd: carp2: state transition: MASTER -> BACKUP
> Apr 9 16:25:17 fw-bkp /bsd: carp1: state transition: MASTER -> BACKUP
>
>
> the primary booting up and takeover the master rule:
> Apr 9 16:24:11 fw-pri /bsd: carp: carp0 demoted group carp to 129
> Apr 9 16:24:11 fw-pri /bsd: carp: carp1 demoted group carp to 130
> Apr 9 16:24:11 fw-pri /bsd: carp: carp2 demoted group carp to 131
> Apr 9 16:24:11 fw-pri /bsd: carp0: state transition: INIT -> BACKUP
> Apr 9 16:24:11 fw-pri /bsd: carp: carp0 demoted group carp to 134
> Apr 9 16:24:12 fw-pri /bsd: carp: pfsync0 demoted group carp to 131
> Apr 9 16:24:12 fw-pri /bsd: carp: pfsync0 demoted group pfsync to 1
> Apr 9 16:24:12 fw-pri /bsd: carp1: state transition: INIT -> BACKUP
> Apr 9 16:24:12 fw-pri /bsd: carp: carp1 demoted group carp to 130
> Apr 9 16:24:12 fw-pri /bsd: carp2: state transition: INIT -> BACKUP
> Apr 9 16:24:12 fw-pri /bsd: carp: carp2 demoted group carp to 129
> Apr 9 16:24:12 fw-pri /bsd: carp1: state transition: BACKUP -> MASTER
> Apr 9 16:24:29 fw-pri /bsd: carp: pfsync0 demoted group carp to 0
> Apr 9 16:24:29 fw-pri /bsd: carp: pfsync0 demoted group pfsync to 0
> Apr 9 16:24:30 fw-pri /bsd: carp0: state transition: BACKUP -> MASTER
> Apr 9 16:24:30 fw-pri /bsd: carp2: state transition: BACKUP -> MASTER
>
>
> hopefully you can help me.
> Regards,
> Tom
>
>
net.inet.carp.preempt Allow virtual hosts to preempt each other.
Set it to 0 and give it a try.
/Tony
Re: unidentified system load
On Sun, Mar 28, 2010 at 1:18 PM, Tony Sarendal wrote: > > > On Sun, Mar 28, 2010 at 10:41 AM, Mark Kettenis > wrote: > >> It's worth trying to disable ichiic(4). >> > > Cheers, giving it a go on a few of them. > > Over a week running with i386 4.6 and -current with ichiic(4) disabled. The 6 boxes I updated all looking good. Thanks Mark
Re: unidentified system load
On Sun, Mar 28, 2010 at 10:41 AM, Mark Kettenis wrote: > It's worth trying to disable ichiic(4). > Cheers, giving it a go on a few of them. /Tony
Re: unidentified system load
Is there a way to see where the cpu time is spent when it isn't in userland ? I took one of our affected systems and killed everything on it as well as disabling pf. bmr1.brh# ps aux USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 1 0.0 0.0 324 296 ?? Is 1Mar100:00.02 /sbin/init root 8898 0.0 0.0 708 1200 ?? Is 1Mar100:00.02 /usr/sbin/sshd root 29797 0.0 0.1 3424 2468 ?? Is 8:29AM0:00.11 sshd: thehoff [priv] (sshd) thehoff 27836 0.0 0.1 3396 1912 ?? S 8:29AM0:00.03 sshd: theh...@ttyp0 (sshd) thehoff 4730 0.0 0.0 480 408 p0 Is 8:29AM0:00.00 -ksh (ksh) root 23806 0.0 0.0 476 460 p0 S 8:29AM0:00.01 -ksh (ksh) root 15249 0.0 0.0 276 276 p0 R+/1 8:53AM0:00.00 ps -aux root 25718 0.0 0.0 408 736 C0 Is+1Mar100:00.00 /usr/libexec/getty std.9600 ttyC0 root 30984 0.0 0.0 300 736 C1 Is+1Mar100:00.00 /usr/libexec/getty std.9600 ttyC1 root 7406 0.0 0.0 256 740 C2 Is+1Mar100:00.00 /usr/libexec/getty std.9600 ttyC2 root 1736 0.0 0.0 336 728 C3 Is+1Mar100:00.00 /usr/libexec/getty std.9600 ttyC3 root 1371 0.0 0.0 440 736 C5 Is+1Mar100:00.00 /usr/libexec/getty std.9600 ttyC5 bmr1.brh# load averages: 0.08, 0.09, 0.08 08:52:43 12 processes: 11 idle, 1 on processor CPU0 states: 0.0% user, 0.0% nice, 0.0% system, 0.2% interrupt, 99.8% idle CPU1 states: 0.0% user, 0.0% nice, 8.1% system, 0.0% interrupt, 91.9% idle Memory: Real: 5220K/351M act/tot Free: 2916M Swap: 0K/8197M used/tot PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND 29797 root 20 3424K 2468K idle netio 0:00 0.00% sshd 27836 thehoff20 3396K 1912K sleep/0 select0:00 0.00% sshd 1 root 100 324K 296K idle wait 0:00 0.00% init 8898 root 20 708K 1200K idle select0:00 0.00% sshd 23806 root 180 476K 460K sleep/0 pause 0:00 0.00% ksh 32058 root 280 712K 1420K onproc/1 - 0:00 0.00% top 4730 thehoff 180 480K 408K idle pause 0:00 0.00% ksh 25718 root 30 408K 736K idle ttyin 0:00 0.00% getty 1736 root 30 336K 728K idle ttyin 0:00 0.00% getty 30984 root 30 300K 736K idle ttyin 0:00 0.00% getty 1371 root 30 440K 736K idle ttyin 0:00 0.00% getty 7406 root 30 256K 740K idle ttyin 0:00 0.00% getty I suspect that there is some device in there that is being polled in some funky way as this only happens on these specific boxes. Even the fujitsu box marked as "kaputt" with red marker pen works as charm. /T
Re: unidentified system load
> I'd be looking at the state of your mbufs as well. man netstat > > Thanks Aaron, these systems are currently running with load very low. From one of the boxes with the problem: bmr1.mlt# uptime 11:33AM up 13 days, 1:04, 1 user, load averages: 0.15, 0.17, 0.11 bmr1.mlt# netstat -m 102 mbufs in use: 81 mbufs allocated to data 4 mbufs allocated to packet headers 17 mbufs allocated to socket names and addresses 69/310/6144 mbuf 2048 byte clusters in use (current/peak/max) 0/8/6144 mbuf 4096 byte clusters in use (current/peak/max) 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max) 0/8/6144 mbuf 9216 byte clusters in use (current/peak/max) 0/8/6144 mbuf 12288 byte clusters in use (current/peak/max) 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max) 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max) 900 Kbytes allocated to network (18% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines bmr1.mlt# bmr1.mlt# vmstat -m ... Memory Totals: In UseFreeRequests 3756K210K 3844873 ... In use 6468K, total allocated 32928K; utilization 19.6% bmr1.mlt# They are basically standard setups with ipsec,bgpd,gre,carp and vlans, small and simple configs, low number of interfaces. Not even any packages added.
unidentified system load
I'm using supermicro boxes (dmesg below) as vpn routers. IPsec+gre+bgp.
After a few days uptime the boxes start reporting 8% system cpu, and at the
same time
they become unresponsive on the network approx every 10 seconds.
Any idea on how to find the reason for this is appreciated.
I have around 20 of these boxes running open and freebsd, so far all of the
openbsd boxes
display this behaviour using amd64, i386, sp and mp, 4.6 and various 4.7
snapshots.
I only see this on these specific supermicros. This happens on the devices
that don't
move any traffic as well.
Regards Tony
bmr0.mlt# ping -i 0.1 172.30.251.230
64 bytes from 172.30.251.230: icmp_seq=42 ttl=255 time=0.278 ms
64 bytes from 172.30.251.230: icmp_seq=43 ttl=255 time=0.328 ms
64 bytes from 172.30.251.230: icmp_seq=44 ttl=255 time=0.250 ms
64 bytes from 172.30.251.230: icmp_seq=45 ttl=255 time=402.911 ms
64 bytes from 172.30.251.230: icmp_seq=46 ttl=255 time=292.374 ms
64 bytes from 172.30.251.230: icmp_seq=47 ttl=255 time=181.836 ms
64 bytes from 172.30.251.230: icmp_seq=48 ttl=255 time=71.300 ms
64 bytes from 172.30.251.230: icmp_seq=49 ttl=255 time=0.255 ms
64 bytes from 172.30.251.230: icmp_seq=50 ttl=255 time=0.305 ms
bmr1.mlt# dmesg
OpenBSD 4.7-beta (GENERIC.MP) #427: Sun Feb 28 12:37:40 MST 2010
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel" 686-class)
3.01 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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR
real mem = 3487580160 (3326MB)
avail mem = 3391463424 (3234MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 07/24/09, BIOS32 rev. 0 @ 0xfdb70,
SMBIOS rev. 2.5 @ 0xcfedf000 (39 entries)
bios0: vendor Phoenix Technologies LTD version "1.30" date 07/24/2009
bios0: Supermicro X7SBi
acpi0 at bios0: rev 2
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
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: apic clock running at 333MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz ("GenuineIntel" 686-class)
3.01 GHz
cpu1:
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,MWAIT,DS-CPL,VMX,SMX,EST,TM2,CX16,xTPR
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
ioapic1 at mainbus0: apid 3 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
acpibtn0 at acpi0: PWRB
acpivideo0 at acpi0: IGD0
bios0: ROM list: 0xc/0x9000
ipmi at mainbus0 not configured
cpu0: Enhanced SpeedStep 3001 MHz: speeds: 3000, 2667, 2333, 2000 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
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 2 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 2 int 16
(irq 5)
uhci1 at pci0 dev 26 function 1 "Intel 82801I USB" rev 0x02: apic 2 int 17
(irq 10)
uhci2 at pci0 dev 26 function 2 "Intel 82801I USB" rev 0x02: apic 2 int 18
(irq 11)
ehci0 at pci0 dev 26 function 7 "Intel 82801I USB" rev 0x02: apic 2 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 2 int 16
(irq 5)
pci3 at ppb2 bus 5
ppb3 at pci0 dev 28 function 4 "Intel 82801I PCIE" rev 0x02: apic 2 int 16
(irq 5)
pci4 at ppb3 bus 13
em0 at pci4 dev 0 function 0 "Intel PRO/1000MT (82573E)" rev 0x03: apic 2
int 16 (irq 5)PHY ID 0x1410CC0 detected (17)
, address 00:30:48:bd:45:3a
ppb4 at pci0 dev 28 function 5 "Intel 82801I PCIE" rev 0x02: apic 2 int 17
(irq 10)
pci5 at ppb4 bus 15
em1 at pci5 dev 0 function 0 "Intel PRO/1000MT (82573L)" rev 0x00: apic 2
int 17 (irq 10)PHY ID 0x1410CC0 detected (17)
, address 00:30:48:bd:45:3b
uhci3 at pci0 dev 29 function 0 "Intel 82801I USB" rev 0x02: apic 2 int 23
(irq 10)
uhci4 at pci0 de
Re: ZFS in OpenBSD
Dan Naumov wrote: > ... I can only suggest therapy, it works > for millions of people. That explains the state of Information Technology. I'll take the code, snide remarks and all. Thanks.
Re: IPsec 4.6 to snapshot failing
On Mon, Mar 1, 2010 at 12:54 PM, Stuart Henderson wrote: > On 2010-03-01, Tony Sarendal wrote: > > Good morning misc, > > > > I upgraded two devices from i386-4.6 to i386-snapshot-feb28. > > After the upgrade snapshot boxes are unable to communicate with the 4.6 > > devices > > when going through ipsec. snapshot-snapshot works fine. > > > > Everything looks ok except that nothing shows up on enc0 when doing > > 4.6<-->snapshot. > > Deleting the SA's restores connectiviy, unencrypted of course. > > Is this a known issue ? > > yes, there was a bug with hmac-sha2 which was causing interop problems > with correct IPsec implementations and needed fixing, unfortunately the > fix breaks backwards compatibility. > > you'll need to switch to e.g. hmac-sha until the 4.6 box can be upgraded. > > Thanks to everyone for the quick and correct response, much appreciated. /T, with a tad of ring rust.
IPsec 4.6 to snapshot failing
Good morning misc, I upgraded two devices from i386-4.6 to i386-snapshot-feb28. After the upgrade snapshot boxes are unable to communicate with the 4.6 devices when going through ipsec. snapshot-snapshot works fine. Everything looks ok except that nothing shows up on enc0 when doing 4.6<-->snapshot. Deleting the SA's restores connectiviy, unencrypted of course. Is this a known issue ? /T bmr1.jfa: 212.112.186.174 (4.6) bmr1.brh: 212.188.183.71 (snapshot) --- bmr1.jfa# ipsecctl -sa | grep 212.188.183.71 flow esp in from 212.188.183.71 to 212.112.186.174 peer 212.188.183.71 srcid 212.112.186.174/32 dstid 212.188.183.71/32 type use flow esp out from 212.112.186.174 to 212.188.183.71 peer 212.188.183.71 srcid 212.112.186.174/32 dstid 212.188.183.71/32 type require esp transport from 212.188.183.71 to 212.112.186.174 spi 0x3f91b3c2 auth hmac-sha2-256 enc aes esp transport from 212.112.186.174 to 212.188.183.71 spi 0xa797ec1e auth hmac-sha2-256 enc aes bmr1.jfa# bmr1.brh# ipsecctl -sa | grep 212.112.186.174 flow esp in from 212.112.186.174 to 212.188.183.71 peer 212.112.186.174 srcid 212.188.183.71/32 dstid 212.112.186.174/32 type use flow esp out from 212.188.183.71 to 212.112.186.174 peer 212.112.186.174 srcid 212.188.183.71/32 dstid 212.112.186.174/32 type require esp transport from 212.188.183.71 to 212.112.186.174 spi 0x3f91b3c2 auth hmac-sha2-256 enc aes esp transport from 212.112.186.174 to 212.188.183.71 spi 0xa797ec1e auth hmac-sha2-256 enc aes bmr1.brh# bmr1.brh# pfctl -d pf disabled bmr1.brh# tcpdump -n -p -i vlan301 host 212.112.186.174 & [1] 2099 bmr1.brh# tcpdump: listening on vlan301, link-type EN10MB bmr1.brh# tcpdump -n -p -i enc0 & [2] 23922 bmr1.brh# tcpdump: listening on enc0, link-type ENC bmr1.brh# bmr1.jfa# tcpdump -n -p -i bge0 host 212.188.183.71 & [1] 443 bmr1.jfa# tcpdump: listening on bge0, link-type EN10MB bmr1.jfa# tcpdump -n -p -i enc0 & [2] 16714 bmr1.jfa# tcpdump: listening on enc0, link-type ENC bmr1.jfa# bmr1.jfa# ping 212.188.183.71 PING 212.188.183.71 (212.188.183.71): 56 data bytes 11:21:48.081933 (authentic,confidential): SPI 0x007e7833: 212.112.186.174 > 212.188.183.71: icmp: echo request 11:21:48.081969 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 15 len 116 11:21:49.085937 (authentic,confidential): SPI 0x007e7833: 212.112.186.174 > 212.188.183.71: icmp: echo request 11:21:49.085974 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 16 len 116 11:21:50.095970 (authentic,confidential): SPI 0x007e7833: 212.112.186.174 > 212.188.183.71: icmp: echo request 11:21:50.096006 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 17 len 116 11:21:51.106010 (authentic,confidential): SPI 0x007e7833: 212.112.186.174 > 212.188.183.71: icmp: echo request 11:21:51.106045 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 18 len 116 bmr1.brh# 10:21:48.102134 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 15 len 116 10:21:49.106079 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 16 len 116 10:21:50.116146 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 17 len 116 10:21:51.126213 esp 212.112.186.174 > 212.188.183.71 spi 0x007e7833 seq 18 len 116 bmr1.jfa# grep 212.188.183.71 /etc/ipsec.conf ike esp transport from 212.112.186.174 to 212.188.183.71 bmr1.brh# grep 212.112.186.174 /etc/ipsec.conf ike esp transport from 212.188.183.71 to 212.112.186.174
Re: softdeps enabled = poor "concurrent" access?
Noah McNallie wrote: > please read latest post Doesn't get any lazier than that.
Re: Open Source hardware (Re: can't get vesa @ 1280x800 or nv)
rhubbell wrote: > Another sensitive type. Guess there are always a few on every list. As distinguished from insensitive twerps like yourself.
Re: Partitioning an external USB drive through OpenBSD -- disklabel
Sorry for top-posting, but please: Disk sectors start with 1 (unless you are
reformatting the entire track and something like Write Record zero still
exists)
On DOS-FORMATTED disks, the initial sector is at cylinder 0, head 0, sector 1,
and contains within the bootstrap loader what DOS and Windows calls a
Partition Table.
The rest of track 0 is empty, unless you are running a boot sector virus or
such.
-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
Kenneth R Westerback
Sent: Friday, October 30, 2009 5:38 PM
To: Josh Grosse
Cc: Amarendra Godbole; misc
Subject: Re: Partitioning an external USB drive through OpenBSD -- disklabel
On Fri, Oct 30, 2009 at 08:53:45AM -0500, Josh Grosse wrote:
> On Fri, 30 Oct 2009 18:44:08 +0530, Amarendra Godbole wrote
>
> > Thank you all for responses -- I have a better idea now. The only
> > thing that I noticed was newfs_msdos wipes out the entire disklabel
> > as well as any fdisk created partitions and gobbles up the entire disk.
> >
> > I guess what James Hartley said in this thread is correct -- Windows
> > must be used to create the DOS partition, and then disklabel to get
> > the OpenBSD one.
>
> No, the reason the MBR and disklabel were wiped out was due to an error you
> made: starting the partition at sector #0. That sector contians the MBR
and
> the MBR primary partition table, and the OpenBSD disklabel follows behind.
>
> Normally, one would begin the first partition -after- the first track
> (typically sectors 0-62).
>
> But, If you were to use Windows disk management to create a FAT partition
of
> some size on the disk, Windows will begin it at sector #63 for you.
Knowledge
> of disk geometry and usage is not required by a Windows user, as the tools
do
> not allow you the control that fdisk(8) does.
On MBR formatted disks, sector 0 is the MBR. So overwriting that
will indeed toast important information about the disk.
However the OpenBSD disklabel is not written to the sector after
the MBR if there is an OpenBSD partition, it is written to the
second sector of the first OpenBSD partition. So whacking the MSDOS
partition starting at sector 0 toasts the MBR, which means the
OpenBSD partition cannot be found, which means the disklabel is
inaccessable. If you were to re-create the MBR with the correct
partitions, the disklabel would re-appear. The MSDOS parition would
now be broken of course. :-).
As an example here is one of my disks, and a hexdump of the first
65 sectors. The MBR can be seen at sector 0, and the disklabel
at sector 64. (64*512 = 32768 = 0x8000).
You'll have to take my word I did
dd if=/dev/rsd0c of=~/tmp/sect0to64 bs=512 count=65
hexdump -C ~/tmp/sect0to64 > ~/tmp/sect0to64.txt
Ken
Script started on Fri Oct 30 18:11:16 2009
# fdisk sd0
Disk: sd0 geometry: 38913/255/63 [625142448 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start:size ]
-
--
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: A6 0 1 1 - 38912 254 63 [ 63: 625137282 ] OpenBSD
# disklabel sd0
# /dev/rsd0c:
type: SCSI
disk: SCSI disk
label: WDC WD3200AAKS-0
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 255
sectors/cylinder: 16065
cylinders: 38913
total sectors: 625142448
rpm: 3600
interleave: 1
boundstart: 63
boundend: 625137345
drivedata: 0
16 partitions:
#size offset fstype [fsize bsize cpg]
a: 417627 63 4.2BSD 2048 163841 # /
b: 25173855 417690swap
c:6251424480 unused
d: 417690 25591545 4.2BSD 2048 163841 # /tmp
e: 417690 26009235 4.2BSD 2048 163841 # /var
g: 20980890 26426925 4.2BSD 2048 163841 # /usr
h:514786860110350485 4.2BSD 2048 163841 # /home
i: 20980890 47407815 4.2BSD 2048 163841 # /usr/src
j: 20980890 68388705 4.2BSD 2048 163841 # /usr/ports
k: 20980890 89369595 4.2BSD 2048 163841 #
/usr/xenocara
# cat sect0to64.txt
ea 05 00 c0 07 8c c8 8e d0 bc fc ff 8e d8 b8 a0 |j...@..h.p<|.X8
|
0010 07 8e c0 31 f6 31 ff b9 00 02 fc f3 a4 ea 22 00
|@1v19..|s$j".|
0020 a0 07 1e 07 0e 1f b4 02 cd 16 a8 03 74 0a b0 07 |
.4.M.(.t.0.|
0030 e8 cb 00 80 0e b4 01 01 f6 c2 80 75 08 be 36 01
|hK...4..vB.u.>6.|
0040 e8 af 00 b2 80 be be 01 b9 04 00 8a 04 3c 80 74
|h/.2.>>.9<.t|
0050 0f 83 c6 10 e2 f5 be 6a 01 e8 96 00 fb f4 eb fc
|..F.bu>j.h..{tk||
0060 88 d0 24 0f 04 30 a2 27 01 b0 34
Re: 4.6 will be released on October 1st?
Nice Daemon wrote: [nothing of interest] [nothing but bad gas] about 23 times worse than CO2. Amazing how the nicknames are what one should be as opposed to what one is. There are a few exceptions, but not this idiot who cannot tell the difference between a cup holder and a disk drive.
Re: Bind ntpd on certain interface?
> I'm very sorry do disappoint you, but I'd have found it (on > my own). But it's nice of you to underestimate other people, > as it fits in your role model. I don't mind. Then why didn't you? (find it on your own) The developers seem to have a rather precise idea of their own Competence and the limits thereof. You seem to think that somehow everybody else should cater to Your ignorance and incompetence. You seem even more stupid than the Microsofties.
Re: Bind ntpd on certain interface?
I can read. The point is that it takes only a minimal amount of abiity in that regard to realize that you are 1. stupid 2. crybaby 3. seemingly devoid of any capacity for rational thought Nobody want to thoroughly research all your drivel to make any kind of point, minor or major. I am getting old and senile, but you seem to be the dumbest most irrelevant twerp I have ever encountered. I can read your statements sufficiently to infer that your ancestors were also incapable of carrying any intelligence. _ From: Nice Daemon [mailto:nicedae...@googlemail.com] Sent: Friday, August 14, 2009 6:17 AM To: t...@servacorp.com Cc: Claudio Jeker; misc@openbsd.org Subject: Re: Bind ntpd on certain interface? No. The point is that you are stupid. Pretending to be otherwise is extremely insulting to my intelligence. Please stop insulting my intelligence. You demonstrate being not able to read. People who are not able to read hardly carry any intelligence. > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] > On Behalf Of Nice Daemon > Sent: Friday, August 14, 2009 5:55 AM > To: t...@servacorp.com. > Cc: Claudio Jeker; misc@openbsd.org > Subject: Re: Bind ntpd on certain interface? > > On Fri, Aug 14, 2009 at 12:42 PM, Tony Aberenthy > wrote: > > > Nice Daemon wrote: > > > No, I'm certainly not stupid. > > > > Invariably the mark of someone who IS stupid. > > > > Longer version. > > If I am not stupid then I can say something intelligent to > make the point. > > > The point was that Henning started insulting. > > > > > > If the only thing I can come up with it to say I am not > stupid, then > > that implies at least a total lack of imagination. > > This is from Microsoft Outlook and I am too lazy to wrap > lines properly. > > Further, this thread is certainly not worth the minimal effort that > > that would require. > > I am stupid, most likely, but I am not THAT stupid.
Re: Bind ntpd on certain interface?
No. The point is that you are stupid. Pretending to be otherwise is extremely insulting to my intelligence. Please stop insulting my intelligence. > -Original Message- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] > On Behalf Of Nice Daemon > Sent: Friday, August 14, 2009 5:55 AM > To: t...@servacorp.com. > Cc: Claudio Jeker; misc@openbsd.org > Subject: Re: Bind ntpd on certain interface? > > On Fri, Aug 14, 2009 at 12:42 PM, Tony Aberenthy > wrote: > > > Nice Daemon wrote: > > > No, I'm certainly not stupid. > > > > Invariably the mark of someone who IS stupid. > > > > Longer version. > > If I am not stupid then I can say something intelligent to > make the point. > > > The point was that Henning started insulting. > > > > > > If the only thing I can come up with it to say I am not > stupid, then > > that implies at least a total lack of imagination. > > This is from Microsoft Outlook and I am too lazy to wrap > lines properly. > > Further, this thread is certainly not worth the minimal effort that > > that would require. > > I am stupid, most likely, but I am not THAT stupid.
Re: Bind ntpd on certain interface?
Nice Daemon wrote: > No, I'm certainly not stupid. Invariably the mark of someone who IS stupid. Longer version. If I am not stupid then I can say something intelligent to make the point. If the only thing I can come up with it to say I am not stupid, then that implies at least a total lack of imagination. This is from Microsoft Outlook and I am too lazy to wrap lines properly. Further, this thread is certainly not worth the minimal effort that that would require. I am stupid, most likely, but I am not THAT stupid.
Re: boot disk ???
> >> I've managed by myself so far That's the wierdest idea of "by myself" I've ever seen. Go back to your cup holder.
Re: boot disk ???
Nick Bender wrote: > On Wed, Aug 5, 2009 at 6:08 PM, PJ wrote: > > Peter N. M. Hansteen wrote: > >> Once you've cleared that hurdle, It would help a lot with > more details > >> about the hardware, what image file you are using and where it came > >> from (ie is it the i386 one, the amd64 one, off an official mirror > >> site, or something different) and what application and > options you use > >> to burn the CD. > > I already posted wherefrom - openBSD ftp site; the burning was done > > exaactly the same as for the FreeBSD and many other files > without ever > > having any problems... and I mean, EVER ! > > How about giving actual details. Here let me help: > > Downloaded install45.iso from > ftp://ftp.openbsd.org/pub/OpenBSD/4.5/amd64/. > Attempted to boot on an IBM x305 with the following errors: ... > Maybe a dmesg from another OS would help... > > See? That wouldn't be too hard now would it? > > >> Burning CD images to DVD media does not always work, > >> for example (probably a stupid one that risks insistent > >> contradictions, but well,), so any detail you supply could > be helpful > >> in sorting out whatever the problem is. > > It really pisses me off that everyone assumes that the poor > sap who is > > asking for help is too stupid to have done things right and > they just > > forget that maybe the problem is in the SOURCE ! > > Rather than details you get all defensive. And for the record I assume > that you are doing something wrong. Why? Because I've booted both > install45.iso and install46.iso hundreds of times without any > problems. > Notice I didn't say stupid, just wrong. I've made my share of brainos > over the years - are you capable of laughing at yourself? > > > I know what a bootable image usually looks like... but > neither of those > > I downloaded look right. > > What color is yours? I see the amd64 installer as mauve and the > i386 as more of a dark green. Again, no details... > > > Unless, of course the booting is supposed to be done in some > > incomprehesible way from some other operating system in > some mysterious > > way that is not spelled out anywhere where I can find it, > anyway. :-) > > Search the archives. Very few people get stuck at the same > point as you. > > > Sorry, but I'm ust laughing all theway back to FreeBSD... > they may be > > fucked-up but at least I can managed to figure out how to > to deal with > them. > > I liked the idea of how your head honcho runs things and the general > > response to the OS, but by gosh and by golly, Molly, > somebody ai'nt got > > the steering sheel pointed right! > > Buh-bye. Don't let the iso hit you in the ass on the way out... > > -N > Maybe it really IS a cup holder. Those do not give out very good diagnostics.
Re: OpenBSD 4.5 pf port forwarding
Anathae Townsend wrote:
>
> I am currently trying to open up a few ports on my firewall
> to allow an
> internal
> windows home server to provide services to the outside world.
>
> My OpenBSD version is OpenBSD 4.5-current (GENERIC) #6: Sat
> May 16 21:50:41
> MDT 2009
>
> I am trying to use the simple proxy method mentioned in the faq on the
> OpenBSD.org to
> forward internal requests to the external ip address to the
> home server.
>
> However, I can't get there from here. Neither internal nor external
> requests to the
on page 58 of Hansteen's excellent "The Book of PF" there is an incantation.
-- from slightly sanitized /etc/pf.conf
-- OpenBSD vintage aprox 4.4
-- scrub is now automatic, ftp-proxy may have changed
Both local and internet refer to the server (Linux) by the one external IP
(on the OpenBSD gateway/firewall/router), including the local server talking
to itself (and it does a lot of that).
Seems like the last two lines below are the critical ones.
scrub in## this would be redundant and wrong on -current
nat on $ext_if from !($ext_if) -> ($ext_if:0)
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021
rdr on $ext_if proto tcp from any to any port $services -> $server
### (p 58 The Book of PF )
rdr on $int_if proto tcp from $localnet to $ext_if port $services -> $server
no nat on $int_if proto tcp from $int_if to $localnet
nat on $int_if proto tcp from $localnet to $server port $services -> $int_if
> external ip address work. A msdos telnet session to the external ip
> address, port 25
> returns an SMTP 421 error immediately and exits.
>
> Any help on opening up these ports would be greatly
> appreciated, below is my
> current
> pf.conf, as well as (slightly edited) output of ifconfig for
> the internal
> (ingress)
> and external (egress) interfaces on the firewall.
>
> NAT is working internally, and I am able to both send email
> and read web
> pages (among
> other stuff.)
>
> --pf.conf-
> --
> --
> # pf.conf created july 6, 2009
> # author: Anathae Townsend
>
> # macros
> homeserv = "192.168.0.195"
> homeport = "{http, https, 4125, smtp, pop3, imap }"
>
> # skip loop back, makes rules quicker
> set skip on lo
>
> # redirects for home server
> rdr on egress proto tcp from any to egress port $homeport -> $homeserv
>
> # redirects for internal web access to proxy server
> rdr on ingress proto tcp from ingress:network to egress port
> 80 -> 127.0.0.1
> port 5000
>
> # NAT rules to allow inside->out
> nat on egress from ingress:network -> (egress)
>
> # allow internal systems to make connection
> pass in # to establish keep-state
>
> # allow home server services
> pass proto tcp from any to $homeserv port $homeport synproxy state
> pass proto tcp from $homeserv to any port smtp synproxy state
>
> # By default, do not permit remote connections to X11
> block in on ! lo0 proto tcp from any to any port 6000
> --ifconfig
> sk0---
> -
> sk0: flags=8843 mtu 1500
> lladdr 00:1e:58:ab:13:8c
> priority: 0
> groups: ingress
> media: Ethernet autoselect (1000baseT
> full-duplex,rxpause,txpause)
> status: active
> inet 192.168.0.1 netmask 0xff00 broadcast 192.168.0.255
> inet 192.168.0.51 netmask 0xff00 broadcast 192.168.0.255
> --ifconfig
> rl0---
> -
> rl0: flags=8843 mtu 1500
> lladdr 00:05:5d:d2:6e:48
> priority: 0
> groups: egress
> media: Ethernet autoselect (10baseT half-duplex)
> status: active
> inet #.#.#.# netmask 0xff80 broadcast #.#.#.#
Re: Floating disk geometry
Sergey Yudin wrote:
>
> Please can someone tell why disk geometry changed after install
>
> in installation time on empty sd0:
>
> Disk: sd0 geometry: 78753/2/911 [143638992 Sectors]
I don't know what that is, or where it came from,
but I don't think any 80386-type pc-BIOS could handle that geometry.
sectors per track show 911 but the maximum is 63
Looks like the install changed ramdom garbage into something useable.
(subject of course to correction from people on this list
who actually know what they are talking about)
> Offset: 0 Signature: 0x0
> Starting Ending LBA Info:
> #: id C H S - C H S [ start:size ]
> --
> -
> 0: 00 0 0 0 - 0 0 0 [ 0:
> 0 ] unused
> 1: 00 0 0 0 - 0 0 0 [ 0:
> 0 ] unused
> 2: 00 0 0 0 - 0 0 0 [ 0:
> 0 ] unused
> 3: 00 0 0 0 - 0 0 0 [ 0:
> 0 ] unused
>
> after install geometry shown as:
>
> Disk: sd0 geometry: 8941/255/63 [143638992 Sectors]
> Offset: 0 Signature: 0xAA55
> Starting Ending LBA Info:
> #: id C H S - C H S [ start:size ]
> --
> -
> 0: 00 0 0 0 - 0 0 0 [ 0:
> 0 ] unused
> 1: 00 0 0 0 - 0 0 0 [ 0:
> 0 ] unused
> 2: 00 0 0 0 - 0 0 0 [ 0:
> 0 ] unused
> *3: A6 0 14 30 - 8931 181 48 [ 911:
> 143487055 ] OpenBSD
>
> thanks a lot
>
>
>
>
> OpenBSD 4.5 (GENERIC) #1749: Sat Feb 28 14:51:18 MST 2009
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
> cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2
> cache) 350 MHz
> cpu0:
> FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,
> PAT,PSE36,MMX,FXSR
> real mem = 268005376 (255MB)
> avail mem = 250855424 (239MB)
> mainbus0 at root
> bios0 at mainbus0: AT/286+ BIOS, date 09/30/98, BIOS32 rev. 0
> @ 0xfd760
> mpbios0 at bios0: Intel MP Specification 1.4
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: apic clock running at 99MHz
> mpbios0: bus 0 is type PCI
> mpbios0: bus 1 is type PCI
> mpbios0: bus 2 is type PCI
> mpbios0: bus 3 is type ISA
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 24 pins
> pcibios0 at bios0: rev 2.1 @ 0xfd760/0x8a0
> pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdef0/240 (13 entries)
> pcibios0: PCI Interrupt Router at 000:02:0 ("Intel 82371FB
> ISA" rev 0x00)
> pcibios0: PCI bus #2 is the last bus
> WARNING: can't reserve area for I/O APIC.
> bios0: ROM list: 0xc/0x8000 0xc8000/0x5000 0xcd000/0x800
> pci0 at mainbus0 bus 0: configuration mode 1 (bios)
> pchb0 at pci0 dev 0 function 0 "Intel 82443BX AGP" rev 0x02
> intelagp0 at pchb0
> agp0 at intelagp0: aperture at 0x1000, size 0x400
> ppb0 at pci0 dev 1 function 0 "Intel 82443BX AGP" rev 0x02
> pci1 at ppb0 bus 1
> piixpcib0 at pci0 dev 2 function 0 "Intel 82371AB PIIX4 ISA" rev 0x02
> pciide0 at pci0 dev 2 function 1 "Intel 82371AB IDE" rev 0x01: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibility
> pciide0: channel 0 ignored (disabled)
> pciide0: channel 1 ignored (disabled)
> uhci0 at pci0 dev 2 function 2 "Intel 82371AB USB" rev 0x01:
> apic 1 int
> 19 (irq 11)
> piixpm0 at pci0 dev 2 function 3 "Intel 82371AB Power" rev 0x02: SMI
> iic0 at piixpm0
> spdmem0 at iic0 addr 0x50: 128MB SDRAM ECC PC100CL3
> spdmem1 at iic0 addr 0x51: 128MB SDRAM ECC PC100CL3
> fxp0 at pci0 dev 3 function 0 "Intel 8255x" rev 0x05, i82558:
> apic 1 int
> 16 (irq 9), address 00:c0:0d:00:94:4f
> inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 0
> vga1 at pci0 dev 4 function 0 "Cirrus Logic CL-GD5430" rev 0x22
> wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
> wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
> ppb1 at pci0 dev 5 function 0 "DEC 21150 PCI-PCI" rev 0x04
> pci_intr_map: bus 0 dev 5 func 0 pin 1; line 9
> pci_intr_map: no MP mapping found
> pci_intr_map: bus 0 dev 5 func 0 pin 2; line 10
> pci_intr_map: no MP mapping found
> pci_intr_map: bus 0 dev 5 func 0 pin 3; line 9
> pci_intr_map: no MP mapping found
> pci_intr_map: bus 0 dev 5 func 0 pin 4; line 11
> pci_intr_map: no MP mapping found
> pci2 at ppb1 bus 2
> ahc0 at pci2 dev 1 function 0 "Adaptec AIC-7890/1 U2" rev
> 0x00: apic 1
> int 17 (irq 10)
> scsibus0 at ahc0: 16 targets, initiator 7
> sd0 at scsibus0 targ 0 lun 0:
> SCSI3 0/direct
> fixed
> sd0: 70136MB, 512 bytes/sec, 143638992 sec total
> ahc1 at pci2 dev 9 function 0 "Adaptec AIC-7890/1 U2" rev
> 0x00: apic 1
> int 17 (irq 10)
> scsibus1 at ahc1: 16 targets, initiator 7
> cd0 at scsibus1 targ 5 lun 0: SCSI2
> 5/cdrom rem
Re: Can't boot scsi drive from floppy boot prompt?
Eric d'Alibut > > On Thu, Jun 11, 2009 at 7:57 PM, Kenneth R > Westerback wrote: > > > Try floppyB or bsd.rd or cdrom. You are probably missing the driver > > for your scsi card. Kinda hard to tell since you have provided no > > information. > > I am booting with teh same floppy I used to do the installation. What > do you suggest for syntax at the floppy boot prompt? > > I'm guessing that the scsi drive cannot be referenced by an 'hd*' > argument since it is not on one of the four IDE channels. > Seems like the distinctions are wd0 1 2 3 ... IDE drives sd0 1 2 3 ... SCSI drives hd0 1 2 3 are hard drives, might be IDE might be SCSI might be USB flash drives.
Re: newfs_msdos alters disklabel?
Jan Stary wrote: > > This is 4.5 trying to create a FAT partition > on an external (USB) 80G disk. > > > Also, why does disklabel say '16 partitions'? > > Thanks > > Jan fdisk plays with DOS (windows) partitions. There are 4 of them. disklabel plays with OpenBSD partitions. There are 16 of them. This is from a Lenovo T43 booted from 2G USB drive. Fdisk partition 0 (DOS fdisk will call it partition 1) Dos partition This is the same disk as disklable partition i (sd0i) There is also fdisk partition 3 (DOS fdisk would call it partition 4) OpenBSD partition. The OpenBSD space is sd0a and sd0b The c partition refers to the entire disk regardless of who does or does not own any part of it. # fdisk sd0 Disk: sd0 geometry: 3949/16/63 [3981312 Sectors] Offset: 0 Signature: 0xAA55 Starting Ending LBA Info: #: id C H S - C H S [ start:size ] --- 0: 0B 0 1 1 - 1928 6 63 [ 63: 1943802 ] Win95 FAT-32 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused *3: A6 1928 7 1 - 3936 8 63 [ 1943865: 2024190 ] OpenBSD # disklabel sd0 # /dev/rsd0c: ... 16 partitions: #size offset fstype [fsize bsize cpg] a: 1992675 1943865 4.2BSD 2048 163841 # / b:31515 3936540swap c: 39813120 unused i: 1943802 63 MSDOS (This is after several rounds of messing around including completely zeroing the drive, so the disk "geometry" may be the worst possible. So far it seems to work, kinda slow)
