Bug 1080731 - shim-install fails to executed in post-installation period on UEFI
shim-install fails to executed in post-installation period on UEFI
: 1080082 1080397 1081060 1082378 1082682 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2
Other Other
: P2 - High : Normal (vote)
: ---
Assigned To: Stefan Hundhammer
Jiri Srain
Depends on:
  Show dependency treegraph
Reported: 2018-02-13 08:35 UTC by Max Lin
Modified: 2019-04-15 12:15 UTC (History)
11 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Max Lin 2018-02-13 08:35:49 UTC
In last TW snapshot, shim-install failed to do its job, the error message says can not create /boot/efi/EFI/boot directory due to the file exists[1], it seems like yast change causes this so I just opened bugrepor to yast.

[1] https://openqa.opensuse.org/tests/608750#step/install_and_reboot/16
Comment 1 Stefan Hundhammer 2018-02-13 12:33:31 UTC
The error message says 

  "mkdir: cannot create directory /boot/efi/EFI/boot: File exists"

Now let's check what might be the reason for that.
Comment 2 Stefan Hundhammer 2018-02-13 12:56:49 UTC
From the committed devicegraph in y2log-1:


2018-02-13 01:57:20 <1> install(3524) [libstorage] ActiongraphImpl.cc:538
  Commit Action "Mounting /dev/vda2 at /boot/efi" [sid:76, first]

2018-02-13 01:57:20 <1> install(3524) [libstorage] SystemCmd.cc:170 SystemCmd
  Executing:"/sbin/udevadm settle --timeout=20"
... SystemCmd.cc:419 system() Returns:0
... BlkDeviceImpl.cc:615 name:/dev/vda2 exists:true

2018-02-13 01:57:20 <1> install(3524) [libstorage] SystemCmd.cc:170 SystemCmd
  Executing:"/bin/mount -t vfat -o 'iocharset=utf8' '/dev/vda2' '/mnt/boot/efi'"
... SystemCmd.cc:419 system() Returns:0

2018-02-13 01:57:20 <1> install(3524) [libstorage] ActiongraphImpl.cc:538
  Commit Action
  "Adding mount point /boot/efi of /dev/vda2 to /etc/fstab" [sid:76, last]

/mnt/etc/fstab diff: 
+UUID=26C4-565A    /boot/efi   vfat   iocharset=utf8     0  0

2018-02-13 01:57:21 <1> install(3524) [Ruby] modules/Mtab.rb:35
  Target /etc/mtab file:

/dev/vda2 /boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro 0 0
Comment 3 Stefan Hundhammer 2018-02-13 12:57:57 UTC
From y2log:

2018-02-13 07:05:01 <1> linux-9n1l(3524) [Ruby] lib/cheetah.rb:158
Executing "parted -s /dev/vda disk_set pmbr_boot off".

Status: 0
Executing "/usr/sbin/shim-install --config-file\=/boot/grub2/grub.cfg".
Error output: mkdir: cannot create directory ���/boot/efi/EFI/boot���: File exists
Status: 1

2018-02-13 07:05:01 <3> linux-9n1l(3524) [Ruby] yast2/execute.rb:99
  Execution of command
  "[["/usr/sbin/shim-install", "--config-file=/boot/grub2/grub.cfg"]]"
Exit code: 1
Error output: mkdir: cannot create directory ‘/boot/efi/EFI/boot’: File exists
Comment 4 Stefan Hundhammer 2018-02-13 13:06:48 UTC
AFAICS creating and mounting /boot/efi worked just fine, so the suspected problem (my latest changes to mount options) does not seem to be a problem here.

If "shim-install" now complains that that directory /boot/efi/EFI/boot already exists, the problem must be elsewhere.

Grub / EFI experts, please have a look!
Comment 5 Stefan Hundhammer 2018-02-13 13:31:51 UTC
One more thought:

We now have mount options "iocharset=utf8" for that filesystem (of type VFAT). The resulting /etc/mtab (/proc/mounts) entry now tells us that the total mount options (including those that are default) are now "rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro"

If "shortname=mixed" is now new in those aggregated mount options because of this "iocharset=utf8", it might change a few things:

VFAT filesystems are case insensitive, so "efi", "EFI", "Efi" are all treated the same. So, if a directory "efi" already exists, "mkdir EFI" will fail with just this error.

OTOH checking if the directory already exists should also work consistently, so this should not really make a difference. And even if it does, this is a bug in that script since this can happen at any time.
Comment 6 Stefan Hundhammer 2018-02-13 13:34:50 UTC
"man mount" also says:

  Defines  the  behavior for creation and display of filenames which fit 
  into 8.3 characters.  If a long name for a file exists, it will always 
  be the preferred one for display."

Not sure how exactly this behaves, but I would expect the Linux VFAT kernel module to handle this properly, i.e. create a long filename when creating a directory entry with Linux syscalls.
Comment 7 Stefan Hundhammer 2018-02-13 14:15:09 UTC
Summarizing a discussion with our resident EFI expert Raymund Will:

We definitely need special mount options for /boot/efi, for this problem here as well as for other issues like restricting permissions to that partition (because it might contain passwords).

Right now, we only have this one set of default mount options that is based on the filesystem type. For at least this special mount point /boot/efi we will need different ones, and we need to make sure we get that at different places: For the proposal as well as for the expert partitioner.

Luckily enough, we already have a special code branch in the expert partitioner since it's not only the mount point /boot/efi which makes the EFI System Partition (ESP) special, it also has a special partition ID; thus we already have  a radio box with this special case when the user selects the purpose of a partition (Linux/LVM PV/raw/.../EFI System Partition).
Comment 8 Stefan Hundhammer 2018-02-13 14:27:25 UTC
Created new Trello card for this issue:

Comment 9 Stefan Hundhammer 2018-02-14 15:46:17 UTC
Filed bug #1081022 for the inconsistent kernel vfat module behaviour (which is the underlying cause, but we will need an independent fix).

The problem appears when mount option "iocharset=utf8" is used and there is only a VFAT "short name" (i.e. all uppercase 8+3), no "long name".
Comment 10 Stefan Hundhammer 2018-02-14 16:40:56 UTC
See also bug #1080082 (duplicate?)
Comment 11 Stefan Schubert 2018-02-16 09:19:53 UTC
*** Bug 1080082 has been marked as a duplicate of this bug. ***
Comment 12 Ancor Gonzalez Sosa 2018-02-16 09:50:35 UTC
*** Bug 1080397 has been marked as a duplicate of this bug. ***
Comment 13 Andrei Borzenkov 2018-02-18 19:27:19 UTC
See also https://github.com/systemd/systemd/issues/3740#issuecomment-234143814
Comment 14 Josef Reidinger 2018-02-19 11:57:12 UTC
*** Bug 1081060 has been marked as a duplicate of this bug. ***
Comment 15 Stefan Hundhammer 2018-02-19 18:15:02 UTC
This should be fixed with https://github.com/yast/yast-storage-ng/pull/532 which (re-)introduces special handling for the mount options for certain paths (/, /boot, /boot/*).
Comment 16 Steffen Winterfeldt 2018-02-23 14:49:07 UTC
*** Bug 1082378 has been marked as a duplicate of this bug. ***
Comment 17 Randy Wright 2018-02-23 23:00:23 UTC
I am still seeing this issue in beta7, but I take it from the date of comment 15 I could not expect that fix to be in beta7.
Comment 18 Charles Arnold 2018-02-26 16:05:34 UTC
*** Bug 1082682 has been marked as a duplicate of this bug. ***