As I’m not familiar with timeshift I can’t tell what’s “better”.
However I would follow @hcvv advice:
They will erase your root partition in the same way if you use them wrongly in the same way.
I never use these what I call “sophisticated” tools. Because then you have to see that you remove all sophistication and press them to do just one thing: copy byte by byte (like dd does > 40 years already).
I would never trust a copy on the file level of a running system to be an exact copy, but your mileage may vary. (maybe your finger crossing did help 
)
If system is booted from the current root partition (and not from the live medium) /boot/efi partition is already mounted so this is not possible. It should be mount --bind (or umount it first).
Also on EFI platform Tumbleweed needs additionally
mount -o bind /sys/firmware/efi/efivars /mnt/p5/sys/firmware/efi/efivars
otherwise NVRAM cannot be updated from within chroot.
I am really tired of posting it over and over again and nobody apparently listening, but - the correct way to reinstall bootlader on (open)SUSE is
update-bootlader --reinit
unless you took some efforts to actually understand the configuration and to find out exactly what bootloader is used, how it is configured and what commands to reinstall it are needed. Blindly using grub2-install without as much as even trying to find out the above will have high probability of introducing hard to troubleshoot misbehavior (which could strike after a long time so nobody will remember and associate problems with this command). On EFI it is not that bad - the worst that can happen is inability to boot due to Secure Boot.
Yes, indeed! Sorry, my fault (I use LIVE media in most cases).
So mount -o bind /sys /mnt/p5/sys will not suffice?
I never used update-bootloader on any of my systems (and all of them are still up and running) so I cannot comment on this.
Ah, to late for me
I have run those commands already and my grub config has changed.
I’m now running from the P5 partition(P5 see above) .
What i have done:
On my existing running install
run the (wrong) commands grub2-install grub2-mkconfig -o /boot/grub2/grub.cfg
The boot options contain after this the de p5 partition.
Made a new snapshot with Timeshift from my existing partition and wrote it to P5.
Timeshift automatic alters my fstab on the new P5 partiton with the correct UUID for /
Took a deep breath, closed everything and did a reboot.
Now I could chose to start from P5 and was running from the new partition
pff lucky me.
Is it wise to run the update-bootlader --reinit after this or is the possible harm already done?
I have searched the forum for this command but the only result that I get is this topic.
The search in this forum is probably not perfect.
Probably @arvidjaar was talking about all his posts on the openSUSE mailing lists as well. There he indeed mentioned that command (at least once).
However I never used that command on any of my systems so I saw no need to recommend it.
Please accept my apology if my negligence caused you any trouble.
No need to
The system is running thanks to your “wrong” commands
I made a note of @arvidjaar comments
Old age is making remember things difficult (only 70 but…)
The install has become bloated so in the coming year I will do a clean install
In my experience, that has been sufficient.
No. This is separate filesystem. Alternative is to use mount --rbind.
Have you ever succeeded doing this on a UEFI/GPT installation? I don’t see anything in that list that gets the ESP mounted before Grub is updated, nor any precaution taken against the new location’s new entry on the ESP usurping the current one required to continue to be able boot the original installation directly. For the first problem, mount -a is needed following chroot. The second problem I deal with by making the original /etc/default/grub GRUB_DISTRIBUTOR= entry unique prior to a normal Grub update, or running an extra one before attempting to install or enable booting of an additional installation.
You may want to read all posts in this thread thoroughly to find the answer (and even more) …
What about mount /dev/nvme0n1p1 /mnt/p5/boot/efi (command number three)?
I know about the GRUB_DISTRIBUTOR= trick (and even use it on some of my systems). However OP mentioned in his first post that he wanted to move his system vom partition /dev/nvme0n1p3 to partition /dev/nvme0n1p5 so I saw no reason “to pollute” his ESP with another directory containing a bootloader pointing to a system which might be deleted immediately after the action discussed here finished successfully.
I read the whole thread before asking, and again after your reply, and still don’t see a clear answer; but, it is a busy thread with multiple posters and subthreads, and I could have missed something.
More what?
I asked because I’d never seen a recommendation to mount the ESP partition prior to the chroot, contrary to Karl’s website. I started a new SDB: a week or more ago on the subject, but never got very far, and only just noticed I had never submitted a first draft.
It’s no trick. Everything in /etc/ is at least theoretically under control of the admin. Items placed there in new TW installations are dwindling, as part of the long term migration of distro configs to /usr/.
String move did not exist in this thread until you used it. I’d rather see recommended that the old is maintained operable until such time as the new is fully ready, unless its destruction is unavoidable.
This reminds me of an old anekdote.
How to boil water in an empty kettle? Fill water, put kettle on a stove.
How to boil water in a full kettle? Pour out water to reduce the problem to the previous one.
How in earth does it matter whether something is mounted on the same directory before or after chroot?
You’re the expert of experts here. Does it, or not? I have little experience with bind mounting outside the context of setting up a chroot. I can’t think of a reason it can’t, except in the logic of traditional mounting via fstab, which first mounts root, from which all other mounting follows. I wasn’t claiming anyone wrong, just questioning.
That said, which is easier to remember, determine, or type:
mount /dev/rootdevice /mnt
mount /dev/esp-device /mnt/boot/efi
mount -o bind /dev /mnt/dev
mount -o bind /run /mnt/run
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
chroot /mnt
<ready>
189 characters above, or 162 characters below?:
mount /dev/rootdevice /mnt
mount -o bind /dev /mnt/dev
mount -o bind /run /mnt/run
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys
chroot /mnt
mount -a
<ready>
The bonus with the latter is potentially more readiness when fstab is conformed to. Could there be something relied upon in fstab besides the usual suspects??? It probably has the more reliable UUID or LABEL for the ESP, but what else might there be???
Well, I think this post contains the most important part of this thread.
It says that OP succeeded although he used the set of commands I recommended and which according to yours and @arvidjaar claims can never work.
I can happily accept that my set of commands is wrong but I would like to understand why it still works (for OP and for me).
True, but please also read the way i solved my problem
I used your commands on the old partion, so no chroot.
https://forums.opensuse.org/t/change-boot-partition-in-tumbleweed/165263/20
So you did not use my set of commands but only parts of it and under different circumstances.
That means most of what I said was based on wrong assumptions on my side …
Sorry !