Same problem here ! Claude AI to the rescue !!!
**Title:** Database upgrade fails after apt upgrade (6.1.x → 6.2.0) — "Cannot read image file" during nxdbmgr upgrade, causes DB version mismatch
**Environment:**
- Debian 13 (trixie)
- NetXMS Server 6.2.0 (from official packages.netxms.org repo)
- PostgreSQL backend
**Problem:**
After an unattended `apt-get upgrade`, the `netxms-server` package was upgraded from 6.1.x to 6.2.0, but the PostgreSQL database schema was not migrated automatically. `netxmsd` refused to start, and both `systemctl status` and manual foreground start showed:
```
Your database has format version 61.36, but server is compiled for version 62.30
```
Running `nxdbmgr upgrade` (after `nxdbmgr unlock`) got stuck partway through the migration chain:
```
Upgrading from version 62.12 to 62.13
Cannot read image file "/var/lib/netxms/images/<GUID>"
Rolling back last stage due to upgrade errors...
Database upgrade failed
```
Reinstalling the `netxms-server` package (`apt-get install --reinstall netxms-server`) did not restore the missing file, confirming it wasn't shipped with the package but was expected to already exist on disk (likely a system default icon that had gone missing from `/var/lib/netxms/images/` at some point in the past, unrelated to this upgrade).
Querying the DB confirmed it was a default system icon (category "Network Objects"), not a custom-uploaded image:
```sql
SELECT guid, name, category, mimetype FROM images WHERE guid='<GUID>';
```
After creating a placeholder file for that GUID, the next `nxdbmgr upgrade` attempt immediately hit the *same* error for a different GUID — turned out **8 image files total** were missing from `/var/lib/netxms/images/` relative to what the `images` table in the database referenced.
**Solution:**
1. Export all image GUIDs referenced in the database:
```bash
su postgres -c "psql -d netxms -t -A -c \"SELECT guid FROM images;\""
```
2. For any GUID with no matching file in `/var/lib/netxms/images/`, generate a placeholder PNG (any valid PNG works — nxdbmgr just needs to read a valid image to complete that migration stage; the actual icon can be re-uploaded later via the Console if desired):
```bash
while read guid; do
f="/var/lib/netxms/images/$guid"
if [ ! -f "$f" ]; then
convert -size 32x32 xc:white png:"$f"
fi
done < guid_list.txt
```
(Note: use `png:/path` prefix with ImageMagick's `convert`, otherwise it fails to guess the output format from a GUID filename with no extension.)
3. Re-run:
```bash
nxdbmgr unlock
nxdbmgr upgrade
```
This completed the full migration chain (62.12 → 62.30) successfully.
4. Verified with:
```bash
nxdbmgr check -f
```
All checks passed, no data errors.
5. Started the service and confirmed it was listening on the client port (4701):
```bash
/etc/init.d/netxmsd start
ss -tlnp | grep 4701
```
**Root cause (suspected):** the missing image files on disk likely predate this incident — possibly from an earlier migration, manual cleanup, or incomplete restore — and only surfaced now because the 6.2.0 upgrade path added a migration step that reads every referenced image file from disk. Might be worth a defensive check in `nxdbmgr` to skip/warn on missing image files instead of hard-failing the whole migration, since this can silently block server upgrades on installations with long histories.
**Title:** Database upgrade fails after apt upgrade (6.1.x → 6.2.0) — "Cannot read image file" during nxdbmgr upgrade, causes DB version mismatch
**Environment:**
- Debian 13 (trixie)
- NetXMS Server 6.2.0 (from official packages.netxms.org repo)
- PostgreSQL backend
**Problem:**
After an unattended `apt-get upgrade`, the `netxms-server` package was upgraded from 6.1.x to 6.2.0, but the PostgreSQL database schema was not migrated automatically. `netxmsd` refused to start, and both `systemctl status` and manual foreground start showed:
```
Your database has format version 61.36, but server is compiled for version 62.30
```
Running `nxdbmgr upgrade` (after `nxdbmgr unlock`) got stuck partway through the migration chain:
```
Upgrading from version 62.12 to 62.13
Cannot read image file "/var/lib/netxms/images/<GUID>"
Rolling back last stage due to upgrade errors...
Database upgrade failed
```
Reinstalling the `netxms-server` package (`apt-get install --reinstall netxms-server`) did not restore the missing file, confirming it wasn't shipped with the package but was expected to already exist on disk (likely a system default icon that had gone missing from `/var/lib/netxms/images/` at some point in the past, unrelated to this upgrade).
Querying the DB confirmed it was a default system icon (category "Network Objects"), not a custom-uploaded image:
```sql
SELECT guid, name, category, mimetype FROM images WHERE guid='<GUID>';
```
After creating a placeholder file for that GUID, the next `nxdbmgr upgrade` attempt immediately hit the *same* error for a different GUID — turned out **8 image files total** were missing from `/var/lib/netxms/images/` relative to what the `images` table in the database referenced.
**Solution:**
1. Export all image GUIDs referenced in the database:
```bash
su postgres -c "psql -d netxms -t -A -c \"SELECT guid FROM images;\""
```
2. For any GUID with no matching file in `/var/lib/netxms/images/`, generate a placeholder PNG (any valid PNG works — nxdbmgr just needs to read a valid image to complete that migration stage; the actual icon can be re-uploaded later via the Console if desired):
```bash
while read guid; do
f="/var/lib/netxms/images/$guid"
if [ ! -f "$f" ]; then
convert -size 32x32 xc:white png:"$f"
fi
done < guid_list.txt
```
(Note: use `png:/path` prefix with ImageMagick's `convert`, otherwise it fails to guess the output format from a GUID filename with no extension.)
3. Re-run:
```bash
nxdbmgr unlock
nxdbmgr upgrade
```
This completed the full migration chain (62.12 → 62.30) successfully.
4. Verified with:
```bash
nxdbmgr check -f
```
All checks passed, no data errors.
5. Started the service and confirmed it was listening on the client port (4701):
```bash
/etc/init.d/netxmsd start
ss -tlnp | grep 4701
```
**Root cause (suspected):** the missing image files on disk likely predate this incident — possibly from an earlier migration, manual cleanup, or incomplete restore — and only surfaced now because the 6.2.0 upgrade path added a migration step that reads every referenced image file from disk. Might be worth a defensive check in `nxdbmgr` to skip/warn on missing image files instead of hard-failing the whole migration, since this can silently block server upgrades on installations with long histories.
