Re: dhclient fallback lease declaration doesn't configure the interface
On Sun 27/04, Kenneth R Westerback wrote:
On Fri, Apr 25, 2014 at 12:31:16PM +0200, Alessandro DE LAURENZIS wrote:
On Tue 22/04, Kenneth Westerback wrote:
Another thing: as highlighted in my initial message, I'm using the
loopback i/f as router address in the lease declaration section:
# Lease declarations (fallback)
lease {
interface trunk0;
fixed-address 192.168.1.103;
option subnet-mask 255.255.255.0;
option routers 127.0.0.1;
option domain-name-servers 127.0.0.1;
option dhcp-lease-time 259200;
renew 4 2020/12/31 23:59:59 UTC;
rebind 4 2020/12/31 23:59:59 UTC;
expire 4 2020/12/31 23:59:59 UTC;
}
(this is the only way to make the router ping-able when trying to
configure a crossover cable connection between 2 PCs). Tomas Bodzar from
misc@ pointed me out it is in a different subnet w.r.t. the fixed
address;
do you think it may be relevant?
Shouldn't be relevant for the dhclient part. Unless there is a check
which I'm not aware of. But I'll look to make sure.
Ken
And now a version that doesn't loop after trying a static lease. :-)
Ken
Hello Ken,
Your last patch doesn't apply to 5.4-Stable as is, some hunks required a
bit of manual code modifications, but finally... it worked!
Now the i/f (both the physical eth and the virtual trunk) are correctly
configured after having acquired the fallback lease.
If you need to experiment with other modifications/adjustments, please
let me know.
Great achievement, in my opinion! Thanks a lot for your support,
kindness and patience.
Cheers
--
Alessandro DE LAURENZIS
[mailto:just22@gmail.com]
LinkedIn: http://it.linkedin.com/in/delaurenzis
OpenBGPD crashing
Hi, We have an issue where every now and then OpenBGPD dies unexpectedly. 2014-04-28T00:00:53.860621+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:02.241936+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:25.538996+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:42.241747+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:52.241976+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:55.690285+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:30:20.227396+01:00 mg1311 bgpd[18490]: nexthop 5.57.80.89 now valid: via 185.25.32.2 2014-04-28T01:02:59.077656+01:00 mg1311 bgpd[18490]: nexthop 185.25.32.22 now valid: directly connected 2014-04-28T01:03:01.762457+01:00 mg1311 bgpd[18490]: dispatch_imsg in main: pipe closed 2014-04-28T01:03:01.762473+01:00 mg1311 bgpd[18490]: Lost child: route decision engine exited 2014-04-28T01:03:01.762756+01:00 mg1311 bgpd[18490]: kernel routing table 0 (Loc-RIB) decoupled 2014-04-28T01:03:01.778424+01:00 mg1311 bgpd[18490]: Terminating This happens maybe once a month on only one of our two firewalls (carp pair). We run a iBGP full mesh between both OpenBSD servers and and our two cisco routers. We also run an iBGP between the two OpenBSD firewalls. Does anyone have any ideas how we can start debugging this? Cheers, Andy.
Re: OpenBGPD crashing
On Mon, Apr 28, 2014 at 09:47:51AM +0100, Andy wrote: Hi, We have an issue where every now and then OpenBGPD dies unexpectedly. 2014-04-28T00:00:53.860621+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:02.241936+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:25.538996+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:42.241747+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:52.241976+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:55.690285+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:30:20.227396+01:00 mg1311 bgpd[18490]: nexthop 5.57.80.89 now valid: via 185.25.32.2 2014-04-28T01:02:59.077656+01:00 mg1311 bgpd[18490]: nexthop 185.25.32.22 now valid: directly connected 2014-04-28T01:03:01.762457+01:00 mg1311 bgpd[18490]: dispatch_imsg in main: pipe closed 2014-04-28T01:03:01.762473+01:00 mg1311 bgpd[18490]: Lost child: route decision engine exited 2014-04-28T01:03:01.762756+01:00 mg1311 bgpd[18490]: kernel routing table 0 (Loc-RIB) decoupled 2014-04-28T01:03:01.778424+01:00 mg1311 bgpd[18490]: Terminating This happens maybe once a month on only one of our two firewalls (carp pair). We run a iBGP full mesh between both OpenBSD servers and and our two cisco routers. We also run an iBGP between the two OpenBSD firewalls. Does anyone have any ideas how we can start debugging this? This is all the log you get? Nothing from the session engine about quitting? The RDE exited via a regualr exit() call and therefor I think that it smells like an issue with the SE. Now why is there no log about the SE crashing or exiting... that should not be possible. Also what version of OpenBSD and therefore bgpd are you using? -- :wq Claudio
Re: OpenBGPD crashing
Hi Claudio, Yea thats all I see in /var/log/messages .. /var/log/daemon had; 2014-04-28T01:02:21.238360+01:00 mg1311 ospf6d[25154]: send_rtmsg: action 1, prefix ::/0: File exists 2014-04-28T01:02:22.048344+01:00 mg1311 ospfd[19386]: desync; scheduling fib reload 2014-04-28T01:02:32.518186+01:00 mg1311 ospfd[19386]: reloading interface list and routing table 2014-04-28T01:02:59.077656+01:00 mg1311 bgpd[18490]: nexthop 185.25.32.22 now valid: directly connected 2014-04-28T01:03:01.762457+01:00 mg1311 bgpd[18490]: dispatch_imsg in main: pipe closed 2014-04-28T01:03:01.762473+01:00 mg1311 bgpd[18490]: Lost child: route decision engine exited 2014-04-28T01:03:01.762756+01:00 mg1311 bgpd[18490]: kernel routing table 0 (Loc-RIB) decoupled 2014-04-28T01:03:01.778424+01:00 mg1311 bgpd[18490]: Terminating It had been up for about a month before this. bgpd on the carp backup is still up and running fine and never dies. It's always been the master that falls over. I might make the other firewall the master and see if it still crashes on the same box. Is there anyway I can increase the session engine logging? Running OpenBSD 5.4 release. Thanks, Andy. On Mon 28 Apr 2014 10:02:27 BST, Claudio Jeker wrote: On Mon, Apr 28, 2014 at 09:47:51AM +0100, Andy wrote: Hi, We have an issue where every now and then OpenBGPD dies unexpectedly. 2014-04-28T00:00:53.860621+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:02.241936+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:25.538996+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:42.241747+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:52.241976+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:01:55.690285+01:00 mg1311 bgpd[18490]: nexthop 2001:7f8:17::a571:1 now valid: via fe80:c::7e69:f6ff:fe68:2210 2014-04-28T00:30:20.227396+01:00 mg1311 bgpd[18490]: nexthop 5.57.80.89 now valid: via 185.25.32.2 2014-04-28T01:02:59.077656+01:00 mg1311 bgpd[18490]: nexthop 185.25.32.22 now valid: directly connected 2014-04-28T01:03:01.762457+01:00 mg1311 bgpd[18490]: dispatch_imsg in main: pipe closed 2014-04-28T01:03:01.762473+01:00 mg1311 bgpd[18490]: Lost child: route decision engine exited 2014-04-28T01:03:01.762756+01:00 mg1311 bgpd[18490]: kernel routing table 0 (Loc-RIB) decoupled 2014-04-28T01:03:01.778424+01:00 mg1311 bgpd[18490]: Terminating This happens maybe once a month on only one of our two firewalls (carp pair). We run a iBGP full mesh between both OpenBSD servers and and our two cisco routers. We also run an iBGP between the two OpenBSD firewalls. Does anyone have any ideas how we can start debugging this? This is all the log you get? Nothing from the session engine about quitting? The RDE exited via a regualr exit() call and therefor I think that it smells like an issue with the SE. Now why is there no log about the SE crashing or exiting... that should not be possible. Also what version of OpenBSD and therefore bgpd are you using?
Re: make with argument in port Makefile
On Sat Apr 26, 2014 at 11:02:44PM +0200, Denis Fondras wrote: Hello all, I'm creating a port for x2goclient (http://www.x2go.org/) but I don't want to build the browser plugin and the documentation, only the heavy client. So instead of the regular make, I have to launch make build_client. https://github.com/jasperla/openbsd-wip/tree/master/x11/x2goclient cheers, Rafael
Re: Get statistics of websites visited without proxy/squid
On 04/25/2014 06:18 PM, James Records wrote: I posted this on reddit a while back, i've been doing this on pfsense for a while don't see why it wouldn't work with OBSD: http://www.reddit.com/r/PFSENSE/comments/1vn51f/monitoring_question_analysis_of_uris_by_ip_address/ basically install httpry and do this: httpry -i em1 | grep 'GET\|POST' | logger Jim Thank you. This is exactly what I've looked for. I'll try to calculate number of unique Get or Post requests per IP and that's all. # httpry -i em0 -d -o /home/httpry/em0.log -u nobody -f timestamp,source-ip,host,method -m get,post 'tcp port 80' # # egrep GET|POST em0.log | uniq | head -10 2014-04-28 12:27:03 192.168.5.32pagestat.mmi.bemobile.uaGET 2014-04-28 12:27:05 192.168.5.32pbs.twimg.com GET 2014-04-28 12:27:07 192.168.5.32glavcom.ua GET 2014-04-28 12:27:07 192.168.5.32pagestat.mmi.bemobile.uaGET 2014-04-28 12:27:07 192.168.5.32 ep01.irl.amz.nimbus.bitdefender.net POST 2014-04-28 12:27:07 192.168.5.32hq.nimbus.bitdefender.net POST 2014-04-28 12:27:07 192.168.5.32glavcom.ua GET 2014-04-28 12:27:08 192.168.5.32glavcom.ua GET 2014-04-28 12:27:08 192.168.5.32informers.ukr.net GET 2014-04-28 12:27:08 192.168.5.32glavcom.ua GET
Re: Getting stylus working on Thinkpad X61 tablet
yes, my new thinkpad edge works with the tablet perfectly fine. On 2014 Apr 27 (Sun) at 16:46:31 -0700 (-0700), Bryan Linton wrote: :Ping. : :Can anyone confirm or deny whether or not the newer Thinkpad :tablets' styluses work as an input device? I see that there is a :usbtablet(4) driver in xenocara, with people reporting success :using external tablets, so it would probably be a matter of :whether or not the newer Thinkpads still use a serial-based wacom :device as opposed to a USB-based one. : :Since FreeBSD supports these serial based tablets with a kernel :module and the linuxwacom driver, I'm assuming that it's probably :going to require more than just a simple port to get this working. : :Even http://cgit.freedesktop.org/~whot/xf86-input-wacom/ which was :created after X.org removed the X.org wacom input driver in favor of :just using the linuxwacom driver says it still needs a driver to :bridge the kernel-userland parts. : :-- :Bryan : :On 2014-04-21 16:26:36, Bryan Linton b...@shoshoni.info wrote: : Hello list, : : [dmesg attached below] : : I recently purchased a Thinkpad X61 tablet (manufactured circa : 2006) and have not been able to get the stylus to work with the : screen in OpenBSD. It worked fine with the Windows 7 install that : came with it, so I know the hardware itself is fine. : : From reading some old posts to misc@, I have used config to : change the address and IRQ of com0 to 0x200 and IRQ 5, which has : caused com0 to show up in the dmesg. : : If I run cu -l /dev/cua00 and write on the screen, I get output : while I am writing that abruptly stops when I move the stylus : away, so I think it's a matter of a driver issue between X11 and : the hardware. : : Unfortunately, emails from the time-period suggest running the : linuxwacom driver, which doesn't compile due to Linuxisms in the : code. Even the older releases don't compile on a modern system. : : Other posts have indicated that adding a wacom driver section to : xorg.conf will work. While there is a wacom(4) listed in : xorg.conf(5), it is not installed on OpenBSD. In fact, : % cd /usr/xenocara; find . -iname *wacom* -print returns : nothing at all, and indeed none of the examples posted have worked : or given any hint in Xorg.0.log that the tablet functionality is : detected at all. : : Is there any way to get the tablet functionality to work on : OpenBSD? Is it simply a matter of a missing wacom(4) driver? Do : any of the later Thinkpad tablets (some of which I've read use USB : connections internally instead of serial connections) work any : better? : : I would really love to be able to use a stylus to write directly : on the screen; writing complicated Japanese kanji with a mouse can : become somewhat tedious after a while, so any help is greatly : appreciated, even if it's only There are no plans to support this : on OpenBSD so that I can start looking into another option (a PDA : perhaps?). : : Thank you. : : -- : Bryan : : : OpenBSD 5.5-current (GENERIC.MP) #43: Sat Apr 12 09:39:12 MDT 2014 : dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP : cpu0: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz (GenuineIntel 686-class) 799 MHz : 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF : real mem = 3194179584 (3046MB) : avail mem = 3129528320 (2984MB) : mpath0 at root : scsibus0 at mpath0: 256 targets : mainbus0 at root : bios0 at mainbus0: AT/286+ BIOS, date 03/22/11, BIOS32 rev. 0 @ 0xfdc80, SMBIOS rev. 2.4 @ 0xe0010 (63 entries) : bios0: vendor LENOVO version 7SET39WW (1.25 ) date 03/22/2011 : bios0: LENOVO 7764CTO : acpi0 at bios0: rev 2 : acpi0: sleep states S0 S3 S4 S5 : acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT ASF! SSDT SSDT SSDT SSDT : acpi0: wakeup devices LID_(S3) SLPB(S3) DURT(S3) IGBE(S4) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) EHC0(S3) [...] : acpitimer0 at acpi0: 3579545 Hz, 24 bits : acpiec0 at acpi0 : acpimadt0 at acpi0 addr 0xfee0: PC-AT compat : cpu0 at mainbus0: apid 0 (boot processor) : mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges : cpu0: apic clock running at 199MHz : cpu0: mwait min=64, max=64, C-substates=0.2.2.2.2, IBE : cpu1 at mainbus0: apid 1 (application processor) : cpu1: Intel(R) Core(TM)2 Duo CPU L7500 @ 1.60GHz (GenuineIntel 686-class) 1.60 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,PBE,NXE,LONG,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,LAHF,PERF : ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins : ioapic0: misconfigured as apic 2, remapped to apid 1 : acpimcfg0 at acpi0 addr 0xf000, bus 0-63 : acpihpet0 at acpi0: 14318179 Hz : acpiprt0 at acpi0: bus 0 (PCI0) : acpiprt1 at acpi0:
Resolving the Lan users hostnames
Dear misc readers, Currently i am using dnsmasq because it inserts in the dns cache the hostname sended to the dhcp server it provides. It's neat, and well done by dnsmasq. But it is not in base, moreover DNSSEC support is relying on some new crypto lib, and some features ( static route did creates some problems in the past. ) Reading unbound doc i saw i can insert name to be resolved but i have to reload each time, so to resolve the LAN clients hostnames i would need to - trigger a script when a lease is given (mostly depends the backend of the dhcp server) - write a script that tranalates the leases into a host/ip list for unbound - reload unbound conf IMHO: EWW Any opinion on doing this properly in-base ? - Priority to using in base openBSD software is my choice, because i rely on the openBSD community to outsmart my choices ! - Best regards, -- - () ascii ribbon campaign - against html e-mail /\
Re: Resolving the Lan users hostnames
On Mon, Apr 28, 2014 at 10:53, sven falempin wrote: Reading unbound doc i saw i can insert name to be resolved but i have to reload each time, so to resolve the LAN clients hostnames i would need to - trigger a script when a lease is given (mostly depends the backend of the dhcp server) - write a script that tranalates the leases into a host/ip list for unbound - reload unbound conf IMHO: EWW Any opinion on doing this properly in-base ? At some point in the distant past, I did this: http://marc.info/?l=openbsd-techm=118039557923827
pkg_add http://${REDIRECT}
Hello,
I'm trying to invent a oneliner for installing a specific package. The
problem is, the destination file is a redirect file forwarding a request
to a target package. The result is:
# pkg_add -v
http://10bees-agent.s3-website-us-east-1.amazonaws.com/openbsd/agent.tgz
parsing agent
Package name is not consistent ???
Error from
http://10bees-agent.s3-website-us-east-1.amazonaws.com/openbsd/agent.tgz
Redirected to
http://10bees-agent.s3-website-us-east-1.amazonaws.com/openbsd/10bees-1.1.55.20.tgz
ftp: Writing -: Broken pipe
--- 10bees-1.1.55.20 ---
Can't install 10bees-1.1.55.20: bad package
The idea behind that is that 'agent.tgz' will always point to the latest
version, so there is no need for users to keep track of the versions.
This pattern works on all other platforms so I'd like to keep that
approach on OpenBSD too, if possible.
Anyways, Package name is not consistent ??? suggests that the problem
is that 'agent.tgz' doesn't follow packages-specs(7). But pkg_add
continues with the install and is failing on ftp - or so it would appear.
So far I figured tow solutions:
- change 'agent.tgz' to match packages-specs(7), didn't check that and
would like to avoid that,
- give users a longer command, like ftp http://${REDIRECT} pkg_add
${PACKAGE}, but that doesn't look too good.
Is there a better way than the second option? I cannot rely on replacing
${FETCH_CMD} as this needs to run on out-of-the-box OpenBSD.
Best regards,
ML
default -inet6 route removed after suspend on wifi
Hi, I recently set up IPv6 on my wifi AP in addition to IPv4. I use rtadvd on the AP and rtsol on the client. When I suspend my laptop and resume after some time (for the test, I waited 30 minutes), the default route is not present anymore. But this occurs only on my wifi, not when I use a wired connection. If I want to have the default route again, I just need to `sudo sh /etc/netstart` and it's okay. I did $ route -n show -inet6 route6.wan.ok before suspend and $ route -n show -inet6 route6.wan.nok after resuming and diff route6.wan.nok route6.wan.ok diff gives: 6a7 defaultfe80::1ebd:b9ff:feff:b711%iwn0 UG 1 60 -56 iwn0 12,13c13 2001:910:1322:2::/64 link#2 UC 10 - 4 iwn0 2001:910:1322:2::1 1c:bd:b9:ff:b7:11 UHLc 08 - 4 iwn0 --- 2001:910:1322:2::/64 link#2 UC 00 - 4 iwn0 23c23 fe80::1ebd:b9ff:feff:b711%iwn0 1c:bd:b9:ff:b7:11 UHLc 0 11 - 4 iwn0 --- fe80::1ebd:b9ff:feff:b711%iwn0 1c:bd:b9:ff:b7:11 UHLc 13 - 4 iwn0 The previous snapshot I was running was Apr 20 (I didn't have IPv6 on the AP before), and now I tested with the last one and it's still happening. dmesg: OpenBSD 5.5-current (GENERIC.MP) #85: Sun Apr 27 09:24:33 MDT 2014 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1982316544 (1890MB) avail mem = 1920884736 (1831MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries) bios0: vendor LENOVO version 6QET46WW (1.16 ) date 06/07/2010 bios0: LENOVO 3680AQ1 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.52 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.0, IBE cpu1 at mainbus0: apid 4 (application processor) cpu1: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz, 2660.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 2, package 0 ioapic0 at mainbus0: apid 1 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 -1 (PEG_) acpiprt2 at acpi0: bus 13 (EXP1) acpiprt3 at acpi0: bus -1 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpiprt5 at acpi0: bus 5 (EXP4) acpiprt6 at acpi0: bus 2 (EXP5) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2 acpitz0 at acpi0: critical temperature is 100 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4835 serial 1199 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 2660 MHz: speeds: 2400, 2399, 2266, 2133, 1999, 1866, 1733, 1599, 1466, 1333, 1199 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core Host rev 0x02 vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1280x800 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 3400 MEI rev 0x06 at pci0 dev 22 function 0 not configured puc0 at pci0 dev 22 function 3 Intel 3400 KT rev 0x06: ports: 1 com com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo com4: probed fifo depth: 0 bytes em0 at pci0 dev 25 function 0 Intel 82577LM rev 0x06: msi, address f0:de:f1:09:c7:94 ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x06: apic 1 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 3400 HD Audio rev 0x06: msi
Problem booting OpenBSD-current AMD64
I've installed OpenBSD-current AMD64 on my new computer without problems, but as soon as I reboot the system, it freezes in the post. The only way to go past the post is wiping the first few megabytes of the harddisk using another computer and than start again. After installing I can't even enter the bios setup. The system contains the following components: - Motherboard: Gigabyte GA-B85M-DS3H - CPU: Intel Core i3 4130T - Memory: Kingston ValueRAM 8 GB DDR3-1600 Kit I've configured the bios the following way: - Windows 8 Features: Other OS - Boot Mode Selection: Legacy Only - VGA Support: Auto (Enables legacy option) The system is working since I can install and run Ubuntu 14.04 AMD64 without problems. Any suggestions on how to fix this? Kind regards, Martijn Rijkeboer
Re: pkg_add http://${REDIRECT}
You're not really explaining what you're trying to do, especially considering you're redirecting agent.tgz to something that has a completely different name... So far, I see a very non transparent redirect to something having nothing in common with the name you're trying to fetch. This looks very sketchy at best. Expect no help from me until you actually explain what you want to do in explicit terms. It looks like you're trying to pull a fast one on pkg_add, and obviously pkg_add isn't duped... you tell it you want to install something, and you end up grabbing some other thing. No way !
Re: pkg_add http://${REDIRECT}
On Mon, Apr 28, 2014 at 3:05 PM, Michał Lesiak mic...@10bees.com wrote:
Hello,
I'm trying to invent a oneliner for installing a specific package. The
problem is, the destination file is a redirect file forwarding a request to
a target package. The result is:
# pkg_add -v
http://10bees-agent.s3-website-us-east-1.amazonaws.com/openbsd/agent.tgz
parsing agent
Package name is not consistent ???
Error from
http://10bees-agent.s3-website-us-east-1.amazonaws.com/openbsd/agent.tgz
Redirected to
http://10bees-agent.s3-website-us-east-1.amazonaws.com/openbsd/10bees-1.1.55.20.tgz
ftp: Writing -: Broken pipe
--- 10bees-1.1.55.20 ---
Can't install 10bees-1.1.55.20: bad package
The idea behind that is that 'agent.tgz' will always point to the latest
version, so there is no need for users to keep track of the versions.
Given package name-version{0,1}.tgz in a $PKG_PATH directory, `pkg_add
name` will match both and present the user with a choice.
Given package name-version1.tgz only, `pkg_add name` doesn't prompt
because there's a single directory entry match.
I would exclusively populate the directory with entries, symlinks or
otherwise, pertaining to the latest version of packages.
Re: Problem booting OpenBSD-current AMD64
Martijn Rijkeboer [mart...@bunix.org] wrote: The system is working since I can install and run Ubuntu 14.04 AMD64 without problems. Any suggestions on how to fix this? Ubuntu (server) 14.04 supports UEFI so it's hard to tell what you are seeing here. Perhaps you could explain what happens when you try and boot OpenBSD? Let's start with 1. what medium are you using and 2. what does it display when it tries to boot?
Re: UEFI Support
Tekk [t...@parlementum.net] wrote: Is OpenBSD capable of booting from pure UEFI yet? This basically translates to Is there a UEFI capable bootloader since I don't have secure boot or anything turned on. I'm rather happy not having to deal with the bios at the moment so having to turn legacy boot back on would be really annoying. Turn legacy boot back on. OpenBSD doesn't support GPT yet. OpenBSD doesn't support UEFI yet. Bitrig did GPT and that might not be so hard to import. There is kernel GPT partition code, kernel uuid code, and a gdisk utility (Son of fdisk) UEFI requires quite a bit of work. At a minimum, we need new boot blocks AND there's kernel BIOS interface code that needs a look. Or rather, an EFI replacement. FreeBSD did this. It's worth looking at if you want a serious understanding of why it's more annoying to read your question than it is for you to turn on Legacy mode. See Tasks: https://wiki.freebsd.org/UEFI
On the way...Yay!
Snip from an email this morning (GMT+10): Shipment from Canada via small packet AIR is confirmed via: CN22 28 April 2014 (ship date). OpenBSD 5.5 CD sets. Now I just have to wait for airmail and customs here in Australia. If you have been slack about ordering now is the time to do it. Lots of new adventures with the first OS to kill the Y2K38 bug. Remember that sales of CD and various swag help the progress of the great product that is OpenBSD. Thanks to everyone who played any part in getting the latest disks to me. *** NOTE *** Please DO NOT CC me. I am 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.
Re: On the way...Yay!
On 4/28/14, Rod Whitworth glis...@witworx.com wrote: Snip from an email this morning (GMT+10): Shipment from Canada via small packet AIR is confirmed via: CN22 28 April 2014 (ship date). Ha! I got you beat... my notice came Sunday evening ;) Just checked and my stuff (at least the CDs) are in Great Falls, MT as of tonight. --patrick OpenBSD 5.5 CD sets. Now I just have to wait for airmail and customs here in Australia. If you have been slack about ordering now is the time to do it. Lots of new adventures with the first OS to kill the Y2K38 bug. Remember that sales of CD and various swag help the progress of the great product that is OpenBSD. Thanks to everyone who played any part in getting the latest disks to me.
Re: Problem booting OpenBSD-current AMD64
On Tue, Apr 29, 2014 at 12:49 AM, Martijn Rijkeboer mart...@bunix.orgwrote: I've installed OpenBSD-current AMD64 on my new computer without problems, but as soon as I reboot the system, it freezes in the post. The only way to go past the post is wiping the first few megabytes of the harddisk using another computer and than start again. After installing I can't even enter the bios setup. Can you collect dmesg from installer and later on output or screenshot during boot what it tries to do? The system contains the following components: - Motherboard: Gigabyte GA-B85M-DS3H - CPU: Intel Core i3 4130T - Memory: Kingston ValueRAM 8 GB DDR3-1600 Kit I've configured the bios the following way: - Windows 8 Features: Other OS - Boot Mode Selection: Legacy Only - VGA Support: Auto (Enables legacy option) The system is working since I can install and run Ubuntu 14.04 AMD64 without problems. At least lspci -v output will be fine from some Linux Any suggestions on how to fix this? Kind regards, Martijn Rijkeboer
sendmail in afterboot(8)
After installing a fresh system (current/amd64), I noticed that afterboot(8) still mentions Sendmail as the default mailer: Sendmail The default mail agent on OpenBSD is sendmail(8). Details on how to configure an alternative mailer are documented in mailer.conf(5). Is this known? Below is a small diff, but I suppose the smtpd autors will want to be more specific. Jan --- afterboot.8.origTue Apr 29 07:43:08 2014 +++ afterboot.8 Tue Apr 29 07:50:26 2014 @@ -471,47 +471,31 @@ dumper: root Run .Xr newaliases 8 after changes. -.Ss Sendmail +.Ss Smtpd The default mail agent on .Ox is -.Xr sendmail 8 . +.Xr smtpd 8 . Details on how to configure an alternative mailer are documented in .Xr mailer.conf 5 . .Pp .Ox ships with a default -.Pa /etc/mail/localhost.cf -file that will work for simple installations; it was generated from -.Pa openbsd-localhost.mc -in -.Pa /usr/share/sendmail/cf . -Please see -.Pa /usr/share/sendmail/README -for information on generating your own sendmail configuration files. -For the default installation, sendmail is configured to only accept +.Pa /etc/mail/smtpd.conf +file that will work for simple installations. +See +.Xr smtpd.conf 5 . +for information on configuring more complex setups. +For the default installation, smptd is configured to only accept connections from the local host. This makes it possible to send mail locally, but not receive mail from remote servers, which is ideal if you have one central incoming mail machine and several clients. -To cause sendmail to accept external network connections, modify the -.Va sendmail_flags -variable in -.Pa /etc/rc.conf.local -to use the -.Pa /etc/mail/sendmail.cf -file in accordance with the comments therein. -This file was generated from -.Pa openbsd-proto.mc . -.Pp -Note that sendmail now also listens on port 587 by default. -This is to implement the RFC 6409 message submission protocol. -You may disable this via the -.Ic no_default_msa -option in your sendmail .mc file. -See -.Pa /usr/share/sendmail/README -for more information. +To cause smtpd to accept external network connections, modify the +.Va listen +directive in +.Pa /etc/mail/smtpd.conf +to include the interfaces to listen at. .Ss Daily, weekly, monthly scripts Review .Xr daily 8
