[SOLVED] pve6to7 Resolved node IP not configured or active

[pmisch]

Hi,

I'm on proxmox 6.4 and I would like to upgrade to 7.
I made sure backups are there and stuff but when I run pve6to6 command I get this output:

pve6to7 
= CHECKING VERSION INFORMATION FOR PVE PACKAGES =
 
Checking for package updates..
PASS: all packages uptodate
 
Checking proxmox-ve package version..
PASS: proxmox-ve package has version >= 6.4-1
 
Checking running kernel version..
PASS: expected running kernel '5.4.119-1-pve'.
 
= CHECKING CLUSTER HEALTH/SETTINGS =
 
SKIP: standalone node.
 
= CHECKING HYPER-CONVERGED CEPH STATUS =
 
SKIP: no hyper-converged ceph setup detected!
 
= CHECKING CONFIGURED STORAGES =
 
PASS: storage 'filer' enabled and active.
PASS: storage 'isos' enabled and active.
PASS: storage 'local' enabled and active.
PASS: storage 'local-lvm' enabled and active.
PASS: storage 'lxctemplates' enabled and active.
PASS: storage 'vmdata' enabled and active.
 
= MISCELLANEOUS CHECKS =
 
INFO: Checking common daemon services..
PASS: systemd unit 'pveproxy.service' is in state 'active'
PASS: systemd unit 'pvedaemon.service' is in state 'active'
PASS: systemd unit 'pvestatd.service' is in state 'active'
INFO: Checking for running guests..
WARN: 6 running guest(s) detected - consider migrating or stopping them.
INFO: Checking if the local node's hostname '3470s' is resolvable..
INFO: Checking if resolved IP is configured on local node..
FAIL: Resolved node IP '2001:aaaa:bbbb:7300:21b:21ff:fec1:a8c0' not configured or active for '3470s'
INFO: Checking backup retention settings..
INFO: storage 'local' - no backup retention settings defined - by default, PVE 7.x will no longer keep only the last backup, but all backups
PASS: no problems found.
INFO: checking CIFS credential location..
PASS: no CIFS credentials at outdated location found.
INFO: Checking custom roles for pool permissions..
INFO: Checking node and guest description/note legnth..
PASS: All node config descriptions fit in the new limit of 64 KiB
PASS: All guest config descriptions fit in the new limit of 8 KiB
INFO: Checking container configs for deprecated lxc.cgroup entries
PASS: No legacy 'lxc.cgroup' keys found.
INFO: Checking storage content type configuration..
PASS: no problems found
INFO: Checking if the suite for the Debian security repository is correct..
INFO: Make sure to change the suite of the Debian security repository from 'buster/updates' to 'bullseye-security' - in /etc/apt/sources.list:6
SKIP: NOTE: Expensive checks, like CT cgroupv2 compat, not performed without '--full' parameter
 
= SUMMARY =
 
TOTAL:    23
PASSED:   18
SKIPPED:  3
WARNINGS: 1
FAILURES: 1
 
ATTENTION: Please check the output for detailed information!
Try to solve the problems one at a time and then run this checklist tool again.

This is my ip a output:

5: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:1b:21:c1:a8:c0 brd ff:ff:ff:ff:ff:ff
    inet 10.10.129.4/26 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 2001:aaaa:bbbb:7300:21b:21ff:fec1:a8c0/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::21b:21ff:fec1:a8c0/64 scope link 
       valid_lft forever preferred_lft forever

This is my network config file (snippet):
auto vmbr0
iface vmbr0 inet static
address 10.10.129.4/26
gateway 10.10.129.1
bridge-ports enp2s0
bridge-stp off
bridge-fd 0
gatway 10.10.129.1
#MGMT

iface vmbr0 inet6 static
address 2001:aaaa:bbbb:7300:21b:21ff:fec1:a8c0/64
gateway 2001:aaaa:bbbb:7300::1

FYI the hostname in DNS does not resolve a IPv4 address but only AAAA IPv6.

 

[mira]

Does the entry in /etc/hosts match that?

 

[pmisch]

Yes, it does match 100%

 

[mira]

Please provide your /etc/hosts file.

 

[pmisch]

I chose to ignore the problem and the update went without any problems.

Thats how my hosts looks like.

127.0.0.1 localhost.localdomain localhost
10.10.101.137 3470s.mydomain.de 3470s
2001:aaaa:bbbb:7300:21b:21ff:fec1:a8c0 3470s.mydomain.de 3470s

 

[mira]

I tried to reproduce it here with a similar /etc/hosts entry, but couldn't.
Ignoring the problem in this case is fine.