I do not for one minute believe these files re-write themselves. This has to be either something users are doing or some bug we have not uncovered. And I won’t shut up until I find out if this is or is not a bug this is to important.
1 Like
I agree 100%.
NOTE
@ben79 and I are not trying to blame anyone. We just want to find the problem and fix it. This should not be happening and we need all the info you can give us. I know the questions get tedious, but we have to troubleshoot this issue. It is critical that we get it fixed.
Thanks @WilsonPhillips. No I am not try to blame anyone at all. I am frustrated by what I see as a not very well defined problem. To explain: We have 2 instances of users reporting about the .repo file “It’s broke”. We can not fix “It’s broke” we need a cause, we need evidence of something to fix this. We need something to work on and so far we do not have that and for me this is extremely frustrating.
well someone in another thread asked me to try a program in the testing repo, so i enabled the rock testing repo, that’s the only change made into the system, and it was enabled via gnome-software. Anyway i wasn’t able to try this program (abcde for what is worth) cause repos are actually unreachables
i have checked the files in yum.repos.d and they already have 2 slashes, like this
[rock-x86_64]
name="OpenMandriva Rock - x86_64"
baseurl=http://mirror.openmandriva.org/rock/repository/x86_64/main/release/;http://abf-downloads.openmandriva.org/rock/repository/x86_64/main/release/
# Alternative if mirror.openmandriva.org is down
# mirrorlist=http://mirrors.openmandriva.org/mirrors.php?platform=rock&arch=x86_64&repo=main&release=release
# fastestmirror=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-OpenMandriva
type=rpm-md
enabled=1
don’t think there is something to modify here?
1 Like
Here is what we have found. The line baseurl has 3 problems. Both of the http need to be https and the ; needs to be removed and the rest of the line on the next line.
baseurl=https://mirror.openmandriva.org/rock/repository/x86_64/main/release/
https://abf-downloads.openmandriva.org/rock/repository/x86_64/main/release/
Of course this needs to be done all the way down that file. At least on the ones that say enabled=1
If we can get this to the point where you can do a dnf repolist and a dnf refresh and see what you get, then we will worry about replacing everything in the folder with one command. Once you don’t get the 404 errors,
sudo dnf reinstall distro-release-repos
Maybe gnome-software is causing this problem?
I don’t use Gnome but on Plasma6 systems we use OpenMandriva Repository Selector aka: om-repo-picker and that software does not do this. We discourage users from using dnfdragora or Discover to manage repositories to only use the om-repo-picker.
I am not a gnome user either, so I am flying blind.
If you need to do it, just paste the contents of the whole file and we can fix it and you just paste it back in.
i don’t have any idea, i used it on other distros without problems, but i do assume since it’s the only thing i touched it’s surely the culprit, and it’s probably best to be avoided on openmandriva
anyway, looking at the suggestion from @WilsonPhillips i was actually able to solve the issue 
i don’t know what caused it, but i can only point my finger at gnome software, since i haven’t messed up with the system…
Is it all working now?
@247 and @SilentRanger
Can you please post your ~/.bash_history ?
Maybe we can see a program that was run that our devs can check. If this had happened to one person, I might not think too much of it, but to happen to two people in two days, this is a critical deal for all of us here.
I don’t really think you are in a position to say that given you are comparing how things work on other distros to this one. We don’t do what other distros do, and are not based on other distros. We don’t use dnf like other distros do. We also document that extensively between here, the wiki, and the chat room.
One guaranteed way to fix this is what I posted above. If you move whatever_branch-whatever_arch.repo to whatever_branch-whatever_arch.repo.bak you won’t have a .repo file. Then you manually download the correct distro-release-repo .rpm for your branch and arch in install or reinstall that an it will write a new pristine and work .repo file.
This is something I have done a number of times, this method is tested and approved. Well approved by @ben79 anyway.
.bash_history.txt (3,8 KB)
here it is
1 Like
At this point, we still don’t know what caused this problem. We just know that it is a big deal.
I would say (but it’s just an assumption) that since i used gnome-software maybe the problem lays in packagekit?
i have already used that app, but maybe there is something implemented differently here, than in more gnome centric distros
that’s the only thing that come into mind, since it was the only thing touched (althought i may be wrong of course)
If it is using packagekit then it probably should not be used for repo management. Discover uses packagekit and we don’t like users to use that for repo management. From my perspective I also see this a guess but I suspect it is a very good guess.
2 Likes