Snap builder problems
-
2 issues after 13th sept, the nanobssd snap file size increase to more than double for some reason and secondly using those snaps u cant even upgrade so the last snap working for me is the 13th sept only and no snaps work after that and just now i saw the builder has stopped building also.
-
Yes, it's known. A lot of work has been happening on the builder.
Whenever the next run finishes, it should be back to normal sizes. The cause of that has already been fixed.
-
Just out of curiosity, How long does the builder take to create the packages? By looking at past timestamps it appears to be around 6 hours?
-
New snapshots don't run continually. It can take several hours per run, and after a run it sleeps for a while until someone makes a commit, or 24 hours pass.
The i386 builder can take 6 hours or so, and a lot of that time is spend on the nanobsd images, since the files are quite large to work on.
-
any1 reading this i recommend staying on the 13th September snap coz lof of builder updates have been going on and latest snap have quiet a bit of things broken, not to mention cron is broken on the 13th September snap
-
I haven't been keeping up with other threads today, but what is broken on a snap from yesterday or today? I haven't heard of any issues.
-
limiter is broken, cron is broken and that breaks most other stuff such as pppoe re connections etc
-
I saw the ticket for cron, but do you have any proof that is more than a cosmetic problem? (e.g. something besides pppoe reconnect failing that is handled by a cron job)
Not sure about limiters, I haven't seen anything about that. Is there a thread or ticket?
I would hesitate to say those are "major" issues for most people, really.
-
High latency on non-default interfaces. Incorrect rules reloading on system bootup/link state change. These effectively break PBR, load balancing and traffic shaping.
-
High latency on non-default interfaces. Incorrect rules reloading on system bootup/link state change. These effectively break PBR, load balancing and traffic shaping.
I just updated to a snapshot from yesterday afternoon and had some issues with pfSctl blocking on boot (making my second WAN DHCP connection on OPT1 seem to hang at boot), and similar issues with my OpenVPN connections, but that's it.
My OPT1 WAN latency once up is normal (54ms), my rules load fine, my load balancing and policy-based routing work fine.
Haven't checked traffic shaping though, but I'd suspect it's also fine.
-
High latency on non-default interfaces. Incorrect rules reloading on system bootup/link state change. These effectively break PBR, load balancing and traffic shaping.
I just updated to a snapshot from yesterday afternoon and had some issues with pfSctl blocking on boot (making my second WAN DHCP connection on OPT1 seem to hang at boot), and similar issues with my OpenVPN connections, but that's it.
My OPT1 WAN latency once up is normal (54ms), my rules load fine, my load balancing and policy-based routing work fine.
Haven't checked traffic shaping though, but I'd suspect it's also fine.
The 'incorrect rule reloading' refers to this four-month unfixed issue:
http://forum.pfsense.org/index.php/topic,25405.msg131941.html#msg131941
I've sent a detailed report to emarl.
The 'high latency' refers to my recent topic on Sep 16-17 snapshot.
-
any1 reading this i recommend staying on the 13th September snap coz lof of builder updates have been going on and latest snap have quiet a bit of things broken, not to mention cron is broken on the 13th September snap
13 sep snapshots had gateway/loadbalancing issues. I'd recommend snapshots fro the 9th or earlier
-
some issue with latest snap include
Sep 19 11:57:06 php: : The command '/sbin/kldload dummynet' returned exit code '1', the output was 'kldload: can't load dummynet: No such file or directory'
Sep 19 11:57:06 php: : The command '/sbin/ipfw /tmp/rules.limiter' returned exit code '1', the output was 'Line 2: setsockopt(IP_DUMMYNET_CONFIGURE): Protocol not available'
-
There are a bunch of modules missing from the builds still, it's being worked on now. That's what is breaking CP/dummynet/etc.
-
As mentioned elsewhere, this should be fixed in the most recent set of snapshots.
-
dummynet seems to have been solved but cron still remains an issue
-
dummynet seems to have been solved but cron still remains an issue
I'm not sure what is not working for you, but cron is operating properly in current snapshots. I can add a cron job and it executes as expected in the normal cron entries in config.xml. The items the system runs by minicron work as well.
If something you expect to happen by cron is not happening, the problem is likely elsewhere, not with cron, unless you have more evidence.
-
its just that during boot, when it says configuring cron, instead of saying done, it says no process found so basically something goes wrong there.
-
No, it's trying to -HUP cron if it's already running, which at that point it isn't.
Look later in the boot log, cron is actually started farther down. I'm committing a fix to suppress that error you're seeing.
