Soekris Net6501 reboot fails

2015-08-12 Thread Brook Milligan
I have been having fairly consistent trouble getting Soekris Net6501-70 boxes to complete a reboot cycle. They seem to run perfectly fine once booted, but then lock up with the red light on when I try to reboot. System information: NetBSD amd64 7.99.18 from 201505311600Z with a GENERIC kernel.

Re: Quick question about NetBSD source code

2015-08-12 Thread J. Lewis Muir
On 8/12/15 8:05 AM, Alexey Smirnov wrote: > Hello > Go a quick question here. > On the documentation we have several types of geting src. > First is to download five archives from > > *ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-6.1/source/sets/ > > Seconf is do download a lot more from > > *ftp://ftp.N

Re: filesystem change monitoring

2015-08-12 Thread matthew sporleder
On Wed, Aug 12, 2015 at 7:35 AM, Emmanuel Dreyfus wrote: > Ryo ONODERA wrote: > >> I have no idea about large hierarchy, > > Simple: try to mirror a hiearchy with more than kern.maxfiles nodes, you > loose. > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org https://wiki.net

Quick question about NetBSD source code

2015-08-12 Thread Alexey Smirnov
Hello Go a quick question here. On the documentation we have several types of geting src. First is to download five archives from *ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-6.1/source/sets/ * *Seconf is do download a lot more from* *ftp://f

Re: filesystem change monitoring

2015-08-12 Thread Malcolm Herbert
On Wed, Aug 12, 2015 at 04:23:39AM +, Christian Koch wrote: |On Tue, Aug 11, 2015 at 02:44:10PM +, Emmanuel Dreyfus wrote: |> Do we have a smart way to monitor a whole filesystem hierarchy for |> changes? kqueue seems a good answer at a glance, but as far as I |> understand, I need to setup

rsync/permissions issue

2015-08-12 Thread William A. Mahaffey III
I am trying to get my NetBSD 6.1.5 64-bit server to backup my RPiB+ which is serving as the ntp & timed master on my LAN. I tried the following w/ the observed results: [wam@4256EE1, ~, 8:05:45am] 525 % sudo rsync -avviiz --delete --exclude '*.o' --exclude '*.a' root@rpitimer::root /home/rs

Re: Please advise usb wifi device for raspberry pi 2, NetBSD 7

2015-08-12 Thread Matt Thomas
> On Aug 11, 2015, at 9:17 PM, Christian Koch wrote: > > On Tue, Aug 11, 2015 at 06:43:33PM +0530, Mayuresh wrote: >> I am looking to purchase a new USB wifi dongle for Raspberry Pi 2 for >> NetBSD 7.0. > > If you're lucky, some man page in chapter 4 will provide a list of what works. > Otherwi

Re: filesystem change monitoring

2015-08-12 Thread Emmanuel Dreyfus
Ryo ONODERA wrote: > I have no idea about large hierarchy, Simple: try to mirror a hiearchy with more than kern.maxfiles nodes, you loose. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org

Re: filesystem change monitoring

2015-08-12 Thread Ryo ONODERA
Hi, From: m...@netbsd.org (Emmanuel Dreyfus), Date: Wed, 12 Aug 2015 11:55:36 +0200 > Ryo ONODERA wrote: > >> If lsyncd uses Linux's inotofy, you can link libinotify from >> pkgsrc/devel/libinotify. It is a result of GSoC and implemented with >> kqueue/kevent (according to DESCR). > > Sure, th

Re: filesystem change monitoring

2015-08-12 Thread Emmanuel Dreyfus
Martin Husemann wrote: > We should really have a recursive "something below this directory has > changed" kevent filter - but the problem is that we can not easily > attach a path (or subpath) to the struct kevent that userland gets back > as notification. Userland could find out using fts(3)?

Re: filesystem change monitoring

2015-08-12 Thread Martin Husemann
On Wed, Aug 12, 2015 at 11:53:18AM +0200, Emmanuel Dreyfus wrote: > To be clear: this is a limitation of the kqueue interface, hence > specific to NetBSD. We should really have a recursive "something below this directory has changed" kevent filter - but the problem is that we can not easily attach

Re: filesystem change monitoring

2015-08-12 Thread Emmanuel Dreyfus
Ryo ONODERA wrote: > If lsyncd uses Linux's inotofy, you can link libinotify from > pkgsrc/devel/libinotify. It is a result of GSoC and implemented with > kqueue/kevent (according to DESCR). Sure, that works, but kqueue needs to open a file descriptor for every monitored file, hence you quickly

Re: filesystem change monitoring

2015-08-12 Thread Emmanuel Dreyfus
Emmanuel Dreyfus wrote: > Yes, I tried porting lsyncd to NetBSD: you quickly hit kern.maxfiles > because it needs to open a file descriptor for every single node monitored. To be clear: this is a limitation of the kqueue interface, hence specific to NetBSD. -- Emmanuel Dreyfus http://hcpnet.fr

Re: filesystem change monitoring

2015-08-12 Thread Ryo ONODERA
Hi, From: Emmanuel Dreyfus , Date: Wed, 12 Aug 2015 08:47:49 + > On Wed, Aug 12, 2015 at 04:19:06PM +1000, Malcolm Herbert wrote: >> I have used this in the past to implement a poor-man's cluster solution >> using lsyncd and rsyncd > > Yes, I tried porting lsyncd to NetBSD: you quickly hit

Re: filesystem change monitoring

2015-08-12 Thread Emmanuel Dreyfus
On Wed, Aug 12, 2015 at 04:19:06PM +1000, Malcolm Herbert wrote: > I have used this in the past to implement a poor-man's cluster solution > using lsyncd and rsyncd Yes, I tried porting lsyncd to NetBSD: you quickly hit kern.maxfiles because it needs to open a file descriptor for every single nod

Re: 7.0_RC1 slow boot

2015-08-12 Thread Alan Barrett
On Sun, 09 Aug 2015, Frank Wille wrote: Alan Barrett wrote: It's not just checking whether a pid is alive, it's checking whether the PID represents a shell running /etc/rc, to guard against pids being recycled. That part is probably unnecessary. I can also reduce the number of times _have_rc_