Tentokrát jsem si instalaci pořádně užil! Protože jsem si pořídil nové železo, vzal jsem i instalaci pěkně od základu, s rozdělováním disků, přípravou SSD a – nově – šifrováním. Načasování se mi opět nevydařilo, Fedora 28 byla teprve beta – ale představa, že s 27 budu za půl roku zase trénovat přeinstalování mě strašila natolik, že jsem betu vyhodnotil jako menší riziko. A vzhledem k novosti HW a velikosti RAM samozřejmě také 64bitovou verzi. A kvůli Steamu a hrám zase návrat k originálním ovladačům nVidia.

Rozdělování SSD disku (4 pokusy)

Začalo to prakticky hned. Nabootuju do live CD, spouštím fdisk se zarovnáváním, cvakám oddíly (dvě sady boot+swap+root, abych mohl mít dvě verze paralelně)

fdisk -S 32 -H 32 /dev/sda
#1GB boot n -> p -> 1 -> enter -> +1G
#8GB swap n -> p -> 2 -> enter -> +8G
#40GB / n -> p -> 3 -> enter -> +40G
#extended n -> e -> 4 -> enter -> enter
#1GB boot n -> p -> 5 -> enter -> +1G
#8GB swap n -> p -> 6 -> enter -> +8G
#40GB / n -> p -> 7 -> enter -> +40G

No a někde v polovině se zarazím – proč se držet u země a mít tam MBR s extended partition, když bych mohl mít nový skvělý GPT?

Takže znovu, jen s použitím gdisku. Jenže jak to neznám, docela solidně jsem se zamotal s typy oddílů, oba booty označil za EFI systém a asi hodinu pročítal internetové stránky a hledal, jak se vlastně z GPT bootuje a jak to souvisí s EFI oddílem. Nakonec jsem to vzdal, všechno smazal a vrátil se k fdisku. Pak rozjel instalaci, nastavil oddíly – a ouha. Anaconda mě nepustila dál. Prý

„Pro UEFI instalaci je nutné přidat Systémový oddíl EFI připojený do /boot/efi umístěný na disku naformátovaném na GPT.“

Ups. Nezbylo než se vrátil k článkům a dát si třetí kolo rozdělování disku, opět s gdiskem.

#1GB boot n -> 1 -> enter -> +1G -> ef00 EFI system
#1GB boot n -> 1 -> enter -> +1G -> 8300 linux filesystem
#8GB swap n -> 2 -> enter -> +8G -> 8200 linux swap
#40GB / n -> 3 -> enter -> +40G -> 8300 linux filesystem
#1GB boot n -> 1 -> enter -> +1G -> 8300 linux filesystem
#8GB swap n -> 2 -> enter -> +8G -> 8200 linux swap
#40GB / n -> 3 -> enter -> +40G -> 8300 linux filesystem

To už se Anacondě líbilo – EFI namountovat do /boot/efi, zbytek klasicky /boot, swap a /.

Šifrování systému (2 pokusy)

Nezapomněl jsem u / vybrat, že chci šifrovat, zvolil heslo a instalaci odstartoval. Šlo to jako po másle, restart, odemčení šifrovaného disku… všechno funkční.

Přistoupil jsem tedy k nastavení TRIMu pro SSD disk. No jo, jenže v /etc/fstab už nefiguruje diskový oddíl, ale šifrovací mapper. Já tam sice nastavím, že pro / se má posílat „discard“, ale na disk přistupuje někdo jiný. Bude to fungovat? Diskuze na internetu byly docela strašidelné, a dočkat se zpomalení disku jsem nechtěl. Už už jsem se chystal na novou instalaci bez šifrování, naštěstí jsem ale našel návod How to Activate TRIM on LUKS Encrypted Partitions in Ubuntu & Debian. A letmá kontrola přes

dmsetup table /dev/mapper/xxxxxxx --showkeys

ukázala, že TRIM už přebírá (výpis končí řetězcem „1 allow_discards“). Ještě jsem se podíval, jestli je to opravdu explicitně napsané v /etc/crypttab a začal se těšit na šifrování nad diskovým polem.

Těšil jsem se ovšem jen chvilku, protože jsem mezitím zjistil, že šifrovat systém má smysl jen když se bude šifrovat i swap. A když jsem si k tomu přidal i diskové pole, bylo by z pouštění počítače nekončící zadávání hesel. Dalo by se to asi řešit klíči, ale… Po několika konzultacích, zralé úvaze a prozkoumání všech kombinací diskových vrstev (LUKS, LVM, RAID) jsem usoudil, že mi postačí šifrovat jen diskové pole s /home. Takže jsem LUKS svazek zase smazal a dal si instalaci podruhé.

Drobné chyby při stahování balíků

Párkrát na mě vyskočily chyby stahování balíku, jako třeba:

dnf -y install encfs
Chyba: Chyba stahování balíku:
file "repomd.xml" was not found in metalink

Internet říká vyčistit, ale

