@jlehtone
This is perplexing and embarassing.
I was sharing the Power supply between this and the older computer on which I had got Zorin installed.
I reassembled the machine - and now it works!!
I am really perplexed - the only difference I think is probably the connection of the HDDs to various points - SATA_2, SATA_3 etc. Because I KNOW for sure, the boot drive (SSD with Rocky Linux its only occupant) was connected to SATA_1 on BOTH ocassions.
Nevertheless it is working right now… But me and I suppose others would be very keen to know why this happened.
I suppose we can close this thread as the problem is solved, but it does feel like this is attributed to happenstance, or the simple choice of connecting the HDDs to their original SATA ports on the motherboard.
BR, and I wish Merry Christmas and happy new year to you all.
It certainly helps to connect them back in their original places, so that what was /dev/sda i still /dev/sda when reconnected. If they were mixed up, then potentially this kind of thing can happen. Whilst technically, /etc/fstab and grub.cfg will have UUID’s for most parts, there is the potential that something was still referencing by disk (/dev/sdX) for example and hence the problems booting. Glad you got it sorted though
I did write that UUID’s in fstab and grub should resolve that but obviously it didn’t. Obviously on his configuration it was referencing the devices via sda etc else he could connect as he wants and the system should have booted normally.
Normally, connecting disks in order will keep the same notation of /dev/sda, /dev/sdb etc. It does on my system. Changing from sata to ide for example won’t necessarily, as previously ide/ata would be /dev/hdX, and sata /dev/sdX. The fact that he did this, and his system started to work, shows that as he mentioned that in his last post.
Of course formatting/cloning would cause issues with UUID’s, but if just switching disks between systems without formatting/cloning, then the UUID will be the same, and should be more reliable than using /dev/sdX notation.
One more thing: LVM (like RAID) has metadata on devices too. One should/could mark LVM disk “detached” before disconnecting and moving to another machine. One does not necessarily want LVM to “autostart” such volumes on first boot, but do it explicitly later. LVM VG and LV names could conflict too (if you combine drives from multiple systems).
Yep, another problem with LVM that can occur. I think from memory that can be done with:
vgchange -an
to disable. I have had disks with LVM attached to a new system that weren’t automatically active and used:
vgchange -ay
to activate and then it was possible to mount, etc. Obviously those commands can be more specific to activate/deactivate for only a particular volume group rather than all vg’s which the -a parameter applies.
UEFI and PCIe support. I have never in my entire life had a good experience with new hardware.
The other thing is the new firmware (BIOS) version has a chance to just not let you boot into that previous installation which depends on how every slot and bus is mapped out. I think they use a virtual IRQ now? IDK but it can and will act like a completely different board between BIOS revisions.
The other issue with video outside of Windows is the boot mode. Every distro and hardware combination is different, so you might need to try different combinations of legacy or UEFI mode with all of the different Secure Boot features used in different combination.
There’s also the on-die GPU which may or may not need to be manually disabled… you might need to use it first and then switch the display cable over to the discrete card later after the Nvidia driver is installed. You might need to use both and figure out where the display cable works best for you when both GPUs are enabled.
There are MANY variables. There is no canned answer that works for everyone with similar hardware. I would suggest trouble-shooting with the motherboard manual. I am sorry I have no easy answer. I spend hours of trial and error with every build.
120 GiB BOOT?!? You have only a SINGLE Partition?!? At the bare minimum you should have 2 partitions: Partition 1 is your /boot partition, it should be no more than 3 GiB in size. Partition 2 is for all the other stuff, LVM is good for that.
Question 2: Grub2: Make sure the /boot partition matches your set up. Assuming you are using UEFI the GRUB 2 entry should be set up to be something like [/boot/efi/EFI/centos/grub.cfg] (/boot/grub2/grub.cfg vs /boot/efi/EFI/centos/grub.cfg - CentOS), not
/boot/grub2/grub.cfg
Question 3: When you got thr new mobo did you Update BIOS. Don’t use the experimental BIOS only the fully tested one/s
Question 4: Is your CPU Intel or AMD?!? If Intel make sure everything is set up to be UEFI, but in that case make sure all devices are UEFI enabled not Legacy enabled.
I think your major problem is that you have just a SINGLE partition of 120 GiB which includes the /boot partition. You would be well advised to create a /boot partition as Partition 1, and a LVM partition for Partition 2.
A NOTE: Right now I would suggest NOT to screw with nouveau which is a driver for Nvidia… at least NOT until you have Rocky Linux 8.5 up and running and fully configured , then fully BACKUPED. Then and ONLY THEN go ahead and try and install the Nvidia drivers. If worse comes to worse and it crashes your machine simply re-install your backup.
One other thing occurred to me: Take the entire rig apart – including CAREFULLY removing the CPU – remove the coin battery, let it sit for 5-10 minutes, then replace the coin battery, then slowly and carefully put the entire thing back together. It is possible there is/was a loose connection. Removing the the coin battery will clear CMOS, that should get you out of the loop.
When I had replaced the Processor, the CMOS battery was removed for more than 10 min.
I had reconnected everything [correctly, I presume the way HDDs were connected to respective SATA terminals on motherboard, prior to the CPU malfunctioning].
And the system was running properly, I had mentioned it in my last reply.
This reply is to thank you for your time and mental capital. Also, if necessary, for you to ponder over the HDD-SATA connectivity order prior to and post CPU replacement - if that was indeed the culprit.
I have no means of record of what the HDD-SATA connectivity was prior to CPU going bust.
