From: none@not.here   
      
   Paul wrote:   
   > 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.   
      
   great!  :)   
      
   > 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   
      
      
   --   
   Linux Mint 22.1   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)