This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 243443 - man pages do not work in rescue mode
man pages do not work in rescue mode
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Joel Andres Granados
Milan Zazrivec
Depends On:
  Show dependency treegraph
Reported: 2007-06-08 14:20 EDT by Forrest Taylor
Modified: 2008-05-21 11:30 EDT (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2008-0397
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-21 11:30:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for RHEL 5 (907 bytes, patch)
2007-08-21 07:13 EDT, Joel Andres Granados
no flags Details | Diff
Activate man pages in rawhide (894 bytes, patch)
2007-08-21 07:14 EDT, Joel Andres Granados
no flags Details | Diff

  None (edit)
Description Forrest Taylor 2007-06-08 14:20:37 EDT
Description of problem:
Getting to the man pages in rescue mode does not work.  `man rpm`, for instance,
gives nothing.  I am not sure what the problem is--possibly the busybox less
pager doesn't work as expected.

Doing a chroot does not work either, as the MANPATH includes the /mnt/sysimage
directory.  I would like to see MANPATH also (exclusively?) include
/usr/share/man so that it works if chroot is available.

Version-Release number of selected component (if applicable):

How reproducible:
Comment 1 Joel Andres Granados 2007-08-17 08:49:45 EDT
less is ok.  manpath is set to
/mnt/sysimage/usr/share/man:/mnt/sysimage/usr/local/share/man, which is sane. 
I'm pretty sure this is an issue with the nroff script.
Comment 2 Joel Andres Granados 2007-08-18 12:24:07 EDT
The /mnt/sysimage/usr/bin/nroff script is trying to exec /usr/bin/iconv, which
is not present in rescue.
Comment 3 Joel Andres Granados 2007-08-21 07:13:17 EDT
Created attachment 161963 [details]
Patch for RHEL 5

The man pages will become active once the images are remade with the anaconda
Comment 4 Joel Andres Granados 2007-08-21 07:14:23 EDT
Created attachment 161964 [details]
Activate man pages in rawhide

The same bug is present in rawhide.  This will add man pages in rescue mode in
Comment 5 Forrest Taylor 2007-08-21 11:16:51 EDT
Might I suggest that MANPATH also include /usr/share/man and
/usr/local/share/man (without /mnt/sysimage)?  This would allow man pages to be
available in the chroot environment as well as rescue mode.
Comment 7 Joel Andres Granados 2007-08-23 12:58:23 EDT
Regarding comment #5.  I'm going to commit what has been done and open another
bug so I don't forget to add this to the rescue mode.
Comment 8 RHEL Product and Program Management 2007-10-15 23:58:11 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 10 Forrest Taylor 2007-11-02 11:22:48 EDT
Regarding comment #7, did you open a new bug, or should I?
Comment 11 Joel Andres Granados 2007-11-06 13:10:45 EST
comment #7 is taken care of in rawhide.
Comment 13 Milan Zazrivec 2008-02-06 07:34:43 EST
RHEL5.2-Server-20080206.nightly rescue mode:
# echo $MANPATH

If I chroot into /mnt/sysimage, $MANPATH points to nonexistent directories

* groff, iconv:
/usr/bin/groff and /usr/bin/iconv are present in stage2.img, not in minstg2.img.
Not sure whether that's intentional or not, but as long as those two binaries
are not present in minstg2.img, there's no way you can read man pages in rescue
mode over serial console for example.
Comment 14 Peter Jones 2008-02-06 14:52:04 EST
Is there a reason that:

HOME=/root chroot /mnt/sysimage bash -l -i

and then running "man foo" from that shell isn't sufficient to solve this problem?
Comment 15 Milan Zazrivec 2008-02-08 11:56:44 EST
RHEL5.2-Client-20070207.0 / anaconda-

Running HOME=/root chroot /mnt/sysimage bash -l -i
does not help, since it does not reset $MANPATH to the right
values needed in the chrooted (/mnt/sysimage) environment ($MANPATH
actually stays at /mnt/sysimage/usr/share/man:/mnt/sysimage/usr/local/share/man)

To be honest, I don't quite understand what was the original point of this bz.

Was it:
1) Being able to access man pages in rescue mode before chroot to /mnt/sysimage


2) Being able to access man pages in rescue mode after chroot to /mnt/sysimage

or 1) && 2) ?

If it's 1), then I have to say that this part works with stage2.img, not with
minstg2.img, because it lacks groff anc iconv.

If it's 2), then the $MANPATH variable is a problem. The only thing that
anaconda suggests before it puts you into the shell is to run chroot
/mnt/sysimage (it says nothing about bash parameters or anything else).
Comment 16 David Cantrell 2008-02-08 15:17:57 EST
Fixed in anaconda- and later.
Comment 18 Joel Andres Granados 2008-02-11 05:49:02 EST
Regarding comment #15:  Changed the MANPATH in the rescue environment,  should
work with new anaconda build.  So now man pages are accessible in nochroot and
chroot environments.
Comment 19 Milan Zazrivec 2008-02-13 03:59:27 EST
RHEL5.2-Client-20080211.0 / anaconda-

sh-3.00# echo $MANPATH

Man pages before and after chroot /mnt/sysimage work as expected.
Comment 20 Forrest Taylor 2008-02-26 15:37:39 EST
In response to comment # 15, I was hoping to have both 1 & 2--man pages from
chroot or non-chroot.  I'll try out the latest version.
Comment 22 errata-xmlrpc 2008-05-21 11:30:17 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

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