Posts by e-nighthawk

Quote from ness1602

There is also resurrected minio:

https://blog.vonng.com/en/db/minio-resurrect/

Didnt try it yet.

I just gave it a shot, since my Minio instance is just holding a few backup files that are not mission critical (until the worst case happens...).

In case anyone is wondering how to change the used image, first add the following line to /etc/default/openmediavault

OMV_S3_APP_CONTAINER_IMAGE="docker.io/pgsty/minio:latest"

Then execute the following commands (not sure, if they are all necessary and correct me if there's an easier way)

monit restart omv-engined
omv-salt stage run prepare
omv-salt stage run deploy

And lastly, since I didn't know how to restart a service from CLI (other than running "podman restart minio-app", which - I presume - would start the same image again), I briefly disabled and enabled S3 in the OMV UI.

Added benefit for me is, as mentioned in the linked Blog post, that the Admin functions in the Minio Web UI are back. I was not happy when those vanished last year.

Ah, I'm so sorry I didn't see this sooner. (I thought the forum would send me an Email about new answers. Edit: It did not, because it was disabled - fixed that.)

I checked and that folder is (and must have been for a few days, as I didn't touch it) empty. Anything else I can check?

Hello!

Despite knowing that the docs say OMV wants to run in a dedicated OS that it manages itself I have it running on DietPi. I was delighted to see an upgrade path to Debian 13 and OMV 8 last weekend and went to upgrade everything right away. I was torn between running the DietPi upgrade script first or omv-release-upgrade. Since DietPi scripts are usually more involved, I decided to run that first. Was probably not the best choice, because the whole process hiccup'd majorly when coming across the OMV 7 packages that were obviously not compatible. Got those errors sorted, OMV 8 runs just fine now, but one message I keep seeing leaves me puzzled.

The apticron cronjob sends me this output every day:

/etc/cron.daily/openmediavault-apticron:
W: Symlinking file to /var/lib/apt/lists/partial/_var_cache_openmediavault_archives_Packages.xz failed - pkgAcqIndex::StageDownloadDone (2: No such file or directory)
W: Symlinking file to /var/lib/apt/lists/partial/_var_cache_openmediavault_archives_Packages.bz2 failed - pkgAcqIndex::StageDownloadDone (2: No such file or directory)
W: Symlinking file to /var/lib/apt/lists/partial/_var_cache_openmediavault_archives_Packages.lzma failed - pkgAcqIndex::StageDownloadDone (2: No such file or directory)
W: Symlinking file to /var/lib/apt/lists/partial/_var_cache_openmediavault_archives_Packages.gz failed - pkgAcqIndex::StageDownloadDone (2: No such file or directory)
W: Symlinking file to /var/lib/apt/lists/partial/_var_cache_openmediavault_archives_Packages.lz4 failed - pkgAcqIndex::StageDownloadDone (2: No such file or directory)
W: Symlinking file to /var/lib/apt/lists/partial/_var_cache_openmediavault_archives_Packages.zst failed - pkgAcqIndex::StageDownloadDone (2: No such file or directory)

I tried (random order):

• omv-salt stage run all
• omv-salt deploy run apt
  
• emptying /var/cache/openmediavault/archives
• omv-aptclean repos

I'm starting to wonder if that message is normal? Or what else can I do to make this work?

Best regards

I installed OMV on a CM4 with DietPi 9.something (latest at that time). So all pretty new and standard, nothing was taken from an existing installation somewhere else. I am also not doing much with OMV yet, so it's more or less empty. Yesterday I installed the latest Kernel update and after that the system did not boot anymore. The console output was pretty clear about what's wrong: My fstab contains a btrfs volume which can't be found anymore.

Some digging later I found out, that the kernel update did not trigger update-initramfs. Running it manually made the system bootable again, which was a relief, but I also wanted to find out why apt did not do that. I believe it is because - at least on my DietPi installation - /etc/default/raspi-firmware contained SKIP_INITRAMFS_GEN=yes. I am pretty sure I did not modify this file so something else must have done that. My other DietPi installations (which are slightly older) have this line commented out.

Does it say "yes" for anyone else running OMV?