Bug 459634 - rpms providing kdump scripts appear "auto-require" /bin/msh
rpms providing kdump scripts appear "auto-require" /bin/msh
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kexec-tools (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Neil Horman
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-20 14:51 EDT by Rich Johnson
Modified: 2010-04-28 14:12 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-04-27 09:26:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rich Johnson 2008-08-20 14:51:01 EDT
Description of problem:

Rpms supplying kdump scripts specifying the "/bin/msh" interpreter for busybox encounter the following error upon installation:

Version-Release number of selected component (if applicable):
  kexec-tools-1.102pre-21.el5_2.2


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
  
Actual results:
  error: Failed dependencies:
        /bin/msh is needed by lsb-ft-cstools-6.0.2-191.x86_64


Expected results:
  no errors

Additional info:
  Related to bug 459622 ?
  Suggestion accept "$!/bin/sh" scripts in the kdump environment.


Avoidance:
  Add
    AutoReq: 0
  to the rpm's spec file to turn off auto-dependency generation.
Comment 1 Neil Horman 2008-08-20 14:57:22 EDT
busybox problem.  busybox needs to include a Provides:/bin/msh directive.     This has nothing to do with kexec-tools.  Reassigning.
Comment 2 Denys Vlasenko 2009-06-16 08:25:03 EDT
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.
Comment 3 Neil Horman 2009-06-16 09:38:23 EDT
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
Comment 4 Ivana Varekova 2009-06-17 01:53:03 EDT
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.
Comment 5 Rich Johnson 2009-07-07 18:09:36 EDT
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.
Comment 6 Denys Vlasenko 2010-04-27 08:52:48 EDT
(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?
Comment 7 Neil Horman 2010-04-27 09:26:09 EDT
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
Comment 8 Rich Johnson 2010-04-28 14:12:30 EDT
This seems reasonable, and has been verified.

Note You need to log in before you can comment on or make changes to this bug.