lightdm greeter i czarny ekran

Od dłuższego czasu lightdm płata mi figla, otóż na dwóch rożnych konfiguracjach sprzętowych wygaszenie/zablokowanie ekranu nie radzi sobie z powrotem na dobre tty gdzie działa lightdm.

Przez pewnie czas olewałem, przyzwyczaiłem się do przełączania na szybko konsoli aby wrócić na odpowiednią, przez pewnie czas korzystałem z xscreensavera, przez pewnie czas ustawiałem presentation mode i w ogóle nie blokowałem ekranu, zmieniałem greeter’a.

W miedzy czasie oczywiście bugi, fora i inne zakamarki internetu, i nic. Minęło dobrych kilka miesięcy i nadal nic, już zdążyłem się przyzwyczaić do slick-greetera zamiast defaultowego lightdm-gtk-greetera ale na prawdę nie daje mi to spokoju. Może się kiedyś doczekam odpowiedzi.

Ku pamięci, gdybym kiedyś miał ten sam problem:

# grep slick /etc/lightdm/lightdm.conf 
greeter-session=slick-greeter
# dpkg -l|grep greeter
ii slick-greeter 1.2.4-2 amd64 Slick-looking LightDM greeter

Realtek RTL8192CU powersaving

Pomimo iż iwconfig pokazuje power management jako off okazuje się, że z defaultu jest jednak włączone co skutkuje wyłączaniem adaptera po nieaktywności.

pi@raspberrypi:~ $ sudo iwconfig wlan0 
wlan0     IEEE 802.11bgn  ESSID:"pakosowo_2G"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 18:31:BF:36:E5:68   
          Bit Rate:144.4 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=100/100  Signal level=69/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

pi@raspberrypi:~ $ cat /sys/module/8192cu/parameters/rtw_power_mgnt
1

Power saving należy ręcznie wyłączyć w:

pi@raspberrypi:~ $ cat /etc/modprobe.d/8192cu.conf
# Disable power saving
options 8192cu rtw_power_mgnt=0

cron-apt

Im więcej mamy pod opieką serwerów bądź też nie logujemy sie na nie codziennie warto wiedzieć kiedy pojawią się jakieś aktualizacje. Tym bardziej gdy (jak ja) nie jesteśmy zwolennikami automatycznych aktualizacji.
Z pomocą przychodzi cron-apt, aplikacja która jak nazwa sugeruje wg ustawień crona sprawdza bądź aktualizuje nasz system, do tego dochodzi opcja powiadomień mailowych.

Instalacja:

apt install cron-apt

Konfiguracja (najprostrza – powiadomienie na mail o dostępnych aktualizacjach):

cat /etc/cron-apt/config
# Configuration for cron-apt. For further information about the possible
# configuration settings see /usr/share/doc/cron-apt/README.gz.
MAILTO="user@mail.com"
MAILON="upgrade"

Kiedy odpalamy:

cat /etc/cron.d/cron-apt 
#
# Regular cron jobs for the cron-apt package
#
# Every night at 4 o'clock.
0 4 * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
# Every hour.
# 0 * * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2
# Every five minutes.
# */5 * * * * root test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config2

Inne opcje:

/usr/share/doc/cron-apt/README.gz

 

Thunderbird: Tries to migrate non-existing .icedove folder

#857112 bug uniemożliwia uruchomienie thunderbirda, póki zaktuaizowana paczka nie pojawi się w reozytorium można ręcznie zastosować workaround:

This is due to an error in the script/usr/bin/thunderbird:
You cannot use the \ to merge multiple lines AND have a comment:
ie:
elif { [ -d "${ID_PROFILE_FOLDER}" ] || [ -L "${ID_PROFILE_FOLDER}" ]; } && \
# .icedove exists as folder or symlink
     { [ -d "${TB_PROFILE_FOLDER}" ] || [ -L "${TB_PROFILE_FOLDER}" ]; } && \
# .thunderbird exists as folder or symlink
       [ "$(readlink -e "${TB_PROFILE_FOLDER}")" != "${ID_PROFILE_FOLDER}" ];
then  # compare if canonical name of both folders equal

Workaround is to remove the comments on those two lines (Anything after \).

Bumblebee – [ERROR]Cannot access secondary GPU – error: [XORG] (EE) Failed to load module „nvidia” (module does not exist, 0)

W sidzie napotkałem ostatnio na wywalenie się bumblebee mimo iż wszystko było wedle starej acz dobrej konifguracji, czyli moduły zbudowane:

    bbswitch, 0.8, 4.6.0-1-amd64, x86_64: installed
    bbswitch, 0.8, 4.8.0-1-amd64, x86_64: installed
    nvidia-current, 367.57, 4.6.0-1-amd64, x86_64: installed
    nvidia-current, 367.57, 4.8.0-1-amd64, x86_64: installed

Poprawnie skonfigurowany /etc/bumblebee.conf/bumblebee.conf.conf z:

Driver=nvidia
KernelDriver=nvidia-current

oraz /etc/bumblebee/xorg.conf.nvidia:

BusID "PCI:07:00:0"

A przy starcie krzyczał, że nie może sobie załadować modułu nvidia:

optirun --status
Bumblebee status: Ready (3.2.1). X inactive. Discrete video card is off.

