On 27/10/2020 16:30, Felix Miata wrote:

Robin Klitscher composed on 2020-10-27 13:56 (UTC+1300): ...

Knowing each of the following inputs & their outputs run while booted to the working Leap will help us help you:

1-content of /etc/fstab on all three installations 2-parted -l 3-blkid

These should not be allowed to wrap. If you can't prevent wrapping in the reply, instead upload to https://susepaste.org/ and provide the URL(s) in reply here. You may also try using the susepaste command, which commonly reports upload failed and yet if you goto https://susepaste.org/lists in web browser you might find that the attempt(s) actually succeeded. If susepaste.org completely fails you try https://pastebin.com/ or one of a number of alternate services intended for temporary text file sharing that does not depend on scripting or login by those wishing to view uploads.

Thanks for your reply. For the fstab info below, Leap 15.2-1 is the installation that's working; Leap 15.2-2 and Tumbleweed are not. /vms at /dev/sda1 is the partition I deleted and rebuilt.

fstab Leap 15.2-1:

UUID=84a01450-8779-44a3-9be6-73e0b1f4de6d / ext4 defaults 0 1 UUID=e6d79374-c1e0-4d51-8bfe-076b0c1ab592 /avstuff ext4 data=ordered 0 2 UUID=84168ba6-727d-4751-8cc3-8570e5999d40 /vms ext4 data=ordered 0 2 UUID=028e6f21-13ae-47ca-b895-e0f3a7231ed1 /home ext4 data=ordered 0 2 UUID=5a691959-e8b4-4908-bf6a-e021d0b88205 /data2 ext4 data=ordered 0 2 UUID=60f0cb8e-d2dc-465d-80c7-43889088a341 /data1 ext4 data=ordered 0 2 UUID=4D62-1AA8 /boot/efi vfat defaults 0 2

fstab Leap 15.2-2

UUID=4e4aacff-8ee7-496f-98d1-2e2451c5e986 / ext4 defaults 0 1 UUID=e6d79374-c1e0-4d51-8bfe-076b0c1ab592 /avstuff ext4 data=ordered 0 2 UUID=47b7e31e-cbc4-4597-8bee-1ce39ee7f9dc /vms ext4 data=ordered 0 2 UUID=5c5d12a4-d148-4b54-8d1d-c1c4b00afb82 /home ext4 data=ordered 0 2 UUID=5a691959-e8b4-4908-bf6a-e021d0b88205 /data2 ext4 data=ordered 0 2 UUID=60f0cb8e-d2dc-465d-80c7-43889088a341 /data1 ext4 data=ordered 0 2 UUID=0908-2851 /boot/efi vfat defaults 0 2

fstab Tumbleweed

UUID=480fb714-3c98-41a1-9ad8-2c1bf006c9df / ext4 defaults 0 1 UUID=e6d79374-c1e0-4d51-8bfe-076b0c1ab592 /avstuff ext4 data=ordered 0 2 UUID=47b7e31e-cbc4-4597-8bee-1ce39ee7f9dc /vms ext4 data=ordered 0 2 UUID=53c9e18d-c164-435f-a0bc-549b89395d6d /home ext4 data=ordered 0 2 UUID=5a691959-e8b4-4908-bf6a-e021d0b88205 /data2 ext4 data=ordered 0 2 UUID=60f0cb8e-d2dc-465d-80c7-43889088a341 /data1 ext4 data=ordered 0 2 UUID=0908-2851 /boot/efi vfat utf8 0 2

and here is parted -l:

parted -l:

Model: ATA Samsung SSD 860 (scsi) Disk /dev/sda: 500GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags:

Number Start End Size File system Name Flags 1 1049kB 500GB 500GB ext4

Model: NVMe Device (nvme) Disk /dev/nvme0n1: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags:

Number Start End Size File system Name Flags 1 1049kB 525MB 524MB fat16 boot, esp 2 525MB 54.2GB 53.7GB ext4 3 54.2GB 269GB 215GB ext4 4 269GB 537GB 268GB ext4 5 537GB 913GB 376GB ext4

Model: NVMe Device (nvme) Disk /dev/nvme1n1: 1000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags:

Number Start End Size File system Name Flags 1 1049kB 8591MB 8590MB linux-swap(v1) swap 2 8591MB 62.3GB 53.7GB ext4 3 62.3GB 277GB 215GB ext4 4 277GB 331GB 53.7GB ext4 5 331GB 545GB 215GB ext4 6 545GB 760GB 215GB ext4

and blkid (I hope this works re wrapping!):

