I used "rsync -aXHv" to duplicate openSUSE's tumbleweed distro from my /dev/sdb8 hard disk partition to my /dev/sdc2 SSD. I then edited the new /etc/fstab on /dev/sdc2 and ran "grub2-mkconfig -o /boot/grub2/grub.cfg". All this for trying to avoid a re-install.

Next boot into the "new" tumbleweed took a long time, lots of disk-head movements and in the end it was a boot into the old system (sdb8).

I looked into /boot/grub2/grub.cfg and that showed the old UUID for /. What happened to make grub2-mkconfig miss the intended target / partition and how can I correct that?

P.S.: I edited /boot/grub2/grub.cfg as root and gave the new UUID but the system goes into emergency mode then... ideas, anyone?

When you ran grub2-mkconfig, it first looks at the current mounted / to figure out what to put in grub.cfg. Since this wasn't the one you wanted, you should have first used "chroot" to change which one. Since the chroot root in this case is a near clone of the old one, this should work okay.

But depending on your specific needs, the simplest thing might actually be to reassign the new partition's UUID to be what the old one was.

The steps I would take for something similar to your situation would be:

1) Shut off computer, install SSD, boot to old system.

2) Use gparted to delete all existing partitions on SSD; create a new one for the cloned OS.

3) mount the new partition to /media/isaac/sdc1

4) use the following command to copy over the files (I use cp -vax because I have had some bad luck with rsync -vaxAX over nfs):

5) use "blkid" to determine the UUID of the new partition; edit /media/isaac/sdc1/etc/fstab appropriately. I comment out all swap partitions in the new fstab until after a successful boot. Actually, I no longer use swap partitions on new installs at all - I now prefer swap file instead, if any.

6) I run update-grub to detect the new install and auto-create a new boot menu entry for the new system. At this point, I could chroot to install grub, but for simplicity instead...

7) Reboot, select new install to boot to. Hopefully this will work. If not, something went wrong.

8) Run update-grub to update grub.cfg. Run grub-install /dev/sdc to install grub to the MBR of /dev/sdc. (I use fdisk -l before this just to make absolutely positively sure that I'm installing it to the SSD.)

I am assuming /boot is part of the / partition, and not in a separate partition. If it's a separate partition, it will also have to be cloned to the SSD.

'Scuse me but this is a misconception on your part. grub2-mkconfig "looks" into all /boot directories it finds -- in my case those of 6 linuxes and the windows disk of my son. And just the copied / rsynced one gives trouble. I did that before with mint (copying to another Partition) which gave no problem.


On the other hand this is openSUSE with btrfs.


I want to run both for the time being (testing, you know ).


That's what I already did, which I described in my first post: "I then edited the new /etc/fstab and ran "grub2-mkconfig -o /boot/grub2/grub.cfg"."





Now it gets tangled: since we are still in an other system (from which all that copying was carried out) we would update that system's grub. An we still would have to run grub2-mkconfig...



Exactly. The /boot/grub2/grub.cfg is faulty.


Well what /boot exacly is on btrfs (something called a subvolume I think) -- that may cause all this trouble. On the other hand grub2-mkconfig works on 4 other openSUSE installations on this machine.

Thanks for trying to help .

Sorry, but you have a misconception. That's why you're having a problem, and that's why you don't understand why you're having a problem.

You are correct that grub2-mkconfig looks at all /boot directories it finds. But it ALSO looks at the currently mounted / in order to figure out which one is the point the grub bootloader to.

If you don't want to learn what's going wrong and learn how to fix it, though, have fun with that! Without understanding how to use grub-install, you'll find your system no longer boots after you remove the old install. Won't that be fun?

Hey, hey, keep calm. I am aware, that grub2-mkconfig looks at the currently mounted / in order to figure out which one is the point the grub bootloader to.

I will run grub2-install from the new installation when I can boot the new installation from the current grub (actually I have grubs on all discs in my machine). Point is, up to now I can't boot the new one -- leaves your chroot suggestion, of course.

And of course I will remove nothing as long as the new install doesn't work and maybe even then not for a long time. This is my working machine...

The simplest starting point is to start grub, then edit the boot line with 'root=<deviceid>'. I find this easiest if the root volumes have unique labels - then I can say 'root="LABEL=<label>"'. The double quotes are needed to ensure the "LABEL=<label>" is treated as the complete value to the root option.

This will use the old kernel with the new root - and you can then run the grub2-mkconfig and get it set right.

Okay, that is an idea. The partitions have labels, though I use UUIDs.

But as I wrote in my first post grub.cfg is generated faulty. That problem has to be tackled, because tumbleweed rather often gets new kernels and every time generates new grub.cfg's.

Sorry for getting ruffled up.

Maybe the only problem is that not all builds of grub2 have the necessary modules to directly use btrfs. I'd try replacing it with an ext4 partition to reduce the number of things that could go wrong.

You are probably right, only this is openSUSE whose people use btrfs as their default "/". This comes in quite handy since YAST produces snapshots of your system every time your system is updated so you can easily roll back when something goes awry. They should package all things necessary for grub on btrfs.

That would rob the charm of the whole setup. Not to mention the fact, that I don't know how, /boot is on a subvolume, not a regular partition, which would probably also break updating the system. No, grub.cfg is faultily produced by grub2-mkconfig. I'll have to find out why and how.

Okay, lets wrap this up. The problem can't be solved (at least not by me).


Facts:

os-prober "looks" not only at the linux_10 line of the grub.cfg but gets some more information. From where I found no documentation to tell me.

grub2-mkconfig creates a faulty grub.cfg under the circumstances I described above with two different UUIDs for root.

The rsync command I used did not create an identical fstab in the new System (in particular those @/.subvolume lines where sort of abbreviated. I adjusted that but no luck then either.

I suspect this has to do something with the subvolumes handling by rsync and/or grub2-mkconfig. I do not know what exactly happens nor how to set it right.

I downloaded and installed tumbleweed, everything is working now as it should. Original Problem not solved.

I do not recommend changing the UUID. ("It's not nice to fool Mother Nature ...")

Ah, well for testing's sake...