omv-release-upgrade worked but issue with eth0 in the GUI

Zitat von jata1

I did clone my omv6 system first at least and have reverted back so no drama

I only hope all other users will take the same precaution as you did,

Zitat von jata1

digging a bit more and I think OMV7 / Deb12 is creating a network interface called end0 rather than eth0.

Re-reading this, when/if you retry the upgrade, can you check if you have disabled via raspi-config, the predictable names PRIOR to do the upgrade?

I'll try to do this later today to test:

Have a Pi4 running OMV6 and have it disabled.

Run omv-release-upgrade and see how it goes.

1st test; Pi4 4Gb RAM, OMV6 with 6.9.10-5 fully updated with only flashmemory & cputemp plugins.

With Enabled predictable names via raspi-config.

ip a shows eth0:

pi@sinkhole:~ $ ip a
---------
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:54:5e:fd brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.191/24 brd 192.168.1.255 scope global dynamic eth0
       valid_lft 3027sec preferred_lft 3027sec
    inet6 2001:818:e867:d900:dea6:32ff:fe54:5efd/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86384sec preferred_lft 43184sec
    inet6 fe80::dea6:32ff:fe54:5efd/64 scope link
       valid_lft forever preferred_lft forever

Ran omv-release-upgrade inside a screen session

After reboot, ip a still shows eth0: shows end0 [EDIT] Was still asleep, [/EDIT]

pi@sinkhole:~ $ dpkg -l | grep openme
ii  openmediavault                       7.0-16        all          openmediavault - The open network attached storage solution
ii  openmediavault-cputemp               7.0           all          cpu temperature plugin for openmediavault
ii  openmediavault-flashmemory           7.0           all          folder2ram plugin for openmediavault
ii  openmediavault-keyring               1.0.2-2       all          GnuPG archive keys of the openmediavault archive
ii  openmediavault-omvextrasorg          7.0           all          OMV-Extras.org Package Repositories for OpenMediaVault

pi@sinkhole:~ $ ip a
-------------
2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:54:5e:fd brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.191/24 metric 100 brd 192.168.1.255 scope global dynamic end0
       valid_lft 3355sec preferred_lft 3355sec
    inet6 2001:818:e867:d900:dea6:32ff:fe54:5efd/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86396sec preferred_lft 43196sec
    inet6 fe80::dea6:32ff:fe54:5efd/64 scope link
       valid_lft forever preferred_lft forever

Also, this time, the USER pi was added without error to the new GROUP _ssh.

Upgrade went normal and without any issue.

Only "fail" I have in this rig (nothing to do with OMV) is that an IC display stopped working.

It's a Sunfounder PIRONMAN box and has some pip scripts to controller a fan, RGB leds and a display with some info.

This is something that I need to check with the manufacturer to see if the scripts have been ported to Debian12.

[EDIT]

All it took was to reinstall the scripts with v2 from Sunfounder:
5. Set up the Pironman — SunFounder Pironman documentation

RGB strip, fan speed/temp and OLED display running again normal.

[/EDIT]

Next test will be with the Predictable names disabled.

Zitat von macom

What shows the network page in the GUI?

I forgot to tell that eth0 is on DHCP.

OMV7 GUI:

omv-firstaid:

Weird...

Zitat von macom

That is similar to what I see on the HC2.

ip a shows a different name than the GUI and the netplan config.

Rectified the info about ip a on #30. Didn't saw that it was showing end0 when already on OMV7.

Funny thing is, I never lost connection to the Pi when doing the upgrade and the network was/is always ON and with the same IP.

I'll flash back the OMV6 prior to the upgrade but this time will do it with the Predictable names disabled to see it it behaves the same.

Zitat von Soma

I'll flash back the OMV6 prior to the upgrade but this time will do it with the Predictable names disabled to see it it behaves the same.

2nd Test but with Predictable names disabled and this time, the upgrade didn't change the name of the eth0:

pi@sinkhole:~ $ ip a
--------------
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:54:5e:fd brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.191/24 metric 100 brd 192.168.1.255 scope global dynamic eth0
       valid_lft 3351sec preferred_lft 3351sec
    inet6 2001:818:e867:d900:dea6:32ff:fe54:5efd/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 86379sec preferred_lft 43179sec
    inet6 fe80::dea6:32ff:fe54:5efd/64 scope link
       valid_lft forever preferred_lft forever


pi@sinkhole:~ $ sudo cat /etc/netplan/20-openmediavault-eth0.yaml
network:
  ethernets:
    eth0:
      match:
        macaddress: dc:a6:32:54:5e:fd
      accept-ra: true
      dhcp4: yes
      dhcp4-overrides:
        use-dns: true
        use-domains: true
      dhcp6: yes
      dhcp6-overrides:
        use-dns: true
        use-domains: true

Again, never lost ssh or connection on the network.

For me, and regarding Pis upgrade, having Predictable names disabled via raspi-config PRIOR to the upgrade will prevent the wired interface from changing its name.

macom

Does armbian-config exists on your system? Does it have any thing similar to raspi-config to disable the "predictable names"?

I also see that you have STATIC IP && DNS assigned on the other thread: I'll redo again everything with STATIC IP && DNSes to see what happens.