/dev/sda1: UUID="84168ba6-727d-4751-8cc3-8570e5999d40" TYPE="ext4" PARTUUID="094cbde3-3b3d-43b2-8812-dc03a87a620a" /dev/nvme1n1: PTUUID="b6504902-92d4-4ac9-ae7e-9f715090cfb8" PTTYPE="gpt" /dev/nvme1n1p1: UUID="ab08f233-f5d1-408c-8102-f3b5611b1a36" TYPE="swap" PARTUUID="43d5ee35-9564-4227-8876-74256b7ee3be" /dev/nvme1n1p2: UUID="4e4aacff-8ee7-496f-98d1-2e2451c5e986" TYPE="ext4" PARTUUID="b931e72b-c111-44bf-a1f9-66bdd64d5747" /dev/nvme1n1p3: UUID="5c5d12a4-d148-4b54-8d1d-c1c4b00afb82" TYPE="ext4" PARTUUID="fca57644-f40f-4ffc-84d1-f2a2629dd810" /dev/nvme1n1p4: UUID="480fb714-3c98-41a1-9ad8-2c1bf006c9df" TYPE="ext4" PARTUUID="9cfc0bbc-9fb5-40f0-902d-fce5027f99e5" /dev/nvme1n1p5: UUID="53c9e18d-c164-435f-a0bc-549b89395d6d" TYPE="ext4" PARTUUID="6963981f-762f-4296-ad14-c7e2fe937d21" /dev/nvme1n1p6: UUID="5a691959-e8b4-4908-bf6a-e021d0b88205" TYPE="ext4" PARTUUID="5c432136-96bd-4aa6-a366-454629e685ff" /dev/nvme0n1: PTUUID="7ccdd54c-83ce-48b9-b5c4-bf287d1fe5f6" PTTYPE="gpt" /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="4D62-1AA8" TYPE="vfat" PARTUUID="7ccc1488-b39a-4993-922d-af39e42d8c7c" /dev/nvme0n1p2: UUID="84a01450-8779-44a3-9be6-73e0b1f4de6d" TYPE="ext4" PARTUUID="e21a19fa-74e8-45c9-8d92-3e2d0038f0d2" /dev/nvme0n1p3: UUID="028e6f21-13ae-47ca-b895-e0f3a7231ed1" TYPE="ext4" PARTUUID="c56b077b-1ade-4dc7-b7c1-4b273a94f19f" /dev/nvme0n1p4: UUID="60f0cb8e-d2dc-465d-80c7-43889088a341" TYPE="ext4" PARTUUID="1b57af9d-de15-4ca0-a152-d91af4aba9ac" /dev/nvme0n1p5: UUID="e6d79374-c1e0-4d51-8bfe-076b0c1ab592" TYPE="ext4" PARTUUID="8af24f30-3073-4f78-a89c-b0e0ddaeff8e"

I see there are differences in UUIDs for /dev/sda1 and the efi partition between the working installation and the other two, and assume that's relevant, but just changing the numbers in the appropriate fstab doesn't seem to improve things. Should it have? Cheers -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 27/10/2020 19:52, Felix Miata wrote: ...............

2: Your fstabs for 15.2-2 and TW each point to two different non-existent filesystem IDs, which produces emergency shells. Fix these and you should be good to go on all three.

# fstab Leap 15.2-1 DEVICE UUID=84a01450-8779-44a3-9be6-73e0b1f4de6d / ext4 defaults 0 1 /dev/nvme0n1p2 UUID=e6d79374-c1e0-4d51-8bfe-076b0c1ab592 /avstuff ext4 data=ordered 0 2 /dev/nvme0n1p5 UUID=84168ba6-727d-4751-8cc3-8570e5999d40 /vms ext4 data=ordered 0 2 /dev/sda1 UUID=028e6f21-13ae-47ca-b895-e0f3a7231ed1 /home ext4 data=ordered 0 2 /dev/nvme0n1p3 UUID=5a691959-e8b4-4908-bf6a-e021d0b88205 /data2 ext4 data=ordered 0 2 /dev/nvme1n1p6 UUID=60f0cb8e-d2dc-465d-80c7-43889088a341 /data1 ext4 data=ordered 0 2 /dev/nvme0n1p4 UUID=4D62-1AA8 /boot/efi vfat defaults 0 2 /dev/nvme0n1p1

# fstab Leap 15.2-2 DEVICE UUID=4e4aacff-8ee7-496f-98d1-2e2451c5e986 / ext4 defaults 0 1 /dev/nvme1n1p2 UUID=e6d79374-c1e0-4d51-8bfe-076b0c1ab592 /avstuff ext4 data=ordered 0 2 /dev/nvme0n1p5 UUID=47b7e31e-cbc4-4597-8bee-1ce39ee7f9dc /vms ext4 data=ordered 0 2 MISSING UUID=5c5d12a4-d148-4b54-8d1d-c1c4b00afb82 /home ext4 data=ordered 0 2 /dev/nvme1n1p3 UUID=5a691959-e8b4-4908-bf6a-e021d0b88205 /data2 ext4 data=ordered 0 2 /dev/nvme1n1p6 UUID=60f0cb8e-d2dc-465d-80c7-43889088a341 /data1 ext4 data=ordered 0 2 /dev/nvme0n1p4 UUID=0908-2851 /boot/efi vfat defaults 0 2 MISSING

# fstab Tumbleweed DEVICE UUID=480fb714-3c98-41a1-9ad8-2c1bf006c9df / ext4 defaults 0 1 /dev/nvme1n1p4 UUID=e6d79374-c1e0-4d51-8bfe-076b0c1ab592 /avstuff ext4 data=ordered 0 2 /dev/nvme0n1p5 UUID=47b7e31e-cbc4-4597-8bee-1ce39ee7f9dc /vms ext4 data=ordered 0 2 MISSING UUID=53c9e18d-c164-435f-a0bc-549b89395d6d /home ext4 data=ordered 0 2 /dev/nvme1n1p5 UUID=5a691959-e8b4-4908-bf6a-e021d0b88205 /data2 ext4 data=ordered 0 2 /dev/nvme1n1p6 UUID=60f0cb8e-d2dc-465d-80c7-43889088a341 /data1 ext4 data=ordered 0 2 /dev/nvme0n1p4 UUID=0908-2851 /boot/efi vfat utf8 0 2 MISSING

