WSL2 Logon type problem SOLVED

About one year ago I wrote a small blog piece in Swedish regarding my problem with using WSL2 on my laptop and how to work around it by restarting the VMMS (Virtual Machine Management Service). I have been following the WSL GITHUB Issue 5401, to see if somebody would find a better solution/workaround.

After christmas (one year later) I got ”fed up” with constantly restarting the VMMS service, so I revisited the problem AND FOUND A PERMANENT SOLUTION!

The problem and solution is described in this Microsoft article for Hyper-V (I used method #3).

The solution is that your domain administrator has to add the special identity group ”NT VIRTUAL MACHINE\Virtual Machines” (SID S-1-5-83-0) to the Group Policy that modifies the ”Logon as a service” names and groups.
In my case it was the ”Default Domain Policy” that needed to be modified.

The operation (to add the special group to the GPO) has to be performed from a computer which has Hyper-V installed in some form, as the special group is local and only created when the Hyper-V functionality is enabled on the computer.

If you inspect the (fixed) Logon as service properties for the GPO from a computer without Hyper-V enabled, you will only see the Well Known SID S-1-5-83-0 in place of the group name.

This is what the group entry looks like from our domain controller

When the updated GPO has been applied to your computer, the problem is gone and you can consistently start WSL!

Home Assistant upgrade from 0.115.6 to 0.116.0

SÅ, samtidigt som jag installerade 0.115.6 så verkar det som det startades ett bygge av 0.116.0 (eller strax efteråt). Nu tänkte jag vara lite snabbare med denna uppgradering så jag hoppade på det på en gång.

Uppgraderingen såg ut att gå bra.
Nya paket vid installation:
Voluptuos 0.11.7 -> 0.12.0

Efter omstart så installeras/uppgraderas följande paket också:
home-assistant-frontend==20201001.1
python-synology==0.9.0
spotipy==2.16.0
ha-ffmpeg==2.0
HAP-python==3.0.0
PyTurboJPEG==1.4.0

Självklart så strulade även denna uppgradering efter omstart. Fick detta felmeddelande:

2020-10-08 13:22:13 ERROR (MainThread) [haffmpeg.core] FFmpeg fails [Errno 2] No such file or directory: 'ffmpeg'
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.8/site-packages/haffmpeg/core.py", line 136, in open
self._proc = await self._loop.run_in_executor(None, proc_func)
File "/home/homeassistant/.local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
result = self.fn(*self.args, **self.kwargs)
File "/home/homeassistant/.local/lib/python3.8/subprocess.py", line 854, in init
self._execute_child(args, executable, preexec_fn, close_fds,
File "/home/homeassistant/.local/lib/python3.8/subprocess.py", line 1702, in _execute_child
raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'ffmpeg'

Misstänker att det beror på att jag inte har ffmpeg installerat, så jag kör kommandot:
sudo apt install ffmpeg

Detta installerade ffmpeg 7:4.1.6-1 och ett gäng tillhörande paket.

Efter omstart igen så fungerar allt utan felmeddelanden iallafall!

Home Assistant upgrade from 0.114 to 0.115 failed (Solved)

Så var det dags för mer problem vid uppgradering av Home Assistant. Det har ju blivit så att man nästan alltid har lite ångest inför uppgradering, eftersom dokumentationen på ”breaking changes” och ”dependencies” inte är den bästa.

Uppgraderingen gick bra när jag körde kommandot ”pip install --upgrade homeassistant” (ett extra paket uppgraderades, men inga felmeddelanden alls). När jag sedan startade om Home Assistant så visade det sig att det var fler paket som behövde uppgraderas (som sker ”automatiskt” av Home Assistant) och det var här som problemen uppstod.

I loggen fick jag först felmeddelandet ”Could not build wheels for pillow which do not use PEP 517”, och lite längre ned i fel-loggen så noterade jag The headers or library files could not be found for jpeg. Det paket som uppgraderades eller installerades och ställde till problem var alltså Pillow.

Lösning

På Pillows installations-sida så kan man läsa att det är ett antal beroenden som behöver installeras för att kompilera från källkod, och eftersom felmeddelandet var att det saknades JPEG-bibliotek så körde jag detta kommando:
sudo apt install libopenjp2-7-dev libjpeg-dev
(dessa verkar vara de som är kopplade till JPEG)

Jag körde därefter kommandot (i VENV-miljön)
pip install --upgrade Pillow
och det uppgraderades då utan problem!

Efter omstart av Home Assistant så ser det ut som allt hoppade igång igen!

Radera duplikat på Synology NAS

Jag köpte en Synology DS614 på blackfriday-spektaklet och 2 stycken 6 TB diskar (Western Digital WD6TB Red). Lade direkt över alla mina olika bild-backuper på NASen och tänkte att det skulle vara en lätt och naturlig sak att hitta och rensa bort dubletter (eftersom vi har sparat bild-biblioteken på olika datorer för att ha någon typ av säkerhet).

Synology DSM har en egen funktion i ”Lagringsanalyseraren” som kan rapportera om dubletter, men det är inte riktigt vad jag var ute efter eftersom den använde filnamnet som primär nyckel (och det andra kriteriet var att det var lika stor). Det innebär ju att den inte funkar om man har döpt om filen på någon annan volym, eller om en fil av någon anledning har blivit korrupt/förändrad (vill var ahelt säker på att det är ett duplikat jag raderar).

Dessvärre så verkar det inte finnas något bra alternativ ens i Synology Community-apparna. Surfade runt lite grann, och hittade till slut ett acceptabelt alternativ, som innebär att man får installera Debian Chroot från Synology Community, och därefter köra kommandot fdupes, till en text-fil.

Utifrån den textfilen blir det en hel del manuellt arbete att hantera alla undantag (t.ex. Synologys ”@eaDir”-kataloger) och fixa, sortera och radera dubletter.

Mer info om exakt hur jag gjorde kommer i ett senare blogginlägg.

Piltangentsstyrning i VI när man redigerar en fil

 

När man redigerar en textfil med VI – man har tryck på  i (insert) eller (append) – så är det ofta så att piltangenterna inte fungerar (i de flesta linux distributionerna som jag testat). Anledningen till detta är att config-filen vimrc.tiny används, och den sätter vim-propertyn compatible.

Lösningen är att gå in och modifiera filen /etc/vim/vimrc.tiny.

I filen finns det (antagligen) en inställning där det står

set compatible

För att få piltangenterna att fungera så sätter man istället

set nocompatible

En alternativ editor är ju annars nano.