[root@localhost ~]# dnf clean all
54 soubory odstraněny

[root@localhost ~]# dnf -y install encfs
Fedora 28 - x86_64 - Test Updates 706 kB/s | 16 MB 00:23
Chyba: Chyba synchronizace mezipaměti pro repositář 'updates'

Napodruhé to ale prošlo...

Tiskárna

U tiskárny Brother 2150N se mi originální drivery od výrobce rozchodit nepovedlo:

dub 19 00:47:48 xxxxxx cupsd[10440]: Connection error: No route to host
dub 19 00:47:48 xxxxxx cupsd[10440]: The printer is unreachable at this time.

Přitom ale síť jede, tiskárna taky, IP adresa je ok, browserem se na tiskárnu dostanu. Čert ví čím to, jestli SE Linux, 64bit OS a staré ovladače nebo něco dalšího, ale vyřešil jsem to obchvatem a vrátil se k jednomu z ovladačů, které ve Fedoře jsou. Brother-HL-2170W Foomatic/ljet4 funguje.
(Více o ovladačích pro Brother 2150N najdete v tomto článku.)

Diskové pole

To byla další záhada. Po restartu jsem místo XFCE měl jen příkazovou řádku. Po prozkoumání logu jsem zjistil, že tomu předcházel problém s diskovými poli, kdy

A start job is running for dev_md0/1 device

Pak se minutu a třicet sekund čekalo a následovalo přepnutí do emergency mode. Obě pole jsem tedy v etc/fstab zakomentoval, restartoval a pak je zkusil přimountovat ručně. Jenže md0 ani md1 nebylo nalezeno. Výpis ukázal, v čem je problém:

cat /proc/mdstat
Personalities : [raid1]
md126 : active (auto-read-only) raid1 sdb2[0]
504771264 blocks super 1.2 [2/1] [U_]
bitmap: 4/4 pages [16KB], 65536KB chunk

md127 : active (auto-read-only) raid1 sdb1[0]
471728128 blocks super 1.2 [2/1] [U_]
bitmap: 4/4 pages [16KB], 65536KB chunk

Ony se identifikovaly jinak, než měly (a to i přesto, že jsem měl vygenerovaný /etc/mdadm.conf). Záhada. Jediné, co mě napadlo, je jméno počítače, to jsem totiž mezi vytvořením pole a nefunkčním restartem změnil a v obsahu mdadm.conf (resp. ve výpisu mdadm --detail --scan) figuruje.

Pole jsem zrušil, vymazal superblok, znovu vytvořil. A fungovalo.

Java a aliasy

Původní java vybalená do /opt tvrdošíjně nešla spustit přes alias (ale napřímo ano). Dlouho jsem to nezkoumal, zkusil jsem stáhnout 64bitovou a rozbalit ji přes to – pomohlo.

XFCE a starý home

Po přihlášení něco v XFCE spadlo a byl jsem zase na přihlašovacím dialogu, dělo se to u všech starých účtů.

Chvíli jsem to hledal, smazal nastavení ploch, pak nastavení celého xfce, ale stejně to nepomohlo. Nakonec jsem přistoupil k radikálnímu resetu účtu, vytvořil si novou složku a postupně dokopírovávám to, co potřebuju. Aspoň se po osmi letech trochu pročistí.

Notecase Pro

Placenou verzi Notecase Pro používám na zápisky; je multiplatformní, takže můžu přecházet mezi počítači, na windows je portable, takže ho nosím s sebou a jeho ovládání mám docela zažité. Jenže 64bit verze nešla nainstalovat! Chyběla jí hromada závislostí:

rpm -ivh notecase_pro-4.0.5-1.fc22.x86_64.rpm

chyba: Selhalé závislosti:
gstreamer je potřeba pro notecase_pro-4.0.5-1.fc22.x86_64
gtksourceview2 >= 2.4.1 je potřeba pro notecase_pro-4.0.5-1.fc22.x86_64
libgstapp-0.10.so.0()(64bit) je potřeba pro notecase_pro-4.0.5-1.fc22.x86_64
libgstreamer-0.10.so.0()(64bit) je potřeba pro notecase_pro-4.0.5-1.fc22.x86_64
libgtksourceview-2.0.so.0()(64bit) je potřeba pro notecase_pro-4.0.5-1.fc22.x86_64
libunique-1.0.so.0()(64bit) je potřeba pro notecase_pro-4.0.5-1.fc22.x86_64
unique je potřeba pro notecase_pro-4.0.5-1.fc22.x86_64

Postupně se našly, nejvíc pomohla instalace gstreameru, ale libgstapp-0.10.so.0()(64bit) prostě nebyla k nalezení. Googlil jsem už skoro zoufale, než jsem na rpmfind.net pochopil, kde ji najít ((zjištěno díky tomuto dotazu)

Ten balík se totiž jmenuje jinak! Potřebuje gstreamer-plugins-base...

To byl ovšem poslední problém a od té doby systém funguje bez jediného klopýtnutí.