From: Dale <rdalek1967@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Changing CPU and motherboard
Date: Sat, 28 Jun 2025 15:10:59 -0500 [thread overview]
Message-ID: <353a6372-1fb3-9ff0-d55f-0a86165388af@gmail.com> (raw)
In-Reply-To: <2fm677fpfb3vdfnyx22jp3lbeeq2wcs5trmtrvzqa3wks5k3x7@nzbvhf4nalxq>
whiteman808 wrote:
> On 28 Jun 2025, 14:32:57, Dale wrote:
>> Jay Faulkner wrote:
>>
>> On 6/28/2025 9:38 AM, whiteman808 wrote:
>>
>> Is it necessary to reinstall Gentoo if I change CPU or motherboard? If
>> not, what steps should be done on the existing Gentoo installation? Do I
>> need to do these operations from chroot?
>>
>> I'm assuming this is amd64->amd64.
>>
>> So the main thing to worry about is CPU compatibility, and your CFLAGS. If
>> you're using -march=native, there's a chance your system won't work as
>> compiled. This isn't always true, but these days it's no longer a guarantee
>> that a newer CPU will have all the features of the old.
>>
>>
>> What I usually do in this case is:
>>
>> - set -march=x86-64-v3 (or whatever lowest-common-denominator CPU arch
>> generic target works) -- https://wiki.gentoo.org/wiki/Safe_CFLAGS#
>> Generic_psABI_levels can help with this. - Ensure my system is fully
>> updated, and `emerge --depclean`'d. - emerge -e @world # this will rebuild
>> your entire system.
>>
>>
>> You can *significantly* reduce the pain of this by using the binary package
>> host.
>>
>>
>> -JayF
>>
>>
>>
>> Follow Jay's advice on the march setting in make.conf. You want a setting that
>> is compatible with both CPUs as Jay mentioned. Do a emerge -e world. Also,
>> --depclean as well.
>>
>> When you install the new CPU. You will need a kernel. Your current one may
>> work, may not. If it does, I'd stick to a console with no GUI running. Method
>> below may be faster since you only have to recompile once if you want to switch
>> the march setting back to native.
>>
>> A somewhat shorter method, after you install new CPU, boot another boot media,
>> Gentoo Live CD, Knoppix or whatever your system can boot with and you like.
>> Then mount your partitions as needed for the OS, chroot in, emerge -e world.
>> It should see the new CPU and change all the settings. Since the boot media is
>> handling the boot, it doesn't matter what your version of OS is as long as the
>> Arch is the same. Don't forget to build a new kernel as well. The command
>> lspci -k can be a really awesome friend. Also, you can leave the MARCH set to
>> native setting and this way you only compile once.
>>
>> If you can make it without the computer a bit, I'd boot from other media and
>> rebuild only once. Oh, don't forget to change the CPU flags if you have it
>> set. The command cpuid2cpuflags is good for that. If you don't have it,
>> package is the same name. You can unmerge it when done if you want.
>>
>> Just another idea. There are likely several ways to accomplish this. Biggest
>> thing is the kernel.
>>
>> Dale
>>
>> :-) :-)
> Does portage need to be able to execute some files already present on
> the system if I compile new software or recompile entire system using
> emerge -e? If yes, what if old CPU features and flags are entirely
> incompatible and not subset of the new CPU settings if I compile using
> livecd? How portage handles these cases?
>
>
I've never ran into that but given the changes software, especially
emerge, has made, it could possibly make a difference. What you could
do is set march to a common setting for both CPUs and then do a emerge
-e portage. That should rebuild everything emerge depends on and emerge
itself. What I would do, I'd try it first. I'd expect emerge to work
fine. I checked on my system, portage doesn't even have CPU flags or
anything that I could see. Of course, python would be the important
one. I checked the python here and it doesn't have CPU flags either.
Given that info, I'd say it is a 99% chance it would work fine. If you
live somewhere where electricity is pricey, I'd certainly try it first.
Just chroot in and do a emerge -ae world. I'd think if there was a
problem, it would say something. If it does fail, then revert. I'd
think booting from other media would eliminate most all issues tho.
Me tho, I'd install the CPU and try booting. I'd just stick to a
console, no GUI. Run emerge -ae world and go take a nap, go to work or
whatever. Make sure to include --resume tho. If something fails, it
will keep trying. If anything does fail, it will spit out a list. Try
them on their own. If you don't have --oneshot set, make sure to
oneshot those so your world file doesn't get full of unwanted entries.
Someone else may have more info on that question. I just think it will
work and at least worth a try. Save a lot of time for sure if it does
work.
Dale
:-) :-)
next prev parent reply other threads:[~2025-06-28 20:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-28 16:38 [gentoo-user] Changing CPU and motherboard whiteman808
2025-06-28 17:33 ` Jay Faulkner
2025-06-28 17:49 ` Michael
2025-06-28 19:10 ` whiteman808
2025-06-28 19:57 ` Jay Faulkner
2025-06-28 19:32 ` Dale
2025-06-28 19:44 ` whiteman808
2025-06-28 20:10 ` Dale [this message]
2025-06-28 20:15 ` Michael
2025-06-29 0:33 ` Dale
2025-06-28 23:04 ` whiteman808
2025-06-29 0:39 ` Dale
2025-06-29 2:23 ` Frank Steinmetzger
2025-06-29 1:17 ` Jay Faulkner
2025-06-29 17:51 ` [gentoo-user] " Grant Edwards
2025-06-29 2:19 ` [gentoo-user] " Frank Steinmetzger
2025-06-29 7:44 ` Michael
2025-06-29 17:55 ` [gentoo-user] " Grant Edwards
2025-06-29 17:54 ` Grant Edwards
2025-07-01 16:22 ` [gentoo-user] " Steven Lembark
2025-07-01 22:58 ` Jay Faulkner
2025-06-29 17:48 ` [gentoo-user] " Grant Edwards
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=353a6372-1fb3-9ff0-d55f-0a86165388af@gmail.com \
--to=rdalek1967@gmail.com \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox