10264 2016-09-13 01:55:00 +0000 On-target postinstall failure results in a wrong state of an rpm package 2016-09-30 02:55:27 +0000 1 1 11 Runtime General Runtime General Runtime 2.2 x86 Multiple RESOLVED NOTABUG Medium+ normal 2.2 M4 1 Qi.Chen stephano anibal.limon leonardo.sandoval.gonzalez liezhi.yang markus.lehtonen --- --- Don't know oldest_to_newest 66068 0 Qi.Chen 2016-09-13 01:55:00 +0000 If we install an rpm package on target and its postinstall script fails to run successfully. The files of the rpm package are installed on target but the rpm package is not considered installed. Please see the console output below for an example. root@qemux86-64:~# rpm -q pulseaudio-server pulseaudio-server-9.0-r0.core2_64 root@qemux86-64:~# rpm -e pulseaudio-server Failed to connect to bus: No such file or directory Removed /etc/systemd/user/sockets.target.wants/pulseaudio.socket. Removed /etc/systemd/user/default.target.wants/pulseaudio.service. root@qemux86-64:~# rpm -q pulseaudio-server package pulseaudio-server is not installed root@qemux86-64:~# rpm -i pulseaudio-server-9.0-r0.core2_64.rpm Running groupadd commands... NOTE: pulseaudio: Performing groupadd with [ pulse] NOTE: pulseaudio: group pulse already exists, not re-creating it Running useradd commands... NOTE: pulseaudio: Performing useradd with [ --system --home /var/run/pulse --no-create-home --shell /bin/false --groups audio,pulse --gid pulse pulse] NOTE: pulseaudio: user pulse already exists, not re-creating it Created symlink /etc/systemd/user/default.target.wants/pulseaudio.service → /usr/lib/systemd/user/pulseaudio.service. Created symlink /etc/systemd/user/sockets.target.wants/pulseaudio.socket → /usr/lib/systemd/user/pulseaudio.socket. Failed to connect to bus: No such file or directory error: %post(pulseaudio-server-9.0-r0.core2_64) scriptlet failed, exit status 1 root@qemux86-64:~# echo $? 1 root@qemux86-64:~# rpm -q pulseaudio-server package pulseaudio-server is not installed root@qemux86-64:~# ls /usr/lib/systemd/user/pulseaudio.s* /usr/lib/systemd/user/pulseaudio.service /usr/lib/systemd/user/pulseaudio.socket 66660 1 stephano 2016-09-27 23:25:49 +0000 I can't seem to reproduce this error. What does your image install look like? I've got systemd and pulseaudio-server running and here's my output: root@qemux86-64:~# rpm -e pulseaudio-server root@qemux86-64:~# rpm -q pulseaudio-server package pulseaudio-server is not installed root@qemux86-64:~# rpm -i pulseaudio-server-9.0-r0.0.core2_64.rpm Running groupadd commands... NOTE: pulseaudio: Performing groupadd with [ pulse] NOTE: pulseaudio: group pulse already exists, not re-creating it Running useradd commands... NOTE: pulseaudio: Performing useradd with [ --system --home /var/run/pulse --no-create-home --shell /bin/false --groups audio,pulse --gid pulse pulse] NOTE: pulseaudio: user pulse already exists, not re-creating it root@qemux86-64:~# echo $? 0 root@qemux86-64:~# rpm -q pulseaudio-server pulseaudio-server-9.0-r0.0.core2_64 66709 2 Qi.Chen 2016-09-29 03:30:13 +0000 You need to make the postinstall fail deliberately. You can do modifications like below. diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc index 7e54ad4..e8ba040 100644 --- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc +++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc @@ -145,6 +145,9 @@ pkg_postinst_${PN}-server() { if [ -z "$D" ] && [ -e ${sysconfdir}/init.d/populate-volatile.sh ] ; then ${sysconfdir}/init.d/populate-volatile.sh update fi + if [ -z "$D" ]; then + exit 1 + fi } And below are the results. qemux86-64 login: root root@qemux86-64:~# rpm -q pulseaudio-server pulseaudio-server-9.0-r0.core2_64 root@qemux86-64:~# rpm -e pulseaudio-server root@qemux86-64:~# ls pulseaudio-server-9.0-r0.core2_64.rpm root@qemux86-64:~# ls /usr/lib/systemd/user basic.target busnames.target exit.target printer.target smartcard.target sound.target timers.target bluetooth.target default.target paths.target shutdown.target sockets.target systemd-exit.service root@qemux86-64:~# rpm -i pulseaudio-server-9.0-r0.core2_64.rpm Running groupadd commands... NOTE: pulseaudio: Performing groupadd with [ pulse] NOTE: pulseaudio: group pulse already exists, not re-creating it Running useradd commands... NOTE: pulseaudio: Performing useradd with [ --system --home /var/run/pulse --no-create-home --shell /bin/false --groups audio,pulse --gid pulse pulse] NOTE: pulseaudio: user pulse already exists, not re-creating it error: %post(pulseaudio-server-9.0-r0.core2_64) scriptlet failed, exit status 1 root@qemux86-64:~# echo $? 1 root@qemux86-64:~# ls /usr/lib/systemd/user basic.target busnames.target exit.target printer.target pulseaudio.socket smartcard.target sound.target timers.target bluetooth.target default.target paths.target pulseaudio.service shutdown.target sockets.target systemd-exit.service root@qemux86-64:~# ls /usr/lib/systemd/user/pulseaudio.service /usr/lib/systemd/user/pulseaudio.service root@qemux86-64:~# rpm -q pulseaudio-server package pulseaudio-server is not installed root@qemux86-64:~# 66738 3 stephano 2016-09-30 02:00:10 +0000 As far as I can tell, this is the way that RPM is designed to work. Per Jeff Johnson: [T]he %post script needs to be written "robustly" so that the exit code is always 0. If you need/want to tell whether some specific operation "worked", then write a test after rpm has run for that specific operation. Another approach would be to have the %post script register its state somewhere in /var so that you can easily test whether the script "worked" or not. ... I'd have to know more about what is implied by a %post success/failure in order to suggest some other approach. In Yocto, we allow the postinstall return code to be != 0 at build time so that those postinstall scripts can be re-run on the host, as documented here: http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new-recipe-post-installation-scripts However, this does not seem to be the case in RPM. Looking at the RPM code, when the package state machine encounters a non-zero exit status, it simply exits. No cleanup is attempted. What are you trying to accomplish here by having a postinstall script fail on the host? We may be able to add a feature to accommodate your goals, but it looks like RPM postinstall scripts are not an option. 66739 4 Qi.Chen 2016-09-30 02:18:00 +0000 (In reply to comment #3) > As far as I can tell, this is the way that RPM is designed to work. Per Jeff > Johnson: > > > [T]he %post script needs to be written "robustly" so that the exit code is > always 0. If you need/want to tell whether some specific operation "worked", > then write a test after rpm has run for that specific operation. Another > approach would be to have the %post script register its state somewhere in > /var so that you can easily test whether the script "worked" or not. > ... > I'd have to know more about what is implied by a %post success/failure in > order to suggest some other approach. > > > In Yocto, we allow the postinstall return code to be != 0 at build time so > that those postinstall scripts can be re-run on the host, as documented here: > > http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new- > recipe-post-installation-scripts > > However, this does not seem to be the case in RPM. Looking at the RPM code, > when the package state machine encounters a non-zero exit status, it simply > exits. No cleanup is attempted. > > What are you trying to accomplish here by having a postinstall script fail > on the host? We may be able to add a feature to accommodate your goals, but > it looks like RPM postinstall scripts are not an option. Thanks for you investigation and information. I didn't know that it's deliberately designed to behave like that. I'm trying to accomplish something by making a postinstall script fail. I brought up this problem because I think some postinstall script might fail, resulting in a broken state of an rpm package. If a non-zero exit status for postinstall script of an rpm package is not allowed, and we are going to change this behaviour, how about we do some documentation and just close this bug? 66740 5 Qi.Chen 2016-09-30 02:20:11 +0000 (In reply to comment #3) > As far as I can tell, this is the way that RPM is designed to work. Per Jeff > Johnson: > > > [T]he %post script needs to be written "robustly" so that the exit code is > always 0. If you need/want to tell whether some specific operation "worked", > then write a test after rpm has run for that specific operation. Another > approach would be to have the %post script register its state somewhere in > /var so that you can easily test whether the script "worked" or not. > ... > I'd have to know more about what is implied by a %post success/failure in > order to suggest some other approach. > > > In Yocto, we allow the postinstall return code to be != 0 at build time so > that those postinstall scripts can be re-run on the host, as documented here: > > http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new- > recipe-post-installation-scripts > > However, this does not seem to be the case in RPM. Looking at the RPM code, > when the package state machine encounters a non-zero exit status, it simply > exits. No cleanup is attempted. > > What are you trying to accomplish here by having a postinstall script fail > on the host? We may be able to add a feature to accommodate your goals, but > it looks like RPM postinstall scripts are not an option. Thanks for you investigation and information. I didn't know that it's deliberately designed to behave like that. I'm not trying to accomplish something by making a postinstall script fail. I brought up this problem because I think some postinstall script might fail, resulting in a broken state of an rpm package. If a non-zero exit status for postinstall script of an rpm package is not allowed, and we are not going to change this behaviour, how about we do some documentation and just close this bug? 66743 6 stephano 2016-09-30 02:55:27 +0000 (In reply to comment #5) > (In reply to comment #3) > > As far as I can tell, this is the way that RPM is designed to work. Per Jeff > > Johnson: > > > > > > [T]he %post script needs to be written "robustly" so that the exit code is > > always 0. If you need/want to tell whether some specific operation "worked", > > then write a test after rpm has run for that specific operation. Another > > approach would be to have the %post script register its state somewhere in > > /var so that you can easily test whether the script "worked" or not. > > ... > > I'd have to know more about what is implied by a %post success/failure in > > order to suggest some other approach. > > > > > > In Yocto, we allow the postinstall return code to be != 0 at build time so > > that those postinstall scripts can be re-run on the host, as documented here: > > > > http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new- > > recipe-post-installation-scripts > > > > However, this does not seem to be the case in RPM. Looking at the RPM code, > > when the package state machine encounters a non-zero exit status, it simply > > exits. No cleanup is attempted. > > > > What are you trying to accomplish here by having a postinstall script fail > > on the host? We may be able to add a feature to accommodate your goals, but > > it looks like RPM postinstall scripts are not an option. > > Thanks for you investigation and information. I didn't know that it's > deliberately designed to behave like that. > > I'm not trying to accomplish something by making a postinstall script fail. > I brought up this problem because I think some postinstall script might > fail, resulting in a broken state of an rpm package. > > If a non-zero exit status for postinstall script of an rpm package is not > allowed, and we are not going to change this behaviour, how about we do some > documentation and just close this bug? Sounds like a good plan. I added Bug 10351 and CC'd you on it. I will close this bug and work off that one going forward.