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

[System Admin]

I have tried to install lubuntu-desktop meta and the lubuntu-grub-theme (current and the previous version 20.04.2) package individually.
I have also removed snapd in the event this was a snapd permissions issue.
The error is still encountered.

See: Bug 1872978

ProblemType: Package
DistroRelease: Ubuntu 20.04
Package: lubuntu-grub-theme (not installed)
ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
Uname: Linux 5.4.0-21-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu26
AptOrdering:
 lubuntu-grub-theme:amd64: Install
 NULL: ConfigurePending
Architecture: amd64
CasperMD5CheckResult: skip
Date: Wed Apr 15 08:33:49 2020
DpkgTerminalLog:
 Preparing to unpack .../lubuntu-grub-theme_20.04.2_all.deb ...
 Unpacking lubuntu-grub-theme (20.04.2) ...
 dpkg: error processing archive /home/support/Downloads/lubuntu-grub-theme_20.04.2_all.deb (--unpack):
  error creating symbolic link './boot/grub/themes/lubuntu-grub-theme/icons/ubuntu.png': Operation not permitted
ErrorMessage: error creating symbolic link './boot/grub/themes/lubuntu-grub-theme/icons/ubuntu.png': Operation not permitted
InstallationDate: Installed on 2020-04-14 (0 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Beta amd64 (20200402)
Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 3.8.2-0ubuntu2
PythonDetails: N/A
RelatedPackageVersions:
 dpkg 1.19.7ubuntu3
 apt 2.0.2
SourcePackage: lubuntu-artwork
Title: 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
UpgradeStatus: No upgrade log present (probably fresh install)

[System Admin (0n0w1c)]

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

[System Admin (0n0w1c)]

I do not believe vfat supports symbolic links.

[System Admin (0n0w1c)]

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.

[System Admin (0n0w1c)]

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

[apt-ghetto (apt-ghetto)]

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?

[System Admin (0n0w1c)]

It was added by the installer.

[System Admin (0n0w1c)]

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.

[apt-ghetto (apt-ghetto)]

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.

[System Admin (0n0w1c)]

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

[System Admin (0n0w1c)]

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

[System Admin (0n0w1c)]

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

[System Admin (0n0w1c)]

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?

[System Admin (0n0w1c)]

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

[System Admin (0n0w1c)]

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

[Jean-Baptiste Lallement (jibel)]

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.

[apt-ghetto (apt-ghetto)]

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

[System Admin (0n0w1c)]

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

[System Admin (0n0w1c)]

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

[Jean-Baptiste Lallement (jibel)]

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

[apt-ghetto (apt-ghetto)]

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

[Joshua Peisach (itzswirlz)]

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

[System Admin (0n0w1c)]

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.

[System Admin (0n0w1c)]

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

[Ivan Dimitrov (idimitro)]

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?