Lennart's weblog

Notes about open source software, computers, other stuff.

Page 2 of 14

Using the Lenovo Thunderbolt 3 Essential Dock with Linux

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:

Shucking hard drives

I recently bought several external hard drives. After looking around on the Internet a bit I settled for Seagate Expansion Desktop (v2) drives. I had read about these drives before and according to the internet the 10TB and larger drives have very interesting drives inside. In fact, I recently bought two 10TB versions of this drive, which contained Barracuda Pro drives (ST10000DM004). These drives are rated for 24hr/day usage, and spin at 7200 rpm so they work very well in a small NAS machine I use. At the time of writing these 10TB external drives cost around €193, whereas the bare internal drive itself costs around €290. Quite the difference! This is why people love so-called ‘shucking’: removing the drives from the enclosure and using them in e.g. their home NAS or home server.

For my annual offline backups I bough a Seagate Expansion Desktop (v2) 12TB (part nr. STEB12000400). For this drive things are even better: it contains an IronWolf Pro drive (ST12000NE008). These are true server drives rated for 24×7 use in servers of up to 24 drive bays. In fact, I use 8TB and 10TB IronWolf Pro’s in servers I use for work. Here the price difference is €210 for the external drive (a nice discount in a Dutch web shop recently) vs. €360 for the internal drive.

Of course, warranty can be an issue when shucking drives. I haven’t (yet?) had the need to return one of my shucked drives. I guess I’d have to put them back into the external enclosures. This would be possible, although I didn’t manage to remove the enclosures without damaging the little clamps that kept the lid attached to the rest of the case… But at these price differences I will take the risk (at least for personal use; professionally warranty without hassle may be worth the extra cost).

Related Images:

And… we’re back!

The title of this blog post refers to two things: first of all, it has been more than 4 years since my last post here. Incredible… Looking back, I think “too busy” is the main reason for this. Both work and private life have eaten up a lot of my ‘spare’ time. So, as many irregular bloggers do, I hereby declare that I will try to post more frequently :-).

The second reason why the title of this post is appropriate, is because the site has been down for several months (since April this year). This was because I made the stupid mistake of wanting to do too many things at the same time. Let me explain.

The webserver that served this blog was a KVM virtual machine running on my home server. The VM was running a version of Ubuntu that was EOL. Moreover, I wasn’t happy with the fact that I used the Ubuntu WordPress package, instead of using the official WordPress installation method. The main reason for my dissatisfaction came from the fact that by using the Ubuntu package I was depending on the Ubuntu packages to update the package. Which didn’t happen often enough to my liking. By using the official WordPress installation method you can configure WordPress to (semi-)automatically update itself. Much better from a security perspective.

I had already migrated my other KVM VMs to LXD containers, with those providing web servers now running behind an Apache reverse proxy setup. I wanted the same for this last remaining VM.

On top of that, the site wasn’t properly configured to use HTTPS (I think I had a self-signed certificate, but no automatic redirection of HTTP to HTTPS). Thanks to Let’s Encrypt there is no excuse for running a proper HTTPS server so users can browse your site without any eavesdropping.

So, one fine weekend in April I bit the bullet. But I bit off too much by doing it all at once: Install an Apache in a fresh LXD container, put it behind a reverse proxy, install the latest WordPress, restore the files from the old VM, all the while trying to implement an HTTP to HTTPS redirect.

Of course, that didn’t work out. The Debian/Ubuntu configuration of WordPress is different from just editing the default WordPress config file, instead Ubuntu has its own config file in /etc/, which is included in the one from WordPress. Also, it turns out that simply redirecting HTTP to HTTPS won’t work because I had ‘mixed content’ warnings all over the place. To fix those I had to do a search-replace of HTTP to the secure variant in the site’s database and to add some extra lines to the reverse proxy config (more details hopefully soon in a separate post). And then it turned out I had forgotten to enable Apache’s mod_rewrite in the LXC container… Before you know it, you loose sight of what you did, when and why. Which config file you changed, what you disabled, enabled, etc. Especially because all the digging, reading and fixing had to be spread across multiple evenings.

Nevertheless, it was a good learning experience :-). Don’t do this if you don’t have ample time for follow-up, do these kind of upgrades in steps and make a proper plan so that dependencies between the steps are clear and you have a functional setup between each step.

Looking back, the following would have been a much better battle plan then “let’s go, this shouldn’t be hard, the migrations of other VMs/services went fine”:

  • put the VM behind the reverse proxy
  • transition to Let’s Encrypt SSL certificates and set up HTTP to HTTPS redirection
  • Configure the container with the upgraded WordPress installation and migrate the data from the old VM.

There might have been some issues with outdated PHP versions in the old VM, but those could have been (probably) mitigated with some extra Ubuntu upgrades focusing only on keeping the web server alive or the use of a PPA with updated PHP package. All the while I could have at least kept the VM running (only disabling it during the times I actually worked on the upgrade). And, of course, I could have put a backup of the VM back while trying and documenting the upgrade path, but every time I nailed an issue, I expected it to be the last one.

Keep on learning!

Related Images:

Fixing Emacs tramp mode when using zsh

Today I finally took some time to fix a long-standing problem: when trying to edit a file on a remote host using Emacs tramp mode, long time-outs occurred when typing the remote file name (after hitting C-x C-f). These time-outs were so long and occurred after each key press that tramp was effectively useless.

After some digging (e.g. excluding helm as the problem source) I found this entry in the Emacs Wiki which basically told my that using zsh (the Z shell) on the remote host could be the culprit. Indeed, after adding

