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): anaconda-11.1.2.36-1 How reproducible: Always
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 scripts.
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 rawhide.
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 release.
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: * MANPATH: # echo $MANPATH /mnt/sysimage/usr/share/man:/mnt/sysimage/usr/local/share/man 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-11.1.2.96-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. Was it: 1) Being able to access man pages in rescue mode before chroot to /mnt/sysimage or 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-11.1.2.88-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 chroot environments.
RHEL5.2-Client-20080211.0 / anaconda-11.1.2.100-1: sh-3.00# echo $MANPATH /mnt/sysimage/usr/share/man:/mnt/sysimage/usr/local/share/man:/usr/share/man:/usr/local/share/man 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. http://rhn.redhat.com/errata/RHBA-2008-0397.html