Beiträge von pplucky

Zitat von notdisclosed

pplucky and others following my workaround. Please have a look at the following blog item: https://www.openmediavault.org/?p=3492 . This item mentions that the issue is revolving around systemd in combination with DHCP.

I had my system configured with DHCP for the IP address, forcing an IP using my router. As I had made snapshots of the system I could roll back and try the mentioned option of setting a fixed IP address. This also solved my problem without updating to a backport version.

Too bad that that solution did not get mentioned in this thread.

Thanks for getting back on this. I also had DHCP on OMV and fixed IP on router, but I also did that to avoid possible future issues.

Zitat von notdisclosed

I have tried solving the issue by following your steps. For me this did not work. Systemd-networkd still crashes.

Looking at the comments at https://github.com/systemd/systemd/issues/27854:

• I noticed that the oldest related bugreport is from 2021, so the issue has been there already for a long time. Why does this issue only surface just now? Is it the latest Debian that got updated recently?
• In later versions of systemd, not yet in stable debian, the issue seems resolved.

Based on the steps of chente combined with the bugreport from votdev I was able to find a workaround for the issue:

• Enable backports using omv-extras
• run apt update to be sure
• run apt install -t bullseye-backports systemd and when prompted keep the current non existent version of /etc/systemd/logind.conf.distrib
• apply the configuration changes using the webinterface
• Disable backports using omv-extras (to be sure no other backports are installed down the line)

This works for me.

I can confirm that the above steps have also worked for me. notdisclosed Thanks for your sharing.

Zitat von votdev

Can you tell how the network is configured on your system? Is it if-up-down or network manager?

It seems to be ifupdown, as per below:

pi@omv:~ $ apt-cache policy ifupdown
ifupdown:
  Installed: 0.8.36
  Candidate: 0.8.36
  Version table:
 *** 0.8.36 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages
        100 /var/lib/dpkg/status

pi@omv:~ $ apt-cache policy network-manager
network-manager:
  Installed: (none)
  Candidate: 1.30.6-1+deb11u1
  Version table:
     1.42.4-1~bpo11+1 100
        100 http://httpredir.debian.org/debian bullseye-backports/main armhf Packages
     1.30.6-1+deb11u1 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages

pi@omv:~ $ apt-cache policy dhcpcd5
dhcpcd5:
  Installed: (none)
  Candidate: 1:8.1.2-1+rpt9
  Version table:
     1:8.1.2-1+rpt9 500
        500 http://archive.raspberrypi.org/debian bullseye/main armhf Packages
     7.1.0-2 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages

pi@omv:~ $ apt-cache policy dhcpcd
dhcpcd:
  Installed: (none)
  Candidate: 1:3.2.3-11
  Version table:
     1:3.2.3-11 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages

pi@omv:~ $ apt-cache policy libnss-resolve
libnss-resolve:
  Installed: 247.3-7+rpi1+deb11u2
  Candidate: 247.3-7+rpi1+deb11u2
  Version table:
     252.5-2~bpo11+1 100
        100 http://httpredir.debian.org/debian bullseye-backports/main armhf Packages
 *** 247.3-7+rpi1+deb11u2 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages
        100 /var/lib/dpkg/status

Not absolutely sure if relevant but this is a fresh-installed Raspberry OS with OMV initially installed on a RPi3 with a dynamic IP address and then the SD card was moved to the final RPi4 with a different fixed IP address (fixed on router). To make it work, as per this post, I had to use console to run omv-firstaid to 'Configure network interface'. After that, I don't recall touching any network-related settings.

Zitat von votdev

Sadly I have no Raspi, so I can not test anything nor know exactly what Raspi OS is installing and using to configure the network.

According to what I found on the inet the dhcpcd service is used.

Can you run the command systemctl status dhcpcd and post it here?

Unit dhcpcd.service could not be found.

Zitat von votdev

There shouldn't be any problems because OMV now installs and uses systemd as it should be. The correct way of installing and configuring systemd network fixes some DNS resolving issues that cause Salt to slow down. Now with the correct configuration of systemd-resolved this problem has been fixed beside the fact that the DNS related config was incorrect in previous versions. The main problem is that every Debian based distro OMV is running on cooks his own soup. The only real problem that comes to my mind is that network manager will fight agains systemd on some Debian derivates. In this case network manager needs to be disabled.

What exactly would you suggest doing on Raspbian GNU/Linux 11 (bullseye), in order to return OMV to a working state as it was before the last update? This, but directly in console to get any execution log?

Hello.

Having the same exact issue as OP Architekt, but as I don't have a wireless keyboard on hand, I tried running the suggestion above from votdev from SSH, and I ended up without connection to the server (as if I had applied the pending settings from UI).

Currently running 6.4.0-3 (Shaitan) on a RPi4, with fixed IP on my router and if I forcefully reboot the server, in the UI I get:

If I choose to apply the pending configuration changes, my system will hang again and lose network connection.

