Hi,
When I try to install the latest yum modified mach on an x86_64 FC Development (as of last week, yum 2.3.2) it then tricks me into thinking that the roots I set up are fine (no errors in the output) when they're not ;-)
I recall having had the same problem on an RHEL4 host for all roots too, which I worked around by manually installing all missing packages, most with --noscripts... and at one point things started to work.
But now, although the "mach setup minimal" reported nothing unusual, here is what I get right after when trying "mach yum groupinstall build- minimal" :
[dude@darkside easytag]$ mach setup minimal Preparing root Making /dev devices Installing group 'minimal' .................. [dude@darkside easytag]$ mach setup minimal [dude@darkside easytag]$ mach yum groupinstall build-minimal Setting up Group Process Setting up repositories core 100% |=========================| 1.1 kB 00:00 freshrpms 100% |=========================| 951 B 00:00 updates 100% |=========================| 951 B 00:00 groups 100% |=========================| 1.1 kB 00:00 Setting up repositories Reading repository metadata in from local files Passing package list to Install Process Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package rpm.x86_64 0:4.3.2-21 set to be updated ---> Package initscripts.x86_64 0:7.93.7-1 set to be updated --> Running transaction check --> Processing Dependency: fileutils for package: initscripts --> Processing Dependency: kernel >= 2.6 for package: initscripts --> Processing Dependency: sh-utils for package: initscripts --> Processing Dependency: fileutils for package: rpm --> Processing Dependency: /sbin/runuser for package: initscripts --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package kernel.x86_64 0:2.6.11-1.14_FC3 set to be installed ---> Package coreutils.x86_64 0:5.2.1-31 set to be updated --> Running transaction check --> Processing Dependency: pam >= 0.66-12 for package: coreutils --> Processing Dependency: libpam_misc.so.0()(64bit) for package: coreutils --> Processing Dependency: libpam.so.0()(64bit) for package: coreutils --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package pam.x86_64 0:0.77-66.2 set to be updated --> Running transaction check
Dependencies Resolved
============================================================================= Package Arch Version Repository Size ============================================================================= Installing: initscripts x86_64 7.93.7-1 updates 1.1 M rpm x86_64 4.3.2-21 core 566 k Installing for dependencies: coreutils x86_64 5.2.1-31 core 2.9 M kernel x86_64 2.6.11-1.14_FC3 updates 17 M pam x86_64 0.77-66.2 updates 1.9 M
Transaction Summary ============================================================================= Install 5 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 24 M Downloading Packages: Running Transaction Test warning: pam-0.77-66.2: Header V3 DSA signature: NOKEY, key ID 4f2a6fd2 Finished Transaction Test Transaction Test Succeeded Running Transaction error: %pre(coreutils-5.2.1-31.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping coreutils-5.2.1-31 error: %pre(kernel-2.6.11-1.14_FC3.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping kernel-2.6.11-1.14_FC3 error: %pre(pam-0.77-66.2.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping pam-0.77-66.2 error: %pre(rpm-4.3.2-21.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping rpm-4.3.2-21 error: %pre(initscripts-7.93.7-1.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping initscripts-7.93.7-1
Installed: initscripts.x86_64 0:7.93.7-1 rpm.x86_64 0:4.3.2-21 Dependency Installed: coreutils.x86_64 0:5.2.1-31 kernel.x86_64 0:2.6.11-1.14_FC3 pam.x86_64 0:0.77-66.2 Complete! [dude@darkside easytag]$
(sorry if things get all wrapped around :-/)
Now the other weird thing is that if I "manually" use "mach rpm -ivh" for all those exact packages, it works fine. It seems that it fails only through yum :-( Given the trivial content of some of these scriplets, I'm really confused! The glibc-kernheaders which fails the same way is :
preinstall scriptlet (using /bin/sh): [ -L /usr/include/linux ] && rm -f /usr/include/linux || : [ -L /usr/include/asm ] && rm -f /usr/include/asm || : exit 0
I really don't see how that manages to fail :-( If I try to "mach chroot" after manually installing what is missing from the "minimal" group, it works, but "yum groupinstall build-base" then fails with other packages, same for the main build group.
Any ideas? Seth, you're building packages on an x86_64, aren't you?
Matthias
(sorry if things get all wrapped around :-/)
Now the other weird thing is that if I "manually" use "mach rpm -ivh" for all those exact packages, it works fine. It seems that it fails only through yum :-( Given the trivial content of some of these scriplets, I'm really confused! The glibc-kernheaders which fails the same way is :
I really don't see how that manages to fail :-( If I try to "mach chroot" after manually installing what is missing from the "minimal" group, it works, but "yum groupinstall build-base" then fails with other packages, same for the main build group.
Any ideas? Seth, you're building packages on an x86_64, aren't you?
is selinux disabled?
-sv
seth vidal wrote :
(sorry if things get all wrapped around :-/)
Now the other weird thing is that if I "manually" use "mach rpm -ivh" for all those exact packages, it works fine. It seems that it fails only through yum :-( Given the trivial content of some of these scriplets, I'm really confused! The glibc-kernheaders which fails the same way is :
I really don't see how that manages to fail :-( If I try to "mach chroot" after manually installing what is missing from the "minimal" group, it works, but "yum groupinstall build-base" then fails with other packages, same for the main build group.
Any ideas? Seth, you're building packages on an x86_64, aren't you?
is selinux disabled?
Yes, it was set to "Warn" at installation time.
Matthias
On Mon, 2005-04-25 at 20:58 +0200, Matthias Saou wrote:
seth vidal wrote :
(sorry if things get all wrapped around :-/)
Now the other weird thing is that if I "manually" use "mach rpm -ivh" for all those exact packages, it works fine. It seems that it fails only through yum :-( Given the trivial content of some of these scriplets, I'm really confused! The glibc-kernheaders which fails the same way is :
I really don't see how that manages to fail :-( If I try to "mach chroot" after manually installing what is missing from the "minimal" group, it works, but "yum groupinstall build-base" then fails with other packages, same for the main build group.
Any ideas? Seth, you're building packages on an x86_64, aren't you?
is selinux disabled?
Yes, it was set to "Warn" at installation time.
turn it off, entirely.
do not even turn on 'warn' and tell me what you get, please.
-sv
seth vidal wrote :
is selinux disabled?
Yes, it was set to "Warn" at installation time.
turn it off, entirely.
do not even turn on 'warn' and tell me what you get, please.
I upgraded the system to today's Rawhide, rebooted with "selinux=off"... and I get something that seems to be working as expected now! I guess "Warn" doesn't really work as advertised.
Actually, I just got the machine to reboot instantly 3 times in a row while rebuilding a package and doing important nfs I/O... but that's a problem for another list ;-)
Matthias
On Mon, 25 Apr 2005, Matthias Saou wrote:
seth vidal wrote :
is selinux disabled?
Yes, it was set to "Warn" at installation time.
turn it off, entirely.
do not even turn on 'warn' and tell me what you get, please.
I upgraded the system to today's Rawhide, rebooted with "selinux=off"... and I get something that seems to be working as expected now! I guess "Warn" doesn't really work as advertised.
Yeah - I've been playing around with this recently as well and for chroot installations you'll want selinux completely off, otherwise it'll fail. Haven't dug any deeper as to why is that (selinux still scares me :)
- Panu -
thias@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) writes:
is selinux disabled?
Yes, it was set to "Warn" at installation time.
turn it off, entirely.
do not even turn on 'warn' and tell me what you get, please.
I upgraded the system to today's Rawhide, rebooted with "selinux=off"... and I get something that seems to be working as expected now! I guess "Warn" doesn't really work as advertised.
afais, mach is using an LD_PRELOAD wrapper also. With Linux-Vservers, we are overriding rpm_execcon(3) and things seem to work fine.
http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/src/rpm...
Enrico
buildsys@lists.fedoraproject.org