Image file is corrupt
-
Geez this started to happen on weekly basis…
-
Geez this started to happen on weekly basis…
Getting pretty ridiculous, yes… Also, the build logs just do not work. Plus, I don't the whole migration/redirection/whatnot mess. What's the difference between
https://snapshots.pfsense.org/FreeBSD_RELENG_8_3/amd64/pfSense_RELENG_2_1/updates/?C=M;O=D (proper non-broken stuff)
https://snapshots.pfsense.org/FreeBSD_RELENG_8_3/amd64/pfSense_RELENG_2_1/.updaters/ (periodically broken junk with dial-up speed upload) -
Is it just me, or all the files now simply missing?
-
Is it just me, or all the files now simply missing?
No, you are obviously right:
http://snapshots.pfsense.org/FreeBSD_RELENG_8_3/amd64/pfSense_RELENG_2_1/.updaters/
is empty, but not
http://snapshots.pfsense.org/FreeBSD_RELENG_8_3/i386/pfSense_RELENG_2_1/.updaters/Interesting is the fact, that timestamps vary by about one day: 26-Mar-2014 versus 27-Mar-2014.
When I successfully upgraded last time it was the corrected i386 version from 26-Mar-2014. Altogether very strange. Why does nobody fix it?
Regards,
Peter -
When a release is being finalized we always remove the public snapshots once we start labeling them -RELEASE.
The fact that they are missing is a good thing, it means 2.1.1-RELEASE is in its final testing. :-)
-
When a release is being finalized we always remove the public snapshots once we start labeling them -RELEASE.
The fact that they are missing is a good thing, it means 2.1.1-RELEASE is in its final testing. :-)
That's good news, any indication as to when the images will be available?
I tried to do an update with this image:
https://snapshots.pfsense.org/FreeBSD_RELENG_8_3/amd64/pfSense_RELENG_2_1/updates/pfSense-Full-Update-2.1.1-PRERELEASE-amd64-20140326-1350.tgz
but the upgrade just hangs. So I'm hoping that a solid image comes out soon.
-
jimp: But what about the 7 unfixed in redmine?
How do the release Project work? Does "-RELEASE" final testing mean like "feature freeze", eg no more bugs or features will be added, but the existing tickets will be solved?
-
jimp: But what about the 7 unfixed in redmine?
There is only one now. Some were moved, some were fixed. If it's not a regression, it may have to wait for 2.2. People will constantly find things that are broken but they can't all make 2.1.1 unless it's a major showstopper or regression.
How do the release Project work? Does "-RELEASE" final testing mean like "feature freeze", eg no more bugs or features will be added, but the existing tickets will be solved?
When it gets to the point where -RELEASE images are built, usually that means that no more changes of any kind will be made unless they are regressions, showstoppers, or otherwise deemed important to correct.
-
When a release is being finalized we always remove the public snapshots once we start labeling them -RELEASE.
The fact that they are missing is a good thing, it means 2.1.1-RELEASE is in its final testing. :-)
Is there an updater url that we should switch to for prerelease?
-
No, at this point I would not expect any more snapshots. If you return your update URL to the stock URL (uncheck the box for an alternate) then it should pull the -RELEASE when it comes.
-
Thanks for the last post to know that snapshots are done for 2.1.1. I now know why I couldn't update my primary to be the same version as the backup (both on PRERELEASE but I was testing different versions by a month for driver reasons).
The firmware autoupdate settings page is a bit confusing I think to those that don't know how it works…
The checkbox says... "Use an unofficial server for firmware upgrades".
If you un-check that box and then select a default from the dropdown selection, The box gets checked again and populated with the default url. The dropdown box still says on the selection you chose. The dropdown selection goes blank after you save.
Since the box is checked then another system admin just looking at that screen would not know if the selection is an official url or not. The text would seem to mean that you are using an unofficial version because the box is checked. The text further below that says that the signature is not checked if an unofficial updater url is configured.
"NOTE: When a custom URL is configured, the system will not verify the image has an official digital signature"
I realize that is just how it works but just thought I would bring it up.
-
If you uncheck "Use an unofficial server for firmware upgrades" the manifest drop-down does not matter. It uses the internally coded one.
The drop-down is a list of alternate update servers in case your system is not pointing to the correct one and you need to force it there. Some older pfSense releases shipped with the internal default update URL pointing to snapshots when it should have been the release servers, so the official ones are in the manifest to be chosen if people need them, but they aren't necessary.
If you uncheck "Use an unofficial server for firmware upgrades" and uncheck "Unsigned images" then it will pull from the official servers automatically and expect a valid signature. That's how most people should be running except when testing snapshots. At that point it doesn't matter what's in the URL input box on the page as it is ignored.
-
Thanks. I thought it was required to select something from the dropdown. Changing my systems now :).
