Lubuntu 18.04 - pomalý boot systému (Vyřešeno)

[Janslav]

Po přechodu z Lubuntu 16 na 18.04.1 LTS se zdá, že start systému je pomalejší. Zkoušel jsem nalézt příčinu pomalosti pomocí terminálového příkazu systemd:

jan@jan-desktop:~$ systemd-analyze blame
          9.254s flexibee.service
          2.967s NetworkManager-wait-online.service
          2.763s postgresql@10-main.service
          2.677s postgresql@9.6-flexibee.service
          2.647s postgresql@9.6-main.service
          1.232s udisks2.service
           949ms dev-sda1.device
           912ms fwupd.service
           725ms networkd-dispatcher.service
           659ms apparmor.service
             atd.
a vypadá to, že část zpoždění způsobuje program Flexibee (účetnictví) a jeho databáze postgresql. To já občas používám, ale zcela nechápu, proč by se mělo objevit při startu systému, je zřejmě z nějakého důvodu obsaženo ve Startup applications.
Jakým způsobem by se  dalo zabránit tomu, aby se tohle nenatahovalo při každém bootu, jen tehdy, když to potřebuji ?

[juwa2]

Je to tam zřejmě proto, že ta aplikace startuje pomalu sama o sobě (ve Windows to takto má ošetřeno např. Adobe Reader). Pokud tu aplikaci spouštíš jenom občas a nevadí ti její pomalý start, ze Startup apps to vyhoď...

[Janslav]

To je jistě pravda, ale jak to mám vyhodit ?
V základních aplikacích ani v  automatickém spouštění to nemám...

[miro_]

Mam podobny dotaz k rychlosti spousteni, ale pro Ubuntu-16 na SSD.
Minuly tyden jsem koupil novy SSD. Klonovani Acronisem mi preneslo partition s Ubuntu 16 beze zmen,
alespon to tak na prvni pohled vypada. Presto nabeh Ubuntu je nekolikanasobne pomalejsi.
 
U16 zavadim z multiboot-grub. Na rozdil od puvodniho SDD vypada spousteni jako z 'live' instalace.
Na puvodnim SSD uvodni obrazovka s napisem "Ubuntu" a teckami v soucasnosti neni a system je zaveden za 20 vterin.

Muze pomaly nabeh U16 souviset s 'Trim' noveho SSD, nez jej system prerovna, nebo jde o neco jineho ?

[juwa2]

To je jistě pravda, ale jak to mám vyhodit ?
V základních aplikacích ani v  automatickém spouštění to nemám...

No odněkud se to spouštět musí - to snad uznáš. Systémové věci/služby se spouští odjinud, používej google a wikiubuntu a najdi si to (všechna místa odkud se tyhle věci spouští)   /etc/xdg/autostart a pak ještě Systemd, Upstart a SysV
Grafické klikátko Boot-up-manager (BUM) ani rcconf bohužel pro U 18.04 k dispozici nejsou, teď by se ti hodily. Možná by ti pomohl Sysv-rc-conf tool

Kód: [Vybrat]

sudo apt-get install sysv-rc-conf

spuštění:

Kód: [Vybrat]

sysv-rc-conf


Nebo tohle https://askubuntu.com/questions/1043248/rcconf-package-alternative-in-bionic-beaver

[juwa2]

Mam podobny dotaz k rychlosti spousteni, ale pro Ubuntu-16 na SSD.
Minuly tyden jsem koupil novy SSD. Klonovani Acronisem mi preneslo partition s Ubuntu 16 beze zmen,
alespon to tak na prvni pohled vypada. Presto nabeh Ubuntu je nekolikanasobne pomalejsi.
 
U16 zavadim z multiboot-grub. Na rozdil od puvodniho SDD vypada spousteni jako z 'live' instalace.
Na puvodnim SSD uvodni obrazovka s napisem "Ubuntu" a teckami v soucasnosti neni a system je zaveden za 20 vterin.

Muze pomaly nabeh U16 souviset s 'Trim' noveho SSD, nez jej system prerovna, nebo jde o neco jineho ?

1. Ano, může to souviset se zarovnáním oddílů, pak klesne výkon disku. Ověříš příkazem

Kód: [Vybrat]

sudo fdisk -l
2. Pokud jsi klonoval pouze oddíl se systémem, záleží také kde máš nainstalovaný zavaděč. Zavaděč samotný lze reinstalovat/opravit.

