Lennart's weblog

Notes about open source software, computers, other stuff.

Tag: Ubuntu (Page 1 of 5)

Pinning the Wine package version so I can keep using the reMarkable Windows app

5 January 2025 / / 0 Comments

Back in January 2021 I ordered the reMarkable 2 e-paper note-taking “tablet”. I use it for two things: making notes and reading and annotating PDFs. Especially the note taking has changed significantly my working environment: no more stacks of paper notes lying all over my desk. No more trying to find a certain note in a notebook or on a piece of paper.

I do miss using my fountain pen, but the advantages, including having all your notes with you on your phone outweighs this. And, although the remarkable itself runs Linux, there is no Linux version of the desktop app. Unfortunately.

For some time I used community-developed tools, mainly to up- and download PDFs to and from the device. However, as the reMarkable software and file format evolved, more and more things stopped working, so I had to shift to another solution. I managed to install the Windows application in Wine. This works well and also allows me to e.g. share my reMarkable screen in video calls.

A few weeks ago, however, the app failed to start. I wasn’t sure if this was due to an update of the remarkable app itself or because the Wine version in Ubuntu 24.04 was upgraded from version 9.22 to 10.0rc2. It turned out to be the latter because my laptop definitely had an older (previously known good) version of the app that hadn’t been updated. Updating the Wine winehq-devel package, however, broke the app (a bug has been reported, see the list of links below).

Now, as you may have noted above, I was using the winehq-devel package, so I thought it was as simple as switching to the winehq-stable package. Unfortunately, that package is not available in Ubuntu 24.04. While looking for deb packages I found that the Wine HQ repo contained older package versions. So I decided to use the package pinning functionality of the Apt packaging system. I created the file /etc/apt/preferences.d/wine with the following contents: 

Package: winehq-devel
Pin: version 9.*
Pin-Priority: 1000

Package: wine-devel
Pin: version 9.*
Pin-Priority: 1000

Package: wine-devel-amd64
Pin: version 9.*
Pin-Priority: 1000

Package: wine-devel-i386:i386
Pin: version 9.*
Pin-Priority: 1000

I determined the required package names by starting with the first one and then kept trying to install the winehq-devel package until it actually finished successfully. I set the pin priority to 1000, which means “causes a version to be installed even if this constitutes a downgrade of the package”, according to the apt_preferences man page. And, indeed, that is what Apt proposes: 

The following additional packages will be installed:
  wine-devel wine-devel-amd64 wine-devel-i386:i386
The following NEW packages will be installed:
  winehq-devel
The following packages will be DOWNGRADED:
  wine-devel wine-devel-amd64 wine-devel-i386:i386
0 upgraded, 1 newly installed, 3 downgraded, 0 to remove and 15 not upgraded.
Need to get 229 MB of archives.
After this operation, 8.414 kB disk space will be freed.
Do you want to continue? [Y/n]

For completeness, these are the Wine packages that are currently installed on my system: 

ii  wine-devel                                       9.22~noble-1                                amd64        WINE Is Not An Emulator - runs MS Windows programs
ii  wine-devel-amd64                                 9.22~noble-1                                amd64        WINE Is Not An Emulator - runs MS Windows programs
ii  wine-devel-i386:i386                             9.22~noble-1                                i386         WINE Is Not An Emulator - runs MS Windows programs
ii  winehq-devel                                     9.22~noble-1                                amd64        WINE Is Not An Emulator - runs MS Windows programs

As a side note, in order to make sure no other Wine settings were influencing my tests, I installed the reMarkable application in a fresh, dedicated WINEPREFIX: 

WINEPREFIX=~/reMarkable/ wine ~/tmp/Downloads/reMarkable-3.16.1.901-win64.exe

After which I could start the application like this: 

WINEPREFIX=~/reMarkable/ wine ~/reMarkable/drive_c/Program\ Files\ \(x86\)/reMarkable/reMarkable.exe

After this fresh install, the Gnome shell menu entry for the app didn’t work any more, so I had a look at the corresponding .desktop file in ~/.local/share/applications/wine/Programs/reMarkable/reMarkable.desktop. After some playing around I guess the problem was in missing double quotes around the path to the .exe file. The following works: 

