NST18: Failed to build transaction (...) requires /bin/python

  • Michael H. Warfield

    I have two, up to date, Fedora 18 systems, one an i686 and one an x86_64, which were both upgraded from Fedora 16 systems on which I was successfully building custom NST16 builds. I pulled down completely fresh svn checkouts of the main trunk and followed the instructions in the "How to Build NST 18" page. It ran nearly to completion and then failed with this error:

    Error creating Live CD : Failed to build transaction : 2:nmap-6.25-1.100.nst18.i686 requires /bin/python

    that was (obviously) from the i686 system. I got the same error from the x86_64 system.

    Presuming it may have been my "updated" build engines and some version skew, I built an entirely fresh clean Fedora 18 system from scratch on a different x86_64 system using the Fedora 18 install DVD. I then updated it to the latest software, and repeated the "svn checkout", "cd repo", "./configure", "make".

    First I discovered that Fedora 18 currently has a bug in the ClamAV packages, which are failing to create the "clamupdate" user and group. That was fixed by manually adding them and reinstalling the various clamav packages. Then the "make" still failed because the /etc/freshclam.conf file needed to be edited to comment out the "example" line (and set the region) - something which probably should be mentioned in the part about setting up the development server.

    Finally, the make ran and, in the end, I got the same error, plus a few more, from the make build like this:

    Error creating Live CD : Failed to build transaction : BackupPC-3.2.1-118.nst18.noarch requires /bin/perl
    netwag-5.39.0-6.nst18.noarch requires /bin/wish8.5
    2:nmap-6.25-1.100.nst18.x86_64 requires /bin/python
    1:suricata-1.4.1-102.nst18.x86_64 requires /bin/python
    u2ps-0.8.2-5.nst18.noarch requires /bin/perl
    Unmounting directory /home/mhw/repo/livecd/tmp/imgcreate-weoxnI/install_root

    Something weird going on here. To quote Heinlein, once is chance, twice is coincidence, three times is enemy action. That's three systems with the same problem. There's something I'm doing wrong here or that I'm missing and I'm just not seeing it.

    Oh, and I first tried this a couple of months or so ago and have tried it about once a week since, updating the systems and then updating the repo (hoping it was something being fixed), with no change.

  • Paul Blankenbaker

    Thanks for all of your investigative efforts Michael.

    We have two development systems (x86_64 and i686) which do yum updates, fresh svn checkouts of the NST source code and builds each night. We are not seeing the issue you are reporting.

    However, we have had those two development systems set up and running for many months now. We have not tried setting up a new development machine recently.

    I will try setting up a new development system from scratch (starting with a Fedora 18 x86_64 live ISO) and to replicate the issue you are seeing and then document what needs to be done to work around it.

    I'm not sure how there can be /bin/python or /bin/perl dependency issues - seems like those should resolve easily.

    I'm a bit swamped at the moment so it may be a few days before I get to this.

  • Paul Blankenbaker

    The short answer (I hope) is not to use the GNOME 3 desktop as the root user.

    Here is what I did (that worked):

    • I used a Fedora 18 x86_64 live ISO image as a starting point.
      [root@rice iso]# md5sum Fedora-18-x86_64-Live-Desktop.iso
      0e32be24b38cba98bd62260896963b43 Fedora-18-x86_64-Live-Desktop.iso
      [root@rice iso]#
    • I installed Fedora 18 onto a VirtualBox system and created a devel account.
    • I gave the devel account free use of the sudo command (no password prompting required).
    • I updated all of the packages on the system.
    • I rebooted the system to load the new kernel.
    • I installed the VirtualBox guest additions and rebooted again to make sure they loaded cleanly.
    • I logged in as the devel user with a GNOME 3 desktop.
    • I following the instructions on the NST WIKI (http://wiki.networksecuritytoolkit.org/nstwiki/index.php/HowTo_Build_NST_18) for checking out the source code.
    • I ran configure.
    • I ran make and ran into the issue your reported about the current Fedora clamav packages having problems. So I temporarily added a minus in front of the following line in livecd/include/make/iso.mk (NOTE: This change has not been pushed out to the ''repo'' area yet so you will need to make it by hand for the time being):
      -$(__sudo_run) $(FRESHCLAM) -v >| freshclam-update.log 2>&1;
    • I ran make again and successfully build the ISO image.

    So at this point I was scratching my head trying to figure out how our two systems might be different. One of the differences that might be possible is that we never use GNOME 3 on our development systems (it just hasn't grown on us yet and we end up using Fluxbox, MATE or a simple ssh login).

    So, I decided to try repeating the build process by logging back into the GNOME 3 desktop, but as the root user.

    When I did this, my build failed.

    I've updated the NST Wiki page with a warning that you should avoid using GNOME 3 when building the NST.

    So then I tried logging out of the GNOME 3 desktop again and using ssh to log in to the system as the root user without any desktop. I was able to successfully build using this method as well.

    So, my question to you is, is it possible that your are logged into the GNOME 3 desktop as the root user and if so, can you try logging out of the GNOME 3 desktop and come in via ssh instead (or use a alternate desktop)?

  • Michael H. Warfield

    Ok... After some significant E-Mail this weekend with Paul, it looks like we have this nailed down (I think). It is / was due to attempting to build NST while running as the superuser (logging in as root, stepping up with su, or running sudo -s before) running ./configure ; make. The thing with GNOME 3 appears to have been a red herring. All three of my build engines are now functioning normally as long as I do not build an initial build as root. If you do run the build as a superuser and you get the indicated dependency errors, you have to run "make clear" and "rm -rf yum/repo" and then try again as a normal user (or check out a whole new source tree). Once that error gets into the local repository, you're screwed until it is deleted.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks