Post-cloning advise required... I think the boot is pointing to the original disk

When I started my Linux experiment, I decided to install to an older/spare nvme drive. This was a great starting point, and I installed two or more other distro’s (Mint, Garuda dragonized, Manjaro Gnome) before finally settling on Manjaro KDE Plasma.

Now that I am feeling more confident that this distro is going to be a really good starting point for my Win10 migration/defection, I decided to use my cloning tool (Macrium, which fully supports ext4) to clone from (in linux terms) /dev/nvme1n1 to /dev/nvme2n1

When I booted for the first time after the cloning, I didn’t see what I expected in the F11 BIOS boot menu… which was something like:

  • Win10 - /dev/nvme0n1
  • Manjaro (I think /dev/nvme1n1)
  • UEFI Boot - /dev/nvme1n1
  • UEFI Boot - /dev/nvme2n1

Quite honestly, I expected to see 2 Manjaro entries, one for each nvme, but perhaps the F11 boot selector is confused by two same named boot options post cloning?

So I selected the /dev/nvme2n1 UEFI boot option which brought me to a Manjaro (grub?) boot screen and booted up. Unexpectedly in the “kde partition manager” GUI tool lists my…

  • fat32 /boot/efi as mounted/locked on /dev/nvme2n1, and
  • ext4 / as mounted/locked on /dev/nvme1n1 … not the same disk

I’m not sure if I rebooted into Manjaro enough between the F11 boot options to fully understand which of the two scenarios is most likely… but here are the two scenarios I suspect so far…

  1. Assuming Grub is in play, it is “hard-coded” to a specific partition on a specific driver… and so when I cloned the drive and booted off the new “/boot/efi” partition, it was still pointing to the original “/” partition on the original disk
  2. Linux/Manjaro/Grub if it has the choice will load the “/boot/efi” and “/” off different drives (two of each post cloning)… and I can see some benefits of doing that (boot disk versus data disk)

In a perfect world, scenario 2 is what’s happening… and that if I took a leap of faith and just wiped the old nvme drive (/dev/nvme1n1) that booting would happen normally with the two cloned partitions on /dev/nvme2n1… but I’d like some clarification and advise before I re-partition /dev/nvme1n1 fully to ext4 as my Timeshift/Backup drive.

But if it’s not a perfect world and I need to manually update the GRUB boot loader on the cloned disk… I’m going to need much more advise.

P.S. there is a part of me that thinks if I just opened up my case and swapped the physical locations of NVME 1 and 2 (0 is Windows) that even scenario 1 would be resolved… but on some level that feels like cheating and I want to make sure I learn this important Linux lesson.

Curiosity killed the cat as I tried a series of things…

  1. I figured that with two “cloned drives” (assumption being they were identical) that I would drop the “/” partition on /dev/nvme1n1
  2. I rebooted and through the F11 boot menu I selected the “UEFI Boot - /dev/nvme2n1”
  3. Other than an initial desktop issue (left monitor black/blank, right monitor contained the left’s wallpaper and empty desktop, and the old right wallpaper and desktop shortcuts were gone… re-seating one of the DP connections seemed to correct the desktops as expected) I had a successful boot
  4. I wanted to confirm in the “kde partition manager” GUI that both the “/boot/efi” and “/” partitions were locked/mounted (which they were)… but I ran into an oddity as the tool told me that it couldn’t touch one of the NTFS partitions on my windows drive (/dev/nvme0n1) because ntfs-3g was required… I checked PAMAC and it indicated it was installed, so I selected the option to reinstall it and that seemed to resolve the oddity.
  5. Since this looked like success, I killed the fat32 “boot/efi” partition on /dev/nvme1n1 and rebooted
  6. Noticed this time in the F11 boot menu that both the Manjaro and “UEFI Boot - /dev/nvme1n1” options were removed.
  7. I selected the “UEFI Boot - /dev/nvme2n1” option and Manjaro loaded successfully once again… although I had to pull a DP cable to correct the desktops again
  8. I rebooted one more time, confirmed “UEFI Boot - /dev/nvme2n1” was the only linux boot option, selected to go into the BIOS instead, looked through the HD boot options, and noticed there was an “Ubuntu - /dev/nvme2n1” entry that was not making it into the F11 boot menu… which was really curious as I’m pretty sure Ubuntu wasn’t one of the distro’s I loaded
  9. So I manually added the “Ubuntu - /dev/nvme2n1” entry as a boot option, saved BIOS, and rebooted
  10. I selected this “ubuntu” option from the F11 boot menu, and was presented with a GRUB prompt… I suspect this is why it was suppressed from the boot menu… GRUB is not 100% happy with with the HD change, and that unbuntu might have just been a grub default entry that’s going no where
  11. This left me wondering how my booting into Manjaro was still working, but I’m not going to look that gift-horse in the mouth… I rebooted, entered the BIOS, reversed my force of the “ubuntu” entry, saved/rebooted, F11 booted into “UEFI Boot - /dev/nvme2n1” successfully, and had to pull the DP cable again to correct the desktops