[Desktop Entry]
Name=reMarkable
Exec=env WINEPREFIX="/home/lennart/reMarkable" wine "/home/lennart/reMarkable/drive_c/Program Files (x86)/reMarkable/reMarkable.exe"
Type=Application
StartupNotify=true
Path=/home/lennart/reMarkable/dosdevices/c:/Program Files (x86)/reMarkable
Icon=94BF_reMarkable.0
StartupWMClass=remarkable.exe

Related Images:

Fixing absence of 5.1 surround sound options on an AMD Linux laptop

19 October 2024 / / 0 Comments

Ever since I had my new laptop (a Thinkpad T14s Gen4 AMD, bought in November 2023, currently running Ubuntu 24.04.1), I had tried to use it to play some movies with 5.1 surround sound via its HDMI port (connected to my 5.1 receiver), but I had never managed to make that work. Whereas on other systems the pavucontrol utility shows an HDMI 5.1 option (among others), no such thing was shown on this machine. It only showed “Play HiFi quality Music” and a “Pro Audio” option, neither of which mentioned anything about 5.1 surround sound. Moreover, the Ubuntu sound settings panel only showed the stereo option for speaker testing.

All those times before I had taken a quick look around the web to see if someone had written about a way to fix this. That didn’t seem to be the case and, given that my goal at those times was to watch a film, I usually switched to an alternative way to do that.

Until tonight. With some time to spare and no immediate intention to watch a film, I thought I’d try to see if I could dig a bit deeper. Surprisingly, this time it took me less than 10 minutes to find a forum post that helped me out.

In this topic on the Linux Mint forum user silmaril describes the same problem as I had, as well as the solution. Apparently, the ALSA Use Case Manager, or alsa-ucm tries to be smart and offer the right kind of configuration, but fails. In the solution they point to this page on the Arch wiki, which describes how to fix this. However, user silmaril took a more drastic route and simply used APT to remove the alsa-ucm-conf package. I did the same and after a 

systemctl --user restart pipewire

The regular HDMI stereo and surround devices popped up in pavucontrol, and a test with a 5.1 film via VLC worked just fine.

No idea why I hadn’t found that topic on the Linux Mint forum before…

Related Images:

Telling update-grub to ignore my ZFS backups

18 October 2024 / / 0 Comments

As I was running some manual package upgrades on my Ubuntu 24.04 server, I noticed that a kernel upgrade led to a long series of kernels being listed. This was strange, as there should have been only two or three. Closer inspection revealed that the update-grub command tries to find all kernels and also looks for kernels on ZFS datasets. Given that I extensively use ZFS, I was aware of that, and normally this is the behaviour I want.

However, in this case, my home server doesn’t have root on ZFS, but on a regular MD RAID mirror with LVM. Looking at the kernels listed during the upgrade, I noticed that update-grub was digging through all ZFS datasets and their snapshots on the server, including the backups sent to my home server from various other machines, some of which do have root on ZFS. All in all this led to a huge list of kernels and a kernel upgrade process that never seemed to end.

A quick web search pointed me to this AskUbuntu.com answer, which showed that the ZFS parsing code can be found in /etc/grub.d/10_linux_zfs. In there, I found the following code block (note, for improved readability I split the long command above the done over multiple lines and added corresponding \): 

# List all the dataset with a root mountpoint
get_root_datasets() {
    local pools="$(zpool list | awk '{if (NR>1) print $1}')"

    for p in ${pools}; do
        local rel_pool_root=$(zpool get -H altroot ${p} | awk '{print $3}')
        if [ "${rel_pool_root}" = "-" ]; then
            rel_pool_root="/"
        fi

        zfs list -H -o name,canmount,mountpoint -t filesystem | \
            grep -E '^'"${p}"'(\s|/[[:print:]]*\s)(on|noauto)\s'"${rel_pool_root}"'$' | \
            awk '{print $1}'
    done
}

This function first lists all the ZFS pools on the system and then (with the last, long command above the done), for each of those, returns the filesystem datasets that can be mounted.

The solution was simple: because all backups from external systems end up as datasets below the remote_backups dataset on my storage pool, simply changed the last awk statement so that it only prints datasets that don’t match remote_backups by adding $1 !~ "remote_backups": 

