2

Recently, I modified my whole ext4 system to become a btrfs one, which was successful. Then, I modified the subvolumes to look like the following:

(btrfs partition block device): ├─@rootfs (subvolume for /) ├─@home (subvolume for /home) ├─@log (subvolume for /var/log) ├─@libvirt (subvolume for /var/lib/libvirt) ├─@opt (subvolume for /opt)

I was able to mount everything properly when booting after using Rescuezilla's live environment for the configurations (for /etc/fstab and grub-install), and I added root=UUID=[btrfs partition UUID] rootflags=rw,subvol=@rootfs to the grub kernel parameters. Now, I have the themes files in the /@rootfs/boot/grub directory, but Grub does not seem to recognize the location and defaults to the default theme whenever I boot into Grub.
How can I make Grub recognize theme files in a btrfs subvolume of the root partition?

Edit: I have created a separate luks1-encrypted boot partition to try to solve this. Everything still works but detecting the theme. The error message (that is thankfully inert) is about a nonexistent file somewhere in /usr/share/grub. I installed grub2 with grub-install --uefi-secure-boot --boot-directory=/boot --efi-directory=/boot/efi --directory=/usr/lib/grub/x86_64-efi --themes=vimix --target=x86_64-efi /dev/nvme0n1p1
The grub error message when booting is:

error: file `/usr/share/desktop-base/ceratopsian-theme/grub/grub-16x9.png' not found.

The file does exist though, at least in the @rootfs subvolume.

I read this which seems to have the same issue, but the solution to stick to the default theme is not helpful: https://forum.endeavouros.com/t/grub-error-no-server-is-specified/42389

Edit 2: Now, I have luks2-encrypted the root partition and boot partition (converting luks1 ⇾ luks2 keeping pbkdf2). A new error shows stating how the cryptodisk module cannot be found, and no server is specified. It is harmless, but it prevents the theme directory from even appearing if the root partition cannot be unlocked while using Grub. Post-boot unlocks fine. The link mentioned previously has these conditions.

Significant parts of /etc/default/grub

GRUB_CMDLINE_LINUX="cryptdevice=UUID=[uuid of encrypted partition]:debian_crypt crypto=sha512:aes-xts-plain64:512:0: root=UUID=[uuid of mapped btrfs root device from encrypted partition at /dev/mapper/debian_crypt] rd.luks.name=[uuid of mapped btrfs root device from encrypted partition at /dev/mapper/debian_crypt]=debian_crypt rd.luks.options=[uuid of mapped btrfs root device from encrypted partition at /dev/mapper/debian_crypt]=tpm2-device=auto,password-echo=no,tries=1 rootflags=rw,subvol=@rootfs intel_iommu=on iommu=pt efi=runtime i915.enable_guc=2" # If your computer has multiple operating systems installed, then you # probably want to run os-prober. However, if your computer is a host # for guest OSes installed via LVM or raw disk devices, running # os-prober can cause damage to those guest OSes as it mounts # filesystems to look for things. GRUB_DISABLE_OS_PROBER=false ... # The resolution used on graphical terminal # note that you can use only modes which your graphic card supports via VBE # you can see them in real GRUB with the command `vbeinfo' GRUB_GFXMODE=1920x1200,auto ... GRUB_THEME="/usr/share/grub/themes/vimix/theme.txt" GRUB_BACKGROUND="/usr/share/desktop-base/ceratopsian-theme/grub/grub-16x9.png" # Enable cryptodisk in case it is needed GRUB_ENABLE_CRYPTODISK=y GRUB_PRELOAD_MODULES="part_gpt btrfs cryptodisk"

update-grub output:

