Всичко за Дебиан

[Тамболианеца]

Съмнявам се. Във всички случаи обаче е по-бърз поне от DNF.
А ти за къде бързаш? Наслади се на бавния му ход

[Mozo]

Хаха, не щем

[бат-начо]

Фен съм на Мока иконите, щото не изглеждат токова плоско. Предиии имаше orion тема, ама "светлото пиво" няма бъдеще (е, нямаше). На Дебиан периодично преслушвам Синаптика за "themes". Тоя път ми излезе ukui-themes. Не изглежда зле, ако не броим иконите на папките (все пак е moka-faba, дето харесвам). Разрових се и излезе, че я има от много време. На Дебиан е по-нова версия от на Убунту (18.04) и както става - изглежда по-зле (папките). Е, то е Мате, има си и теми, не е само икони. Не знам как изглежда на Мате (пробвал съм я на xfce и lxde), там би трябвало да е чук.
Разгледах ги - на Дебиана му трябва basic-a (тия ми харесват, де), а то праска ukui-icon-theme-classical.

[бат-начо]

Едни приемливи съвети и ще се метна на Xebian за проба. На Сид не съм се задържал толкова дълго, че да дочакам счупване, сега ще пробвам. М-да, и преди съм го пробвал ксебиана, но сега ще опитам да поостана.

[Тамболианеца]

Едни приемливи съвети и ще се метна на Xebian за проба. На Сид не съм се задържал толкова дълго, че да дочакам счупване, сега ще пробвам. М-да, и преди съм го пробвал ксебиана, но сега ще опитам да поостана.

Ако ще е само за пробата - няма значение на каква файлова система как ще го инсталираш.
Но ако е за дългосрочно многогодишно ползване ти препоръчвам zfs-on-root или btrfs-on-root за лесно възстановяване на ОС-а чрез ролбеци, ако се наложи.
Ролингите си сакат крави.

[hunter4o83]

Току що инсталирах Xebian пуснах го да се ъпдейтва сега чакам да видя какво ще се случи

[бат-начо]

Ролингите си сакат крави.

Знам си се, не търпя ролинг стоунс, само го слушам.

[бат-начо]

Току що инсталирах Xebian пуснах го да се ъпдейтва сега чакам да видя какво ще се случи

Нищо особенно няма да стане, щото не е включено от трошливия софт. Инсталирай либрето-офис на тая трагедия от Корней за проба.

[Тамболианеца]

Gnome 3.36.1 сакурата цъфна днес и в Sid.

[бат-начо]

Наистина "Дебиан Е"! Правя това (е, почти) на лаптопа, пък той бавен, не ми се говори... Обачееее, нема забивания, нема лабаво! Може да си работиш и друго спокойно. Същото на Убунту-базирано (хеле пък като почне компесията на squashfs-та ) - умира почти на по-здраво желязо и се чуди неизветен период от време "да го направя ли и другото, да не го ли направя"...

[Mozo]

Ubuntu е зле, откога го говоря Па, ако инсталираш едно Manjaro, ще се родиш

[бат-начо]

Пиннах си Каприна да не се обновява (имам хранилището на Спарки, удобство си е, с едно-друго "от въздуха"), обаче за стабилните пакети съм заковал прекалено голям и дебел цигански пирон, и май ще трябва да го сменя.

[Тамболианеца]

Как да се защитим срещу update/upgrade проблеми в ролинг дистро като Debian Sid?

Проблемът: понякога поредният ъпдейт може да потрoши Sid инсталацията.
Не защото ъпдейтът е калпав, а защото е непълен, т.е. не всички пакети са ъпдейтнати изцяло в даден функционален контекст.

Тогава възниква въпросът - даунгрейд или ролбек?
Определено ролбек е отговорът. За минути и безпроблемно.

Предпоставки за успешен ролбек: ZFS-on-root инсталация.

Как се инсталира zfs-on-root?
Така: https://github.com/openzfs/zfs/wiki/Deb ... oot-on-ZFS

Как да правим снапшоти при zfs-on-root?
Просто е, прават се pre и post snapshot ъпдейти, идея която съм взаимствал от openSUSE за snapper/btrfs, но в контекста на zfs-on-root за Debian: изпълним файл zapt.sh

Код: Избери всички

#!/bin/bash
# A script to create pre and post snapshots for package upgrade
# Aptitude package manager is used
# The script requires user sudoers permissions

dt=$(date +%Y%m%d:%H%M)
sudo zfs snapshot bpool/BOOT/debian@pre-${dt}
sudo zfs snapshot rpool/ROOT/debian@pre-${dt}
sudo zfs snapshot rpool/home/<user>@pre-${dt}

sudo aptitude update
# sudo aptitude full-upgrade --assume-yes
# sudo aptitude upgrade --without-recommends --assume-yes
sudo aptitude upgrade --assume-yes

