Po delší době zase mám dotaz, nebo spíš podnět k diskusi...
Na ntb se SSD jsem zkusil instalovat Kubuntu 20.04 LTS a to tak, že / je jeden oddíl ext4 (sda1), /home další oddíl ext4 (sda2) a /swap je jako poslední. Swap bych na SSD normálně nepoužil, ale ntb má málo RAM, takže je nutný a ošetřilo se to pomocí vhodného nastavení hodnoty swapiness.
Oddílu / jsem vyhradil 14 GB v bláhové naději, že to bude stačit (podotýkám, že jde o standardní instalaci pouze s několika málo přidanými nenáročnými programy). Vždycky dříve to v Kubuntu tak fungovalo, dokonce tuším cca s poloviční velikostí....
No, rozežranost dnešního sw nicméně nezklamala a po cca druhé či třetí aktualizaci systém už nenabootoval, protože těch 14 GB je prostě málo a disk byl plný. Pro základní oživení pomohlo purge ze záchranného režimu, nicméně na / nyní zbývá pouze cca 760 MB, takže nepoužitelné...
Nyní k věci: jde bez přeinstalace systému zvětšit velikost / (sda1) ? Můžu zmenšit /home (sda2) a vytvořit tak volné místo, ale myslím, že třeba takový Gparted nedokáže volné místo přesunout na jiný oddíl...
Nějaké užitečné nápady?
Díky.
Update 7.7.2020:tak příběh se opakoval, přestože jsem mezitím zvětšil systémový oddíl na "pouhých" 33,3GB. Příčina? Opět zcela zaplněný systémový disk.
No a příčina příčiny?
Jsou dvě a jmenují se /var/log/kern.log a /var/log/syslog.1, upřesnění je zřejmé z obrázku v příloze. Jak můžou log soubory při běžném a bezproblémovém cca dvoutýdenním využití (a to zdaleka ne každodenně) nabýt takové velikosti, to vědí asi jen v Canonicalu...
Už jsem nechtěl věc zkoumat pomocí tail apod., takže oba šly pomocí live do pryč a vše budu nadále sledovat a analyzovat... Jo a tady
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/115774je hlášený bug, přičemž v
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/115774/comments/39 se píše, že přetrvává i v *buntu 20.04...