Ubuntu Server 26.04 jako VHD na Ventoy — wersja minimalna z działającym zapisem

Posted on by forteller

Poniższy wpis został wygenerowany za pomocą AI, niemniej przeszedłem przez niego własnoręcznie. Jeśli kiedykolwiek będę chciał zrobić to jeszcze raz, dokumentuję to poniżej.

Cel: zainstalowane najnowsze Ubuntu na pendrive z systemem plików do zapisu. Po uruchomieniu działa jak normalny zainstalowany system operacyjny.

Po przejściu Ubuntu na dracut (od wydania 25.10) tradycyjna metoda przygotowania obrazu VHD pod Ventoya — czyli skrypt vtoyboot.sh — przestała być niezawodna. Główną przyczyną jest binarny moduł jądra dm_patch.ko, który dostarcza vtoyboot i który rozjeżdża się z każdą nową wersją jądra. Stąd narzucony obowiązek uruchamiania vtoyboot.sh po każdej aktualizacji oraz zgłoszone, nienaprawione błędy uniemożliwiające rozruch w nowszych wydaniach Ubuntu.

Poniżej minimalne podejście oparte na pomyśle z poradnika korkmana, ale ograniczone do najprostszego scenariusza: jeden plik VHD, jedna partycja Ventoy, bez szyfrowania, bez osobnego /boot. Pominięte zostały: drugi plik VHD na rozruch, automatyczne montowanie /boot, niezmienne punkty montowania, skrypty przenoszące montowania oraz własna konfiguracja GRUB-a wewnątrz maszyny wirtualnej.

Przenośność między pendrive’ami. Przygotowany w ten sposób initrd działa niezależnie od tego, czy partycja Ventoy została sformatowana jako exFAT, NTFS lub FAT32. Dzięki temu plik VHD można później przełożyć na inny pendrive Ventoy bez konieczności ponownego budowania obrazu.

Zgodność z BIOS i UEFI. Ten sam plik VHD uruchamia się pod GRUB-em Ventoya zarówno w trybie Legacy BIOS, jak i UEFI — niezależnie od tego, w którym trybie zainstalowano Ubuntu. Kluczowy fakt: bootloader znajdujący się wewnątrz pliku VHD (grub-pc lub grub-efi) nigdy nie jest wykorzystywany przez Ventoya. GRUB Ventoya samodzielnie podpina plik VHD jako urządzenie loop, odczytuje /boot/vmlinuz oraz /boot/initrd.img z partycji głównej, a następnie ładuje jądro bezpośrednio. Spotykana czasem obserwacja, że „Linux zainstalowany w trybie BIOS nie chce się uruchomić pod UEFI”, odnosi się do prób uruchomienia takiego systemu bezpośrednio z firmware UEFI, gdzie wymagany jest moduł ładujący EFI na partycji ESP. W omawianym scenariuszu nie ma tego problemu, ponieważ to GRUB Ventoya pełni funkcję modułu ładującego. Z tego samego powodu Linux zainstalowany w trybie UEFI uruchomi się również pod Ventoyem działającym w trybie BIOS — droga rozruchu jądra nie wymaga środowiska EFI, a wpis /boot/efi w /etc/fstab jest tolerowany (FAT32 montuje się normalnie i bez interfejsów EFI).

Dlaczego to działa bez vtoyboot

Vtoyboot polega na binarnym module jądra dm_patch.ko, który rozjeżdża się z każdą nową wersją jądra — stąd wymóg uruchamiania vtoyboot.sh po każdej aktualizacji. W zaproponowanym tu rozwiązaniu zamiast modułu jądra używany jest zwykły skrypt powłoki jako hook w dracut. Działa wyłącznie w przestrzeni użytkownika i jest odtwarzany w initrd przy każdym uruchomieniu update-initramfs, które wykonuje się i tak przy aktualizacji jądra.

