From: nospam@needed.invalid   
      
   On Thu, 8/21/2025 1:17 PM, alan wrote:   
   > After months without a working system, one with a new motherboard actually   
   > started up and is currently running off a Mint 22.1 install flash drive.   
   > It is cloning the contents of a 1TB drive to a 2TB drive. When it is   
   > finished, the 1TB drive will be removed.   
   > The problem is that the 1TB Nvme drive was set on an Asus motherboard   
   > whereas the replacement is a Gigabyte board. When trying to boot from it,   
   > it gets to the grub menu but comes to a halt after scrolling several lines   
   > up the screen.   
   > I don't want to lose the contents by reinstalling. Is there a procedure I   
   > can take to recover it?   
   >   
      
   Linux distros can be moved from machine to machine.   
   I'm not concerned about that part. From what I've seen, even   
   if you used Driver Manager for one video card, then had a different   
   video card in the machine with the moved distro, it still boots   
   and comes up and you can see the screen. The distro knows enough   
   to handle any driver issue. This works best with "mature" video cards   
   which have been around long enough to be handled by the release.   
      
   How are you cloning ?   
      
   You can't use "dd" to clone a GPT partitioned drive to a   
   larger GPT partitioned drive, since the secondary partition table   
   (at the end of the disk), is no longer sitting at the end.   
      
   This shows me "fixing" my big disk after a dd clone to it.   
      
       Select the "fix" option when it is offered!   
      
   I am using "gparted" package to do it, and just pointing   
   gparted at the disk when started gparted, is enough to   
   trigger the repair dialog. Once repaired, only BIGDSK is in the   
   machine during its first boot (to avoid duplicate identifier   
   issues caused by dd cloning).   
      
      sudo gparted /dev/sdb         # Point gparted at the BIGDSK not the SMALLDSK   
                                    # You can do this right after the dd clone if   
   you want.   
      
      [Picture]   
      
       https://i.postimg.cc/htKvjgFt/fix-small-big-clone-via-gparted.gif   
      
   I noticed during boot of the repaired BIGDSK, a complaint of   
   corrupt inodes being removed, so at some point in my "dd adventure"   
   some cloning was not done properly and some write data was not   
   flushed out to the BIGDSK. I'm not sure where that came from,   
   but I don't like to see crap like that. I pride myself on treating   
   mounted partitions properly so that does not happen, which is why   
   I like to know how such things happen.   
      
   *******   
      
   If you used some other cloning method, the "handler" in the cloning   
   method should do a much better job of such things, and damaging   
   the secondary GPT partition table won't be an issue when moving   
   to the larger disk.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)