Tara o której wiemy już wszystko. Linux Mint 19 „Tara”
Na przekór etykietce „najpopularniejszej dystrybucji tej dekady”, Linux Mint 19 „Tara” uniknął marketingowego embarga informacyjnego. Kompletnie nie eskalowano napięcia przed ostateczną wersją finalną. Od tygodni znamy nowe funkcje elementów składowych systemu, zmiany w środowisku graficznym. Ba, udostępniono nawet obrazy instalacyjne wersji Beta. I dla większość fanów tej dystrybucji finalna wersja Linux Mint 19 była aktualizacją dla wspomnianej wersji Beta, która u wielu jest już podstawowym systemem od kilku tygodni.
Nowa podstawa
Linux Mint 19 z kernelem 4.15 i bazą paczek z Ubuntu 18.04 nikogo nie powinien dziwić. To sukcesywne podążanie za koncepcją wydań ogłoszoną parę lat temu. Z każdą nową wersją o długoterminowym wsparciu – nowa seria Minta. Wybawienie dla osób znudzonych wersją oprogramowania z 16.04. Tym razem w roli głównej występuje np. serwer grafiki X.Org 1.19.6, biblioteki Gtk+ 3.22.30, Qt 5.9.5, glibc 2.27 i Mesa 18.0.0, kompilator gcc 7.3.0 oraz demon systemd 237.
Cinnamon 3.8
Flagowe i autorskie środowisko graficzne w nowym wydaniu musiało otrzymać oczywiście nowy numer. Nie jest to jednak zmiana kosmetyczna, ale potężna dawka poprawek i ulepszeń, które autorzy zaaplikowali swojemu dziełu.
Na początku należy wspomnieć o ogromnej ilości optymalizacji jakich doczekał się Cinnamon. Okna rysowane są obecnie niemal cztery razy szybciej niż w poprzednich wersjach.
Powiadomienia systemowe stały się sprytniejsze. Pojawił się przycisk zamykania, który robi to co ma robić, bez odsyłania do programu generującego powiadomienie. Okienko nie ulega również rozmyciu po najechaniu myszką. Wprowadzono limit powiadomień w jednostce czas na aplikację. Okienka znikają, jeżeli zostanie aktywowany program który chce przykuć naszą uwagę. Możemy również skonfigurować miejsce pojawiania się tych informacji.
Pojawiły się również ikony symboliczne poprawiające nowoczesność całego środowiska.
CJS, interpreter Javascriptu to obecnie GJS 1.50.2 i wykorzystuje mozjs52.
Poprawiono wsparcie dla dekoracji okna CSD, dodano wsparcie dla GTK 3.22.
Elementy systemowe zostały przepisane do Pythona 3.
Dodano wsparcie dla protokołów admin://, elogind i systemd-timedated1.
System oraz środowisko sprawniej dogadują się też z laptopami. Ekran jest automatycznie blokowany przed uśpieniem, touchpad jest aktywowany automatycznie gdy system nie wykryje myszki, zamknięcie pokrywy laptopa może również wyłączać system.
Timeshift i Menedżer Aktualizacji
Istotnym elementem systemu stał się Timeshift umożliwiający sprawne tworzenie migawek systemu i jego przywracanie w przypadku problemów po np. aktualizacji. Również Menedżer Aktualizacji przypomina o ustawieniu tego narzędzia (sam system informuje nas o takiej możliwości już na ekranie startowym). Przyrostowe tworzenie kopii systemu (rsync, btrfs) pozwala niemal bezstresowo aktywować automatyczne aktualizacje systemu. W przypadku jego awarii przywrócenie ostatniej działającej wersji Minta to parę chwil. W tym wszystkim najlepiej odnajdą się nawet zwykli (automatyczne aktualizacje). Nie powinni oni mieć problemów z ewentualnym przywróceniem systemu do stanu sprzed paru dni. Ułatwia to graficzny interfejs za pomocą którego obsługujemy cały proces.
Menedżer Oprogramowania
Niekończąca się rozbudowa i przebudowa Menedżera Oprogramowania trwa nadal. Tym razem zmieniono nieco układ okna, dodano delikatne animacje, poprawiono nawigowanie za pomocą klawiatury. Wyszukiwanie podsuwana nam wiele bardziej sugestywnie wyniki (z uwzględnieniem kategorii). Pojawiła się wewnętrzna pamięć podręczna programu, dzięki której Menedżer tak samo łatwo obsługuje paczki deb (APT) oraz Flatpak. Wsparcie dla .flatpakref oraz .flatpakrepo pozwala instalować Flatpaki wprost z internetu (przycisk na stronie). A przy okazji program uruchamia się też znacznie sprawniej niż poprzednio.
Aplikacje systemowe
Osławione XApps również doczekały się rozwinięć swojej funkcjonalności i innych usprawnień.
Edytor tekstu Xed doczekał się nowego okna z ustawieniami. Program podciągnięto również pod standard GTK 3.22. Wprowadzono skróty klawiszowe w menu pomocy a nowa wtyczka zajmie się autouzupełnianiem tekstu.
Przeglądarka PDF, Xreader, doczekała się podobnego okna z preferencjami. Mamy możliwość aktywowania opcji „ostatnio oglądane” i szybkiego powrotu do poprzednich plików PDF. Możemy także zmienić rozmiary miniatur oraz wykasować notatki.
Inne
Wśród pozostały licznych zmian znajdziemy też kilka takich, które mogą mieć namacalny wpływ na codzienną jakość pracy.
Nośniki pamięci USB możemy sformatować z systemem plików exFat.
Źródła Oprogramowania potrafią pokazać paczki zainstalowane z PPA.
Ekran logowania wspiera wielomonitorowe stanowiska pracy i pozwala wybrać ten domyślny.
Firefox pokaże nam na panelu postęp pobieranych plików.
W domyślnej instalacji znajdziemy GNOME Calendar z możliwością zsynchronizowania go z kontem Google.
Kodeki multimedialne zawierają również fonty Microsoftu.
Zobaczymy też wiele nowych tapet, poprawiony temat graficzny Mint-Y (domyślny), nowe ikony, jeszcze lepsze wsparcie dla HiDPI.
System będzie otrzymywał poprawki bezpieczeństwa do 2023 roku. Wszystkie następne wersje Linux Mint aż do roku 2020 będą korzystać z tej samej podstaw – Ubuntu 18.04 LTS i Mint 19.
Instalacyjne obrazy ISO znajdziemy pod tym adresem.
74 komentarze
Dodaj komentarz
Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.
Ciekawe czy przewidziano możliwość upgrade’u z 18? Czy może trzeba będzie instalować od nowa, jak przy zmianie 17 na 18.
Niedługo pojawią się informacje, jak wykonać jaką aktualizację.
Pozostaje czekać na wydanie HPLIP-a pod Tarę.
A jaki masz z tym problem, bo nie bardzo rozumiem? Jak praktycznie 100% programów “core” Minta pochodzą one bezpośrednio z Ubuntu, a tu:… https://packages.ubuntu.com/search?keywords=hplip&searchon=names&suite=bionic§ion=all voila 😉
Mam pytanie do kogoś, kto ma Mint 19 z Cinnamonem na jakiejkolwiek, ale lepiej (tzn. szybciej się zobrazuje) z mniejszą ilością RAM (ot, powiedzmy 4GB), maszynie. Czy dalej po kilkunastu-kilkudziesięciu minutach wykonywania tych samych operacji system ulega totalnemu zawieszeniu (wycieki pamięci)?
Próbowałem z najnowszym HPLIP 3.18.6
System w Printers -localhost drukarkę LaserJet M1132 MFP widzi ale nie drukuje (brak ikonki HP w pasku na dole)
W terminalu sh hplip-3.18.6.run wyrzuca error: linuxmint-19 version is not supported…
Można ją w inny sposób zmusić do pracy ?
Ok… Zdaje się, że już rozumiem pierwszy post. W Ubuntu/Mint masz wersję 3.17.10 i ta powinna działać. Co ciekawe nawet w nadchodzącym wydaniu 18.10 jest nadal ta wersja hplip.
HPLIP 3.18.6 powstał, gdy jeszcze Mint 19 nie było. Jeśli skrypt w *.run sprawdza wersję, to w istocie otrzyma odpowiedź, że jest to Mint 19 i wygeneruje błąd.
Jeśli bardzo potrzebujesz akurat tej wersji hplip to musisz poszukać, czy nie ma w jakimś PPA lub zbudować sobie paczkę ze źródeł lub spróbować zainstalować pakiet dostarczany w tarballu (osobiście jestem jednak zwolennikiem wprowadzania do systemu wyłącznie pakietów rozpoznawanych przez ich menedżer w danej dystrybucji).
Ja bym stawiał na czystą instalację. Przejście z init (16.04) na systemd (18.04) może utrudnić bezbolesny upgrade. A jak ktoś miał swoje własne konfiguracje systemu, to tym bardziej. I nie trzeba czekać na żadne poradniki. Godzinka i po strawie.
reddit /r/linux4noobs/comments/8v7n14/mint_why_is_cinnamon_taking_up_4g_of_ram/
Prawdopodobnie jakieś niezałatane pluginy. Nigdy nie używałem Cinnamona więc nie znam się na tym.
To nie do końca tak, a przynajmniej być może nie na wszystkich konfiguracjach sprzętowych. U mnie sam Cinnamon znajda około 240 – 280 MB pamięci. Więc jest całkiem nieźle. Niestety, pozostały 500MB zjada 21 oddzielnych procesów cinnamon-settings-daemon (wprowadzonych na rzecz rozproszonej i stabilniejszej kontroli nad systemem). W ten sposób sam system zajmuje nam około 800 – 900 MB pamięci RAM. Trochę słabo to się sprawdzi na maszynkach z 4GB.
A jak do tego dojdą wycieki… To już inna bajka. Na szczęście mój Mint wytrzymuje bez resetowania już od tygodnia i nie zauważyłem przygód z wyciekami.
Niestety wersja 3.17.10 domyślnie zainstalowana z obrazu Mint 19 nie działa i chociaż system drukarkę wykywa, ta nie drukuje. /3.18.16 z Mint 18.2 na lapku żony drukuje bez problemów/. Wygląda na to że niestety będę musiał wrócić do wcześniejszej wersji Mint bo nie mam wiedzy odnośnie budowania paczki ze źródeł. Dziękuję za odpowiedź.
Nie musisz nawet budować paczki (choć gorąco zalecam; może znajdzie się jakaś dobra dusza, która Ci to zbuduje – spytaj np. na forum Minta) – możesz ściągnąć tarball ze stronki hplip, a instrukcja instalacji również się tu mieści: https://developers.hp.com/hp-linux-imaging-and-printing/howtos/install#howtocheck5
To nie są niezałatane pluginy Cinnamona, a jakaś kwestia między bibliotekami Gtk a domyślnym WM używanym tak w GNOME3, jak również w jego klonie w Cinnamon. Na komputerze żony wprawdzie Cinnamon brał chyba mniej RAM niż owe 800-900MB, ale po jakimś czasie (powtarzalne czynności – to jest ważne) – powodował kompletne zawieszenie się komputera, któremu nie pomagało nic innego oprócz twardego resetu. Problem był nagłośniony w okolicach wejścia Ubuntu 18.04, ale znany jest już wcześniej.
Aha i raczej nie chodzi o to co na reddicie. Dla mnie obojętne jest, czy Cinnamon bierze sobie 4GB, czy 200MB byleby tylko potrafił racjonalnie zarządzać pamięcią. Np. w przypadku Plasmy, gdy jakaś aplikacja ma wycieki pamięci (np. tak było choćby z Qupzillą czy Kadu), to sam proces plasmashell się wywłaszcza (zajmuje mniej RAM) – fakt, Plasma wolniej chodzi, ale mam czas na reakcję. W przypadku Cinnamona (i pojawiło się to w wersji 3.8.x + Gtk+3.22) dochodzi do zapełnienia wszystkiego i system wisi. Nie ma reakcji na dowolny klawisz. Nawet na konsolę nie da rady się przełączyć, by pozamykać zbędne procesy.
A udało Ci się ustalić co tak puchnie? Sam Cinnamon, czy któryś z csd?
Nie. Jak już spuchnie – koniec kropa – nie ma żadnej możliwości dowiedzenia się (twardy reset). Komputer żony – nie używam i tylko słyszę, że: nic nie mogę zrobić! Teraz już też nie ustalę, albowiem Cinnamon poszedł do kosza i nie bardzo chyba mam potrzebę go przywracać. Ogólne objawy natomiast dokładnie takie same jak szeroko opisywane przy okazji Ubuntu 18.04 (tak z Gnome, a nie z Cinnamonem, ale… Gtk+ to samo, a WM w obu tych przypadkach praktycznie ten sam).
A powiedz jeszcze, czy to sprzęt Della?
Już wszystko działa. Rozwiązaniem okazał się być brakujący HP-plugin /qt5ct/. Jeszcze raz dziękuję za pomoc.
Packard Bell, czyli Acer. To chyba nie jest zaleźne od sprzętu. W necie miły filmik. Gostek naciska na przycisk menu przez kilkanaście minut i… zwiecha 🙂
A to co napisałeś jest… jak dla mnie śmieszne. Qt5ct to jest wyłącznie “programik”, którego jedynym celem jest to, by aplikacje Qt5 miały w innych środowiskach odpowiedni wygląd. Nie powinno to w ogóle mieć żadnego wpływu na możliwość drukowania. Czego to się człowiek jeszcze nie dowie w swoim starczym życiu…
Inna sprawa, że taki Mint adresowany ponoć do ZU winien ów qt5ct mieć po prostu na pokładzie OTB.
Rozumiem, że dla starego wyjadacza może to byc śmieszne.. Kończyłem kierunek nie mający nic wspólnego z politechniką więc jestem takim ZU. W konsoli wpisałem hp-plugin. Coś tam sobie pociągnął z sieci i bingo ! Zadziałał 🙂
Tak,wybierasz instalację ręczną w hplip i wskazujesz system ubuntu 18.04,jakos tak
Jest na to rada,prosta i skuteczna:
XFCE
Jest też: MATE, Plasma, Deepin, OpenBox, JWM i od groma innych. Sam (za żonę) taki wybór zresztą dokonałem. Czy jednak przez ten wybór Cinnamon i GNOME pozbędą się tych problemów – wątpię.
Grunt że działa.
PS: Nie mam żadnego wykształcenia technicznego, a gdy się uczyłem, to o PC nikt nawet nie słyszał. Informatyka w szkole? 😀
Tak, mogłem raz na fizyce popatrzeć przez chwilę na Timex Computer 2048 😀
Musi być Mint? Obecne wydanie choć zdaje się być responsywniejsze od poprzedniego to jednak swoje wymagania ma i rakietą nawet na szybszym sprzęcie nie jest. Zerknij ma MX Linux (podrasowany, customowy Debian z XFCE): świeższe kernele, soft podobny, brak systemd i flatpaki z popularnym softem ładnie działają. Fajnie działa na starszych sprzętach.
Cinnamon nie był na Mincie i – po wielu, doprawdy wielu, latach z dystrybucjami opartymi o APT (od Debiana, przez jego bezpośrednie pochodne np. Sidux, dalsze pochodne – jak *buntu, na krótkiej randce z Mintem skończywszy) – nie wrócę do nich i w domu i w firmie, dopóki ja zarządzam tymi komputerami żadna dystrybucja taka nie stanie. Niemniej jednak gdyby okazało się, że problem w Mint 19 Cinnamon nie występuje, to wiedziałbym gdzie szukać problemu. XFCE właśnie postawiłem żonie i jak na razie jestem z tego zadowolony na jakieś 60-70%. Flatpak – nie problem (działa), ale nie potrzebuję go.
Po prostu chciałem wiedzieć jak z tym Cinnamonem. Pewnie jak się wnerwię, to zainstaluję tam KDE i będę miał spokój 🙂 Przynajmniej środowisko, które dość dobrze znam, a po ostatnich zmianach zaczyna być doprawdy mało wymagające. Aplikacje – dla niesmartfonowca (a żona nim nie jest) – też zdecydowanie bardziej czytelne w obsłudze. W sumie… może to niezły pomysł.
Jeśli to cudzy komputer to… trzymaj się tego co znasz, co działa i nie trzeba naprawiać.
Ja przy doborze distra kieruję się dostępnym softem i długim wsparciem, a następnie jeśli chodzi o środowisko graficzne równam w dół tj. do najsłabszej maszyny. W ten sposób wszędzie mam to samo i nie nadwyrężam przesadnie mózgownicy jak coś gdzieś sprawia problemy.
Ja mam od około tygodnia Mint 19 (wcześniej beta) na starym AMD z 4 GB RAMu i na dysku SSD 😉
Jeszcze ani razu system mi się nie zwiesił….
Fakt , świeża instalacja i uruchamiam głównie programy do obróbki zdjęć na kilka chwil oraz przeglądarkę Firefox ale daje radę. Jedyne co ma miejsce to rozłączanie z wifi bez sygnalizacji tego faktu. Pomaga wyłącz i włącz sieć bezprzewodową…
Tak trochę poboczem i obok wątku. Nie wiem czy jestem za stary czy czegoś nie kumam. “cynamona” z Archem od dziewięciu miesięcy używam i jedyne problemy to przejście z 3.6 na 3.8. Po pierwszej aktualizacji osunięte restarty . Lapka bez potrzeby nie wyłączam , czasami chodzi i 12 godzin bez współpracy, nagminnie używam Dartable do obróbki 300 i więcej zdjęć (ot taka mania na starość) potem Gimp żeby wygładzić efekt, a w chwilach wolnych Calibre. No nie było wypadku żeby odmówił współpracy, zawiesił się przy wybudzeniu. A sprzęt nienowy, system wykrywa 3,7 RAMu. (a producent twierdzi ze mam 4 Gb). Na innym forum czytałem żeby sprawdzić że po kilku minutach klikania ikony Menu sprzęt zawiesza się dokumentnie. Ludzie, naprawdę się w to bawicie? Dla mnie powtarzalne sytuacje to odpalnie przeglądarki, Audacius w tle, Dartable w natarciu – no zero czknięć nawet po wybudzeniu.
Czemu lapka nie wyłączasz ? Za długo startuje system ? 😉 Ja od niedawna mam Linuxa na SSD i moim zdaniem to ideał , nawet 4 GB RAM-u wystarcza żeby pracować bez żadnych zacięć i spowolnień…Wyłączanie systemu trwa 2 sek. ? Startuje nieco dłużej bo kilkadziesiąt sekund ale jest przepaść między tym co było a jest…
Miałem podobny problem w pracy na Gentoo. Miałem Cinnamona, który po tygodniu pracy na komputerze zawieszał się i trzeba było go restartować. Z Gnomem shellem na prywatnym lapie miałem podobne przeboje (Ubuntu GNOME). Rozwiązaniem okazało się powrót do korzeni, czyli przełączenie na środowisko MATE w pracy i instalacja Ubuntu MATE na prywatnym lapku.
Jeśli na SSD system włącza Ci się (jak rozumiem z zimnego) kilkadziesiąt sekund, to przyglądnąłbym się temu SSD lub swoim ustawieniom. Stanowczo zbyt długo. Tyle nie powinien startować nawet komputer z najbardziej tradycyjnym HDD (choć niektóre DE będą szybciej nadawały się do używania).
Zmierzony odczyt to zaledwie 283 MB/sek. 😉 Przy teoretycznym 550 MB/sek. Winna jest stara SATA ? Chyba w wersji I a sam dysk jest w standardzie SATA III. Jutro lub dziś sprawdzę ze stoperem ile to dokładnie trwa od wybrania Linux Mint w Grubie 😉
No to – prawdopodobnie – masz wąskie gardło: SATA.
Można by pewnie zrobić upgrade i kupić kartę z portami SATA III na PCI-Express (to komputer desktop) tylko nie wiem czy to ma sens ? Byłoby do 2 x szybciej ? Na początek zainwestowałem w kartę z USB 3.0 do podpinania szybkich urządzeń peryferyjnych , czytnik kart SD , HDD itd. 😉
Patrząc na wartość transferu masz złącze SATA II. Nie warto kupować dodatkowego kontrolera, bo dobre karty są trudno dostępne i drogie, a na kiepskich złapiesz wartości jak dla SATA II lub niewiele większe. Jak masz wolne złącze PCI-e 2.0 4x to warto rozważyć SSD w formacie M2 na karcie/adapterze do tego złącza.
Tak jak napisał @pavbaranov:disqus coś Ci ten system za długo startuje (no chyba, że bardzo długo wisi na BIOSie).
Niczego nie ryzykuję, /home mam i tak w osobnej partycji, więc jeżeli upgrade nie wypali, zawsze mogę postawić system od nowa.
Od naciśnięcia Enter w Grub do pojawienia się pulpitu mija ok. 31 sek. 😉
Faktycznie mam SATA II , płyta główna to ASUS M2N-E (NVIDIA nForce® 570 Ultra™ MCP supports:
– 1 x Ultra DMA 133 / 100 / 66 / 33
– 6 x Serial ATA 3.0Gb/s
– NVIDIA MediaShield™ RAID supports RAID 0, 1, 0+1, 5 and JBOD span cross Serial ATA drives) .
Obejrzałem sobie tanie chińskie karty z rzekomo SATA III i tam ludzie w rzeczywistości osiągają transfery niższe od mojego obecnego na SATA II 😉 Z kolei dobre karty SATA III kosztują pół ceny mojego dysku SSD , więc odpuszczam temat… W zasadzie to obecna wydajność systemu dyskowego jest dla mnie więcej jak dobra , średnia prędkość odczytu 282,4 MB/s (100 próbek) , czas dostępu 0,07 ms (1000 próbek). Wolę klasyczny dysk na złączu SATA bo można go łatwo przenieść do dowolnego komputera w tym laptopa.
“Startuje nieco dłużej bo kilkadziesiąt sekund ale jest przepaść między tym co było a jest…”
Zamiast wróżyć z magicznej, szklanej kuli polecę sprawdzenie co tam się dzieje za pomocą “systemd-analyze blame”/”systemd-analyze critical-chain” – być może jakiś unit startuje bardzo długo. Szklana podpowiada mi, że przyczyną takich atrakcji mogą być uszkodzone/przestarzałe configi (pacman sam configów nie podmienia – zapisują się jako pliki nazwaconfigu.pacnew).
Drugą opcją może być to, że zapomniałeś o włączeniu funkcji trim i wydajność I/O z czasem bardzo spadła – Arch nie ma włączonego domyślnie cotygodniowego trima (można sprawdzić to za pomocą “systemctl status fstrim.timer”) ani nie dodaje opcji discard w fstab. Trzeba włączyć samemu.
Trim włączony , każdego dnia się sam robi przez crona.
Czasem robię ręcznie w terminalu.
W fstab noatime bez discard bo tak zalecają w poradniku mint 19 i ssd
System postawiony od nowa , więc nie wiem co by mogło być przestarzałe ?
Fakt , nie widzę co się długo inicjuje bo widać wyłącznie logo linux mint , wskaźnik myszki pojawia się ok. 5 sek. wcześniej niż sam ekran główny systemu. Musiałbym przejrzeć logi bootowania ?
Instrukcja upgrade z wersji 18.3 systemu już dostępna na :
https://community.linuxmint.com/tutorial/view/2416
Już się pojawiła : https://community.linuxmint.com/tutorial/view/2416
Obie komendy nie pokażą jednak czasu od “zimnego” startu do pojawienia się możliwości pracy w DE.
To co się długo inicjuje nie zobaczysz nawet jeśli splasha nie będzie (choć samo wczytanie splasha również zajmuje jakiś czas; być może tam też plymouth jest – nie wiem i nie chce mi się sprawdzać).
Podstawowe komendy do diagnozowania czasu bootowania w systemach, gdzie jest systemd, są obie, wskazane Ci wyżej przez @Xyzz. Po wywołaniu ich w konsoli zobaczysz co najdłużej zajmuje czas przy bootowaniu. Jest to jednak lekko złudne, albowiem część z usług podnoszonych przez systemd jest podnoszonych równolegle, część jest podnoszonych jeszcze gdy masz już możliwość korzystania z DE itp. Trochę trzeba to umieć czytać 🙂 Np. uruchomiony w pewnym momencie dzisiaj komputer pokazał mi, że jedna usługa trwała ponad 1,5 minuty, a jeszcze inna ok. 30 sek. Nie oznacza to jednak, że DE pojawiło się dopiero po kilku minutach.
IMO – jeśli czas z “zimnego” startu Ci pasuje, a nie znasz się na tym, które usługi możesz wyłączyć, a których na pewno nie, to zostaw jak jest lub daj komputer komuś, kto będzie wiedział co ma zrobić. Przy czym jeśli będzie wiedzieć bez wypytania Ciebie o to co jest, a co nie jest potrzebne, to nie jest to ktoś, kto się zna.
Czekaj, czekaj – “Trim włączony , każdego dnia się sam robi przez crona.”. Z tego co pamiętam, to starsze ssd-ki nie były demonami prędkości jeśli chodzi o szybkość manualnego trim i kilkanaście sekund potrafiło to zająć. Jak zapisujesz/usuwasz codziennie ~ 1/10 pojemności dysku, to codzienny trim może być delikatną przesadą i można rozważyć cotygodniowy trim.
Jeśli włączyłeś codziennego trima przez crona, to łatwej metody sprawdzenia czy to jest powodem dłuższego startu systemu nie ma (oprócz wyłączenia tego w crontabie i sprawdzenia, czy system bez tego startuje szybciej).
Jeśli włączyłeś to korzystając z timerów systemd (edytując timer fstrim.timer aby startował codziennie oraz wpisując “systemctl enable fstrim.timer”), to czas startu danej jednostki sprawdzisz poleceniem “systemd-analyze blame”. Jeśli problemem jest tutaj wolny fstrim, to jako pierwsza powinna pojawić się jednostka “fstrim.service” razem z czasem potrzebnym do jej wykonania.
“Musiałbym przejrzeć logi bootowania ?”
Logi bootowania najprawdopodobniej nic ciekawego nie pokażą, ale można sprawdzić logi z ostatniego uruchomienia poleceniem “journalctl -b”.
“Trim włączony , każdego dnia się sam robi przez crona.”
To może być problemem dłuższego startu, bo na starszych ssd-kach “manualny” trim potrafił zająć trochę czasu (sata 2 w laptopie może jeszcze to wydłużyć). Codzienny fstrim może być przesadą, jeśli np. zapisujesz/usuwasz 1/10 pojemności dysku dziennie – cotygodniowy mógłby się tutaj sprawdzić lepiej.
Jeśli włączyłeś codzienny trim za pomocą crona, to systemd-analyze nie pokaże czasu potrzebnego na zainicjowany przez crona fstrim. W takim przypadku sprawdziłbym czas drugiego startu systemu tego samego dnia.
systemd-analyze blame
23.597s apt-daily.service
6.151s fstrim.service
1.114s networking.service
1.007s systemd-resolved.service
977ms apt-daily-upgrade.service
960ms hddtemp.service
942ms grub-common.service
934ms speech-dispatcher.service
847ms udisks2.service
722ms dev-sdc1.device
540ms NetworkManager.service
370ms ubuntu-system-adjustments.service
362ms systemd-journal-flush.service
311ms ModemManager.service
303ms networkd-dispatcher.service
270ms accounts-daemon.service
247ms lightdm.service
245ms plymouth-quit-wait.service
213ms upower.service
210ms systemd-udevd.service
207ms systemd-logind.service
203ms avahi-daemon.service
190ms apport.service
186ms keyboard-setup.service
180ms apparmor.service
160ms systemd-modules-load.service
156ms wpa_supplicant.service
134ms lvm2-monitor.service
99ms systemd-udev-trigger.service
92ms nvidia-persistenced.service
88ms gpu-manager.service
85ms thermald.service
83ms lm-sensors.service
75ms colord.service
72ms user@1000.service
71ms systemd-journald.service
64ms alsa-restore.service
63ms polkit.service
62ms rsyslog.service
61ms dns-clean.service
52ms systemd-tmpfiles-setup-dev.service
51ms packagekit.service
43ms pppd-dns.service
36ms dev-disk-byx2duuid-5976caefx2d0f66x2d4001x2d9933x2d0d193b9
34ms systemd-sysctl.service
33ms rtkit-daemon.service
25ms dev-mqueue.mount
25ms blk-availability.service
270ms accounts-daemon.service
247ms lightdm.service
245ms plymouth-quit-wait.service
213ms upower.service
210ms systemd-udevd.service
207ms systemd-logind.service
203ms avahi-daemon.service
190ms apport.service
186ms keyboard-setup.service
180ms apparmor.service
160ms systemd-modules-load.service
156ms wpa_supplicant.service
134ms lvm2-monitor.service
99ms systemd-udev-trigger.service
92ms nvidia-persistenced.service
88ms gpu-manager.service
85ms thermald.service
83ms lm-sensors.service
75ms colord.service
72ms user@1000.service
71ms systemd-journald.service
64ms alsa-restore.service
63ms polkit.service
270ms accounts-daemon.service
247ms lightdm.service
245ms plymouth-quit-wait.service
213ms upower.service
210ms systemd-udevd.service
207ms systemd-logind.service
203ms avahi-daemon.service
190ms apport.service
186ms keyboard-setup.service
180ms apparmor.service
160ms systemd-modules-load.service
156ms wpa_supplicant.service
134ms lvm2-monitor.service
99ms systemd-udev-trigger.service
92ms nvidia-persistenced.service
88ms gpu-manager.service
85ms thermald.service
83ms lm-sensors.service
75ms colord.service
72ms user@1000.service
71ms systemd-journald.service
64ms alsa-restore.service
63ms polkit.service
62ms rsyslog.service
61ms dns-clean.service
52ms systemd-tmpfiles-setup-dev.service
51ms packagekit.service
43ms pppd-dns.service
36ms dev-disk-byx2duuid-5976caefx2d0f66x2d4001x2d9933x2d0d193b9f1937.swap
34ms systemd-sysctl.service
33ms rtkit-daemon.service
25ms dev-mqueue.mount
25ms blk-availability.service
24ms kmod-static-nodes.service
24ms flatpak-system-helper.service
23ms systemd-tmpfiles-setup.service
22ms ufw.service
20ms kerneloops.service
20ms plymouth-start.service
18ms sys-kernel-debug.mount
15ms systemd-rfkill.service
15ms dev-hugepages.mount
14ms systemd-remount-fs.service
13ms systemd-random-seed.service
12ms systemd-update-utmp.service
12ms plymouth-read-write.service
12ms console-setup.service
10ms systemd-user-sessions.service
9ms sys-fs-fuse-connections.mount
9ms systemd-update-utmp-runlevel.service
7ms ureadahead-stop.service
4ms openvpn.service
3ms sys-kernel-config.mount
3ms tmp.mount
3ms motd-news.service
2ms setvtrgb.service
Pierwszym nie przejmuj się. Dziwi mnie ponad 6 sek. fstrim. Ponad sekunda podnoszenia sieci wynika prawdopodobnie z faktu, że to połączenie WIFI.
Nie mam systemu z APT, ale popracowałbym nad wszelkimi jego (i tfu, bo to świństwo, packagekit) serwisami. Raz, że – IMO – to w ogóle nie ma prawa być uruchamiane bez zgody roota (ale cóż, to Mint), dwa, że nie jest to potrzebne przy każdym starcie systemu.
Reszta zależy już od tego z czego korzystasz (np. korzystasz z modemu “komórkowego”?).
Tak, czy inaczej – owe 31 sek do DE prawdopodobnie jest wynikiem podnoszenia samego DE. Samo polecenie systemd-analyze pokaże Ci realny czas ładowania systemu do userspace.
Xyzz – zwróć uwagę, że u Marka ta usługa chyba jest podnoszona 2x (nie mam SSD nie znam się na tym – przeanalizuj jego “blame”).
systemd-analyze
Startup finished in 18.729s (kernel) + 2.568s (userspace) = 21.297s
graphical.target reached after 2.555s in userspace
Coś mi ten trim nie pasuje. Nie usuwam wcale plików a teraz tuż po starcie systemu po sudo fstrim -v / :
/: obcięto 206,6 GiB (bajtów: 221830623232)
Po analizie szybkości w tym samym terminalu :
/: obcięto 801 MiB (bajtów: 839876608)
Może trzeba zostawić jaką przestrzeń wolną unallocated na overprovisioning ? na moim dysku SSD żeby nie trzeba było trimować 206 GB ?
16.04 miał już systemd.
ostatni z upstart ( “poprawionym” initem od cannonicala) to 14.04
Jak na SSD długo. Coś pewnie możesz jeszcze popracować. Na SHDD czasy jakie miałem, to od 8 do 13 sek. 21-22sek to czasy dobrego HDD, a nie SSD. Popracowałbym zatem nad usługami i usunął to co zbędne. Chyba, że wystarcza Ci to. Wówczas niczego nie zmieniać. Lepsze jest wrogiem dobrego.
Ma jeszcze pytanie gdzie ustawia się adres swapa ? Tylko w fstab ? bo zmieniłem niechcący jego rozmiar i system teraz bootuje 3 min. 🙁 Trzeba chyba poprawić adres montowania swapa ?
“Nie mam systemu z APT, ale popracowałbym nad wszelkimi jego (i tfu, bo to świństwo, packagekit) serwisami. Raz, że – IMO – to w ogóle nie ma prawa być uruchamiane bez zgody roota (ale cóż, to Mint)”
Mint “odziedziczył” apt-daily.service po Ubuntu. “Wymagane” jest to po to, aby manager aktualizacji pokazywał dostępne aktualizacje bez ręcznego sprawdzania.
https://404.g-net.pl/2017/03/zgin-przepadnij-apt-daily-service/
“Xyzz – zwróć uwagę, że u Marka ta usługa chyba jest podnoszona 2x (nie mam SSD nie znam się na tym – przeanalizuj jego “blame”).”
fstrim.service tam wykonuje się tylko raz. Całe te powtarzanie się niektórych unitów wynika albo z błędu przy kopiowaniu albo z błędu podczas edycji komentarza w Disqs (widać powtarzające się fragmenty oraz unity nie są posortowane względem czasu – blame zwraca wyniki posortowane względem czasu malejąco).
Zrobiłem według instrukcji i wszystko poszło ok. Chociaż instalacja de novo jest szybsza… 😉
Zrobiłem resize głównej partycji /ext4 i wykasowałem starego swapa , następnie utworzyłem nowego , zostawiając ok. 24 GB unallocated . Następnie poddałem edycji fstab zmieniając UID swapa na nowe mimo to start systemu wydłużył się do 3 min. ! System ma jakiś problem ? Bo start dramatycznie się wydłużył , jak można to naprawić ? Nie chce mi się instalować systemu na nowo 🙁
Startup finished in 3min 18.991s (kernel) + 2.577s (userspace) = 3min 21.568s
graphical.target reached after 2.568s in userspace
Masz Minta, a zatem Ubuntu – jeśli nic nie zmieniałeś, to jest tu swap-file. O reszcie można jedynie domniemywać.
Nie rób niczego na łapu-capu. IMO – jeśli nic nie stoi na przeszkodzie – postaw tego wariackiego Minta od nowa (skoro to już musi być Mint). Dopiero później zacznijmy to dostosowywać.
Teoretycznie powinno to działać (zakładając wklejenie nowego, poprawnego UUID – po przesunięciu partycji UUID zmienia się i trzeba wkleić nowy, skopiowany dla odpowiedniej partycji. UUID można podejrzeć za pomocą “lsblk -f”).
1 – można sprawdzić, czy nowy swap jest rzeczywiście wykrywany jako swap.
“swapon –show” powinno pokazywać coś w tym stylu:
NAME TYPE SIZE USED PRIO
/dev/sda5 partition 4G 5.1M -1
2 – można przejrzeć logi kernela z ostatniego startu systemu za pomocą “journalctl -b -k” w poszukiwaniu błędów/ostrzeżeń
Dzięki , problem naprawiony dzięki tej stronie :
https://ubuntu-andrzej001.blogspot.com/2011/07/montowanie-partycji-swap.html
Następnie przechodzimy do /etc/initramfs-tools/conf.d/resume i wpisujemy aktualny UUID.
RESUME=UUID=4183e74e-f986-473e-8d97-8dde1973cab7
Jeszcze aktualizacja iniramfs:
sudo update-initramfs -k all -u
Powinno to także naprawić “hibernację systemu”.
Wszystko 😉
Startup finished in 18.679s (kernel) + 7.792s (userspace) = 26.472s
graphical.target reached after 2.617s in userspace
Witam, u mnie też aktualizacja przeszła bez problemów. Mam zachowane wszystkie ustawienia systemu i programów z wersji 18.3. Jest tylko jedno ale: w przypadku Virtual Box trzeba było zainstalować z repozytorium aktualną wersję Extension Pack (dla wersji ubuntu 18.04).
Poleci ktoś do cinnamona aplikację w stylu “gnome do” do uruchamiania aplikacji i wyszukiwania plików/folderów (+ewentualnie przeszukującej zawartość zakładek i poczty)?
Ja mogę polecić “Albert” – https://github.com/albertlauncher
Indeksuje pliki z wybranych lokalizacji, wyszukuje programy, zakładki z firefoxa/chromium/chrome, ma opcję wyszukiwania w sieci uruchamiającą domyślną przeglądarkę (np. wpisując “gh albert” przeszukam githuba pod kątem repozytoriów zawierających “albert”). Do wyboru ~30 wbudowanych motywów, skrót klawiszowy jest konfigurowalny.
Są też do tego dostępne zewnętrzne wtyczki – https://github.com/albertlauncher/python
A jednak pojawiło się i drugie ale: Kiedy próbuję wysyłać dokumenty z Libreoffice za pomocą email nic się nie dzieje mimo tego, że wszystko jest ustawione tak, jak w Mincie Cinnamon 18.3. Też tak macie? Jakaś rada?
Dzięki, przetestuję po weekendzie 😉
Uważajcie na nowe jajko w mięcie! Lepiej do tej wersji nie uaktualniać.
https://bugs.launchpad.net/ubuntu/bionic/+source/linux/+bug/1779827
Mi działa stabilnie od ponad tygodnia 😉 Aktualizuję na bieżąco i zero problemów , jedynie wifi tp-link czasem się potrafi zwiesić bez żadnego ostrzeżenia. Poza tym super system 😉
Jedynie.. No to jak można mówić o działaniu stabilnym, skoro coś się zwiesza?
W zasadzie masz rację ale sam nie wiem czyja to wina. Mój sprzęt ma swoje lata i jest nieco wysłużony a ta karta wifi na usb pod Windows XP też czasem potrafi się nieprawidłowo zainicjować i pomaga jedynie wpięcie i wypięcie z portu USB. Gdyby użyć innej karty wifi może wszystko byłoby ok. ?
Nie wiem.. nie wróżę z fusów 😉 Prawdopodobnie jest to karta typu combo, a z tymi są cyrki w linuksach.
Nie bądźmy drobiazgowi 😉 To PC i konfiguracji sprzętowych mogą być tysiące , trudno żeby wszystko działało idealnie bez grzebania w systemie ? Kliknięcie na wyłącz / włączą komunikację bezprzewodową jestem w stanie zaakceptować o ile nie będzie ono wymagane zbyt często 🙂
Taka ciekawostka dla wszystkich. Montując dysk SSD wymonotowałem napęd FDD ale nie wyłączyłem jego wykrywania i obecności w BIOS komputera. Dziś użyłem opcji disabled w BIOS i to wręcz dramatycznie skróciło czas bootowania systemu :
Startup finished in 6.059s (kernel) + 2.503s (userspace) = 8.563s
graphical.target reached after 2.493s in userspace
Start systemu Linux Mint 19 jest mniej więcej 2 x szybszy ! Przypadek ? 😉
wifi w mincie nie dzialalo poprawnie i nie dziala nadal ,dziwie sie ze nikt tego przez kilka kolejnych wydan nie potrafi naprawic (kilka roznych laptopow ale chyba zazwyczaj z broadcomem) wifi udaje ze jest ale neta chwilami brak , na innych dystybucjach ten sam sprzet i jest ok