Mechanika rozruchu wygląda następująco:

  1. GRUB Ventoya podpina plik VHD jako urządzenie loop i ładuje vmlinuz oraz initrd z partycji głównej zawartej w VHD.
  2. Jądro startuje, dracut szuka systemu plików root po LABEL=VentUbuntu.
  3. Etykieta nie istnieje (plik VHD jest w tym momencie tylko zwykłym plikiem na partycji exFAT/NTFS) — uruchamia się nasz skrypt hook.
  4. Skrypt montuje partycję Ventoy, wykonuje losetup -P na pliku VHD, dzięki czemu partycje wewnątrz VHD pojawiają się jako urządzenia blokowe, a /dev/disk/by-label/VentUbuntu materializuje się.
  5. Dracut kontynuuje normalny rozruch i montuje system plików root.

Ten sam initrd działa również w maszynie wirtualnej, ponieważ tam etykieta istnieje od razu i skrypt hook nie wykonuje żadnej akcji.

Założenia struktury

Aby GRUB Ventoya mógł odczytać /boot/vmlinuz z pliku VHD, partycja główna musi być w formacie, który GRUB rozumie (ext4 jest w porządku), bez LVM i bez szyfrowania. Najprostszy układ przy instalacji w trybie UEFI:

  • (loop1,1) — ESP (FAT32, około 500 MB) — wykorzystywana wyłącznie w maszynie wirtualnej, nie modyfikujemy jej.
  • (loop1,2) — ext4 z /boot w środku — z tej partycji GRUB pobiera vmlinuz oraz initrd.

Krok 1: Przygotowanie maszyny wirtualnej i instalacja Ubuntu

W programie VirtualBox:

  • Utwórz nową maszynę wirtualną w trybie UEFI (System → Enable EFI).
  • Dysk: format VHD, stały rozmiar (nie dynamiczny), na przykład 30 GB.
  • Uruchom z obrazu ISO Ubuntu Server 26.04.
  • Przy partycjonowaniu wybierz Custom storage layout (manualne):
    • 500 MB FAT32 → punkt montowania /boot/efi, flaga ESP.
    • reszta dysku → ext4 → punkt montowania /.
    • Nie używaj LVM, nie szyfruj, swap pomiń (lub utwórz później jako plik wymiany).
  • Dokończ instalację i zaloguj się.

Krok 2: Konfiguracja systemu

Wszystkie poniższe operacje wykonujemy w maszynie wirtualnej, przed skopiowaniem pliku VHD na pendrive.

Etykieta partycji głównej

Sprawdź, na której partycji znajduje się system plików root:

lsblk -f

Załóżmy, że jest to /dev/sda2. Nadaj jej etykietę:

sudo e2label /dev/sda2 VentUbuntu

Jeśli identyfikator partycji jest inny, podstaw odpowiedni.

Moduł dracut

Utwórz katalog modułu:

sudo mkdir -p /usr/lib/dracut/modules.d/99ventubuntu

Plik module-setup.sh:

sudo tee /usr/lib/dracut/modules.d/99ventubuntu/module-setup.sh > /dev/null << 'EOF'
#!/bin/bash
check()   { return 0; }
depends() { echo "rootfs-block"; return 0; }
installkernel() {
    # Wszystkie systemy plików spotykane na pendrive'ach Ventoy + loop dla losetup
    # exfat (domyślny w Ventoyu dla nośników większych niż 32 GB),
    # ntfs3 (sterownik NTFS wbudowany w jądro, z obsługą zapisu),
    # vfat (FAT16/32)
    hostonly='' instmods -c exfat ntfs3 vfat loop
}
install() {
    inst_hook initqueue/settled 10 "$moddir/ventubuntu-vhd.sh"
}
EOF
sudo chmod +x /usr/lib/dracut/modules.d/99ventubuntu/module-setup.sh

Główny skrypt — uruchamia się po udev settle, więc wszystkie urządzenia, które miały się pojawić, są już dostępne:

