Hello, Many users using SystemRescueCD encounter issues because some host variables are not unset. In the LinuxFromScratch handbook, the chroot instruction is more elaborated, in order to not disturb the chrooted environment. http://www.linuxfromscratch.org/lfs/view/stable/chapter06/chroot.html I would suggest to change chroot /mnt/gentoo /bin/bash to chroot /mnt/gentoo /bin/env -i TERM=$TERM /bin/bash As I came from LFS, I always use that "mantra" without any problems since years. I sent an email to Sven Vermeulen, and he said : "I can remember that we used to use that setting but we rolled the change back, but I can't remember why. It wouldn't hurt to ask in a bugreport (https://bugs.gentoo.org) to update the documentation anyhow, I wouldn't mind the change. However, I can't change it myself, I'm no developer anymore so any change needs to pass through the gentoo bugzilla." So, maybe there are some good reason to not call /bin/env. But I try to propose ;-) Kind regards, Xavier Miller Reproducible: Always Steps to Reproduce: 1. boot SystemRescueCD 2. chroot /mnt/gentoo /bin/bash 3. cryptic emerge errors Expected Results: 1. boot any LiveCD 2. chroot /mnt/gentoo /bin/env -i TERM=$TERM /bin/bash 3. no cryptic emerge error
1. We do not support using SystemRescueCD or any other unofficial LiveCD. We only support our official installation CDs. 2. That env variable is useless for a real Gentoo LiveCD environment. It's not something that someone who's using Gentoo to install will have to worry about. As SystemRescueCD is not Gentoo, but a derivative distro, then any problems you encounter while using it need to be resolved with its authors and support community. Not a bug; closing.
OK, I repoen the bug for the "Alternative Gentoo Installation Guide": http://www.gentoo.org/doc/en/altinstall.xml THERE, you should need to adjust the chroot instuctions. Kind regards, Xavier.
Nope. Read the altinstall guide warning: "Important: The Gentoo developers cannot support you if something goes wrong with a non-Gentoo LiveCD, as there's no way to fix, troubleshoot, or document every quirk of every LiveCD out there. Only Gentoo LiveCDs are officially supported. If you run into problems with alternative installation media, please visit the Gentoo Forums for community help." I'm not changing this doc because of one particular broken LiveCD distribution. get SysRescueCD upstream to fix their LiveCD environment, then env hacks won't be necessary.
(In reply to comment #3) > I'm not changing this doc because of one particular broken LiveCD distribution. > get SysRescueCD upstream to fix their LiveCD environment, then env hacks won't > be necessary. This is not the first time we got a request for such a change. I don't see any problem with making the chroot instructions more robust, and I will therefore handle this bug.
In CVS, thanks. I've removed the `su -` bit, which, AFAIK, should not be needed because only root can chroot() anyway.
Hello, This was the reason I opened the bug : each week, there come some "chrooted in SysRescCD" threads in the forum, and this was SO easy to work around. Thank you very much to listen to users! (In reply to comment #4) > (In reply to comment #3) > > I'm not changing this doc because of one particular broken LiveCD distribution. > > get SysRescueCD upstream to fix their LiveCD environment, then env hacks won't > > be necessary. > > This is not the first time we got a request for such a change. I don't see any > problem with making the chroot instructions more robust, and I will therefore > handle this bug. >
Hello, There is a typo in the command : # chroot / /bin/env -i TERM=TERM /bin/bash In place of # chroot /mnt/gentoo /bin/env -i TERM=TERM /bin/bash Please fix it accordingly. Kind regards, Xavier Miller.
OOPs, 2 typos : # chroot / /bin/env -i TERM=TERM /bin/bash becomes # chroot /mnt/gentoo /bin/env -i TERM=$TERM /bin/bash (mount point and TERM variable)
Thanks, apparently I suck at fixing stuff after midnight. Please allow the webnodes an hour or so to pick up the change.
