There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

Is a reinstall required when switching from Intel to AMD

Hi all, I’m switching motherboards. No dGPU. Going from an Intel MB to an AMD one. I have my root partition on an nvme and the home one on a 2.5" sata. Do I need to reinstall, or can I just move the drives from the old MB to the new one without a problem? Figured since both Intel and AMD drivers are both baked into the kernel out of the box, wouldn’t it just work and I’ll only need to remove the Intel stuff? I’m running good ole endeavourOS with KDE Plasma if that makes any difference. Any insight is much appreciated

hackris ,

Reinstalling is only needed when the old and new CPU differ in architecture. Since these two don’t, you don’t have to reinstall, just make sure you install the amd-ucode package :)

penquin OP ,

Just installed the AMD-ucode. Thank you

hackris ,

Happy to help!

original_ish_name ,

Just make sure to install amd-ucode

circuitfarmer ,
@circuitfarmer@lemmy.sdf.org avatar

I just did this a couple weeks back. Absolutely no issues of any kind.

billwashere ,

As you’ve read from the comments it will work just fine.

On the other hand I’ve never done this major of a hardware change without a reinstall. I’d always be concerned if something is wiggy if it was some ghost in the machine from the previous install.

Now I also work in enterprise level IT so even my home stuff is a fairly automated install process with ansible and the like. Then again a lot of it is also virtual so take this with a grain of salt.

penquin OP ,

I actually did run into some of those “ghosts”. Lol Nothing major, though. I’ve been thinking of doing a complete clean install anyway since I haven’t done it in a very long time. Like, I want to even nuke my home partition and redo the whole thing.

neoney ,
@neoney@lemmy.neoney.dev avatar

It will work, but swap the microcode afterwards.

penquin OP ,

What’s the microcode? A driver?

bitwolf ,

It’s a firmware blob. It’ll manifest as a package you have available in the repos usually.

penquin OP ,

Found it as AMD-ucode

neoney ,
@neoney@lemmy.neoney.dev avatar

On Arch, the package names are amd-ucode and intel-ucode

It can be used to fix exploits like the infamous Spectre and Meltdown.

penquin OP ,

Thank you

potpie ,

Sure there are edge cases and whatnot, but just go ahead and move the drive over. If it doesn’t work I’ll buy you a beer.

penquin OP ,

❤️ 🍻

skullgiver , (edited )
@skullgiver@popplesburger.hilciferous.nl avatar

