Fedora 43 (nvidia drivery, rozbitý dovecot, IMAP autentikace, rozbité duplicity, nefunguje generování náhledů)

Těšil jsem se, jaká to bude pohoda, a zase to byl adrenalinový večer.

Samotná instalace a nvidia drivery

Oficiální postup zde, první krok je refresh a následně stažení upgradu:

sudo dnf upgrade --refresh
sudo dnf system-upgrade download --releasever=43

Výsledek ukázal problémy,

Transakci nebylo možné vyřešit:
Balíček "qcom-wwan-firmware-20251111-1.fc42.noarch" je již nainstalován.
Balíčky je pro argument 'dnfdragora-updater' jsou dostupné, ale nejsou nainstalovány.
Problém 1: installed package kmod-nvidia-6.17.7-200.fc42.x86_64-3:580.105.08-1.fc42.x86_64 requires nvidia-kmod-common >= 3:580.105.08, but none of the providers can be installed
- xorg-x11-drv-nvidia-3:580.105.08-1.fc42.x86_64 nepatří do distupgrade repozitáře
- problem with installed package
Problém 2: installed package xorg-x11-drv-nvidia-3:580.105.08-1.fc42.x86_64 requires nvidia-modprobe(x86-64) = 3:580.105.08, but none of the providers can be installed
- installed package kmod-nvidia-6.17.8-200.fc42.x86_64-3:580.105.08-1.fc42.x86_64 requires nvidia-kmod-common >= 3:580.105.08, but none of the providers can be installed
- nvidia-modprobe-3:580.105.08-1.fc42.x86_64 nepatří do distupgrade repozitáře
- problem with installed package

podle chytráka ChatGPT je nvidia stopka a mám ovladače odinstalovat úplně, pak udělat upgrade a pak znovu drivery. Pravda, překvapuje mě tam kmod, když jsem odjakživa používal automatický akmod, ale možná to souvisí s tím, jak jsem si hrál s kartou na LLM po refreshi železa. Takže

sudo dnf remove 'kmod-nvidia*' 'xorg-x11-drv-nvidia*' 'nvidia-modprobe*' 'nvidia-kmod-common*'
(...)
Shrnutí transakce:
Odstranit: 23 balíčků
(...)

Pak

sudo dnf system-upgrade download --releasever=43 --allowerasing

(...)
Shrnutí transakce:
Nainstalovat: 87 balíčků
Aktualizovat: 3550 balíčků
Nahradit: 3569 balíčků
Odstranit: 8 balíčků
Ponížit: 1 balíček

Celková velikost balíčků k instalaci je 7 GiB. Staženo bude 7 GiB.
Po tomto úkonu bude navíc zabráno 2 GiB (nainstalováno 20 GiB, odstraněno 18 GiB).

Po nějakých sedmi minutách staženo a přišel zas na samotnou instalaci. Tady je novinka, oproti předchozímu „sudo dnf system-upgrade reboot“, které okamžitě skočilo do speciálního režimu, je tu

sudo dnf5 offline reboot

které to udělá při příštím restartu. Kdybych si to rozmyslel, mohl bych to zrušit pomocí „sudo dnf5 offline clean“. Po restartu asi asi 12 minut instalace, pak teda trochu děsivé červené výpisy:

Musel jsem počítač vypnout natvrdo tlačítkem, ale pak zase naběhl. Vrátil jsem nvidia drivery:

sudo dnf install akmod-nvidia xorg-x11-drv-nvidia

A pokračoval klasickými kroky, tedy kontrola konfigurací pomocí

rpmconf -a

Ta identifikovala jen postfix, tam jsem si poučeně ponechal svůj.

Udělal jsem další neúspšný pokus o update GRUBu:

mount | grep "/boot "
/dev/sda2 on /boot type ext4 (rw,relatime,seclabel)
grub2-install /dev/sda
grub2-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory.

Pak zkontroloval duplicity (žádné)

