bozsingAz szépen látszik, hogy a legtovább a systemd-journal-flush.service @6.090s +33.215s tart, 33 másodpercig. Itt egy elég részletes leírás a lehetséges megoldásokról: https://askubuntu.com/questions/1094389/what-is-the-use-of-systemd-journal-flush-service De úgy általában is szerintem jó tanács, hogy ha nincs szükséged snap csomagokra, akkor érdemes eltávolítani az egész hóbelevancot (Így: https://askubuntu.com/a/1035917/134964). Ha Chromiumot (is) használsz, akkor annyi dolgod lesz, hogy újra kell telepíteni .deb csomagból (sudo apt install chromium).

    meskobalazsKöszi! A leírásban lévő egyik parancsra (sudo apt autoremove --purge snapd gnome-software-plugin-snap) ez jött: E: A dpkg megszakadt, saját kezűleg kell futtatnia a(z) „sudo dpkg --configure -a” parancsot a probléma megoldásához. Ilyenkor mi a teendő?

      lev258Köszönöm! Van esetleg erre javító jellegű javallatod is vagy bármi ötlet?

        bozsingElőször is futtasd azt a parancsot amit javasol. sudo dpkg --configure -a Ez törött csomagot(kat) javít.

          bozsingA sudo apt autoremove egy rendszertisztító parancs - így önmagában nyugodtan futtathatod. Ha vannak snap-el telepített alkalmazásod(aid), ez a parancs kilistázza őket: snap list Figyelmedbe ajánlom ezt az oldalt mely példákkal mutatja be a snap csomagkezeléséhez szükséges parancsokat.: https://snapcraft.io/docs/getting-started#heading--listing

          bozsingElsőként ez. sudo systemctl disable NetworkManager-wait-online.service

          Köszönöm! Az általatok megadott parancsokat lefuttattam, de az alaphelyzet nem változott, továbbra is lassú: https://www.linkpicture.com/q/Keperny%C5%91kep-err%C5%91l_-2021-04-20-12-41-02.png

            bozsingA snap csomagok is tudják lassítani. Csak jelzem, hogy Ubuntun a Szoftverközpontban most már kizárólag az van. Persze Terminálból, Synaptic-ból továbbra is telepíthetőek hagyományos csomagok. Ebben a listában a + utáni értékek számítanak. Csak azok jeleznek időtartamot.

            lala2Hogyne, köszönöm! # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # # / was on /dev/sda3 during installation UUID=b9ddd069-3fa4-4d35-969f-771e81959207 / ext4 errors=remount-ro 0 1 # /boot/efi was on /dev/sda2 during installation UUID=99DA-B01E /boot/efi vfat umask=0077 0 1 /swapfile none swap sw 0 0

            sömikeÜdv! Erre pedig ezt kaptam: Archived and active journals take up 1.4G in the file system.

              bozsingVan 2 tök egyforma gép, egyforma beállítással/rendszerrel. Az egyik normálisan bootol, a másik nagyon lassan. A lassan bootoló ezt az üzenetet dobja: "Booting in insecure mode" - a másik nem. Ezek szerint mégis van különbség a 2 gép beállításai között - nem? Szerintem a secure boot BIOS beállításnál kéne keresni a különbséget. Arról persze nem vagyok meggyőződve hogy ez okozna ekkora különbséget a boot időben.

                lala2Az a baj, hogy csak a „hibás” gépen láttuk a systemd-analyze kimenetét, így nehéz összenézni a kettőt.

                  meskobalazs Jogos! Ez a "jó" gép kimenete:

                  graphical.target @25.193s
                  └─multi-user.target @25.193s
                    └─postfix.service @12.804s +3ms
                      └─postfix@-.service @9.126s +3.675s
                        └─network-online.target @9.120s
                          └─NetworkManager-wait-online.service @2.540s +6.579s
                            └─NetworkManager.service @2.304s +229ms
                              └─dbus.service @2.299s
                                └─basic.target @2.282s
                                  └─sockets.target @2.282s
                                    └─uuidd.socket @2.282s
                                      └─sysinit.target @2.271s
                                        └─systemd-backlight@backlight:intel_backlight.service @3.>
                                          └─system-systemd\x2dbacklight.slice @3.186s
                                            └─system.slice @426ms
                                              └─-.slice @426ms
                  Ennyivel később: 9 hónap

                  meskobalazs szia! a probléma továbbra is fennáll, ezért most megpróbáltam az általad javasolt helyen (https://askubuntu.com/questions/1094389/what-is-the-use-of-systemd-journal-flush-service) lefuttatni a journalctl --verify parancsot, és ezt az eredményt adja vissza:

                  4c3e50: Invalid object                                           
                  File corruption detected at /var/log/journal/7493ef24b12b49ce88b4013cc65323df/user-1000@0005d64e0fc7973e-df042c599a424c41.journal~:4c3e50 (of 8388608 bytes, 59%).
                  FAIL: /var/log/journal/7493ef24b12b49ce88b4013cc65323df/user-1000@0005d64e0fc7973e-df042c599a424c41.journal~ (Rossz üzenet)
                  PASS: /var/log/journal/7493ef24b12b49ce88b4013cc65323df/user-1000.journal
                  PASS: /var/log/journal/7493ef24b12b49ce88b4013cc65323df/system@3c6285d6860d4e48b46fbf2f2ace839f-0000000000000001-0005d64572559e69.journal
                  PASS: /var/log/journal/7493ef24b12b49ce88b4013cc65323df/system.journal
                  PASS: /var/log/journal/7493ef24b12b49ce88b4013cc65323df/system@0005d64572654f9e-b644e748a454b5a9.journal~
                  PASS: /var/log/journal/7493ef24b12b49ce88b4013cc65323df/user-1000@0005d64574718d30-f2caac891776c4ec.journal~
                  PASS: /var/log/journal/7493ef24b12b49ce88b4013cc65323df/user-1000@e1dd491601204628bf93880298e389d1-00000000000006dc-0005d645746d3cf5.journal
                  59cfa0: Invalid hash (c522d1733ba69d4f vs. c42f8329f9b8def7      
                  59cfa0: Invalid object contents: Rossz üzenet                    
                  File corruption detected at /var/log/journal/7493ef24b12b49ce88b4013cc65323df/system@0005d64e0dc55b01-912f8abd218d15d7.journal~:59cfa0 (of 8388608 bytes, 70%).
                  FAIL: /var/log/journal/7493ef24b12b49ce88b4013cc65323df/system@0005d64e0dc55b01-912f8abd218d15d7.journal~ (Rossz üzenet)

                  lehet, hogy itt van a gond? ha igen, mit hogyan lehet ezt javítani?

                  • klt válaszolt erre.

                    OFF
                    Mindkét gép teljes lemezét valamilyen klónozóval, pl. Clonezilla menteni, "rossz" gépre feltenni a "jó" gépét és megnézni mi a helyzet.
                    ON

                    • klt kedveli ezt.