The handbook instuctions command: tar xvjpf stage3-*.tar.bz2 Extracts the files using the owner/group "names" for each file. Those names may not exist in a non-gentoo livecd, as some group names are gentoo specific or may have different IDs compared to the livecd used. The result is that some of the extracted files/directories have wrong owners/groups, resulting in a from the beginning partially broken installation. The correct instructions would be: tar --numeric-owner -xvjpf stage3-*.tar.bz2 The "--numeric-owner" argument makes sure that only the id numbers are extracted, which are agnostic of the currect system, and are later (after chroot) fully recognized by the real gentoo system, because then it is the time that the /etc/passwd is really correct. The --numeric-owner documentation can be found in the tar manual: http://www.gnu.org/software/tar/manual/tar.html Reproducible: Always Steps to Reproduce: 1. Start installation from non-gentoo livecd (in this example ubuntu 10.04) 2. Download and extract the stage3 .tar using the handbook instructions 3. chroot according to handbook 4. "ls -l" inside some /var/*/ folders Actual Results: drwxrwxr-x 3 root wheel 4096 Jun 10 01:38 lock drwxrwxr-x 27 root mail 4096 Jun 10 10:23 man Expected Results: drwxrwxr-x 3 root uucp 4096 Jun 14 19:09 lock drwxrwxr-x 27 root man 4096 Jun 10 13:23 man Few files/folders are affected, but they ARE affected, and results may differ depending on the livecd used. Some device files in /dev/ are also affected, but I don't know if that matters because udev overmounts them anyway in a real system. Whatever the livecd used though, inserting "--numeric-owner" in the tar command completely solves all possible problems. The situation gets really worse when people use the handbook instructions "reversed" to create custom stage4 backups as there, the groups are many more and many more things can break, and the extraction may be broken even from gentoo isos as not all groups exist there (compared to stage4's). The way I discovered this, is a popular bug (that I have seen many reports) the broken /usr/libexec/dbus-daemon-launch-helper that is always messed after any extraction without --numeric-owner. That file has both messagebus group, and setuid, which tar always messes up in all stage4 restores. People reporting automounting/rebooting/blueman not working in gnome probably made a stage4 restore the handbook way. I am marking this as Critical because the results are unpredictable from the beginning (installation), and because the --numeric-owner thing only solves problems and never creates any (in my experience).
More specific note, this problem arises when the user/group owning the extracted file exists in the environment performing the extract but under a different uid/gid number. From the above example, I can deduce Parent environment: group uucp: 10 group mail: 12 Gentoo environment (chroot): group wheel: 10 group man: 12 So when the extract is performed, it sees the file should be owned by 'uucp' and creates it with gid 10. Then when the chroot it performed, it sees gid 10 is wheel. If the group doesnt exist at all, the problem does not occur as tar will then fall back to the uid/gid number in the tarball. Since the handbook specifically says "You can install Gentoo in many different ways. You can download and install from one of our Installation CDs, from a distribution already installed, from a bootable CD (such as Knoppix)", this should be taken into account and advised as the proper way of extracting a stage tarball in the handbook.
Obligatory disclaimer: We don't support booting from anything other than Gentoo installation media simply because we can't possibly begin to test or document all the LiveCDs out there. You're welcome to experiment with using other distributions' media to install Gentoo, but you should know that you're on your own if something goes wrong. We can't fix those CDs or document their individual quirks, nor should we attempt to do so. Please use a Gentoo CD if you want a fully supported installation method. --- That being said, I did add your tip to the altinstall guide, and I also placed notes on reading said guide right at the top of the handbook. This way users that have non-Gentoo install media know right up front that the installation process differs, and they must read the altinstall guide. The command just doesn't fit with the rest of the handbook, as the explanation for *why* it's needed is extraneous to the supported install, and it implies that there are owner ID issues with the Gentoo CDs, which is not the case. So yes, the flag is in our documentation now, just in a better spot than the handbook. I also rewrote the altinstall guide to be more neutral, to not favor Knoppix so much. I even included a link to a resource site for finding alternative LiveCDs, depending on the user's needs.
Perhaps a note should be added next to that little section that says 'gentoo can be installed from other distributions' (the section I quoted at the end of my previous post). I know it mentions it a few paragraphs down, but stating that gentoo can be installed from other distros without any warnings implies that it is supported.
*** Bug 387449 has been marked as a duplicate of this bug. ***