[[ $TERM == "dumb" ]] && unsetopt zle && PS1='$ ' && return

at the top of my ~/.zshrc file solved the problem instantly. What this line does is simply replacing the shell prompt with a very simple one (a $ followed by a space) if the terminal is of the dumb type (which is the case for tramp).

Related Images:

Installing parted during Ubuntu installation

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

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:

Converting a PDF file to a PNG file

Although ideally I try to create and use PDF files whenever I create something that is to be printed or even used on screen. It’s a universal, well defined open format. The added advantage is that is works well with vector graphics, something you really want for high quality material. However, sometimes external circumstances force you to deviate from your preferences. Yesterday I needed to import a PDF image into a LibreOffice Impress presentation. Unfortunately Impress can’t import PDF images. So I decided to convert my PDF image to a PNG file. My first idea was to use the convert utility:

convert file.pdf file.png

However, the default resolution was too low (and can be corrected using the -r option), but more importantly, I had some colour problems that I didn’t know how to correct.

I quickly looked around on the web and found this answer on superuser.com that pointed me to the pdftoppm tool. That worked brilliantly:

pdftoppm -r 1200 -png file.pdf > file.png

Related Images:

Configuring Org2blog

Yesterday I installed Org2blog, which allows me to write my blog posts in Emacs org-mode and push them to my WordPress blog from within Emacs. So far I like it a lot! One less reason to leave Emacs :-), and hopefully also a reason to blog more often. Other good things about keeping your blog posts in Emacs are:

  • You can simply export them to e.g. PDF. In my current setup it’s a easy as adding the line

    #+LATEX_CLASS: lckartcl
    

    somewhere at the top of the file (before the actual text of the post starts) to tell org-mode that it should use my personal LaTeX export style, followed by C-c C-e l o and a nicely formatted PDF of my blog post pops up.

  • You keep all your blog posts in plain text format, so if you would decide to change to a different blogging platform, uploading the old posts should be fairly easy.

Org2blog’s GitHub page mentions C-c p as prefix key for Org2blog’s functions, but in my case this prefix is already used by Projectile, and looking in Org2blog’s Customize Group I noticed that C-c M-p is an alternative prefix, so I’m using that to get the following functionality:

C-c M-p p publish buffer
C-c M-p P post buffer as page and publish
C-c M-p d post buffer as draft
C-c M-p D post buffer as page draft
C-c M-p t complete category

This is the Org2blog configuration in my .emacs file (note that I’m using John Wiegley’s use-package macro):

;;;;;;;;;;;;;;;;;;;;
;; Configure Org2blog, which allows me to write blog posts in org-mode
;; and then push them to my WordPress blog.
(use-package org2blog
  :config
  (require 'org2blog-autoloads)
  (setq org2blog/wp-blog-alist
        '(("blog.karssen.org"
           :url "https://blog.karssen.org/xmlrpc.php"
           :username "xxxxxx"
           :default-title "New blog post"
           :default-categories "Linux"
           :tags-as-categories nil)))
  )

Related Images:

Upgrading to Org-mode 8.3 via the package repository: fixing an error

Today I tried to upgrade Emacs Org-mode to version 8.3. I used the regular package upgrade, but got the following error:

Invalid function: org-babel-header-args-safe-fn

Unfortunately, Irreal’s advice to byte-compile ob-R.el (twice) didn’t work out for me (by the way: thanks Planet Emacsen for aggregating so many useful posts!).

Browsing through some discussions on the emacs-orgmode mailing list it seemed that the error was due to org-mode being loaded while reinstalling the package. So I did the following:

  • I started emacs without loading my personal settings: emacs -Q
  • Next I ran the following code from my .emacs file in the scratch buffer (M-x eval-region) to set up the package manager:

    (require 'package)
    (package-initialize)
    ;; Add the original Emacs Lisp Package Archive
    (add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/") t)
    ;; Add the user-contributed repository
    (add-to-list 'package-archives
                 '("marmalade" . "http://marmalade-repo.org/packages/"))
    
  • And finally I used the package manager to remove and then install the latest org package.

    Now all is fine again! 🙂

    And by the way: this is my first blog post using Org2blog!

Related Images:

Experimenting with Google’s AdSense

I don’t think this blog has any regular readers (especially since I’m not posting very regularly), but if they would exist they would have noticed two prominent changes in the last two days:

  1. the WordPress theme for the site has changed, and
  2. this blog now has several advertisements from Google’s AdSense programme.

Obviously, the two changes are tied together. From almost the first day of this blog’s existence I had been using the Carrington theme, and although I still like it a lot (including the fact that it has two columns on the left), its appearance on mobile devices was sub-par. To fix this I looked around for a theme with “responsive design” and the current one looks quite nice both on my desktop machines and on my phone.

Changing themes had been on my list for quite some time, but the reason that I took the time to actually do it was because of my idea to play around a bit with Google’s AdSense program. Apparently, Google likes it if a site looks well on all platforms. The main reason to add ads to this blog was to experiment a bit and simply to see if this is a viable way of recouping (some of) the costs associated with hosting this blog. I’ve got a decent number of monthly views (at least I think it’s decent 🙂 and it’s definitely more than I expected when I started out) so why not give it a try. Moreover, since this is my personal, low profile site, it can also give me an idea if it’s worth having advertisements on some of the community sites that I run.

So, all in all, I think the theme change is definitely a good one, and about the ads, we’ll see. Maybe it works out, maybe it doesn’t. All in all I hope they don’t interfere too much with normal reading of the site.

Related Images:

« Older posts Newer posts »

© 2024 Lennart's weblog

Theme by Anders NorénUp ↑