dt=$(date +%Y%m%d:%H%M)
sudo zfs snapshot bpool/BOOT/debian@post-${dt}
sudo zfs snapshot rpool/ROOT/debian@post-${dt}

На мястото на <user> e съответната потребителска home директория, за по-лесно направо хардкодната в скрипта

В случая правим snapshots на root, boot и home, всички те се влият и променят по принцип при всеки ъпдейт

Use-case #1 - rollback от зареждаема все още Sid инсталация:
Чрез команди от сорта на zfs rollback <root | boot | home> pre-<datastamp>
Порядъкът е ясен, връщаме се към най-последния pre снапшот преди ъпдейта/ъпгрейда:

Код: Избери всички

sudo zfs rollback bpool/BOOT/debian@pre-<datastamp>
sudo zfs rollback rpool/ROOT/debian@pre-<datastamp>
sudo zfs rollback rpool/home/<user>@pre-<datastamp>
sudo reboot

Естествено <datastamp> в командата трябва да бъде заместен със съответния му реален еднакъв такъв.

Use-case #2
Зареждане на Live distro поддържащо ZoL като Ubuntu 20.04
или Zed-live: viewtopic.php?f=230&t=107008&start=420#p1007111
с единствено различие zpool import на rpool и bpool
и на практика повтарящо прецедурата за ролбек по use-case #1

Премахване на излишните натрупани снапшоти:
Ръчно: чрез изтриване на еднаквите по datestamp снапшоти за rpool, bpool

Код: Избери всички

sudo zfs destroy  bpool/BOOT/debian@pre -<datastamp>
sudo zfs destroy  bpool/BOOT/debian@post-<datastamp>
sudo zfs destroy  rpool/ROOT/debian@pre-<datastamp>
sudo zfs destroy  rpool/ROOT/debian@post-<datastamp>
sudo zfs destroy  rpool/home/<user>/debian@pre-<datastamp>

Отново <datastamp> в командата трябва да бъде заместен със съответния му реален такъв.

Графично: Чрез елементарен zenity script

Код: Избери всички

# A script to generate a Zenity dialog for manual selection 
# of zfs snapshots to be destroyed
# The script requires user sudoers permissions

