Hi - I am about to embark on a new adventure and am going to install/upgrade a new motherboard, with new processor, on-board graphics, and memory. (The old one is about 15 years old, dating back to the Pentium 2 core processor days.) I want to keep my OpenSuSE 15.4 x64 system and all the custom application configurations as is. Is there any hiccups or other roadblocks I should prep my system for, before doing this massive hardware change-over? I just want to make this adventure go as smooth as possible and looking for advice from the schools of hard knocks! Thanks as always, in advance... Marc.. -- *"The Truth is out there" - Spooky* *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed and the OpenPGP electronic signature is added as an attachment. If you know how, you can use my public key to prove this email indeed came from me and has not been modified in transit. My public key, which can be used for sending encrypted email to me also, can be found at - https://keys.openpgp.org/search?q=marc@marcchamberlin.com or just ask me for it and I will send it to you as an attachment. If you don't understand all this geek speak, no worries, just ignore this explanation and ignore the OpenPGP signature key attached to this email (it will look like gibberish if you open it) and/or ask me to explain it further if you like./)
From: Marc Chamberlin <marc@marcchamberlin.com> Date: Tue, 10 Jan 2023 13:12:30 -0800 Hi - I am about to embark on a new adventure and am going to install/upgrade a new motherboard, with new processor, on-board graphics, and memory. (The old one is about 15 years old, dating back to the Pentium 2 core processor days.) I want to keep my OpenSuSE 15.4 x64 system and all the custom application configurations as is. Is there any hiccups or other roadblocks I should prep my system for, before doing this massive hardware change-over? I just want to make this adventure go as smooth as possible and looking for advice from the schools of hard knocks! Thanks as always, in advance... Marc.. I have popped many old openSUSE boot drives into hardware of various ages and they have all "just worked." So putting a current 15.4 boot drive into new hardware should be a breeze, since you are unlikely to have drivers that can't handle interfaces that came out after the OS release. Famous last words, of course, so I'm sure I don't need to tell you to back it up first. -- Bob Rogers http://www.rgrjr.com/
On 2023-01-10 15:12:30 Marc Chamberlin wrote:
|Hi - I am about to embark on a new adventure and am going to |install/upgrade a new motherboard, with new processor, on-board |graphics, and memory. (The old one is about 15 years old, dating back to |the Pentium 2 core processor days.) I want to keep my OpenSuSE 15.4 x64 |system and all the custom application configurations as is. Is there any |hiccups or other roadblocks I should prep my system for, before doing |this massive hardware change-over? I just want to make this adventure go |as smooth as possible and looking for advice from the schools of hard |knocks! | |Thanks as always, in advance... Marc..
I know this isn't strictly a response to your question, but I always keep my /home directory on a separate drive so that it's independent of any glitches that might arise when migrating either OS or hardware. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 x86_64
Marc Chamberlin composed on 2023-01-10 13:12 (UTC-0800):
Hi - I am about to embark on a new adventure and am going to install/upgrade a new motherboard, with new processor, on-board graphics, and memory. (The old one is about 15 years old, dating back to the Pentium 2 core processor days.) I want to keep my OpenSuSE 15.4 x64 system and all the custom application configurations as is.
The general rule is no problems if the new motherboard is old enough. That translates roughly into 6-12 months newer OS release than hardware introduction date. That translates on 15.4 roughly into no problems for sockets LGA1200 & LGA4189 (Comet Lake, Cooper Lake, Ice Lake & Rocket Lake 4XX/5XX chipset) motherboards, possible problems for sockets LGA1700 & LGA4677 (Alder Lake 6XX chipset) motherboards, and probable problems for Raptor Lake (1700/4677 with 2022 CPUs/7XX chipsets). For Alder Lake you may need a BP kernel (from build service same kernel version TW and/or 15.5 is using) for everything to work. Without one, you may need to use nomodeset to enable booting at all, and Intel X graphics may have limitations or totally fail, especially if you have done any manual X configuration. Intel CPUs with on-chip GPU support 3 displays on motherboards providing that many outputs. My Rocket Lake has one DP and two HDMI. If currently XF86-video-intel is installed, removing it first could be a good idea, as it's generally disfavored for recent Intel graphics. You also may need newer firmware for networking, more likely for wireless than for wired. Basically, try booting your old HDD or SSD on the new motherboard, and see what happens. If you don't reach the login screen you should try again by striking the E key at the Grub menu to append plymouth=no and remove splash=silent and quiet on the end of the linu line to enable boot messages to look for clues what is happening or not. Otherwise successfully booted you'll need to modify network settings for the changed MAC addresses, and audio may need reconfiguration, but otherwise you might have a well working installation. Linux is really good with hardware switches when limited to hardware it knows about. Once you know what's needed, you'll want a fresh installation to the NVME you'll want to be using to enjoy maximum available storage performance. You could clone from the old HDD or SSD to the NVME, but I suggest you don't, to facilitate automatic use of optimal settings for the faster new environment. Logged in as root you can copy your homedir on the old disk to the new NVME location to preserve personal settings. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 1/10/23 16:18, Felix Miata wrote:
The general rule is no problems if the new motherboard is old enough. That translates roughly into 6-12 months newer OS release than hardware introduction date.
100% agree, Since the boot process probes for hardware, as long as the kernel has the modules for your hardware, just put the new motherboard in, add your 15.4 drive and hit the power button... As long as you haven't forked out $1K for AMD or Intel's latest hardware that rolled of the assembly line yesterday and that 15.4 doesn't know about, you should be fine. You may want to regenerate the initrd after your first boot. In 15.4 as root just run 'mkinitrd' and that will automatically hook dracut. Or you can do: dracut -fM --kver $(uname -r) That said, if the boot went fine, there really isn't any reason. It will be triggered anyway on your next update that does it automatically (e.g. systemd, kernel, etc..) -- David C. Rankin, J.D.,P.E.
David C. Rankin composed on 2023-01-11 02:07 (UTC-0600):
Felix Miata wrote:
The general rule is no problems if the new motherboard is old enough. That translates roughly into 6-12 months newer OS release than hardware introduction date.
100% agree,
Since the boot process probes for hardware, as long as the kernel has the modules for your hardware, just put the new motherboard in, add your 15.4 drive and hit the power button...
As long as you haven't forked out $1K for AMD or Intel's latest hardware that rolled of the assembly line yesterday and that 15.4 doesn't know about, you should be fine.
You may want to regenerate the initrd after your first boot. In 15.4 as root just run 'mkinitrd' and that will automatically hook dracut. Or you can do:
dracut -fM --kver $(uname -r)
IME, as long as you wish to rebuild the running kernel on openSUSE, there's no need to be concerned with what the kernel version or syntax is. All you need is: dracut -f From man page: SYNOPSIS dracut [OPTION...] [<image> [<kernel version>]] DESCRIPTION Create an initramfs <image> for the kernel with the version <kernel version>. If <kernel version> is omitted, then the version of the actual running kernel is used.... -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 1/11/23 02:28, Felix Miata wrote:
IME, as long as you wish to rebuild the running kernel on openSUSE, there's no need to be concerned with what the kernel version or syntax is. All you need is:
dracut -f
And less typing too. I had always hardwired the version if calling dracut -- not the first time I've over-complicated things for myself :) -- David C. Rankin, J.D.,P.E.
David C. Rankin composed on 2023-01-11 02:07 (UTC-0600):
Since the boot process probes for hardware, as long as the kernel has the modules for your hardware, just put the new motherboard in, add your 15.4 drive and hit the power button...
Maybe not such a good idea if your old hardware included an NVidia GPU and NVidia's proprietary drivers installed, and the new will include a different GPU. Those drivers muck with things that could make the first boot experience painful. Those drivers should be uninstalled according to their installation instructions last thing before turning off the old for the last time before the motherboard swap, unless you'll be using the same old GPU with the new motherboard. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
On 1/11/23 02:35, Felix Miata wrote:
David C. Rankin composed on 2023-01-11 02:07 (UTC-0600):
Since the boot process probes for hardware, as long as the kernel has the modules for your hardware, just put the new motherboard in, add your 15.4 drive and hit the power button...
Maybe not such a good idea if your old hardware included an NVidia GPU and NVidia's proprietary drivers installed, and the new will include a different GPU. Those drivers muck with things that could make the first boot experience painful. Those drivers should be uninstalled according to their installation instructions last thing before turning off the old for the last time before the motherboard swap, unless you'll be using the same old GPU with the new motherboard.
They should attempt the load and fail when no hardware was found. The onboard graphics should still be found an initialized. It may be a bit confusing on which monitor what goes (especially if you had hard-coded some of your x86 config as in the old days). If things do go south for graphics on boot, then /var/log/Xorg.0.log should point to the exact culprit. -- David C. Rankin, J.D.,P.E.
David C. Rankin composed on 2023-01-11 04:09 (UTC-0600):
Felix Miata wrote:
David C. Rankin composed on 2023-01-11 02:07 (UTC-0600):
Since the boot process probes for hardware, as long as the kernel has the modules for your hardware, just put the new motherboard in, add your 15.4 drive and hit the power button...
Maybe not such a good idea if your old hardware included an NVidia GPU and NVidia's proprietary drivers installed, and the new will include a different GPU. Those drivers muck with things that could make the first boot experience painful. Those drivers should be uninstalled according to their installation instructions last thing before turning off the old for the last time before the motherboard swap, unless you'll be using the same old GPU with the new motherboard.
They should attempt the load and fail when no hardware was found. The onboard graphics should still be found an initialized....
They should, but it's my understanding that NVidia's proprietary drivers may include a replacement for at least one system lib (evil "muck with") that is not compatible with drivers for other GPUs, meaning X may fail to run even trying to use the crude, fallback vesa and/or fbdev drivers. In such a case Xorg.0.log may not report what's needed to know, just an inexplicable segfault. Since I never install proprietary drivers on any PC I own, I've had no incentive to test whether my understanding has any basis in fact. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Am 11.01.23 um 11:37 schrieb Felix Miata:
David C. Rankin composed on 2023-01-11 04:09 (UTC-0600):
Felix Miata wrote:
David C. Rankin composed on 2023-01-11 02:07 (UTC-0600):
They should attempt the load and fail when no hardware was found. The onboard graphics should still be found an initialized....
They should, but it's my understanding that NVidia's proprietary drivers may include a replacement for at least one system lib (evil "muck with") that is not compatible with drivers for other GPUs, meaning X may fail to run even trying to use the crude, fallback vesa and/or fbdev drivers. In such a case Xorg.0.log may not report what's needed to know, just an inexplicable segfault. Since I never install proprietary drivers on any PC I own, I've had no incentive to test whether my understanding has any basis in fact.
years in past i have had exact this situation removing nvidia prop drivers and put a amd gpu in, it will not work, do not ask me where the problem was, but nvidia has blocked something to fallback to an standart driver. i only remember i have searched long to find what it was..... :-(( (i for sure would find it this days faster :-)) never used any nvidia again, even if they build nice hardware. -- www.becherer.de ----------------------------------------------- - Das ist die vorlaeufig endgueltige Version! - Herbert C. Maier Dipl.-Ing. (FH) -----------------------------------------------
On 1/11/23 04:51, Simon Becherer wrote:
years in past i have had exact this situation removing nvidia prop drivers and put a amd gpu in, it will not work, do not ask me where the problem was, but nvidia has blocked something to fallback to an standart driver. i only remember i have searched long to find what it was..... :-(( (i for sure would find it this days faster :-)) never used any nvidia again, even if they build nice hardware.
I guess that's the good lesson. I've use ATI/AMD proprietary drivers as well as nvidia proprietary drivers and would always remove the drivers before a hardware change. I've done it on openSUSE and on Arch and haven't had any issues. If I recall correctly, the issue with nvidia is it is not compatible with the fbdev frame-buffer. I'm not sure if it removes it, but uninstalling nvidia must revert it or it wouldn't be rpm compliant (may just rename it and restore it with some post-remove script) That should be sound advice on any major hardware change -- remove proprietary drivers for hardware that is going to change. Change the hardware and hit the power button. -- David C. Rankin, J.D.,P.E.
On Tue, 10 Jan 2023 at 22:12, Marc Chamberlin <marc@marcchamberlin.com> wrote:
Hi - I am about to embark on a new adventure and am going to install/upgrade a new motherboard, with new processor, on-board graphics, and memory. (The old one is about 15 years old, dating back to the Pentium 2 core processor days.)
Oh boy. So, for such an old system, is the OS and/or data on a hard disk drive?
I want to keep my OpenSuSE 15.4 x64 system and all the custom application configurations as is.
Should be OK with Linux. A world of pain with Windows, of course. Are you buying a new SSD or something for the new one? If it's an HDD and you're not buying an SSD, you definitely should. If it's an old small SSD, buy a bigger one. Plug both into the new or the old computer, boot off a Live USB, use Gparted to copy your whole old partition(s) to the new drive(s). This will copy the UUIDs of the partitions as well, and if your `/etc/fstab` file uses UUIDs not device names -- as it ought to -- then it should Just Work™ on the new PC. Then put the old one(s) in a safe place as backup. On the new drive in the new PC, reinstall GRUB and you _should_ be good to go. P.S. the generally accepted netiquette is that a signature should be a max of 4 80-column lines. ;-) -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
On Tue, 10 Jan 2023 23:45:09 +0100 Liam Proven <lproven@gmail.com> wrote:
P.S. the generally accepted netiquette is that a signature should be a max of 4 80-column lines. ;-)
I don't think so. Four lines yes, eighty characters no. RFC5322 says "There are two limits that this specification places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF." So that says 78 rather than 80. And then it refers to the MIME RFCs which specify 76 (4x19) and indeed if we look at the source of the last line of the signature in your email we find: (elision to be sure to fit it on one line because my MUA wraps early) UK: (+44) ... WhatsApp/Telegram/Signal]: (+420) 702-829-= 053 and surely enough the mail system has split your carefully engineered 78 character line into two lines so that neither exceeds 76!
On Wed, 11 Jan 2023 at 13:28, Dave Howorth <dave@howorth.org.uk> wrote:
On Tue, 10 Jan 2023 23:45:09 +0100 Liam Proven <lproven@gmail.com> wrote:
P.S. the generally accepted netiquette is that a signature should be a max of 4 80-column lines. ;-)
I don't think so. Four lines yes, eighty characters no.
Ahahahaha! :-D I sit corrected. -- Liam Proven ~ Profile: https://about.me/liamproven Email: lproven@cix.co.uk ~ gMail/gTalk/FB: lproven@gmail.com Twitter/LinkedIn: lproven ~ Skype: liamproven UK: (+44) 7939-087884 ~ Czech [+ WhatsApp/Telegram/Signal]: (+420) 702-829-053
On Wednesday 11 January 2023, Marc Chamberlin wrote:
Hi - I am about to embark on a new adventure and am going to install/upgrade a new motherboard, with new processor, on-board graphics, and memory. (The old one is about 15 years old, dating back to the Pentium 2 core processor days.) I want to keep my OpenSuSE 15.4 x64 system and all the custom application configurations as is. Is there any hiccups or other roadblocks I should prep my system for, before doing this massive hardware change-over? I just want to make this adventure go as smooth as possible and looking for advice from the schools of hard knocks!
Thanks as always, in advance... Marc..
I've never had any substantial issues when moving Linux boot ssd/harddrives to new systems. I did three moves as recently as last year. As others have mentioned you might need to reconfigure for changes such as a different GPU, or audio, but it should boot to where you can do all that later. As for SSD versus NVME. After moving to a Ryzen 5600 based CPU and motherboard last year, I decided to see if 250GB MVME would make much of a difference over the 250 GB SSD that I was using for root (and only root). I think I might have saved a second or two on boot, but there were no other noticeable improvements. I switched root back to SSD: no tiny screws, less handling issues, less heat concerns, no messing with the MB, which makes SSD's quick and easy to swap around, including back into 10 year old machines. SSD is a big win, a couple of years back I've moved /home to a 2TB SSD, totally worth every dollar spent. Rotating rust is now for backups only. As I understand it NVME will be of benefit if you're doing lots of chunky I/O, such as loading up a game, trawling through a database, or a disk to disk copy. I just don't do enough of that kind of thing. I've relegated the NVME to being a utility drive on /mnt/fast. I probably should have spent the NVME money on more RAM. With AMD/Ryzen it's supposedly risky to add more RAM later. The advice seems to be to replace the whole set with another. Intel is supposedly more robust due to older memory controller tech. Mysterious crashes are not something I want to deal with. Michael
Am 10.01.23 um 22:12 schrieb Marc Chamberlin:
Hi - I am about to embark on a new adventure and am going to install/upgrade a new motherboard, with new processor, on-board graphics, and memory. (The old one is about 15 years old, dating back to the Pentium 2 core processor days.) I want to keep my OpenSuSE 15.4 x64 system and all the custom application configurations as is. Is there any hiccups or other roadblocks I should prep my system for, before doing this massive hardware change-over? I just want to make this adventure go as smooth as possible and looking for advice from the schools of hard knocks!
Thanks as always, in advance... Marc..
only two things to think about: 1) if you have a nvidia graphic in the old system with nvidia proprietary drivers, remove all of the driver stuff. (i am not sure if necessary to run mkinitrd after removing) 2) take a look in your /etc/fstab file. if there are the old drives in with the specific names, change them inside your old computer to something that will boot in the new one as example "/dev/sda1" will be fine for new and old computers (if its a real harddrive). if its a something cryptic your new system will maybe not boot (you could try). of course you have to run the mkinitrd as david has written here, before you change hardware, that the initrd boot is ready when you plug in new mainboar3d (and after also as he has described). simoN -- www.becherer.de ----------------------------------------------- - Das ist die vorlaeufig endgueltige Version! - Herbert C. Maier Dipl.-Ing. (FH) -----------------------------------------------
Marc Chamberlin wrote:
Hi - I am about to embark on a new adventure and am going to install/upgrade a new motherboard, with new processor, on-board graphics, and memory. (The old one is about 15 years old, dating back to the Pentium 2 core processor days.) I want to keep my OpenSuSE 15.4 x64 system and all the custom application configurations as is. Is there any hiccups or other roadblocks I should prep my system for, before doing this massive hardware change-over?
In my business, we rent a number of servers externally, I think we have a motherboard replaced about once a year. For us, the key thing is the MAC address(es) of the network interfaces in /etc/udev.d/rules.d/70-persistent-net.rules. Those rules determine the naming of your network interfaces, which is often critical to everything else. AFAIR, it is usually a good idea to also rebuild the initrd.
--
*"The Truth is out there" - Spooky*
[snip 24 lines of signature - maybe a bit too long?] -- Per Jessen, Zürich (6.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Wed, Jan 11, 2023 at 1:28 PM Per Jessen <per@jessen.ch> wrote:
For us, the key thing is the MAC address(es) of the network interfaces in /etc/udev.d/rules.d/70-persistent-net.rules. Those rules determine the naming of your network interfaces, which is often critical to everything else.
And those rules will not match after motherboard replacement. More than once I found a system in a remote datacenter inaccessible after motherboard replacement with only pure hardware smart hands on site.
Andrei Borzenkov wrote:
On Wed, Jan 11, 2023 at 1:28 PM Per Jessen <per@jessen.ch> wrote:
For us, the key thing is the MAC address(es) of the network interfaces in /etc/udev.d/rules.d/70-persistent-net.rules. Those rules determine the naming of your network interfaces, which is often critical to everything else.
And those rules will not match after motherboard replacement.
Yes, exactly.
More than once I found a system in a remote datacenter inaccessible after motherboard replacement with only pure hardware smart hands on site.
Ditto - most often though, our provider will have booted a rescue system, and the first thing we do is always to remove /etc/udev.d/rules.d/70-persistent-net.rules and then reboot. -- Per Jessen, Zürich (6.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
participants (11)
-
Andrei Borzenkov -
Bob Rogers -
Dave Howorth -
David C. Rankin -
Felix Miata -
J Leslie Turriff -
Liam Proven -
Marc Chamberlin -
Michael Hamilton -
Per Jessen -
Simon Becherer