dnf repoquery --duplicates
dnf remove --duplicates

Nechal odinstalovat důchodce:

remove-retired-packages

Vypsal extráty (86, klesá to).

dnf list --extras

A spokojeně pokračoval v práci. Do prvního problému, samozřejmě.

Vybírání lokální pošty Thunderbirdem - rozbitý dovecot a IMAP autentikace

Problém se objevil hned po spuštění Thunderbirda, pošta z localhostu byla opět prázdná. Ale proč?

Možná nechodí maily? Zkontroloval jsem službu postfix, ta běžela.

systemctl status postfix

Tak možná nefunguje přeposílání od roota na mého uživatele? Poslal jsem mail rootovi a v "mail" v mém uživateli se objevila, tedy to také funguje.

A co IMAP server? Běží, žádné chyby nehlásí. Zkrátka vše ok, akorát že to Thunderbird nestahuje.

systemctl status dovecot

Nehlásí něco komunikace přes IMAP protokol? Zkusil jsem ho telnetem:

A1 login wulogin wupassword
A1 OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE REPLACE SNIPPET=FUZZY PREVIEW=FUZZY PREVIEW SPECIAL-USE STATUS=SIZE SAVEDATE COMPRESS=DEFLATE INPROGRESS NOTIFY LITERAL+] Logged in

A2 SELECT INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted.
* 0 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1764777199] UIDs valid
* OK [UIDNEXT 1] Predicted next UID

A2 OK [READ-WRITE] Select completed (0.001 + 0.000 secs).

A3 SEARCH UNSEEN
* SEARCH
A3 OK Search completed (0.001 + 0.000 secs).

A4 LOGOUT
* BYE Logging out
A4 OK Logout completed (0.001 + 0.000 secs).
Connection closed by foreign host.

Takže je to prázdné. A kde teda ty maily vlastně jsou (když je "mail" ukazuje)? Před pár lety jsem přesvědčil postfix, aby je ukládal do Maildir, a evidentně to dělá dál, protože výpis je vypsal:

ls ~/Maildir/new/ -l

Takže musím upravit dovecot! Holt asi usoudili, že bude nejlepší dosavadní default konfiguraci na Maildir zrušit… V konfiguraci /etc/dovecot/dovecot.conf tedy změnit

mail_home = /home/%{user}
mail_driver = maildir
mail_path = ~/mail

na

mail_home = /home/%{user}
mail_driver = maildir
mail_path = ~/Maildir

A restartovat

systemctl restart dovecot

Tohle pomohlo.

Na serveru to bylo ještě o krok zábavnější, protože se samozřejmě zase nešlo přihlásit. ALE oproti minule jsem nemusel hledat jak vypnout SSL, protože Thunderbird už podporuje přidání výjimky!

Problém s duplicity a chybějícími manifest entries

Zálohování na servem pomocí duplicity je taky rozbité. Sice najde všechny změny, ale pak skončí ohromným křikem, že mu chybí manifest entries: ['vol1.difftar']. Vzhledem k tomu, že udržuju 4 plné updaty po deseti dnech a mezitím přírůstkové, vypadá to, že mu chybí manifest entries úplně všude. Asi zase nějaká novinka v duplicity 3.0.6 oproti 3.0.4.1, kterou jsem měl předtím.

