#NAbox 4.2.1 upgrade incomplete and VM reboots

44 messages · Page 1 of 1 (latest)

trim juniper
#

I'm upgrading to v4.2.1 but the 'OS Upgrade' step does not complete and the upgrade process has rebooted the VM 4 times so far.

Any ideas what is going on?

admin@nabox4 ~ $ last reboot
reboot system boot 6.12.87-flatcar Tue May 19 10:01 still running
reboot system boot 6.12.87-flatcar Tue May 19 09:55 - 10:01 (00:06)
reboot system boot 6.12.87-flatcar Tue May 19 09:48 - 09:54 (00:06)
reboot system boot 6.12.87-flatcar Tue May 19 09:42 - 09:48 (00:06)
reboot system boot 6.12.87-flatcar Tue May 19 09:35 - 09:41 (00:06)
admin@nabox4 ~ $ sudo su -
nabox4 ~ #
Broadcast message from root@nabox4 (Tue 2026-05-19 10:01:30 UTC):

The system will reboot now!


Broadcast message from root@nabox4 (Tue 2026-05-19 10:01:30 UTC):

The system will reboot now!

nabox4 ~ #
Update Status: locksmithd - Reboot planned
Broadcast message from locksmithd at 2026-05-19 10:03:04.808403674 +0000 UTC m=
System reboot in 5 minutes!

lapis cliff
#

@violet glacier

trim juniper
#

Now up to 29 reboots!

violet glacier
#

ouch.

#

when you get a chance as soon as you get the shel, remove /etc/nabox/status.json

#

what does df -h say?

trim juniper
#

admin@nabox4 ~ $ sudo rm /etc/nabox/status.json admin@nabox4 ~ $ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda9 5.8G 2.5G 3.0G 45% / sysext 1.9G 8.0K 1.9G 1% /usr /dev/sda6 128M 5.5M 119M 5% /oem overlay 5.8G 2.5G 3.0G 45% /etc devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 775M 1.7M 773M 1% /run tmpfs 1.9G 0 1.9G 0% /media tmpfs 1.9G 0 1.9G 0% /tmp tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-resolved.service /dev/sdb 492G 143G 327G 31% /data tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-networkd.service tmpfs 1.0M 0 1.0M 0% /run/credentials/getty@tty1.service /dev/sda1 127M 72M 55M 57% /boot tmpfs 388M 4.0K 388M 1% /run/user/1000 tmpfs 1.0M 0 1.0M 0% /run/credentials/serial-getty@ttyS0.service

violet glacier
#

Mmm, ok capacity is looking good. What is the running version now ?

dc images
naboxd version
cat /etc/lsb-release
trim juniper
#

admin@nabox4 ~ $ dc images
CONTAINER REPOSITORY TAG IMAGE ID SIZE
alertmanager alertmanager latest 6519630d2dcc 72MB
caddy caddy latest aac61abc4024 58.6MB
cadvisor cadvisor latest a31688ab1366 75.1MB
grafana grafana-oss latest ffe38074db41 1.07GB
havrest havrest latest 141652aea6cc 28.9MB
node-exporter node-exporter latest 47509d7f7c15 25.8MB
victoria-metrics victoria-metrics latest 5bcd3c377fe8 33.6MB
vmagent vmagent latest de4deec58be9 28.5MB
vmalert vmalert latest 06a41aa5d2d5 32.9MB
admin@nabox4 ~ $ naboxd version
v4.2.1-0-g1ad0b40
admin@nabox4 ~ $ cat /etc/lsb-release
DISTRIB_ID="Flatcar Container Linux by Kinvolk"
DISTRIB_RELEASE=4593.2.1
DISTRIB_CODENAME="Oklo"
DISTRIB_DESCRIPTION="Flatcar Container Linux by Kinvolk 4593.2.1 (Oklo)"

violet glacier
#

Looking good, except maybe havrest that is 8ee126cb46f2 for me, but maybe running a test release

trim juniper
#

i have uploaded the logs now i think

gleaming dome
#

same thing here, updated nabox over gui, it downloaded the update automatically and reboots now every 5 minutes, it's stuck at "OS Upgrade", reboots the vm and as soon the containers are up it reboots the vm again and again, the api gives me always the same issue, i also added the support bundle to the upload site

violet glacier
#

Can you save aside status.json ?

#

@trim juniper were you running update direct from web ui or did you upload it ?

gleaming dome
#
admin@llsvnabox01 ~ $ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda9       5.8G  3.1G  2.4G  56% /
sysext          1.9G  8.0K  1.9G   1% /usr
/dev/sda6       128M  5.5M  119M   5% /oem
overlay         5.8G  3.1G  2.4G  56% /etc
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           775M  1.7M  773M   1% /run
tmpfs           1.9G     0  1.9G   0% /media
tmpfs           1.9G     0  1.9G   0% /tmp
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-journald.service
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-resolved.service
/dev/sdb        196G  2.7G  184G   2% /data
tmpfs           1.0M     0  1.0M   0% /run/credentials/systemd-networkd.service
tmpfs           1.0M     0  1.0M   0% /run/credentials/getty@tty1.service
tmpfs           388M  4.0K  388M   1% /run/user/1000
/dev/sda1       127M   71M   56M  56% /boot
tmpfs           1.0M     0  1.0M   0% /run/credentials/serial-getty@ttyS0.service

df -h looks fine to me

#
admin@llsvnabox01 ~ $ dc images
naboxd version
cat /etc/lsb-release

