Bug 459634
Summary: | rpms providing kdump scripts appear "auto-require" /bin/msh | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Rich Johnson <richard.johnson> |
Component: | kexec-tools | Assignee: | Neil Horman <nhorman> |
Status: | CLOSED NOTABUG | QA Contact: | Red Hat Kernel QE team <kernel-qe> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5.2 | CC: | dvlasenk, nhorman |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-04-27 13:26:09 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Rich Johnson
2008-08-20 18:51:01 UTC
busybox problem. busybox needs to include a Provides:/bin/msh directive. This has nothing to do with kexec-tools. Reassigning. AFAIKS, busybox rpms do not install /bin/msh (or any other applet). They only install /sbin/busybox.
So they cannot claim they provide /bin/msh.
/bin/msh are created by some other program.
>Steps to Reproduce:
>1. create an rpm including a kdump post script specifying the "$!/bin/msh"
>interpreter
>2. attempt to install rpm on a target system
1. Do you have an example of such rpm somewhere to take a look at?
2. What command do you use?
On a broader note, I am working on making busybox shells standard compatible enough so that they can be installed just as /bin/sh.
I am assuming scripts which explicitly use #!/bin/msh do so because they are using (working around) msh's bugs (there are many) and they can't use /bin/sh.
Starting from busybox 1.14.x, hush supersedes msh, and it is significantly less buggy and more standard compatible. As a longer term plan, whoever uses #!/bin/msh may consider installing hush or ash as /bin/sh and using just /bin/sh.
Thoughts?
If I misunderstood the problem, and it is indeed in busybox, please describe it in more details.
No, you're right, Thinking about it, If someone creates an rpm that has a script which uses /bin/msh as an interpreter, its that rpms responsibility to require /bin/msh. But as busybox doesn't actually create a /bin/msh link anywhere, it can't provide that. The only sane answer is for the initial rpm to require busybox instead, and run /sbin/busybox msh instead of just /bin/msh, or create the link manually. either way the rpm being created needs to Require: busybox directly Please which package needs "$!/bin/msh"? (I can't find lsb-ft-cstools - perhaps I overlook something), this is not busybox problem and it should be reassign to proper component. lsb-ft-cstools is a third party package extending kdump's (kexec-tools) capabilities. - Among it's deliveries are scripts to be run only from the initrd's busybox. - These scripts specify /bin/msh; a capability provided by the busybox in the initrd context. - The rpm requires kexec-tools, which in turn requires busybox. It follows that all dependencies should be satisfied. There is no need for /bin/msh outside the busybox environment. I think what's happening here is that rpm's Auto-Requires is generating an implicit (and spurious) requirement from the "#! /bin/msh" in the scripts. - Specifying "AutoReq: 0" in the specfile is an avoidance. - Allowing busybox scripts to specify "$!/bin/sh" would also work, but a requirement on the main runtime's /bin/sh is just as spurious. I'm pretty sure it's too much to ask for an initrd context qualifier to the Requires clause. (In reply to comment #5) > lsb-ft-cstools is a third party package extending kdump's (kexec-tools) > capabilities. > - Among it's deliveries are scripts to be run only from the initrd's busybox. > - These scripts specify /bin/msh; a capability provided by the busybox in the > initrd context. > - The rpm requires kexec-tools, which in turn requires busybox. I don't see it: $ rpm -qp --requires kexec-tools-1.102pre-96.el5_5.1.x86_64.rpm /bin/bash /bin/sh /bin/sh /bin/sh /bin/sh /bin/sh busybox >= 1.2.0 chkconfig config(kexec-tools) = 1.102pre-96.el5_5.1 coreutils libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rtld(GNU_HASH) sed Does it mean problem no longer exists in latest kexec-tools? > It follows that all dependencies should be satisfied. Obviously. > There is no need for > /bin/msh outside the busybox environment. I wonder why they chose to create a lot of PITA by not using msh as /bin/sh, not /bin/msh. Next time "small shell" is replaced, "/bin/msh" in all the scripts will need to be edited again. Oh well... maybe there is a reason for this. > I think what's happening here is that rpm's Auto-Requires is generating an > implicit (and spurious) requirement from the "#! /bin/msh" in the scripts. > > - Specifying "AutoReq: 0" in the specfile is an avoidance. In which specfile? > - Allowing busybox scripts to specify "$!/bin/sh" would also work, but a > requirement on the main runtime's /bin/sh is just as spurious. > I'm pretty sure it's too much to ask for an initrd context qualifier to the > Requires clause. I did not understand this part. And lastly, should this bug be reassigned to kexec-tools? This isn't a bug at all. Its simply an artifact of how you need to work with busybox. busybox provides the busybox binary, which does several things depending on command line options, one of which is the msh shell (which is whats used by kdump). If you write a script thats meant for kdump, and you want to package it in such a way that: 1) you can run it in kdump 2) you can test it on a normally running machine you need to do two things: A) write the script with this line at the top to specify the command interpreter: #!/sbin/busybox msh B) Add a Requires: busybox line in the spec file that you use to package the script This seems reasonable, and has been verified. |