Losing Ethernet with Latest OMV Update

I have not had this issue updating any of my OMV systems over the last few days - but they all have a static ip set in the network settings.

I am wondering if I might have an issue with any of my OMV systems if I change from static to dhcp in the network settings.

Good to know if there is a way to determine if any of my systems are 'at risk' so I can update/fix them in a controlled way.

My thinking is this:

• systems with latest naming for network interface should be fine (e.g. enp3s0)
• systems with eth0 or end0 might have a problem - this could impact a lot of SBC setups...
• what happens with systems that have bridge network setups (e.g. br0 linked to interface eth0)
• any other scenarios?

I have a number of SBC systems running OMV7. They have either eth0 or end0 as the interface name. Should I look to fix these systems?

So I tested changing the network settings to dhcp from static on 2 OMV systems. One with end0 and the other with eth0 interface names.

In all my tests everything was fine - no issues with network config. I do have static dhcp addresses set on my router so the dhcp assigned addresses are the same as the static. Maybe this prevents the issue?

I was expecting the interface name to change from eth0 or end0 to a predictable name but this did not happen.

Just calling out here that I had the same issue. Seems interface name changed to end0 with some update.

Confirmed that had to run omv-firstaid to reconfigure NIC (annoyingly, running headless so had to lug it all out to the living room).

Quote from jata1

So I tested changing the network settings to dhcp from static on 2 OMV systems. One with end0 and the other with eth0 interface names.

In all my tests everything was fine - no issues with network config. I do have static dhcp addresses set on my router so the dhcp assigned addresses are the same as the static. Maybe this prevents the issue?

I was expecting the interface name to change from eth0 or end0 to a predictable name but this did not happen.

I'm thinking too that its a good idea to collect some facts/ideas whats causing the issues (on a high level first).

The situation I'm observing at the moment on my side:

I'm having 3 RPi4B:

RPi-OMV

- currently running Debian12 (bookworm)

- upgraded from Debian11 and OMV6 through upgrade script last year

- dhcp (router configured to static ip)

- eth0 (never changed)

- no issue w this 7.5.0 update (tested on a copy of system-ssd)

RPi-Homebridge

- currently running Debian12 (bookworm)

- upgraded from Debian11 through upgrade script from Homebridge

- dhcp (router configured to static ip)

- eth0 (never changed)

RPi-Test&Play

- currently running Debian12 (bookworm) & GUI

- initially installed last year w Debian12

- dhcp

- eth0 (never changed)

What all have in common:

They were initially installed via "Raspberry Pi Imager" - I don't know, but maybe this is a special version?

There was at no time "end0" or any other adapter-name - allways eth0

I'm really curious whats causing the differences in behavor. Just to be prepared ...

I did not run the update yet, I would like to check upfront if my OMV install would be affected as well. If I check my netplan configuration I see that the "modern" names are already used. In my case enp2s0.

Does this mean I can safely run the update or is there something else I should check?

Quote from ojtindrum

Are you headless or you have a display and keyboard?

Headless. Finding a way to connect keyboard and monitor would be painful...

That's why I would like to make sure my system is unlikely to be affected by this (potential) problem.

Quote from chielmi

I did not run the update yet, I would like to check upfront if my OMV install would be affected as well. If I check my netplan configuration I see that the "modern" names are already used. In my case enp2s0.

Does this mean I can safely run the update or is there something else I should check?

I would create a full-backup/restore of your system disk on a spare one, boot from this copy and test the update.

In case of desaster just change your disks again.

I think this is the most safe way.

And the way I did it also at the end.

OMV cannot find network after update

Won't allow me to use omv-firstaid

I have CLI access direct

Thanks for the suggestions! Unfortunately this is not easy to do, my system doesn't have a SD system disk. Also a full backup/restore on a spare disk is a bit of a pita...

I hope somebody can give a short checklist of configuration item to inspect prior to running the update, to mitigate/lower the risk of any issues.

version is 7.5.0.1 sandworm

running raspberry pi5

changed admin password but will not work

I have successfully given the eth0 a valid IP address using sudo imv-firstaid and can now access to omv interface.

All seems normal BUT I need to modify the configuration to make it find an IP address on boot up

All is well it seems that omv-firstaid has made the necessary modifications to boot sequence and it boots, and finds IP address from DHCP.

The login screen saying use omv-firstaid could mention using sudo to make it work. I spent hours trying to login then being told I wasn't authorised

Thanks for replying

Inaccessible after OMV update. I don't remember how the interface names looked - it was very likely just eth0. There were extra interfaces created by tailscale. Also for some weird reason, I saw raspi listed with my tailscale ip - 100.106.32.86 on my router, instead of the static ip assigned to it - 192.168.1.151 right after the update. A reboot completely took it off the routers active device list and it never came back up.

My setup -

1. Raspi 5 8GB, installed raspberry pi os lite 64 bit, before running omv install script.

2. Static IP set on router, not on raspi

3. Tailscale installed for remote access

Ordered a keyboard, monitor (+micro hdmi cable) and mouse from Amazon just to run the "omv-firstaid" command. This raspi was at my parents house in a different country until last month. Can't imagine what I would have done if that was my situation now.