Like with every YaST related bug report, please attach the resulting file of the supplied "save_y2logs" script; see also

https://en.opensuse.org/openSUSE:Report_a_YaST_bug#I_reported_a_YaST2_bug,_and_now_I_am_asked_to_"attach_y2logs"_(for_package_installation_also_"libzypp_logging")._What_does_that_mean,_and_how_do_I_do_that?


But I have a hunch what might have happened here:

In recent months, we had a number of cases where the by-id device name of disks were not as stable as they should be; and I see two disks of the same make and model in your hardware list.

Sometimes, hardware makers don't assign a unique serial number to every individual disk during manufacturing, and then it's a matter of coincidence which one of the disks the kernel discovers first, and that one gets a number 00001 appended, and the other one 00002 (or similar).

You can check this with

  ls -l /dev/disk/by-id | grep -v 'part'

This is a known problem, and we are working on it.

On my machine, those device names look like this:

scsi-0ATA_SAMSUNG_HD103SJ_S246JD2Z921828 -> ../../sdb
scsi-0ATA_SAMSUNG_HD103SJ_S246JD2Z921835 -> ../../sda
scsi-0ATA_Samsung_SSD_860_S3YJNX0K873041Y -> ../../sdc

The first two, /dev/sda and /dev/sdb, are rotational disks also of the same make and model. You can see that the long names are different only in the last two digits.

When grub2 is to be installed on /dev/sda1, and after rebooting the kernel changes the order of those disks, it might check /dev/sdb1 instead; and if there is a Windows partition and not the expected EFI system partition, you might just get that error that you saw.

Using /dev/disk/by-id device names, not simple kernel devices like /dev/sda, was a requirement years ago because back then those /dev/sda, /dev/sdb etc. names were even less stable.

We might have to reevaluate that strategy, or even use /dev/disk/by-uuid instead.

See also bug #1210446

Here, I think, the most important part is this (taken from the initial comment):

Error output: /usr/bin/grub2-editenv: error: ../grub-core/kem/fs.c:121:unknown filesystem.

WORKAROUND
In step 2b in "STEPS TO REPRODUCE" when editing each partition, instruct the installer to **format the partition**. The installer will then install GRUB2 EFI and complete installation normally.

And I feel we already had similar bugreport. Assigned to GRUB2 maintainer?

And JFTR bug #1187471 is about something else. Although it also appears on the radar.

Ouch. Yes, you are right: It won't work with an unformatted partition. I overlooked that part.

Dexter, please notice that not formatting the ESP (EFI System Partition) is only an option if you are sure that there already is one with a valid filesystem. If there is nothing yet, it needs to be created first, i.e. formatted.

It should be already VFAT. But I am not sure if it is enough, as ESP requires specific entry in GPT. So it is possible that in this case GUID for partition in GPT is not set to C12A7328-F81F-11D2-BA4B-00A0C93EC93B but to something else. So here my wild guess ( without logs hard to say for sure ) is that premade partitioning does not match EFI requirements.