OK; I've changed the UUIDs for the "missing" filesystems for /vms and /boot.efi in the fstab files for Leap 15.2-2 and Tumbleweed to the ones in the fstab for the working Leap 15.2-1. Unfortunately that did not improve the situation, so there must be something else in play as well. But I've no idea where to look. -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 28/10/2020 18:56, Andrei Borzenkov wrote: ....................................

Boot into emergency mode, dump journal:

journalctl -b > journal.out

then mount your root file system from working instance and upload resulting file together with modified /etc/fstab.

journalctl.out and modfied fstab attached. Regards -- Robin K Wellington "Harbour City" New Zealand

On 29/10/2020 00:18, Carlos E. R. wrote:

On 28/10/2020 10.41, Robin Klitscher wrote:

...

On 28/10/2020 18:56, Andrei Borzenkov wrote:

....................................

...

Boot into emergency mode, dump journal:

journalctl -b > journal.out

then mount your root file system from working instance and upload resulting file together with modified /etc/fstab.

journalctl.out and modfied fstab attached.

Huh. Forgot to say, that when a file is large, such as the journal, the netiquette says to upload it somewhere instead of attaching, like to susepaste.org

Yes; I know that; and I hang my head in shame for not complying. -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 29/10/2020 06:56, Andrei Borzenkov wrote:

28.10.2020 12:41, Robin Klitscher пишет:

...

On 28/10/2020 18:56, Andrei Borzenkov wrote:

....................................

...

Boot into emergency mode, dump journal:

journalctl -b > journal.out

then mount your root file system from working instance and upload resulting file together with modified /etc/fstab.

journalctl.out and modfied fstab attached.

Oh! It does stop in dracut (although I am still surprised it asks for password) and the reason is indeed that dracut adds ESP as required for booting. You can verify it with

1. Mount partition containing /boot of installation that fails to boot 2. Use command

lsinitrd <mountpoint>/boot/initrd | grep initqueue/finished

I expect to see one line for device containing /boot/efi with old, no more valid, UUID.

That was completely new to me. And yes, this means you need to regenerate initrd if ESP is reformatted.

Here's the output of lsinitrd on one of the broken systems as you suggest above:

lsinitrd /mnt/boot/initrd | grep initqueue/finished drwxr-xr-x 2 root root 0 Oct 21 09:57 lib/dracut/hooks/initqueue/finished -rw-r--r-- 1 root root 37 Oct 21 09:57 lib/dracut/hooks/initqueue/finished/devexists-\\x2fdev\\x2fdisk\\x2fby-uuid\\x2f0908-2851.sh

... and that last part after the double \ does indeed reference UUID 0908-2851, which no longer exists, so you are right. In the running system it's 4D62-1AA8 for the ESP - confirmed by issuing the same lsinitrd command against the running system's /boot/initrd. How that error came about is another matter. But a lesson may be that those who don't fully understand what they're doing should not ignore warning messages. When I was booted externally to Parted Magic and mistakenly deleted and remade the partition /dev/sda1, I thought nothing of the ensuing message that the kernel had not been informed. Mea culpa. Meantime I'll try my hand at a chroot and mkinitrd. -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 29/10/2020 10:32, Robin Klitscher wrote:

Meantime I'll try my hand at a chroot and mkinitrd.

It worked! Happy, happy, happy!!!! Thank you Andrei and Carlos for your help in digging me out of a hole I'd made for myself. Much appreciated. Carlos, I'll think for a bit on your further recommendations, in the context of preventing recurrence - an "abundance of caution" as they say. Regards, Robin -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 29/10/2020 11:52, Carlos E. R. wrote:

On 28/10/2020 23.21, Robin Klitscher wrote:

...

On 29/10/2020 10:32, Robin Klitscher wrote:

...

Meantime I'll try my hand at a chroot and mkinitrd.

It worked!  Happy, happy, happy!!!!

Thank you Andrei and Carlos for your help in digging me out of a hole I'd made for myself.  Much appreciated.

Carlos, I'll think for a bit on your further recommendations, in the context of preventing recurrence - an "abundance of caution" as they say.

If you do "ls /boot/efi/EFI/" you should get three directories, besides "boot" or "opensuse". If you don't, you still have work to do.

Telcontar:~ # ls /boot/efi/EFI/ auxiliary  boot  main-os Telcontar:~ #

I get this: robin@Corgi:~> ls /boot/efi/EFI boot opensuse -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 29/10/2020 14:50, Carlos E. R. wrote:

On 29/10/2020 00.35, Robin Klitscher wrote:

...

On 29/10/2020 11:52, Carlos E. R. wrote:

...

On 28/10/2020 23.21, Robin Klitscher wrote:

...

On 29/10/2020 10:32, Robin Klitscher wrote:

...

Meantime I'll try my hand at a chroot and mkinitrd.

It worked!  Happy, happy, happy!!!!

Thank you Andrei and Carlos for your help in digging me out of a hole I'd made for myself.  Much appreciated.

