Upgrade 7.4 to 8, not reacheable after reboot

milk

New Member
Jun 26, 2023
20
0
1
Good morning everyone.

Over the weekend I tried to upgrade several times from 7.4 to 8 on an empty ovh test machine with this intel(r) xeon(r) cpu e3-1270 v6 @ 3.80ghz and NVME

the upgrade works without errors until the machine is rebooted.

When restarted, the machine is unreachable.

I checked through ovh rescue mode several times, also tried to downgrade the kernel with proxmox-boot-tool kernel, but without success.

I don't find particular errors in the logs through the rescue mode, but after trying and trying again I went back to 7.4

Do you think it's a kernel problem? or to the network configuration? or is the machine too old to host version 8?

Do you have any ideas?

Thank you all
 
Hi,

Can you ping the PVE after restarted?

Can you check from the NIC name and compare it with the network configuration?
 
Hi,

Can you ping the PVE after restarted?

Can you check from the NIC name and compare it with the network configuration?
Hi Thanks for the reply.

machine does not respond to ping after reboot

I checked the interfaces.

I don't know how to check from the name of the NIC card actually used by the PVE via the ovh rescue mode.

Could they be different between PMX and Rescue Mode? I think so but maybe I'm wrong.

Thank you for the answer, because in fact it could be a network problem.
 
You can issue the following command:

Bash:
udevadm info -q all -p /sys/class/net/<Adapter Name> | grep ID_NET_NAME


Replace <Adapter Name> with the chosen adapter `ip a`

Then you have to check on the output:

Code:
E: ID_NET_NAME_MAC=
E: ID_NET_NAME_PATH=

And compare the result of the PVE network configuration in /etc/network/interfaces.
 
Hi Thanks for the reply.

machine does not respond to ping after reboot

I checked the interfaces.

I don't know how to check from the name of the NIC card actually used by the PVE via the ovh rescue mode.

Could they be different between PMX and Rescue Mode? I think so but maybe I'm wrong.

Thank you for the answer, because in fact it could be a network problem.
Hi,
There is some issues with the latest OVH templates, cloud init is updated.
I faced almost same issues yesterday.
Have a look there : https://forum.proxmox.com/threads/strange-proxmox-errors.129419/#post-567511
 
You can issue the following command:

Bash:
udevadm info -q all -p /sys/class/net/<Adapter Name> | grep ID_NET_NAME


Replace <Adapter Name> with the chosen adapter `ip a`

Then you have to check on the output:

Code:
E: ID_NET_NAME_MAC=
E: ID_NET_NAME_PATH=

And compare the result of the PVE network configuration in /etc/network/interfaces.
Ok thanks, I'll try to upgrade again now
 
Ok thanks, I'll try to upgrade again now
I have tried both solution 1 and solution 2 and have not been successful, the server still won't restart.

@Moayad - 1 solution the tests I did are these:

udevadm info -q all -p /sys/class/net/<Adapter Name> | grep ID_NET_NAME

Via OVH Rescue Mode:
the NIC is eth0 and not eno1 but inside my interfaces file are eno1

Comparing this command with a 7.4 server in production the result is:

E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp4s0
E: ID_NET_NAME=eno1

While through OVH Rescue it is:

E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp5s0
E: ID_NET_NAME=eno1

changing eth0 in my interface didn't fix and changing to enp5s0 instead it didn't solve

@flotho 2 solution the tests I did are these:

My Hosts file don't have the problem describe in this post: https://forum.proxmox.com/threads/strange-proxmox-errors.129419/#post-567511

But for the 3 possible solutions
-disable cloud-ini
touch /etc/cloud/cloud-init.disabled -

I've tryed this one

-comment line in /etc/cloud/cloud.cfg
- update-etc-hosts

This line is not present in my file

-restore the old conf that was kept during the upgrade (before deleting, check that you have the cloud.cfg.dpkg-old in /etc/cloud)
rm /etc/cloud/cloud.cfg; mv /etc/cloud/cloud.cfg.dpkg-old /etc/cloud/cloud.cfg

I' don't have cloud.cfg.dpkg-old in my directory


Compared to what I tried over the weekend this time I didn't try to select a different kernel via proxmox-boot-tool

I just followed yours advice but for now the server can only be reached via OVH Rescue after upgrade to version 8 and reboot.


Any Idea?

Thanks all :)
 
This is my interface file:

auto lo
iface lo inet loopback

#iface enp5s0 inet manual
iface eno1 inet manual

iface eno2 inet manual

auto vmbr0
iface vmbr0 inet static
address xx.xx.xx.xx/24
gateway xx.xx.xx.xx
bridge-ports eno1
bridge-stp off
bridge-fd 0
hwaddress xx:xx:xx:xx:xx:xx

iface vmbr0 inet6 static
address 2001:xx:xx:xx::/64


------------------------------------------------------------------------------------
Other info:

root@rescue-customer-eu:/etc/network# uname -r
6.1.32-mod-std
----------------------------------------------------------------------------------------

