zmień rozmiar / zmniejsz główny system plików za pomocą grub2 (tj. przed zamontowaniem)

Kontekst:

kilka zdalnych serwerów 32-bitowych Debian 7
dostępne tylko przez SSH
ponad połowa dysków jest pusta
1 partycja całego dysku na serwer
małe okno serwisowe, nie może być opuszczone na długo
systemy plików ext4
UWAGA: Rozwijam swoje rozwiązanie przy użyciu maszyny wirtualnej VirtualBox, ale serwery są proste od zera.

Cel: zaktualizuj system operacyjny do wersji Debian 9+ w nieniszczący sposób, ponieważ idealnie maszyna musi pozostać w gotowości do ponownego uruchomienia w nowym systemie operacyjnym.

Tak więc dla każdego serwera planuję (mile widziane inne sugestie) wykonać następujące czynności:

Zmniejsz obecny rootfs deb 7 z resize2fs do nieco mniejszej niż 1/2 rozmiaru partycji
Zmniejsz partycję, aby wyczyścić 1/2 dysku
Podziel nowo uwolnione miejsce (/, / home, swap) i zainstaluj LVM2
(utwórz VG, LV itp.) I Debian 9

Mój problem polega na tym, że resize2fs może tylko zmniejszyć ext4 fs JEŚLI odmontowany. Pomysł polega więc na użyciu obrazu initrd lub initramfs do wywołania resize2fs na odmontowanym / dev / sda1 podczas sekwencji ładowania GRUB2.

Zbudowałem własny obraz initrd zawierający statyczny plik binarny resize2fs i skrypt powłoki, który go wywołuje (i wykonuje inne walidacje itp.), Ale wydaje mi się, że trafiłem w kłopoty, próbując napisać poprawny wpis w pliku grub.cfg, aby zrobić montuje mój obraz initrd i wykonuje skrypt zmiany rozmiaru na odmontowanym / dev / sda1.

Więc moje pytanie brzmi:

Jakie menu grub.cfg muszę napisać, aby załadować mój niestandardowy obraz initrd zawierający mój skrypt /bin/resize.sh, a następnie go uruchomić (/bin/resize.sh)?

— Martin Vincent
źródło

To, co zrobiłem wcześniej (i być może ryzykowne?), To ustawienie tymczasowego minimalnego systemu plików na ramdysku i przestawienie na niego katalogu głównego, umożliwiając odmontowanie dysku bez utraty dostępu SSH. Używał go wcześniej, aby całkowicie zmienić typ głównego systemu plików, więc zmniejszanie powinno działać. Jeśli chcesz podążać tą ścieżką, daj mi znać, a ja mogę ją napisać rano.

— Bob

Niezależnie od tego, której metody użyjesz, sugeruję, aby mieć kopie zapasowe, które są aktualne i możliwe do odtworzenia na wypadek najgorszego.

— Bob

Cześć @Bob, rzeczywiście czytałem o użyciu techniki pivot_root, ale czułem, że jest to nieco bardziej ryzykowne i złożone (wiele kroków) niż zwykłe zmienianie rozmiaru z grub (tj. Przed zamontowaniem jakichkolwiek partycji). Staram się, aby było to stosunkowo proste i skryptowalne (tj. Bezobsługowe wykonanie, jeśli to możliwe). To powiedziawszy, jestem zdecydowanie zainteresowany uzyskaniem dodatkowych informacji na temat wybranej przez ciebie ścieżki. Z góry dziękuję.

— Martin Vincent

Ach, znalazłem ten , na którym oparłem mój , który jest dość obszernym przewodnikiem (i działa na konfiguracjach systemowych, w przeciwieństwie do tego, który połączyłeś). Jedyną modyfikacją, którą wprowadziłem, było wygenerowanie tymczasowego katalogu głównego debootstrapzamiast cptworzenia istniejących plików. Dla moich celów posiadanie interaktywnej powłoki było bardziej przydatne, zarówno dlatego, że moja instalacja składała się z wielu kroków, jak i do testowania / sprawdzania poprawności przed ponownym uruchomieniem. Ale oczywiście, jeśli wolisz zautomatyzować go za pomocą równie ważnego initrd - niestety nie mogę pomóc bezpośrednio, przepraszam.

— Bob

Jeszcze raz dziękuję @Bob za odpowiedź. Udało mi się sprawić, aby działało przy użyciu initrd z mniej więcej następującymi krokami: 1. stwórz plik obrazu initrd (rozpakuj w ~ / initrd istniejący, dodaj kilka plików) rezip z: 2. stwórz debian7-32bits:~/initrd# find . | cpio -o -H newc | gzip -9 > /boot/initrd.img-3.2.0-5-486-resize2fs wpis w /boot/grub/grub.cfgpodobny sposób:

menuentry "run_once_resize_fs" {         set root='(hd0,msdos1)'; 	insmod linux grub help kernel initrd; 	linux	/boot/vmlinuz-3.2.0-5-486;         initrd  /boot/initrd.img-3.2.0-5-486-resize2fs;     }

— Martin Vincent