On Monday, 23 November 2020 01:09:16 GMT the...@sys-concept.com wrote: > On 11/22/2020 05:25 PM, Michael wrote:
> > Do you have both disks connected to the MoBo when you're trying to boot > > from the new disk? > > Yes, they are both connected In this case the /dev/sda* you see could well be on the old disk. > > Have you changed the UUIDs on the new partitions? > > Never used UUID in fstab. Do I just run: blkid|grep UUID > and copy it to fstab. I warned you about UUIDs. The block device of /dev/sda* could be pointing at a partition either on the old, or the new disk. In such cases it is a good idea to find out what block devices the MoBo identifies and what the kernel. Go into your BIOS GUI and check if your MoBo sees both disks. You could select which disk to boot from in the BIOS menu. Before you change this, boot the OS and let's look at what block devices the kernel identifies: ls -la /dev/disk/by-* If in the various symlinks listed you will find what disk(s) and partitions your kernel identifies. Alternative commands are blkid, lsblk, udevadm info, hwinfo --block, et al. As long as the kernel has the appropriate modules and you're not missing any necessary firmware, you should find what the nvme disk is identified as and corresponding PARTUUIDs and filesystem UUIDs. When you clone a disk, partition tables, PARTUUIDs, and fs UUIDs, will be copied over. Therefore the kernel will not be able to differentiate reliably which is which, old or new. In addition, sometimes devices are not initialized in the same order. So when probed by the kernel what was identified as /dev/sda last time could be /dev/ sdb now, further adding to confusion when the fs data content is identical. Gparted has an option to change a UUID to a new random number - I suggest you use it. https://gparted.org/display-doc.php?name=help-manual#gparted-changing-partition-uuid On the CLI you can use instead uuidgen and then tune2fs. Once you've done this, it would make sense to mount the / partition on the new disk and adjust its fstab accordingly. In addition you will need to update GRUB so it picks up the new disk / partition. > > Have you installed the boot manager on the new disk (if using MBR)? > > I just copied the whole MBR to a new disk and it worked, the system > boots, but nothing can be compiled. How did you copy the MBR? Using dd command? Unless you cloned a whole disk the MBR sector content won't have been copied over. If the MBR sector has not been copied over the new disk will not be able to boot on its own, but you could still boot it from the old disk, as long as GRUB on the old disk has been updated to pick up the new disk's / partition. I don't think you mentioned it, but in any case I assume you've been using a legacy BIOS with a conventional MBR boot loader and GRUB as a boot manager. As Neil suggested, finding out what's wrong with your current setup and fixing it should prove more fruitful than unnecessarily wasting time reinstalling the whole OS. Ask if you get stuck.
signature.asc
Description: This is a digitally signed message part.
