Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
przesuwanie, rozszerzanie, łączenie partycji
71 views
Skip to first unread message
Roman Tyczka
Jul 3, 2022, 5:33:44 AM7/3/22
to
Witam,
Dysk systemowy wygląda tak:
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Typ etykiety dysku: gpt
Identyfikator dysku: 80451809-FD8C-40EA-85F3-81B2192676A3
Urządzenie Początek Koniec Sektory Rozmiar Typ
/dev/nvme0n1p1 2048 94207 92160 45M System EFI
/dev/nvme0n1p2 94208 390719487 390625280 186,3G Linux - system plików
/dev/nvme0n1p3 390719488 781344767 390625280 186,3G Linux - system plików
/dev/nvme0n1p4 781344768 1953523711 1172178944 558,9G Linux - system plików
czyli 4 partycje (z czego 2 i 3 identyczne rozmiarem):
- p1 - EFI
- p2 - niewykorzystana - 186GB
- p3 - /, root - 186GB
- p4 - /home 558GB
Chciałbym pozostawić 3 partycje, a partycja p2, niewykorzystana, żeby
była połączona z p4 (/home). Chcę to osiągnąć w ten sposób, że za pomocą
dd skopiuję partycję p3 (/) na p2 (tę niewykorzystaną), a potem p3 usunę
i jej przestrzeń połączę z p4.
Ale jako, że to mój główny komp, a operacja jest nietrywialna to się
obawiam, że coś pójdzie nie tak i będzie zonk. Dlatego pytam czy to
dobry pomysł, czy może inaczej to zrobić?
Partycję / czyli p3, mam podpiętą w fstab przez PARTUUID:
PARTUUID=8c5543f5-5888-4fae-a989-de60928c061e /
ext4 errors=remount-ro 0 1
Czy po skopiowaniu partycji p3 na p2 wystarczy zmiana w fstab samego
UUID partycji i system normalnie wstanie?
Jak połączyć bez utraty danych partycje p3 (a w zasadzie wolne miejsce
po niej) i p4, gdzie p4 to obecnie /home? Da się? W dawnych czasach w
windows takie rzeczy managerami partycji robiłem i się powodziły, w
Linuksie nie wiem czy tak się uda.
--
pzdr
Roman
Dysk systemowy wygląda tak:
Jednostki: sektorów, czyli 1 * 512 = 512 bajtów
Rozmiar sektora (logiczny/fizyczny) w bajtach: 512 / 512
Rozmiar we/wy (minimalny/optymalny) w bajtach: 512 / 512
Typ etykiety dysku: gpt
Identyfikator dysku: 80451809-FD8C-40EA-85F3-81B2192676A3
Urządzenie Początek Koniec Sektory Rozmiar Typ
/dev/nvme0n1p1 2048 94207 92160 45M System EFI
/dev/nvme0n1p2 94208 390719487 390625280 186,3G Linux - system plików
/dev/nvme0n1p3 390719488 781344767 390625280 186,3G Linux - system plików
/dev/nvme0n1p4 781344768 1953523711 1172178944 558,9G Linux - system plików
czyli 4 partycje (z czego 2 i 3 identyczne rozmiarem):
- p1 - EFI
- p2 - niewykorzystana - 186GB
- p3 - /, root - 186GB
- p4 - /home 558GB
Chciałbym pozostawić 3 partycje, a partycja p2, niewykorzystana, żeby
była połączona z p4 (/home). Chcę to osiągnąć w ten sposób, że za pomocą
dd skopiuję partycję p3 (/) na p2 (tę niewykorzystaną), a potem p3 usunę
i jej przestrzeń połączę z p4.
Ale jako, że to mój główny komp, a operacja jest nietrywialna to się
obawiam, że coś pójdzie nie tak i będzie zonk. Dlatego pytam czy to
dobry pomysł, czy może inaczej to zrobić?
Partycję / czyli p3, mam podpiętą w fstab przez PARTUUID:
PARTUUID=8c5543f5-5888-4fae-a989-de60928c061e /
ext4 errors=remount-ro 0 1
Czy po skopiowaniu partycji p3 na p2 wystarczy zmiana w fstab samego
UUID partycji i system normalnie wstanie?
Jak połączyć bez utraty danych partycje p3 (a w zasadzie wolne miejsce
po niej) i p4, gdzie p4 to obecnie /home? Da się? W dawnych czasach w
windows takie rzeczy managerami partycji robiłem i się powodziły, w
Linuksie nie wiem czy tak się uda.
--
pzdr
Roman
Roman Tyczka
Jul 3, 2022, 7:14:59 AM7/3/22
to
na p2, ustawiłem w fstab partycji p2 nowe PARTUUID dla /, dodatkowo w
pliku /boot/efi/EFI/ubuntu/grub.cfg zmieniłem UUID w poleceniu:
search.fs_uuid 368bd0f9-b430-41ca-a4ff-122da2e38db0 root
i liczyłem, że wystartuje z nowej partycji, a tu dupa. Startuje z
poprzedniej, p3.
Co zrobiłem źle lub czego nie zrobiłem?
--
pzdr
Roman
Jacek Marcin Jaworski
Jul 3, 2022, 8:40:31 AM7/3/22
to
> Jak połączyć bez utraty danych partycje p3 (a w zasadzie wolne miejsce
> po niej) i p4, gdzie p4 to obecnie /home? Da się? W dawnych czasach w
> windows takie rzeczy managerami partycji robiłem i się powodziły, w
> Linuksie nie wiem czy tak się uda.
Jeśli w grę wchodzi przesuwanie danych to szkoda czasu. Bo się nie doczekasz. Już lepiej skopiować dane. Wywalić wszystko i utworzyć nowe partycje i skopiować z powrotem.
> po niej) i p4, gdzie p4 to obecnie /home? Da się? W dawnych czasach w
> windows takie rzeczy managerami partycji robiłem i się powodziły, w
> Linuksie nie wiem czy tak się uda.
Jeśli nie trzeba przesuwać danych, to samo łączenie partycji powinno być bezproblemowe.
Przed zabawą gparted i kparted kopia zapasowa jest obowiązkowa. Tak samo jak okresowa kopia zapasowa.
Roman Tyczka
Jul 4, 2022, 1:54:23 AM7/4/22
to
On 03.07.2022 13:14, Roman Tyczka wrote:
> No to odpaliłem kompa z pendrive, z fedorą live. Skopiowałem partycję p3
> na p2, ustawiłem w fstab partycji p2 nowe PARTUUID dla /, dodatkowo w
> pliku /boot/efi/EFI/ubuntu/grub.cfg zmieniłem UUID w poleceniu:
>
> search.fs_uuid 368bd0f9-b430-41ca-a4ff-122da2e38db0 root
>
> i liczyłem, że wystartuje z nowej partycji, a tu dupa. Startuje z
> poprzedniej, p3.
> Co zrobiłem źle lub czego nie zrobiłem?
Na dalszym etapie nauki (czyt. rzeźby) dowiedziałem się, że katalog
> No to odpaliłem kompa z pendrive, z fedorą live. Skopiowałem partycję p3
> na p2, ustawiłem w fstab partycji p2 nowe PARTUUID dla /, dodatkowo w
> pliku /boot/efi/EFI/ubuntu/grub.cfg zmieniłem UUID w poleceniu:
>
> search.fs_uuid 368bd0f9-b430-41ca-a4ff-122da2e38db0 root
>
> i liczyłem, że wystartuje z nowej partycji, a tu dupa. Startuje z
> poprzedniej, p3.
> Co zrobiłem źle lub czego nie zrobiłem?
/boot jest złożony zarówno z partycji EFI jak i danych partycji
systemowej, a zmiany które zrobiłem były niewystarczające i należało
jeszcze wprowadzić zmiany w pliku:
/boot/grub/grub.cfg
który zawiera wielki skrypt. W tym skrypcie był zahardcodowany PARTUUID
poprzedniej partycji systemowej i jego zmiana na nowy UUID spowodował w
końcu start z tej partycji co trzeba.
To co mnie obecnie zastanawia to fakt, że w tym pliku w nagłówku jest
informacja o tym, że jest on tworzony automatycznie przez narzędzie
grub-mkconfig. Ale jak się domyślam, narzędzie to należy wystartować z
systemu, którego partycję chcemy tym automatem wsadzić do skryptu
grub.cfg, a skoro zmieniam partycję i nie potrafię właśnie odpalić
systemu z tej partycji, bo zawartość pliku grub.cfg wskazuje poprzednią
partycję to co wtedy? Błędne koło. Zatem ręczne zmiany pomogły, ale jak
to się powinno poprawnie przeprowadzać?
--
pzdr
Roman
Dominik Ałaszewski
Jul 4, 2022, 3:21:51 AM7/4/22
to
Dnia 04.07.2022 Roman Tyczka <roman...@hate.you.spammer> napisał/a:
> grub.cfg, a skoro zmieniam partycję i nie potrafię właśnie odpalić
> systemu z tej partycji, bo zawartość pliku grub.cfg wskazuje poprzednią
> partycję to co wtedy? Błędne koło. Zatem ręczne zmiany pomogły, ale jak
Pewnie starczy wykonać chroot na tę partycję, gdzie docelowo ma być root.
> grub.cfg, a skoro zmieniam partycję i nie potrafię właśnie odpalić
> systemu z tej partycji, bo zawartość pliku grub.cfg wskazuje poprzednią
> partycję to co wtedy? Błędne koło. Zatem ręczne zmiany pomogły, ale jak
> to się powinno poprawnie przeprowadzać?
problemy nie mają szansy zaistnieć ;-)
--
Dominik Ałaszewski (via raspbianowy slrn)
"W życiu piękne są tylko chwile…" (Ryszard Riedel)
Wyrażam wyłącznie prywatne poglądy zgodnie z Art. 54 Konstytucji RP
Pisząc na priv zmień domenę na gmail.
Krzysztof Gajdemski
Jul 4, 2022, 3:47:11 AM7/4/22
to
Jest Mon, 4 Jul 2022 07:54:21 +0200, Roman Tyczka pisze:
wygląda, że robisz tę akcję na Ubuntu. W Debianach, Ubuntu etc.,
konfigurację gruba uaktualniamy poleceniem update-grub. W żadnym razie
nie edytujemy konfiguracji ręcznie.
> Ale jak się domyślam, narzędzie to należy wystartować z
> systemu, którego partycję chcemy tym automatem wsadzić do skryptu
> grub.cfg, a skoro zmieniam partycję i nie potrafię właśnie odpalić
> systemu z tej partycji, bo zawartość pliku grub.cfg wskazuje poprzednią
> partycję to co wtedy? Błędne koło.
Tak, update-grub musi być wykonany z „wnętrza” systemu. Masz dwie opcje:
1. Odpalasz jakieś narzędzie typu rescue (ja używałem kiedyś Debian
rescue) i tam powinna być możliwość automatycznego wykonania chroot
do systemu. Technikalia zostaną zrobione za użytkownika. Wtedy
wykonujesz po prostu update-grub i po sprawie.
2. W dystrybucji live/rescue montujesz gdzieś / z leczonym systemem
i wykonujesz tam chroot. Jednak w środku potrzebny jest co najmniej /dev
i /proc (a często także /sys, /dev/pts …). Więc przed chroot
montujesz to, co będzie potem potrzebne:
# mount --bind /proc /mnt/mojchroot/proc
# mount --bind /dev /mnt/mojchrot/dev
I tak dalej. Robisz chroot i tam już update-grub.
k.
--
Krzysztof Gajdemski | songo (at) debian.org.pl | KG4751-RIPE
Registered Linux User #133457 | BLUG Registered Member #0005
PGP key at: http://s.debian.org.pl/gpg/gpgkey * ID: D3259224
Szanuję was wszystkich, którzy pozostajecie w cieniu - Snerg
> On 03.07.2022 13:14, Roman Tyczka wrote:
>> No to odpaliłem kompa z pendrive, z fedorą live. Skopiowałem partycję p3
>> na p2, ustawiłem w fstab partycji p2 nowe PARTUUID dla /, dodatkowo w
>> pliku /boot/efi/EFI/ubuntu/grub.cfg zmieniłem UUID w poleceniu:
^^^^^^^^^^^^^^^^^^^^^
>> No to odpaliłem kompa z pendrive, z fedorą live. Skopiowałem partycję p3
>> na p2, ustawiłem w fstab partycji p2 nowe PARTUUID dla /, dodatkowo w
>> pliku /boot/efi/EFI/ubuntu/grub.cfg zmieniłem UUID w poleceniu:
>> search.fs_uuid 368bd0f9-b430-41ca-a4ff-122da2e38db0 root
>> i liczyłem, że wystartuje z nowej partycji, a tu dupa. Startuje z
>> poprzedniej, p3.
>> Co zrobiłem źle lub czego nie zrobiłem?
> Na dalszym etapie nauki (czyt. rzeźby) dowiedziałem się, że katalog
> /boot jest złożony zarówno z partycji EFI jak i danych partycji
> systemowej, a zmiany które zrobiłem były niewystarczające i należało
> jeszcze wprowadzić zmiany w pliku:
>> i liczyłem, że wystartuje z nowej partycji, a tu dupa. Startuje z
>> poprzedniej, p3.
>> Co zrobiłem źle lub czego nie zrobiłem?
> Na dalszym etapie nauki (czyt. rzeźby) dowiedziałem się, że katalog
> /boot jest złożony zarówno z partycji EFI jak i danych partycji
> systemowej, a zmiany które zrobiłem były niewystarczające i należało
> jeszcze wprowadzić zmiany w pliku:
> To co mnie obecnie zastanawia to fakt, że w tym pliku w nagłówku jest
> informacja o tym, że jest on tworzony automatycznie przez narzędzie
> grub-mkconfig.
Przepraszam jeśli coś umknęło, bo nie czytałem całego wątku, ale
> informacja o tym, że jest on tworzony automatycznie przez narzędzie
> grub-mkconfig.
wygląda, że robisz tę akcję na Ubuntu. W Debianach, Ubuntu etc.,
konfigurację gruba uaktualniamy poleceniem update-grub. W żadnym razie
nie edytujemy konfiguracji ręcznie.
> Ale jak się domyślam, narzędzie to należy wystartować z
> systemu, którego partycję chcemy tym automatem wsadzić do skryptu
> grub.cfg, a skoro zmieniam partycję i nie potrafię właśnie odpalić
> systemu z tej partycji, bo zawartość pliku grub.cfg wskazuje poprzednią
> partycję to co wtedy? Błędne koło.
1. Odpalasz jakieś narzędzie typu rescue (ja używałem kiedyś Debian
rescue) i tam powinna być możliwość automatycznego wykonania chroot
do systemu. Technikalia zostaną zrobione za użytkownika. Wtedy
wykonujesz po prostu update-grub i po sprawie.
2. W dystrybucji live/rescue montujesz gdzieś / z leczonym systemem
i wykonujesz tam chroot. Jednak w środku potrzebny jest co najmniej /dev
i /proc (a często także /sys, /dev/pts …). Więc przed chroot
montujesz to, co będzie potem potrzebne:
# mount --bind /proc /mnt/mojchroot/proc
# mount --bind /dev /mnt/mojchrot/dev
I tak dalej. Robisz chroot i tam już update-grub.
k.
--
Krzysztof Gajdemski | songo (at) debian.org.pl | KG4751-RIPE
Registered Linux User #133457 | BLUG Registered Member #0005
PGP key at: http://s.debian.org.pl/gpg/gpgkey * ID: D3259224
Szanuję was wszystkich, którzy pozostajecie w cieniu - Snerg
Krzysztof Gajdemski
Jul 4, 2022, 3:51:55 AM7/4/22
to
Jest 04 Jul 2022 07:21:16 GMT, Dominik Ałaszewski pisze:
wspomniałem w innym poście, trzeba sobie najpierw to podmontować.
>> to się powinno poprawnie przeprowadzać?
> A poprawnie to należy używać LVM. Wtedy po prostu tego typu
> problemy nie mają szansy zaistnieć ;-)
Zgadza się. Inna sprawa, że nie zawsze można.
> Dnia 04.07.2022 Roman Tyczka <roman...@hate.you.spammer> napisał/a:
>> grub.cfg, a skoro zmieniam partycję i nie potrafię właśnie odpalić
>> systemu z tej partycji, bo zawartość pliku grub.cfg wskazuje poprzednią
>> partycję to co wtedy? Błędne koło. Zatem ręczne zmiany pomogły, ale jak
> Pewnie starczy wykonać chroot na tę partycję, gdzie docelowo ma być root.
Nie wystarczy. W chroot potrzebny jest /proc, /dev, /sys… Jak
>> grub.cfg, a skoro zmieniam partycję i nie potrafię właśnie odpalić
>> systemu z tej partycji, bo zawartość pliku grub.cfg wskazuje poprzednią
>> partycję to co wtedy? Błędne koło. Zatem ręczne zmiany pomogły, ale jak
> Pewnie starczy wykonać chroot na tę partycję, gdzie docelowo ma być root.
wspomniałem w innym poście, trzeba sobie najpierw to podmontować.
>> to się powinno poprawnie przeprowadzać?
> A poprawnie to należy używać LVM. Wtedy po prostu tego typu
> problemy nie mają szansy zaistnieć ;-)
Dominik Ałaszewski
Jul 4, 2022, 4:18:33 AM7/4/22
to
Dnia 04.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
> Nie wystarczy. W chroot potrzebny jest /proc, /dev, /sys… Jak
> wspomniałem w innym poście, trzeba sobie najpierw to podmontować.
Dzięki za uzupełnienie. Robiłem coś takiego dawno i pewnie mi
> Nie wystarczy. W chroot potrzebny jest /proc, /dev, /sys… Jak
> wspomniałem w innym poście, trzeba sobie najpierw to podmontować.
się zapomniało.
Marcin Debowski
Jul 4, 2022, 6:43:45 AM7/4/22
to
On 2022-07-04, Dominik Ałaszewski <Dominik.A...@gazeta.pl.invalid> wrote:
> Dnia 04.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
>
>> Nie wystarczy. W chroot potrzebny jest /proc, /dev, /sys… Jak
>> wspomniałem w innym poście, trzeba sobie najpierw to podmontować.
>
> Dzięki za uzupełnienie. Robiłem coś takiego dawno i pewnie mi
> się zapomniało.
No właśnie... od dłuższego czasu robię to z podmotowywaniem, ale robię
> Dnia 04.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
>
>> Nie wystarczy. W chroot potrzebny jest /proc, /dev, /sys… Jak
>> wspomniałem w innym poście, trzeba sobie najpierw to podmontować.
>
> Dzięki za uzupełnienie. Robiłem coś takiego dawno i pewnie mi
> się zapomniało.
to bo zwykle updatuje gruba spod jakiejś wersji "live", która jest różna
od tego co się znajduje na tej chrootowanej. Natomiast wyraźnie
pamiętam, jeśli taka operacja dotyczyła praktycznie identycznej kopii
systemu to nie trzeba było podmontowywać, tzn. grub radził sobie bez
tego. Ale też ostatni raz robiłem to z 10 lat temu, więc coś mogło się
zmienić.
--
Marcin
Roman Tyczka
Jul 4, 2022, 9:11:19 AM7/4/22
to
On 04.07.2022 09:47, Krzysztof Gajdemski wrote:
>> To co mnie obecnie zastanawia to fakt, że w tym pliku w nagłówku jest
>> informacja o tym, że jest on tworzony automatycznie przez narzędzie
>> grub-mkconfig.
>
> Przepraszam jeśli coś umknęło, bo nie czytałem całego wątku, ale
> wygląda, że robisz tę akcję na Ubuntu. W Debianach, Ubuntu etc.,
> konfigurację gruba uaktualniamy poleceniem update-grub. W żadnym razie
> nie edytujemy konfiguracji ręcznie.
Sprawdziłem to update-grub, wytwarza ten plik w formie bardzo podobnej
>> To co mnie obecnie zastanawia to fakt, że w tym pliku w nagłówku jest
>> informacja o tym, że jest on tworzony automatycznie przez narzędzie
>> grub-mkconfig.
>
> Przepraszam jeśli coś umknęło, bo nie czytałem całego wątku, ale
> wygląda, że robisz tę akcję na Ubuntu. W Debianach, Ubuntu etc.,
> konfigurację gruba uaktualniamy poleceniem update-grub. W żadnym razie
> nie edytujemy konfiguracji ręcznie.
do tego co mam. Ale przy okazji mam pytanie, w katalogu /boot mam pełno
plików:
System.map-5.xxxxxx-generic
config-5.xxxxxx-generic
initrd.img-5.xxxxxxx-generic
vmlimuz-5.xxxxxxx-generic
Każdy z powyższych plików jest w kilkunastu wersjach. Zgaduję, że to są
kernele po kolejnych aktualizacjach. W jaki sposób usunąć te zbędne i
zostawić po 2-3? Bo domyślam się, że ręcznie tego się nie powinno robić.
Jest jakieś narzędzie?
>> Ale jak się domyślam, narzędzie to należy wystartować z
>> systemu, którego partycję chcemy tym automatem wsadzić do skryptu
>> grub.cfg, a skoro zmieniam partycję i nie potrafię właśnie odpalić
>> systemu z tej partycji, bo zawartość pliku grub.cfg wskazuje poprzednią
>> partycję to co wtedy? Błędne koło.
>
> Tak, update-grub musi być wykonany z „wnętrza” systemu. Masz dwie opcje:
>
> 1. Odpalasz jakieś narzędzie typu rescue (ja używałem kiedyś Debian
> rescue) i tam powinna być możliwość automatycznego wykonania chroot
> do systemu. Technikalia zostaną zrobione za użytkownika. Wtedy
> wykonujesz po prostu update-grub i po sprawie.
miarę automatycznie i bez pola do pomyłek.
> 2. W dystrybucji live/rescue montujesz gdzieś / z leczonym systemem
> i wykonujesz tam chroot. Jednak w środku potrzebny jest co najmniej /dev
> i /proc (a często także /sys, /dev/pts …). Więc przed chroot
> montujesz to, co będzie potem potrzebne:
>
> # mount --bind /proc /mnt/mojchroot/proc
> # mount --bind /dev /mnt/mojchrot/dev
>
> I tak dalej. Robisz chroot i tam już update-grub.
skomplikowane i podatne na ludzkie błędy, więc nim nabędę biegłości wolę
unikać takich dzikich solucji :-)
Dzięki za informacje.
--
pzdr
Roman
Roman Tyczka
Jul 4, 2022, 9:20:28 AM7/4/22
to
On 04.07.2022 09:21, Dominik Ałaszewski wrote:
>> grub.cfg, a skoro zmieniam partycję i nie potrafię właśnie odpalić
>> systemu z tej partycji, bo zawartość pliku grub.cfg wskazuje poprzednią
>> partycję to co wtedy? Błędne koło. Zatem ręczne zmiany pomogły, ale jak
>
> Pewnie starczy wykonać chroot na tę partycję, gdzie docelowo ma być root.
>
>> to się powinno poprawnie przeprowadzać?
>
> A poprawnie to należy używać LVM. Wtedy po prostu tego typu
> problemy nie mają szansy zaistnieć ;-)
A możesz w trzech słowach opisać jak to się robi? I kiedy? Czy na etapie
>> grub.cfg, a skoro zmieniam partycję i nie potrafię właśnie odpalić
>> systemu z tej partycji, bo zawartość pliku grub.cfg wskazuje poprzednią
>> partycję to co wtedy? Błędne koło. Zatem ręczne zmiany pomogły, ale jak
>
> Pewnie starczy wykonać chroot na tę partycję, gdzie docelowo ma być root.
>
>> to się powinno poprawnie przeprowadzać?
>
> A poprawnie to należy używać LVM. Wtedy po prostu tego typu
> problemy nie mają szansy zaistnieć ;-)
instalacji systemu? Czy wszystkie partycje są wtedy "zwirtualizowane" na
jednej? A co z EFI?
A czy gotowy system da się teraz zmigrować?
--
pzdr
Roman
Dominik Ałaszewski
Jul 4, 2022, 10:05:36 AM7/4/22
to
Dnia 04.07.2022 Roman Tyczka <roman...@hate.you.spammer> napisał/a:
> A możesz w trzech słowach opisać jak to się robi? I kiedy? Czy na etapie
W trzech słowach? "Podczas instalacji systemu" :-)
Wtedy zwykle z ładnym graficznym międzymordziem użytkownika.
> instalacji systemu? Czy wszystkie partycje są wtedy "zwirtualizowane" na
> jednej? A co z EFI?
na dowolnym wolumenie fizycznym (partycji lub dysku).
Może być to jedno urządzenie, może być więcej.
UEFI system partition raczej musi pozostać partycją, ale tu
trzeba pytać mądrzejszych ode mnie.
> A czy gotowy system da się teraz zmigrować?
przez kopię plikową, np. rscyncem.
Krzysztof Gajdemski
Jul 4, 2022, 10:48:51 AM7/4/22
to
Jest Mon, 4 Jul 2022 15:11:15 +0200, Roman Tyczka pisze:
z kolei generuje grub.cfg na podstawie konfiguracji systemu. Pewnie
zmieniło się tylko to, co dopisałeś ręcznie.
> Ale przy okazji mam pytanie, w katalogu /boot mam pełno
> plików:
> System.map-5.xxxxxx-generic
> config-5.xxxxxx-generic
> initrd.img-5.xxxxxxx-generic
> vmlimuz-5.xxxxxxx-generic
> Każdy z powyższych plików jest w kilkunastu wersjach. Zgaduję, że to są
> kernele po kolejnych aktualizacjach. W jaki sposób usunąć te zbędne i
> zostawić po 2-3? Bo domyślam się, że ręcznie tego się nie powinno robić.
> Jest jakieś narzędzie?
Owszem, trzeba zrobić purge'a niepotrzebnych pakietów z jądrem,
np. apt purge linux-image-5.xxxxxx-generic.
> On 04.07.2022 09:47, Krzysztof Gajdemski wrote:
>>> To co mnie obecnie zastanawia to fakt, że w tym pliku w nagłówku jest
>>> informacja o tym, że jest on tworzony automatycznie przez narzędzie
>>> grub-mkconfig.
>>
>> Przepraszam jeśli coś umknęło, bo nie czytałem całego wątku, ale
>> wygląda, że robisz tę akcję na Ubuntu. W Debianach, Ubuntu etc.,
>> konfigurację gruba uaktualniamy poleceniem update-grub. W żadnym razie
>> nie edytujemy konfiguracji ręcznie.
> Sprawdziłem to update-grub, wytwarza ten plik w formie bardzo podobnej
> do tego co mam.
Tak, bo update-grub, to w zasadzie wrapper na grub-mkconfig, który
>>> To co mnie obecnie zastanawia to fakt, że w tym pliku w nagłówku jest
>>> informacja o tym, że jest on tworzony automatycznie przez narzędzie
>>> grub-mkconfig.
>>
>> Przepraszam jeśli coś umknęło, bo nie czytałem całego wątku, ale
>> wygląda, że robisz tę akcję na Ubuntu. W Debianach, Ubuntu etc.,
>> konfigurację gruba uaktualniamy poleceniem update-grub. W żadnym razie
>> nie edytujemy konfiguracji ręcznie.
> Sprawdziłem to update-grub, wytwarza ten plik w formie bardzo podobnej
> do tego co mam.
z kolei generuje grub.cfg na podstawie konfiguracji systemu. Pewnie
zmieniło się tylko to, co dopisałeś ręcznie.
> Ale przy okazji mam pytanie, w katalogu /boot mam pełno
> plików:
> System.map-5.xxxxxx-generic
> config-5.xxxxxx-generic
> initrd.img-5.xxxxxxx-generic
> vmlimuz-5.xxxxxxx-generic
> Każdy z powyższych plików jest w kilkunastu wersjach. Zgaduję, że to są
> kernele po kolejnych aktualizacjach. W jaki sposób usunąć te zbędne i
> zostawić po 2-3? Bo domyślam się, że ręcznie tego się nie powinno robić.
> Jest jakieś narzędzie?
np. apt purge linux-image-5.xxxxxx-generic.
Dominik Ałaszewski
Jul 5, 2022, 2:01:54 AM7/5/22
to
>> kernele po kolejnych aktualizacjach. W jaki sposób usunąć te zbędne i
>> zostawić po 2-3? Bo domyślam się, że ręcznie tego się nie powinno robić.
>> Jest jakieś narzędzie?
>
> Owszem, trzeba zrobić purge'a niepotrzebnych pakietów z jądrem,
> np. apt purge linux-image-5.xxxxxx-generic.
W Ubunciaku system tego nie ogarnia? W Busterze mam takie cosie:
>> zostawić po 2-3? Bo domyślam się, że ręcznie tego się nie powinno robić.
>> Jest jakieś narzędzie?
>
> Owszem, trzeba zrobić purge'a niepotrzebnych pakietów z jądrem,
> np. apt purge linux-image-5.xxxxxx-generic.
root@morpheus:~# head -1 /etc/apt/apt.conf.d/01autoremove-kernels
// DO NOT EDIT! File autogenerated by /etc/kernel/postinst.d/apt-auto-removal
root@morpheus:/# head -13 /etc/kernel/postinst.d/apt-auto-removal
#!/bin/sh
set -e
# Mark as not-for-autoremoval those kernel packages that are:
# - the currently booted version
# - the kernel version we've been called for
# - the latest kernel version (as determined by debian version number)
# - the second-latest kernel version
#
# In the common case this results in two kernels saved (booted into the
# second-latest kernel, we install the latest kernel in an upgrade), but
# can save up to four. Kernel refers here to a distinct release, which can
# potentially be installed in multiple flavours counting as one kernel.
I faktycznie, po upgrade kernela kolejna stara wersja wskakuje
w status do automatycznego usunięcia.
Krzysztof Gajdemski
Jul 5, 2022, 3:51:14 AM7/5/22
to
Jest 05 Jul 2022 06:01:52 GMT, Dominik Ałaszewski pisze:
Jasne, że ogarnia, to praktycznie Debian. :) Masz rację, jakoś nie
doczytałem i wyszło mi, że autor chce usunąć wszystkie niepotrzebne
wersje jądra. Prawidłową odpowiedzią jest jest więc apt autoremove
(ew. z --purge przy zachowaniu zasad BHP).
> Dnia 04.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
>
>>> kernele po kolejnych aktualizacjach. W jaki sposób usunąć te zbędne i
>>> zostawić po 2-3? Bo domyślam się, że ręcznie tego się nie powinno robić.
>>> Jest jakieś narzędzie?
>> Owszem, trzeba zrobić purge'a niepotrzebnych pakietów z jądrem,
>> np. apt purge linux-image-5.xxxxxx-generic.
> W Ubunciaku system tego nie ogarnia? W Busterze mam takie cosie:
> root@morpheus:~# head -1 /etc/apt/apt.conf.d/01autoremove-kernels
[ … ]
>
>>> kernele po kolejnych aktualizacjach. W jaki sposób usunąć te zbędne i
>>> zostawić po 2-3? Bo domyślam się, że ręcznie tego się nie powinno robić.
>>> Jest jakieś narzędzie?
>> Owszem, trzeba zrobić purge'a niepotrzebnych pakietów z jądrem,
>> np. apt purge linux-image-5.xxxxxx-generic.
> W Ubunciaku system tego nie ogarnia? W Busterze mam takie cosie:
> root@morpheus:~# head -1 /etc/apt/apt.conf.d/01autoremove-kernels
Jasne, że ogarnia, to praktycznie Debian. :) Masz rację, jakoś nie
doczytałem i wyszło mi, że autor chce usunąć wszystkie niepotrzebne
wersje jądra. Prawidłową odpowiedzią jest jest więc apt autoremove
(ew. z --purge przy zachowaniu zasad BHP).
Roman Tyczka
Jul 6, 2022, 1:44:09 PM7/6/22
to
On 05.07.2022 09:50, Krzysztof Gajdemski wrote:
> Jest 05 Jul 2022 06:01:52 GMT, Dominik Ałaszewski pisze:
>> Dnia 04.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
>>
>>>> kernele po kolejnych aktualizacjach. W jaki sposób usunąć te zbędne i
>>>> zostawić po 2-3? Bo domyślam się, że ręcznie tego się nie powinno robić.
>>>> Jest jakieś narzędzie?
>>> Owszem, trzeba zrobić purge'a niepotrzebnych pakietów z jądrem,
>>> np. apt purge linux-image-5.xxxxxx-generic.
>> W Ubunciaku system tego nie ogarnia? W Busterze mam takie cosie:
>> root@morpheus:~# head -1 /etc/apt/apt.conf.d/01autoremove-kernels
>
> [ … ]
>
> Jasne, że ogarnia, to praktycznie Debian. :) Masz rację, jakoś nie
> doczytałem i wyszło mi, że autor chce usunąć wszystkie niepotrzebne
> wersje jądra. Prawidłową odpowiedzią jest jest więc apt autoremove
> (ew. z --purge przy zachowaniu zasad BHP).
Tak, autor chciał usunąć wszystkie niepotrzebne wersje jądra. I autor
> Jest 05 Jul 2022 06:01:52 GMT, Dominik Ałaszewski pisze:
>> Dnia 04.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
>>
>>>> kernele po kolejnych aktualizacjach. W jaki sposób usunąć te zbędne i
>>>> zostawić po 2-3? Bo domyślam się, że ręcznie tego się nie powinno robić.
>>>> Jest jakieś narzędzie?
>>> Owszem, trzeba zrobić purge'a niepotrzebnych pakietów z jądrem,
>>> np. apt purge linux-image-5.xxxxxx-generic.
>> W Ubunciaku system tego nie ogarnia? W Busterze mam takie cosie:
>> root@morpheus:~# head -1 /etc/apt/apt.conf.d/01autoremove-kernels
>
> [ … ]
>
> Jasne, że ogarnia, to praktycznie Debian. :) Masz rację, jakoś nie
> doczytałem i wyszło mi, że autor chce usunąć wszystkie niepotrzebne
> wersje jądra. Prawidłową odpowiedzią jest jest więc apt autoremove
> (ew. z --purge przy zachowaniu zasad BHP).
nadal ich nie umie usunąć, bo po wykonaniu:
$ sudo apt autoremove --purge
Czytanie list pakietów... Gotowe
Budowanie drzewa zależności... Gotowe
Odczyt informacji o stanie... Gotowe
Następujące pakiety zostaną USUNIĘTE:
fonts-font-awesome* icu-devtools* libclang-cpp13* libicu-dev* libllvm13*
libomp5-13* libstd-rust-1.59* libstd-rust-dev* libxml2-dev*
libykpers-1-1* libyubikey-udev* libyubikey0* llvm-13* llvm-13-dev*
llvm-13-linker-tools* llvm-13-runtime* llvm-13-tools*
0 aktualizowanych, 0 nowo instalowanych, 17 usuwanych i 0
nieaktualizowanych.
Po tej operacji zostanie zwolnione 847 MB miejsca na dysku.
Kontynuować? [T/n] T
Usunęło trochę rzeczy, ale jąder zyliony jak leżały tak leżą.
Oba polecenia head, jakie podał Dominik wyświetlają komunikat o braku
tych plików.
Co dalej?
--
pzdr
Roman
Jacek Marcin Jaworski
Jul 6, 2022, 2:02:08 PM7/6/22
to
środa, 6 lipca 2022 o 19:44:09 UTC+2 Roman Tyczka napisał(a):
> Co dalej?
sudo apt purge linux-image-5.4.0-96-generic
Nie daj się nabrać na to, że powyższa komenda jest nie do wykonania. Po prostu dodawaj nazwy pakietów jakie blokują jej wykonanie. Rób tak długo aż te wszystkie zbędne pakiety jawnie wymienisz. Wtedy to dziadowstwo usuwa zbędne kernele.
Mnie osobiście bardzo dziwi i bardzo niepokoii cotygodniowa aktualizacja kernela w dystrybucjach bazujących na Debianie. Nie wnikam co tam oni mieszają, tylko po instalacji wydaję komendę:
sudo apt-mark hold linux-*
> Co dalej?
sudo apt purge linux-image-5.4.0-96-generic
Nie daj się nabrać na to, że powyższa komenda jest nie do wykonania. Po prostu dodawaj nazwy pakietów jakie blokują jej wykonanie. Rób tak długo aż te wszystkie zbędne pakiety jawnie wymienisz. Wtedy to dziadowstwo usuwa zbędne kernele.
Mnie osobiście bardzo dziwi i bardzo niepokoii cotygodniowa aktualizacja kernela w dystrybucjach bazujących na Debianie. Nie wnikam co tam oni mieszają, tylko po instalacji wydaję komendę:
sudo apt-mark hold linux-*
Dominik Ałaszewski
Jul 7, 2022, 2:48:56 AM7/7/22
to
Dnia 06.07.2022 Roman Tyczka <roman...@hate.you.spammer> napisał/a:
> Tak, autor chciał usunąć wszystkie niepotrzebne wersje jądra. I autor
> nadal ich nie umie usunąć, bo po wykonaniu:
>
> $ sudo apt autoremove --purge
SOA#1, u mnie wyjątek z loga (/var/log/apt/history.log):
> Tak, autor chciał usunąć wszystkie niepotrzebne wersje jądra. I autor
> nadal ich nie umie usunąć, bo po wykonaniu:
>
> $ sudo apt autoremove --purge
Start-Date: 2022-07-04 07:56:24
Commandline: apt upgrade
Requested-By: dominik (1000)
Install: linux-image-4.19.0-21-amd64:amd64 (4.19.249-2, automatic)
Upgrade: gnupg-utils:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), linux-libc-dev:amd64 (4.19.235-1, 4.19.249-2), gnupg-agent:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), gpg-wks-client:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), gnupg-l10n:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), gpg-wks-server:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), gpg:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), dirmngr:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), linux-image-amd64:amd64 (4.19+105+deb10u15, 4.19+105+deb10u16), gpgv:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), gnupg:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), gpg-agent:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), gpgconf:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2), gpgsm:amd64 (2.2.12-1+deb10u1, 2.2.12-1+deb10u2)
End-Date: 2022-07-04 07:56:53
Start-Date: 2022-07-04 07:57:14
Commandline: apt autoremove
Requested-By: dominik (1000)
Remove: linux-image-4.19.0-19-amd64:amd64 (4.19.232-1)
End-Date: 2022-07-04 07:57:21
Jak widać z aktualizacją przyszło nowe jądro, a stare wskoczyło w status
do automatycznego usunięcia, wykonane chwilę później "apt autoremove"
je usunęło.
> Oba polecenia head, jakie podał Dominik wyświetlają komunikat o braku
> tych plików.
trzeba to zrobić inaczej, niż w Debianie/Ubuntu.
> Co dalej?
Wujek G podpowiada, że jest stosowna opcja w guju:
https://winaero.com/automatically-remove-old-kernels-linux-mint/
Roman Tyczka
Jul 7, 2022, 3:01:46 AM7/7/22
to
On 07.07.2022 08:48, Dominik Ałaszewski wrote:
>> Tak, autor chciał usunąć wszystkie niepotrzebne wersje jądra. I autor
>> nadal ich nie umie usunąć, bo po wykonaniu:
>>
>> $ sudo apt autoremove --purge
>
> SOA#1, u mnie wyjątek z loga (/var/log/apt/history.log):
>
[..]
>> Tak, autor chciał usunąć wszystkie niepotrzebne wersje jądra. I autor
>> nadal ich nie umie usunąć, bo po wykonaniu:
>>
>> $ sudo apt autoremove --purge
>
> SOA#1, u mnie wyjątek z loga (/var/log/apt/history.log):
>
> Jak widać z aktualizacją przyszło nowe jądro, a stare wskoczyło w status
> do automatycznego usunięcia, wykonane chwilę później "apt autoremove"
> je usunęło.
>
>> Oba polecenia head, jakie podał Dominik wyświetlają komunikat o braku
>> tych plików.
>
> Może to oznaczać, iż opiekunowie Minta stwierdzili, że z jakichś powodów
> trzeba to zrobić inaczej, niż w Debianie/Ubuntu.
>
>> Co dalej?
>
> Wujek G podpowiada, że jest stosowna opcja w guju:
> https://winaero.com/automatically-remove-old-kernels-linux-mint/
Czyli mój system powinien automatycznie oznaczać poprzednie jądra do
usunięcia? I tak jest defaultowo czy trzeba to jakoś uaktywnić?
--
pzdr
Roman
Dominik Ałaszewski
Jul 7, 2022, 4:09:28 AM7/7/22
to
Dnia 07.07.2022 Roman Tyczka <roman...@hate.you.spammer> napisał/a:
> Ja jednakowoż mam Ubuntu, a konkretnie Kubuntu :-)
> Czyli mój system powinien automatycznie oznaczać poprzednie jądra do
> usunięcia? I tak jest defaultowo czy trzeba to jakoś uaktywnić?
A, to już nie wiem. Wszelakie poradniki, w rodzaju:
> Ja jednakowoż mam Ubuntu, a konkretnie Kubuntu :-)
> Czyli mój system powinien automatycznie oznaczać poprzednie jądra do
> usunięcia? I tak jest defaultowo czy trzeba to jakoś uaktywnić?
https://help.ubuntu.com/community/RemoveOldKernels#Using_Apt
twierdzą, że apt autoremove powinno załatwiać sprawę,
czyli powinny być stosownie oznaczane.
Tropem mogłoby być, że jądra były ewentualnie instalowane
"ręcznie", co można by sprawdzić przez:
apt-mark showmanual 'linux-image*'
i ewentualnie dla pewności: apt-mark showauto 'linux-image*'
Może jeśli uaktualnianie jest wykonywane jakimś GUIowym
czymś, to dostają status zainstalowanych ręcznie?
Ale podejrzany jest brak pliku /etc/apt/apt.conf.d/01autoremove-kernels,
to mi to wygląda na jakąś głębszą modyfikację systemu, bo ludzie
mający nawet problemy z autonieusuwaniem (na Kubuntu) twierdzą,
że ten plik jest. Przykładowo:
https://askubuntu.com/questions/1325387/why-is-apt-get-autoremove-failing-to-remove-my-old-kernels
Roman Tyczka
Jul 7, 2022, 4:24:50 AM7/7/22
to
On 07.07.2022 10:08, Dominik Ałaszewski wrote:
>> Ja jednakowoż mam Ubuntu, a konkretnie Kubuntu :-)
>> Czyli mój system powinien automatycznie oznaczać poprzednie jądra do
>> usunięcia? I tak jest defaultowo czy trzeba to jakoś uaktywnić?
>
> A, to już nie wiem. Wszelakie poradniki, w rodzaju:
> https://help.ubuntu.com/community/RemoveOldKernels#Using_Apt
> twierdzą, że apt autoremove powinno załatwiać sprawę,
> czyli powinny być stosownie oznaczane.
>
> Tropem mogłoby być, że jądra były ewentualnie instalowane
> "ręcznie", co można by sprawdzić przez:
>
> apt-mark showmanual 'linux-image*'
> i ewentualnie dla pewności: apt-mark showauto 'linux-image*'
$ apt-mark showmanual 'linux-image*'
>> Ja jednakowoż mam Ubuntu, a konkretnie Kubuntu :-)
>> Czyli mój system powinien automatycznie oznaczać poprzednie jądra do
>> usunięcia? I tak jest defaultowo czy trzeba to jakoś uaktywnić?
>
> A, to już nie wiem. Wszelakie poradniki, w rodzaju:
> https://help.ubuntu.com/community/RemoveOldKernels#Using_Apt
> twierdzą, że apt autoremove powinno załatwiać sprawę,
> czyli powinny być stosownie oznaczane.
>
> Tropem mogłoby być, że jądra były ewentualnie instalowane
> "ręcznie", co można by sprawdzić przez:
>
> apt-mark showmanual 'linux-image*'
> i ewentualnie dla pewności: apt-mark showauto 'linux-image*'
linux-image-5.11.0-40-generic
linux-image-5.13.0-22-generic
linux-image-5.13.0-23-generic
linux-image-5.13.0-25-generic
linux-image-5.13.0-27-generic
linux-image-5.13.0-28-generic
linux-image-5.13.0-30-generic
linux-image-5.13.0-35-generic
linux-image-5.13.0-37-generic
linux-image-5.13.0-39-generic
linux-image-5.13.0-40-generic
linux-image-5.13.0-41-generic
linux-image-5.13.0-44-generic
linux-image-5.13.0-46-generic
linux-image-5.13.0-48-generic
linux-image-5.13.0-51-generic
linux-image-5.13.0-52-generic
$ apt-mark showauto 'linux-image*'
linux-image-generic
> Może jeśli uaktualnianie jest wykonywane jakimś GUIowym
> czymś, to dostają status zainstalowanych ręcznie?
w trayu, że są aktualizacje, więc klik i leci. Może to jego sprawka.
> Ale podejrzany jest brak pliku /etc/apt/apt.conf.d/01autoremove-kernels,
razem 88
-rw-r--r-- 1 root root 49 maj 12 2021 00aptitude
-rw-r--r-- 1 root root 40 maj 12 2021 00trustcdrom
-rw-r--r-- 1 root root 630 kwi 13 2021 01autoremove
-rw-r--r-- 1 root root 92 kwi 13 2021 01-vendor-ubuntu
-rw-r--r-- 1 root root 168 lis 28 2021 10periodic
-rw-r--r-- 1 root root 108 maj 14 2021 15update-stamp
-rw-r--r-- 1 root root 604 lip 27 2021 20apt-esm-hook.conf
-rw-r--r-- 1 root root 85 maj 14 2021 20archive
-rw-r--r-- 1 root root 168 lis 28 2021 20auto-upgrades
-rw-r--r-- 1 root root 243 gru 16 2009 20dbus
-rw-r--r-- 1 root root 1040 lis 2 2020 20packagekit
-rw-r--r-- 1 root root 114 mar 26 2021 20snapd.conf
-rw-r--r-- 1 root root 2592 lut 16 2021 50appstream
-rw-r--r-- 1 root root 625 cze 1 2020 50command-not-found
-rw-r--r-- 1 root root 6155 lut 19 2021 50unattended-upgrades
-rw-r--r-- 1 root root 435 lut 16 2021 60icons
-rw-r--r-- 1 root root 251 lut 16 2021 60icons-hidpi
-rw-r--r-- 1 root root 348 lut 16 2021 60icons-large
-rw-r--r-- 1 root root 253 lut 16 2021 60icons-large-hidpi
-rw-r--r-- 1 root root 182 kwi 18 2020 70debconf
-rw-r--r-- 1 root root 305 maj 14 2021 99update-notifier
> to mi to wygląda na jakąś głębszą modyfikację systemu, bo ludzie
20.04 do 21.10, może mu się przy tym skoku coś pokitrasiło.
> mający nawet problemy z autonieusuwaniem (na Kubuntu) twierdzą,
> że ten plik jest. Przykładowo:
> https://askubuntu.com/questions/1325387/why-is-apt-get-autoremove-failing-to-remove-my-old-kernels
sudo apt purge linux-image-5.4.0-96-generic
--
pzdr
Roman
Dominik Ałaszewski
Jul 7, 2022, 5:06:57 AM7/7/22
to
Dnia 07.07.2022 Roman Tyczka <roman...@hate.you.spammer> napisał/a:
> Zazwyczaj aktualizacje robię rzeczywiście KDE'owym Odkrycą, bo wyskakuje
> w trayu, że są aktualizacje, więc klik i leci. Może to jego sprawka.
Był/jest taki problem:
> w trayu, że są aktualizacje, więc klik i leci. Może to jego sprawka.
https://bugs.kde.org/show_bug.cgi?id=43029
https://github.com/PackageKit/PackageKit/issues/450
> Czyli co? Pozostaje jednak usuwać pojedynczo? za pomocą:
jako auto:
apt-mark auto linux-image-5.11.0-40-generic
i dać apt autoremove.
Z tym, że to nie rozwiąże problemu właściwego oznaczania pakietów
przy upgrade. Rozwiązanie to olać guiowy narządź i użyć np.
pakietu unattended-upgrades. Ewentualnie protezy podane
w drugim linku- oznaczanie pakietów kernela jako auto co tydzień :-)
Krzysztof Gajdemski
Jul 7, 2022, 11:48:38 AM7/7/22
to
Jest 07 Jul 2022 08:08:41 GMT, Dominik Ałaszewski pisze:
wykonywane wyłącznie na podstawie wewnętrznego kodu w apt i pliki te nie
są potrzebne. W changelogu jest to opisane enigmatycznie:
#v+
apt (2.4.5) unstable; urgency=medium
* Only protect two kernels, not last installed one (LP: #1968154)
* Fix segfault in CacheSetHelperAPTGet::tryVirtualPackage()
-- Julian Andres Klode <j...@debian.org> Fri, 08 Apr 2022 12:22:23 +0200
#v-
https://metadata.ftp-master.debian.org/changelogs//main/a/apt/apt_2.5.1_changelog
Ale kod nie pozostawia wątpliwości:
https://salsa.debian.org/apt-team/apt/-/commit/824651ded0bcf8603e9b508860b8fe5a68fc53ff#fb7a2b7fa64fa286b067e42f0fbdc74b17c8b1b2
Czyli u kol. Romantycznego z systemem jest wszystko w porządku. I racja,
za zaistniałą sytuację odpowiada bug w Packagekit. Teoretycznie jest to
poprawione w (K)Ubuntu 22.04 LTS.
> Dnia 07.07.2022 Roman Tyczka <roman...@hate.you.spammer> napisał/a:
> Ale podejrzany jest brak pliku /etc/apt/apt.conf.d/01autoremove-kernels,
> to mi to wygląda na jakąś głębszą modyfikację systemu, bo ludzie
> mający nawet problemy z autonieusuwaniem (na Kubuntu) twierdzą,
> że ten plik jest. Przykładowo:
> https://askubuntu.com/questions/1325387/why-is-apt-get-autoremove-failing-to-remove-my-old-kernels
Wygląda na to, że od wersji 2.4.5 apt to się zmieniło. Usuwanie jest
> Ale podejrzany jest brak pliku /etc/apt/apt.conf.d/01autoremove-kernels,
> to mi to wygląda na jakąś głębszą modyfikację systemu, bo ludzie
> mający nawet problemy z autonieusuwaniem (na Kubuntu) twierdzą,
> że ten plik jest. Przykładowo:
> https://askubuntu.com/questions/1325387/why-is-apt-get-autoremove-failing-to-remove-my-old-kernels
wykonywane wyłącznie na podstawie wewnętrznego kodu w apt i pliki te nie
są potrzebne. W changelogu jest to opisane enigmatycznie:
#v+
apt (2.4.5) unstable; urgency=medium
* Only protect two kernels, not last installed one (LP: #1968154)
* Fix segfault in CacheSetHelperAPTGet::tryVirtualPackage()
-- Julian Andres Klode <j...@debian.org> Fri, 08 Apr 2022 12:22:23 +0200
#v-
https://metadata.ftp-master.debian.org/changelogs//main/a/apt/apt_2.5.1_changelog
Ale kod nie pozostawia wątpliwości:
https://salsa.debian.org/apt-team/apt/-/commit/824651ded0bcf8603e9b508860b8fe5a68fc53ff#fb7a2b7fa64fa286b067e42f0fbdc74b17c8b1b2
Czyli u kol. Romantycznego z systemem jest wszystko w porządku. I racja,
za zaistniałą sytuację odpowiada bug w Packagekit. Teoretycznie jest to
poprawione w (K)Ubuntu 22.04 LTS.
Roman Tyczka
Jul 7, 2022, 1:03:00 PM7/7/22
to
On 07.07.2022 11:06, Dominik Ałaszewski wrote:
>> Zazwyczaj aktualizacje robię rzeczywiście KDE'owym Odkrycą, bo wyskakuje
>> w trayu, że są aktualizacje, więc klik i leci. Może to jego sprawka.
>
> Był/jest taki problem:
> https://bugs.kde.org/show_bug.cgi?id=43029
> https://github.com/PackageKit/PackageKit/issues/450
No patrz Pan jaka wtopa. Dobrze, że dysk duży mam i nie dobiło do końca,
>> Zazwyczaj aktualizacje robię rzeczywiście KDE'owym Odkrycą, bo wyskakuje
>> w trayu, że są aktualizacje, więc klik i leci. Może to jego sprawka.
>
> Był/jest taki problem:
> https://bugs.kde.org/show_bug.cgi?id=43029
> https://github.com/PackageKit/PackageKit/issues/450
bo byłby większy kłopot przy aktualizacji.
>> Czyli co? Pozostaje jednak usuwać pojedynczo? za pomocą:
>
> Można jeszcze oznaczyć jakiś stary pakiet kernela
> jako auto:
> apt-mark auto linux-image-5.11.0-40-generic
> i dać apt autoremove.
>
> Z tym, że to nie rozwiąże problemu właściwego oznaczania pakietów
> przy upgrade. Rozwiązanie to olać guiowy narządź i użyć np.
> pakietu unattended-upgrades. Ewentualnie protezy podane
> w drugim linku- oznaczanie pakietów kernela jako auto co tydzień :-)
upgrade do Kubuntu 22, tylko czekam na większą stabilność, bo tam chyba
nadal jakieś jaja z waylandem się odbywają.
Ale ubyło z dysku ponad 8GB niepotrzebnego śmiecia! :-)
No i widzę, że także się przebudowała konfiguracja gruba, bo tam też te
kernele były uwzględnione.
Dzięki za pomoc.
--
pzdr
Roman
Jacek Marcin Jaworski
Jul 7, 2022, 2:35:59 PM7/7/22
to
czwartek, 7 lipca 2022 o 19:03:00 UTC+2 Roman Tyczka napisał(a):
> Ale ubyło z dysku ponad 8GB niepotrzebnego śmiecia! :-)
Zaprogramuj chociaż 1MB działającego podobnie śmiecia, to uznam Cię za godnego wygadywania takich głupot!
> Ale ubyło z dysku ponad 8GB niepotrzebnego śmiecia! :-)
Roman Tyczka
Jul 8, 2022, 3:30:01 AM7/8/22
to
On 07.07.2022 20:35, Jacek Marcin Jaworski wrote:
>> Ale ubyło z dysku ponad 8GB niepotrzebnego śmiecia! :-)
>
> Zaprogramuj chociaż 1MB działającego podobnie śmiecia, to uznam Cię za godnego wygadywania takich głupot!
Nie napinaj się, niepotrzebne pliki = śmieci, nie oceniałem zawartości
>> Ale ubyło z dysku ponad 8GB niepotrzebnego śmiecia! :-)
>
> Zaprogramuj chociaż 1MB działającego podobnie śmiecia, to uznam Cię za godnego wygadywania takich głupot!
tych plików.
--
pzdr
Roman
Dominik Ałaszewski
Jul 8, 2022, 3:37:00 AM7/8/22
to
Dnia 07.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
> Wygląda na to, że od wersji 2.4.5 apt to się zmieniło. Usuwanie jest
> wykonywane wyłącznie na podstawie wewnętrznego kodu w apt i pliki te nie
Słuszną linię ma nasza partia. Poprzednio na wszelki wypadek nie było
> Wygląda na to, że od wersji 2.4.5 apt to się zmieniło. Usuwanie jest
> wykonywane wyłącznie na podstawie wewnętrznego kodu w apt i pliki te nie
żadnej konfiguracji, ale chcący zachowywać np. 3 stare kernele mogli
poprawić skrypt. Teraz będą musieli skompilować sobie własnego apta :-)
Krzysztof Gajdemski
Jul 8, 2022, 5:46:02 AM7/8/22
to
Jest 08 Jul 2022 07:36:07 GMT, Dominik Ałaszewski pisze:
zrobić sobie własny skrypt apt-auto-removal. On po prostu dodaje
w apt.conf.d wpisy typu APT::NeverAutoRemove{ }; i to nadal będzie
działać.
> Dnia 07.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
>
>> Wygląda na to, że od wersji 2.4.5 apt to się zmieniło. Usuwanie jest
>> wykonywane wyłącznie na podstawie wewnętrznego kodu w apt i pliki te nie
> Słuszną linię ma nasza partia. Poprzednio na wszelki wypadek nie było
> żadnej konfiguracji, ale chcący zachowywać np. 3 stare kernele mogli
> poprawić skrypt. Teraz będą musieli skompilować sobie własnego apta :-)
Były i takie uwagi. Jednak nadal nic nie stoi na przeszkodzie, żeby
>
>> Wygląda na to, że od wersji 2.4.5 apt to się zmieniło. Usuwanie jest
>> wykonywane wyłącznie na podstawie wewnętrznego kodu w apt i pliki te nie
> Słuszną linię ma nasza partia. Poprzednio na wszelki wypadek nie było
> żadnej konfiguracji, ale chcący zachowywać np. 3 stare kernele mogli
> poprawić skrypt. Teraz będą musieli skompilować sobie własnego apta :-)
zrobić sobie własny skrypt apt-auto-removal. On po prostu dodaje
w apt.conf.d wpisy typu APT::NeverAutoRemove{ }; i to nadal będzie
działać.
Jacek Marcin Jaworski
Jul 8, 2022, 6:07:16 AM7/8/22
to
piątek, 8 lipca 2022 o 11:46:02 UTC+2 Krzysztof Gajdemski napisał(a):
> Jest 08 Jul 2022 07:36:07 GMT, Dominik Ałaszewski pisze:
> > Dnia 07.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
> >
> >> Wygląda na to, że od wersji 2.4.5 apt to się zmieniło. Usuwanie jest
> >> wykonywane wyłącznie na podstawie wewnętrznego kodu w apt i pliki te nie
> > Słuszną linię ma nasza partia. Poprzednio na wszelki wypadek nie było
> > żadnej konfiguracji, ale chcący zachowywać np. 3 stare kernele mogli
> > poprawić skrypt. Teraz będą musieli skompilować sobie własnego apta :-)
> Były i takie uwagi. Jednak nadal nic nie stoi na przeszkodzie, żeby
> zrobić sobie własny skrypt apt-auto-removal. On po prostu dodaje
> w apt.conf.d wpisy typu APT::NeverAutoRemove{ }; i to nadal będzie
> działać.
Pewnie tak, ale nie o to tu chodzi!
> Jest 08 Jul 2022 07:36:07 GMT, Dominik Ałaszewski pisze:
> > Dnia 07.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
> >
> >> Wygląda na to, że od wersji 2.4.5 apt to się zmieniło. Usuwanie jest
> >> wykonywane wyłącznie na podstawie wewnętrznego kodu w apt i pliki te nie
> > Słuszną linię ma nasza partia. Poprzednio na wszelki wypadek nie było
> > żadnej konfiguracji, ale chcący zachowywać np. 3 stare kernele mogli
> > poprawić skrypt. Teraz będą musieli skompilować sobie własnego apta :-)
> Były i takie uwagi. Jednak nadal nic nie stoi na przeszkodzie, żeby
> zrobić sobie własny skrypt apt-auto-removal. On po prostu dodaje
> w apt.conf.d wpisy typu APT::NeverAutoRemove{ }; i to nadal będzie
> działać.
Tu chodzi o to, że dostajesz coś za darmo. I to coś można w każdej chwili popsuć. I nie ma co się spinać, bo gratisy nie mają gwarancji.
W dodatku sprwa jest aż tak ważna, że SZAP wykłada na to grubą kapuchę.
Aby jakoś unaocznić, że rozdawanie w pełni funkcjonalnych systemów Linuks jest nie normalne, podam, że aby uczciwie zapłacić za taki system należało by dorzucić co najmniej kwotę jaką się daje za nowy komputer.
Taki ma cennik Apple i nie jest to przypadek.
Tak więc przestańcie się zachowywać jak głupie dziewczynki co czatują na promkę w Biedronce. Tylko dajcie złoty pieniążek tym co jeszcze sprzedają Linuksa, bo inaczej czarno to widzę i wszyscy normalni będą musieli siedzieć na szpiegujących Makach.
Niech ktoś z was powie: Jesteście biednymi uczniami lub studentami, że was nie stać na płatnego Linuksa?
Jacek Marcin Jaworski
Jul 8, 2022, 6:08:54 AM7/8/22
to
piątek, 8 lipca 2022 o 12:07:16 UTC+2 Jacek Marcin Jaworski napisał(a):
Jest:
Tylko dajcie złoty pieniążek tym co jeszcze sprzedają Linuksa, bo inaczej czarno to widzę i w końcu wszyscy normalni będą musieli siedzieć na szpiegujących Makach.
Jest:
> Tylko dajcie złoty pieniążek tym co jeszcze sprzedają Linuksa, bo inaczej czarno to widzę i wszyscy normalni będą musieli siedzieć na szpiegujących Makach.
Powinno być:
Tylko dajcie złoty pieniążek tym co jeszcze sprzedają Linuksa, bo inaczej czarno to widzę i w końcu wszyscy normalni będą musieli siedzieć na szpiegujących Makach.
Dominik Ałaszewski
Jul 8, 2022, 7:13:41 AM7/8/22
to
Dnia 08.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
> Były i takie uwagi. Jednak nadal nic nie stoi na przeszkodzie, żeby
> zrobić sobie własny skrypt apt-auto-removal. On po prostu dodaje
> w apt.conf.d wpisy typu APT::NeverAutoRemove{ }; i to nadal będzie
> działać.
A nie było uwag, że najprościej byłoby użyć parametru w konfiguracji,
> Były i takie uwagi. Jednak nadal nic nie stoi na przeszkodzie, żeby
> zrobić sobie własny skrypt apt-auto-removal. On po prostu dodaje
> w apt.conf.d wpisy typu APT::NeverAutoRemove{ }; i to nadal będzie
> działać.
skoro jednemu będzie pasować 2 a innemu 5 pozostawionych kerneli?
Krzysztof Gajdemski
Jul 8, 2022, 9:02:14 AM7/8/22
to
Jest 08 Jul 2022 11:13:39 GMT, Dominik Ałaszewski pisze:
argument na 99% otrzymasz prośbę o przysłanie odpowiedniego patcha.
> Dnia 08.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
>
>> Były i takie uwagi. Jednak nadal nic nie stoi na przeszkodzie, żeby
>> zrobić sobie własny skrypt apt-auto-removal. On po prostu dodaje
>> w apt.conf.d wpisy typu APT::NeverAutoRemove{ }; i to nadal będzie
>> działać.
> A nie było uwag, że najprościej byłoby użyć parametru w konfiguracji,
> skoro jednemu będzie pasować 2 a innemu 5 pozostawionych kerneli?
To jest jeden z tych przypadków, gdzie w odpowiedzi na tego typu
>
>> Były i takie uwagi. Jednak nadal nic nie stoi na przeszkodzie, żeby
>> zrobić sobie własny skrypt apt-auto-removal. On po prostu dodaje
>> w apt.conf.d wpisy typu APT::NeverAutoRemove{ }; i to nadal będzie
>> działać.
> A nie było uwag, że najprościej byłoby użyć parametru w konfiguracji,
> skoro jednemu będzie pasować 2 a innemu 5 pozostawionych kerneli?
argument na 99% otrzymasz prośbę o przysłanie odpowiedniego patcha.
Dominik Ałaszewski
Jul 9, 2022, 5:38:51 AM7/9/22
to
Dnia 08.07.2022 Krzysztof Gajdemski <son...@debian.org.pl> napisał/a:
> To jest jeden z tych przypadków, gdzie w odpowiedzi na tego typu
> argument na 99% otrzymasz prośbę o przysłanie odpowiedniego patcha.
Patch patchem, ale zastanawiam się, czy były takie argumenty,
> To jest jeden z tych przypadków, gdzie w odpowiedzi na tego typu
> argument na 99% otrzymasz prośbę o przysłanie odpowiedniego patcha.
czyli czy jeszcze ktoś (oprócz mnie) tak uważa. Jeśli nie,
to i patcha przysyłać nie ma sensu, bo i dla kogo?
0 new messages