sudo tee /usr/lib/dracut/modules.d/99ventubuntu/ventubuntu-vhd.sh > /dev/null << 'EOF'
#!/bin/sh
# Jeśli system plików root jest już widoczny (np. rozruch w VirtualBox),
# nie podejmujemy żadnej akcji
[ -e /dev/disk/by-label/VentUbuntu ] && exit 0

# Skanujemy wszystkie urządzenia blokowe w poszukiwaniu pliku Ubuntu.vhd.
# Logika nie zależy od etykiety partycji, więc działa zarówno na czystym
# pendrivie Ventoy, jak i wtedy, gdy Ventoy został doinstalowany jako wtyczka
# do Easy2Boota (gdzie partycja ma swoją własną etykietę).
mkdir -p /mnt/Ventoy
for dev in $(blkid -o device); do
    fstype=$(blkid -s TYPE -o value "$dev" 2>/dev/null)
    case "$fstype" in
        exfat|vfat) ;;
        # blkid zwraca "ntfs" zarówno dla starego, jak i nowego sterownika;
        # wybieramy ntfs3 (wbudowany w jądro, z obsługą zapisu)
        ntfs)        fstype=ntfs3 ;;
        *)           continue ;;
    esac

    if mount -t "$fstype" "$dev" /mnt/Ventoy 2>/dev/null; then
        if [ -e /mnt/Ventoy/Ubuntu.vhd ]; then
            losetup -Pf /mnt/Ventoy/Ubuntu.vhd
            # need_shutdown wymusza pełne wyłączenie zamiast szybkiego restartu,
            # dzięki czemu zapisy do pliku VHD trafiają na pendrive
            need_shutdown
            exit 0
        fi
        umount /mnt/Ventoy
    fi
done
EOF
sudo chmod +x /usr/lib/dracut/modules.d/99ventubuntu/ventubuntu-vhd.sh

Warto zwrócić uwagę, że partycję Ventoy montujemy bez opcji -o ro — musi być w trybie zapisu, ponieważ jądro odmawia utworzenia urządzenia pętlowego w trybie zapisu z pliku znajdującego się na nośniku zamontowanym tylko do odczytu. Konsekwentnie utworzony tak loop device byłby read-only, a wraz z nim cały system plików root. Czystego zamknięcia broni mechanizm need_shutdown razem z hakiem sysrq opisanym poniżej.

Wymuszenie czystego zamknięcia (opcjonalne, ale zalecane)

Bez tego elementu istnieje ryzyko uszkodzenia pliku VHD przy wyłączaniu — initramfs-tools nie udostępnia standardowego sposobu na zamknięcie urządzeń loop, więc wymuszamy przejście systemów plików w tryb tylko do odczytu poprzez sysrq:

sudo tee /lib/systemd/system-shutdown/VentUbuntuVHD.shutdown > /dev/null << 'EOF'
#!/bin/sh
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
EOF
sudo chmod +x /lib/systemd/system-shutdown/VentUbuntuVHD.shutdown

Odtworzenie initrd

sudo dracut -f --regenerate-all

Jeżeli z jakiegoś powodu instalacja Ubuntu 26.04 nadal używa initramfs-tools (sprawdzenie: which dracut), zamiast powyższego polecenia użyj sudo update-initramfs -u -k all. Domyślnie jednak Ubuntu Server 26.04 korzysta z dracut.

Zamknięcie maszyny wirtualnej

sudo poweroff

Maszynę wirtualną należy zamknąć poprawnie — nie wystarczy zamknąć okna VirtualBox.

Krok 3: Wyłączenie nowych flag ext4 (obejście dla GRUB 2.04)

