update from 7.4.17 to 7.5.0 failed

Quote from greg77

If you have a copy, I would do this:

1. run omv-firstaid

2. remove the extra line from cmdline.txt

3. reboot.

4. hope for the best and let us know if that works.

I bricked it previously, then restored the backup, run omv-firstaid, updated to 7.5.0 and it works fine, so the steps above should also work for you.

Display More

This is somehow what I thought ...

But I ran omv-firstaid. It started fine. Then ssh-connection was gone and I couldn't see whats going on.

After some minutes I tried to connect again - no success - neither ssh nor web-gui

Then I did a power cycle, but system didn't come up. And wasn't connected to my network (FritzBox).

No chance.

So I had to boot my backup again.

I have the same problem on a RPI5. When updating from 7.4.12 to whatever the latest version is today (11th February 2025), the whole thing breaks completely. No web access, no SSH access, no way to connect to OMV. And no, I cannot connect a keyboard and mouse, the whole setup is designed in a way that it's physically inaccessible. I can only reach the power button and the SD card.

I see that this problem has been going on for a month now. Can we please get an update which does not break the system?

I have the same question as others before me. Can we fix it by editing something some file on the SD card?

Quote from Un4Seen

see that this problem has been going on for a month now. Can we please get an update which does not break the system?

What part didn't you understand?

This is an issue with raspiOS/Debian.

Not normal but not inusual.

Run locally omv-firstaid and reconfiguring the ethernet will fix it.

Quote from Un4Seen

Can we fix it by editing something some file on the SD card?

Was already mentioned on post #19

Quote from Soma

This is an issue with raspiOS/Debian.

Not normal but not inusual.

Pardon my ignorance, but if this is known, why is OMV pushing this update to the users? Wouldn't it be better to hold it back until it's fixed and not break people's systems?

Quote from Un4Seen

Pardon my ignorance, but if this is known, why is OMV pushing this update to the users?

OMV doesn't push it. It's Debian.

Quote from Un4Seen

Wouldn't it be better to hold it back until it's fixed and not break people's systems?

The 2 sole developers of OMV can't just consider every possible situation with every update from the underlying OS with every possible hardware where it runs and pre-test it all.

You can see, for eg, what is happening with Armbian updated kernel that renders several devices unable to boot.

How is this OMV fault?

Alright, thank you for the clarifications. I didn't say it's anybody's "fault". I get it that OMV is free and is "take it or leave it". All I'm saying is that since we now know that the underlying Debian update breaks things, OMV could decide to not offer to do that update until Debian fixes things. But I guess that comes with other downsides, like the security aspects of an outdated OS. So yeah, it's a huge mess and pretty bad user experience.

Honesty, this (sometimes fatal) dependency on upstream Debian made leave OMV again after just one month.

Also, the lack of warning before the 7.5.0 update in spite the amount of network less rendered machines made me doubt.

There are many free alternatives out there like ZimaOS, TrueNAS Scale, YunoHost where you receive reliable updates from one source.

Maybe one day, OMV will also shift away from plain Debian and control and maintain its own packages.

Nevertheless, thank you Volker and team for providing this nice piece of software for free and your countless hours of support.

So, for anybody who hasn't bricked their system yet with this update, I figured out a way to apply the update without loosing access to the OMV machine. If you've already bricked it, then this won't help you, it's too late. In that case try to restore from a backup and then follow these steps or try alternative solutions if you can, like connect keyboard+monitor and run `omv-firstaid` or try some other solution from previous posts.

If you haven't bricked it yet, then here's how to prevent it. The problem is that the update causes the OMV machine to loose network access over ethernet. It affects setups which rely on connecting to the OMV machine over ethernet only. Actually, I suspect that it's not this update that messed it up, but some previous already installed update, because, as you'll see from the below steps, making any change to the network configuration causes the OMV machine to loose ethernet connection even without applying the new update.

Steps:

1. On the OMV web interface go to Network -> Interfaces. If you only have the `eth0` set up, then trying to do the update will mess it up. Take note how the ethernet interface is configured, with DHCP or static address, etc.

2. To prevent loosing access completely, add another network interface for WiFi (click the "+" button at the top, above the already existing `eth0` interface) and set up the WiFi connection (DHCP or static).

3. Apply the changes. For me this already caused it to loose connection over ethernet. If not this step, then the update will for sure.

