Univention Bugzilla – Bug 55552
Improve pre-upgrade check
Last modified: 2023-03-08 08:45:23 CET
As agreed with PM here is bug for improving the pre-upgrade check: During an escalation by a customer after a failed upgrade to UCS 5.0 it was discovered that there were non-UCS packages installed, namely: libc6-i386, was left the system in a broken state, that required rolling back the snapshot. This already happened with another customer where I wrote some small bash scripts to a) detect left-over installed packages from Cool Solutions and b) left-over installed packages from Debian repository. Debian packages: dpkg -l > packages.txt ; for package in $(grep ^ii packages.txt | awk '{print $2 }' ); do res=$(apt policy ${package} 2>/dev/null 1>/dev/stdout | grep -A1 '\*\*\*' | tail -n1 | grep -c debian ) ; if [ "${res}" = "1" ]; then echo "${package} installed from Debian"; fi ; done Cool-Solutions: dpkg -l > packages.txt ; for package in $(grep ^ii packages.txt | awk '{print $2 }' ); do res=$(apt policy ${package} 2>/dev/null 1>/dev/stdout | grep -A1 '\*\*\*' | tail -n1 | grep -c cool-solutions ) ; if [ "${res}" = "1" ]; then echo "${package} installed from Cool Solutions repository"; fi ; done As there is no support for installed foreign packages it is better to check beforehand if those packages are installed before an upgrade fails and causes a support case or even an escalation by a customer. There is surely a better and faster way to check package database for foreign packages than the two Bash one-liners.
@Dirk - maybe something for UCS 5.1 ?
See https://git.knut.univention.de/univention/toolshed/-/blob/master/dpkg-get-pkg-repos which deprecated `find-packages-without-upstream-repository` and `print-package-repositories` (In reply to Ingo Steuwer from comment #1) > @Dirk - maybe something for UCS 5.1 ? We have less than two weeks left, which is not enough time for implementation and QA. At #bitflip is already over-booked, so which task shall be drop?
(In reply to Philipp Hahn from comment #2) > (In reply to Ingo Steuwer from comment #1) > > @Dirk - maybe something for UCS 5.1 ? > > We have less than two weeks left, which is not enough time for > implementation and QA. At #bitflip is already over-booked, so which task > shall be drop? I was asking about 5.1, not 5.0-3
(In reply to Ingo Steuwer from comment #3) > (In reply to Philipp Hahn from comment #2) > > (In reply to Ingo Steuwer from comment #1) > > > @Dirk - maybe something for UCS 5.1 ? > > > > We have less than two weeks left, which is not enough time for > > implementation and QA. At #bitflip is already over-booked, so which task > > shall be drop? > > I was asking about 5.1, not 5.0-3 Ah, sorry, me is in the 5.0-3 tunnel already.
Hmmm... What is the real benefit here? We would catch accidentally installed packages. But how were they installed in the first place? You do not "accidentally add the debian repository". At some point you know what you are doing. Years later this may have unwanted side effects during an upgrade. But at least at the beginning you really wanted that package. And you probably still do, at least you are not aware of any problems that may arise during upgrade, right? UCS can warn you. Always (diagnostic module) or before the upgrade (preup.sh). In both cases, you would need an option to override the warning. Because you may have good reasons for your packages. But then: Wouldn't the customer escalate anyway when they upgrade and the system breaks due to a cool solution?
(In reply to Dirk Wiesenthal from comment #5) > Hmmm... > > What is the real benefit here? We would catch accidentally installed > packages. But how were they installed in the first place? You do not > "accidentally add the debian repository". At some point you know what you > are doing. Years later this may have unwanted side effects during an > upgrade. But at least at the beginning you really wanted that package. And > you probably still do, at least you are not aware of any problems that may > arise during upgrade, right? > > UCS can warn you. Always (diagnostic module) or before the upgrade > (preup.sh). In both cases, you would need an option to override the warning. > Because you may have good reasons for your packages. > > But then: Wouldn't the customer escalate anyway when they upgrade and the > system breaks due to a cool solution? My suggestion here is to implement a check for packages which are not part of our standard repositories or App Center, print warnings about them and stop the update. The check can be deactivated by setting an UCR variable. The benefit is that the customer is made aware of the risk that the system has access to packages which are not in scope of our product tests and something bad might happen. And as said in the initial bug description there were cases where "something bad" was a broken system.