WARN[0000] The "tG9KLy" variable is not set. Defaulting to a blank string.
WARN[0000] The "tG9KLy" variable is not set. Defaulting to a blank string.
WARN[0000] The "tG9KLy" variable is not set. Defaulting to a blank string.
WARN[0000] The "tG9KLy" variable is not set. Defaulting to a blank string.
……a few more WARN[0000]……
WARN[0000] The "tG9KLy" variable is not set. Defaulting to a blank string.
WARN[0000] The "tG9KLy" variable is not set. Defaulting to a blank string.
WARN[0000] The "tG9KLy" variable is not set. Defaulting to a blank string.
WARN[0000] The "tG9KLy" variable is not set. Defaulting to a blank string.
CONTAINER           REPOSITORY          TAG                 IMAGE ID            SIZE
alertmanager        alertmanager        latest              6519630d2dcc        72MB
caddy               caddy               latest              aac61abc4024        58.6MB
cadvisor            cadvisor            latest              a31688ab1366        75.1MB
grafana             grafana-oss         latest              ffe38074db41        1.07GB
havrest             havrest             latest              141652aea6cc        28.9MB
node-exporter       node-exporter       latest              47509d7f7c15        25.8MB
victoria-metrics    victoria-metrics    latest              5bcd3c377fe8        33.6MB
vmagent             vmagent             latest              de4deec58be9        28.5MB
vmalert             vmalert             latest              06a41aa5d2d5        32.9MB

v4.2.1-0-g1ad0b40

DISTRIB_ID="Flatcar Container Linux by Kinvolk"
DISTRIB_RELEASE=4593.2.1
DISTRIB_CODENAME="Oklo"
DISTRIB_DESCRIPTION="Flatcar Container Linux by Kinvolk 4593.2.1 (Oklo)"

this also looks fine to me

flat flare
#

I’m having the same issue as well. I uploaded the package for the upgrade.

violet glacier
#

Thanks. Please move aside status.json to stop reboot loop

#

And then go in /data/uploads/upgrade

gleaming dome
#

i already did that and it indeed stopped after a reboot

violet glacier
#
flatcar-update --to-version  4593.2.1 --to-payload flatcar_production_update.gz --extension oem-vmware.gz
#

That should tell us what’s happening.

gleaming dome
#
llsvnabox01 /data/uploads # mkdir upgrade
llsvnabox01 /data/uploads # cd upgrade/
llsvnabox01 /data/uploads/upgrade # cd /data/uploads/upgrade
llsvnabox01 /data/uploads/upgrade # flatcar-update --to-version  4593.2.1 --to-payload flatcar_production_update.gz --extension oem-vmware.gz
/usr/bin/flatcar-update: line 244: flatcar_production_update.gz: No such file or directory
llsvnabox01 /data/uploads/upgrade #
violet glacier
#

you probably acknowledged the upgrade already ? ls -al ?

trim juniper
violet glacier
#

maybe that's the common factor

trim juniper
violet glacier
#

Click Upgrade ? does it work ?

trim juniper
#

yea, it takes me to this screen and clicking done clears the popup:

violet glacier
#

so it worked ?

trim juniper
#

yup

violet glacier
#

ok. On my side I tried an automatic upgrade and it worked without issues. I'll keep an eye on this issue

flat flare
#

Seems stable for me now. Flatcar 4593.2.1. Thanks Yann!

rugged finch
#

Hi All / @violet glacier We have a window tomorrow to update our nabox system, I just wanted to check on the status of 4.2.1 ... Is it regarded as being a solid release? Should we anticipate any specific issues? I noticed this thread, where at least a couple of users reported problems with/after the update. FYI: We're currently running nabox 4.0.9 + a recent nightly build of Harvest. Thanks in advance!

violet glacier
#

Hey Robb, There seem to be an issue wih some deployment, possibly when on limited disk space. I would take a snapshot beforehand, and keep https://nabox.org/kb/increase-root-partition-size-on-existing-deployments/ in mind

If stuck in a reboot loop, deleting /etc/nabox/status.json during the ssh availability windows does the trick.

Sorry I wasn't able to pin that one down yet

rugged finch
#

OK, thanks for the instant feedback! I'll run that past my team mate before we decide. We have already arranged for a VMware snapshot :-). If we decide to go ahead, is there anything we should try to capture i.e. that might help you with debugging?

#

I checked the document pointer: "If available space is low, increase the system disk size for the VM and reboot". Can you define"low"? I have no access the the nabox right now, is there a seperate root filesystem, or is it all one large fs? I recall that last week the nabox system dashboard was showing me 65% disk usage, but I can't remember if that was for the whole system or just for a "/data" filesystem.

#

(This is a 4.0.9 system, originally installed new using 4.0.9, and the disk space has been expanded at least a couple times since.)

violet glacier
#

Low would be <3.5GB I think

#

Which is not /data but the root fs

rugged finch
#

danke nochmals!

#

Er - sorry! I meant "Thanks again!" 😉

gleaming night
#

I have same issue with reboot loop

#

deleting this file did not fix my reboot loop: /etc/nabox/status.json

violet glacier
#

Well that's a new one. You have time for a remote session ?

gleaming night
#

Can you DM me?

rugged finch
#

I see that the root fs is at 55% 3 GB used and 2.5 available ... any suggestions about what I could delete?

rugged finch
#

Aha, journalctl --rotate followed by a --vacuum won me 540MB