Unsuccessful upgrade, system with changed network settings
-
Yesterday I reinstalled from scratch the RC1 image (26 Feb) amd64.
All I did was:
- allow upgrades from unsigned images
- set a gateway
- set the DNS servers (NO DHCP override)
- set the netmask and WAN IP address
- set the upgrade URL to the beta build server
After that, I tried up upgrade to the then current nightly.
Result: on the web interface the upgrade got stuck somwhere at 94% or so, but the system seemed to have rebooted.
All looks fine, but I can't ping the system or log in. After a while I notice that:
a) the WAN interface reset itself to DHCP, so I set the IP address again.
So now I can log in, but the system can't check upgrade availability, further investigation shows that
b) DNS servers have DHCP override ENABLED again, I change that back to hardwired DNS servers, but the system still can't check upgrade availability. I dig further, and I notice that
c) the gateway, while still defined, ceased to be the default gateway, and that the WAN interface has no gateway defined.Right now, the system is still on premises as I continue to play, but had this been deployed, that would have been a very expensive joke…
These kind of settings can't just "get lost" because they require console level intervention, which just isn't an option for an system sitting in a colocation server halfway across the continent.Right now, I'm just upgrading again to the latest snapshot (Sat Mar 12 02:08:09 EST 2011), to see if this issue persists...
-
Right now, the system is still on premises as I continue to play, but had this been deployed, that would have been a very expensive joke…
These kind of settings can't just "get lost" because they require console level intervention, which just isn't an option for an system sitting in a colocation server halfway across the continent.You're right that would be very bad.
However you do realise that the daily snapshots are for testing and may well contain experimental code?
There is a reason that they are unsigned. You shouldn't be using anything but the signed releases for 'production'.That said by using the daily snapshots and reporting back the results you are helping to develop the project, thank you. :)
Are you using the NanoBSD image, booting from flash?
Steve
-
Right now, the system is still on premises as I continue to play, but had this been deployed, that would have been a very expensive joke…
These kind of settings can't just "get lost" because they require console level intervention, which just isn't an option for an system sitting in a colocation server halfway across the continent.You're right that would be very bad.
However you do realise that the daily snapshots are for testing and may well contain experimental code?
There is a reason that they are unsigned. You shouldn't be using anything but the signed releases for 'production'.That said by using the daily snapshots and reporting back the results you are helping to develop the project, thank you. :)
Are you using the NanoBSD image, booting from flash?
I understand this is still in testing, however:
a) this is a release-candidate phase, not Alpha, Beta or some development branch of v2.5
b) this was a completely unmodified system (no packages)
c) this is the most rudimentary functionality: simply retaining the settings for IP address, Netmask, Gateway and DNS Servers.So we're talking as plane-jane as it gets and about as core as functionality can get, so it's a bit unexpected to have that sort of thing happen this late in the game.
BTY: I'm not using NanoBSD. There's no amd64 architecture image, plus also no option to install the FreeSwitch module.
-
I understand your frustration but:
a) Although 2.0 is now in the RC phase the daily snapshots are not release candidates. As the developers work to fix the bugs in RC1 there is, unfortunately, the possibility that new bugs are introduced. Personally I would stick to the rc1 release unless there is a bug that's causing you difficulty.c) I agree.
I should have known there's no 64bit Nano image, my bad! :-[
Steve