Carlos, I'll think for a bit on your further recommendations, in the context of preventing recurrence - an "abundance of caution" as they say.

If you do "ls /boot/efi/EFI/" you should get three directories, besides "boot" or "opensuse". If you don't, you still have work to do.

Telcontar:~ # ls /boot/efi/EFI/ auxiliary  boot  main-os Telcontar:~ #

I get this:

robin@Corgi:~> ls /boot/efi/EFI boot  opensuse

Which means that you did not correct the ESP problem.

You have to do the procedure I described.

I'll get around to it shortly - but why is it necessary to do this by hand? Not everybody has multi-boot setups of course. But there must be a reason why the arrangement is not offered as an option on installation, or even as a default? -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Le 29/10/2020 à 09:49, Carlos E. R. a écrit :

1) Change "GRUB_DISTRIBUTOR=..." to something different on every installation.

but be warned that the EFI partition is sometime very small and can get filled with old installs... AFAIR you can also *copy* the EFI openSUSE entry to an other name before the new install to avoid collision the only true solution would be add an EFI edit menu in the yast install jdd -- http://dodin.org -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Thu 29 Oct 2020 12:58:12 PM CDT, Felix Miata wrote:

jdd composed on 2020-10-29 10:07 (UTC+0100):

...

but be warned that the EFI partition is sometime very small and can get filled with old installs...

I seriously doubt anyone with less than 15 installations could fill up even a 100M ESP:

<snip>

Extrapolated it would take around 75 installations to fill a 500M ESP.

Hi Some users may have additional Hardware manufacturer tools installed, eg HP for BIOS updates direct, BIOS backup, efi shell (non secure boot) but even then I've found 260MB seems to work fine. -- Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890) Tumbleweed 20201026 | GNOME Shell 3.36.7 | 5.9.1-1-default Intel DQ77MK MB | Xeon E3-1245 V2 X8 @ 3.40 GHz | Intel/Nvidia up 1:14, 2 users, load average: 0.14, 0.24, 0.42 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 30/10/2020 23.02, Robin Klitscher wrote:

On 29/10/2020 21:49, Carlos E. R. wrote:

..............................................

...

So:

1) Change "GRUB_DISTRIBUTOR=..." to something different on every installation. 2) Force YaST bootloader module to write ALL the files again, on every install. And the trick to do this is changing one second the timeout.

Why changing the timeout does the trick I do not know, but it does the trick. It does need to be so for grub files, but not for ESP files. They could add a tick to force write of all files instead, but...

And the trick to do it on each of your systems is the mount bind and chroot I described - otherwise, you have to boot each of them and run yast as described. Whatever is easier for you.

OK; I finally got around to trying the procedure you outlined, booted to my Leap 15.2-1 installation and mounting, binding and chroot-ing into the others. All went well for the booted system, but in chroot to the others I got an error output "No valid EFI partition". So I backed out by undoing all that I'd done so far.

You missed the step to mount it. You have to mount the root and the EFI to their *relative* places: [root] |--[/boot/efi] | \----/opensuse | |--[/home] | +--[/mnt] | |\ | | -[other root] | | |\ | | | \-"/boot" | | | \___[another EFI] <====== | | | | | \--[another /home] | | | \--[ 3rd root]] Example: md /mnt md /mnt/leap152 mount /dev/disk/by-uuid/4e4aacff-8ee7-496f-98d1-2e2451c5e986 /mnt/leap152 mount --bind /boot/efi /mnt/leap152/boot/efi # <====== you missed this step, or equivalent. mount --bind /proc /mnt/leap152/proc mount --bind /sys /mnt/leap152/sys mount --bind /dev /mnt/leap152/dev chroot /mnt/leap152/ joe /etc/default/grub # <=== if you did not do it before. Or any other editor you like. yast

Can I safely assume there's no hidden surprise in the alternative you suggest? That is, doing the yast trick for each of the installations while booted to each one individually? I'm just a bit cautious about ending up with an unbootable mess (again).

You missed this part in my instructions: CER> Then, you have to mount ALL the partitions of Leap 15.2-2 under, say, /mnt/leap152, Strictly speaking, not all partitions are needed, but root and efi (you do not have a separate /boot) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 31/10/2020 04.01, Robin Klitscher wrote:

On 31/10/2020 13:20, Carlos E. R. wrote:

...

On 30/10/2020 23.02, Robin Klitscher wrote:

...

On 29/10/2020 21:49, Carlos E. R. wrote:

...............................

...

You missed this part in my instructions:

CER> Then, you have to mount ALL the partitions of Leap 15.2-2 under, say, /mnt/leap152,

Strictly speaking, not all partitions are needed, but root and efi (you do not have a separate /boot)

Thank you for your patience. It worked. My cup runneth over ...

(The part about binding the /boot/efi partition in particular wasn't explicit in your earlier guidance, but I should have worked out the need anyway. Sometimes I'm a bit slow. Thanks again.)

Welcome. Yes, it wasn't explicit. The procedure is more complex to explain than to do, so I shortened the text... -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 29/10/2020 18:37, Andrei Borzenkov wrote:

29.10.2020 00:32, Robin Klitscher пишет:

...

How that error came about is another matter.

