Gentoo Archives: gentoo-amd64

From: Dale <rdalek1967@×××××.com>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Re: About to install on a 64 bit system. Advice wanted.
Date: Thu, 09 Dec 2010 07:06:50
In Reply to: [gentoo-amd64] Re: About to install on a 64 bit system. Advice wanted. by Duncan <>
1 Duncan wrote:
2 > Dale posted on Wed, 08 Dec 2010 18:26:00 -0600 as excerpted:
3 >
4 >
5 >> Frank Peters wrote:
6 >>
7 >>> On Wed, 08 Dec 2010 15:17:18 -0600
8 >>> Dale<rdalek1967@×××××.com> wrote:
9 >>>
10 >>>
11 >>>> What are some things that I should watch for and enable that isn't so
12 >>>> obvious for someone new to 64 bit?
13 >>>>
14 >>>>
15 >>> The first thing to decide is whether or not you want a pure 64-bit
16 >>> system or a 64-bit system that keeps 32-bit capability.
17 >>>
18 >>> I am a purist. I left 32-bit programs in the dust a long time ago. But
19 >>> as a consequence there are some things that I will miss because they
20 >>> are available in 32-bit packages only.
21 >>>
22 >
23 >> Now I have a question. How do I tell Gentoo to make it pure 64 or a mix
24 >> of 32 and 64? I have read about this but I don't think I have actually
25 >> seen where it is set. Is it a profile selection, USE flag or something
26 >> else?
27 >>
28 >> If I decide on one then want to switch to the other, does that require a
29 >> reinstall or just a change in settings and a recompile of world?
30 >>
31 >> Since I use KDE, I always use Okular to view pdf files. I assume KDE is
32 >> 64 bit ready.
33 >>
34 > Welcome to 64-bit, Dale! (We both post follow a couple kde lists as well
35 > as certain other gentoo lists, and kde is definitely 64-bit ready, as I
36 > too run a 64-bit-only profile. =:^)
37 >
38 > Frank had my thought, but of course my posts tend to beat details to
39 > death, so here goes...
40 >
41 > First thing, know that an amd64 (aka x86_64, including Intel and Via 64-
42 > bit x86, NOT just AMD) system can run either 32-bit or 64-bit in hardware,
43 > natively. Which you decide to do for your system is your decision -- on
44 > Gentoo, you can build and run from x86 (32-bit) profiles or amd64 (64-bit)
45 > profiles. If you run 64-bit/amd64, you have a second choice, multilib,
46 > which makes running 32-bit programs on a normally 64-bit profile easy, or
47 > no-multilib, profiles that are 64-bit only. Both Frank and I have chosen
48 > the no-multilib profile.
49 >
50 > However, note that it's still possible to do a 32-bit x86 profile chroot
51 > build on an otherwise amd64 no-multilib profile machine, it's just more
52 > work, as now you're effectively building much of the system twice, once
53 > for amd64 no-multilib and once for the x86 chroot. However, despite the
54 > extra work, in some ways this is closer to what some might call the pure
55 > "Gentoo way", because it remains the only way to build /everything/ from
56 > source, both 32-bit and 64-bit. (Multilib uses pre-built 32-bit binaries,
57 > emul-linux-86x-* packages for many libraries and *-bin, example firefox-
58 > bin, for selected 32-bit binaries, while building only 64-bit for most
59 > stuff. However, multilib does build 32-bit and 64-bit for a few critical
60 > toolchain packages like the glibc system library, gcc, portage's sandbox,
61 > etc.) There's a couple reasons you might want to do this, as covered
62 > below.
63 >
64 > Which you may /want/ to run is an interesting question. Certainly, 32-bit
65 > is most compatible with as Frank says, generally legacy and mostly closed
66 > source software. On archs other than x86 (ppc, mips, etc), there's often
67 > a definite advantage to staying 32-bit, except for perhaps the kernel
68 > itself and maybe one or two really huge memory sucking things like
69 > databases and their dependencies, because 32-bit code is smaller (memory
70 > addresses double their size to 64-bit on 64-bit) and there's little
71 > instruction-set difference between the bitness variants of the arch, so 32-
72 > bit userspace conserves memory and is simpler. Still, once one gets to 4
73 > gig of RAM, a 64-bit kernel is preferred (even tho, on Linux x86 at least,
74 > a 32-bit kernel can make use of upto 64 gig of RAM, at significant loss of
75 > efficiency), and similarly, once apps (like big databases) start using
76 > gigs of memory for a single app, it's time to go 64-bit. Thus, it's
77 > common on other archs (and an option, tho not fully supported, on gentoo/
78 > amd64) to have a 64-bit kernel, 32-bit userspace, profile, as well as full
79 > 32-bit and full 64-bit kernel and userspace.
80 >
81 > However, on x86, the 32-bit instruction-set has a number of weaknesses,
82 > chief among them being an extremely limited set of available CPU
83 > registers, that the 64-bit instruction set corrects -- there are many more
84 > available registers in 64-bit mode. For this reason, on x86, the ordinary
85 > negatives of going full 64-bit are reasonably balanced out by the
86 > positives of the less limited instruction set, with the result being that
87 > the 64-bit kernel-space, 32-bit userland model is *FAR* less common. As I
88 > said, there's an option (profile) available for it on Gentoo, but it's not
89 > considered supported. Most folks go either full 64-bit (tho with multilib,
90 > which is supported and in fact the Gentoo default) or stay with 32-bit
91 > only.
92 >
93 > So your first choice is whether you want to stick with a standard 32-bit-
94 > only x86 install on your new 64-bit-capable system, or whether you're
95 > ready to go 64-bit. Presumably, you'll go 64-bit kernel /and/ userland,
96 > and that's what the rest of this post assumes.
97 >
98 > With that decision out of the way, one now has to decide between a multilib
99 > and a no-multilib profile. A multilib profile is the default, but both
100 > Frank and I have chosen no-multilib as we prefer full 64-bit systems
101 > without the complications of the 32-bit multilib, and we don't have apps
102 > that require 32-bit compatibility be maintained. (I won't speak for
103 > Frank, but I'm sure from seeing my posts in the kde lists and elsewhere
104 > that you know I cannot and will-not install servantware, in the context of
105 > my sig. Since binary-only servantware is what most of the remaining 32-
106 > bit only Linux software is, and I cannot and will not install it, that
107 > leaves me far freer to consider a no-multilib profile, as I'm not bound to
108 > some old 32-bit-binary-only software like some servant bound to his
109 > master. My choices are mine and I'm /not/ telling you what to do --
110 > that's your decision, but at the same time, my feelings are quite strong
111 > on the subject and you're reading my post -- they come with the territory.)
112 >
113 > As I said, multilib is the Gentoo default, in part because the same
114 > multilib-based stages can be used to build both multilib and no-multilib
115 > systems, depending on the profile chosen. As long as the system is
116 > multilib, you have the choice of switching profiles, rebuilding, and going
117 > nomultilib, but once you've switched to nomultilib and rebuild the
118 > toolchain (gcc, glibc, etc), it loses the capacity to build the 32-bit
119 > side, and the only (easy, well, "easy" in relative terms) way back to
120 > multilib is to start with a new multilib stage tarball and rebuild. So in
121 > that regard, going no-multilib is a one-way decision. You can make it at
122 > any time as long as you are still multilib, but once no-multilib, you
123 > can't so easily go back.
124 >
125 > That said, there /are/ certain complexities and negatives to multilib.
126 > One is simply the time involved to build already long-build toolchain
127 > packages, glibc and gcc especially, since effectively you're building them
128 > twice, once for 32-bit and once for 64-bit. Another is the previously
129 > mentioned not-quite-the-normal-gentoo-way of multilib, with all the pre-
130 > built binaries of emul-linux-x86-* (for libs) and *-bin (for
131 > executables). Those builds by definition have way more generic CFLAGS,
132 > USE flags, etc, than what one may well have if they built them from source.
133 >
134 > Third, due to its complexity, multilib is somewhat brittle, and because
135 > most stuff builds as 64-bit only, it's possible for the 32-bit toolchain
136 > side to break and remain broken for some time before its detected, then
137 > you suddenly find yourself without an easy way to upgrade your toolchain
138 > (glibc, gcc, sandbox, binutils, for the most part), since multilib will
139 > try to build both, and the 32-bit side is broken. Not to scare you as
140 > multilib *IS* supported and there are (semi-complex, sometimes involving
141 > extracting files or whole packages from a stage tarball --
142 > FEATURES=buildpkg can help avoid that, BTW) ways out of this bind, that
143 > people can help you with if you find yourself in this situation, and
144 > certainly, the on-the-edge ~amd64 and sometimes still hard-masked-for-
145 > testing stuff that I tend to run made me more susceptible to this than
146 > many, but it was after about the third time of having this happen to me,
147 > that I decided, since I didn't need 32-bit compatibility anyway, I might
148 > as well do away with the headache and go full no-multilib. That was
149 > definitely one of my better decisions; one I've certainly not regretted.
150 > Since then I've appreciated both the lower-complexity/better-robustness
151 > and the faster build-times of no-multilib, and as I said, since I don't
152 > run the servantware that tends to be about the only software left that's
153 > 32-bit only, there wasn't any compatibility issues at all to worry about,
154 > here.
155 >
156 > Meanwhile, what about that 32-bit chroot option I mentioned? Actually,
157 > there's a whole properly documented Gentoo guide for that, and it's sort
158 > of special case, so I'll skip the details on it, but I'll describe enough
159 > about it so you have some idea why you might want to run one and how it
160 > works.
161 >
162 > As it happens, I do actually run one here, tho not for the normal reason,
163 > better 32-bit compatibility. Rather, I have a 32-bit-only Atom based
164 > netbook that I run Gentoo on as well. But my 64-bit system is
165 > sufficiently beefier than the Atom, that I saw no reason to have that puny
166 > single-core Atom with only a gig and a half of memory and a single drive
167 > toiling away for days to build its system or update, say KDE, when I could
168 > do the same thing in hours, on a 32-bit chroot build-image on my main
169 > machine. So that's what I use the 32-bit chroot for, as the build-image
170 > for my Atom based netbook. I have a custom scripted SSH and rsync setup
171 > to keep the necessary parts of the two systems synced (the netbook doesn't
172 > even have a portage tree on it, I mount it into the chroot on my main
173 > machine, tho I do keep the package database on both the build image and
174 > the netbook, for backup purposes), and the 32-bit chroot build image on
175 > the main machine is the way I handled building and now handle updates on
176 > my Gentoo based netbook. =:^)
177 >
178 > But whether you use it for something like that, or need better or more
179 > proper "gentoo-like" 32-bit support than multilib gives you, the basic
180 > idea is that you setup a chroot, unpack a normal 32-bit x86 tarball onto
181 > it, selectively mount parts of your main 64-bit system into the chroot,
182 > and then build /most/ of a 32-bit system as you normally would. If you're
183 > using it as a build-image for another system, as I do, you build stuff
184 > like syslog, cron, an appropriate 32-bit kernel, etc, too. But if you're
185 > only using it for better 32-bit support than multilib gives you on your
186 > main 64-bit system, you can skip stuff like that, since the 32-bit chroot
187 > still uses the system kernel and services from its 64-bit host.
188 >
189 > If you /do/ decide to run a 32-bit chroot, it takes care of the 32-bit
190 > compatibility stuff better than multilib does, so running no-multilib on
191 > the main system makes sense. One /possible/ exception to that might be
192 > the servantware graphics drivers, since on a multilib system they'll build
193 > both 32-bit and 64-bit interfaces and must be built against the system
194 > kernel. Gamers in particular may be concerned about that. However, I'm
195 > unsure of that, since as already mentioned, servantware including
196 > servantware graphics drivers isn't a viable option for me, so others are
197 > certainly better qualified to answer questions in that area if it's a
198 > concern.
199 >
200 > Finally, to answer your multilib question directly, it's a profile
201 > setting. Once you are setting up your 64-bit system, have the stage
202 > tarball installed, and get to the point of selecting your profile, eselect
203 > profile list should do just that, list available profile choices,
204 > including no-multilib. For reference, here's what I get listed here, with
205 > the no-multilib option starred, indicating it's active. (Note that as
206 > I've been no-multilib for some time and no longer have a multilib
207 > toolchain, most of these aren't viable options for me after all, but this
208 > is the list a fresh installing user might be able to choose.)
209 >
210 > $ eselect profile list
211 > Available profile symlink targets:
212 > [1] default/linux/amd64/10.0
213 > [2] default/linux/amd64/10.0/desktop
214 > [3] default/linux/amd64/10.0/desktop/gnome
215 > [4] default/linux/amd64/10.0/desktop/kde
216 > [5] default/linux/amd64/10.0/developer
217 > [6] default/linux/amd64/10.0/no-multilib *
218 > [7] default/linux/amd64/10.0/server
219 > [8] hardened/linux/amd64
220 > [9] hardened/linux/amd64/no-multilib
221 > [10] selinux/2007.0/amd64
222 > [11] selinux/2007.0/amd64/hardened
223 > [12] selinux/v2refpolicy/amd64
224 > [13] selinux/v2refpolicy/amd64/desktop
225 > [14] selinux/v2refpolicy/amd64/developer
226 > [15] selinux/v2refpolicy/amd64/hardened
227 > [16] selinux/v2refpolicy/amd64/server
228 > $
229 >
230 >
232 I read the whole post and it explained a lot. I think you read my mind
233 and posted the list of profiles available too. I asked for that in
234 another reply and when I hit send, I saw your replies. There was the
235 list of profiles. You got ESP or do us Gentooers think alike? lol
237 I'm liking the option you are using. It seems clean and simple. Is #4
238 no-multilib or multilib? I suspect it is multi. I ask because as you
239 already know I use KDE and I also use the kde profile in x86. The stuff
240 8 and below are way over my head. I'm not even thinking of going into
241 that area. ;-)
243 I do have nvidia video cards. I assume the nvidia-drivers package will
244 work fine with no-multilib? The way I am reading things it will but I
245 do want drivers that work.
247 Thanks.
249 Dale
251 :-) :-)


Subject Author
[gentoo-amd64] Re: About to install on a 64 bit system. Advice wanted. Duncan <1i5t5.duncan@×××.net>
Re: [gentoo-amd64] Re: About to install on a 64 bit system. Advice wanted. Frank Peters <frank.peters@×××××××.net>