To be honest... the way you shout in the forest is the way it comes out. Your posts didn't come across very friendly to me and had an aggressive undertone.
I apologize if you felt it like this, it was not my intention. Are you willing to help, or should we leave it here?
Display MoreWhen I worked with hardkernel years ago, they didn't care that I was uninstalling petitboot or that armbian recommended removing it. Linux isn't even supported on many x86 systems people are using for OMV.
On your system. tobetter could not reproduce on his system. And yes, I know others have seen it.
OMV and armbian work very well on all of the odroid boards I have (many - xu4, hc2, hc4, c1, c2, c4, etc). And after four years, no other odroid board is using petitboot. No other manufacturer is using it either. Armbian supporting hardkernel boards makes hardkernel money by selling more boards. They are not going to tell you to not use Armbian.
10 mins??? The system is in use. I would have to figure out how to put petit boot back on it, take the system apart to attach a serial connection and then try to replicate. Follow that by trying to figure out why it is happening. This could be hours and hours. Easy for you to offer my time to do that.
I am pre-retired but as a CTO I managed different software development teams and the agressive pushback I encounter here is a bit odd. Something is breaking Debian when installing OMV and with my experience with developers I was expecting "Sh*t, cool, let see!", that's at least simple professional curiosity, if not professional sens of responsibility. As I said I am willing to help, willing to spend time on it, I described the issue, I sent you the logs, but if you don't want to help just tell me.
But you have already considered that in Debian 12 the complete software was updated and thus the problem could be introduced? So maybe it is not a problem with OMV.
This could be a systemd or APT package management issue or the service (e.g. Samba) itself.
I don't know what the problem is. I just saw than Debian 12 is working perfectly, including the package management, before installing OMV 7. OMV installation modify quite a lot the OS, including something questionable in terms of security as allowing root to log on SSL. I am willing to spend time help them but apparently, some of the guys here from OMV are not interested in fix it. I will leave it here
Display MoreTo be honest, I'm too lazy to read through 38 posts right now, but after briefly skimming through them, I only see blame but no helpful information to narrow down the problem.
The problem seems to me to be specific to the hardware. So I think the community that has this hardware must also contribute a fix or provide the necessary information.
Since there is a workaround as far as I have seen, it is all the more true that the community must provide a solution if the workaround does not want to be used.
The most important thing is when exactly does the problem occur. how is it reproducible. is there any log data on it. what does rebooted mean? Does the machine shut down properly or is the power lost for a short time and then it reboots?
Is it a power supply problem under full load? Is it a runtime error in one of the installed software packages that pulls the entire machine into the abyss and triggers a restart?
I think I answered most of the questions you asked. The work around consists in installing an OS not officially supported by the SBC manufacturer and the day I may encounter another problem I may get the answer "sorry but you did not install the OS as specified". It is working perfectly on Debian 11 and OMV 6.
The problem occurred only with Debian 12, and only after installing OMV, whatever I installed it following the Odroid official page or the OMV official installation guide or upgrading using omv-release-upgrade (the later creating even more issues). I supplied some logs and clearly state "I can reinstall Debian 12 if someone want me to investigate further".
The problem (unattended reboot) occurred when installing a service from inside OMV, but from the console I encounter the same problem when configuring or restarting some services, I got reboot with dkpg --configure -a and systemctl restart networking && minidlna. It is 100% reproductible when doing it from the OMV UGI. It maybe only an issue with the HC4 or petitboot, or not, but I think it worth the time to investigate because Odroid is a major manufacture of SBC and petitboot common bootloader and this issue may resurface with other configurations.
ryecoaaron seems to have a HC4, he can reproduce the issue is 10 minutes and is obviously much more competent that I am for this, but I am willing to help, I am not a Linux guy but a former CTO in networking and security, I understand that having an issue is perfectly normal: Fixing it also.
You have been told several times in this thread that you are installing OMV using an untested and not recommended procedure.
You can tell that guy on that forum that he should post his problems with OMV on the OMV forum, not on forums that have nothing to do with OMV.
I used both the procedures recommended on the Odroid official pages odroid-hc4:software:install_omv_nas [ODROID Wiki] and the procedure recommended on the official OMV pages Installation on Debian — openmediavault 7.x.y documentation , with exactly the same result. Is Armdian the Unofficial-Official procedure because this is the only "fix" mentioned by ryecoaaron? Odd because Armdian is not officially supported on the HC4 and the OMV official installation page does not mention Armdian, but only Debian. Debian 12 is working perfectly before installing OMV, and it OMV is working perfectly on Debian 11. If OMV is not supported on Debian 12, at least on the HC4, this should be part of the OMV documentation and not as a forum message.
The fact that Odroid users post on Odroid forum and not on OMV forum does not change the fact OMV is not working on Debian 12 for these users. In place of denying the issue and proposing an unofficial "fix", try fixing the installation on the officially supported OS.
Check the log I attached, it will me more constructive.
Since OMV 7 requires Debian 12, this is not rude.
I don't know what this means.
Without logs, we will never know. At this point, I this I will step away from this thread. We have a known working method and that will have to be good enough.
By the way, check this post, you will see I am not the only one with exactly the same issue HC4 with Debian 12 and OMV7 reboots - ODROID
Since OMV 7 requires Debian 12, this is not rude.
I don't know what this means.
Without logs, we will never know. At this point, I this I will step away from this thread. We have a known working method and that will have to be good enough.
I saved the syslog, ngnix and journal log, attached. Check syslog around the line 9128. Updating the OS when updating a service should not be allowed, especially without warning, I think it is easy to understand why. Not allowing root login through SSL is a common security practice and the default Debian and Ubuntu configuration. SSL should only allow sudoers not root and, again, modifying a root security parameter without warning is rude. I reinstall Debian 11 and OMV 6.x it is working perfectly. For me it is a hard fact that on my HC4, Debian 12 with OMV 7 is not working. I am just here to find a solution not to open a dispute, nothing personal, everything technical ovm log.zip
As a matter of curiosity, I did a "omv-release-upgrade" and it serious blows up the system 🤣. SSL and the web interface were no more accessible, so I did a "omv-firstaid" to reconfigure the network. And... it reboot the system, coming back alive with a network "interfaces" configuration file pointing to an empty folder, I have to reconfigure it manually. syslog, just before the reboot, shows that php7.4-fpm failed restart. So I tried to restart it manually.
"systemctl start php7.4-fpm" returning "Failed to start php7.4-fpm.service: Unit php7.4-fpm.service is masked."
"systemctl enable php7.4-fpm" reboots the system.
I found that "omv-release-upgrade" non only upgrades OMV but also my Debian 11 to 12... that's pretty rude to say the least. OMV installation also authorizes root to log through SSL, pretty rude too.
So I am done with the tests, something is truly broken here.
After many reboots, many reinstallations, I switched to Debian 11, installed OMV and everything works fine.
With Debian 12 I did not find any trace of the reboot cause in any log, it just reboot without any pre-message, just the normal reboot message and file system clean-up. Configuring services from OMV web interface, dpkg as well as "apt purge" rebooted the system after about 20 seconds, and it can be reproduced 100% of the time. It seems that installing OMV 7, manually or using the Git script is messing up Debian 12 in a way I cannot determine. My install process is:
Yes "dpkg --configure -a" or "apt purge" are not supposed to reboot the system, but it did. I can reinstall Debian 12 if someone want me to investigate further
Thanks for your replies
I disagree. The installation script and OMV build are the same whether you are using petit boot or not. If you find something, I am willing to make changes but I don't plan to put anymore time into this.
Thanks for your reply. I am not asking anything but trying to find a solution. I was able to reproduce the issue outside OMV web interface: After a reboot trying to install the minidlna service from OMV GUI, I found that "dpkg --configure -a" from the console as root also reboot the system. So, I am closer to the source of the issue. The reboot seems to be related to new package installation or configuration, but apparently only after the installation of OMV. From OMV I was able to create users and link file systems but not able to configure any services. I will reinstall Debian 12 from petitboot and will install packages similar to those of OMV before installing OMV, just to see how it works. I will not have the time to investigate further for the next few days, I will keep posting here should I find something.
Why? Petit boot is clearly causing the problem.
It was working perfectly with Petitboot before, same version and configuration, so the culprit it is probably the current OMW build or the installation script. It is probably fixable, I don't need my NAS right now so I am curious, and I can spend some time to investigate. Thanks for your reply.
Same here exactly as described by ondras. It was running perfectly for months but during a move the SD card was damaged, and I just reinstalled it on Debian 12 from Petitboot and OMV using the Github script. I was able to set the Dashboard and to mount the file system but trying to apply any other setting reboot the HC4 without applying the configuration. I will prefer to avoid the Armbian fix. No obvious error message in the log just some things probably unrelated as in the Kernel log "spi-nor spi1.0: unrecognized JEDEC id bytes: 0b 40 18 0b 40 18" that just indicat a non-identified memory chips. Any idea?
do you reboot your NAS?, sometimes resolve the problem you describe.
I found the issue but not sure I can fix it. My system, an Odroid HC4, have the minimum recommended RAM (4Gbs) and the swap partition is too small. When Photoprism reach the maximum of 90% of the RAM, when I am trying to index a large set of RAW image, the Kernel kill the Photoprism process. I can either increase the swap partition to the recommended 4Ggs, but on a SD card it will be probably very slow and a SD card is not supposed to handle a large number of constants write operations, or I can decrease the Photoprism parameter "PHOTOPRISM_WORKERS" (still looking in what file this parameter is on the Photoprism plug-in implementation of OMV). I am in Raid 1, so the HDD are not available for swap
do you reboot your NAS?, sometimes resolve the problem you describe.
Of course, I have been on this problem for about a month. Sometime I can access it for a few minutes, then it disconnects. I suspect some resource issues, like a memory leak but I found nothing obvious. I tried to restart the service, to change the port, to use different browsers... This is really specific to Photoprism<. the Filebrowser plugin is working fine, I have no trouble accessing the OMW GUI, SSH, SMB, DNLA... No error linked to Photoprism in the log.
Hi there,
I installed Photoprism as a plugin, not through Docker, under Debian 11, but I cannot access the web pages with a "refuse to connect" as if the port was not open. NMAP effectively does not show the Photoprism port open.
The plugin is see as running in OMV, Systemctl shows "pod-photoprism.service loaded active running Podman pod-photoprism.service", ss shows "tcp LISTEN 0 4096 0.0.0.0:2342 0.0.0.0: users:(("conmon",pid=166868,fd=5)). pstree -p show a conmom process with two sub-processes for the pid 166868, one of these subprocesses is "pause". All the other http services on this system are running fine. I am not familiar with podman, not enough to debug it and the standard Linux tools show nothing wrong. I am on a flat network, no firewall, no routing, no proxy. I even forced open the port in the Debian firewall. Any idea?
I run it on the Odroid HC4 in RAID1 (Mirroring), running fine with two open issues I am still trying to understand: For some unknow reasons sometime I cannot restart it and I have to reflash the firmware (Petitboot). Issue with Photoprism, sometime the web page is not accessible: I have about hundred thousand photos, maybe a resource issue.
Inexpensive hardware, very low power consumption.
Hi there,
Often, I am not able to connect Photoprism with timeout or Connection refused message until, without any specific reason I can identify, it works again. When this appends Nmap show the 2342 IP port as "filtered", but I am on a flat home network, there is no firewall or so, internally. My OMW is on Linux Debian, and command like "netstat" show the port open and listening. I created a firewall rule on the NAS to force open the port 2342, but to no effect. It is really something about Photoprism as all the other ports and associated services are accessible and working perfectly (OMV, File browser plugins, Web console, SSH, etc.). I can't reproduce the issue on demand, it seems totally random. My guess is about something odd with the Debian resource's allocation for the Photoprism processes and if the port 2342 is open the plugin/network stack is not returning anything (I also tried to use another port). I uninstaled Docker.
The hardware is an Odroid HC4, two disks mirrored.
Any idea?
Thanks
Hi,
I have a similar issue, time out or a connection refused, often the Photoprism page is not responding. When this appends Nmap show the 2342 IP port as "filtered", but I am on a flat home network, there is no firewall or so, internaly. My OpenMediaVault is on Linux Debian and command like netstat show the port open and listening. I created a firewall rule on the NAS to force open the port 2342, but to no effect. All the other ports and associated services are accessible (OMV, File browser plugins, Web console). It is just Photoprism returning a time out or a "connection refused" about 50% of the time until without any specific reason it works again. I can't reproduce the issue, it seems totally random. My guess is something odd with the Debian resource's allocation for the Photoprism processes.
these two flags are the same and since you have a forward slash in there, it is adding the root filesystem to the rsync. remove -O /
Haha silly me, syntax, syntax. Thank you 
Hi there
I am trying to rsync a folder and its subfolders from one Openmediavault to an other one. It is working but for some reason the sync also copy the full content of the root volume of the source.
The file /var/lib/openmediavault/cron.d/rsync*** shows
rsync --verbose --log-file="/var/log/rsync.log" --archive -O / --omit-dir-times "/srv/dev-disk-by-uuid-*******/Users/" "rsync@192.*.*.*::RsyncBackup" & wait $!So only the /Users/ folder should have been sync and the rsync log shows exactly this happening. But in fact the entire content of the root volume is also transferred 
, despite the fact it is located on an other volume . Any idea?
The source is on Debian 10 running on and Odroid HC4 with disk mirroring, Openmediavault Release: 5.6.25-1
Thanks