Change boot partition in Tumbleweed

[nietgiftig]

@arvidjaar

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

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.

[susejunky]

@nietgiftig

I have searched the forum for this command but the only result that I get is this topic.

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.

[nietgiftig]

@susejunky

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

[nrickert]

@susejunky

So mount -o bind /sys /mnt/p5/sys will not suffice?

In my experience, that has been sufficient.

[arvidjaar]

@susejunky

So mount -o bind /sys /mnt/p5/sys will not suffice?

No. This is separate filesystem. Alternative is to use mount --rbind.

[arvidjaar]

@nrickert

In my experience, that has been sufficient.

Reinstalling grub after losing dual boot

Well, you obviously have to use the same names that are listed in your /etc/fstab or mount them manually. Yes, you need additionally bind-mount /sys/firmware/efi/efivars. Instructions that you were following are long outdated.

[karlmistelberger]

@nrickert

In my experience, that has been sufficient.

It was sufficient. But that changed: Grub – EFI – Btrfs | Karl Mistelberger

[mrmazda]

@susejunky

mkdir /mnt/p5
mount /dev/nvme0n1p5 /mnt/p5
mount /dev/nvme0n1p1 /mnt/p5/boot/efi
mount -o bind /dev /mnt/p5/dev
mount -o bind /sys /mnt/p5/sys
mount -o bind /run /mnt/p5/run
mount -o bind /proc /mnt/p5/proc
chroot /mnt/p5
grub2-install
grub2-mkconfig -o /boot/grub2/grub.cfg
exit

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.

[susejunky]

@mrmazda

Have you ever succeeded doing this on a UEFI/GPT installation?

You may want to read all posts in this thread thoroughly to find the answer (and even more) …

@mrmazda

… I don’t see anything in that list that gets the ESP mounted before Grub is updated

What about mount /dev/nvme0n1p1 /mnt/p5/boot/efi (command number three)?

@mrmazda

… 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.

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.

[mrmazda]

@susejunky

@mrmazda

Have you ever succeeded doing this on a UEFI/GPT installation?

You may want to read all posts in this thread thoroughly to find the answer

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.

(and even more) …

More what?

@mrmazda

… I don’t see anything in that list that gets the ESP mounted before Grub is updated

What about mount /dev/nvme0n1p1 /mnt/p5/boot/efi (command number three)?

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.

@mrmazda

… 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.

I know about the GRUB_DISTRIBUTOR= trick (and even use it on some of my systems).

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/.

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.

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.

[arvidjaar]

@mrmazda

I’d never seen a recommendation to mount the ESP partition prior to the chroot

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?

[mrmazda]

@arvidjaar

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???

[susejunky]

@mrmazda

More what?

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).

[nietgiftig]

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

[susejunky]

@nietgiftig

I used your commands on the old partion, so no chroot.

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 !