When you reinstalled one openSUSE instance it formatted ESP. You could have avoided it by telling installer to not do it. Or you could ask immediately when you deleted partition/filesystem and do not encounter this issue in the first place.

That's certainly a credible explanation and good advice; and I'll watch out for the trap in the future. But, on its own, it doesn't quite take account of the fact that I reinstalled one of the systems because *none* of the three were working. Which is to say that the fault existed *before* any re-installation exposed the ESP to re-format. So part of the mystery remains ..... -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 29/10/2020 21:38, Andrei Borzenkov wrote:

On Thu, Oct 29, 2020 at 10:06 AM Robin Klitscher wrote:

...

But, on its own, it doesn't quite take account of the fact that I reinstalled one of the systems because *none* of the three were working. Which is to say that the fault existed *before* any re-installation exposed the ESP to re-format. So part of the mystery remains .....

That was due to changed UUID on one of filesystem in /etc/fstab (/vms ) that you deleted and then created again. Again. you could have avoided this issue by giving it the same UUID as before.

Thank you. Quite so; I can see that now, but didn't at the time.

Actually it likely was enough to simply create this partition again with exact start and size.

Ah - I didn't know that either. Wish I had. An additional problem that I haven't mentioned so far was that restoring the contents of the (deleted) partition from a Clonezilla image wouldn't start because Clonezilla said the target partition was smaller than the original source, and that to proceed was "dangerous". So I didn't, resorting instead to restoring the contents piecemeal - or most of it - from raw backup scraps. -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 27/10/2020 06.13, Robin Klitscher wrote:

On 27/10/2020 16:30, Felix Miata wrote:

...

Robin Klitscher composed on 2020-10-27 13:56 (UTC+1300): ...

Knowing each of the following inputs & their outputs run while booted to the working Leap will help us help you:

1-content of /etc/fstab on all three installations 2-parted -l 3-blkid

These should not be allowed to wrap. If you can't prevent wrapping in the reply, instead upload to https://susepaste.org/ and provide the URL(s) in reply here. You may also try using the susepaste command, which commonly reports upload failed and yet if you goto https://susepaste.org/lists in web browser you might find that the attempt(s) actually succeeded. If susepaste.org completely fails you try https://pastebin.com/ or one of a number of alternate services intended for temporary text file sharing that does not depend on scripting or login by those wishing to view uploads.

Or just attach to the email: parted -l > outputofparted.txt and attach outputofparted.txt. same with the other operations.

Thanks for your reply. For the fstab info below, Leap 15.2-1 is the installation that's working; Leap 15.2-2 and Tumbleweed are not. /vms at /dev/sda1 is the partition I deleted and rebuilt.

...

fstab Leap 15.2-1:

UUID=84a01450-8779-44a3-9be6-73e0b1f4de6d / ext4 defaults 0 1 UUID=e6d79374-c1e0-4d51-8bfe-076b0c1ab592 /avstuff ext4 data=ordered 0 2 UUID=84168ba6-727d-4751-8cc3-8570e5999d40 /vms ext4 data=ordered 0 2 UUID=028e6f21-13ae-47ca-b895-e0f3a7231ed1 /home ext4 data=ordered 0 2 UUID=5a691959-e8b4-4908-bf6a-e021d0b88205 /data2 ext4 data=ordered 0 2 UUID=60f0cb8e-d2dc-465d-80c7-43889088a341 /data1 ext4 data=ordered 0 2 UUID=4D62-1AA8 /boot/efi vfat defaults 0 2

All in disk /dev/nvme0n1

...

fstab Leap 15.2-2

UUID=4e4aacff-8ee7-496f-98d1-2e2451c5e986 / ext4 defaults 0 1 UUID=e6d79374-c1e0-4d51-8bfe-076b0c1ab592 /avstuff ext4 data=ordered 0 2 UUID=47b7e31e-cbc4-4597-8bee-1ce39ee7f9dc /vms ext4 data=ordered 0 2 --> Does not exist (2)

...

UUID=5c5d12a4-d148-4b54-8d1d-c1c4b00afb82 /home ext4 data=ordered 0 2 UUID=5a691959-e8b4-4908-bf6a-e021d0b88205 /data2 ext4 data=ordered 0 2 UUID=60f0cb8e-d2dc-465d-80c7-43889088a341 /data1 ext4 data=ordered 0 2 UUID=0908-2851 /boot/efi vfat defaults 0 2 --> Does not exist. (1)

fstab Tumbleweed

UUID=480fb714-3c98-41a1-9ad8-2c1bf006c9df / ext4 defaults 0 1 UUID=e6d79374-c1e0-4d51-8bfe-076b0c1ab592 /avstuff ext4 data=ordered 0 2 UUID=47b7e31e-cbc4-4597-8bee-1ce39ee7f9dc /vms ext4 data=ordered 0 2 --> Does not exist (2) UUID=53c9e18d-c164-435f-a0bc-549b89395d6d /home ext4 data=ordered 0 2 UUID=5a691959-e8b4-4908-bf6a-e021d0b88205 /data2 ext4 data=ordered 0 2 UUID=60f0cb8e-d2dc-465d-80c7-43889088a341 /data1 ext4 data=ordered 0 2 UUID=0908-2851 /boot/efi vfat utf8 0 2 --> Does not exist. (1)