root@rescue-customer-eu:/etc/network# pveversion -v
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
proxmox-ve: 8.0.1 (running kernel: 6.1.32-mod-std)
pve-manager: 8.0.3 (running version: 8.0.3/bbf3993334bfa916)
pve-kernel-6.2: 8.0.2
pve-kernel-5.15: 7.4-4
pve-kernel-6.2.16-3-pve: 6.2.16-3
pve-kernel-5.15.108-1-pve: 5.15.108-1
ceph-fuse: 16.2.11+ds-2
corosync: 3.1.7-pve3
criu: 3.17.1-2
glusterfs-client: 10.3-5
ifupdown2: 3.2.0-1+pmx2
libjs-extjs: 7.0.0-3
libknet1: 1.25-pve1
libproxmox-acme-perl: 1.4.6
libproxmox-backup-qemu0: 1.4.0
libproxmox-rs-perl: 0.3.0
libpve-access-control: 8.0.3
libpve-apiclient-perl: 3.3.1
libpve-common-perl: 8.0.5
libpve-guest-common-perl: 5.0.3
libpve-http-server-perl: 5.0.3
libpve-rs-perl: 0.8.3
libpve-storage-perl: 8.0.1
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 5.0.2-4
lxcfs: 5.0.3-pve3
novnc-pve: 1.4.0-2
proxmox-backup-client: 2.99.0-1
proxmox-backup-file-restore: 2.99.0-1
proxmox-kernel-helper: 8.0.2
proxmox-mail-forward: 0.2.0
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.1
proxmox-widget-toolkit: 4.0.5
pve-cluster: 8.0.1
pve-container: 5.0.4
pve-docs: 8.0.3
pve-edk2-firmware: 3.20230228-4
pve-firewall: 5.0.2
pve-firmware: 3.7-1
pve-ha-manager: 4.0.2
pve-i18n: 3.0.4
pve-qemu-kvm: 8.0.2-3
pve-xtermjs: 4.16.0-3
qemu-server: 8.0.6
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.1.12-pve1
--------------------------------------------------------------------------------------------------------

root@rescue-customer-eu:/etc/network# proxmox-boot-tool kernel list
Manually selected kernels:
None.

Automatically selected kernels:
5.15.108-1-pve
6.2.16-3-pve
 
ok now i disable the bridge in my interface file

This is my interface file:

auto lo
iface lo inet loopback

#iface enp5s0 inet manual
#iface eno1 inet manual

#iface eno2 inet manual

auto eno1
iface eno1 inet static
address xx.xx.xx.xx/24
gateway xx.xx.xx.xx
#bridge-ports eno1
#bridge-stp off
#bridge-fd 0
hwaddress xx:xx:xx:xx:xx:xx

#iface vmbr0 inet6 static
#address 2001:xx:xx:xx::/64

The result are that server ping but i've no access via web or via ssh

Any idea? Thanks!
 
nothing I tried to reinstall the 7.4 version of ovh and redo the upgrade to version 8 but on the first reboot, the server stops pinging..
 
I'm sure that the issue related to the network issue, since you can't able to ping or browse your server after the reboot.

Can you ask the OVH if they can provide you a VNC remote to see the network config and the output of `ip a`?
 
I believe that in my Standard service plan it is not possible to open a ticket to ask about this, but maybe I'm wrong
I'm sure that the issue related to the network issue, since you can't able to ping or browse your server after the reboot.

Can you ask the OVH if they can provide you a VNC remote to see the network config and the output of `ip a`?
I believe that in my Standard service plan it is not possible to open a ticket to ask about this, but maybe I'm wrong
 
I'm sure that the issue related to the network issue, since you can't able to ping or browse your server after the reboot.

Can you ask the OVH if they can provide you a VNC remote to see the network config and the output of `ip a`?
This is the result frome rescue mode:

root@rescue-customer-eu (ns3072585.ip-xx-xx-xx.eu) ~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 32:00:b1:34:f4:5d brd ff:ff:ff:ff:ff:ff
3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 86:48:32:3a:81:e0 brd ff:ff:ff:ff:ff:ff
4: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32
link/ether 62:93:94:74:4c:ea brd ff:ff:ff:ff:ff:ff
5: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32
link/ether 02:e0:4d:07:f0:af brd ff:ff:ff:ff:ff:ff
6: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether a4:bf:01:17:6b:28 brd ff:ff:ff:ff:ff:ff
inet xx.xx.xx.xx/24 brd xx.xx.xx.255 scope global dynamic eth0
valid_lft 86317sec preferred_lft 86317sec
inet6 fe80::a6bf:1ff:fe17:6b28/64 scope link
valid_lft forever preferred_lft forever
7: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether a4:bf:01:17:6b:29 brd ff:ff:ff:ff:ff:ff
8: teql0: <NOARP> mtu 1500 qdisc noop state DOWN group default qlen 100
link/void
9: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/ipip 0.0.0.0 brd 0.0.0.0
10: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
link/gre 0.0.0.0 brd 0.0.0.0
11: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
12: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
13: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
14: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
link/tunnel6 :: brd ::
----------------------------------------------------------------------------------------------------

root@rescue-customer-eu (ns3072585.ip-xx-xx-xx.eu) ~ # udevadm info -q all -p /sys/class/net/eth0 | grep ID_NET_NAME
E: ID_NET_NAME_MAC=enxa4bf01176b28
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp5s0
-----------------------------------------------------------------------------------------------------

In the meantime I tried reinstalling 7.4 + pve kernel 6.1 again and the boot was fine

I did the upgrade again with kernel 6.1 installed and noticed this error :debian /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf

post update before reboot i noticed bind9 wasnt installed i installed it and rebooted and the server didnt come back up
 
Last edited:
Are you using ZFS? I read about Grub issues with ZFS after upgrading...
I'ts a default fresh blank ovh proxmox installation, i think zfs are installed but i don't use it. thank for the suggest i search for understand this possible issue
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!