3. Acronis sice umí pracovat i s linuxovými disky/oddíly nicméně doporučuji použít raději Clonezillu.
Jak jsem zjistil, práce s Acronisem je sice o něco pohodlnější, ale nedokáže ošetřit určité věci. Proto ti doporučím naklonovat to znovu Clonezillou - je šance že to bude OK. A pokud klonuješ celý disk, musí bootování probíhat naprosto stejně jako z disku původního.

4. Pokud to ale nepomůže, udělej čistou instalaci na nové SSD. V rámci usnadnění si nejprve všechny PPA a nainstalované programy zálohuj pomocí Aptik - pak to v novém systému zase obnovíš. Ušetříš spoustu práce a času.
Nastavení aplikací (např. složky profilů prohlížečů) si normálně zkopíruj.

[Janslav]

Při pokusu o instalaci mi to nenalezlo balík sysv-rc-conf...

[juwa2]

Při pokusu o instalaci mi to nenalezlo balík sysv-rc-conf...

Ano, omlouvám se - ani sysv-rc-conv už není pro U 18.04 k dispozici.  Zdá se,(bohužel) že s každou novější verzí se stává Ubuntu čím dál víc nepřátelské vůči uživatelům. Věci co fungovaly léta k plné spokojenosti najednou nefungují/nejsou dostupné. Autoři aplikací už mají (jak v čím dále větší míře pozoruji) těchto neustálých změn plné zuby a postupně upouštějí od vývoje (vůbec se jim za této situace nedivím). Oproti tomu jsou distra zaplavována dalšími a dalšími neužitečými nesmysly, samozřejmě - jak jinak, ve jménu bezpečnosti. Zvláště bych vyzdvihl celé otřesné gnome v U 18.04, ale ještě větší paskvil v jeho rámci je Nautilus (3.26.3) a zejména Gedit (3.28.1) - to snad musel někdo dostat za úkol aby potrestal uživatele.... A nainstalovat předchozí "slušnou" verzi? Nemožné (záměrně - a to mi nikdo nevymluví - naházené "klacky pod nohy")....
------------------------------------
Zkrátka to celé postupně "windowsovatí", včetně automatických aktualizací (překvapení dekády) a "bonzování" (první pokusy již ve 14.04). Zdá se mi, že zkrátka docházejí penízky a tak se monetizuje co se dá.... Maximální znechucení z tohoto vývoje - a ano, je to (zatím) stále zadarmo, ale původní myšlenka o svobodném systému/sw je dávno pryč.... 
----------------------------------------------------------------------------------
Určité řešení (ale nikomu ho nenutím):
Zůstat na U 14.04 i po konci EOL. Přejít na repozitáře .old. V parametrech načítání kernelu (v grubu) vypnout nesmysly typu pti a trampolína které jenom snižují výkon, přitom reálný dopad na bezpečnost je silně přeceňovaný.
Je to jenom kampaň výrobců kteří chtějí především prodávat nový HW (tentokrát už opravdu zabezpečený, ale pouze do doby než se zase objeví nová,"zázračně v pravý okamžik na jejich objednávku" nalezená hrozba) a tak stále dokola. Tím pádem je problém s léta stagnující obmněnou HW/prodejem zaručena...
Novější verze aplikací řešit případně přes snap nebo appimage, i když zase záleží na čem to bylo zkompilováno, nemusí to vždy na starším systému běžet..

[Janslav]

No tohle je dost pesimistický názor. Asi na tom bude hodně pravdy, ale vracet se mi k Lubuntu 14 opravdu nechce. Snad se tedy vrátit k Lubuntu 16, to fungovalo docela slušně..

Ale znovu bych zopakoval svůj původní dotaz k současnému Lubuntu 18: jak vyhodit aplikaci ze Startupu ?   Snad by to mělo nějak jít, ale nic jsem nikde nenašel.

[juwa2]

No tohle je dost pesimistický názor. Asi na tom bude hodně pravdy, ale vracet se mi k Lubuntu 14 opravdu nechce. Snad se tedy vrátit k Lubuntu 16, to fungovalo docela slušně..

Ale znovu bych zopakoval svůj původní dotaz k současnému Lubuntu 18: jak vyhodit aplikaci ze Startupu ?   Snad by to mělo nějak jít, ale nic jsem nikde nenašel.

