Posts by CyberLeader3000

    The maintainers of the Salt package used in OMV have backported many things from Salt 3007.

    The origin problem is IMO that your filesystem is corrupted and therefor some files are erroneous. Try to reinstall the packages.

    Hi votdev,


    I agree but I don't know how they became corrupted since I only used the OMV update screen.


    I tried re-installing salt-common and salt-minion, but they seem to install the 3006 which still references 3007.


    Which modules should I re-install? (and how? is it just apt-get?)

    I would rather not have to reinstall OMV 7 from scratch.


    Thanks.

    Thanks ryecoaaron,


    Quote


    saltstack can be installed with python pip too.

    Is it a good idea to use pip? When I try I get this message:

    Thanks for the very quick reply. I am not sure, I don't think I have installed saltstack 3007.0. I only used the system update functions in OMV and did not update it separately.


    When I checked apt, it does not seem to have saltstack 3007 installed just 3006:

    Code
    pi@nassie5bw:~ $ apt list --installed | grep salt
    
    WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
    
    salt-common/sandworm,sandworm,sandworm,sandworm,now 3006.0+ds-1+232.1 all [installed,automatic]
    salt-minion/sandworm,sandworm,sandworm,sandworm,now 3006.0+ds-1+232.1 all [installed,automatic]


    However, it looks like /usr/bin/salt-call requires 3007:

    Python
    #!/usr/bin/python3
    # EASY-INSTALL-ENTRY-SCRIPT: 'salt==3007.0','console_scripts','salt-call'
    import re
    import sys
    
    # for compatibility with easy_install; see #2198
    __requires__ = 'salt==3007.0'


    I tried reinstalling 3006, no change. I removed salt-* files in /usr/bin and reinstall saltstack with:

    Code
    pi@nassie5bw:/usr/bin $ sudo apt-get reinstall salt-common=3006.0+ds-1+232.1
    pi@nassie5bw:/usr/bin $ sudo apt-get reinstall salt-minion=3006.0+ds-1+232.1

    The /usr/bin/salt-* file installed for version 3006 has the code that says 3007 is required. It looks like there might be a problem with saltstack 3006.


    Thanks.

    The OMV7 7.7.5 update did not install correctly, there seems to be a problem in a Python module with a file. I tried some things but could not get 7.7.5 to install correctly.

    I figured I would wait a bit and see if there was an update that fixed it. I tried 7.7.6 today and it had the same problem.


    I am running OMV7 on a RPi 5 CM with the I/O board connected to an ASM1166 SATA controller with 4 drives.


    Any thoughts or hints would be useful.

    Since support for OMV6 is ending, I thought it would be a good time to move to OMV7. I build my own Raspberry Pi CM4 NAS (NASsie - 3D printed Raspberry PI 4CM NAS).


    I made a new micro SD card with Bookworm lite 64-bit, however the CM4 would not boot. After some debugging I discovered the PCIe SATA card was stopping it from booting. When I removed the card it would boot and run. After some digging I found this post on GitHub (https://github.com/raspberrypi/linux/issues/5659). It seems the kernel options for the PCIe interface have changed and do not work with the CM4 and carrier board. The fix is to add "pcie_aspm=off" and "pcie_ports=compat" to "/boot/firmware/cmdline.txt". This makes the PCIe cards work with Bookworm.


    I then used the install script to install OMV7. After installing OMV7 the PCIe is not working again. If I remove the PCIe SATA card then OMV7 works, but a NAS is not that useful without a SATA interface. :)


    The changes to "cmdline.txt" are still in the file.


    HELP, does OMV7 store the kernel options someplace else? Has any got PCIe working on the CM4 with OMV7?

    What can I try?

    Would building a custom kernel with the correct PCIe options help?

    First auanasgheps thank you very much for the BorgBackup guide it is really useful.


    I had the same problem as mountain-eagle, my remote Borg backup worked from the command line but not in the Plug-in GUI.


    I have a Raspberry Pi 4 system and I think things are a bit different. I believe that in a normal system the root password is set during the installation, but the Raspberry Pi root does not have a password and you can not log in as root. It appears that BorgBackup (plugin?) may first connect over ssh as root and then change to requested user.


    What I did to fix it:

    -you need to set a password for root but you can not login as root and you cannot "su" to root.

    -I did a "sudo sh" to run a shell as root.

    -I then used "passed" to set a pass word for root.

    -The RSA key pair for root was generated during OMV install

    -The key need to be shared with the remote system (this should work: ssh-copy-id remote_username@server_ip_address)


    I am not sure if you need to setup a root password and share it on the local and remote system but I did it anyway.


    After this the BorgBackup plug-in worked!

    I have just built a new NAS called NASsie using a Raspberry Pi 4CM and an all 3D printed case. I actually built 3: main system, backup system and test system.


    There are hardware and software instructions are on Hackster.io

    Hardware: https://www.hackster.io/cyberl…d-storage-hardware-38a258

    Software: https://www.hackster.io/cyberl…d-storage-software-a4a968


    The 3D print case is on Printables.com: https://www.printables.com/mod…-home-network-attached-st


    The code for the use interface is on GitHub: https://github.com/CyberLeader3000/NASsie