deleted_by_author

    •
    penquin OP ,

    MB is a gigabyte one. I’ll do what I can to remove all the Intel stuff. I mean, if it comes to it, I can easily reinstall. My home partition is separate on its own drive, so a reinstall shouldn’t be an issue aside from reinstalling my apps back.

    loops ,

    You can use Timeshift to backup your apps + configuration and restore after install. Honestly it’s what I would do if plug n’ play doesn’t work.

    penquin OP ,

    Already got that covered with snapshots. I didn’t know I can restore those snapshots on another system. Is it an easy process? Like just move the time shift folders to the new system and restore from the app?

    loops ,

    From what Timeshift tells me, yes. Just restore it on another system; however, I’ve never done it myself. I don’t see how it wouldn’t work though, as long as your not also switching distros.

    d3Xt3r ,

    You may potentially need to edit your kernel boot parameters in grub or w/e bootloader you’re using, in case you’re early-loading any CPU microcode. For instance, if you’re loading your Intel microcode via GRUB, you may need to run grub-mkconfig from a chroot (or your old system, if it’s still accessible), or edit your grub.cfg and check the initrd parameter. But if you’re late-loading microcode then you don’t need to worry about it (although late-loading is discouraged and will taint the kernel).

    Best to check your distro’s documentation on how to update the initrd / microcode.

    penquin OP ,

    I have not made any special changes to the kernel parameters. Everything is stock. Only thing I did is hide grub menu from etc/default/grub. That’s all.

    dohpaz42 ,
    @dohpaz42@lemmy.world avatar

    Intel and amd are compatible because they are both the same architecture. The only times you would need to reinstall is if the architecture changes; eg, 32-bit to 64-bit or you started using an arm based processor.

    penquin OP ,

    Got it. Thank you so much.

    J4g2F ,
    @J4g2F@lemmy.ml avatar

    I upgraded my girlfriends PC grom a i7-4770 too a Ryzen 2600 and just moved the drive without any problems.

    I don’t needed to update or change anything. Only needed to select the drive in the bios.

    penquin OP ,

    That’s reassuring, thank you!

    poVoq ,
    @poVoq@slrpnk.net avatar

    No need to change anything, it will just work.

    penquin OP ,

    Thank you🙏

    mustardman ,

    Microcode and iGPU drivers.

    entropicdrift ,
    @entropicdrift@lemmy.sdf.org avatar

    iGPU drivers should both be in Mesa, so no change needed by the user. Microcode it’d depend on the distro but most should support both out of the box.

    mustardman ,

    amdgpu is distinctly separate from Mesa. Some distos have additional Mesa packages that also need to be instealled, now that you mention it.

    entropicdrift ,
    @entropicdrift@lemmy.sdf.org avatar

    amdgpu is a kernel module. Nearly every distro includes it in their kernel by default. Unless OP rolled their own kernel, they should already have it. If they start up their machine with an AMD graphics card of any kind they most likely shouldn’t need to install or configure anything.

    mustardman ,

    You’re right about amdgpu, my mistake. On arch systems individual Mesa components need to be installed though, like the specific Vulkan modules to be used (amdvlk or RADV).

    wiki.archlinux.org/title/AMDGPU

    trompete , (edited )
    @trompete@hexbear.net avatar

    Should just work. No need to reinstall. You are correct in thinking that all the drivers are included, and furthermore, the drivers on Linux are typically loaded automatically when the hardware is detected on every boot, and this is not configured anywhere in a file or anything like that.

    Usually, anyway. In theory it’s possible that you manually (or some tool) hardcoded drivers somewhere, like in xorg.conf, but I’m willing to bet that isn’t the case.

    atlasraven31 ,

    Tanget: Is it possible to skip this detection step for a faster boot?

    redcalcium ,

    I think you can regenerate your initramfs image to only include your currently loaded modules instead of all modules, which should speed things up a bit.

    …wordpress.com/…/faster-boot-with-trimmed-initram…

    trompete ,
    @trompete@hexbear.net avatar

    No… Not in practice anyway, maybe in theory. I know on ARM SoCs there’s lack of auto-configuration (like you have on PCs with e.g. PCI), and the kernel has no way of knowing what hardware is available. So there’s a file that lists all the devices, and how to talk to them, called (I think) a “device tree”. This file gets appended to the kernel image, and so the bootloader just loads that together with the kernel. The kernel doesn’t do any auto-configuration and rather just reads this file and loads the relevant drivers based on that. I guess it might be (in theory) possible to do this on PC, but I’ve never heard of such a thing. I also don’t expect that to make any noticeable difference for boot times. Pretty sure boot times are dominated by user space, and not the kernel anyway.

    Sidenote (don’t do this): You can compile your own kernel (this used to be pretty common back in the day). You can select only the drivers you need, and can also select whether they should be compiled directly into the kernel or as modules that can be loaded later if needed. Pretty sure the auto-detection happens regardless for most hardware, since the driver needs to be initialized and told where the hardware is to be found. Compiling a driver right into the kernel just means the driver code is in memory right from the very start. I don’t recommend doing this btw, the only difference you will notice is shit not working due to you screwing up, and you’re going to waste a bunch of time and electricity compiling your kernel with every update. You sometimes needed to do this to get all your hardware working, but I haven’t done this in ages.

    penquin OP ,

    Awesome, thank you so much.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines
    •