WARNING. found missing difftar(s) in backup sets, possibly left from aborted session:
WARNING: Backup set at 20251117T200028Z has missing volumes or manifest entries:
- manifest entries: ['vol1.difftar']
WARNING: Backup set at 20251123T200025Z has missing volumes or manifest entries:
- manifest entries: ['vol1.difftar']
WARNING: Backup set at 20251124T200025Z has missing volumes or manifest entries:
- manifest entries: ['vol1.difftar']
WARNING: Backup set at 20251125T200025Z has missing volumes or manifest entries:
- manifest entries: ['vol1.difftar']
WARNING: Backup set at 20251126T200113Z has missing volumes or manifest entries:
- manifest entries: ['vol1.difftar', 'vol2.difftar', 'vol3.difftar', 'vol4.difftar', 'vol5.difftar', 'vol6.difftar', 'vol7.difftar', 'vol8.difftar', 'vol9.difftar', 'vol10.difftar', 'vol11.difftar', 'vol12.difftar', 'vol13.difftar', 'vol14.difftar', 'vol15.difftar', 'vol16.difftar', 'vol17.difftar', 'vol18.difftar', 'vol19.difftar', 'vol20.difftar', 'vol21.difftar', 'vol22.difftar', 'vol23.difftar', 'vol24.difftar', 'vol25.difftar', 'vol26.difftar', 'vol27.difftar', 'vol28.difftar', 'vol29.difftar', 'vol30.difftar', 'vol31.difftar', 'vol32.difftar', 'vol33.difftar', 'vol34.difftar', 'vol35.difftar', 'vol36.difftar', 'vol37.difftar', 'vol38.difftar', 'vol39.difftar', 'vol40.difftar', 'vol41.difftar', 'vol42.difftar', 'vol43.difftar', 'vol44.difftar', 'vol45.difftar', 'vol46.difftar', 'vol47.difftar', 'vol48.difftar', 'vol49.difftar', 'vol50.difftar', 'vol51.difftar', 'vol52.difftar', 'vol53.difftar', 'vol54.difftar']
(atd. atd. atd.)

Řekl jsem si, že to bude nějaká nekompabilita formátu, všechny staré zálohy přesunul bokem do archivu a nechal projet plnou zálohu tak, jak si to duplicity přeje… A stejně to nepomohlo.

Až po hodině diskuzí s chytrákem ChatGPT se ukázalo, že nekřičí zálohování, to funguje správně, ale křičí odmazávání starých setů – kterému jsem nepřidával odkaz na --archive-dir (a doteď to fungovalo).

duplicity remove-all-but-n-full 4 --force file:///media/net_backup/linux-snapshots --archive-dir=/root/.cache/backup_to_netdisk

Chytrák to zmínil mimochodem, ale já si toho naštěstí všiml…

- nějaké jiné volání duplicity (cleanup / remove-older-than / restore) bez --archive-dir používá default ~/.cache/duplicity a tam jsou staré rozbité manifesty → při běhu dostáváš varování na úplně jinou sadu záloh.

Nefunkční generátor náhledů

A na závěr to nejhorší. Kdykoliv exportuji z GIMPu obrázek nebo ho chci třeba v Geequie zobrazit (a tím pádem náhledy všech obrázků ve složce), zařve SE linux že „zdrojový proces bwrap se pokouší o přístup mounton na directory /tmp“ a náhled se nevytvoří. V detailu je ještě vidět, že se jedná o thumb_t a nějak jsem se dobral k tomu, že je v tom jakýsi glycin. Chytrák ChatGPT píše, že

SELinux doména thumb_t je určena pro:
generování náhledů obrázků,
indexaci médií,
různé služby třetích stran, které vyrábějí thumbnails.
Pokud Glycin (Linux thumbnailer napsaný v Rustu) nebo jiný podobný proces volá bubblewrap, může se pokusit spustit něco v sandboxu → a tím pádem vznikne přesně tento konflikt.

Moderní thumbnailery (např. Glycin) běží sandboxovaně, protože:
obrázky mohou být škodlivé
izolace generování náhledů je bezpečnostní best practice
bwrap je jednoduchý sandboxovací nástroj
Ale SELinux politika pro thumb_t JE SCHVÁLNĚ velice přísná.
→ mounton je pro thumbnailer zakázaný → SELinux blokuje pokus.

Sice mi radil i možnost nějakých custom modulů pro SE linux, ale nechci se do toho moc pouštět. Ještě jsem ho nechal najít, jestli je to už nahlášené v bugzille (asi ano) a teď čekám na update.

(A ten nepřichází, a tak čekám dál.)