Clean Install of OMV7 Hangs - Multiple attempts

    if ya'll care to close the loop - after following the help on this thread - I've had no further issues. I have applied updates as they have come in and run a couple of containers for iOT stuff - no issues here.

    jimmy

    simplicity is the ultimate sophistication.

    • Official Post

    For all, the OMV7 - RPI script has been fixed. The above fix is no longer necessary.
    The OMV7 RPI install doc will be drafted soon.

    Quote from lucid3ye

    if ya'll care to close the loop - after following the help on this thread

    The thread has been labeled Resolved.

    Quote from crashtest

    For all, the OMV7 - RPI script has been fixed. The above fix is no longer necessary.
    The OMV7 RPI install doc will be drafted soon.

    The thread has been labeled Resolved.

    Sorry to be the bearer of bad news but I am not sure the eth0 / end0 issues have been resolved.


    I used the script on a rpi4 and rpi5 yesterday and had various eth0/end0 problems on both.

    • Official Post

    The issue has been resolved but implementing the fix has taken another route:

    In the interim, after booting into Raspberry OS, Bookworm 64bit Lite:
    Run the following in an SSH session;

    sudo apt-get update

    sudo apt-get upgrade -y


    # Run the following preinstall script

    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash


    sudo reboot


    # Run the following install script

    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

    There will be an automated reboot at the end of the script, then log into the GUI.

    Nice one. Hope it works for everyone else.


    I have a rpi4 with end0 ethernet device name but that is fine.


    Managed to end up with eth0 on my rpi5 but followed the same (old) process.


    both are new/clean installs so all is good.

    • Official Post
    Quote from jata1

    I have a rpi4 with end0 ethernet device name but that is fine.

    "If" you haven't changed and saved anything in networking:

    The following script, followed by a reboot, will fix the end0 interface name which is part of the overall issue.

    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash

    Quote from crashtest

    "If" you haven't changed and saved anything in networking:

    The following script, followed by a reboot, will fix the end0 interface name which is part of the overall issue.

    wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/preinstall | sudo bash

    Wasn't aware of this script.


    I have a mixed of end0 and eth0 refs on the upgraded CM4, and also on the fresh Pi5 with OMV7
    Haven't felt any issues with it. All services run as they should but if it can be "fixed/cleared", it would feel more "clean".


    Any catches by trying this remotely?

    Other than the reboot, of course.


    I'm still one week away of going home so, not much willing to loose connection to the server.


    Heck, I'll go for the Pi5 and see what happens. This one is just for experiments and serve a NFS that I can afford to be without.


    [EDIT] Before Script:


    Code
    pi@raspberrypi:~ $ ip a

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d8:3a:dd:cf:26:21 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.243/24 metric 100 brd 192.168.1.255 scope global dynamic eth0
       valid_lft 3495sec preferred_lft 3495sec


    After Script:

    Everything the same, :/ :/ :/


    First, ssh to the Pi5.

    Went on GUI and created a "new" ethernet, while still having the end0.

    Pointed to the eth0 and configured the same way has the end0.


    Before applying the yellow banner, deleted the end0.

    Applied settings and reboot.


    Now, only eth0 is seen on the system.


    On GUI, my SMART widget stopped showing any info.

    Realized that the monitoring of the disks was disabled by some reason, go figure 8|

    • Official Post
    Quote from Soma

    Wasn't aware of this script.

    I wasn't aware that this script was available, until yesterday, where I started to test it. During times prior, I'd been creating the outcome of this script manually, and plugging in the MACaddress of my device.

    Quote from Soma

    Any catches by trying this remotely?

    Other than the reboot, of course.


    I'm still one week away of going home so, not much willing to loose connection to the server.

    Given your consideration, it wouldn't hurt to "wait". :) There's always an exception to every rule.

    Quote from Soma

    First, ssh to the Pi5.

    Went on GUI and created a "new" ethernet, while still having the end0.

    Pointed to the eth0 and configured the same way has the end0.

    In my case, this novel approach was not possible (SSH), due to the following. (I had to hook up a monitor to see what was going on. In my case, systemd networking was hosed.)

    Quote from crashtest

    "If" you haven't changed and saved anything in networking:

    The following script, followed by a reboot, will fix the end0 interface name which is part of the overall issue.

    If anything has been changed in the GUI's networking screen and saved, all bets are off. If end0 is the interface name and some network change is saved in the GUI, that's it. At that point, end0 (at least in the testing I've done) appears to be permanent and, in my case (an R-PI4 w/ Bookworm - Raspi OS 64bit lit - OMV7), network wise, it bricks the install.

    This is why the short pre-install script will become part of the build process; to nail down the wired interface to eth0, and prevent issues even if it's only in the RP4 use case in bold, above. (I don't have an R-PI 5 or an R-PI3 for testing purposes.)

    • Official Post
    Quote from crashtest

    prevent issues even if it's only in the RP4 use case in bold, above. (I don't have an R-PI 5 or an R-PI3 for testing purposes.)

    RPI5 requires the preinstall as well.

    omv 7.4.7-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.3 | k8s 7.2.0-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.8


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Like 1
    Quote from ryecoaaron

    RPI5 requires the preinstall as well.

    Yes but I accidentally found a work-a-round on rpi5 (without the preinstall).


    Not 100% sure but I think the process was...


    1. new install pi os lite

    2. use raspi-config to disable predictable network names

    3. install omv - normal install script

    4. reboot and use raspi-config to disable predictable network names again (something in the script seems to enable it)

    5. reboot and network name is eth0 in gui and system

    • Official Post
    Quote from jata1

    2. use raspi-config to disable predictable network names

    3. install omv - normal install script

    4. reboot and use raspi-config to disable predictable network names again (something in the script seems to enable it)

    The installation must be reasonably intuitive, at least as much as possible. To that end, additional steps on the CLI are avoided wherever possible, to include using CLI utilities where decisions or selections are required. The preinstall script "nails down" eth0 permanently. It's a one time operation that gets the needed result.

    Keep in mind that many R-PI users are not experts.

    • Official Post
    Quote from jata1

    Yes but I accidentally found a work-a-round on rpi5 (without the preinstall).

    I was just saying the RPi5 needs the preinstall for crashtest's process. I have installed many, many times without using the preinstall script since I just wrote it yesterday.

    omv 7.4.7-1 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.14 | compose 7.2.3 | k8s 7.2.0-1 | cputemp 7.0.2 | mergerfs 7.0.5 | scripts 7.0.8


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Like 1

    has anyone seen or reproduced the syslog issue on rpi / omv7 where logging just stops sometime during the reboot process? I can reproduce this at will on rpi4 and rpi5 after a clean install of omv7 or upgrade from omv6.


    work-a-round is to restart systemd-journald at reboot using a scheduled job but it would be good to find a better solution


    systemctl restart systemd-journald

    not sure if this was your intent - but i was in fudging around anyway - so I ran the above process. may have made zero difference as my install was already working well - but I can report everything is STILL working after script(s) if that is helpful information.. It did state that it updated many modules. On first glance my CPU utilization and temperature are trending a little lower than what i have been observing previously. I also observed it adding ETH0 to the database - which I don't recall seeing previously. I'm assuming this is the fix. So. Fix is good!

    jimmy

    simplicity is the ultimate sophistication.

    I'm going to order a Raspi 5 in the next few days - waiting on a good SSD hat or Argon40 to get stuff out. At that point I'll rebuild OMV. is there anything in particular that might be useful for me to look for or report back to the development team? Happy to pass anything up that might help.

    jimmy

    simplicity is the ultimate sophistication.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login