Fórum Ubuntu CZ/SK
Ubuntu pro osobní počítače => Instalace, aktualizace a spouštění => Téma založeno: JirkaZ 15 Června 2020, 17:05:01
-
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/115774
je 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...
-
Velikosti oddílů se dají běžně upravit i po instalaci. Disk ale musí být offline - musíš to proto udělat z live pomocí GParted (nezapomeň odpojit swap). Nejprve tedy zmenši oddíl s /home (zprava). Pak ho celý přesuň doprava. Zmenšování a přesun chvíli potrvá, v závislosti kolik je na něm dat. Pak oddíl se systémem rozšiř do takto vzniklého místa. Zvětšení systémového oddílu bude rychlé.
Ad "rozežranost": Dříve nebyl snap ani flatpak. A vsadím se, že nemáš vyčištěnou apt-cache a odinstalované staré kernely....
A není od věci si udělat "audit" co nejvíc žere místo. Nejlépe pomocí jdiskreport. To pak někdy bývá překvapení... :)
Nepotřebné položky samozřejmě smazat, starší verze kernelů a snapů odinstalovat. Snapům flatpakům se vyhnout, instalovat pomocí apt.
-
Velikosti oddílů se dají běžně upravit i po instalaci. Disk ale musí být offline - musíš to proto udělat z live pomocí GParted (nezapomeň odpojit swap).
To snad není třeba zdůrazňovat...
Nejprve tedy zmenši oddíl s /home (zprava). Pak ho celý přesuň doprava. Zmenšování a přesun chvíli potrvá, v závislosti kolik je na něm dat.
Stalo se už před dotazem (úspěšně).
Pak oddíl se systémem rozšiř do takto vzniklého místa. Zvětšení systémového oddílu bude rychlé.
Nejde to. Na sda2 je nyní 10 GB unallocated space (mezi / na sda1 a /home na sda2) a nejde s ním nic dělat. Nemůže vadit, že sda1 je primární oddíl a sda2 rozšířený?
Ad "rozežranost": Dříve nebyl snap ani flatpak.
Nepoužívám, už dávno se tady proti tomu "vymezuju"... Pokud je na disku nějaká poinstalační podpora, tak něco možná zabírá (nedíval jsem se), ale programy tohoto typu nemám.
A vsadím se, že nemáš vyčištěnou apt-cache a odinstalované staré kernely....
Pochopitelně že mám, to bych vůbec nepokračoval...
A není od věci si udělat "audit" co nejvíc žere místo. Nejlépe pomocí jdiskreport. To pak někdy bývá překvapení... :)
Jo, instalovat na ten sotva běžící systém další věci (javu - nevím, zda tam je atd.) asi fakt nemá smysl.
Prostě potřebuju ten / oddíl zvětšit alespoň o těch uvolněných 10GB a pak budu řešit, proč je systém tak obří...
-
Nejde to. Na sda2 je nyní 10 GB unallocated space (mezi / na sda1 a /home na sda2) a nejde s ním nic dělat. Nemůže vadit, že sda1 je primární oddíl a sda2 rozšířený?
Ano, je to pravdepodobne. Mozem vediet preco este nemas na SSD GPT? Tam mozes mat 128 primarnych oddielov.
-
Nejde to. Na sda2 je nyní 10 GB unallocated space (mezi / na sda1 a /home na sda2) a nejde s ním nic dělat. Nemůže vadit, že sda1 je primární oddíl a sda2 rozšířený?
Ano, je to pravdepodobne. Mozem vediet preco este nemas na SSD GPT? Tam mozes mat 128 primarnych oddielov.
GPT....no nevím. Používám ho na (mnohem novějším a výkonnějším) stolním PC, ten citovaný ntb je ThinkPad T61, čili poměrně "starý" model a prostě jsem to na něm neřešil. Je to pouze linuxový jednoúčelový stroj, léta běhající k naprosté spokojenosti (dříve s HDD).
Koukám, že nejjednodušší bude záloha /home, komplet smazání a nové rozdělení SSD a nová instalace.
-
Pak oddíl se systémem rozšiř do takto vzniklého místa. Zvětšení systémového oddílu bude rychlé.
Nejde to. Na sda2 je nyní 10 GB unallocated space (mezi / na sda1 a /home na sda2) a nejde s ním nic dělat. Nemůže vadit, že sda1 je primární oddíl a sda2 rozšířený?
Koukám, že nejjednodušší bude záloha /home, komplet smazání a nové rozdělení SSD a nová instalace.
No pochopitelně, pokud je ten /home oddíl logický v rámcí rozšířeného, a ten systémový je primární, musíš zmenšit (zleva) i ten rozšířený. Teprva pak bude to místo volné pro zvětšení toho primárního systémového. To tě nenapadlo? ::)
P.S. Další co si libuje ve (zbytečných) reinstalacích - ach jo...... :-\
-
Dá se udělat v Linuxu konverze z MBR na GPT bez ztráty dat?
-
Dá se udělat v Linuxu konverze z MBR na GPT bez ztráty dat?
gdisk /dev/sdx
Zmáčkni w k zápisu GPT partition tabulky na disk.
Zmáčkni y pro potvrzení akce.
Jak ostatně každá manipulace s diskem, to je potenciálně riziková operace - takže raději zálohovat. Na druhou stranu se to většinou povede...
-
Takže to jde lehce. A když se ta změna provede na systémovém disku, dovede Linux nabootovat? Nebo má stejně jako Windows problémy?
Jinak já mám dokonce i na počítači s MBR disk ve formátu GTP, dala jsem do něj staré SSD a jen naformátovala při instalaci. Vlastně kromě toho jednoho mám všechno UEFI/GPT.
-
Změna se samozř. musí provést offline (z live). Dále bude třeba reinstalovat grub, jelikož jak známo, grub sídlí v mbr která půjde do pryč....
(Nabootovat live > chrootnout ten systém > reinstalovat grub > vylézt z chrootu > restart > hotovo)
Ano, i na PC s klasickým biosem (legacy) můžeš mít disk gpt, ale pouze jako datový - nenabootuješ z něj...
-
Update původního dotazu - viz onen dotaz ;-)
-
Max. velikosti logů a jejich rotace se většinou dají nastavit v přísl. konfig. souborech. Nedávno jsem to jednomu nešťastníkovi dělal (měl složku /var/log/journal 7GB velkou). Některé log soubory měly až 200MB - to bych chtěl teda vidět, kdo a v čem by to otevíral/študoval.
Proč je to takto defaultně nastavené netuším.... :-\
-
Max. velikosti logů a jejich rotace se většinou dají nastavit v přísl. konfig. souborech. Nedávno jsem to jednomu nešťastníkovi dělal (měl složku /var/log/journal 7GB velkou). Některé log soubory měly až 200MB - to bych chtěl teda vidět, kdo a v čem by to otevíral/studoval.
Proč je to takto defaultně nastavné netuším.... :-\
Jo, to už jsem taky zjistil. Taky jsem uvažoval o skriptu na automatické mazání těch souborů atd. apod....
Mě by ale především zajímalo, co je důvodem k vytváření takto mamutích logů, zejména když tentýž hw pracoval s Kubuntu 14.04 LTS léta bez problémů. Koukal jsem se na jiný stroj do 18.04 a tam je to taky OK (logy mají max. jednotky MB).
Prostě nechci dělat workaround, ale řešit příčinu.
Čili budu to nadále sledovat. Momentálně mám udělaný aut. restart počítače po 5 min. a nechám to běhat pár dnů, uvidíme...
-
Osobně si myslím, že viníkem je systemd (ve 14.04 ještě není)....
-
Jake jsou ty prisl. konfig. soubory pro nastaveni max. velikosti tech logu?
-
Jake jsou ty prisl. konfiv. soubory pro nastaveni max. velikosti tech logu?
No to záleží co je to za logy. Např. pro /var/log/journal (schválně se podívej jak máš tu složku velkou, budeš překvapený) se to nastavuje v souboru /etc/systemd/journald.conf
Obyčejné syslogy aj. se ošetřují pomocí logrotate (/etc/logrotate.conf)
-
To jsem překvapen - a také velikostí jednotlivých souborů - co to je za log, že má 8.4MB? - všechny.
Ale nejstarší tam je z 22.5.2020, takže to vypadá, že se po čase mažou?
Můžu je prostě smazat, když budu potřebovat?
-
To jsem překvapen - a také velikostí jednotlivých souborů - co to je za log, že má 8.4MB? - všechny.
Ale nejstarší tam je z 22.5.2020, takže to vypadá, že se po čase mažou?
Můžu je prostě smazat, když budu potřebovat?
Ano, můžou se po čase mazat. Ale ošetři si to viz výše (po editaci config souboru zadej):
sudo systemctl restart systemd-journald
A hned uvidíš, jak je to promazané. Pak už s o to nemusíš starat... ;)
Jo, jde to vymazat i ručně, ale jen ty starší soubory, hlavně ne proboha tu složku a aktuální journal...