[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-user
Subject:    Re: [gentoo-user] Migrate install from Intel 6th gen to AMD Zen 4
From:       Victor Ivanov <vic.m.ivanov () gmail ! com>
Date:       2023-09-01 10:30:05
Message-ID: CAB=_hA5F2VweUhWxLye=XE98j5s8XaYHBY_N0G1twca03FJRdA () mail ! gmail ! com
[Download RAW message or body]

Thank you both for the suggestions.

Generally speaking the process went very smooth. I decided not to
recompile all of @world a-priori and go for gold.

Initially it 'appeared' to have hung after 'Loading ramdisk' but this
ultimately turned out to be a frame buffer issue as the machine was,
in fact, booting.

I had installed 'sys-kernel/gentoo-kernel-bin' as a fallback option,
as Nikos suggested, and tried booting into it to investigate the
issue. Sadly, it wouldn't even go past 'Waiting for systemd-udevd',
although not freezing so not quite/yet a frame buffer issue with this
kernel. I gave up on it immediately and relied on my gut feeling that
my kernel should have, in fact, booted as expected (SSH to the
rescue).

There are still issues with 'amdgpu' and early frame buffer where it
continues to hang after loading the ramdisk, especially over
DisplayPort and having a separate nVidia dGPU, but I might post
separately re this if I can't figure it out. I suspect DRM issues and
module conflicts (I've explored the nvidia and amdgpu Getntoo Wiki
articles).

All in all this was a success and a _huge_ improvement over my
previous setup, pretty chuffed with the platform. My 'favourite'
package, QtWebEngine, now only takes 28 min to compile (with
+jumbo-build). I'm still to take it out for a spin with actual work,
but expect huge gains.


On 29/08/2023 11:58, Rich Freeman wrote:
> Well, you won't get segfaults so much as SIGILL, but I'd probably
> simplify a bit.

My bad, but at least the general point was conveyed :)

> As you can see I'm not even setting march. Maybe I could set it a
> little more aggressively and not risk any problems, but I'm concerned
> about the situation where I might have an unplanned CPU upgrade. My
> motherboard could die, and if it does I'd rather be able to just
> replace the motherboard+CPU and not have to fuss around with
> rebuilding my entire system from a rescue disk.

This seems sensible. I don't think there's going to be that big of an
improvement with exact -march, as you point out, except in HPC loads.
I could probably have set it "znver3" or "znver2" to cover a wider
range of CPUs. Then again, since I opted for AM5 and, more crucially,
DDR5 it's unlikely that I would be going to an earlier generation
unless all key components happen to fail at the same time. So fingers
crossed nothing fails any time soon.

> I do have CPU_FLAGS_X86 set, but it seems like most of these are used
> by less critical packages, and I'm not sure how much trouble getting
> these wrong would be.

CPU_FLAGS_X86 aren't that critical tbh as not all packages would
leverage these flags. And, realistically, I was expecting the new ones
to be a superset of the old ones which ultimately ended up being the
case. Unlikely that this would be an issue. Perhaps only for some
packages and if doing a backwards migration to an earlier generation
hardware.

> You say you're "thinking about upgrading" so it sounds like you aren't
> in a hurry and odds are you don't have the new hardware looking at you
> and begging you to boot it up.

Not at the time of writing, but parcels did start arriving quite speedily :)

Cheers,
- V

[prev in list] [next in list] [prev in thread] [next in thread]