Posts by foreach

    I think mergerfs is messing around, and I guess to solve this error I need to delete the mergerfs pool or at least remove the bad drive from the pool configuration.. If this is the problem, I think that this error should not be affecting to list other file systems


    thank you

    Replacing a disk does not involve a snapraid fix command. Did you read what was suggested?

    I read what was suggested, but I don't trust the bad disk anymore, and my initial idea was to use the parity disk to recover files on the new disk one. But anyway, this does not solve the error I am facing when a disk is removed physically, it is supposed that -as what Recovery says- I should be able access to "Storage -> File Systems" and see a missing drive there and create a new file system for the new drive.


    But I got this error instead.


    41407-pasted-from-clipboard-png


    In other words, what if a data disk from a mergerfs pool died, and I couldn't copy the content before? I would be facing the same UUID error? How can I solve it? I should remove the dead disk from mergerfs pool?


    Thank you

    Hello. Sorry to bump this thread, but I'm in a similar situation, I have a bad disk with some 'Current pending sectors' and I would like to replace it, I have already a new one to swap, I tried to remove the bad one and put the new one but once I enter to file systems it shows this error and can't see any file system or add a new one because of that. I've been using snapraid with 2 data disks and 1 parity drive along with MergerFS. I think that this error is related to the fuse.mergerfs file system, the disk I'm trying to replace is labeled hdd2, any help would be very appreciated, In the meantime I have put back the bad disk again and the error doesn't appear anymore.


    Thank you


    Is the mtu set to 6 in the web interface? I can't find anything in the code that could change the value to anything other than 0.

    I've taken a look and yes, MTU is defined to 6 there..



    I should set here this value to 1500 instead setting it in the netplan file? I don't know why this field has a value.. I think I never typed any to be honest.


    Edit: I set it to 0 and applied changes, mtu disappeared from netplan file and now seems it's working good too. Maybe best option is to let it be the default value.

    This ONLY "fixes" people incorrectly calling snapraid commands without the config file argument ( -c /etc/snapraid/ARRAY_NAME.conf ) from the command line or script

    Sorry. I didn't know that it was "incorrect" not passing -c config file argument, I've been running snapraid commands from terminal since OMV 5.0 without this argument. Maybe this should be noted in omv-extras documentation?


    omv6:omv6_plugins:snapraid [omv-extras.org]


    Thank you

    Hello, finally managed to upgrade successfully. The problem was MTU value on 'ens18' interface netplan. I don't know why, it had a value of 6, and it should be 1500 in my case... Changing it to 1500 now wget github.com works... just intrigued why worked till today with this value on OMV6 but on OMV7 don't. Anyway… Thank you!

    Yes. I can.

    Code
    root@openmediavault:~# wget google.com
    --2024-06-20 17:04:11--  http://google.com/
    Resolving google.com (google.com)... 142.250.200.78, 2a00:1450:4003:80e::200e
    Connecting to google.com (google.com)[142.250.200.78]:80... connected.
    HTTP request sent, awaiting response... 301 Moved Permanently
    Location: http://www.google.com/ [following]
    --2024-06-20 17:04:11--  http://www.google.com/
    Resolving  www.google.com (www.google.com)... 216.58.215.164, 2a00:1450:4003:80f::2004
    Connecting to google.com (www.google.com)[216.58.215.164]:80... connected.
    HTTP request sent, awaiting response... 200 OK

    Maybe is something related with known_hosts?

    This is the last part of the upgrade process:

    Here you can see both results from OMV6 and OMV7


    Executing wget from OMV6:


    Executing wget from the same VM after doing omv-release-upgrade:

    Code
    root@openmediavault:~# wget "https://github.com/regclient/regclient/releases/download/v0.6.0/regctl-linux-amd64"
    --2024-06-20 14:51:00--  https://github.com/regclient/regclient/releases/download/v0.6.0/regctl-linux-amd64
    Resolving github.com (github.com)... 140.82.121.3
    Connecting to github.com (github.com)[140.82.121.3]:443... failed: Connection timed out.
    Retrying.
    
    --2024-06-20 14:53:11--  (try: 2)  https://github.com/regclient/regclient/releases/download/v0.6.0/regctl-linux-amd64
    Connecting to github.com (github.com)[140.82.121.3]:443...

    Your system is failing to connect to github. There is something on your network likely causing this. Wireguard is incoming connection and shouldn't block outgoing. Did you change any firewall settings in the OMV web interface?

    Hello, I don't see any rules on OMV firewall web interface, and I've never had one that I know of. It's weird because on the other LXC containers or VM's, github connection is working without any problems, and in OMV6 prior to do omv-release-upgrade it's working too… any more ideas... hints? Thank you.

    Hello,


    I've been running OMV on a proxmox VM without major issues since a few years ago. Now I tried to upgrade from 6 to 7 and the upgrade process gets stuck at this point. On OMV6 (tested before the upgrade) there are no problems with github at all. It's during the upgrade that something broke, and can't figure out what's causing it. I've already tried to reset iptables removing all docker stuff etc. without any luck. Also uninstalled wireguard to make sure that it's not messing with some network configuration and same result. I've restored a backup and tried to run the upgrade multiple times, and always gets stuck at the same point. The only plugins/extras that I have are, docker, wireguard, snapraid, minidlna and mergerfs


    Thank you.