There might be additional functionality within those missing packages. File ownership concept is different in ntfs. If I recall, it manages things using access control lists, not as status bits and user/group id per file. If you even could change the accessibility for certain user, which user would it be and could the disk function within Windows after the operation? I have no clue and would not try with any valuable data.
Therefore it would be advisable to get the original problem solved, allowing automation to do its job and idmap the disk right, when mounted on Linux.
Nobody more knowledgeable seems to be responding. This yum/dnf-side is alien territory for me and generally I have just reinstalled when something like this happens (can be done in an hour, including setup), but that results no skills. And what is the fun in that?
Let’s try to get deeper, while we wait. What does dnf repolist -v say? It should be a safe command, works even without sudo. It should report active software repositories in verbose (-v) mode.
Brief manual reading session later - repository info is stored at /etc/yum.repos.d and although I do not run znver, mine do not have ‘;’ anywhere, so what might happen, if you run grep \; /etc/yum.repos.d/*
That should be safe, sudo not needed. Grep searches through text files, searching parameter one ‘;’ from the rest of the parameters, all files from that directory. Note the backslash, it is needed for quotation.
Aren’t those 2 links exactly the same as each other?
I haven’t edited any config files. But I did have a problem with my main internal (not root) HDD “Linux Storage”, where all of it’s files were owned by root. This was solved in this forum post. “Liam’s Gameplay” is owned by root too, but as you’ve already mentioned, ntfs file ownership works differently, so that may not be the problem.
Another thing is, a few days ago when I was getting help on this forum installing Mullvad VPN, I enabled the Extra OpenMandriva repository from the command-line, suggested by one of the users helping me. In the end, enabling it didn’t end up being what I needed to install the VPN. So once I had installed the VPN, I disabled the Extra repository from within the Discover GUI because I didn’t need it, and I think it’s best to only enable if the need for it ever arises.
Now, there’s another issue I’ve been having that I was planning on asking for help with after this issue gets resolved because I assumed it was unrelated. But I can’t remember anymore if the issue came about before enabling the Extra repository, or after enabling it. The problem is that, when using Discover to update the system, Freedesktop Platform is refusing to update - specifically version “freedesktop-sdk-22.08.27”. Whenever I perform an update in Discover, everything successfully updates, except for the Freedesktop Platform. I don’t even get any errors; it just doesn’t update. There’s also a few applications that refuse to install from Discover; one of them being Lutris. I’m not sure if these issues are related, but these are other issues I’ve been having since installing OpenMandriva.
Oh, did not proofread and using long links is error prone, as we can see. Corrected, for completeness sake and for other readers comfort and debafflement. Thanks!
Command line is a powerful tool. If mistakes are made, learning is guaranteed. That’s one reason why I prefer it.
All instances are in same file. Based on comparison with my (non-znver) system and openmandriva-rolling-x86_64.repo, the structure is different. Instead of ‘;’ is newline and next line is indented with tabulator.
Now, changing this is trivial and I could even give you a single liner sed regexp, but… I do not know if that would heal your system or break it more. So we need somebody more advanced in the way of OMLx-yum-dnf to give opinion. Or a couple of hours of more manual reading.
If you decide to try this on editor (/etc/yum.repos.d/openmandriva-rolling-znver1.repo is a text file), copy a backup somewhere first.
I think this may have been your problem. Launch the OpenMandriva welcome app, find the repository selector tool, disable all extra repos(this will prompt for a password), then re-enable extra/3rd-party repos(password again). I suggest enabling the Extra, Restricted, and Non-free repos.
Do not use the Discover app.
After all of that, run the sudo dnf dsync --refresh again.
I would still like to see if any side effect clearing might happen. It would be much simpler solution.
The problem is, that while baseurl can contain several URLs in repo file, the URLs cannot be separated with semicolon. Comma is ok, as is newline-whitespace combination, but at the moment we have 2 illegal semicolons where it counts.
Ok then. No app is useful, because the main component is misconfigured and none of those allow the needed brutality. But command line will.
Now, the file could be edited by hand, of course. If that is tedious and you would like to live dangerously, here are some commands. Only the last will be sudo.
Make backup cp -pi /etc/yum.repos.d/openmandriva-rolling-znver1.repo ~/BACKUP-REPO
This means copy (cp) while preserving timestamps (-p) and interactively making certain you are not overwriting any other file (i). Tilde ‘~’ means your home directory, under which the copied file (BACKUP-REPO) will reside.
Make certain there are no errors and the file really exists before proceeding ls -l /etc/yum.repos.d/openmandriva-rolling-znver1.repo ~/BACKUP-REPO
The files should have similar size and same date.
Create corrected file cd
Change directory, without parameters, moves you to your home. And now the somewhat scary part: sed 's/;/\n\t/' BACKUP-REPO > NEW-REPO
Make particularly certain, that every quotation mark, slash and backslash are exactly as written here. Explanation: using sed, the ‘stream editor’, substitute (s) the thing between first slashes (semicolon) with the thing between second and third slash (\n\t), which means Newline and Tabulator. Take a look at these files.
And then the really scary part, installing the new file using sudo sudo cp NEW-REPO /etc/yum.repos.d/openmandriva-rolling-znver1.repo
Yes, you actually want to overwrite the file, if it asks.
IF you get any errors or something looks fishy, stop and we will take a look!
