Seth Vidal wrote:
On Fri, 2008-09-12 at 16:05 +0100, Paul Howarth wrote:
> Today I tried building (in mock on a Fedora 9 host) some nmap packages
> for CentOS3 as version 4.76 came out. The mock build crashed out at the
> setup stage, due to the %pre script for the "dev" package failing (it
> thinks devfs is mounted). As I had built packages for version 4.75 only
> a couple of days ago, I tried rebuilding that and it now failed in the
> same way. I'd installed a bunch of updates in the last couple of days
> but the only one I could think of that might have caused that was the
> yum upgrade. So I downgraded yum from 3.2.19-3.fc9 to 3.2.17-2.fc9 and
> tried the build again, and this time it worked.
>
> The salient difference in the root.log was this:
>
> DEBUG util.py:250: Cannot install the dev package: mounted devfs
> detected.
> +DEBUG util.py:250:
> --------------------------------------------------------------------------------
> +DEBUG util.py:250: Total 1.5
> GB/s | 14 MB 00:00
> DEBUG util.py:250: error: %pre(dev-3.3.12.3-1.centos.0.x86_64)
> scriptlet failed, exit status 1
> DEBUG util.py:250: error: install: %pre scriptlet failed (2),
> skipping dev-3.3.12.3-1.centos.0
> DEBUG util.py:250: ls:
> @@ -233,8 +236,7 @@
> DEBUG util.py:250: mkinitrd failed
> DEBUG util.py:250: Installed: libpcap.x86_64 14:0.7.2-7.E3.5
> openssl-devel.x86_64 0:0.9.7a-33.24 pcre-devel.x86_64 0:3.9-10.4
> pkgconfig.x86_64 1:0.14.0-5 zlib-devel.x86_64 0:1.1.4-10.EL3
> DEBUG util.py:250: Dependency Installed: dev.x86_64
> 0:3.3.12.3-1.centos.0 kernel.x86_64 0:2.4.21-57.EL krb5-devel.x86_64
> 0:1.2.7-68 losetup.x86_64 0:2.11y-31.24 lvm.x86_64 0:1.0.8-14
> mkinitrd.x86_64 0:3.5.13.6-1
> -DEBUG util.py:311: Child returncode was: 0
> -DEBUG backend.py:436: Copying packages to result dir
> +DEBUG util.py:311: Child returncode was: 1
> DEBUG backend.py:484: umount -n /var/lib/mock/centos-3-x86_64/root/proc
> DEBUG util.py:272: Executing command: umount -n
> /var/lib/mock/centos-3-x86_64/root/proc
> DEBUG util.py:311: Child returncode was: 0
>
>
> So the scriptlet failures that didn't formerly affect affect mock builds
> due to the zero exit code of yum are now causing build failures due to a
> "1" exit code.
>
> I'm not sure what the best approach to fixing this should be. It makes
> perfect sense to me for yum to return a non-zero exit code when there's
> a scriptlet failure yet in some cases this is a problem that doesn't
> affect the subsequent build.
>
> As I suspect that this is a problem that mainly affects legacy
> distribution versions, perhaps there could be a mock option that could
> be set in the config file to ignore the yum exit code?
>
Yah - the exit code was changed with a scriptlet failure. I think the
correct thing to do here is to fix the pkg causing the scriptlet
failure.
Is there a reason why we can't do that?
This is without doubt the technically correct thing to do, though
"official" updates for legacy distros and even RHEL 3 may be hard to get.
I've taken the approach of building workaround packages and adding them
to a local repo in my buildsystem.
For CentOS 3, I needed a patched MAKEDEV package that didn't bail out of
%pre (at least for the "dev" subpackage) if there was something mounted
on /dev (which it assumed would be devfs).
For other distributions of similar vintage, I needed a hacked mkinitrd
package with a patched new-kernel-pkg script that didn't return a "1"
exit status if mkinitrd failed (which typically happened in the kernel
package's %post when mkinitrd found it didn't have any available loop
devices to use).
For Fedora 4 and 5 (some people just won't move on...) I also needed a
tweaked util-linux package with %post tweaked to return a zero exit
status. I think this may have been a package ordering issue as the %post
script was getting "command not found" errors for things in /bin like
touch, chown, and chmod.
One other curiosity I noticed whilst looking at these issues was that
mock silently refuses to overwrite an existing file if you try to do it
using config_opts['files'], even if that file is empty. So it's not
possible for instance to set up a custom /etc/fstab in the chroot this
way, since mock has already created an empty one by this time. What's
the reasoning behind this?
Paul.