Cześć Wszystkim...
Na wstępie się ponownie przywitam z zacnym gronem forum.
Nie jestem ,,pro userem", to tak na wstępie, więc przychodzę do Was moi drodzy po pomoc/poradę.
Używam systemu CachyOS, jest świetny, wszystko w nim działa jak chcę, mam wszystko zrobione jak chcę i ogólnie jestem baaardzo zadowolony. Jest moją jedyną dystrybucją i nie mam zamiaru jej już zmieniać (były Ubuntu, Debiany, Minty, Red Hat kiedyś nawet, Mandrivy i inne wynalazki).
Do rzeczy: nurtuje mnie jeden problem, a z racji tego, że nie jestem power userem, mam zagwozdkę, mianowicie, na Mincie ostatnio było coś takiego jak Timeshift i działało to świetnie. Tutaj chciałem tak samo, ale z racji tego, że Cachy mam domyślnie na Btrfs i rozruch na systemd to nie działa to jak w Mincie. Oczywiście rozumiem, że tak nie będzie.
Chodzi o to, że istnieje coś takiego jak ,,migawki" systemu na btrfs i to mi się wydaje dużo lepsze, bo nie zabiera tyle przestrzeni, ale ni diabła nie wiem jak to przywrócić i czego używać by było jak najłatwiej – snapper czy Timeshift?
Snapper mam chyba dobrze skonfigurowanego (w sumie domyślnie jak był proponowany z Cachy Hello) ale migawki robi, bo są :)
Mogę ewentualnie użyć Timeshift zamiast tego bo też ma opcje migawek, pytanie tylko jak to przywrócić w razie rozsypania systemu (chciałbym dmuchać na zimne), bo już się trochę napracowałem przy nim i nie chcę by się to zepsuło.
Czy ktoś może mi wyjaśnić jak mam to przywracać najmniej inwazyjnie i bezproblemowo?
Jakich poleceń użyć, bo w sumie mam mętlik w głowie i nie daje mi to spokoju.
Widziałem gdzieś jak gość przywraca na czystym Archu z Timeshift poleceniami, miał do wyboru której migawki chce użyć wtedy i po odtworzeniu, system wstawał bez problemu.
Jak mam to ,,ugryźć" w CachyOS, tak by było pewne w razie czego?
System plików btrfs oferuje Ci sam w sobie coś jak timeshift (inna sprawa, że IMO - to strata miejsca i czasu). Masz taką apkę Btrfs assistant (jak nie, to doinstaluj) i poukładaj to jak chcesz.
PS: Jeszcze nie udało mi się Kaczkę zdestabilizować tak, by ją odtwarzać z jakiegoś snapa. Z Archem, którego używałem jeszcze dłużej - również.
PS2: Lepiej nauczyć się cachy(arch)-chroota, albowiem chroot działa na każdym systemie.
Ja rozumiem, że ciężko go zepsuć, apka Btrfs assistant jest oczywiście i pewnie z jej poziomu będzie działać.
Mnie tylko chodzi o to, jak odtworzyć ze snapa, czy timeshift (komendą, lub komendami), w razie gdy większość systemu nie działa.
Chroot pewnie potężne narzędzie, nie wątpię, ale co by nie mówić - kopia szybsza :)
Snapy wydają się być idealne, ale nie wiem jak mam odtworzyć, a chciałbym mieć taką wiedzę "w razie czego" :)
No i co do stabilności, to zgadzam się, jak dotąd chodzi jak skała :)
Zerknij na
wiki Archa oraz podane tam linki. Zdaje się że tym asystentem też można to poustawiać. Nie używam, ale z tego co wiem, po prostu przy btrfs nie jest Ci potrzebne narzędzie pn. timeshift, bowiem ta sama funkcjonalność jest wbudowana w system plików.
Cytat: pavbaranov w Lipiec 10, 2025, 08:32:30 AMZerknij na wiki Archa oraz podane tam linki. Zdaje się że tym asystentem też można to poustawiać. Nie używam, ale z tego co wiem, po prostu przy btrfs nie jest Ci potrzebne narzędzie pn. timeshift, bowiem ta sama funkcjonalność jest wbudowana w system plików.
Tak rozumiem. Patrzyłem wiki, patrzyłem jak to ma działać, ale problemem jest bootloader "systemd" - nie da się prosto.
Na czystym Arch, tak, nawet timeshift ogarnia bez problemu z systemd, ale w cachy testowałem i niestety system już nie wstaje.
Narzędzie wbudowane jest, mam skonfigurowane i chodzi mi o to, aby po włączeniu kompa gdy nie mogę się zalogować nawet w trybie tekstowym, móc "coś" zrobić, aby system przywrócić do życia sprzed awarii (może być nawet odpalenie z live) i wiedzieć co wykonać, aby przywrócić właśnie z tego snapa.
Ewentualnie na spokojnie w któryś dzień przeprowadzę na innym dysku operację i powrzucam screeny jak to wygląda, może wtedy będziecie mieli chłopaki jaśniejszy obraz tego o czym mówię.
Istnieje tez inna ewentualność - mógłbym robić kopię całego dysku na inny, nawet w formie klona, ale to tez nie działa, bo po klonie system nie wstaje wcale.
lubię mieć poustawiane jak mam, i chciałbym "w razie czego" mieć kopie, aby w parę chwil mieć system jak sprzed awarii, która oczywiście nie musi się wydarzyć, ale zawsze może :)
Chwila, bo nie bardzo rozumiem. SystemD nie jest bootloaderem. Bootloaderem o podobnej nazwie jest systemd-boot, który można dość łatwo konfigurować (niestety z "palca"). Jak się domyślam tu masz gdzieś problem (w konfiguracji systemd-boot), ale nie wiem jaki i nie będę wiedział, dopóki nie napiszesz w czym konkretnie problem leży.
Jeśli wolisz GRUBego, to zawsze możesz zmienić.
PS: System nie wstaje (jeśli w ogóle mu się to przydarzy) zasadniczo w kilku przypadkach:
1. Została wykonana częściowa aktualizacja systemu - remedium proste: zawsze wykonywać pełną, bowiem Arch (i pochodne) nie wspierają częściowej aktualizacji systemu.
2. Z jakiegoś powodu nowy kernel się pokłócił z systemem - miej 2 kernele w systemie, wystartuj z drugiego, a wówczas możesz sobie naprawiać do woli.
3. Coś poszło nie tak ze sterownikami - tu najczęściej albo poprawne przeinstalowanie sterownika, bądź jego downgrade zwykle pomoże (i dotyczy/-ło/ to głównie nvidia, a Ty masz Intela i AMD - nie pamiętam, by to się wywaliło od kilkudziesięciu lat).
Większość operacji wykonasz nawet bez live. Z live, to właśnie chroot. Dlaczego proponuję takie rozwiązanie? Bowiem pozwoli na rozpoznanie problemu i jego naprawę. Tak, niekiedy trwa to dłużej niż przywrócenie ze snapa, ale snap da tylko poprzedni system, a nie aktualny.
O swoje ustawienia nie musisz się martwić, bowiem są one przechowywane w ~/home, do którego aktualizacja systemu nie ma dostępu. Dla pewności zawsze możesz mieć partycję root i home (choć osobiście już dawno tego zaprzestałem).
Tak, chodzi o systemd-boot, taki jest domyślny w Cachy, ale mi pasuje, nie przeszkadza, nie umiem go konfigurować, ale zgłębię temat ;) bo myślałem że nie bardzo jest co w nim robić, dlatego taki surowy jest :)
Co do kerneli, mam drugi "w razie czego" "lts" dograny i bootloader bez problemu go ładuje.
Czyli co? Olać te snapy i nie zawracać sobie nimi głowy? A jak się posypie to wtedy będziemy myśleć?
Cytat: pavbaranov w Lipiec 10, 2025, 10:01:01 AMChwila, bo nie bardzo rozumiem. SystemD nie jest bootloaderem. Bootloaderem o podobnej nazwie jest systemd-boot, który można dość łatwo konfigurować (niestety z "palca"). Jak się domyślam tu masz gdzieś problem (w konfiguracji systemd-boot), ale nie wiem jaki i nie będę wiedział, dopóki nie napiszesz w czym konkretnie problem leży.
Problem leży w "nie umieniu lub nie znaniu" komend na przywrócenie snapa. Chciałem tylko dla świętego spokoju...
Cytat: Accura w Lipiec 10, 2025, 11:10:36 AMTak, chodzi o systemd-boot, taki jest domyślny w Cachy, ale mi pasuje, nie przeszkadza, nie umiem go konfigurować, ale zgłębię temat ;) bo myślałem że nie bardzo jest co w nim robić, dlatego taki surowy jest :)
Co do kerneli, mam drugi "w razie czego" "lts" dograny i bootloader bez problemu go ładuje.
Czyli co? Olać te snapy i nie zawracać sobie nimi głowy? A jak się posypie to wtedy będziemy myśleć?
Systemd-boot jest jak najbardziej konfigurowalny. Jeśli pamiętam (w tym momencie nie siedzę na Kaczce), to w CachyOS jest jakieś narzędzie do jego konfiguracji.
Zawsze pozostaje też konfiguracja z palca.
Tutaj oraz
tutaj masz garść informacji jak to robić.
Jeśli chodzi o drugą kwestię. Jeden jedyny bodaj raz musiałem sięgnąć po chroota w Archu i cały błąd, który mnie do tego zmusił, był wywołany przeze mnie. Oba komputery mają konfigurację, która jest raczej bezproblemowa dla linuksa (zwłaszcza dla nowszych, aktualnych systemów). Ryzyko, że coś pójdzie w sposób uniemożliwiający zalogowanie się choćby do konsoli jest w zasadzie zależne wyłącznie od Ciebie. Jeśli coś bez sensu, bez zrozumienia, pomachasz w systemie - tak może nie wstać. Inaczej ryzyko sprowadza się (przynajmniej z mojego doświadczenia) do zera. Zrób kiedyś z live chroot systemu (cachyos-chroot bodaj to się nazywa w przypadku instalki CachyOS). Tak dla sportu, by wiedzieć jak się w tym poruszać. Ostatecznie masz 2 komputery - zawsze wiki poprowadzi Cię bez problemu.
Zatem - tak, z mojego punktu widzenia, te wszystkie snapy nie są mi potrzebne. Ani razu nie byłem zmuszony do sięgnięcia po nie. Zainstaluj sobie
pak i rób instalacje/akutalizacje tym narzędziem. Zmniejszysz praktycznie do zera ryzyko częściowej aktualizacji systemu. Mniej więcej raz na miesiąc (lub jak się pojawią nowe pliki mirrorlist) wykonaj aktualizację mirrorów i używaj systemu spokojnie. Odpłaci Ci się Twoim spokojem.
Dziękuje serdecznie za wyczerpujące odpowiedzi.
W takim razie wywalam te snapy i przyjrzę się linkom, które podałeś.
Jedyne w sumie co może mi namieszać to firmowe sprawy, typu cisco, które musze mieć i użam jak dotąd bez problemu, ale zależności które wymaga mogą mieć później problemy, a tak poza tym to wszystko hula jak trzeba :)
Dziękuję jeszcze raz serdecznie.
Widzisz, "sprawy typu cisco" to kwestia aplikacji. Nie widzę żadnej pod taką nazwą w repozytoriach, a zatem pewnie to AUR, albo jeszcze co innego. Niestety AUR to już kwestia kompletnie niezwiązana z repozytoriami. Tu musisz dbać o apkę samemu. Jeśli po aktualizacji się sypnie, to być może trzeba zrobić jakiś rebuild, czy aktualizację (pak - jeśli dostępna jest w AUR nowa wersja, to Ci to pokaże). Ogólnie z aplikacjami tego typu niekiedy w istocie może być problem w dystrybucjach typu rolling. Jeśli tak Ci się zdarza, to może - o ile jest dostępne - skorzystać z jakiegoś np. flatpaka, albo nawet samemu zbudować appimage. W takim przypadku niezależnie od aktualizacji systemu, sama apka winna nadal działać. Trzymanie natomiast starego Archa (tj. bez aktualizacji) ze względu na jakąś apkę, która się kłóci z nowszą wersją może w przyszłości (gdy się już na aktualizację systemu zdecydujesz) prowadzić w istocie do większych problemów, bo w systemie zajdą takie zmiany, że nie tak prosto będzie ją przeprowadzić. Cóż - taki urok rolling release.
Cytat: pavbaranov w Lipiec 10, 2025, 12:25:29 PMMniej więcej raz na miesiąc (lub jak się pojawią nowe pliki mirrorlist) wykonaj aktualizację mirrorów i używaj systemu spokojnie. Odpłaci Ci się Twoim spokojem.
Tak dopytam jeszcze, wszak pro userem nie jestem... Czy aktualizację mirrorów zrobię z pak jakąś komendą, czy muszę ręcznie dodawać?
Gdzie szukać info o aktualizacji mirrorlist?
Pak ma manual, gdzie wszystko jest - w miarę dobrze rozpisane. Aktualizacja mirrorów w pak to:
pak -mPotem zatwierdzasz.
Przy czym pak aktualizuje wyłącznie mirrory dla Archa.
CachyOS dla własnych mirrorów ma skrypt:
sudo cachyos-rate-mirrorsOczywiście można to robić również ręcznie, bo paczki *-mirrorlist regularnie się pojawiają w systemie, tyle, że wchodzą najczęściej jako *.pacnew. Wówczas możesz skorzystać z obu poleceń. Powinny przynieść ten sam rezultat, co ręczna podmiana plików i ich właściwe uruchomienie (paczka mirrorlist.pacnew nie jest "aktywna" i po jej przekopiowaniu na mirrorlist musisz jeszcze usunąć # przed tymi serwerami, których chcesz używać. Polecenie paka jest wygodniejsze (korzysta z reflector, zatem narzędzia archowego).
Dziękuję serdecznie za pomoc w tym temacie. Można zaznaczyć, że rozwiązano bo, zastosuję się do porad kolegi pavbaranov.
Jeśli kiedyś temat powróci i/lub coś z tematem namieszam, zwrócę się o pomoc :)
Tak przy okazji - w Kaczce jest programik do zarządzania snapami w btrfs (zob.:
https://github.com/CachyOS/CachyOS-PKGBUILDS/tree/master/cachyos-snapper-support).
Tak, to dzięki niemu konfiguracja jest szybka i bezproblemowa. Można zarządzać snapami w Btrfs Assistant.
Mnie chodziło o to, że jak się coś sypnie, to odpalam kompa->klepie jakiąś komendę/y->wybieram który numer snapa->uruchamiam ponownie->System działa jak przed zmianą gdy się sypnął. :) Tyle.
Przy okazji mam pytanie odnośnie pak. Przedwczoraj klepnąłem sobie aktualizacje pak -Su i był kernel do aktualizacji. No i zgodziłem się, zaczął mielić. Tyle tylko że trwało to ze dwie godziny :) na drugim kompie aktualizacja taki sam kernel z pacman -Su i trwało to 5 minut. W czym rzecz???
Sprawdzaj co robi pak :) Na 99,99% zrobiłeś kompilację kernela z AUR. Kernele z Kaczki są udostępniane w AUR jeszcze, gdy są testowane.
Pak instaluje w kolejności:
1. repozytoria
2. AUR
3. POLAUR (tego na razie nie używaj; dopiero się tym zajmę - może jesienią).
Wypisuje z czego chce instalować.
Ostatni kernel w repo Kaczki to 6.15.6-2 (przynajmniej jeśli chodzi o cachyos, ale inne będą podobnie z wyjątkiem LTS). W tej chwili w AUR jest wcześniejsza wersja, ale w istocie wczoraj, czy przedwczoraj pojawiła mi się możliwość aktualizacji kernela, ale z AUR, a nie z repo. Uruchom sobie sprawdzanie akutalizacji przez pak z repo i z AUR (info w helpie pak). Dostaniesz czytelną informację jakie są dostępne aktualizacje i z czego.
Oczywiście mogło się też zdarzyć tak, że aktualizując na tym komputerze, gdzie trwało to bardzo długo, z jakiegoś powodu spadła Ci transmisja danych. Też mi się to kiedyś zdarzyło.
No wychodzi na to, że kompilacja się odbywała. Dzisiaj natomiast miałem to samo z wine, też pokazał aktualizacje, no i też się kompilowało, ale nie wzbudziło we mnie wcześniej podejrzeń, bo wyglądała jak zwyczajna aktualizacja :)
Musze się bardziej przyglądać :)
Pozdrawiam i dziękuję za czas.
Po prostu trzeba bardziej patrzeć na to co pak robi.
Uruchom:
[color=#000000]systemctl --user enable --now pak-checkupdates.timer[/color]
[color=#000000]systemctl --user enable --now pak-auracle.timer[/color]Będziesz widział co jest do instalacji z repo, a co z AUR.
Pak został tak skonstruowany - celowo - że domyślnie ma aktualizować wszystko, co jest do aktualizacji, albowiem jego użycie ma powodować, że system będzie działać, że każda apka zainstalowana w systemie będzie działać.
Przy aktualizacji podaje Ci m.in.:
[color=#5454ff][b]::[/b][/color] [color=#000000][b]Uruchamianie aktualizacji z AUR[/b]...[/color]
Możesz to pominąć, jeśli wiesz co robisz.
Jeśli chcesz instalować/aktualizować system wyłącznie z repo, to wybierz:
sudo pacman -SyuNa pewno wówczas nie będzie Ci niczego kompilować z AUR.
Cytat: pavbaranov w Lipiec 13, 2025, 12:27:42 PMSprawdzaj co robi pak :) Na 99,99% zrobiłeś kompilację kernela z AUR. Kernele z Kaczki są udostępniane w AUR jeszcze, gdy są testowane.
Pak instaluje w kolejności:
1. repozytoria
2. AUR
3. POLAUR (tego na razie nie używaj; dopiero się tym zajmę - może jesienią).
Wypisuje z czego chce instalować.
Skorzystam jeszcze z Twojej dobroci...
Czy w tej sytuacji jest jak mówisz? Wykonałem komendę "pak -C"
:: System
Sprawdzanie...
nie ma nic do zrobienia
:: AUR
Sprawdzanie...
nie ma nic do zrobienia
:: POLAUR
Sprawdzanie...
Pakiety do aktualizacji:
new-branded/pak-git 1:5.6.3.r0.gdec6932-1 => 1:5.7.r1.g9ed046f-1
Mam jeszcze takie coś:
:: Niezscalone pliki pacnew/pacsave
/etc/pacman.d/cachyos-mirrorlist.pacnew
/etc/pacman.d/cachyos-v3-mirrorlist.pacnew
/etc/pacman.d/cachyos-v4-mirrorlist.pacnew
/etc/resolv.conf.pacnew
/etc/pacman.d/mirrorlist.pacnew
no i mimo zainstalowania auracle-git takie coś:
:: Lista zainstalowanych pakietów VCS
Sprawdzanie...
auracle-git r429.8253272
błąd: Nie można wyszukać aktualizacji. Nie znaleziono PKGBUILD dla pakietu w: /home/marcin/.cache/pak/pkgs/auracle-git/
Bardzo ciekawi mnie ten pak, nawet wyłączyłem octopi i dodałem sobie wpisy by mnie powiadamiał pak o aktualizacjach.
Kilka wyjaśnień potrzebuję, aby komfortowo go używać i pragnę by mój system zawsze działał jak należy.
Cytat: pavbaranov w Lipiec 13, 2025, 12:27:42 PMUruchom sobie sprawdzanie akutalizacji przez pak z repo i z AUR (info w helpie pak).
Nie umiem/nie potrafię znaleźć? Rozumiem, że wtedy będzie sprawdzał tylko repo i aur? Czy wtedy będzie mniejsza szansa na "kompilację", gdy nie doczytam? :)
Sorry że tak dopytuję, ale kto pyta nie błądzi...
Najlepiej wątek - od pewnego czasu - przenieść do nowego o pak (tu uśmiech do Pawła).
Od końca - sprawdzanie, to właśnie te usługi systemctl. Uruchomiłeś. One po prostu informują czy i co jest do aktualizacji i z czego.
Z auracle-git - osobiście mam udostępnione repo chaotic-aur i nie bawię się w kompilacje. Po prostu instaluje mi się nowa wersja. W Twoim przypadku wygląda tak, jakbyś nie instalował tej paczki z pomocą pak.
Paczki pacnew - dobrze to opisane w wiki Archa. Wszelkie tego typu plik są instalowane w systemie, ale nie nadpisują się na zainstalowanych. Jeśli użytkownik chce - może to wykonać ręcznie, zmieniając nazwy itd. itp., a w pliku (dotychczasowym *.pacnew dodatkowo usuwając # przed tymi mirrorami, których chcesz używać). Użyć możesz również reflektor, albo... pak, by to zmienił (jest w opisie).
Z pak-git z POLAUR nie bardzo rozumiem o co mu chodzi, ale z paczkami *-git tak już jest, że one numer wersji dostają po zbudowaniu. Nie wiem skąd ściągnąłeś tego pak, ale ja mam wersję 1.5.7-1 (akurat przez przypadek nie korzystam z *-git). Możesz sobie spokojnie puścić aktualizację pak-git do najnowszej wersji. Trwa to sekundy.
Więc tak:
Rzeczy, które chciałem osiągnąć, czyli:
Szybkie przywrócenie systemu do życia z kopii, w razie rozwalenia czegoś, czy to z mojej winy czy też nie,
nie da się w moim przypadku osiągnąć w migawkach systemowych na systemie BTRFS :)
Rozwiązaniem jest Timeshift i system plików EXT4 - działa wyśmienicie :)
Temat można oznaczyć jako rozwiązany.