## The Problem: "No Bootable Device" After Installation

If you have attempted to install Devuan following the Live Install Guide for the desktop-live ISO using the refractainstaller, you've probably encountered this issue. The installation process appears to finish successfully, but when you remove the USB drive and reboot, you've likely encountered a warning similar to:

grub-install: warning: EFI variables cannot be set on this system.
You will have to complete the GRUB setup manually.

This guide explains exactly why this happens, why it is not an issue with your physical system, and how the --removable flag provides a universal fix.

## The Core Concept (UEFI vs. Legacy)

To understand the error, you must understand the two ways computers boot:

1. Legacy BIOS (Old Way): The computer looks at the very first sector of your hard drive (MBR) to find the bootloader. It's simple and doesn't require a special partition.

2. UEFI (New Way): Modern computers (almost all made since 2012) use UEFI. Instead of looking at the first sector, the motherboard has a small internal database (NVRAM) that stores a Boot List. This list tells the computer exactly which file on which partition to load (e.g., \EFI\devuan\grubx64.efi).

3. The Catch: To add an entry to this internal Boot List, the operating system installer must have special access to the motherboard's firmware settings via something called EFI Variables.

## Why the Installation Failed

When you run the Devuan installer (refractainstaller) or the grub-install command from a Live USB, one of two things usually happens to block access to these EFI Variables:

### Scenario A: Devuan booted the Live USB install in "Legacy/CSM" Mode

Even if your laptop supports UEFI, many ISO creators default to "Legacy" compatibility mode.

• What happens: The Linux kernel sees it is running in Legacy mode. It disables all UEFI features because it thinks they aren't available.

• The Result: When grub-install tries to talk to the UEFI firmware to add your new Devuan entry to the boot list, the firmware says, "I can't hear you," or the kernel says, "I don't have the tools to talk to it."

• The Error: EFI variables cannot be set on this system.

### Scenario B: The efivarfs Filesystem is Missing

Even if you booted the USB in UEFI mode, the Live environment might not have automatically mounted the special virtual filesystem (efivarfs) that allows software to talk to the UEFI chip.

The Result: The installer copies the bootloader files to your hard drive successfully, but fails at the very last step: registering the boot entry in the motherboard's memory.

## The Consequence

The installer copies the necessary files (like grubx64.efi) to your hard drive's EFI partition, but it fails to tell your motherboard that these files exist. When you reboot, the motherboard looks at its empty Boot List, finds no instruction to load Devuan, and gives up with "No Bootable Device."

## The Solution (The --removable Flag)

You don't need to re-partition or fix the Live USB boot mode. You can force the bootloader to install in a way that bypasses the need for EFI Variables entirely.

### How It Works

UEFI standards mandate a fallback path. If the motherboard's Boot List is empty or broken, it is required to look for a specific file at a specific location:

/efi/boot/bootx64.efi

By using the --removable flag, you tell grub-install:

"Don't try to write to the motherboard's internal database (which is failing). Instead, copy the bootloader to the fallback location that every UEFI computer checks automatically."

## Step-by-Step Repair Guide

Since you already have Devuan installed and just need to repair GRUB, follow these steps to chroot correctly and reinstall the bootloader. The "no directory" error you saw earlier usually happens because the virtual filesystems (/dev, /proc, /sys) were not bound before entering the chroot.

1. Boot from your Live USB/CD.

2. Login as superuser:

   su -

3. Mount Partitions and Bind Filesystems

   Use lsblk to identify the root / partition (TYPE... part) that you set with refractainstaller for your permanent (non-live) install on your device's drive. It should be the one that IS NOT the mountpoint for the /run/live* directories.
      
   In the example output below, this is what typical user's setup might look like:

   NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
   loop0    7:0    0   1.5G  1 loop /run/live/rootfs/filesystem.squashfs
   sda      8:0    0   1.8T  0 disk 
   └─sda1   8:1    1   1.7G  0 part /run/live/medium
   └─sda2   8:2    1   1.4M  0 part
   sdb
   └─sdb1   9:1    1   476M  0 part /boot/efi
   └─sdb2   9:2    1   69.4G 0 part /

   In this example case, the partition identified within /dev/sdb2 would be root /, and the EFI partition for UEFI setups would be /dev/sdb1.
   `
   |---
   | NOTE: The commands in below will use this example scenario, your input/commands will vary.
   |---
        
   - Mount root partition:

   mount /dev/sdb2 /mnt

   - (UEFI use only) Mount EFI partition:

   mount /dev/sdb1 /mnt/boot/efi

   - Bind virtual filesystems (CRITICAL STEP):

   mount --rbind /dev /mnt/dev
   mount --rbind /proc /mnt/proc
   mount --rbind /sys /mnt/sys
   mount --rbind /run /mnt/run

   - Copy DNS settings to allow network access inside chroot:

   cp /etc/resolv.conf /mnt/etc/

4. Enter the Chroot

   Now enter the environment:

   chroot /mnt /bin/bash

5. Reinstall and Update GRUB

   Once inside the chroot, determine your boot mode. Run this command to check:

   ls /sys/firmware/efi/efivars

      
   If the directory is missing or empty, you are in BIOS/Legacy mode.
   If the directory exists and contains files, you are in UEFI mode.
      
   - For BIOS/Legacy Systems:

   apt update
   apt install --reinstall grub-pc
   grub-install /dev/sdX
   update-grub

   |---
   | NOTE: Replace /dev/sdX with your disk, e.g., /dev/sda, NOT a partition like /dev/sda1)
   |---
   `
   - For UEFI Systems:

   apt update
   apt install --reinstall grub-efi-amd64
   grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable
   update-grub

      
   |---
   | NOTE: We removed --bootloader-id=Devuan long option in the grub-install command
   | because it is ignored when using --removable).
   |---
      
   |---
   | NOTE: If update-grub fails to detect other operating systems, ensure os-prober is installed and uncomment
   | GRUB_DISABLE_OS_PROBER=false in /etc/default/grub.
   |---
   `

6. Exit and Reboot

   umount -R /mnt
   reboot

Hi all,

I've been trying to, on-and-off, get Hyprland to be able to screenshare sound and windows/screens. The primary way that I have historically done this on systemd based Linux distributions (OpenMandriva Lx) is via Vesktop.. This has also been an issue with things like attempting to stream or record video on things like OBS.

In Vesktop, when I click the screenshare button in `i3` on XLibre, it simply works now that I am able to launch `pipewire` properly on boot. However, when I switch to Hyprland, when I click the screenshare button on Vesktop, the program simply refuses to open/display the window to display the possible sources for sharing at all. Peculiar.

In an earlier post, I shared that I was able to get Pipewire to work on Hyprland, which from my understanding is what is relied upon for the sound portion of the share for compositors:

I've been trying to further experiment, but I'm stuck.

In short, here are some relevant notes that could indicate the source of what the solution may be:

1. Created the scripts that the pipewire article on the Gentoo wiki suggests
2. Attempted to follow the GitHub Gist the Hyprland wiki (linked above) suggested
3. One output I do get whenever I stop Hyprland and get booted back into the TTY is the following:

dconf-WARNING **: 12:34:41:884: failed to commit changes to dconf: Cannot autolaunch without X11 $DISPLAY

    One thing I've seen suggested on the net a lot is to do something like the following:

export DISPLAY=:0

    I do not see a change as a result of this, at least from my understanding.