Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Zabawy z MBR - Instalacja Windows Server 2012 z Linuksa, na serwerze bez dostępu do BIOS'u, napędu CD ani USB

Kolega załapał się ostatnio na testy serwerów dedykowanych z nowym panele administracyjnym w homecloud.pl. Dzięki temu ja również miałem okazje zobaczyć ten panel i pobawić się serwerem :)

Są to serwery firmy Supermicro, ale panel jest wykonany przez home i wyszło im to świetnie! Home zawarło w nim kilka fajnych funkcji, takich jak uruchomienie serwera z obrazu ISO umieszczonego na zewnętrznym serwerze HTTP lub wybranego z listy preinstalowanych. Dostępny jest też bardzo fajny obraz rescue bazujący na Debianie, dzięki czemu, w razie awarii mamy pełny dostęp do dysku serwera i możemy naprawić znajdujący się na nim system.

Standardowy panel Supermicro też pozwala uruchomić serwer z obrazu ISO, jednak przekierowanie realizowane jest tylko i wyłącznie z komputera na którym uruchomiona jest konsola. W przypadku wolnego łącza, idzie to jak krew z nosa i powoduje (zbędne?) wkurzanie się na Jave w której napisana jest konsola.

Home rozwiązało to przy pomocy serwera PXE - serwer (klienta) podczas uruchamiania się odpytuje dostępne w sieci serwery DHCP o swoją konfiguracje. Serwer DHCP w odpowiedzi przesyła adres serwera TFTP oraz nazwę pliku znajdującego się na tym serwerze. Dedyk (serwer klienta) pobiera z tego serwera (home) plik (w przypadku homecloud jest to gPXE) a następnie go uruchamia. gPXE to kolejny agent PXE, ale ma on więcej funkcji niż ten wgrany na stałe w ROM karty sieciowej - tutaj najważniejsza jest obsługa HTTP. Dalej już właśnie po HTTP pobierany jest bootloader który pozwala na start z ISO czyli GRUB, kolejno właściwy obraz ISO i dopiero uruchamiany jest system operacyjny.