zfs list -H -o name,canmount,mountpoint -t filesystem | \
    grep -E '^'"${p}"'(\s|/[[:print:]]*\s)(on|noauto)\s'"${rel_pool_root}"'$' | \
    awk '$1 !~ "remote_backups" {print $1}'

This way, the code would still work if I ever move this system to have root on ZFS, but now update-grub skips all backups and finds only the kernels relevant for my home server :-).

Related Images:

Fixing delayed syncing with Linux Nextcloud client

30 January 2024 / / 0 Comments

Recently, I noticed that changed files were not picked up by the Nextcloud client as fast as before. As a result I sometimes missed a file (or changes in a file) on my laptop that had been created on my desktop PC.

Today, I tried to run tail and got the following message: 

tail: inotify resources exhausted
tail: inotify cannot be used, reverting to polling

This made me realise that the problem with the delayed client sync could be related to the inotify system for monitoring file changes.

It turns out there is a maximum to the number of inotify file watches: 

sysctl fs.inotify

fs.inotify.max_queued_events = 16384
fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 524288

Given that on my desktop the Nextcloud client syncs about 235 GB with my personal Nextcloud server and about 10 GB to two servers for work (including several Git repositories), I could imagine the 65536 watches is not enough. Indeed, manually increasing that number made file syncs more or less instantaneous again: 

sysctl -n -w fs.inotify.max_user_watches=524288
sysctl fs.inotify

524288
fs.inotify.max_queued_events = 16384
fs.inotify.max_user_instances = 128
fs.inotify.max_user_watches = 524288

To make these changes permanent I added the following lines at the bottom of /etc/sysctl.conf: 

grep -A1 inotify /etc/sysctl.conf

# Increase the number of inotify watches so that the Nextcloud client
# keeps syncing without delay
fs.inotify.max_user_watches=524288

Side note: to apply the changes in the /etc/sysctl.conf file use sudo sysctl -p.

Related Images:

Upgrading nodejs to the latest LTS release on Ubuntu 21.10

31 May 2022 / / 0 Comments

Today I upgraded the Bash language server (to v3.0.3), after which I noticed that it stopped working. When loading a .bash file, the language server didn’t load and told me to look in the error output for more information. In Emacs, the errors of the Bash language server can be found in the *bash-ls::stderr* buffer, which showed me: 

/home/lennart/.emacs.d/.cache/lsp/npm/bash-language-server/lib/node_modules/bash-language-server/node_modules/vscode-jsonrpc/lib/common/linkedMap.js:40
        return this._head?.value;
                          ^

SyntaxError: Unexpected token '.'
    at wrapSafe (internal/modules/cjs/loader.js:915:16)
    at Module._compile (internal/modules/cjs/loader.js:963:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
    at Function.Module._load (internal/modules/cjs/loader.js:708:14)
    at Module.require (internal/modules/cjs/loader.js:887:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (/home/lennart/.emacs.d/.cache/lsp/npm/bash-language-server/lib/node_modules/bash-language-server/node_modules/vscode-jsonrpc/lib/common/api.js:37:21)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)

I re-ran lsp-install-server, which pointed out that I had nodejs v12.22.5 installed and the language server required v14 or higher.

Time to figure out how to install a newer nodejs version on my Ubuntu 21.10 machine. It turns out that v12 is no longer maintained. The current LTS version of nodejs is v16. Here I found instructions on how to install a given version of nodejs on Ubuntu. For v16, this boils down to running 

curl -sL https://deb.nodesource.com/setup_16.x | sudo bash -

The script that this command fetches (and executes as root) is quite elaborate, but in the end it simply creates the file /etc/apt/sources.list.d/nodesource.list, with the following contents: 

deb [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_16.x impish main
deb-src [signed-by=/usr/share/keyrings/nodesource.gpg] https://deb.nodesource.com/node_16.x impish main

After that, a simple apt upgrade didn’t suffice. The nodejs upgrade was held back because of a dependency problem. Even an explicit upgrade of the nodejs package didn’t work: 

$ sudo apt upgrade nodejs
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies.
 libnode72 : Conflicts: nodejs-legacy
E: Broken packages

So, I resorted to a full apt dist-upgrade, which worked fine. After that, I reopened a Bash script and all was fine.

Related Images:

Opening Emacs (-client) windows with full screen height

10 November 2021 / / 0 Comments

I usually want my Emacs windows, including those opened via emacsclient, to be opened using the full screen height. It turns out that Emacs has a command line option for this:

emacs --fullheight

Now, for emacsclient this option doesn’t exist, so how can we solve this? Looking around the web, I found this answer on Emacs StackExchange that explained how to do this from within Emacs (see also the fullscreen option on the corresponding page in the Emacs manual). Combined with this answer on StackOverflow that shows how to use the -F/--frame-parameters option of emacsclient I managed to open a full-height Emacs client window:

emacsclient --create-frame --frame-parameters="'(fullscreen . fullheight)"

Most of the time I open new Emacs (-client) windows using the button in Ubuntu’s/Gnome shell’s dock. So how do we incorporate the aforementioned options in the relevant .desktop file? Before explaining how I did this, I have to mention that I don’t use a pre-packaged version of Emacs. As of this writing Emacs v27.2 is the latest official release, but I have been compiling Emacs from source for about two years now. About a month ago I compiled Emacs from the emacs-28 branch 1, which contains what will become Emacs v28. In this branch the .desktop files used by Gnome for its list of applications (including the icons/launchers that end up in the Gnome shell dock) have received some love. For example, the emacsclient.desktop file now opens a regular Emacs at first launch, but subsequent clicks on the icon will launch an Emacs client window. Right-clicking on the icon shows an option called “New Instance”, which will do as it says: launch a new Emacs instance. Well done Emacs maintainers! This perfectly fits my workflow, where most of the time I want to open a client window, but sometimes want to open a new Emacs instance (e.g. when I don’t want to clutter my regular workspaces).

So, getting back to the fullheight topic, editing the emacsclient.desktop file seemed like the way to go. Given that I compile Emacs from source and do not install it system-wide (I used the --prefix=/home/$USER/.local option when running ./configure), the .desktop files can be found in ~/.local/share/applications. This is the contents of the emacsclient.desktop file before I edited it:

[Desktop Entry]
Name=Emacs (Client)
GenericName=Text Editor
Comment=Edit text
MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" %F
Icon=emacs
Type=Application
Terminal=false
Categories=Development;TextEditor;
StartupNotify=true
StartupWMClass=Emacs
Keywords=emacsclient;
Actions=new-window;new-instance;

[Desktop Action new-window]
Name=New Window
Exec=/home/lennart/.local/bin/emacsclient --alternate-editor= --create-frame %F

[Desktop Action new-instance]
Name=New Instance
Exec=emacs %F

After my edits, this is the contents of the file:

[Desktop Entry]
Name=Emacs (Client)
GenericName=Text Editor
Comment=Edit text
MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor=  --frame-parameters=\\"'(fullscreen . fullheight)\\" --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame --frame-parameters=\\"'(fullscreen . fullheight)\\"; fi" %F
Icon=emacs
Type=Application
Terminal=false
Categories=Development;TextEditor;
StartupNotify=true
StartupWMClass=Emacs
Keywords=emacsclient;
Actions=new-window;new-instance;

[Desktop Action new-window]
Name=New Window
Exec=/home/lennart/.local/bin/emacsclient --alternate-editor= --create-frame --frame-parameters="'(fullscreen . fullheight)" %F

[Desktop Action new-instance]
Name=New Instance
Exec=emacs --fullheight %F

The diff is:

@@ -3,7 +3,7 @@
 GenericName=Text Editor
 Comment=Edit text
 MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
-Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor= --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame; fi" %F
+Exec=sh -c "if [ -n \\"\\$*\\" ]; then exec emacsclient --alternate-editor=  --frame-parameters=\\"'(fullscreen . fullheight)\\" --display=\\"\\$DISPLAY\\" \\"\\$@\\"; else exec emacsclient --alternate-editor= --create-frame --frame-parameters=\\"'(fullscreen . fullheight)\\"; fi" %F
 Icon=emacs
 Type=Application
 Terminal=false
@@ -15,8 +15,8 @@

 [Desktop Action new-window]
 Name=New Window
-Exec=/home/lennart/.local/bin/emacsclient --alternate-editor= --create-frame %F
+Exec=/home/lennart/.local/bin/emacsclient --alternate-editor= --create-frame --frame-parameters="'(fullscreen . fullheight)" %F

 [Desktop Action new-instance]
 Name=New Instance
-Exec=emacs %F
+Exec=emacs --fullheight %F

One final note: for those who don’t use the Emacs client, there is also the emacs.desktop file, with the same icon. You can find out which one is in your Gnome shell dock by running:

gsettings get org.gnome.shell favorite-apps

which returns a list like this:

['org.gnome.Terminal.desktop', 'thunderbird.desktop', 'firefox.desktop', 'emacsclient.desktop']

If you’d like to edit this variable manually, you can use either dconf-editor to edit org/gnome/shell/favorite-apps, or set it directly:

gsettings set org.gnome.shell favorite-apps "['org.gnome.Terminal.desktop', 'thunderbird.desktop', 'firefox.desktop', 'emacs.desktop']"

Note, the order of the list matters!

Footnotes:

1

The commit I used was d86b2e59c.

Related Images:

Use a script to convert Office files to PDF via Nautilus’ right-click menu

28 June 2021 / / 0 Comments

Recently, I bought a reMarkable 2, a tablet-like device with an e-ink screen that allows me to replace real paper with digital note taking, while keeping the hand-written aspect of writing notes. The device also allows me to read and annotate PDFs in a comfortable way. Given that I use RMfuse to ‘mount’ the reMarkable cloud on my computer, I normally drag-n-drop the files I want to read in GNOME Files (formerly Nautilus, GNOME’s file manager) from their location on my computer to the mounted cloud.

This works really well so far. However, I also regularly receive files in the MS Office .docx format. Often I need to make substantial changes in these documents, which I do on my laptop or computer. But sometimes I only need to read them or only put my signature at the bottom. For these cases I would open the .docx file in LibreOffice, convert it to PDF and copy it to my reMarkable. In order to speed this up, I thought it would be nice to have some way where I right-click on a .docx file in GNOME Files/Nautilus and then convert it to PDF automatically, after which I can drag-n-drop the PDF file to the mounted reMarkable cloud.

So the question was: how can I add an item to the right-click menu of Nautilus, which runs a script when I click on it. After looking around on the internet, this turned out to be quite easy. It turns out that scripts placed in ~/.local/share/nautilus/scripts/ end up in the Nautilus right-click menu under the Scripts submenu.

To do the actual conversion to PDF, I created the following script: 

#!/bin/bash
# This script converts the selected file to PDF using LibreOffice
# For general instructions on how to use Nautilus scripts, see
# https://help.ubuntu.com/community/NautilusScriptsHowto
#
# Save this script in ~/.local/share/nautilus/scripts/ and make it
# executable.

IFS_BAK=$IFS
IFS="
"

for SelectedFile in ${NAUTILUS_SCRIPT_SELECTED_FILE_PATHS}; do
    soffice \
        --nodefault \
        --nolockcheck \
        --nologo \
        --norestore \
        --nofirststartwizard \
        --convert-to pdf "${SelectedFile}"
done

IFS=$IFS_BAK

Because I wanted to be able to select multiple files, some having spaces in their names, I had to make sure the space character wasn’t used to split the NAUTILUS_SCRIPT_SELECTED_FILE_PATHS variable. That is why I temporarily replace the IFS variable with a newline.

I have only tried this on .docx files so far, but I guess it would work on presentations and spreadsheets as well.

Related Images:

Ubuntu Thunderbolt settings

Using the Lenovo Thunderbolt 3 Essential Dock with Linux

5 January 2021 / / 1 Comment

Today the Lenovo Thunderbolt 3 Essential dock I had ordered just before the new year arrived. My current laptop is a 6th Gen Lenovo Thinkpad X1 Carbon, which actually has two Tunderbolt 3 (TB3) ports. For a while the cable mess on my desk had been bothering me and a dock looked like a good way to get rid of both the clutter and the fact that I had to plug in a power cable, an HDMI cable, a USB cable and a network cable. The latter was especially tricky, because my laptop doesn’t have a dedicated ethernet port, but instead has a dongle that plugs into one of the TB3 ports. Of course, I didn’t want it to happen that I was on the road without the dongle, so double checking and making sure I had it in my bag was a regular worry.

With the TB3 Essential dock all this should be over. The dock is pretty well equipped:

  • 1 ethernet port (1Gbps)
  • 1 HDMI 2.0 port
  • 1 DisplayPort 1.4
  • 2 USB A 3.0 1.5Gbps ports
  • 2 USB C 10Gbps ports (no video support)
  • 1 3.5 mm audio jack.

The one thing that remained to be seen, of course, was whether the all those ports would work under Linux as well. I read some promising reports for other TB3-based docks from Lenovo, so I decided to order it.

After connecting the various cables to the dock came the moment supreme: I plugged in the TB3 cable to the laptop. And… The display connected to the HDMI port lit up. So far, so good! No USB functionality, however. Time to dive into the BIOS, because I remembered having seen some settings there, including some security related ones.

In the BIOS I couldn’t change the TB3 security setting because, as the help message explained, the graphics memory was set to 512MB. I’m not sure why this is an issue, but I looked up the graphics RAM setting and reduced it to 256MB. Next, I went back to the TB settings and set the security level to the first option: “No security”, followed by a reboot. Now, everything worked. That is one step in the right direction.

However, I wasn’t willing to forgo all security, so I went back to the BIOS settings and set the security level to “Secure Connection” (according to this blog post at dell.com this is security level 2 or SL2). I rebooted and indeed, no USB. So I went to Ubuntu’s Thunderbolt settings and there I had to press the ‘Unlock’ button in the top right corner, after which I could click on a button authorise the dock. After that all connections worked again. From the commandline, the boltctl utility can be used to see more information on the connected thunderbolt devices. This is the output for an unauthorised device:

$ boltctl list
? Lenovo Thunderbolt 3 Essential Dock
  ?? type:          peripheral
  ?? name:          Thunderbolt 3 Essential Dock
  ?? vendor:        Lenovo
  ?? uuid:          00b00089-417d-0801-ffff-ffffffffffff
  ?? status:        connected
  ?  ?? domain:     ca030000-0070-6f08-2382-4312b0238921
  ?  ?? authflags:  none
  ?? connected:     ma 04 jan 2021 16:26:45 UTC
  ?? stored:        ma 04 jan 2021 16:20:57 UTC
     ?? policy:     iommu
     ?? key:        no

And this is the output after clicking the “Authorise” button in the Ubuntu settings:

? boltctl list
? Lenovo Thunderbolt 3 Essential Dock
  ?? type:          peripheral
  ?? name:          Thunderbolt 3 Essential Dock
  ?? vendor:        Lenovo
  ?? uuid:          00b00089-417d-0801-ffff-ffffffffffff
  ?? status:        authorized
  ?  ?? domain:     ca030000-0070-6f08-2382-4312b0238921
  ?  ?? authflags:  none
  ?? authorized:    ma 04 jan 2021 16:30:07 UTC
  ?? connected:     ma 04 jan 2021 16:26:45 UTC
  ?? stored:        ma 04 jan 2021 16:20:57 UTC
     ?? policy:     iommu
     ?? key:        yes (new)

Nice!

However, my joy was shortlived, because after disconnecting and reconnecting the dock, the USB ports had stopped working again. The device had to be authorised again. This seemed tedious, so I set about reading more in the boltctl man page and found that there was a way to enroll a device permanently. So that is what I did. First I removed its UUID from the database:

$ boltctl forget 00b00089-417d-0801-ffff-ffffffffffff

And then added it again, this time with the auto policy:

$ boltctl enroll --policy auto 00b00089-417d-0801-ffff-ffffffffffff
 ? Lenovo Thunderbolt 3 Essential Dock
   ?? type:          peripheral
   ?? name:          Thunderbolt 3 Essential Dock
   ?? vendor:        Lenovo
   ?? uuid:          00b00089-417d-0801-ffff-ffffffffffff
   ?? dbus path:     /org/freedesktop/bolt/devices/00b00089_417d_0801_ffff_ffffffffffff
   ?? status:        authorized
   ?  ?? domain:     ca030000-0070-6f08-2382-4312b0238921
   ?  ?? parent:     ca030000-0070-6f08-2382-4312b0238921
   ?  ?? syspath:    /sys/devices/pci0000:00/0000:00:1d.0/0000:05:00.0/0000:06:00.0/0000:07:00.0/domain0/0-0/0-1
   ?  ?? authflags:  secure
   ?? authorized:    ma 04 jan 2021 22:33:08 UTC
   ?? connected:     ma 04 jan 2021 22:32:43 UTC
   ?? stored:        ma 04 jan 2021 16:20:57 UTC
      ?? policy:     auto
      ?? key:        yes

As you can see from the boltctl list output below, the policy is now set to auto (instead of the previous iommu):

$ boltctl list
 ? Lenovo Thunderbolt 3 Essential Dock
   ?? type:          peripheral
   ?? name:          Thunderbolt 3 Essential Dock
   ?? vendor:        Lenovo
   ?? uuid:          00b00089-417d-0801-ffff-ffffffffffff
   ?? status:        authorized
   ?  ?? domain:     ca030000-0070-6f08-2382-4312b0238921
   ?  ?? authflags:  secure
   ?? authorized:    ma 04 jan 2021 22:41:46 UTC
   ?? connected:     ma 04 jan 2021 22:41:45 UTC
   ?? stored:        ma 04 jan 2021 16:20:57 UTC
      ?? policy:     auto
      ?? key:        yes

Now I can disconnect and reconnect the dock without problems :-).

I also tested the 3.5mm audio port, which worked (at least for listening, I didn’t have a headset with microphone at hand). Same for the two USB A and the two USB C ports. Finally, I tested the DisplayPort and that worked too. In fact, connecting my 3440×1440 screen via both HDMI and DP to the dock worked fine. The Ubuntu display settings showed a “3 monitor” setup, two 3440×1440 screens and the latop’s own screen at 2560×1440.

So, in conclusion: the Lenovo Thunderbolt 3 Essential dock is fully supported under Ubuntu 20.04.

Thanks to this blog post at FunnelFiasco.com for pointing me to the boltctl utility!

Related Images:

Installing parted during Ubuntu installation

22 February 2016 / / 0 Comments

When installing Ubuntu (I guess a regular Debian installation won’t be any different), I sometimes would like to manually create or change partitions (by jumping to another terminal, e.g. using Alt-F2) before doing the actual install. My preferred tool for that is parted, however, on regular Ubuntu installation images (at least the server variety), parted isn’t available from the console by default.

Today I noticed that (at least on today’s daily image of Ubuntu 16.04 Xenial), a udeb file for parted is available. This is how you install it: 

udpkg -i /cdrom/pool/main/p/parted/parted-udeb_3.2-15_amd64.udeb

after which you can use parted to your heart’s content.

For more information on udebs see the Debian Installer Internals documentation.

Related Images:

Setting the console font when using an nVidia card

17 October 2015 / / 0 Comments

Even though I do most of the work I do on my workstation in a graphical desktop environment, I sometimes want or need to switch to one of the virtual terminals (consoles), for example when trying to fix a connection problem or hanging desktop environment.

Whenever I had to do this I was always bothered by the fact that the font was so large (or, the other way around, the resolution so low). What made my annoyance worse was that I knew from my early Linux days So, instead of being annoyed I decided to fix this. Thanks to the help of mchid on unix.stackexchange.com I solved in a matter of minutes. The tricky part for me was to realise I am using an nVidia graphics card, which means things are just a little bit different than normally.

Just in case StackExchange ever goes down or this answer gets lost I will reproduce it below.

For newer Debian & Ubuntu distros using nvidia, I had to do the following: First, edit /etc/default/grub. Change the following line: 

#GRUB_GFXMODE=640x480

to this: 

GRUB_GFXMODE=1920x1200
GRUB_GFXPAYLOAD_LINUX=keep

replacing 1280×800 with the desired resolution.

Then: 

echo "echo FRAMEBUFFER=y" | sudo tee /etc/initramfs-tools/conf.d/splash
sudo update-initramfs -u
sudo update-grub

To simply change the font size, you can do so using the following command: 

sudo dpkg-reconfigure console-setup

Related Images:

« Older posts

Archives

© 2025 Lennart's weblog

Theme by Anders Norén — Up ↑