snaplist=$(sudo zfs list -H -t snapshot | cut -f 1)
snaparray=(${snaplist})
snaptable=()
for (( i=0; i<${#snaparray[*]}; i++ ))
do
    snaptable+=(FALSE "${snaparray[$i]}")
done
res=$(zenity --list \
	--column="Delete" --column="Snapshot Name" ${snaptable[@]} --checklist \
	--title="Delete OLD snapshots" --width=400 --height=600 --window-icon=warning)
snapdest=$(echo $res | tr '|', ' ')
for x in ${snapdest}
do
	res=0
	while [ $res -eq 0 ]
	do
		sudo zfs destroy ${x} &>/dev/null
		res=$?
		if [ $res -eq 0 ]
		then
			echo "Snapshot destroyed: ${x}"
		fi
	done
done

Debian Sid zfs-on-root - най-стабилното Linux ролинг-дистро

[Тамболианеца]

Конфигурация на earlyoom в Debian

Видях, че започвайки с Fedora 32 earlyoom е запуснат по подразбиране, което навежда на мисълта, че технологията е вече достатъчно надеждна.

Време и ние с гайдите в Debian да надигнем крак

1. Какво e earlyoom?
https://packages.debian.org/unstable/earlyoom

Или в Гугъл превод: Earlyoom е OOM (out-of-memory) убиец на потребителско пространство, който може да избегне системата да изпадне в нереагиращо състояние, причинено от размяна, което е най-вероятно да възникне, когато има голям суап и паметта е плътна. Той проверява количеството налична памет и се разменя периодично и когато и двете са под предварително конфигурирана стойност, той убива най-големия процес.
(на английски си е по-ясно)

2. Инсталация в Debian Sid/Testing (ver. 1.5)

Код: Избери всички

% sudo aptitude install earlyoom
% sudo systemctl enable earlyoom
% sudo systemctl start earlyoom

(В Debian Buster обаче версията е 1.2, както и не я виждам в backports. В този случай е по-добре да се компилира към последната версия от git 1.6, има много малко зависимости)

3. Конфигурация на earlyoom
Ако спрем с т.2 Инсталация, по подразбиране earlyoom ще се конфигурира със следните параметри в Debian:
- ще се опита да изпрати SIGTERM сигнал за нормално приключване на процеси с висока стойност на oom_score, когато свободната памет И свободният суап паднат под 10% обем;
- ще се опита да изпрати SIGKILL сигнал за принудително убиване на процеси с висока стойност на oom_score, когато свободната памет И свободният суап паднат под 5% обем;
- ще разписва текущите стойности в журнала на свободната памет И суапа на всеки 3600 секунди, т.е. на всеки час.

Ясно е, че стойностите по подразбиране не са удобни всекиму, а още повече че и липсват указания кои процеси са за предпочитане да бъдат запазени, както и кои да бъдат терминирани в ситуация на безпаметност

Конфигурационният файл e /etc/default/earlyoom. Възможни са всякакви вариантни конфигурации, но не всяка е оптимална.

Текуща ситуация:
Инсталацията ми на Debian е с физически параметри 32 GiB RAM и 8 GiB SWAP.
Системата съм си я настроил да започва да суапва при 20% свободна памет, т.е vm.swappiness=20 при мен заради купчините виртуални машини, които често пускам едновременно. С други думи започвам да swap-вам, когато свободната ми RAM памет падне под 6.5 GiB.

Преследвани цели:
- целта ми е този earlyoom да сработва малко по-късно от старта на swap-ването, а от друга страна по-рано от 10% оставащ свободен swap при подразбиращите се earlyoom стойности, когато пък e твърде късно - ще си ми блокира компа гарантирано;
- оптималните за мен стойности са сработване за SIGTERM при 2 GiB RAM и 2 GiB SWAP свободни, a за SIGКILL ще използвам подразбиращата се 2-пъти по-малко спрямо SIGTERM памет от 1 GiB и няма изрично да указвам размера й;
- допълнително искам да запазя процеси от терминиране като ssh, Xorg, a в същото време да се оттърва от процеси, които са най-честата причина да изяждане на паметта - браузерите;
- на последно място искам да се води журнал за промените в свободната памет на всеки 10 мин, а не на всеки час - прекалено дълъг период в неизвестност какво се случва и за търсене впоследствие на виновниците за изяждането на паметта.

Всичко гореописано може да се представи с параметър в /etc/default/earlyoom така:

Код: Избери всички

EARLYOOM_ARGS="-r 600 -M 2097152 -S 2097152 --avoid '^(Xorg|sshd)$' --prefer '^(chromium|firefox)$'"  

Параметрите, разтълкувани:
-r = периодът на записване в журнала в секунди;
-M = абсолютната стойност на сработване на earlyoom за SIGTERM за ниво на свободна памет, и на половина за SIGKILL;
-S = абсолютната стойност на сработване на earlyoom за SIGTERM за ниво на свободен суап, и на половина за SIGKILL;
--avoid = кои процеси изрично държа да не биват терминирани/убивани;
--prefer = кои процеси бих желал първи да бъдат терминирани/убивани при критично ниско ниво на паметта.

След промените по конфигурирането престартираме earlyoom сървиса, за да ги активираме:

Код: Избери всички

% sudo systemctl restart earlyoom

% sudo systemctl status earlyoom     
● earlyoom.service - Early OOM Daemon
     Loaded: loaded (/lib/systemd/system/earlyoom.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2020-05-02 17:31:35 EEST; 3s ago
       Docs: man:earlyoom(1)
             https://github.com/rfjakob/earlyoom
   Main PID: 147268 (earlyoom)
      Tasks: 1 (limit: 38381)
     Memory: 508.0K
     CGroup: /system.slice/earlyoom.service
             └─147268 /usr/bin/earlyoom -r 600 -M 2097152 -S 2097152 --avoid ^(Xorg|sshd)$ --prefer ^(chromium|firefox)$

May 02 17:31:35 tumbolia systemd[1]: Started Early OOM Daemon.
May 02 17:31:35 tumbolia earlyoom[147268]: earlyoom v1.5
May 02 17:31:35 tumbolia earlyoom[147268]: Preferring to kill process names that match regex '^(chromium|firefox)$'
May 02 17:31:35 tumbolia earlyoom[147268]: Will avoid killing process names that match regex '^(Xorg|sshd)$'
May 02 17:31:35 tumbolia earlyoom[147268]: mem total: 32114 MiB, swap total: 8191 MiB
May 02 17:31:35 tumbolia earlyoom[147268]: sending SIGTERM when mem <=  6.38% and swap <= 25.00%,
May 02 17:31:35 tumbolia earlyoom[147268]:         SIGKILL when mem <=  3.19% and swap <= 12.50%
May 02 17:31:35 tumbolia earlyoom[147268]: mem avail: 17606 of 32114 MiB (54.82%), swap free: 8191 of 8191 MiB (100.00%)

От изхода се вижда, че earlyoom си е преизчислил стойностите в проценти памет. Същият резултат можехме да получим и ако бяхме използвали параметри с малки букви (-m -s) за процентно указване прага на паметта.

4. Повече за технологията от:
https://github.com/rfjakob/earlyoom
за безаварийно и безблокажно с earlyoom.

[Mozo]

Много добре описано и обяснено