Generating grub configuration file ... Found theme: /usr/share/grub/themes/vimix/theme.txt Found background image: .background_cache.png Found linux image: /boot/vmlinuz-6.15-amd64 Found initrd image: /boot/initrd.img-6.15-amd64 Found memtest86+ 64bit EFI image: /boot/memtest86+x64.efi Found memtest86+ 32bit EFI image: /boot/memtest86+ia32.efi Found memtest86+ 64bit image: /boot/memtest86+x64.bin Found memtest86+ 32bit image: /boot/memtest86+ia32.bin Warning: os-prober will be executed to detect other bootable partitions. Its output will be used to detect bootable binaries on them and create new boot entries. Adding boot menu entry for UEFI Firmware Settings ... done
Improve this question
5
  • Is the btrfs filesystem mounted on anywhere at all when you run grub-install? Did you chroot into anywhere before the run? Commented Jun 30 at 1:39
  • Yes, grub-install was run inside a chroot environment on a LiveCD. It reported no errors. Commented Jun 30 at 2:46
  • So what was the root of the chroot? Say you chrooted into /mnt, did you mount the @rootfs subvolume on /mnt before that? (If you ls /usr/share/desktop-base/ceratopsian-theme/grub/grub-16x9.png after chrooting, would it also report file not found?) Commented Jun 30 at 7:54
  • I mounted with arch-chroot /mnt after mounting with mount -o subvol=@rootfs [btrfs device] /mnt, and the file does exist. Commented Jun 30 at 10:10
  • @TomYan This might be an issue with some part of grub's configuration I do not know yet. Commented Jun 30 at 10:39

3 Answers 3

Reset to default
2
+50

--themes=vimix

First of all, make sure you check whether you should really use vimix in the grub-install command. There's a chance that you should use Vimix instead, depending how you installed the theme to the "grub-install installation / set". In other words, check /usr/share/grub/themes/ for the name.

In my experiment, grub-install will NOT complain even if you entered a non-existent name.

You can also check whether /boot/grub/themes exists and contains the corresponding copy of theme directory (e.g. Vimix) after grub-install.

Actually (when everything is working properly) you don't even have to specify --themes= when grub-install. It's only necessary when e.g. your root filesystem device is not accessible by grub (but only by the kernel) and that you have a separate device and filesystem for /boot. In other words, the argument makes grub-install copies the theme(s) specified from /usr/share/grub/themes to /boot/grub/themes.

If you want to have (a copy of) the theme files in e.g. /boot/grub/themes/Vimix anyway, and that you want grub to use that copy, then you should have:

GRUB_THEME="/boot/grub/themes/Vimix/theme.txt"

Either way, if you don't see e.g.:

Found theme: /boot/grub/themes/Vimix/theme.txt

when you run grub-mkconfig, then most likely something have gone / been done wrong. Again the command won't complain if the path you have given is non-existent, so make sure you check e.g. whether it is vimix or Vimix on your installation.

GRUB_BACKGROUND="/usr/share/desktop-base/ceratopsian-theme/grub/grub-16x9.png"

I'm not sure what exactly you want here. Are you trying to override the background image of the Vimix theme? Or are you just experimenting?

As far as I can see here, GRUB_BACKGROUND will just be ignored if you have provided a valid value for GRUB_THEME. If you are looking to override the background image, probably you should just grub-install with --themes=Vimix, and then manually copy /usr/share/desktop-base/ceratopsian-theme/grub/grub-16x9.png to /boot/grub/themes/Vimix/background.jpeg. (Double check whether the existing / original one is .jpeg instead of .jpg in your case.)

For the record I don't know if grub supports PNG and whether the extension name matters in "triggering" the support or so. You may need to convert it to JPEG first, or keep the (extension) name and modify the theme.txt accordingly.

