Re: [gentoo-amd64] Re: About to install on a 64 bit system. Advice wanted.

[Dale]

Duncan wrote:
> Dale posted on Wed, 08 Dec 2010 18:26:00 -0600 as excerpted:
>
>
>> Frank Peters wrote:
>>
>>> On Wed, 08 Dec 2010 15:17:18 -0600
>>> Dale<rdalek1967@×××××.com>   wrote:
>>>
>>>
>>>> What are some things that I should watch for and enable that isn't so
>>>> obvious for someone new to 64 bit?
>>>>
>>>>
>>> The first thing to decide is whether or not you want a pure 64-bit
>>> system or a 64-bit system that keeps 32-bit capability.
>>>
>>> I am a purist.  I left 32-bit programs in the dust a long time ago. But
>>> as a consequence there are some things that I will miss because they
>>> are available in 32-bit packages only.
>>>
>
>> Now I have a question.  How do I tell Gentoo to make it pure 64 or a mix
>> of 32 and 64?  I have read about this but I don't think I have actually
>> seen where it is set.  Is it a profile selection, USE flag or something
>> else?
>>
>> If I decide on one then want to switch to the other, does that require a
>> reinstall or just a change in settings and a recompile of world?
>>
>> Since I use KDE, I always use Okular to view pdf files.  I assume KDE is
>> 64 bit ready.
>>
> Welcome to 64-bit, Dale! (We both post follow a couple kde lists as well
> as certain other gentoo lists, and kde is definitely 64-bit ready, as I
> too run a 64-bit-only profile. =:^)
>
> Frank had my thought, but of course my posts tend to beat details to
> death, so here goes...
>
> First thing, know that an amd64 (aka x86_64, including Intel and Via 64-
> bit x86, NOT just AMD) system can run either 32-bit or 64-bit in hardware,
> natively.  Which you decide to do for your system is your decision -- on
> Gentoo, you can build and run from x86 (32-bit) profiles or amd64 (64-bit)
> profiles.  If you run 64-bit/amd64, you have a second choice, multilib,
> which makes running 32-bit programs on a normally 64-bit profile easy, or
> no-multilib, profiles that are 64-bit only.  Both Frank and I have chosen
> the no-multilib profile.
>
> However, note that it's still possible to do a 32-bit x86 profile chroot
> build on an otherwise amd64 no-multilib profile machine, it's just more
> work, as now you're effectively building much of the system twice, once
> for amd64 no-multilib and once for the x86 chroot.  However, despite the
> extra work, in some ways this is closer to what some might call the pure
> "Gentoo way", because it remains the only way to build /everything/ from
> source, both 32-bit and 64-bit.  (Multilib uses pre-built 32-bit binaries,
> emul-linux-86x-* packages for many libraries and *-bin, example firefox-
> bin, for selected 32-bit binaries, while building only 64-bit for most
> stuff.  However, multilib does build 32-bit and 64-bit for a few critical
> toolchain packages like the glibc system library, gcc, portage's sandbox,
> etc.)  There's a couple reasons you might want to do this, as covered
> below.
>
> Which you may /want/ to run is an interesting question.  Certainly, 32-bit
> is most compatible with as Frank says, generally legacy and mostly closed
> source software.  On archs other than x86 (ppc, mips, etc), there's often
> a definite advantage to staying 32-bit, except for perhaps the kernel
> itself and maybe one or two really huge memory sucking things like
> databases and their dependencies, because 32-bit code is smaller (memory
> addresses double their size to 64-bit on 64-bit) and there's little
> instruction-set difference between the bitness variants of the arch, so 32-
> bit userspace conserves memory and is simpler. Still, once one gets to 4
> gig of RAM, a 64-bit kernel is preferred (even tho, on Linux x86 at least,
> a 32-bit kernel can make use of upto 64 gig of RAM, at significant loss of
> efficiency), and similarly, once apps (like big databases) start using
> gigs of memory for a single app, it's time to go 64-bit.  Thus, it's
> common on other archs (and an option, tho not fully supported, on gentoo/
> amd64) to have a 64-bit kernel, 32-bit userspace, profile, as well as full
> 32-bit and full 64-bit kernel and userspace.
>
> However, on x86, the 32-bit instruction-set has a number of weaknesses,
> chief among them being an extremely limited set of available CPU
> registers, that the 64-bit instruction set corrects -- there are many more
> available registers in 64-bit mode.  For this reason, on x86, the ordinary
> negatives of going full 64-bit are reasonably balanced out by the
> positives of the less limited instruction set, with the result being that
> the 64-bit kernel-space, 32-bit userland model is *FAR* less common.  As I
> said, there's an option (profile) available for it on Gentoo, but it's not
> considered supported.  Most folks go either full 64-bit (tho with multilib,
> which is supported and in fact the Gentoo default) or stay with 32-bit
> only.
>
> So your first choice is whether you want to stick with a standard 32-bit-
> only x86 install on your new 64-bit-capable system, or whether you're
> ready to go 64-bit.  Presumably, you'll go 64-bit kernel /and/ userland,
> and that's what the rest of this post assumes.
>
> With that decision out of the way, one now has to decide between a multilib
> and a no-multilib profile.  A multilib profile is the default, but both
> Frank and I have chosen no-multilib as we prefer full 64-bit systems
> without the complications of the 32-bit multilib, and we don't have apps
> that require 32-bit compatibility be maintained.  (I won't speak for
> Frank, but I'm sure from seeing my posts in the kde lists and elsewhere
> that you know I cannot and will-not install servantware, in the context of
> my sig.  Since binary-only servantware is what most of the remaining 32-
> bit only Linux software is, and I cannot and will not install it, that
> leaves me far freer to consider a no-multilib profile, as I'm not bound to
> some old 32-bit-binary-only software like some servant bound to his
> master.  My choices are mine and I'm /not/ telling you what to do --
> that's your decision, but at the same time, my feelings are quite strong
> on the subject and you're reading my post -- they come with the territory.)
>
> As I said, multilib is the Gentoo default, in part because the same
> multilib-based stages can be used to build both multilib and no-multilib
> systems, depending on the profile chosen.  As long as the system is
> multilib, you have the choice of switching profiles, rebuilding, and going
> nomultilib, but once you've switched to nomultilib and rebuild the
> toolchain (gcc, glibc, etc), it loses the capacity to build the 32-bit
> side, and the only (easy, well, "easy" in relative terms) way back to
> multilib is to start with a new multilib stage tarball and rebuild.  So in
> that regard, going no-multilib is a one-way decision.  You can make it at
> any time as long as you are still multilib, but once no-multilib, you
> can't so easily go back.
>
> That said, there /are/ certain complexities and negatives to multilib.
> One is simply the time involved to build already long-build toolchain
> packages, glibc and gcc especially, since effectively you're building them
> twice, once for 32-bit and once for 64-bit.  Another is the previously
> mentioned not-quite-the-normal-gentoo-way of multilib, with all the pre-
> built binaries of emul-linux-x86-* (for libs) and *-bin (for
> executables).  Those builds by definition have way more generic CFLAGS,
> USE flags, etc, than what one may well have if they built them from source.
>
> Third, due to its complexity, multilib is somewhat brittle, and because
> most stuff builds as 64-bit only, it's possible for the 32-bit toolchain
> side to break and remain broken for some time before its detected, then
> you suddenly find yourself without an easy way to upgrade your toolchain
> (glibc, gcc, sandbox, binutils, for the most part), since multilib will
> try to build both, and the 32-bit side is broken.  Not to scare you as
> multilib *IS* supported and there are (semi-complex, sometimes involving
> extracting files or whole packages from a stage tarball --
> FEATURES=buildpkg can help avoid that, BTW) ways out of this bind, that
> people can help you with if you find yourself in this situation, and
> certainly, the on-the-edge ~amd64 and sometimes still hard-masked-for-
> testing stuff that I tend to run made me more susceptible to this than
> many, but it was after about the third time of having this happen to me,
> that I decided, since I didn't need 32-bit compatibility anyway, I might
> as well do away with the headache and go full no-multilib.  That was
> definitely one of my better decisions; one I've certainly not regretted.
> Since then I've appreciated both the lower-complexity/better-robustness
> and the faster build-times of no-multilib, and as I said, since I don't
> run the servantware that tends to be about the only software left that's
> 32-bit only, there wasn't any compatibility issues at all to worry about,
> here.
>
> Meanwhile, what about that 32-bit chroot option I mentioned?  Actually,
> there's a whole properly documented Gentoo guide for that, and it's sort
> of special case, so I'll skip the details on it, but I'll describe enough
> about it so you have some idea why you might want to run one and how it
> works.
>
> As it happens, I do actually run one here, tho not for the normal reason,
> better 32-bit compatibility.  Rather, I have a 32-bit-only Atom based
> netbook that I run Gentoo on as well.  But my 64-bit system is
> sufficiently beefier than the Atom, that I saw no reason to have that puny
> single-core Atom with only a gig and a half of memory and a single drive
> toiling away for days to build its system or update, say KDE, when I could
> do the same thing in hours, on a 32-bit chroot build-image on my main
> machine.  So that's what I use the 32-bit chroot for, as the build-image
> for my Atom based netbook.  I have a custom scripted SSH and rsync setup
> to keep the necessary parts of the two systems synced (the netbook doesn't
> even have a portage tree on it, I mount it into the chroot on my main
> machine, tho I do keep the package database on both the build image and
> the netbook, for backup purposes), and the 32-bit chroot build image on
> the main machine is the way I handled building and now handle updates on
> my Gentoo based netbook. =:^)
>
> But whether you use it for something like that, or need better or more
> proper "gentoo-like" 32-bit support than multilib gives you, the basic
> idea is that you setup a chroot, unpack a normal 32-bit x86 tarball onto
> it, selectively mount parts of your main 64-bit system into the chroot,
> and then build /most/ of a 32-bit system as you normally would.  If you're
> using it as a build-image for another system, as I do, you build stuff
> like syslog, cron, an appropriate 32-bit kernel, etc, too.  But if you're
> only using it for better 32-bit support than multilib gives you on your
> main 64-bit system, you can skip stuff like that, since the 32-bit chroot
> still uses the system kernel and services from its 64-bit host.
>
> If you /do/ decide to run a 32-bit chroot, it takes care of the 32-bit
> compatibility stuff better than multilib does, so running no-multilib on
> the main system makes sense.  One /possible/ exception to that might be
> the servantware graphics drivers, since on a multilib system they'll build
> both 32-bit and 64-bit interfaces and must be built against the system
> kernel.  Gamers in particular may be concerned about that.  However, I'm
> unsure of that, since as already mentioned, servantware including
> servantware graphics drivers isn't a viable option for me, so others are
> certainly better qualified to answer questions in that area if it's a
> concern.
>
> Finally, to answer your multilib question directly, it's a profile
> setting.  Once you are setting up your 64-bit system, have the stage
> tarball installed, and get to the point of selecting your profile, eselect
> profile list should do just that, list available profile choices,
> including no-multilib.  For reference, here's what I get listed here, with
> the no-multilib option starred, indicating it's active.  (Note that as
> I've been no-multilib for some time and no longer have a multilib
> toolchain, most of these aren't viable options for me after all, but this
> is the list a fresh installing user might be able to choose.)
>
> $ eselect profile list
> Available profile symlink targets:
>    [1]   default/linux/amd64/10.0
>    [2]   default/linux/amd64/10.0/desktop
>    [3]   default/linux/amd64/10.0/desktop/gnome
>    [4]   default/linux/amd64/10.0/desktop/kde
>    [5]   default/linux/amd64/10.0/developer
>    [6]   default/linux/amd64/10.0/no-multilib *
>    [7]   default/linux/amd64/10.0/server
>    [8]   hardened/linux/amd64
>    [9]   hardened/linux/amd64/no-multilib
>    [10]  selinux/2007.0/amd64
>    [11]  selinux/2007.0/amd64/hardened
>    [12]  selinux/v2refpolicy/amd64
>    [13]  selinux/v2refpolicy/amd64/desktop
>    [14]  selinux/v2refpolicy/amd64/developer
>    [15]  selinux/v2refpolicy/amd64/hardened
>    [16]  selinux/v2refpolicy/amd64/server
> $
>
>

I read the whole post and it explained a lot.  I think you read my mind 
and posted the list of profiles available too.  I asked for that in 
another reply and when I hit send, I saw your replies.  There was the 
list of profiles.  You got ESP or do us Gentooers think alike?  lol

I'm liking the option you are using.  It seems clean and simple.  Is #4 
no-multilib or multilib?  I suspect it is multi.  I ask because as you 
already know I use KDE and I also use the kde profile in x86.  The stuff 
8 and below are way over my head.  I'm not even thinking of going into 
that area.  ;-)

I do have nvidia video cards.  I assume the nvidia-drivers package will 
work fine with no-multilib?  The way I am reading things it will but I 
do want drivers that work.

Thanks.

Dale

:-)  :-)