Please do as this only occurs (at least for me) on recent, new installs, I don't experience the problem on an older installation.
Did the link to the pull request not prove that I am doing this? Oddly enough, I still have not run into this issue. But maybe I keep using the 64bit image which does not use raspbian packages - it is pure Debian.
Why don't they have a working image for OMV on SBC?
1. OMV 5.x's saltstack code doesn't work in chroot.
2. The images go out of date too fast.
3. I don't want to maintain a lot of images.
4. The script is less error prone.
5. The script gives you an update to system because I can make changes to it on the fly without having to update a lot of images.
6. You don't have to wait for an image to be built for new boards because the script just works.
7. I own a lot of boards but not all. Hard to test.
8. It is very good for users to know a little bit of how to use the command line.
Is that enough? Why is it so hard to run one install script? We have a very good guide that most would need even if the image already had OMV on it. RPi?
Also debian-backports is not really meant for Raspbian.
The only packages that an RPi should use from debian-backports are cockpit and borgbackup. I see no harm in using either.
I changed the install script and submitted a pull request to not add the security repo on RPis. Old installs will have to set environment variable. I guess I could have an update of omv-extras do it.
If you are on 5.6.3, it should remove it. Here is the code - https://github.com/openmediava…ploy/apt/default.sls#L104 THat said, it should be a one time fix.
What do you mean by that? Does this include only the following switches or also the omv-extras repos?
No. This is an OMV setting not omv-extras. So, if you enabled the community repo in the OMV plugins settings tab, it would replace it. Updates to OMV might do that as well.
I've been running OMV in this configuration for over a year and this is the first time a problem with apt occured. I didn't do anything in the web interface except for starting the upgrade of OMV from v5.6.2-1 to 5.6.3-1
Yes, I know. This was caused by Debian AND Raspbian releasing the exact same package version in their repos which makes apt confused because their checksums are different. This is the first time I have seen this since using Raspbian (years). Now that it is fixed, you shouldn't have any problems again. But the ultimate fix is not adding the Debian security repo on RPi. Like I said, I still need to think of a solution that Volker will like.
If you are on OMV 5.6.3, just execute the command: sudo omv-salt deploy run apt
If that doesn't work for some reason, execute this: sudo sed -i "/security/d" /etc/apt/sources.list
/etc/apt/sources.list.d/openmediavault-os-security.list has to be removed from RPis (Yes I'm running OMV on one)
But it will be added back any time you make a repo change in the web interface.
In your post you suggested to remove the hashsum and reinstall the package, which would have been quite a hassle for 62 packages.
My post doesn't say anything about doing that for 62 packages. Just one.
I meant the auto-install-of security-updates thing, as I guess it introduced/changed openmediavault-os-security.list?
That just tries to auto-install security updates. It can't fix this unless it stops adding the Debian security repo for *just* the RPi.
for all 62 packages that won't resolve?
All you should have to do is what is in my post.
Is there maybe a more compact command to clean apt?
Not sure what you mean. Other than apt-get clean or omv-aptclean? Neither of these will "clean" a package conflict that is causing the problem. The debian security repo shouldn't be added to the RPi. I haven't thought of a solution to suggest to Volker to fix this since it only affects the RPi and this is the first time it has happened.
The update should have removed the security repo from /etc/apt/sources.list and put it in /etc/apt/sources.list.d/openmediavault-os-security.list.
Does: sudo omv-salt deploy run apt fix it?
Is this related to RE: libapt-inst2.0 1.8.2.2 installation problem
Yes.
OMV-updates have been working without hassles so far, so I'm pretty sure it's yesterday's OMV-upgrade that introduced these problems.
Not related. omv-update and omv-upgrade do the same thing.
I've mentioned this before but checking all of the boxes on the updates tab can sometimes cause things to not work right. It explicitly tries to install all of the packages that are checked even if one of them needs to be uninstalled due to a replacement package. omv-update (can run from omv-extras or command line), should do the right thing.
Is the way of adding a sound card to an existing VM via creating a new VM (with Audio On) and attaching the existing VM storage volume ?
Or can it be added via the Edit XML method ?
Either option would work.
5.0.7 is in the repo.
Did the option to add a Sound Card to a VM get added or dropped from the KVM plugin?
It is still there. You have to enable the "Show advanced options" checkbox to see the Audio checkbox.
The reason was the "share root filesystem" plugin by omv-extras.
That isn't an omv-extras plugin. It is a core plugin.
is there a possibility for a fix in the future?
I gave you the only possible fix I know of (auto unlock). OMV (not the plugin) would need a major redesign to handle these filesystems that aren't mounted or even exposed until the device is decrypted. If you want something that works well, I wouldn't use LUKS.
Would it maybe be a thing you could add?
Yep. 5.0.17 is in the repo.
Now I have got the problem that even though the luks device is decryptet sftp still serves the root directory, just without access to the folders inside it. I have no way to access the desired folder.
The bind mounts will need to be remounted after the LUKS device is decrypted. Using LUKS has many issue with OMV because OMV expects drives to be accessible always. Unlocking on boot is my only suggestion.
Is this intented behaviour?
Yep. sftp bind mounts the path. Bind mounts don't care if the path is mounted or not.
Err: 9 https://deb.debian.org/debian buster-backports Release Certificate verification failed: The certificate is NOT trusted. The certificate chain uses not yet valid certificate. Could not handshake: Error in the certificate verification. [IP: 151.101.242.132 443]
Err: 10 https://packages.openmediavault.org/publicusul Release Certificate verification failed: The certificate is NOT trusted. The certificate chain uses not yet valid certificate. Could not handshake: Error in the certificate verification. [IP: 178.254.11.33 443]
Your system clock is wrong. Set the correct time or enable ntp.