Note 1: As /boot/efi points to the same (not existing) partition, you have to make sure that in file "/etc/default/grub" the line GRUB_DISTRIBUTOR="whatever" is different for each. Note 2: as you rebuilt that partition on sda, you probably have to point to it on all systems. You have to correct those two errors, and probably run "mkinitrd" on the two failing systems. Huh, not enough, you need rebuild EFI as well. See later. ....

and blkid (I hope this works re wrapping!):

It did. /dev/sda

...

/dev/sda1: UUID="84168ba6-727d-4751-8cc3-8570e5999d40" TYPE="ext4" PARTUUID="094cbde3-3b3d-43b2-8812-dc03a87a620a" --> /vms of Leap 15.2-1

/dev/nvme 1 TB

...

/dev/nvme1n1: PTUUID="b6504902-92d4-4ac9-ae7e-9f715090cfb8" PTTYPE="gpt" /dev/nvme1n1p1: UUID="ab08f233-f5d1-408c-8102-f3b5611b1a36" TYPE="swap" PARTUUID="43d5ee35-9564-4227-8876-74256b7ee3be" /dev/nvme1n1p2: UUID="4e4aacff-8ee7-496f-98d1-2e2451c5e986" TYPE="ext4" PARTUUID="b931e72b-c111-44bf-a1f9-66bdd64d5747" --> / of Leap 15.2-2 /dev/nvme1n1p3: UUID="5c5d12a4-d148-4b54-8d1d-c1c4b00afb82" TYPE="ext4" PARTUUID="fca57644-f40f-4ffc-84d1-f2a2629dd810" --> home of Leap 15.2-2 /dev/nvme1n1p4: UUID="480fb714-3c98-41a1-9ad8-2c1bf006c9df" TYPE="ext4" PARTUUID="9cfc0bbc-9fb5-40f0-902d-fce5027f99e5" --> / of TW /dev/nvme1n1p5: UUID="53c9e18d-c164-435f-a0bc-549b89395d6d" TYPE="ext4" PARTUUID="6963981f-762f-4296-ad14-c7e2fe937d21" --> /home of TW /dev/nvme1n1p6: UUID="5a691959-e8b4-4908-bf6a-e021d0b88205" TYPE="ext4" PARTUUID="5c432136-96bd-4aa6-a366-454629e685ff" --> /data2

/dev/nvme 1 TB

...

/dev/nvme0n1: PTUUID="7ccdd54c-83ce-48b9-b5c4-bf287d1fe5f6" PTTYPE="gpt" /dev/nvme0n1p1: SEC_TYPE="msdos" UUID="4D62-1AA8" TYPE="vfat" PARTUUID="7ccc1488-b39a-4993-922d-af39e42d8c7c" --> /boot/efi of Leap 15.2-1 /dev/nvme0n1p2: UUID="84a01450-8779-44a3-9be6-73e0b1f4de6d" TYPE="ext4" PARTUUID="e21a19fa-74e8-45c9-8d92-3e2d0038f0d2" --> / of Leap 15.2-1 /dev/nvme0n1p3: UUID="028e6f21-13ae-47ca-b895-e0f3a7231ed1" TYPE="ext4" PARTUUID="c56b077b-1ade-4dc7-b7c1-4b273a94f19f" --> /home of Leap 15.2-1 /dev/nvme0n1p4: UUID="60f0cb8e-d2dc-465d-80c7-43889088a341" TYPE="ext4" PARTUUID="1b57af9d-de15-4ca0-a152-d91af4aba9ac" --> /data1 /dev/nvme0n1p5: UUID="e6d79374-c1e0-4d51-8bfe-076b0c1ab592" TYPE="ext4" PARTUUID="8af24f30-3073-4f78-a89c-b0e0ddaeff8e" --> /avstuff

I see there are differences in UUIDs for /dev/sda1 and the efi partition between the working installation and the other two, and assume that's relevant, but just changing the numbers in the appropriate fstab doesn't seem to improve things. Should it have?

Nope... (change the names below to your liking) Ok boot the one system that works. Then, you have to mount ALL the partitions of Leap 15.2-2 under, say, /mnt/leap152, and those of TW under, say, /mnt/tw. Edit on /etc/default/grub: GRUB_DISTRIBUTOR="Leap 15.2-1" Edit on /mnt/leap152/etc/default/grub: GRUB_DISTRIBUTOR="Leap 15.2-2" Edit on /mnt/tw/etc/default/grub: GRUB_DISTRIBUTOR="TW" Then you have to do (as root in a terminal): yast You will get to YaST in text mode. Do not try to use the GUI version (it will not work with the other two chroot operations later). Move with the tab key, or use the highlighted letter (with Alt). Go to "System/Boot Loader" module, then to the "Bootloader Options" tab. Then change the number of seconds in "Timeout in Seconds" by one up or down. Then push the Ok button to apply the changes. Changing the seconds is a trick that forces YaST to write it all again to disk. mount --bind /proc /mnt/leap152/proc mount --bind /sys /mnt/leap152/sys mount --bind /dev /mnt/leap152/dev mount --bind /proc /mnt/tw/proc mount --bind /sys /mnt/tw/sys mount --bind /dev /mnt/tw/dev chroot /mnt/leap152/ yast (same as above) exit chroot /mnt/tw/ yast (same as above) exit I hope this is all you need. :-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 28/10/2020 00.58, Robin Klitscher wrote:

On 28/10/2020 11:38, Carlos E. R. wrote:

..............

...

I hope this is all you need. :-)

Thank you muchly for your effort. But just a couple of questions before I take the plunge, if I may.

1. On all three installations the line in etc/default/grub is empty, as in "GRUB_DISTRIBUTOR= ". Since this includes the 15.2-1 installation that works, I wonder if the steps you outline in that regard are strictly required?

Yes. The reason is that each openSUSE install writes to "/boot/efi/EFI/opensuse/", and you have normally only one such partition, thus 3 installs writing to the same directory. Result: only the last one boots. You may have one install on a different disk, but still the safe thing is 3 different names. The default name is "opensuse", but you create a different name with "GRUB_DISTRIBUTOR=..." Oh, and some bioses do not accept any char in there, so avoid spaces and fancy chars. One of my machines does not accept '_' or '-', I don't remember which. Plus, if you install fresh another openSUSE (or reinstall any of them), it will overwrite "/boot/efi/EFI/opensuse/"... so better never use "GRUB_DISTRIBUTOR=", but write something different there.

2. I note when booted to the 15.2-1 installation that works that the mounted /boot/efi folder contains subfolders /EFI/boot and EFI/opensuse, each with files within.

Yes.

In each of the inactive 15.2-2 and TW root folders, however, there's nothing at all below /boot/efi. Is this relevant to the problem, or are such subfolders and files regenerated on booting into the system concerned?

Yes, that's part of the problem. I think that the yast step recreates those directories. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 28/10/2020 17:10, Felix Miata wrote:

Robin Klitscher composed on 2020-10-28 12:58 (UTC+1300):

...

1. On all three installations the line in etc/default/grub is empty, as in "GRUB_DISTRIBUTOR= ". Since this includes the 15.2-1 installation that works, I wonder if the steps you outline in that regard are strictly required?

By default, "GRUB_DISTRIBUTOR= " translates to /boot/efi/EFI/opensuse. Last installation to write it wins control of the post-Grub boot process.

All mine get a unique one first thing after installation, or even before if I'm particularly ambitious, with the result that I can safely delete any "opensuse" directory on the ESP filesystem. Mine unambiguously include opensusetw, opensuse423, opensuse150, opensuse151, opensuse152, fedora32, fedora33, debian10 and debian11, so none overwrite others, and with mounting the ESP partition *only* to the installation I wish to control booting as I do, booting never gets broken unless I screw something up myself, or forget first thing with a new installation to undo. I usually don't need to undo it, as I usually remember to taboo Grub installation unless it's the first on a new ESP.

Thank you; you're 'way ahead of me! But from what you say, in a multi-boot scenario the running system has indeed written to the ESP. What I don't get is that although I can see and enter the folders and files below /boot/efi from the running system, those same sub-folders and files don't exist in a backup of the root filesystem done with Grsync using full superuser rights and all the other capabilities that Grsync offers. Curious. -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 28/10/2020 05.54, Robin Klitscher wrote:

On 28/10/2020 17:10, Felix Miata wrote:

...

Robin Klitscher composed on 2020-10-28 12:58 (UTC+1300):

...

1. On all three installations the line in etc/default/grub is empty, as in "GRUB_DISTRIBUTOR= ". Since this includes the 15.2-1 installation that works, I wonder if the steps you outline in that regard are strictly required?

By default, "GRUB_DISTRIBUTOR= " translates to /boot/efi/EFI/opensuse. Last installation to write it wins control of the post-Grub boot process.

All mine get a unique one first thing after installation, or even before if I'm particularly ambitious, with the result that I can safely delete any "opensuse" directory on the ESP filesystem. Mine unambiguously include opensusetw, opensuse423, opensuse150, opensuse151, opensuse152, fedora32, fedora33, debian10 and debian11, so none overwrite others, and with mounting the ESP partition *only* to the installation I wish to control booting as I do, booting never gets broken unless I screw something up myself, or forget first thing with a new installation to undo. I usually don't need to undo it, as I usually remember to taboo Grub installation unless it's the first on a new ESP.

Some updates do write to that partition. Happened to me few months back, wrote to the wrong place, and got "error: symbol `grub_calloc' not found", "Entering rescue mode".

...

Thank you; you're 'way ahead of me!

But from what you say, in a multi-boot scenario the running system has indeed written to the ESP. What I don't get is that although I can see and enter the folders and files below /boot/efi from the running system, those same sub-folders and files don't exist in a backup of the root filesystem done with Grsync using full superuser rights and all the other capabilities that Grsync offers. Curious.

Maybe because that partition doesn't need to be mounted while the system is running, and then you don't see it. And maybe because all had the same name and thus the last one installed overwrote the others, and then there was only one. In the setup you posted, the partition pointed by the two non working did not exist, so there was something weird going on. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 10/28/20 7:00 AM, Carlos E. R. wrote:

On 28/10/2020 05.54, Robin Klitscher wrote:

...

On 28/10/2020 17:10, Felix Miata wrote:

...

Robin Klitscher composed on 2020-10-28 12:58 (UTC+1300):

...

1.    On all three installations the line in etc/default/grub is empty, as in "GRUB_DISTRIBUTOR= ". Since this includes the 15.2-1 installation that works, I wonder if the steps you outline in that regard are strictly required?

