I want to upgrade busybox-syslog package. Upgrade calls prerm script. Script looks like this: # remove syslog if test "x$D" = "x"; then if test "$1" = "upgrade" -o "$1" = "remove"; then /etc/init.d/syslog stop fi fi update-alternatives --remove syslog-conf /etc/syslog.conf.busybox update-alternatives --remove syslog-init /etc/init.d/syslog.busybox update-alternatives --remove syslog-startup-conf /etc/syslog-startup.conf.busybox if [ -z "$D" ]; then /etc/init.d/syslog stop fi Problem is that update-alternatives removes /etc/init.d/syslog link. So second "/etc/init.d/syslog stop" call always fails. Here is the output: # opkg --version opkg version 0.3.3 # opkg install /tmp/busybox-syslog_1.24.1-r3_mips32el.ipk Upgrading busybox-syslog from 1.24.1-r0 to 1.24.1-r3 on root. Installing busybox-syslog (1.24.1) on root. Stopping syslogd/klogd: stopped syslogd (pid 711) stopped klogd (pid 714) done update-alternatives: removing /etc/syslog.conf as no more alternatives exist for it update-alternatives: removing /etc/init.d/syslog as no more alternatives exist for it update-alternatives: removing /etc/syslog-startup.conf as no more alternatives exist for it ///var/lib/opkg/info/busybox-syslog.prerm: line 12: /etc/init.d/syslog: not found To remove package debris, try `opkg remove busybox-syslog`. To re-attempt the install, try `opkg install busybox-syslog`. Collected errors: * pkg_run_script: package "busybox-syslog" prerm script returned status 127. * prerm_upgrade_old_pkg: prerm script for package "busybox-syslog" failed * opkg_solver_install: Cannot install package busybox-syslog. It seems this is the problematic git commit: http://git.openembedded.org/openembedded-core/commit/meta/classes/update-alternatives.bbclass?id=2a5484a90513b58c829a916bfe5268a0fde3512a It is possible to switch the order of the calls? So first update-rc.d.bbclass and then update-alternatives.bbclass ?
Patch sent for review: https://patchwork.openembedded.org/patch/132685/ Would you be able to verify that it fixes your issue?
The patch is in master-next: http://git.openembedded.org/openembedded-core/commit/?h=master-next&id=11b2224ceca8ccd7c44b3ce64c1ee38e97cc1d9a However, I also submitted slightly improved v3 of the patch: https://patchwork.openembedded.org/patch/132725/ Either will fix the bug although v3 is slightly more robust.
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ac647ea6964e166c395334fe107015030adc1b76 but lets not forget about the other changes we talked about to improve things a little further!
Yes, the patch fixes the problem. But it's a more general problem. Latest opkg version executes postrm and prerm scripts during an upgrade. If the last statement in the script returns error code opkg aborts. http://git.yoctoproject.org/cgit/cgit.cgi/opkg/commit/libopkg/opkg_install.c?id=a8555d352d2851ee1482b74b57ba9eacfb354c18 See here. I stop avahi daemon before the upgrade and upgrade fails: root@et8500:~# opkg -v opkg version 0.3.3 root@et8500:~# /etc/init.d/avahi-daemon stop * Stopping Avahi mDNS/DNS-SD Daemon: avahi-daemon ...done. root@et8500:~# opkg install /tmp/avahi-daemon_0.6.32-r0_mips32el.ipk Upgrading avahi-daemon from 0.6.31-r0 to 0.6.32-r0 on root. Installing avahi-daemon (0.6.32) on root. * Stopping Avahi mDNS/DNS-SD Daemon: avahi-daemon ...fail! To remove package debris, try `opkg remove avahi-daemon`. To re-attempt the install, try `opkg install avahi-daemon`. Collected errors: * pkg_run_script: package "avahi-daemon" prerm script returned status 1. * prerm_upgrade_old_pkg: prerm script for package "avahi-daemon" failed * opkg_solver_install: Cannot install package avahi-daemon. There is also a problem when you don't stop the daemon: root@et8500:~# /etc/init.d/avahi-daemon start * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon ...done. root@et8500:~# opkg install /tmp/avahi-daemon_0.6.32-r0_mips32el.ipk Upgrading avahi-daemon from 0.6.31-r0 to 0.6.32-r0 on root. Installing avahi-daemon (0.6.32) on root. * Stopping Avahi mDNS/DNS-SD Daemon: avahi-daemon ...done. * Stopping Avahi mDNS/DNS-SD Daemon: avahi-daemon ...fail! update-rc.d: /etc/init.d/avahi-daemon exists during rc.d purge (continuing) Removing any system startup links for avahi-daemon ... /etc/rc0.d/K19avahi-daemon /etc/rc1.d/K19avahi-daemon /etc/rc2.d/S21avahi-daemon /etc/rc3.d/S21avahi-daemon /etc/rc4.d/S21avahi-daemon /etc/rc5.d/S21avahi-daemon /etc/rc6.d/K19avahi-daemon Running useradd commands... NOTE: avahi: Performing useradd with [ --system --home /var/run/avahi-daemon --no-create-home --shell /bin/false --user-group avahi] NOTE: avahi: user avahi already exists, not re-creating it deluser: can't find avahi in /etc/group delgroup: unknown group avahi update-rc.d: /etc/init.d/avahi-daemon exists during rc.d purge (continuing) Removing any system startup links for avahi-daemon ... Configuring avahi-daemon. Adding system startup for /etc/init.d/avahi-daemon. * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon Timeout reached while wating for return value Could not receive return value from daemon process. ...fail! root@et8500:~# grep avahi /etc/passwd root@et8500:~# grep avahi /etc/group root@et8500:~# ps -w | grep ava 924 root 2780 S grep ava preinst creates the avahi group and user and postrm (which is I think called afterwards) deletes the user and group again. (should I create new bugs for it?)
Argh, that is bad :/ I just sent two patches to fix that specific behavior: http://lists.openembedded.org/pipermail/openembedded-core/2016-October/127467.html
(In reply to comment #3) > http://git.yoctoproject.org/cgit.cgi/poky/commit/ > ?id=ac647ea6964e166c395334fe107015030adc1b76 > > but lets not forget about the other changes we talked about to improve > things a little further! I guess you mean the class inheritance checking(?) I've not forgotten those and they're (two patches) in contrib repo: http://git.openembedded.org/openembedded-core-contrib/log/?h=marquiz/fixes-10299 http://git.openembedded.org/openembedded-core-contrib/log/?h=marquiz/bitbake/fixes-10299 But, I think those patches can be postponed to 2.3. I can prepare and submit them for 2.2 too, if you'd like, though.
Haven't tested the patches yet. I try to do it tomorrow. But it seems to me that they "only" fix first problem with upgrade with stopped daemon and not the problem with running daemon that users and groups are missing, or? Wouldn't it be a better solution to ignore return values in opkg? There might be other prerm, preinst scripts in packages without daemons which might return errors because of minor issues(file is missing or cannot be executed ...) and then upgrade always fails. I guess it's quite difficult to make all scripts robust against all possible errors, or?
I just ran into the same problem, with busybox-syslog. These patches won't help if a package with the bad prerm is already installed. The only way to recover seems to be to forcefully uninstall busybox-syslog and reinstall it. In opkg, there is mention of dpkg doing some extra work if the prerm fails, namely to run the prerm of the new package with a 'failed-upgrade' argument. That way a new package can recover from the situation with a normal upgrade command, without having to force-uninstall and reinstall. It's also too bad that none of the opkg --force-* flags is useful here. I'm having a look if adding a --ignore-scripts or something would be useful. Or adding the 'failed-upgrade' functionality.
We should probably create a new bug about opkg package scriptlet handling.
(In reply to comment #7) > Haven't tested the patches yet. I try to do it tomorrow. But it seems to me > that they "only" fix first problem with upgrade with stopped daemon and not > the problem with running daemon that users and groups are missing, or? Oh, I somehow ignored this problem. I think that it's a bug in avahi that it tries to remove users or groups. Otherwise the system may be left with files with non-existent owner and may even lead to security issues if somebody else later adds a new user or group with the used-to-be-avahi UID or GID.
@Markus: The problem with avahi wasn't there with old opkg version as the scripts weren't executed. I will create new bug against opkg. @Rob: A colleague found the bugs. I'm only the reporter. He said that also an upgrade of the opkg package fails(haven't tested this myself). So if a user already has installed the packages, I guess the only way to fix the problem is to forcefully (manually) deinstall the packages and install new version again or to reinstall complete system. I see no way to fix it as most likely also opkg package upgrade fails.
I just tested your patches. The problem that a stopped daemon causes upgrade to fail is fixed. Nevertheless avahi daemon package cannot be upgraded. As said I will create new bug against opkg regarding script handling.
Here is the new bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10430
Thanks! Independent of the script failures, I think avahi shouldn't delete users or groups because of the reasons I stated above. What do you think? I can create a bug about that.
I think it's more a opkg bug. Old opkg version didn't execute postrm and prerm scripts in case of an upgrade. So in past problem was not there. New version execute the scripts in case of an upgrade and fails if there are errors in the script. Removing the deluser from the postrm script is I think not correct as postrm is also executed when you deinstall a package. And in this case I guess is user deletion correct, or? So I think only in case of an upgrade user deletion shouldn't be performed. And this can only be changed in opkg. Is there somewhere a documentation what may be added to postrm/prerm/preinst/postinst scripts and what not? Which scripts should be executed in which cases (install, deinstall, upgrade)? What should the scripts return? How should opkg, dpkg, ... in case of install/deinstall/upgrade handle these return values? If there is no documentation, I guess you should open a discussion with OE-core, opkg, dpkg,... guys how it should work. By the way I found meta/recipes-devtools/distcc/distcc_3.2.bb also calls deluser in postrm script.
Sorry, read your comment again. So never delete users again? And what if the passwd line is wrong? E.g. user changed it. Ok, users fault, but then he has only the possibility to reinstall complete system. Or can you check passwd entry in installation script and adapt it if it is not correct?
Regarding avahi userdel/groupdel, I created bug 10442. Let's continue the discussion there.