So I’ve learned some things, confirmed some theories (I think the truth lives somewhere between scenario 1 and 2 in my OP), and created new questions. The good news is that I have a booting Manjaro on /dev/nvme2n1 like I wanted, as well as having /dev/nvme1n1 now dedicated fully as an ext4 TimeShift drive… and my revised questions are…

  1. Have I opened a can of worms? might there be other “ntfs-3g” niggles where I may have to reinstall applications/libraries/components to truly be up and functioning 100 percent? Should I really just start over and reinstall Manjaro from scratch? I’m hoping not.
  2. Might my reset KDE theme completely post also provide an answer to the odd desktop loading issue that corrects after a DP cable reset (unplug/plug)? I suspect this issue might have pre-existed the cloning as I don’t recall rebooting prior to it, and I do recall a moment where I had reversed my DP cables as I tried to work through a context menu opening on the wrong monitor thing… and when I reversed the DP cables that caused the exact same desktop issue, so I un-reversed them… so, I may have created the desktop issue and just not known until reboot… or is there some “commit” I can force to re-save the KDE plasma settings that I assume changed after the DP cable was re-seated?
  3. Are there some steps I can perform to correct grub (if that’s truly what’s required) to restore the “Manjaro” F11 boot option (overwriting/correcting the ubuntu entry the BIOS finds)? I think the answer(s) may lay in this wiki I found, but it’s covering a lot of scenarios, giving a lot of suggestions, and it’s just not clear to me which parts would actually improve things instead of making them worse. chroot versus Manjaro-chroot versus reinstall grub… lions and tigers and bears… oh my!

What was your motivation in doing that?

When you clone a disk you will copy UUID’s, not a good idea to have identical UUID’s in a system…

2 Likes

It was was purely to migrate to the newer/faster nvme… but I never just trust the cloning proces, so I trialed it’s booting before repartitioning the original drive, which has now happened.

With cloning i had a lot of trouble years aggo. It is possible, but it is a lot of thinking in advance and work. It is possible to run into big trouble (for example with btrfs this could be desastrous)

My best way to do this is

  • to do a fresh Install until the point it boots up correct but empty.
  • Then copy my Data with rsync (!!!) from the old disk to the new one.
  • Then look for some special files like grub.cfg and fstab. And for the kernels :wink:
  • Then reinstall all packages that where listed in the old install (saved textfile) in one step
  • Then compare (Meld) /etc/* from the old install to the new one

Andreas :sunglasses:

Thank you for the reply andreas85!

I ended up deciding to reinstall Manjaro after backing up a few Home directory items, as there wasn’t much “personal files” I had brought into Manjaro yet… other than downloading a couple hundred gigs of Steam games (loving Proton / Steam Play btw!) One big change I noticed after kicking off the Live USB installer was that the wipe/replace install option showed a diff that indicated the cloned fat32 partition did exist but wasn’t “flagged”/labeled an EFI partition. Might have just been a GUI thing, but that caught my attention.

Saving my Home files taught me about sudo chown $USER:$USER /path/to/mountpoint so I could save my files to another ext4 drive during the reinstall. And this also explained why I was getting permissions issues when I tried to use deja-dup or backintime.

So on this fresh install I have TimeShift looking after my boot and non-Home files (default)… and BiT looking after my Home directory… both are rsync based. Interesting that you mentioned Meld, as it was prompted as an option for BiT… such a great diff program that integrated right into BiT… real slick!

I’ve run into another issue though with the second install, and I’m going to save that for another thread, but hopefully people don’t mind if I ask a few more questions about what I’m still learning in this post.

  1. rsync data copy - what do you make a copy of? do you use rsync to make a copy of all “/” folders/files… or just some select folders files like /home/, /etc/, and your other “special files”?
  • can you point me to any links that would teach me more about what data is stored where? Like where the OS resides, where applications/packages and their configs are written, and is only my personal data in /Home/*?
  1. Special Files… I’m going to reserve grub.cfg and kernels for future learning
  • /etc/fstab - I really needed to move past the /run/media/* mountpoints on access (helped tools like BiT access drive on boot if the drive was automounted), so I now understand the importance of this file… weird though that this post suggested systemd mounts are better… yet the Manjaro install populated fstab… its contents were a great template to follow while I followed the post to mount my other drives
  1. Reinstall All Packages - How do you reinstall packages from a text file? and what generated the text file?

When restoring Data from a backup or a “crashed” linux you have some data you will want to restore, but you will try to not mess up the new install with old files.

  • Don’t copy “/” !!!
  • in /home there is all data from all users of your system

In the new Install create all users from the previous install in the order they where created in the old install (so you will get the same user-ids for the same users. This saves a lot of trouble) you can verify this by
ls -ln /home
check the user-ids ! They normaly start with 1000 for the first user

then you copy all data with rsync from old /home to new /home

After that all data and desktopfiles and user-configs … of all users should be present in the new system.

In /etc you will find all systemwide configfiles. These are to be handled with care. You can´t copy them all together, but you have to inspect them.

  • Do only copy what you understand
  • Do only copy if the same file is present
  • Do only copy single lines or short blocks if needed
1 Like

This info can be found in the arch-wiki. It is real easy to find related infos if you:

1 Like

You will find reliable Infos by searching for:

Fstab is good for things that change seldom

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.