Red Hat Bugzilla – Bug 243443
man pages do not work in rescue mode
Last modified: 2008-05-21 11:30:17 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):
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.
The /mnt/sysimage/usr/bin/nroff script is trying to exec /usr/bin/iconv, which
is not present in rescue.
Created attachment 161963 [details]
Patch for RHEL 5
The man pages will become active once the images are remade with the anaconda
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
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.
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.
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
Regarding comment #7, did you open a new bug, or should I?
comment #7 is taken care of in rawhide.
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.
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?
RHEL5.2-Client-20070207.0 / anaconda-220.127.116.11-1:
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.
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).
Fixed in anaconda-18.104.22.168-1 and later.
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
RHEL5.2-Client-20080211.0 / anaconda-22.214.171.124-1:
sh-3.00# echo $MANPATH
Man pages before and after chroot /mnt/sysimage work as expected.
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.
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.