(In reply to Stefan Hundhammer from comment #2)
> On my machine, those device names look like this:
> 
> scsi-0ATA_SAMSUNG_HD103SJ_S246JD2Z921828 -> ../../sdb
> scsi-0ATA_SAMSUNG_HD103SJ_S246JD2Z921835 -> ../../sda
> scsi-0ATA_Samsung_SSD_860_S3YJNX0K873041Y -> ../../sdc
> 
> The first two, /dev/sda and /dev/sdb, are rotational disks also of the same
> make and model. You can see that the long names are different only in the
> last two digits.

But they do differ. So what exactly is the issue with these by-id links?

> scsi-0ATA_SAMSUNG_HD103SJ_S246JD2Z921828 -> ../../sdb

For ATA devices, the /dev/disk/by-id/ata-* symlink would be preferred over "scsi-0". Example:

ata-WDC_WD5003ABYX-50WERA1_WD-WMAYP2337147 -> ../../sda
scsi-0ATA_WDC_WD5003ABYX-5_WD-WMAYP2337147 -> ../../sda

In my case there's also 

scsi-350014ee0ad9e9909 -> ../../sda
scsi-1ATA_WDC_WD5003ABYX-50WERA1_WD-WMAYP2337147 -> ../../sda
scsi-SATA_WDC_WD5003ABYX-5_WD-WMAYP2337147 -> ../../sda
wwn-0x50014ee0ad9e9909 -> ../../sda

All these, except scsi-S*, would be preferred to scsi-0*.

Note that we want to get rid of the scsi-0 and scsi-S symlinks in the future (https://jira.suse.com/browse/PED-2687)

(In reply to Martin Wilck from comment #8)
> (In reply to Stefan Hundhammer from comment #2)
> > On my machine, those device names look like this:
> > 
> > scsi-0ATA_SAMSUNG_HD103SJ_S246JD2Z921828 -> ../../sdb
> > scsi-0ATA_SAMSUNG_HD103SJ_S246JD2Z921835 -> ../../sda
> > scsi-0ATA_Samsung_SSD_860_S3YJNX0K873041Y -> ../../sdc
> > 
> > The first two, /dev/sda and /dev/sdb, are rotational disks also of the same
> > make and model. You can see that the long names are different only in the
> > last two digits.
> 
> But they do differ. So what exactly is the issue with these by-id links?

That was on my machine, just as an example. It may be different on the bug reporter's machine. We are still waiting for logs.

(In reply to Stefan Hundhammer from comment #1)
> Like with every YaST related bug report, please attach the resulting file of
> the supplied "save_y2logs" script; see also
> 
> https://en.opensuse.org/openSUSE:Report_a_YaST_bug#I_reported_a_YaST2_bug,
> _and_now_I_am_asked_to_"attach_y2logs"_(for_package_installation_also_"libzyp
> p_logging")._What_does_that_mean,_and_how_do_I_do_that?

I will have to do a re-install to obtain yast logs. The system was successfully installed as I stated in the "WORKAROUND" section of my original post. It will be two or three days before I can do so.

As I have never had to obtain yast install logs I am a bit unclear how to obtain them. The link you referenced seems to apply to a system that can boot. However, as GRUB2 EFI is not installed the system cannot boot. The installer issues the two mentioned error dialogs then goes to the reboot system dialog. I assume that the installer is writing logs to RAM disk, so, are volatile (unless they are written to hard disk). It would seem that to obtain the logs I would have to cancel the reboot prompt then copy the log file from RAM disk - is this correct?
 
> But I have a hunch what might have happened here:
> 
> In recent months, we had a number of cases where the by-id device name of
> disks were not as stable as they should be; and I see two disks of the same
> make and model in your hardware list.
> 
> Sometimes, hardware makers don't assign a unique serial number to every
> individual disk during manufacturing, and then it's a matter of coincidence
> which one of the disks the kernel discovers first, and that one gets a
> number 00001 appended, and the other one 00002 (or similar).
> 
> You can check this with
> 
>   ls -l /dev/disk/by-id | grep -v 'part'

Not the problem:

cosmic@peach:~> ls -l /dev/disk/by-id | grep -v 'part'
total 0
lrwxrwxrwx 1 root root  9 May 25 15:09 ata-WDC_WD2003FZEX-00SRLA0_WD-WCC6N24R1751 -> ../../sda
lrwxrwxrwx 1 root root  9 May 25 15:09 ata-WDC_WD2003FZEX-00SRLA0_WD-WCC6NLLRDU25 -> ../../sdb
lrwxrwxrwx 1 root root  9 May 25 15:09 scsi-0ATA_WDC_WD2003FZEX-0_WD-WCC6N24R1751 -> ../../sda
lrwxrwxrwx 1 root root  9 May 25 15:09 scsi-0ATA_WDC_WD2003FZEX-0_WD-WCC6NLLRDU25 -> ../../sdb
lrwxrwxrwx 1 root root  9 May 25 15:09 scsi-1ATA_WDC_WD2003FZEX-00SRLA0_WD-WCC6N24R1751 -> ../../sda
lrwxrwxrwx 1 root root  9 May 25 15:09 scsi-1ATA_WDC_WD2003FZEX-00SRLA0_WD-WCC6NLLRDU25 -> ../../sdb
lrwxrwxrwx 1 root root  9 May 25 15:09 scsi-350014ee26ae2b7aa -> ../../sdb
lrwxrwxrwx 1 root root  9 May 25 15:09 scsi-350014ee2c04cdd4e -> ../../sda
lrwxrwxrwx 1 root root  9 May 25 15:09 scsi-SATA_WDC_WD2003FZEX-0_WD-WCC6N24R1751 -> ../../sda
lrwxrwxrwx 1 root root  9 May 25 15:09 scsi-SATA_WDC_WD2003FZEX-0_WD-WCC6NLLRDU25 -> ../../sdb
lrwxrwxrwx 1 root root  9 May 25 15:09 wwn-0x50014ee26ae2b7aa -> ../../sdb
lrwxrwxrwx 1 root root  9 May 25 15:09 wwn-0x50014ee2c04cdd4e -> ../../sda

(In reply to Stefan Hundhammer from comment #6)
> Dexter, please notice that not formatting the ESP (EFI System Partition) is
> only an option if you are sure that there already is one with a valid
> filesystem. If there is nothing yet, it needs to be created first, i.e.
> formatted.

But of course! See section "STEPS TO REPRODUCE" step #1 in my original post.

The REAL issue is just what Lukas noted as important in comment #4 - the installation succeeds when the installer is allowed to format existing partitioned/formatted drives.

This is a LEAP 15.4 issue. As I mentioned in my original post, I first observed the problem almost a year ago. Since the problem did not go away I decided to file a bug report as, IMHO, this is an installer bug. LEAP 15.3 works as expected. In fact, SUSE all the way back to SUSE 10 (yup, been on SUSE that long) works as expected.

(In reply to Josef Reidinger from comment #7)
> It should be already VFAT. But I am not sure if it is enough, as ESP
> requires specific entry in GPT. So it is possible that in this case GUID for
> partition in GPT is not set to C12A7328-F81F-11D2-BA4B-00A0C93EC93B but to
> something else. So here my wild guess ( without logs hard to say for sure )
> is that premade partitioning does not match EFI requirements.

GParted partitions/formats drives correctly. The drives are EFI conformant. The EFI partition is VFAT and labeled (flagged) correctly:

cosmic@peach:~> sudo parted -l /dev/sda
Model: ATA WDC WD2003FZEX-0 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  2149MB  2147MB  fat32           ESP   boot, esp
 2      2149MB  70.9GB  68.7GB  ext4            OS
 3      70.9GB  140GB   68.7GB  ext4            VAR
 4      140GB   277GB   137GB   ext4            TMP
 5      277GB   827GB   550GB   ext4            HOME
 6      827GB   1923GB  1096GB  ext4            DATA
 7      1923GB  2000GB  77.3GB  linux-swap(v1)  SWAP  swap

The issue, as Lukas observed in Comment #4, is the incorrect behavior of the installer. The installer will install GRUB2 EFI, if and only if, the installer is allowed to format the hard drives even when the hard drives are correctly prepartitioned and preformatted.

FWIW, this bug is easily reproduced. All that is required is a plaform with UEFI BIOS with CSM disabled. Install LEAP 15.4 from ISO as outlined in the section "STEP TO REPRODUCE" of my original post.

Use any partitioning/formatting tool to format a hard drive - the tool does not matter.

What I failed to mention in my first post is that the installer does install the selected software to the hard drive.

The installer screws up at the point of installing GRUB2 EFI to the ESP if the installer is NOT permitted to format already formatted partitions - that is the bug.

HTH

(In reply to Dexter Foster from comment #13)
> The issue, as Lukas observed in Comment #4, is the incorrect behavior of the
> installer. The installer will install GRUB2 EFI, if and only if, the
> installer is allowed to format the hard drives even when the hard drives are
> correctly prepartitioned and preformatted.

The "installer" consists of many pieces. As this have failed in GRUB2, I'd rather ask our GRUB2 maintainer first. Michael, can you please take a look?

(In reply to Dexter Foster from comment #11)
> (In reply to Stefan Hundhammer from comment #1)
> > Like with every YaST related bug report, please attach the resulting file of
> > the supplied "save_y2logs" script; see also
> > 
> > https://en.opensuse.org/openSUSE:Report_a_YaST_bug#I_reported_a_YaST2_bug,
> > _and_now_I_am_asked_to_"attach_y2logs"_(for_package_installation_also_"libzyp
> > p_logging")._What_does_that_mean,_and_how_do_I_do_that?
> 
> I will have to do a re-install to obtain yast logs. The system was
> successfully installed as I stated in the "WORKAROUND" section of my
> original post. It will be two or three days before I can do so.
> 
> As I have never had to obtain yast install logs I am a bit unclear how to
> obtain them. The link you referenced seems to apply to a system that can
> boot. However, as GRUB2 EFI is not installed the system cannot boot. The
> installer issues the two mentioned error dialogs then goes to the reboot
> system dialog. I assume that the installer is writing logs to RAM disk, so,
> are volatile (unless they are written to hard disk). It would seem that to
> obtain the logs I would have to cancel the reboot prompt then copy the log
> file from RAM disk - is this correct?
>  
> > But I have a hunch what might have happened here:
> > 
> > In recent months, we had a number of cases where the by-id device name of
> > disks were not as stable as they should be; and I see two disks of the same
> > make and model in your hardware list.
> > 
> > Sometimes, hardware makers don't assign a unique serial number to every
> > individual disk during manufacturing, and then it's a matter of coincidence
> > which one of the disks the kernel discovers first, and that one gets a
> > number 00001 appended, and the other one 00002 (or similar).
> > 
> > You can check this with
> > 
> >   ls -l /dev/disk/by-id | grep -v 'part'
> 
> Not the problem:
> 
> cosmic@peach:~> ls -l /dev/disk/by-id | grep -v 'part'
> total 0
> lrwxrwxrwx 1 root root  9 May 25 15:09
> ata-WDC_WD2003FZEX-00SRLA0_WD-WCC6N24R1751 -> ../../sda
> lrwxrwxrwx 1 root root  9 May 25 15:09
> ata-WDC_WD2003FZEX-00SRLA0_WD-WCC6NLLRDU25 -> ../../sdb
> lrwxrwxrwx 1 root root  9 May 25 15:09
> scsi-0ATA_WDC_WD2003FZEX-0_WD-WCC6N24R1751 -> ../../sda
> lrwxrwxrwx 1 root root  9 May 25 15:09
> scsi-0ATA_WDC_WD2003FZEX-0_WD-WCC6NLLRDU25 -> ../../sdb
> lrwxrwxrwx 1 root root  9 May 25 15:09
> scsi-1ATA_WDC_WD2003FZEX-00SRLA0_WD-WCC6N24R1751 -> ../../sda
> lrwxrwxrwx 1 root root  9 May 25 15:09
> scsi-1ATA_WDC_WD2003FZEX-00SRLA0_WD-WCC6NLLRDU25 -> ../../sdb
> lrwxrwxrwx 1 root root  9 May 25 15:09 scsi-350014ee26ae2b7aa -> ../../sdb
> lrwxrwxrwx 1 root root  9 May 25 15:09 scsi-350014ee2c04cdd4e -> ../../sda
> lrwxrwxrwx 1 root root  9 May 25 15:09
> scsi-SATA_WDC_WD2003FZEX-0_WD-WCC6N24R1751 -> ../../sda
> lrwxrwxrwx 1 root root  9 May 25 15:09
> scsi-SATA_WDC_WD2003FZEX-0_WD-WCC6NLLRDU25 -> ../../sdb
> lrwxrwxrwx 1 root root  9 May 25 15:09 wwn-0x50014ee26ae2b7aa -> ../../sdb
> lrwxrwxrwx 1 root root  9 May 25 15:09 wwn-0x50014ee2c04cdd4e -> ../../sda

Okay, I figured out how to obtain the yast logs, forget I asked...

Created attachment 867238 [details]
yast install logs

Yast install logs at the failure point have been obtained and uploaded.

The empty prepartitioned/preformatted hard drive looks like this:

user@debian:~$ sudo fdisk -l /dev/sda
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD2003FZEX-0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 99115135-5AD0-4907-A349-582FEF9F1CA3

Device          Start        End    Sectors  Size Type
/dev/sda1        2048    4196351    4194304    2G EFI System
/dev/sda2     4196352  138414079  134217728   64G Linux filesystem
/dev/sda3   138414080  272631807  134217728   64G Linux filesystem
/dev/sda4   272631808  541067263  268435456  128G Linux filesystem
/dev/sda5   541067264 1614809087 1073741824  512G Linux filesystem
/dev/sda6  1614809088 3756029951 2141220864 1021G Linux filesystem
/dev/sda7  3756029952 3907024895  150994944   72G Linux swap

user@debian:~$ sudo parted -l /dev/sda
Model: ATA WDC WD2003FZEX-0 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 1      1049kB  2149MB  2147MB  fat32           ESP   boot, esp
 2      2149MB  70.9GB  68.7GB  ext4            OS
 3      70.9GB  140GB   68.7GB  ext4            VAR
 4      140GB   277GB   137GB   ext4            TMP
 5      277GB   827GB   550GB   ext4            HOME
 6      827GB   1923GB  1096GB  ext4            DATA
 7      1923GB  2000GB  77.3GB  linux-swap(v1)  SWAP  swap

All software (OS and apps) are properly installed on the hard drive.

New info (because I did not look before) is that the ESP partition is empty, i.e., nothing was installed. The ESP partition filesystem (VFAT) is intact and the GUID is correct. The ESP partition is unalted.

(In reply to Dexter Foster from comment #14)
> FWIW, this bug is easily reproduced. All that is required is a plaform with
> UEFI BIOS with CSM disabled. Install LEAP 15.4 from ISO as outlined in the
> section "STEP TO REPRODUCE" of my original post.
> 
> Use any partitioning/formatting tool to format a hard drive - the tool does
> not matter.

Did you perform the pre-format to the disk from a Leap 15.4 system or from a more recent release like Tumbleweed ? IMHO the file-system formatting tool does matter since new features may be added that will necessitate grub to patch it's own file-system drivers if that change turns out to be backward incompatible.

Example:
https://savannah.gnu.org/bugs/?61606