Ventoy w bieżącej wersji nadal dostarcza GRUB 2.04, który nie obsługuje dwóch flag systemu plików ext4 włączanych domyślnie przez nowsze wydania e2fsprogs: metadata_csum_seed (od Ubuntu 22.04) oraz orphan_file (od Ubuntu 24.04). W rezultacie GRUB Ventoya zgłasza „unknown filesystem” i nie potrafi odczytać /boot/vmlinuz z partycji root pliku VHD. Wsparcie tych flag pojawiło się dopiero w GRUB 2.12. System plików nadal jest poprawny — Linux go montuje bez zastrzeżeń — problem dotyczy wyłącznie bootloadera.

Obie flagi można usunąć poleceniem tune2fs, ale wymaga ono odmontowanego systemu plików, więc operację trzeba wykonać po uruchomieniu z innego nośnika. Najprościej:

  • W ustawieniach maszyny wirtualnej dodaj obraz ISO z Ubuntu Desktop (lub innej dystrybucji w trybie live) i ustaw rozruch z napędu optycznego przed dyskiem.
  • Uruchom maszynę i wybierz tryb „Try Ubuntu” (bez instalacji).
  • Otwórz terminal i wykonaj:
sudo tune2fs -O ^metadata_csum_seed,^orphan_file /dev/sda2
sudo e2fsck -fy /dev/sda2

Identyfikator partycji (/dev/sda2) podstaw zgodnie z układem dysku — w trybie live można sprawdzić lsblk -f. Po zakończeniu zamknij środowisko live, odepnij obraz ISO z maszyny wirtualnej i przejdź do kolejnego kroku.

Krok 4: Skopiowanie pliku VHD i konfiguracja Ventoya

Skopiuj plik VHD z katalogu VirtualBox na partycję Ventoy. Plik nazwij Ubuntu.vhd — celowo bez sufiksu .vtoy, ponieważ nie chcemy, aby Ventoy próbował obsłużyć go samodzielnie poprzez vtoyboot.

Utwórz katalog ventoy/ na partycji Ventoy (jeśli jeszcze nie istnieje), a w nim plik ventoy/ventoy_grub.cfg:

menuentry "Ubuntu Server 26.04 (VHD)" {
    loopback loop9 ${vtoy_iso_part}/Ubuntu.vhd
    search --no-floppy --label VentUbuntu --set vent_root
    linux  ($vent_root)/boot/vmlinuz root=LABEL=VentUbuntu ro net.ifnames=0
    initrd ($vent_root)/boot/initrd.img
}

Uwagi:

  • ${vtoy_iso_part} to zmienna ustawiana przez Ventoya, wskazująca na partycję, na której znajdują się obrazy. Działa zarówno na czystym pendrivie Ventoy, jak i wtedy, gdy Ventoy uruchamiany jest jako wtyczka do Easy2Boota — dzięki temu nie trzeba odwoływać się do etykiety partycji nośnika.
  • search --label VentUbuntu znajduje partycję po etykiecie nadanej w kroku 2, niezależnie od numeru partycji w pliku VHD. Jest to odporniejsze niż wpisanie (loop9,2) na sztywno — Ubuntu Server bywa kapryśny i potrafi przy manualnym partycjonowaniu dodać bios_boot lub osobny /boot, przez co rootfs trafia na partycję inną niż druga.
  • Wartość LABEL=VentUbuntu musi się zgadzać z etykietą nadaną poleceniem e2label w kroku 2.
  • /boot/vmlinuz oraz /boot/initrd.img to dowiązania symboliczne, które Ubuntu utrzymuje na bieżącą wersję jądra — przy aktualizacji jądra są aktualizowane automatycznie, więc plik ventoy_grub.cfg nie wymaga późniejszej edycji.
  • Ten sam plik ventoy_grub.cfg obsłuży rozruch zarówno przy uruchomieniu Ventoya pod Legacy BIOS (przez Easy2Boot), jak i pod UEFI (przez AGFM) — GRUB Ventoya w obu trybach wykona te same instrukcje i wyświetli to menu.

