Quick Quality-of-Life Improvements

Like this?

autostart_menu
#!/bin/bash

# vms to start
declare -a work_qubes=("work-vm1" "work-vm2" "work-vm3")
declare -a system_qubes=("sys-net" "sys-firewall" "sys-usb" "sys-vpn")
declare -a admin_qube=("admin-vm1" "admin-vm2")
declare -a comms_qube=("comms-vm1" "comms-vm2")

# commands to launch apps
declare -a browser_firefox=("browser firefox")

start_qubes() {
  qubes_to_start=("${!1}")

  for qube in "${qubes_to_start[@]}"; do
    echo "Starting $qube..."
    qvm-start "$qube" || echo "Failed to start $qube"
  done
}

run_application() {
  app_to_start=("${!1}")

  for qube in "${app_to_start[@]}"; do
    echo "Starting $apps..."
    qvm-run -p "$" || echo "Failed to start $app"
  done
}

prompt_user() {
  startup_choice=$(zenity --list --radiolist --height 200 --width 250 --title="Select Startup Group" --text "Choose a group of qubes to start:" --column "Pick" --column "Startup Group" TRUE "Work Qubes" FALSE "System Qubes" FALSE "Admin Qube" FALSE "Comms Qube" FALSE "Browser Firefox")

  case "$startup_choice" in
    "Work Qubes")
      echo "Starting work qubes..."
      start_qubes work_qubes[@]
      ;;
    "System Qubes")
      echo "Starting system qubes..."
      start_qubes system_qubes[@]
      ;;
    "Admin Qube")
      echo "Starting admin qubes..."
      start_qubes admin_qube[@]
      ;;
    "Comms Qube")
      echo "Starting comms_kick..."
      start_qubes comms_qube[@]
      ;;
    "Browser Firefoz")
      echo "Starting Firefox in Browser"
      run_application browser_firefox[@]
      ;;
    *)
      echo "No option selected. Exiting."
      ;;
  esac
}

echo "QubesOS autostart script initialized"
prompt_user

If I’m not mistaken, what your script does is launch a predefined (hardcoded) set of VMs and apps only upon Qubes OS startup.

What @q4u’s code does is allow users to enter a shortcut whenever they want (e.g. $mod + o), then enter commands (e.g. “fm” to open Firefox and Mail), then press ESC to exit and execute.

That was my first impression, too @fiftyfourthparallel.

I’m unsure what zenity does, but on second read it makes the impression to me that @kenosen’s stuff does in fact prompt the user for input/choice on what to start.

Although I think this might be tied with XFCE.

It might not be a one-fits-all solution but a XFCE-only functionally-equivalent variant of what my script/i3-config does.

Ah, then I defer back to those hotkeys from 3hhh and hotkey a dom0 terminal open/close, though using a verve command line in the xfce panel is another option.

Does not work for me.

in /etc/lightdm/lightdm.conf I set with sudo:

#autologin-user=

to

autologin-user=dom0-username

also tried user since I was not sure if you have used username as an alias for your actual Qubes OS user name (in my case user)

autologin-user=dom0-user

I also tried shutdown and power on again instead of reboot.

Qubes OS always asks for the user’s password on boot (after LUKS password).

PS: My system runs coreboot but I do not think that should impact this configuration.

Is your username dom0-user? For instance, if my username is solene then the line should be autologin-user=solene

3 Likes

Thanks, confirmed, it works.
Sorry, for my foolishness :see_no_evil:

3 Likes

Maybe @renehoj wants to modify the code line:

autologin-user=dom0-username

to

autologin-user=<your_dom0_username>
1 Like

@whoami @renehoj Done

1 Like

Dom0 also offers screenshot per window. default ist Alt+Print, but this sometimes leads to revoking the right click action i wanted to screenshot.

1 Like

NETVM CHANGER.

I have made some modifications in one script that was posted here, it list the vms that have provides_network true and popup a menu list using zinity to choose the new netvm on the focused window.

1 Like

Decrease Time to Login Prompt/Autologin

  • Modify qubes-vm@.service to be a simple systemd service
    • Create override config using command sudo systemctl edit qubes-vm@.service
    • Insert following lines in active section, ABOVE the line ### Lines below this comment will be discarded
      • [Service]
        Type=simple
        
    • Explanation: simple service allows systemd to boot next service without checking exit status or successful launch of command unlike oneshot
3 Likes

@den1ed Added as an alternative, thanks
@a_lurker_no_more Added, thanks

1 Like

I forget this one:

Show netvm from focused window

netvm_show
#!/bin/bash

# Get the ID of the focused window
ID=$(xdotool getwindowfocus)
QUBE=$(xprop _QUBES_VMNAME -id $ID | cut -f2 -d\")

# Variable to store the NetVM
netvm=""

# Check if the current VM has a defined NetVM
if [ -n "$QUBE" ]; then
    netvm=$(qvm-prefs "$QUBE" netvm)
fi

# Check if a NetVM was found
if [ -z "$netvm" ]; then
    notify-send "No NetVM found for $QUBE."  
    exit 0
else
    notify-send "The NetVM for $QUBE is: $netvm"
fi

@den1ed Thanks for the submission.

This one feels a bit niche, but maybe I’m not seeing it’s true potential.

Would you kindly illustrate how you use it?

2 Likes

Script for dynamically increasing qube performance, by changing the Xen priority for the domain of the active widnow.

#!/bin/bash

CUR_WIN_ID=`xdotool getwindowfocus`
CUR_VM=`xprop _QUBES_VMNAME -id $CUR_WIN_ID |cut -d \" -f2`

xl sched-credit2 -d $CUR_VM -w $1

exit 0

The default weight is 256, if you change it to 512 that domain will be scheduled twice as often as other domains.

The script takes the weight value as an argument, and it assumes you are using credit2, which is the default scheduler.

./script.sh 512 increase priority.
./script.sh 256 reset priority.

6 Likes

I created a new category (performance) and put your entry there; please check for accuracy. See post below

I took the liberty of naming the shell script “reneboost” in your honor. “reneturbo” or “turborene” were considered but wasn’t as catchy.

Sorry if it seems I’m asking for too much, but is there a simple way to make VM window titles show their priority levels?

1 Like

@renehoj When double-checking I realized I misread your post.

Since your script needs an input it can’t be made into a shortcut, as-is. However I feel your script can use a UX improvement, where users can just apply it to the current window when needed without worrying about anything else, but power users also have the option of invoking the CLI version with input parameters.

What I have in mind is a toggle system, where the script resets the priority of all other VMs and raises the priority of the selected window’s VM to a predefined level (e.g. 512) and, if possible, adds some sort of indicator to the window title or title bar (like a star). To reset all priorities just use the shortcut on a boosted VM’s window.

What do you think?

 

Example:

  1. I select an app-browsing window and then enter “ctrl + shift + B”, invoking reneboost.sh. This causes app-browsing to increase to 512. A star appears in front of its dom0 titlebar name.

  2. I select and app-media window and enter the shortcut. This causes all other VMs, including app-browsing, to return to 256 while app-media is boosted to 512. A star appears in front of app-media’s dom0 titlebar name while vanishing from app-browsing’s.

  3. To reset all priorities to 256, I select an app-media window and enter the shortcut again. The star vanishes.

  4. For finer-grained adjustments, I use your script as you originally intended.

All this may be a bit beyond the scope of this thread, but I reckon it’s worth it.

 

The original (faulty) version of my post:

  • Increase CPU priority of selected window’s VM - [dom0] Create /bin/reneboost.sh (expandable), make it executable (chmod +x), then map to shortcut @renehoj

    reneboost.sh
    #!/bin/bash
    
    CUR_WIN_ID=`xdotool getwindowfocus`
    CUR_VM=`xprop _QUBES_VMNAME -id 
    $CUR_WIN_ID |cut -d \" -f2`
    
    xl sched-credit2 -d $CUR_VM -w $1
    
    exit 0
    
1 Like

The input is a command line parameter, it works with XFCE shortcuts.

You can toggle it on and off by making two shortcuts to the same script, 512 to increase priority and 256 to reset, the domian will also reset when it shuts down.

I don’t think you can easily permanently change the title, at least I don’t know how. You can change the title with xdotool, if the qube changes the title your change will be overwritten.

The problem is that users have to manually keep track of Xen priorities for each VM. I don’t know of an easy way to look up Xen priorities (a column in Qubes Manager in the future?), and even if I did it’d be something of a pain to do so frequently.

Adding to the confusion is the fact that it’s not clear if these priorities reset upon VM shutdown or Qubes OS shutdown. So it’s entirely possible someone ends up setting a 1024 and forgetting, then whenever that VM is on it ends up hogging most resources.

This is why I’m hesitant to add your entry as-is, since the lack of guardrails means there’s potential for serious and somewhat permanent (if completely forgotten) performance degradation.

I recommend a dom0 window shortcut that only allows one VM at a time to be boosted, and shows an indicator. This UX also makes it easier to boost-when-needed and without much effort. The function you wrote can be for power users who want to set-and-forget for some VMs, have different priority tiers, etc.

You’ve contributed a ton to this thread and the community in general so I’m not really asking you, specifically, for more work; if anyone reading this can upgrade this entry I’d be grateful and you’d also get co-credit.

 

Edit: 100th post!