Leap 42.2 Bugfix and Security repos will not update.

My Leap 42.2 install was working as expected until today. Now I cannot update: http://download.opensuse.org/update/leap/42.2/oss/ and I cannot update: [http://download.opensuse.org/update/leap/42.2/non-oss/" target="_blank">http://download.opensuse.org/update/leap/42.2/non-oss/</a>"] http://download.opensuse.org/update/leap/42.2/non-oss/ . I tried using YAST to update, but it did not work either, so I decided to remove and reinstall these two repos, and YAST will not re-install them. The error I get in YAST is, “Unable to create repository from URL http://download.opensuse.org/update/leap/42.2/oss/](http://<a href=”(http://download.opensuse.org/update/leap/42.2/non-oss/)

I also had trouble updating those repos this morning. But they started working again about 15 minutes ago. Maybe there was some maintenance going on?

I noticed that the oss and non-oss update repos are missing for openSUSE 42.2 (while preparing to upgrade from 42.1), and instead only the following update repo…

I haven’t this investigated any further.

I had a problem with those repos about two minutes ago.

I’ll try again tomorrow. Something is temporarily broken somewhere.

Yep, hopefully they come back for you soon.

Yes, the 42.2 update repos got messed up somehow yesterday evening.
They are fine again meanwhile.


Maybe installing a new build? Today the repos worked and I had 313 new packages. Most of these were deltas so it did not take very long. Most everything that was of any importance was updated or replaced. Not sure if that was because I removed and reinstalled the repositories yesterday, or if it was because of a significant update. Whatever the case, everything seems to be working today.

Doesn’t seem to be the case according to the package modification times in the repo, and I didn’t get new updates from the update repo today at all here.
And removing and readding the repo shouldn’t cause a reinstallation of packages either.

No idea what happened on your system… :
But 313 packages would really sound like all updates have been reinstalled.

You didn’t run “zypper dup” while the repos were broken, I suppose?
This would have reverted your system to 42.2 at release time…
Not that I think you did, but that would be the only explanation I can think of right now… :wink:

I don’t think so.

I checked this morning with “zypper lu”. There were several updates available, but most were from the packman repo. I don’t remember seeing anything in the opensuse repos, except a kernel update. I’m waiting till I am ready to reboot before I install the kernel update.

I updated flash, but left everything else unchanged until just before I reboot some time tomorrow.

A new build would have provided many more updates from the opensuse repos.

The kernel update was released yesterday already though.
And I did install it yesterday, before the repos broke.

A new build would have provided many more updates from the opensuse repos.

Right, and it would show up in the file modification times when you open the repo URL in a web browser (and also in the file names, because a rebuild would mean a higher revision number without which it wouldn’t be seen as update anyway).

PS: in case you’re interested, this is the official explanation of the problem:

The problem was a mistake in the sync script.

While the official distribution has oss and non-oss directories, the ports
have/had not. But some of the ports (like armv7hl) now are also ready to
release a 42.2 (and beyond). While this is nice in general, the try to
generalize the repository sync script resulted in the described failure. (looks
like we should not allow admins to work late at the evening on productive

So while we pushed hard to get the original state back (including all mirrors),
we are currently discussing how to avoid such mistakes in the future. The
problem at the moment is, that we do not have a testing/staging setup for the
bash script that is handling the sync for special projects (this script started
as simple 5 liner and now contains a bunch of “special repo handling” stuff).

So while the original failure is fixed now, we need to investigate more during
the next days, hoping that there will not be another “special repo handling”
candidate knocking at our door or that the admin has his mind/eyes more open
when he adapts the script again.

I apologize for the trouble caused. This was not by intention nor a indication
for a hack. It was just a simple human error.