Odpověď jsi dostal 10 Září 2018, 13:00:09  tak se nevyptávej dokola jako jojo. A grafické klikátko pro 18.04 není....
------------------
A jestli snad za odpověď požaduješ pouze podrobný návod ve stylu "polož pravou ruku na myš, klikni levým tlačítkem na..", obávám se, že se nedočkáš...   Kam se máš po startup položkách podívat už víš, o zbytek se musíš postarat sám, to za tebe nikdo neudělá. Je to tvůj PC a ty u něho sedíš, tak se snaž.

[Janslav]

Děkuji za jedovatou odpověď a končím tuto diskuzi.

[miro_]

Vracim se k dotazu na problem pomaleho boot U16 po klonovani.
Zkusil jsem Vasi radu "sudo fdisk -l".
Po vypisu stavu partition to vrati nasledovne msg.:

Partition table entries are not in disk order.

Zkusil jsem porovnat 'syslog' puvodniho a klonovaneho disku a myslim ze problem je patrny hned na pocatku:

: dev-disk-by\x2duuid-03e17fa8\x2df05b\x2d4266\x2d94bf\x2de88a7301ac2f.device:
 Job dev-disk-by         \x2duuid-03e17fa8\x2df05b\x2d4266\x2d94bf\x2de88a7301ac2f.device/start timed out.
: Timed out waiting for device dev-disk-by\x2duuid-03e17fa8\x2df05b\x2d4266\x2d94bf\x2de88a7301ac2f.device.
systemd[1]: Dependency failed for /dev/disk/by-uuid/03e17fa8-f05b-4266-94bf-e88a7301ac2f.
systemd[1]: dev-disk-by\x2duuid-03e17fa8\x2df05b\x2d4266\x2d94bf\x2de88a7301ac2f.swap:
 Job dev-disk-by\x2duuid-03e17fa8\x2df05b\x2d4266\x2d94bf\x2de88a7301ac2f.swap/start failed with result 'dependency'.
systemd[1]: dev-disk-by\x2duuid-03e17fa8\x2df05b\x2d4266\x2d94bf\x2de88a7301ac2f.device:
 Job dev-disk-by\x2duuid-03e17fa8\x2df05b\x2d4266\x2d94bf\x2de88a7301ac2f.device/start failed with result 'timeout'.

Nedostupne UUID je swap puvodniho disku ! Jak to spravit a neshodit jiz dnes funkcni oba systemy ?

Na vysvetlenou jak jsem klonovani a obnovu do stavajiciho stavu provadel:
 kolonovani  bylo z SSD 120GB na SSD 240GB. Na disku mam XP a U16. XP nejsou na 'C:' !
 (Puvodni XP instalaci jiz dnes nejsem schopen preinstalovat a tak je prenasim a obnovuji jiz jen pres image !)
 Po klonovani nebyl boot do XP funkcni, U16 funkcni bylo, ale jiz s timto pomalym startem cca 2 minuty.
 Zvetseni nekterych partition mi nevyhovovalo a tak jsem je formatoval, zmensil a obnovit pres image
 mimo partition s U16 ktere zustalo na konci disku.

[juwa2]

1. Zpřeházené partitions ničemu nevadí (kromě toho, že to blbě vypadá)...
2. Číms to klonoval??  Jediná Clonezilla zachovává UUID oddílů.
A pokud neklonuješ celý disk, ale pouze chaoticky vytváříš jednotlivé oddíly, udělals v tom akorát guláš....
Nově vytvořené oddíly dostanou vždy nový UUID který pak nesedí se zápisem v fstab.
--------------------------------------
Teď hezky koukej uvést do souladu UUID všech oddílů (vč. swapu) se stavem který je v souboru /etc/fstab
Buď změň ty UUIDy podle fstabu nebo (což bude asi jednodušší) si stávající UUIDy zjisti a edituj fstab. V každém případě to musí souhlasit.
-------------------------------------
Pokud ani potom nedosáhneš cíle, nezbývá než to celé reinstalovat "od píky"

[miro_]

V prvnim prispevku jsem to psal. Klonovani jsem delal 'Acronis 2009'.
Kdyz jsem testoval 'Win10-insider'  a po jejich aktualizacich disk nestacil tak jsem se musel presunout na vetsi disk.
Spolu s  'Win10-insider' tam byl Ubuntu 14 a zadny problem jsem nezpozoroval.

[miro_]

Pri kontrole UUID jednotlivych partition jsem zjistil ze 'swap' na klonovanem SSD nema zadne UUID !
Postacilo je vygenerovat v 'GParted' a zapsat do '/etc/fstab'.
Nyni jiz je rychlost spousteni srovnatelna s vychozim SSD.