Tomorrow I should be able to have my wireless keyboard to try it directly via console. Will this eventually yield a different result or at least provide insights on what is causing this issue?

Is this a known issue resulting from this upgrade?

Btw, is there an easy way to revert the upgrade, or do I really need to restore last backup?

Thanks for all your help.

Zitat von TheFax

I paste here some lines, for future reference, hoping they can also be useful to other peolpe:

LOGIN (the file cookie.txt will be generated):

Code

$ curl --request POST --cookie-jar cookies.txt --data '{"service":"session","method":"login","params":{"username":"admin","password":"yourpassword"}}' 192.168.0.5/rpc.php


{"response":{"authenticated":true,"username":"admin"},"error":null}

Comunication test:

Code

$ curl --request POST --cookie cookies.txt --data '{"service":"system","method":"noop","params":null}' 192.168.0.5/rpc.php


{"response":"I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.","error":null}

Shutdown:

Code

$ curl --request POST --cookie cookies.txt --data '{"service":"system","method":"shutdown","params":{"delay":10}}' 192.168.0.5/rpc.php


{"response":null,"error":null}

Alles anzeigen

Hello TheFax.

Now that I have finished the installation of my new OMV 5.x on an RPi4 as host, I was considering "building" an interface to read data from my HA system (I currently have a few settings being sent from bash scripts via MQTT).

Would you be willing to provide more details on how you did it on hass.io? If you think this is out of scope for this forum, can you contact me directly?

I'd like to have HD free space, temperatures, need to go through the RPC methods' info provided by ryecoaaron above.

Thanks in advance and kind regards.

Hello all.

I currently am trying to run a bash script out of a php file I added manually to folder /var/www/openmediavault.

Script is executed with user openmediavault, but some sudo mount lines are not executed properly.

I know this is a security risk, but there should be no external exposure to my OMV, so I'd really like to be able to put this to work.

As of now, I already added user openemediavault to group 'users' in file /etc/group (to allow it to write a log file within the bash script), and also added the following line to visudo:

openmediavault ALL=(ALL) NOPASSWD: /bin/mount /bin/umount /sbin/mount.davfs /sbin/mount.nfs /sbin/umount.davfs /sbin/umount.nfs

This didn't work, as WebDav and NFS drives are not mounted as it should, unless I would add the following line to visudo (which I would prefer not to):

openmediavault ALL=(ALL) NOPASSWD: ALL

I would rather give the user access only to what is required to be done in the bash script, but I don't know what else may be missing.

Also tried running the following command, but no output is given:
sudo su openmediavault -c "/path_to_script/backup-flashair.sh"

Any ideas?

Currently running OpenMediaVault 2.1.18 on a Raspberry Pi 2.

No such file, on openmediavault 2.1.17...

Maybe some plugin needed missing?

I will do the upgrade to Stone Burner later anyway. I will let you know.

OMV 1.19 (Kralizec)

Zitat von gderf

Maybe a boot delay would help by editing /etc/default/grub

This file doesn't exist in my installation... Maybe I'm missing something.

Initial mount was done via OMV Gui, so using UUID.

Better late than never: thanks a lot for the idea, it works perfectly now!

Still happens, so I would appreciate any ideas on why this may happen. Thanks in advance

You're right, sorry about that.

Initial backup from SD card to file done with command:
sudo dd if=/dev/mmcblk0 of=path_and_image_filename.img

Restore from initial backup to new SD card (same size/brand/etc):
sudo dd if=path_and_image_filename.img of=/dev/mmcblk0

No errors occur during the execution of any of the above commands and I always unmount the SD cards before removing it from the card reader.

This is how far the boot process goes when booting RPi2 from new SD card (restored from image, as per above command):

Hello.

My offline backup method for OMV is done by shutting down the RPi, removing the SD card, doing a full DD (all partitions) to an image file (in a Linux Mint installation).

When trying to restore, by doing DD again from the image file to a new SD card, I can never get the system to boot properly, it complains of an issue in one of the partitions.

If I do the same exact DD command but directly from an SD card to a new SD card (same size, brand, etc), I can properly boot from the new SD card.

Any reason why the dd to image and image to new SD card would not work?

Thanks in advance for any help.

Hello.

I have recently noticed that one of the 2 Hard Drives connected via USB to my Raspberry PI 2 running OMV 1.14, simply doesn't mount by itself.

I already had my SD card system partition full due to the drive not being mounted while running an rsync backup, so I needed to write down a bash script to make sure all connected hard drives are properly mounted before actually starting the rsync backup.

Still then, considering that the hard drive is declared properly in /etc/fstab and that it mounts properly if I run 'mount -a' via CLI, why doesn't it mount automatically when I reboot my system?

Any ideas?

Thanks in advance and best regards.

Found myself the answer here: Could't login to OMV

I think my rsync Jobs were copying data to a mountpoint folder in the SD Card in which nothing was mounted properly at the time, so the copy was actually being done to the SD Card rather than the drive that should be mounted and was not.