error: file `/usr/share/desktop-base/ceratopsian-theme/grub/grub-16x9.png' not found.

The fact that you see this error apparently indicate two things:

  1. /usr/share/grub/themes/vimix/theme.txt does not exist (when you run grub-mkconfig), because otherwise GRUB_BACKGROUND would have likely been ignored.

  2. Very likely your distro ships a old / broken version of grub(-mkconfig) that does not support "resolving" the path into the "version" grub should use at boot time (when it involves btrfs subvolume). Instead it simply copies the path provided verbatim.

One simple and future-proof workaround would be to create a subvolume named boot (yes, not @boot) directly under the root of the filesystem (i.e. where your other "@ subvolumes" exist). Then have it mounted on /boot (of @rootfs; so e.g. /mnt/boot before chroot, after mounting @rootfs on /mnt, before mounting the ESP on /mnt/boot/efi). (Don't forget to have an fstab entry for it too. Also make sure you have it in the /etc/fstab in @rootfs, but not the one of your rescue / live environment.) Obviously the goal is to make /boot refers the same place for both grub and the Linux installation.

Also don't forget to move the files from @rootfs/boot to the boot subvolume first (well, at least everything else other than the grub directory -- for that you can and should just run grub-install again; but you should probably delete @rootfs/boot/grub to prevent it from causing confusion at any point). That is, you should mount the filesystem (root; i.e. without specify any -o subvol=) on e.g. /mnt and perform the move first. (And of course unmount it after having that done.)

Probably because of the bug, you will need to grub-install with --themes= (or copy the background image you desire to somewhere under the boot subvolume (make sure e.g. /boot is mounted / is NOT @rootfs/boot!) if you want to use GRUB_BACKGROUND instead of GRUB_THEME).

Improve this answer
3
  • That's true, grub doesn't complain if one puts some bogus as the theme. The theme is lowercase though, so vimix is the theme. update-grub does not complain and shows the correct theme and background directories/files I specified. By the way, the theme used to work before I placed my whole system into the @rootfs subvolume, so you may be right; I will try this out soon. Commented Jun 30 at 20:29
  • /boot/grub/themes/vimix exists with theme.txt. Also, grub tells me while booting that it cannot unlock the main partition to find the background because the cryptodisk module might not be loaded even though I tried preloading it. Commented Jun 30 at 21:52
  • See my answer, I found the solution. Thanks too, you guided me to the answer. I didn't have to create a new boot subvolume, so it isn't a bug but a misconfiguration on my part. Commented Jun 30 at 22:20
1

The theme issue stems from confusion around where your subvolumes are mounted during grub-install. Specifically, you mount @rootfs under /mnt, and the theme is under /mnt/usr/share/, so grub-install correctly reports that it's not under /usr/share/.

There is also encryption on top, so GRUB won't be able to load the theme during boot until the volume holding it is unlocked, which is probably not what you want.

The solution is to copy the theme directory to your ESP, next to grub.cfg. This will make themes work irrespective of what happens to your OS or filesystems.

Assuming that your grub.cfg is in /boot/efi/efi/grub/ and your theme is in /usr/share/grub/themes/vimix, then this should do it:

sudo mkdir /boot/efi/efi/grub/themes sudo cp -r /usr/share/grub/themes/vimix /boot/efi/efi/grub/themes/

The goal is to have the following setup:

- EFI system partition - <grub dir> - grub.cfg - themes/ - vimix/ - theme.txt

Then add this to grub.cfg right before the first menuentry:

set theme="vimix/theme.txt" export theme

Once you get the theme working, copy the background image grub-16x9.png next to grub.cfg on the ESP and add background_image grub-16x9.png to grub.cfg after the export theme line.

It should work well, but these manual steps may be overridden when you run grub-mkconfig again. To make the changes survive that, you'll have to tweak /etc/grub.d/.

Improve this answer
2
  • 1
    Actually the OP mentioned that the error does not come from grub-install. Instead it's a "boot (time) error". (Also, he ran grub-install after chrooting into /mnt.) Commented Jun 30 at 11:59
  • @Sergiu How would I tweak /etc/grub.d to preserve those changes? Commented Jun 30 at 21:54
0

I forgot to mention some time ago, inside the theme.txt, I changed the desktop-image property to reference the @rootfs subvolume in the filesystem. The line looked like this:

desktop-image: "/usr/share/desktop-base/ceratopsian-theme/grub/grub-16x9.png"

I did that because I didn't like the background provided by the theme.

In an attempt to fix this, I followed the first part of @TomYan's answer to change the GRUB_THEME option to reference /boot/grub/themes/vimix/theme.txt. (lowercase) I updated and reinstalled grub, and since that did not work, I copied /usr/share/desktop-base/ceratopsian-theme/grub/grub-16x9.png to /usr/share/grub/themes/vimix/background.jpg. That didn't work because I used the wrong file extension (.png, not .jpg silly), so I change the file extension, updated and reinstalled grub, and everything worked with no error messages.

I would also like to point out that changing GRUB_THEME in /etc/default/grub also caused grub to only want the password to the boot partition, not also the btrfs root partition as the previous theme file was in that partition. Grub cannot even open the main root partition because it is encrypted with argon2, not pbkdf2, which grub does not support, so that is probably the reason for this issue.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.