By default, "GRUB_DISTRIBUTOR= " translates to /boot/efi/EFI/opensuse. Last installation to write it wins control of the post-Grub boot process.

All mine get a unique one first thing after installation, or even before if I'm particularly ambitious, with the result that I can safely delete any "opensuse" directory on the ESP filesystem. Mine unambiguously include opensusetw, opensuse423, opensuse150, opensuse151, opensuse152, fedora32, fedora33, debian10 and debian11, so none overwrite others, and with mounting the ESP partition *only* to the installation I wish to control booting as I do, booting never gets broken unless I screw something up myself, or forget first thing with a new installation to undo. I usually don't need to undo it, as I usually remember to taboo Grub installation unless it's the first on a new ESP.

Some updates do write to that partition. Happened to me few months back, wrote to the wrong place, and got "error: symbol `grub_calloc' not found", "Entering rescue mode".

...

...

Thank you; you're 'way ahead of me!

But from what you say, in a multi-boot scenario the running system has indeed written to the ESP.  What I don't get is that although I can see and enter the folders and files below /boot/efi from the running system, those same sub-folders and files don't exist in a backup of the root filesystem done with Grsync using full superuser rights and all the other capabilities that Grsync offers.  Curious.

Maybe because that partition doesn't need to be mounted while the system is running, and then you don't see it. And maybe because all had the same name and thus the last one installed overwrote the others, and then there was only one.

In the setup you posted, the partition pointed by the two non working did not exist, so there was something weird going on.

It seems that the hurdles here are fundamentally due to sharing a single /boot/efi partition across 3 installations.  Is that really needed??? Just fwiw, seeing how far along you are with your current approach, its worth considering that it might be easier to use a separate /boot/efi for each install, using one grub as the master which chainloads the other two or alternatively using the bios boot selection feature (if the machine supports that) to choose which install to boot.  I use both, i.e., ordinarily chainloading from the master while having the bios boot as a backup. Re "something weird going on":  The TW and -2 fstab files point to two partitions that no longer exist, yet the partition /dev/nvme1n1p1 (which now holds swap) is not included.  (A good guess would be that this first partition is where the missing UUID=0908-2851 for /boot/efi was located.)  In any event, two corrupted fstab's are not the result of only a "data partition" having been deleted (per the original post).  Suggests that partition changes are being made from within one install that affects the other install(s), or that an outside tool is being used.  Begs the question, what is OP using Parted Magic/gparted for and why? --dg -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

enhancement request bug report filed 27 months ago: https://bugzilla.opensuse.org/show_bug.cgi?id=1101756 enable specification of custom GRUB_DISTRIBUTOR= in UEFI bootloader installation Perhaps some additional CCs or comments would spur developer activity. 15.3 development is about to start officially. -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Andrei Borzenkov composed on 2020-10-29 21:31 (UTC+0300):

Felix Miata composed:

...

enhancement request bug report filed 27 months ago:

commit d9e4f8e598c069c35b13084e1289be33a482ce27 Author: Josef Reidinger Date: Thu Sep 10 09:11:08 2015 +0200

remove distributor entry from ui

Please describe how to access that commit.

...

https://bugzilla.opensuse.org/show_bug.cgi?id=1101756 enable specification of custom GRUB_DISTRIBUTOR= in UEFI bootloader installation

...

Perhaps some additional CCs or comments would spur developer activity. 15.3 development is about to start officially.-- Evolution as taught in public schools, like religion, is based on faith, not on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 28/10/2020 18:55, Andrei Borzenkov wrote:

28.10.2020 02:58, Robin Klitscher пишет:

...

.............................

...

2. I note when booted to the 15.2-1 installation that works that the mounted /boot/efi folder contains subfolders /EFI/boot and EFI/opensuse, each with files within. In each of the inactive 15.2-2 and TW root folders, however, there's nothing at all below /boot/efi. Is this

Do you know what "mount point", "mounted file system" in Linux/Unix is?

.............................. I thought I did. The thing is that in /boot in my running system I can see a handful of (config) files and two subdirectories, /efi and /grub2. /grub2 contains a few folders and a couple of files. /efi contains another folder named /EFI which itself contains two more folders, /boot and /opensuse. Mounting the root folder of one of the problematic installations from the working installation, I can see under /boot much the same as above - /grub2 and /efi together with a number of config and vmlinuz files, and I can enter the two folders so so I assume the parent is mounted. The /grub2 folder looks much like on the running system as above. But the /efi sub-folder contains nothing. If that means it's not mounted when its parent and companion are, then I have indeed learned something. Regards, -- Robin K Wellington "Harbour City" New Zealand -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Wed, 28 Oct 2020 22:43:31 +1300 Robin Klitscher wrote:

On 28/10/2020 18:55, Andrei Borzenkov wrote:

...

Do you know what "mount point", "mounted file system" in Linux/Unix is? ..............................

I thought I did.

There is a page https://en.opensuse.org/SDB:Basics_of_partitions,_filesystems,_mount_points that explains some of it, and a linked page https://en.opensuse.org/openSUSE:UEFI about the specifics of the particular partitions. Caveat: I haven't looked at the pages in detail, so double-check anything they say before acting on the information :) -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org