Jeżeli mimo wszystko search --label nie znajdzie partycji, najprawdopodobniej oznacza to, że system plików root znajduje się na woluminie LVM (GRUB nie umie wówczas odczytać etykiety bez wczytanego modułu LVM). W takim przypadku należy wrócić do instalacji i powtórzyć ją bez LVM.

Krok 5: Rozruch

Włóż pendrive Ventoy do docelowego komputera i uruchom z niego system. W menu Ventoya wciśnij F6, aby wejść w „Custom GRUB Menu” — tam pojawi się pozycja „Ubuntu Server 26.04 (VHD)”.

Aktualizacje i konserwacja

  • Aktualizacja jądra. Nie wymaga żadnych dodatkowych czynności. Polecenie apt upgrade odtwarza initrd, a hook jest częścią modułu dracut, więc trafia do każdego nowego initrd automatycznie.
  • Zmiana etykiety partycji lub układu. Należy zsynchronizować trzy miejsca: wynik e2label, parametr root= w pliku ventoy_grub.cfg oraz wartość LABEL= w skrypcie hook.
  • Test po aktualizacji jądra. Warto raz po aktualizacji uruchomić system z VHD w VirtualBoxie przed podłączeniem pendrive’a do fizycznej maszyny — jeżeli rozruch w maszynie wirtualnej działa, na fizycznym sprzęcie zwykle również zadziała.

Co celowo pominięto względem poradnika korkmana

Element u korkmanaPo co tam jestDlaczego tutaj niepotrzebne
Drugi plik VHD VentUbuntuBoot.vhd z osobnym /bootDla BIOS-ów widzących tylko pierwszą partycję pendrive’aNowoczesny UEFI nie ma tego ograniczenia; wystarczy jeden plik VHD
boot.automount w /etc/fstabPonieważ /boot znajduje się na osobnym pliku VHD, który trzeba podmontować/boot leży w obrębie systemu plików root i montuje się normalnie
chattr +i /boot, chattr +i /mnt/VentoyŻeby aktualizacje przypadkiem niczego tam nie zapisałyPrzy jednoplikowej instalacji takie ryzyko nie występuje
Przeniesienie montowania /mnt/Ventoy do systemu plików rootAby pendrive był widoczny w działającym systemieNiepotrzebne — system korzysta z własnego systemu plików root w VHD
Własny 07-VentUbuntu oraz update-grub w maszynie wirtualnejAby maszyna wirtualna uruchamiała się tym samym mechanizmemMaszyna wirtualna uruchamia się natywnie z ESP — nie korzysta z naszej konfiguracji GRUB-a
Partycja VentMore jako rezerwowaZ czasów, gdy Ventoy ograniczał pierwszą partycję do 32 GBOgraniczenie nieaktualne w nowych wersjach Ventoya

Potencjalne problemy

  • Secure Boot. Jeżeli komputer ma włączoną tę funkcję, mogą pojawić się problemy z uruchomieniem niepodpisanego jądra ładowanego „z boku” przez Ventoya. Należy wyłączyć Secure Boot w ustawieniach firmware albo użyć wersji Ventoya zgodnej z Secure Boot wraz z odpowiednio podpisanym shimem.
  • Dynamiczny VHD. Nie należy go używać. Ventoy obsługuje wyłącznie pliki VHD o stałym rozmiarze.
  • Plik VHD większy niż 4 GB na partycji FAT32. Jest to niemożliwe ze względu na ograniczenia samego FAT32. Jeśli pendrive Ventoy korzysta z FAT32, trzeba ograniczyć się do mniejszego pliku VHD lub przy okazji ponownej instalacji Ventoya sformatować nośnik na exFAT lub NTFS.
  • Stary sterownik ntfs (tylko do odczytu). Skrypt celowo wymusza wybór ntfs3. Można pozostawić zmienną fstype bez tej podmiany, ale wówczas zapis do pliku VHD nie będzie działał — w praktyce nie ma to sensu.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *