package lubuntu-grub-theme (not installed) failed to install/upgrade: error creating symbolic link './boot/grub/themes/lubuntu-grub-theme/icons/ubuntu.png': Operation not permitted - symbolic link on vfat filesystem

Not sure if this is relevant or not, but since it pertains to the destination of the install:

$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# /boot/efi was on /dev/vda1 during installation
UUID=5839-64D6 /boot/efi vfat umask=0077 0 1
/boot/efi/grub /boot/grub none defaults,bind 0 0

I do not believe vfat supports symbolic links.

If I comment out the mounting of /boot/efi in /etc/fstab and then perform the installation of lubuntu-grub-theme it installs without error.

I should add this was a clean install of Unbuntu Desktop 20.04 to a KVM guest with a ZFS root filesystem.

Where does the fstab entry "/boot/efi/grub /boot/grub none defaults,bind 0 0" come from? Was it added automatically by the installer? Or did you add it manually?

It was added by the installer.

As I mentioned, this is a root on ZFS installation but on a VM guest, one that does not have UEFI enabled. My guess is the ZFS install makes a single installation that works for both UEFI and BIOS. Options to modify the ZFS layout are not currently available in the installer.

Thank you for reporting this bug. I can confirm this behaviour with:
- virtual machine (qemu)
- booted in BIOS mode
- use the empty disk and choose ZFS automatism

I am not sure, if the created /etc/fstab is product of a bug or an feature.

I can confirm, this is a feature. Without this bind mount, the ZFS snapshot history is not available via grub at boot time.

I should say the "new snapshots" are not available since having removed the bind mount. Any snapshots previous to removing the bind mount remain available, however any subsequent snapshots are not. Restoring the bind mount and reinstalling grub will make the newer snapshots available.

For a bit more information, see: https://ubuntuforums.org/showthread.php?t=2440919

This is the offending symbolic link found in /boot/grub/themes/lubuntu-grub-theme/icons:

lrwxrwxrwx 1 root root 11 Apr 17 10:43 ubuntu.png -> lubuntu.png

After removing the bind mount, copying the theme to the /boot/grub, re-establishing the bind mount, copying the file rather than using a symbolic link for the file, and then finally configuring grub to use the theme... it is not that useful for ZFS installations. Unfortunately it truncates menu options with important information for the for the ZFS snapshot history, like date and time.

Maybe if the grub resolution is increased it would work better?

At 1280x1024x32 resolution for grub, the ZFS history options are fully visible, at least on my system.

Modified /etc/default/grub by adding the following:

GRUB_GFXMODE=1280x1024x32
GRUB_GFXPAYLOAD_LINUX=keep
GRUB_THEME=/boot/grub/themes/lubuntu-grub-theme/theme.txt

On ZFS setup, boot/grub/ uses the EFI system partition to store GRUB configuration so, it's always readable by grub on boot. This partition is of type vfat and this filesystem type doesn't support symbolic links.

The problem with lubuntu grub theme is that a file used for the theme is a symbolic link, so dpkg cannot extract it to the VFAT partition

ls -l src/boot/grub/themes/lubuntu-grub-theme/icons/ubuntu.png
lrwxrwxrwx 1 u u 11 avril 3 10:10 src/boot/grub/themes/lubuntu-grub-theme/icons/ubuntu.png -> lubuntu.png

A solution at the packaging level is to create a copy instead of using a symbolic link.

@jibel Thank you for explaining this.

Is it somewhere documented, why a EFI system partition is created on a system, which is installed in BIOS mode?

I would expect a separate /boot partition with ext2 or ext4 and the ESP (with the efi images for grub, shim and mok) only for systems which are booting in EFI mode.

I believe the answer is because the of ZFS filesystem, including /boot. Grub can not read ZFS filesystems, my understanding that is in development.

And the reason /boot is ZFS rather than ext2/3/4 is to be able to snapshot and roll-back.

@apt-ghetto, an ESP is always created in BIOS in case the boot is switched to UEFI. A typical use case on many systems, you boot an image and perform the installation in BIOS mode, and reboot in UEFI.

@jibel Your typical use case (install in BIOS mode and reboot into UEFI mode) ends typically in an error. There is no bootloader installed on /boot/efi/EFI/ubuntu and there is no boot entry in the NVRAM, which would point to shim or grub on the ESP.

The typical user has to replace grub-pc with grub-efi-* and create a boot entry in the NVRAM (/sys/firmware/efi doesn't exist, neither in the installed system, nor in the live-system). I guess, most users won't do that. They would simply reinstall in the desired mode.

Another possible problem I spotted: The installer created a msdos partition table on an empty disk (which isn't a problem). The problem starts, if the user installs Windows on this disk. Windows will be installed in BIOS mode and if you change the boot mode of Ubuntu, you don't have a dualboot anymore.
I didn't test it, but if the ESP is created as a logical partition, there are surely errors, if the system is booted in UEFI mode.

Meanwhile, I try to find a Lubuntu dev to fix lubuntu-artwork.

Lubuntu Final ISO was released today, so I'll take a look at it.

If this can not be fixed before the final ISO, maybe it can be removed from required to suggested for arm64? It is art only and does not affect the ability to run the Lubuntu Desktop.

Err, I meant to type amd64 not arm64. Our arm64 installations do not use ZFS, therefore they are unaffected by this issue.

Hi, The issue happened to me with zfs on root + neon grub theme.

Failing on the unable to make backup link of './boot/grub/themes/breeze/progress_bar2_c.png' before installing new version: Operation not permitted
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/grub-theme-breeze_5.19.5-0xneon+20.04+focal+build9_amd64.deb

Any idea on possible solution/workaround?