optirun -vvv glxgears
[ 4067.950712] [DEBUG]Reading file: /etc/bumblebee/bumblebee.conf
[ 4067.950993] [INFO]Configured driver: nvidia
[ 4067.951137] [DEBUG]optirun version 3.2.1 starting...
[ 4067.951146] [DEBUG]Active configuration:
[ 4067.951149] [DEBUG] bumblebeed config file: /etc/bumblebee/bumblebee.conf
[ 4067.951153] [DEBUG] X display: :8
[ 4067.951156] [DEBUG] LD_LIBRARY_PATH: /usr/lib/x86_64-linux-gnu/nvidia:/usr/lib/i386-linux-gnu/nvidia:/usr/lib/nvidia
[ 4067.951160] [DEBUG] Socket path: /var/run/bumblebee.socket
[ 4067.951163] [DEBUG] Accel/display bridge: auto
[ 4067.951170] [DEBUG] VGL Compression: proxy
[ 4067.951176] [DEBUG] VGLrun extra options:
[ 4067.951180] [DEBUG] Primus LD Path: /usr/lib/x86_64-linux-gnu/primus:/usr/lib/i386-linux-gnu/primus:/usr/lib/primus:/usr/lib32/primus
[ 4067.951224] [DEBUG]Using auto-detected bridge primus
[ 4068.128154] [INFO]Response: No - error: [XORG] (EE) Failed to load module "nvidia" (module does not exist, 0)

[ 4068.128165] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Failed to load module "nvidia" (module does not exist, 0)

[ 4068.128170] [DEBUG]Socket closed.
[ 4068.128185] [ERROR]Aborting because fallback start is disabled.
[ 4068.128187] [DEBUG]Killing all remaining processes.

lsmod|grep nvid
nvidia              11485184  0

Pomimo iż oczywiście się załadował. Po dłuższej dłubaninie i pytaniach w internetach doszedłem, że sterowniki z w tej wersji w sidzie jakieś niedorobione są i wystarczy zainstalować je z experimentala.

install -t experimental nvidia-driver

Po tym jak ręką odjął, wszystko działa 🙂

nixnote2 beta 5

Dawno brakowało mi jakiegoś klienta z gui do evernote na linuxie. Dopiero odnowiona/przepisana wersja nixnote na qt jako tako działa i wygląda.

Screenshot from 2015-12-08 18-04-48Jedyny problem to paczka która w zależnościach ma jakieś stare wersje libopenexr kiedy to w sidzie aktualna jest libopenexr6v5.

Dlatego też zapodaję poprawioną paczkę dla w/w wersji libopenexr: nixnote2-2.0-beta5_amd64.deb

debian – Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied

Taki sobie error pojawia się w przypadku próby dodania poprzez virt-managera. Dlaczego? Ano wiki debiana na którym się wzorowałem i pewnie nie tylko ja wspomina jedynie o dodaniu grup kvm i libvirt dla usera, nie wspomina jednak o ustawieniu dodatkowo w /etc/libvirtr/qemu.conf, np:

user = "pakos"
group = "pakos"

Po takim zabiegu wszystko powinno działać 😉

downgrade experminetal – unstable

Nie wiem dokładnie jak ja to wczoraj zrobiłem ale z normalną aktualizacją systemu połowa paczek zaciągła się z repo experimental. Czegoś takiego na co dzień nie chcę, wystarczą mi pojedyncze paczki. Ale jak to cofnąć? Niestety nie doszukałem się jakiejś zautomatyzowanej i prostej metody, jedynie manipulacja pinami.

w /etc/apt/preferences dodajem/edytujemy:

Package: *
Pin: release a=unstable
Pin-Priority: 1001

i apt-get upgrade, to powinno zainstalować paczki w wersji z sid’a. Nadal pozostaną jednak w systemie paczki z experimentala które zostały zainstalowane jako zależności a których w sidzie jeszcze nie ma.

Sprawdzamy co zostało:

aptitude search ~S~i~Aexperimental

i w zasadzie możemy je na tym etapie wywalić.

BOINC

Większość z naszych maszyn podczas gdy na nich nie pracujemy marnuje się (o ile są włączone oczywiście ;)) dlaczego by też nie wykorzystać ich w imię nauki.

W BOINC możemy wybrać sobie dowolny projekt dla którego udostępnimy swoją moc obliczeniową, wystarczy zainstalować:

aptitude install boinc-client

Graficznie resztę można wyklikać poprzez:

aptitude install boinc-manager

Gdy jednak maszyna nie posiada serwera graficznego możemy się posiłkować konfiguracją manualną (boinc-manager posiada opcję połączenia remote aczkolwiek nie mogłem w ten sposób dodać żadnego projektu, świetnie się jednak sprawdza później do podglądu jak nam idzie).

Tak więc wybieramy jakiś projekt, rejestrujemy konto na stronie i konfiguruejmy klienta:

boinccmd --lookup_account projekt mail haslo

np:

boinccmd --lookup_account http://setiathome.berkeley.edumail@mail haslo

pojawi się nasz kod, dodajemy go:

boinccmd --project_attach projekt kod

np:

boinccmd --project_attach http://setiathome.berkeley.edu kod

Aby móc połączyć się zdalnie w pliku /var/lib/boinc-client/remote_hosts.cfg podajemy ip a w /var/lib/boinc-client//var/lib/boinc-client hasło.

Na koniec w iptables otwieramy port 31416 i łączymy się managerem.

BOINC
BOINC