Niestety z tym rozwiązaniem jest jeden problem - po zbootowaniu nie jest możliwy dostęp do CD-ROMU, a niektóre systemy tego wymagają. Problem nie występuje z obrazami typu netinstall, do korzystania z których namawia nas panel, jednak niektóre systemy - tutaj Windows Server nie posiadają obrazów tego typu i wysypują się zaraz po starcie :(

W tym wpisie przedstawię jak udało mi się na tym serwerze zainstalować Windows Server 2012 korzystając z Debiana 7 oraz GRUB'a. Dostęp do BIOS'u serwera był zablokowany na hasło. Podłączenie napędu CD, albo pendrive także nie wchodziło w grę bez interwencji kogoś w serwerowni.

***

1. Zainstalowałem na serwerze Debiana 7 korzystając z dostępnego w panelu instalatora. System został zainstalowany tylko na pierwszym dysku, bez konfiguracji RAID'u.

2. Po instalacji wyzerowałem MBR na drugim dysku:

dd if=/dev/zero of=/dev/sdb bs=512 count=1

3. Utworzyłem na drugim dysku 1 partycje o rozmiarze 1GB i następnie sformatowałem ją w systemie plików NTFS (pod Debianem konieczna jest do tego instalacja pakietu ntfs-3g).

apt-get update apt-get install ntfs-3g cfdisk /dev/sdb mkfs -t ntfs /dev/sdb1

4. Przymontowałem uprzednio pobrany obraz ISO Windows Server 2012 oraz partycje /dev/sdb1.

mkdir /mnt/cd /mnt/sdb1 mount -t udf /root/plyta.iso /mnt/cd mount -r ntfs-3g /dev/sdb1 /mnt/sdb1

Płyty instalacyjne nowych Windowsów są sformatowane w nowszym formacie - UDF - ISO 13346, a nie typowym ISO 9960. Po przymontowaniu płyty w standardowy sposób (mount -t iso9660) zobaczymy tylko 1 plik z informacją nt. formatu płyty.

5. Przekopiowałem pliki z obrazu płyty na partycje sdb1:

cp -rv /mnt/cd/* /mnt/sdb1/

***

MBR to kod znajdujący się na samym początku dysku twardego, jeszcze przed partycjami, a dokładniej w pierwszym sektorze. Składa z 512 bajtów i określa rozmiar i pierwsze sektory 4 partycji podstawowych (tablica partycji znajdująca się na końcu) oraz zawiera kod rozruchowy (446 bajtów na samym początku). Kod rozruchowy wykonywany jest podczas startu komputera i to za jego pomocą ładowany jest system operacyjny.

VBR to kod znajdujący się na początku partycji. Również składa się z 512 bajtów. Pierwsza część NTFS VBR - 84 bajty, zawiera informacje specyficzne dla partycji - rozmiar sektora, ilość sektorów na klaster i ścieżkę, ilość głowic, sektorów, klastrów, identyfikator partycji itp. Po zmianie dokonanej w tej części NTFS VBR, partycja staje się niemożliwa do przymnotowania. W dalszej części znajduje się kod uruchamiający, podobny do tego z MBR.

Obecnie możliwe jest zawarcie kodu startowego w sektorze VBR partycji a następnie ustawienie dla tej partycji flagi boot (Windowsowe określenie to partycja aktywna), co spowoduje wykonywanie kodu z sektora VBR partycji podczas startu komputera. Wykorzystuje się to zamiast umieszczania kodu bezpośrednio w MBR.

Domyślnie po rekordzie VBR NTFS'a na partycji znajduje się jeszcze 14 wolnych sektorów. Właściwy system plików zaczyna się od 16 sektora. W tej wolnej części, jeśli partycja jest bootowalna, umieszcza się dalszą część kodu rozruchowego.

Tak właśnie jest z pendrive instalacyjnym Windowsa. Po skopiowaniu plików na pierwszą partycje pendrive z ustawioną flagą boot, uruchamia się program bootsect.exe znajdujący się na płycie, podając nazwę partycji na której ma być zapisany kod startowy. Na Linuksie nie jest to jednak możliwe, tak więc musiałem znaleźć inne wyjście.

Duuuuuużo więcej informacji nt. MBR'u, VBR'u i Assemblera można znaleźć na tej stronie: http://thestarman.pcministry.com/asm/mbr/index.html. Tutaj znajduje się opis rekordu VBR dla partycji NTFS: http://thestarman.pcministry.com/asm/mbr/NTFSBR.htm, a tutaj VBR wraz z kodem startowym dla Windows Vista: http://thestarman.pcministry.com/asm/mbr/VistaVBR.htm.

***

6. Na wszelki wypadek wykonałem kopię zapasową rekordu MBR dla drugiego dysku oraz VBR wraz z 14 kolejnymi pustymi sektorami dla pierwszej partycji tego dysku do plików w katalogu domowym:

dd if=/dev/sdb of=/root/mbr.bin bs=512 count=1 dd if=/dev/sdb1 of=/root/vbr.bin bs=512 count=15

7. Przy pomocy edytora heksadecymalnego dla Windowsa (HxD) wykonałem kopię sektora VBR oraz kolejnych sektorów w których znajdował się kod startowy z pendrive instalacyjnego Windowsa 8 do pliku i załadowałem go na serwer, a następnie nadpisałem tym plikiem sektor VBR i kolejne na partycji, ponownie nadpisałem konfigurację partycji znajdującą się w pierwszych 84 bajtach z kopii oryginalnego VBR (po poprzednim nadpisaniu została tam ta dla mojego pendrive) i sprawdziłem czy możliwe jest przymontowanie partycji:

dd if=/root/vbr_pendrive.bin of=/dev/sdb1 bs=512 count=15 dd if=/root/vbr.bin of=/dev/sdb1 bs=84 count=15 mount -t ntfs-3g /dev/sdb1 /mnt/sdb1 -- zadziałało :)

8. Teraz gdyby serwer nie miał założonego hasła na BIOS i ekran wyboru urządzeń (nie wiem jak to się dokładnie nazywa, chodzi mi o opcje boot device w trakcie startu komputera), możliwy byłby start komputera z tego dysku i instalacja systemu.

Musiałem więc dopisać do pliku konfiguracyjnego GRUB'a - Linuksowego bootloadera, odpowiednią opcje, tak aby mógł on uruchomić system z drugiego dysku.

Konfig GRUB'a w Debianie 7 znajduje się w /boot/grub/grub.cfg, jednak twórcy dystrybucji nie zalecają jego edycji i proponują dodawać nowe opcje do jakiegoś folderu w /etc a następnie skłądać to wszystkiego w grub.cfg przy pomocy jakiegoś polecenia. That's the proper way, ale ja po prostu dopisałem poniższy fragment do pliku, w sekcji 40_custom:

menuentry 'Instalator Windowsa' { set root='(hd1,msdos1)' chainloader +1 }

Dyski (w drugiej linijce) numerowane są od 0, więc hd1 to drugi dysk twardy, a hd0 to ten pierwszy na którym postawiłem Debiana. Partycje numerowane są już od 1, więc chodzi tutaj o pierwszą partycje drugiego dysku.

Po aktualizacji kernela pod Debianem, przestanie to, co prawda działać, ale było to i tak chwilowe rozwiązanie.

Pomocna była jeszcze zmiana czasu po jakim automatycznie wybierana jest pierwsza pozycja w menu (czyli Debian) i ładowany jest ten system. Domyślnie to 5 sekund. Odpowiada za to opcja:

set timeout=50 -- tutaj zamieniłem na 50 sekund

9. Po restarcie, na liście systemów w GRUB'ie znajdował się już odpowiedni wpis, ale nie mogłem się do niego dostać strzałkami. Serwery Supermicro mają z tym jakiś problem. Wygooglałem rozwiązanie polegające na zmianie ustawień konsoli w panelu Supermicro do którego nie miałem dostępu. Pomogło wywołanie z menu konsoli jViewer (której niestety home nie udało się unicestwić bo jest za bardzo powiązana ze sprzętem) polecenia: Options -> Keyboard Mouse Hotplug.

10. Dalej było już prosto - Windows zainstalował się jak z płyty.

(tak wiem że jest po polsku a tłumaczenie jest brzydkie, ale kolega wrzucił na serwer właśnie ten obraz)

11. Właśnie wtedy dotarło do mnie że wystarczyło nadpisać cały 2 dysk obrazem ISO:

dd if=/root/plyta.iso of=/dev/sdb

Jednak robiąc partycje instalacyjną prawidłowym sposobem dowiedziałem się czegoś na temat MBR i VBR więc i tak wrzucam ten wpis.

***

Do doebugowania bardzo pomocne było polecenie hd, dostępne domyślnie w Debianie. hd czyli hexdump wyświetla pliki i strumienie binarne w postaci heksadecymalnej i ASCII, podobnie jak typowe windowsowe hexedytory (choć to pewnie jest odwrotnie i hd był pierwszy).

Aby wyświetlić rekord MBR zapisany w pliku, a właściwie to jakikolwiek plik binarny w programie hd, wpisujemy:

hd /root/mbr_sdb.bin

A, żeby odczytać MBR bezpośrednio z dysku:

dd if=/dev/sdb bs=512 count=1 | hd 

windows linux serwery

Komentarze

0 nowych
  #1 13.12.2013 21:09

Cześć

Ciekawy tutorial, ja zastosowałem inną metodę żeby mieć windowsa na swojej licencji w hetzner niby jest tez gpxe ale nie dziłaja znaki / i : nie wiem czemu wiec nie można zmienic adresu do serwera http z obrazem. Ale ja rozwiązałem to inaczej a mianowicie tak: na komputerze z ubuntu postawiłem sobie virtualboxa z domyślnymi ustawieniami przy tworzeniu maszyny wirtualnej dla windowsa 7 x64 bit. Zainstalowałem system, włączyłem opcje pulpitu zdalnego i wyłaczyłem system. Następnie przekonwertowałem obraz dysku z wirtualką na format raw jest do tego specjalne narzędzie z virtualboxa.
Następnie na serwerze hetzner odpaliłem tryb rescue z debianem i utworzyłem partycje ext4 na dysku 2 i wgrałem na nią spakowany obraz dysku z virtualboxa. Następnie poleceniem dd odtworzyłem obraz na dysku nr 1 i dałem restart. Po restarcie uruchomił się system windows :)

  #2 13.12.2013 21:19

Zamienił stryjek siekierkę na kijek...

4lpha   10 #3 13.12.2013 22:13

okokok, nareszcie jakiś wpis :)
Czytałem z przyjemnością.

tomeeek64   10 #4 13.12.2013 22:15

Pomysłowe rozwiązanie. Ciekawe czy z wirtualnym serwerem dałoby się zrobić coś podobnego :)

okokok   12 #5 13.12.2013 22:56

tomeeek64, jak najbardziej jeśli mowa o wirtualizacji a nie parawirtualizacji. Wirtualizacja czyli coś jak HYPER-V Microsoftu, VMware albo XEN HVM. Wszystkie te hypervisory "emulują", choć to nie do końca dobre słowo, prawdziwego PC, z napędami, BIOS'em (mimo częstego braku setupu), normalnym startowaniem/bootowaniem itp. Parawirtualizacja to np. OpenVZ, Parallels Virtuozzo, XEN PV itp. Tutaj kernel jest wspólny, każdy VPS oraz system hosta korzysta z 1, więc kolejne VPS nie powodują takiego obciążenie zasobów jeśli nic nie jest na nim uruchomione poza samym systemem. Jeśli ten współdzielony kernel to kernel Linuksa to można podmieniać pliki systemowe (/) tylko pomiędzy wspieranymi dystrybucjami. Parawirtualizacja jest oczywiście dużo tańsza i dość popularna - np. VPS w homecloud.

roobal   15 #6 14.12.2013 11:06

Taki instalator można przygotować również przy użyciu, np. Unetbootin, tyle że partycja musi być sformatowana jako Ntfs, aby instalator Windowsa wystartował.

"Parawirtualizacja to np. OpenVZ, Parallels Virtuozzo, XEN PV itp."

W parawirtualizacji chodzi o to, że system operacyjny uruchomiony na serwerze, wie że nie działa bezpośrednio na fizycznym sprzęcie i się do niego nie odwułuje, wszystkie odwołania przekazuje do API hypervisora, Windows nie jest dostosowany do takiego rozwiązania, dlatego wymaga Xen HVM. Natomiast OpenVZ to wirtualizacja na poziomie systemu operacyjnego, tu systemu korzystają ze wspólnego jądra, w Xenie system gość korzysta z własnego jądra.

okokok   12 #7 14.12.2013 13:18

@roobal, Xenem się nie bawiłem i jakoś uznałem że musi być tak jak w OpenVZ :(

roobal   15 #8 14.12.2013 13:55

@okokok

Xenem nie trzeba się bawić, aby wiedzieć jak działa ;) W OpenVZ systemy zarówno gospodarz jak i goście korzystają z tego samego jądra, w Xenie system gospodarz i goście działają na tym samym sprzęcie, tyle że goście odwołują się do hypervisora, a nie bezpośrednio do sprzętu. Teraz przynajmniej znasz różnicę ;)

roobal   15 #9 14.12.2013 13:57

Różnicę też widać w ofertach hostingowych, niekiedy w ofertach VPS na Xen możesz dostrzeć opcję: pełny dostęp do iptables, bo gość działa właśnie z własnym jądrem, a nie współdzielonym, jak w openVZ.

okokok   12 #10 14.12.2013 14:05

@roobal, mogę więc na Xenie tworzyć własne urządzenia - mam na myśli ramdrive, /dev/tun, /dev/tap itp.? Jak wygląda startowanie? Rozumiem że Xen ładuje kernel kontenera, a nie żadnego Gruba, czy cokolwiek z 0x80?

grapeli23   5 #11 14.12.2013 23:43

Można bootować Linuxowy kernel bezpośrednio z MBR-a bez dodatkowego Bootloadera, typu Grub, Lilo, Syslinux, itd. Ten niewiarygodnie mały loader nazywa się - Minimal Linux Bootloader.

Dokładny i prosty opis jak tego dokonąć znajduje się tu.
http://sebastian-plotz.blogspot.com/

Ma to zasadniczą jedną wadę obraz kernela nie może być sfragmentowany. Druga mniejsza - komendy startowe mają ograniczoną długość. Z tym, że zawsze można dodać "wkompilować" je na stałe konfigurując kernel.
Sporo informacji jest też zwartych w dokumentacj kernela w pliku Documentation/x86/boot.txt

roobal   15 #12 15.12.2013 17:10

@okokok

System gość uruchomiony na Xenie działa tak, jakby był uruchomiony na fizycznym sprzęcie (oczywiście w przypadku parawirtualizacji - Xen PV) z tą różnicą, że system gość nie wysyła odwołań do sprzętu tylko do API hypervisora, a hiper nadzorca kontroluje całą resztę. Pod Xenem masz dostęp do iptables i innych rzeczy, które wspominasz. Co do startowania, Xen może korzystać z PyGrub.

Xen jest hiper nadzorcą pierwszego typu, czyli działa bez pośredników, VirtualBox czy VMWare Workstation to hipervisory drugiego typu, czyli do działania wymagają uruchomionego systemu operacyjnego i działają jako aplikacja. Załóżmy, że VirtualBox czy VMWare jest zainstalowany bezpośrednio na sprzęcie, tj. tak jakby był hyperwizorem pierwszego typu i uruchamia wirtualne maszyny, to na podobnej zasadzie działa Xen, a jeszcze podobniej Xen HVM.