Hello, download.o.o is down, answers all requests with a 403 error, and dmesg indicates /srv has filesystem issues :-( See https://progress.opensuse.org/issues/41933 for details. I can imagine you now quickly checked and everything looks good. No, I'm not drunk, and I'm not inventing issues ;-) What you see is a workaround - I changed download.o.o to redirect everything to provo-mirror and started apache (instead of nginx) there. As a workaround, I changed the apache config so that *** everything gets redirected to provo-mirror *** I also stopped nginx and instead started apache on provo-mirror, which means the mirrorbrain setup there is active now Obviously the redirect to provo-mirror comes with some problems. The mirrorbrain database in Provo is outdated (I'd guess last update was the NBG power outage) - it doesn't know about Leap 15, which means provo- mirror will have to handle lots of load and traffic itsself. We'll see how good it will survive under the load. I know this solution is far from perfect, but it's still better than serving a 403 error for all of download.o.o. The original apache config is in /etc/apache2---before-workaround-2018-10-03 I copied it there before adding the redirect + doing some other changes needed to let apache load the updated config - for example, apache doesn't like a /srv/whatever DocumentRoot if /srv/ isn't available. After fixing the /srv partition, you can move the backed up apache config back to production, and everything should work again as if nothing had happened ;-) Regards, Christian Boltz -- These are the requirements for granted correct behavior. If you are not interested in that, I am happy to provide you with a list of data that could be removed from a general Suse installation to let Suse Linux behave similar and to permit booting from time to time only. [Jörg Schiling in https://bugzilla.novell.com/550021#c32] -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org