4. Go to the settings of your router and look in the list of connected clients. Find the OMV machine by hostname or by anything that helps you identify it and see what IP address it got assigned. If you set up the WiFi interface with static IP address in step 2, then it should be that IP address, otherwise the router will assign one to it, so find that one.

5. Knowing the IP address of the OMV machine over Wifi, use it to connect to the OMV over SSH. No need for keyboard or monitor.

6. Run `omv-firstaid` and configure the network interface for the ethernet according to your notes from step 1. Afer you hit "OK" or "Apply", you'll loose connection again because the WiFi interface will be nuked.

7. Connect back to your OMV machine over ethernet using its normal IP address that it gets from the router over ethernet.

8. Go to the OMV web interface and check the Network -> Interfaces section. You'll see that the WiFi interface added in step 2 is gone (we only needed it temporarily anyway) and what used to be `eth0` is now `end0` (whatever that means).

9. Apply the updates from the update section of the web interface and the reboot.

10. Enjoy your updated and not bricked OMV.

Quote from ryecoaaron

I have run Debian 25+ years and can't remember the last time there was an issue on x86.

I think it's time to acknowledge in the communities (not just OMV) that SBCs are just as valid options for running server applications as "normal" computers. In fact they are better options due to their low power consumption, small size and noiseless operation. They offer pretty good performance (CPU, RAM) these days that is more than enough for many server apps (OMV included). People who develop and maintain the OS distros for SBCs should take it just as seriously as those who are responsible for the mainstream x86/x64 ones.

Quote from Un4Seen

I think it's time to acknowledge in the communities (not just OMV) that SBCs are just as valid options for running server applications as "normal" computers.

It would be much easier for OMV developers to just forget arm devices and just stick with amd64.
For sure, it would have less people complaining that OMV "bricks" their systems.

And using "bricked" is completely misplaced.

Honestly, is it so difficult to attach a monitor and a keyboard to a Pi and run few simple commands to be back online?

Or use that parameter that Teschbert posted on #19

2- add parameter net.ifnames=0 to /boot/cmdline.txt (forcing kernel to use old if-names like eth0)

If it was "bricked", it was just a paper weight and no recovery possible.

Quote from Un4Seen

They offer pretty good performance (CPU, RAM) these days that is more than enough for many server apps (OMV included).

With the price of N100 boards being almost on par with a SBC, you will be better off with one of those.

Quote from Un4Seen

People who develop and maintain the OS distros for SBCs should take it just as seriously as those who are responsible for the mainstream x86/x64 ones.

Since the OS is Debian/RaspiOS, maybe you should be complaining on the proper forums/github.

And since this debate will get us nowhere different than where we are standing, I'll end my input here.

Alright, seems to me that my remarks have been taken a bit too personally. I did not mean to offend anybody. I appreciate the work that the OMV devs put into it. I don't know if you guys are the devs or just fans of it, either way, the goal was not to upset you.

From my perspective I was just stating the facts. The update broke OMV. Doesn't really matter that the underlying Debian caused it, the end result is still the same. The OMV machine became unusable. And of course people are going to complain on the OMV forums. If you buy a Mercedes which has a Honda engine in it and the engine dies while you're on the highway, who are you going to complain to? To the dealer who sold you the car (Mercedes) or to the engine manufacturer (Honda)? Especially if you just like riding the car and never cared to check what type of engine is in it. That is why updates should in my opinion be vetted. But I understand that OMV is developed on a very small scale by only two people, so there are clearly no resources for that.

All that being said, I hope my solution a few posts before helps some people.

Quote from ryecoaaron

Debian is damn good.

I agree.

Quote from ryecoaaron

Why are they reliable??? TrueNAS scale is based on debian too

And macOS on BSD. And Manjaro on Arch. And Ubuntu on Debian...

But, unlike OMV, they all do maintain their own packages. They run beta and RC cycles to ensure smooth updates.

Quote from ryecoaaron

You do know that OMV has one developer and I am the only dev of omv-extras plugins, right? We both work on OMV in our spare time.

Yes, I did know. And I do really appreciate your work.

But I was talking about the technical backgrounds. For me as an end user (on amd64 actually) it is just too risky to update my server and have to be afraid every time it could break.

Did Volker consider to use some other base like Buildroot?

ZimaOS and Home Assistant do rely on it:

Home Assistant Operating System | Home Assistant Developer Docs

The Home Assistant Operating System is a purpose built operating system specifically designed to run Home Assistant on single board computers and x86-64…

developers.home-assistant.io