Uruchamianie UML:
Do uruchomienia potrzebny jest plik z obrazem systemu plików. System plików można zbudować przy pomocy programu UML Builder (trzeba mieć własne płyty instalacyjne) lub pobrać z Internetu:
Należy przy tym pamiętać o podmienieniu modułów dla jądra (paragraf poprzedni) przed uruchomieniem maszyny wirtualnej na obrazie.
Jeżeli przy kompilacji zaznaczono opcję COW Device to jądro może pracować z obrazem bez jego modyfikowania ( patrz linux -help ). Modyfikowany jest jedynie plik pomocniczy. Pozwala to na uruchomienie kilku instancji wirtualnej maszyny UML na jednym obrazie plików.
Zasadniczym poleceniem uruchamiającym UML jest nazwa pliku binarnego wraz z argumentem - nazwą pliku emulującego system plików dla jądra:
damian@linux:~/UML/test/linux ubd0=root_fs
lub dla pracy w trybie COW: damian@linux:~/UML/test/linux ubd0=root_fs_cow,root_fs
Informacje o poleceniach przy uruchamianiu można znaleźć na stronie:
Jeżeli już na samym początku naszej przygody z jądrem nie będzie się chciało ono poprawnie uruchomić należy poprosić o dodatkowe informacje o błędach:
damian@linux:~/UML/test/linux ubd0=root_fs stderr=1
Dodatkowe informacje ze stderr pozwolą na lepsze zorientowanie się które polecenie w jądrze nie wykonuje się poprawnie.
Strony o UML gdzie można szukać pomocy:
Odpluskwianie UML:
Do odpluskwiania maszyny wirtualnej UML służy odpluskiwacz gdb. Używa się analogicznie jak przy odpluskwianiu innych programów. Odpluskwianie dla jądra pracującego w trybie TT oraz SKAS rozpoczyna się poleceniem:
damian@linux:~/UML>gdb linux
W uruchomionym gdb inicjujuje się wykonywanie programu:
(gdb) r ubd0=/home/damian/UML/root_fs_cow,/home/damian/UML/root_fs
W trybie TT odpluskiwanie można rozpocząć też poleceniem(uruchamia sesję gdb w oddzielnym oknie):
damian@linux:~/UML> %linux root_fs_cow,/home/damian/UML/root_fs debug
Jądro UML w trybie SKAS intensywnie używa sygnałów SIGSEGV oraz SIGUSR1. Aby zapobiec notorycznemu zatrzymywaniu się debuggera na tych sygnałach należy wydać gdb polecenia, które nakażą mu lekceważenie tych sygnałów:
(gdb) handle SIGSEGV pass nostop noprint
(gdb) handle SIGUSR1 pass nostop noprint
Trudno odpluskiwa się jądro skompilowane do pracy zarówno w trybie SKAS jak i TT. Wtedy odpluskiwacz gdb notorycznie zatrzymuje się na wywołaniu sygnału SIGTRAP:
(gdb) c
Program received signal SIGTRAP, Trace/breakpoint trap. 0xa000c000 in _start () at af_packet.c:1903 1903 }
(gdb)
Rozwiązaniem jest zdecydowanie się przy kompilacji tylko na jeden z powyższych trybów pracy.
Do jądra pracującego w trybie SKAS oraz TT pod kontrolą odpluskwacza można wysyłać sygnał za pomocą systemowego polecenia kill, który zostanie przechwycony przez gdb i spowoduje przerwanie wykonywania się jadra:
Praca w trybie TT - gdy procesy uruchamiane w maszynie wirtualnej mają swoje odpowiedniki na komputerze gospodarza - pozwala na odpluskwianie semaforów oraz zakleszczeń dzięki możliwości przełączenia się gdb pomiędzy procesami:
Odłączenie się od procesu:
(gdb) det
Przyłączenie się do podejrzanego procesu:
(gdb) att <pid w systemie gospodarza>
Przyglądanie się procesowi:
(gdb) bt
Powrót do pierwotnie odpluskwianego procesu
(gdb) att 1
Przykład dłuższej sesji z gdb znajduje się na stronie: