It looks like I don't use any 32 bit app so I made the switch to the no-multilib profile. Only 1 question remains (atm actually :P) : Can I just remove the /lib32 and the /usr/lib32 dirs?
On Fri, Nov 21, 2008 at 1:39 PM, Duncan <[EMAIL PROTECTED]> wrote: > Tonko <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted > below, on Fri, 21 Nov 2008 11:23:19 +0100: > >> Let's just say that I would switch to the no-multilib profile. Would it >> be enough to just change the profile and do a emerge @system @world >> -auvDN ? Or are there more steps I need to take? > > That's enough in general, yes. The big things to remember to remerge are > glibc, gcc, binutils, and sandbox (and IDR, possibly baselayout as well), > but of course an emerge @system should take care of all of those. If > you've sat thru or timed gcc and/or glibc emerges before, you should > immediately notice they take MUCH less time to merge now, particularly > glibc, because as I explained earlier, with multilib they're effectively > built twice, once for 32-bit and once for 64-bit. > > The other thing to look at with any profile change is what default USE > flags may have changed, and whether you're comfortable with the changes > or not. Of course, switching to a no-multilib profile, some USE flags > are masked either in general or on specific packages, due to requiring > 32-bit, so there'll likely be more change than a simple profile upgrade > would bring. If you like, you can try switching profiles without merging > anything, do emerge -pv @system @world, and take a look at the changes. > If you don't like what you see, it's easy enough to switch back before > you do any real emerges, since all you've done at that point is change > the config and take a look at what it would do. > > When you're done remerging and everything, it'd probably be wise to check > and make sure the old lib32 dirs (I've forgotten what the were > specifically) and etc are all gone, but I /think/ the remerge of > baselayout on the new profile will handle that, unless of course you have > those dirs CONFIG_PROTECTed for some reason. > > One other thing that again the profile should manage, but just in case it > doesn't... For legacy reasons, booting amd64 starts in IIRC 16-bit real- > mode, just as does booting x86(32). That's handled with the traditional > 32-bit gcc. Thus, grub is masked on no-multilib. Instead, you'll use > grub-static. Of course, what's actually installed in the boot sector > doesn't change until you install grub to the boot sector yourself. > > Just to make sure nothing unexpected happens in the process leaving you > unable to boot, be sure you have some other way to boot, a Gentoo LiveCD, > grub installed on a floppy or USB device, etc, and test booting from it. > To be real sure, disable the hard drive in your BIOS, and boot from the > alternative without it. If it's grub, you should be able to get to the > grub menu without the hard drive, tho of course you won't be able to find > the kernel and boot the hard drive with it disabled. If it's a LiveCD or > whatever, obviously you should be able to boot it, with or without the > hard drive. Once you know your alternative boot works, you can reenable > your hard drive in BIOS. > > Then if you like, I think you can merge grub-static (unmerging grub in > the process) BEFORE you switch profiles. This will be safest since > you'll be doing only grub-static by itself, not everything at once. It > will of course install on the system, and try to install to /boot as > well, with an elog message saying whether it could or not. But you will > need to install it to the boot sector yourself. After you've done so, > reboot, making sure it all works, using your pre-tested alternative boot > if something goes wrong, but it shouldn't. Once you've installed it, you > can go ahead with the profile change and not have to worry about at least > that bit of it, since you'll have done it already. > > Of course if you run LILO, it too has 32-bit components. However it > works rather differently. I used to use it on Gentoo back before Gentoo > supported it on amd64, by just using the LILO precompiled binary > available from its homepage. But I eventually switched to GRUB and > haven't kept up with LILO, so don't know the details of how Gentoo > manages it now. But LILO users should be pretty used to managing it > themselves already since Gentoo doesn't provide much help with it, and > because it uses an absolute pointer directly from the boot sector to each > of its kernel entries and the kernel won't need changed for the move to > the no-multilib profile, it's something they don't have to worry about > right during the profile switch in any case. > > Meanwhile, back to the general case. There's an official Gentoo > Upgrading Guide with profile upgrading instructions, here: > > http://www.gentoo.org/doc/en/gentoo-upgrading.xml > > If you're not on a 2008.0 profile yet, you may wish to take the > opportunity to upgrade to that at the same time. Be sure your portage is > upto date, and check the specific instructions for the 2008.0 upgrade as > posted. > > They suggest using eselect profile, but I've always done my profile > changes by repointing the symlink manually, here. The one thing eselect > profile will do is make selecting a subprofile intended as a cascaded > subprofile only, not a main profile, much more difficult, since it only > lists valid whole profiles. However, the no-multilib profile stands on > its own, so there's little danger of that here, and as I said, I've > always managed the symlink here by hand (well, normally using mc, but > whatever). And they list the manual method as well, for those like me > that prefer it. =:^) > > -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > > -- Tonko
