Ogólne

    NetBSD w OVH na dedykowanym serwerze

    OVH oferuje dedykowane serwery w przystępnych cenach, zwłaszcza z linii kimsufi. Przy okazji posiada ich tyle, że swego czasu zablokowali możliwość kupowania nowych, ponieważ klienci starszych maszyn nie przedłużali umów, tylko kupowali nowe maszyny za niższą cenę i z lepszymi parametrami.

    Nastał czas migracji jednej maszyny (Pentium III Xeon) z 2010 roku na nową (Core 2 Duo). I tu zaczynają się problemy, ponieważ w roku 2010 w OVH było coś takiego jak vKVM, czyli podłączone zasoby fizycznego serwera poprzez Qemu, z możliwością użycia dowolnego ISO i instalacji czego dusza zapragnie. Pomny takich możliwości, nowy serwer został zakupiony i przesiadka ze starego z funkcjonującym NetBSD i kilkoma usługami wydawał się banalna. Niestety OVH jakiś czas temu nie mówiąc nic nikomu zrezygnowała z vKVMa dając do dyspozycji dość szeroki wachlarz dystrybucji, niestety bez NetBSD.

    ovh1

    Muszę tu z uznaniem zauważyć, że od 2011 roku nie musiałem wchodzić do panelu zarządzającego, ponieważ system osiągnął imponujący uptime 1012 dni po czym padł mu zasilacz i musiał zostać wymieniony, tracąc cały uptime :)

         #               Uptime | System                                     Boot up
    ----------------------------+---------------------------------------------------
         1   1012 days, 07:06:5 | NetBSD 5.99.37            Thu Jul 21 08:36:46 2011
         2   216 days, 23:27:49 | NetBSD 5.99.37            Wed Dec  8 12:34:48 2010
         3    64 days, 16:47:53 | NetBSD 5.99.37            Sun Aug 15 20:59:35 2010
         4    30 days, 02:34:48 | NetBSD 5.99.37            Mon Nov  8 09:59:07 2010
         5    19 days, 20:31:45 | NetBSD 5.99.37            Tue Oct 19 14:18:21 2010
         6     7 days, 15:07:02 | NetBSD 5.99.37            Wed Jul 13 17:28:44 2011
         7     4 days, 05:54:32 | NetBSD 5.99.37            Wed Aug 11 14:31:49 2010
    ->   8     0 days, 00:03:21 | NetBSD 5.99.37            Tue Apr 29 09:02:03 2014
    ----------------------------+---------------------------------------------------
    1up in     4 days, 05:51:12 | at                        Sat May  3 14:56:35 2014
    no1 in   1012 days, 07:03:3 | at                        Sat Feb  4 15:08:55 2017
        up   1355 days, 19:34:0 | since                     Wed Aug 11 14:31:49 2010
      down     0 days, 22:59:33 | since                     Wed Aug 11 14:31:49 2010
       %up               99.929 | since                     Wed Aug 11 14:31:49 2010

    Wymiana zasilacza

    Oczywiście takie standardy jak Apache, MySQL, Postfix, Dovecot, BIND itp. można przenieść na dowolną instalację, ale jest zasadnicza różnica między przeniesieniem configów (dzięki bardzo poukładanemu filesystemowi NetBSD) a przeniesieniem i poprawieniem każdej jednej ścieżki. Dodatkowo czas gonił bo pierwszego maja stary serwer miał zostać wyłączony.

    Szczęśliwie OVH w razie padu systemu daje możliwość uruchomienia go w trybie rescue. Jest to tryb w którym system bootuje się z sieci, na maila dostajemy tymczasowe hasło roota, a wszystkie slice’y/partycje możemy sobie podmontować i sprawdzić co tam nie gra, względnie przenieść gdzieś dane i zaorać stary system nowym z listy.

    System rescue jest wystarczający do zainstalowania jakiegokolwiek innego systemu z ISO wg. własnych potrzeb. W przypadku *BSD mamy właściwie dwa sposoby. Pierwszy to odpalenie rescue w trybie freebsd (musi być zainstalowany najpierw jakiś FreeBSD z listy). W tym trybie dostajemy dostęp do partycji na obydwóch dyskach fizycznych z obsługą FFS2. Po założeniu partycji FFS i rozpakowaniu setów z ISO NetBSD (można użyć drugi dysk jako tymczasowe miejsce na ściągnięcie setów, ponieważ rescu jest w trybie do odczytu tylko), właściwie mamy działający system. Pozostaje kwestia bootloadera, którego z FreeBSD nie zainsytlujemy. FreeBSD nie ma binarnej kompatybilności z NetBSD (w drugą stronę taka kompatybilność istnieje).

    Niesprawdzony sposób to zrzucenie z innego NetBSD pierwszych 446 bajtów z bootowalnego dysku.

    dd if=/dev/wd0d of=/tmp/netbsd_boot.dump bs=446 count=1

    Dlaczego 446? Dlatego, że po wgraniu na inny dysk będzie tam tylko kod rozruchowy. Zrzucenie 512 bajtów zrzuca cały disklabel, który kiedy nie jest identyczny spowoduje sieczkę na dysku.

    dd if=/tmp/netbsd_boot.dump of=/dev/ada0s1 bs=446 count=1

    To powinno po restarcie poprawnie wybootować NetBSD z pierwszego dysku . Oczywiście trzeba pobawić się w „ślepą inżynierię” aby wykryć wszystkie urządzenia, nazwy interfejsów sieciowych i po ponownym wybootowaniu w trybie rescue, odpowiednio wyedytować pliki konfiguracyjne. Ja używałem do tego prostych skryptów uruchamianych z rc.local lub z crona po wybootowaniu i wpisujących wynik do pliku, np:

    @reboot         dmesg >> /root/dmesg.txt

    Drugim sposobem jest instalacja z ISO przy pomocy Qemu. W tym celu uruchamiamy rescue linuksowe. Jest to jakis zmodyfikowany Debian. Jeżeli dysponujemy ilością RAM około 4GB możemy sobie system przerzucić do RAMu i dodatkowo mieć ISO w RAM.

    mount -t tmpfs -o size=4000m tmpfs /mnt
    mkdir /mnt/var
     mkdir /mnt/var/cache
     mkdir /mnt/var/lib
     mkdir /mnt/var/run
     mkdir /mnt/usr
     mkdir /mnt/lib
    rsync -a /var/cache/ /mnt/var/cache/
     rsync -a /var/lib/ /mnt/var/lib/
     rsync -a /var/run/ /mnt/var/run/
     rsync -a /usr/ /mnt/usr/
     rsync -a /lib/ /mnt/lib/

    rsync chwilę potrwa.

    mount -B /mnt/var/cache /var/cache
     mount -B /mnt/var/lib /var/lib
     mount -B /mnt/var/run /var/run
     mount -B /mnt/usr /usr

    Voila! Mamy Linuxa w ramie w trybie RW.

    Ściągamy teraz najnowsze dostępne ISO gdzieś do /mnt

    cd /mnt && ftp -a ftp://ftp.fr.netbsd.org/pub/NetBSD/iso/6.1.4/NetBSD-6.1.4-amd64.iso
     (albo wget ftp://ftp.fr.netbsd.org/pub/NetBSD/iso/6.1.4/NetBSD-6.1.4-amd64.iso)

    Potrzebujemy jeszcze Qemu

    apt-get update
     apt-get install qemu

    Fajne jest to że OVH ma swój mirror repozytorium Debiana więc idzie to szybko. Dodatkowo serwer ftp NetBSD we francji chyba także jest w OVH :)

    2014-04-29 19:55:36 (10.8 MB/s) – `NetBSD-6.1.4-amd64.iso’ saved [347023360]

    Przygotowania skończone, uruchamiamy Qemu ze ściągniętym ISO i dyskiem fizycznym jako pierwszy dysk twardy:

    qemu-system-x86_64 -net nic -net user -m 1G -alt-grab -localtime  -k en-us -cdrom \
     /mnt/NetBSD-6.1.4-amd64.iso -hda /dev/sda  -vnc :0

    Jeżeli nie dostaniemy żadnych błędów w konsoli, znaczy się, że działa i możemy się zalogować na nasz IP w OVH przez VNC. Jeżeli instalujemy system 32 bitowy zamiast qemu-system-x86_64 uruchamiamy po prostu qemu.

    NetBSD bootuje się w OVH

    Instalacja NetBSD przez VNC

    Należy przeprowadzić standardową instalację, i wstępnie skonfigurować system do działania. Można np. spróbować skonfigurować wszystkie podstawowe karty sieciowe (wm,bge0,fxp0,re0 itp.), jeżeli trafimy w tą właściwą to po restarcie z dysku NetBSD powinien zacząć odpowiadać na ping. Oczywiście trzeba otworzyć ssh, dodać użytkownika albo pozwolić rootowi się logować. Mi udało się dostać do systemu za drugim podejściem. Pierwszy raz zrobiłem literówkę w bramie :) Ustawienia sieciowe oczywiście bierzemy z systemu rescue, są identyczne z normalnym systemem. W przypadku droższych serwerów może być jeszcze potrzeba zmiany w fstabie z emulowanego wd0 na rzeczywisty sd0. W moim przypadku, jako że serwer posiada dyski SATA, zarówno w Qemu jak i fizycznym NetBSD dyski widniały jako wd0.

    No i to tyle. Powyższy sposób z Qemu może być stosowany do każdego ISO, np. Windows Server czy dowolnej dystrybucji Linuksa. Do Windows 7 lub 2008 trzeba doinstalować jeszcze kvm (apt-get install kvm)

    Przy okazji na koniec mała dygresja, o tym jak szybko rynek reaguje na takie zmiany i braki jak zrezygnowanie z vKVM. Szukając informacji i materiałów odnoście tego zagadnienia natrafiłem na kilka stron które w przedziale 20$-35$ oferują instalację dowolnego lub z innej listy systemu operacyjnego – głównie Windows. Przykłady:

    http://winstaller.org/

    https://www.pozzo-balbi.com/products/custom-installation.

    A u mnie macie za darmo i po polsku ;)

    Podziękowania dla morr‚a za pomoc przy pierwszych próbach z instalacją bez Qemu :)

    BONUS: porównanie dmesga z maszyny w Qemu i fizycznego serwera po instalacji – http://maciejewski.org/temp/dmes_ovh_qemu_i_bm.txt

    VN:F [1.9.22_1171]
    Rating: 10.0/10 (1 vote cast)
    VN:F [1.9.22_1171]
    Rating: +1 (from 1 vote)
    Job / Praca

    Zdalna konsola, instalacja NetBSD i kreatywne lenistwo

    Dzisiaj instalowałem NetBSD na DELL’u Power Edge 2850 przez zdalną konsolę. Po zamontowaniu go w szafie i włożeniu płytki wróciłem do biurka. Instalacja bardzo standardowa, jednak pojawił się problem podczas restartu. Płyta została w środku i zamiast moja bootować moją świerzynkę, serwer cały czas startował z instalacją. No cóż, najprościej byłoby podejść do szafy, wyciągnąć płytę i ponownie go uruchomić. No ale po co się przemęczać, zwłaszcza jeśli obok stoi gorąca kawa i  świeże rogale świętomarcińskie. Załatwmy to po UNIXowemu ! :)

    1. DRAC w pełnej okazałości, serwer startuje (już jest po instalacji).

    VN:F [1.9.22_1171]
    Rating: 10.0/10 (1 vote cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    Job / Praca

    Upgrade AS/400

    Przyszły paczki (tak paczki!) aby wykonać upgrade AS400 do wersji 6.1. Może wydawać się to dość dziwne, ale upgrade odebrany od kuriera wygląda tak:

    Upgrade AS400 jeszcze zapakowany.
    Upgrade AS400 jeszcze zapakowany.

    Po rozpakowaniu okazuje się, że w większosći są to licencji i trochę płytek. Po rozpakowaniu obydwu paczek stos kartek i książeczek (wyjaśnienie do licencjonowania – książka ~100 stron :) przewyższała wysokość paczek w których przyszły :)

    Bałagan!
    Bałagan!

    Po odesparowaniu okazało się, że jeden upgrade to 16 płytek!

    Upgrade w całej okazałości
    Upgrade w całej okazałości

    Warto także wspomnieć o modelu biznesowym IBM’a (chyba tak to się poprawnie nazywa). Dwa upgrade’y dostaliśmy za symboliczne 120$, które to są kosztami logistycznymi (pakowanie, przechowywanie, wysyłka z USA). Właściwie mamy je za darmo w ramach maintenance. Dostaliśmy je także dlatego, że kończy się support na wersję 5.3 i minimum trzeba mieć wersję 5.4. Skok między 5.x a 6.x jest tak duży, że w przypadku upgrade’u trzeba przejść całą ścieżkę stąd dwa upgrade’y. Jeśli natomiast ktoś jest tak zaawansowanym adminem AS’a (lub iSeries, lub i5 – OS name madness ;), że poradzi sobie bez maintenance i po kilku latach zdecyduje się na upgrade i chciałby go kupić (tak jak się kupuje inne systemy w pudełku) to nie ma takiej mozliwości. Nie ma maintenance – nie ma upgrade’u. Ok, można wykupić sobie maintenance zatem, ale trzeba zapłacić wszystkie lata wstecz także! I dlatego IBM to największa i najbogatsza firma produkująca hardware/software na świecie :) Nie wspominam już o cenach mainenance i sprzętu do AS’a….

    Z drugiej strony instalacja od zera AS’a to święto Administratora, nie często się to zdarza :)




    VN:F [1.9.22_1171]
    Rating: 0.0/10 (0 votes cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    Job / Praca

    NetBSD 5.0 na Netrze T1-200

    W końcu przyszły! Dwie Netry T1-AC200 z allegro. Jak widać na stronie SUN’a (lub ORACLE’a za jakiś czas :) sprzęt co kolwiek stary, ale wciąż jary. Po pierwsze 1U, po drugie niska cena (249 zł za sztukę), po trzecie architektura SPARC, po czwarte hardcoreowy 1337 sprzęt dla geeków^W niezawodna maszyna dla administratorów. W sam raz na jeden mały serwis www do uzytku wewnętrznego + dodatkowa Netra do testów i poznania Solarisa. Słowo wyjaśnienia odnośnie hardcorowości tego sprzętu. Nie mamy możliwości podłączenia monitora, klawiatury (ewentualnie USB), nie ma karty graficznej. Wszystko co dostajemy to dwa porty sieciowe, dwa konsolowe, dwa USB i jeden zewnętrzny SCSI. Na szczęście jest także LOM czyli Lights Off Management do którego dostajemy się poprzez port szeregowy z innego komputera specjalnym kablem RS232< ->RJ45. Kabelek ten pasuje od urządzeń CISCO, lub można go zrobić samemu (koszt kitowej wtyczki RS232 z wyprowadzonymi kablami do zlutowania to 12 zł a schemat jest tu). Dla leniwców SUN przewidział promocje – 500 zł netto za oryginalny kabel ;). Generalnie podłączenie się do LOM to najmniejszy problem. Wystarczy jakiś komputer z terminalem. Ja wykorzystałem NetBSD i minicoma. Ustawiłem odpowiedni port szeregowy oraz jego prędkość (9600 8N1 oraz kontrola parzystości) i po Initializing Modem zgłosił się LOM. Polecam zapoznanie się z tym artykułem na początek. Czas na właściwa instalację. Tutaj zaczynają się schody. Można użyć zewnętrznego napędu SCSI, ale akurat takiego nie posiadałem (allegro też nie specjalnie ma takie rzeczy) pozatym przydałby się raz i koniec. Z zewnętrznego napędu USB Netry niestety nie da się wybootować. Pozostała ostatnia możliwość czyli netboot NetBSD z innej maszyny NetBSD. I tu zaczyna się właściwa część tego posta, a jeśli kiedyś będziesz mieć przyjemność instalacji tego typu to zgodzisz się ze mną że T1 jest hardcoreowa :)

    Potrzeba będzie nam kilku rzeczy. rarpd, tftp, dhcp i bootp używany z dhcp oraz nfs. Dodatkowo NetBSD/sparc64.

    Netrę podłączamy do sieci oraz do konsoli i szukamy adresu MAC pierwszej karty sieciowej. Jeśli jesteśmy w ok to wydajemy polecenie banner i rezultacie dostajemy to czego szukamy:

    ok banner
    Netra T1 200 (UltraSPARC-IIe 500MHz), No Keyboard
    OpenBoot 4.0, 1024 MB memory installed, Serial #401376.
    Ethernet address 0:3:ba:6:1f:e0, Host ID: 83061fe0.

    Jeśli jesteśmy w lom wydajemy polecenie power-on aby przejść do ok. Podczas startu Netry wysyłamy sygnał break (w minicomie CTRL+A F) aby maszyna nie zbootowała się dalej jeśli ma zainstalowany system i ostatecznie jesteśmy w ok i dajemy banner. Jeśli nie wiesz o czym piszę to znaczy że nie odrobiłeś lekcji z akapitu powyżej i nie przeczytałeś o co chodzi w LOM i jego trybach pracy :)

    Chwilowo Netrę zostawiamy i zajemiemy się środowiskiem w NetBSD potrzebnym do sieciowego wybootowania NetBSD na Netrze.

    Zaczynamy od rarpd czyli reverse ARP. Będzie on potrzebny do nadania IP na podstawie MAC którego chwilę wcześniej zdobyliśmy.

    Na NetBSD dopisujemy następujące rzeczy do następujących plików:

    /etc/ethers
    0:3:ba:6:1f:e0 netra

    /etc/hosts
    10.1.0.8 netra netra.

    Uruchamiamy poleceniem rarpd -a -d dzięki czemu rarpd nie forknie się nam do backgroundu i będziemy widzieć czy coś się z nim komunikuje. Adres IP oczywiście w/g własnych potrzeb. Mój NetBSD ma akurat 10.1.0.6 więc Netra będzie miała 10.1.0.8.

    Następnie konfigurujemy tftp czyli Trivial File Transfer Protocol. Tutaj jest trochę zabawy.

    Tworzymy po pierwsze katalog dla plików potrzebnych do podania przez TFTP:

    mkdir /tftpboot

    Linkujemy lub kopiujemy bootloader z dystrybucji NetBSD/sparc64 zmieniając nazwę na IP Netry zapisanej w hex’ie czyli szesnastkowo :) Czyli:

    Po ściągnięciu z ftp.netbsd.org/pub/NetBSD/NetBSD-5.0/sparc64/ kopiujemy bootloader do katalogu dostępnego dla tftp:

    cp /usr/home/cancer/sun/sparc64/installation/netboot/ofwboot.net /tftpboot

    Przeliczamy wybrany IP Netry na hex używając np bc
    bc
    obase=16
    10
    A
    1
    1
    0
    0
    8
    8

    Czyli 10.1.0.8 = 0A108

    Linkujemy ofwboot.net jako IPHEX. Gwoli wyjaśnienia – miałem dziwne problemy z tftpd i podczas debugowania dodałem dodatkowe zera do IP w HEX dlatego są dwa podlinkowania w moim katalogu. Ostatecznie nie wiem który zadziałał ale powinny obydwa :)

    ls -la /tftpboot/
    total 19240
    lrwxr-xr-x 1 root wheel 11 May 19 11:03 0A010008 -> ofwboot.net
    lrwxr-xr-x 1 root wheel 11 May 19 11:01 0A108 -> ofwboot.net
    -rw-r--r-- 1 root wheel 85249 May 19 10:15 ofwboot.net

    Kiedy mamy już przygotowany tftp możemy go uruchomić. Tutaj nastąpiła rzecz dziwna ponieważ whereis tftpd zwracało nic, a komenda tftpd oznajmiała tftpd: Command not found mimo że jak wół tftpd jest w basesystemie:

    ls -la /usr/libexec/tftpd
    -r-xr-xr-x 1 root wheel 23216 Feb 21 2008 /usr/libexec/tftpd

    tftpd uruchamiamy z inetd.conf odhashowując odpowiednią linijkę:
    tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpboot

    Musiałem lekko zmodyfikować dając pełną scieżkę:
    tftp dgram udp wait root /usr/libexec/tftpd /usr/libexec/tftpd -l -s /tftpboot

    Ostatecznie po którymś restarcie zadziałało mimo tego że kiedy widać było tftpd w procesach to Netra się nie chciała dogadać, kiedy w procesach tftpd nie było (po restarcie inetd) Netra nagle zaczęła się bootować. Nie wiem czy to akurat moja dolegliwość czy ogólnie NetBSD 4.0_STABLE. Zakładając, że rarpd i tftp jest ok, możemy wybootować Netrę dla testu.

    ok boot net
    Boot device: /pci@1f,0/pci@1,1/network@c,1 File and args:
    Using Onboard Transceiver - Link Up.
    18c00
    Server IP address: 10.1.0.6
    Client IP address: 10.1.0.8
    >> NetBSD/sparc64 OpenFirmware Boot, Revision 1.13
    Using Onboard Transceiver - Link Up.
    bootp: no reply
    Using BOOTPARAMS protocol: ip address: 10.1.0.8bootparamd: 'whoami' call failed
    open netbsd: Unknown error: code 60
    Failed to load 'netbsd'.
    : trying netbsd.gz...

    Najważniejszą informacją jest, że boot loader został pomyślnie wczytany. Błędem że bootp nie odpowiada nie przejmujemy się na razie, za chwilę go ustawimy. W logach rarpd powinno być mniej więcej coś takiego:

    rarpd: 00:03:ba:06:1f:e0 asked; netra replied

    Zapamiętać! architektura sparc64 używa dhcpd z bootp a nie samo bootp :) Godzina zaoszczędzona na bezskuteczne i dziwne skonfigurowanie bootp.

    Tworzymy konfig dhcp dla naszych potrzeb:

    /etc/dhcpd.conf
    deny unknown-clients;
    ddns-update-style none;
    allow bootp;

    subnet 10.1.0.0 netmask 255.255.255.0 {
    }

    group {
    option broadcast-address 10.1.0.255;
    option domain-name "test.net";
    option domain-name-servers 10.1.0.1;
    option routers 10.1.0.251;
    option subnet-mask 255.255.255.0;

    host netra {
    hardware ethernet 00:03:ba:06:1f:e0;
    fixed-address 10.1.0.8;
    option host-name "netra";
    filename "netbsd-INSTALL.gz";
    next-server 10.1.0.6;
    option root-path "/export/netra/root";
    }
    }

    Odpalamy dhcpd uprzednio tworząc plik /var/db/dhcpd.leases

    touch /var/db/dhcpd.leases
    /usr/sbin/dhcpd -d -f

    dyrektywa filename mówi jaki kernel ma załadować bootloader, chcemy kernel instalacyjny którego sciagamy z
    ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-5.0/sparc64/binary/kernel/netbsd-INSTALL.gz i umieszczamy tam gdzie jest root katalog w nfs czyli w /export/netra/root. Dyrektywa next-server 10.1.0.6 mówi gdzie jest serwer nfs, reszta opcji raczej jasna.

    Jeszcze Netry nie startujemy bo nie mamy skonfigurowanego NFS’a.

    Tworzymy strukturę katalogów i kopiujemy nasz instalacyjny kernel do odpowiedniego katalogu:

    mkdir -p /export/netra/root/dev
    mkdir /export/netra/usr
    mkdir /export/netra/home
    touch /export/netra/swap
    cp netbsd-INSTALL.gz /export/netra/root
    mknod /export/netra/root/dev/console c 0 0

    dodajemy wpisy do /etc/exports

    /etc/exports
    /export/netra/root -maproot=root:wheel netra
    /export/netra/swap -maproot=root:wheel netra
    /export/netra/usr -maproot=nobody:nobody netra
    /export/netra/home -maproot=nobody:nobody netra

    dodajemy do /etc/rc.conf komponenty NFSa:

    /etc/rc.conf
    rpcbind=YES
    mountd=YES
    nfsd=YES

    i startujemy go:

    /etc/rc.d/rpcbind start
    /etc/rc.d/mountd start
    /etc/rc.d/nfsd start

    Warto sprawdzić czy wszystkie komponenty zostały uruchomione, aby potem nie szukać błędu podczas bootowania. Kolejność uruchamiania jest dość ważna.

    Ok, jeśli mamy wszystko. Działający rarpd, tftp, dhcpd z bootp i nfsd mountd i rpcbind oraz odpowiednie prawa do wszystkiego – możemy spróbować kompletnie wybootować Netrę! Go!

    ok boot net
    Boot device: /pci@1f,0/pci@1,1/network@c,1 File and args:
    Using Onboard Transceiver - Link Up.
    18c00
    Server IP address: 10.1.0.6
    Client IP address: 10.1.0.8
    >> NetBSD/sparc64 OpenFirmware Boot, Revision 1.13
    Using Onboard Transceiver - Link Up.
    Using BOOTP protocol: ip address: 10.1.0.8, hostname: netra, netmask: 255.255.21
    root addr=10.1.0.6 path=/export/netra/root

    =0x8573d8
    Loading netbsd: 6935248+357272+439736 [522792+334504/

    I tu następują już znane komunikaty kernela. Jeśli na samym początku jest:

    NetBSD 5.0 (INSTALL) #0: Mon Apr 27 08:27:44 UTC 2009

    to znaczy, że jeśli hardware się nie wywali to za kilka sekund ujżymy upragnione:

    Welcome to sysinst, the NetBSD-5.0 system installation tool.

    Instalacja jest prawie taka sama jak na i386/amd64. Po ostatecznym zbootowaniu mamy gotowy system!

    uname -mrs
    NetBSD 5.0 sparc64

    Kilka uwag na koniec:

    1. Jeśli podczas bootowania kernel/system nie odpowiada, można wysłać mu breaka, wtedy jednak zamiast wrzucić nas do ok znajdziemy się w debugerze db>. po wydaniu reboot Netra zawieszała się na amen i tylko twardy reset a właściwie cold boot pomagał. Dlatego trzeba rebootować z opcją 0x4 co powoduje brak syncowania dysków i restart do lom.

    2. Chwilę przed wejściem do sysinstalla jest pytanie o typ klawiatury, trzeba wybrac sun-type4 a nie sun, ponieważ nie będą działały kursory. Instalacja jednak jest nadal możliwa używając literałów jako skrótów opcji.

    3. NetBSD na architekturze sparc64 nie zbootuje się z FFS2, dlatego chociaż / musi zostać jako FFS1, reszta partycji może być FFS2.

    4. Zmiana kernela z INSTALL na zwykły oraz rozpakowanie setsów do odpowiedniego miejsca w /export/netra/ oraz drobne modyfikacje rc.conf i swapa (tych w export) przy powyższej konfiguracji zaskutkuje stworzeniem bezdyskowej stacji roboczej. Zmiana setsów na i386 lub amd64 pozwoli uruchomić bezdyskową stację na zwykłym PC :)

    W razie problemów do dyspozycji macie komentarze oraz IRC – #netbsd.pl – nick cancer. Podziękowania dla lamy i morra za cenne wskazówki podczas uruchamiania netboota :)

    Na koniec dmesg z świeżo odpalonej Netry:

    Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,
    2006, 2007, 2008
    The NetBSD Foundation, Inc. All rights reserved.
    Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California. All rights reserved.

    NetBSD 5.0 (GENERIC) #0: Mon Apr 27 08:13:38 UTC 2009
    builds@b4.netbsd.org:/home/builds/ab/netbsd-5-0-RELEASE/sparc64/200904260229Z-obj/home/builds/ab/netbsd-5-0-RELEASE/src/sys/arch/sparc64/compile/GENERIC
    total memory = 1024 MB
    avail memory = 991 MB
    timecounter: Timecounters tick every 10.000 msec
    mainbus0 (root): SUNW,UltraAX-i2 (Netra T1 200): hostid 83061fe0
    cpu0 at mainbus0: SUNW,UltraSPARC-IIe @ 500 MHz, UPA id 0
    cpu0: 32K instruction (32 b/l), 16K data (32 b/l), 1024K external (64 b/l)
    psycho0 at mainbus0
    psycho0: SUNW,sabre: impl 0, version 0: ign 7c0 bus range 0 to 2; PCI bus 0
    psycho_alloc_extent: no "available" property
    psycho_alloc_extent: no "available" property
    DVMA map: c0000000 to e0000000
    IOTSB: 11d0000 to 1250000
    pci0 at psycho0
    pci0: i/o space, memory space enabled
    ppb0 at pci0 dev 1 function 1: Sun Microsystems Simba PCI bridge (rev. 0x13)
    pci1 at ppb0 bus 1
    pci1: i/o space, memory space enabled
    ebus0 at pci1 dev 12 function 0
    ebus0: Sun Microsystems PCIO Ebus2 (US III), revision 0x01
    flashprom at ebus0 addr 0-fffff not configured
    clock0 at ebus0 addr 0-1fff: mk48t59
    ebus_attach: idprom: incomplete
    SUNW,lomh at ebus0 addr 200000-200003 ipl 42 not configured
    alipm0 at pci1 dev 3 function 0: 74KHz clock
    iic0 at alipm0: I2C bus
    spdmem0 at iic0 addr 0x54
    spdmem0: SDRAM memory, data ECC, 512MB, 133MHz (PC-1100)
    spdmem0: 13 rows, 11 cols, 1 banks, 4 banks/chip, 7.5ns cycle time
    spdmem0: tAA-tRCD-tRP-tRAS: 3-20-20-45
    spdmem0: voltage LvTTL (not 5V tolerant), refresh time 7.8us (self-refreshing)
    spdmem1 at iic0 addr 0x55
    spdmem1: SDRAM memory, data ECC, 512MB, 133MHz (PC-1100)
    spdmem1: 13 rows, 11 cols, 1 banks, 4 banks/chip, 7.5ns cycle time
    spdmem1: tAA-tRCD-tRP-tRAS: 3-20-20-45
    spdmem1: voltage LvTTL (not 5V tolerant), refresh time 7.8us (self-refreshing)
    admtemp0 at iic0 addr 0x18: ADM1021 or compatible environmental sensor
    ebus1 at pci1 dev 7 function 0
    ebus1: Acer Labs M1533 PCI-ISA Bridge, revision 0x00
    dma at ebus1 addr 0-ffff ipl 1 not configured
    power at ebus1 addr 2000-2007 ipl 37 not configured
    com0 at ebus1 addr 3f8-3ff ipl 43: ns16550a, working fifo
    com0: console
    com1 at ebus1 addr 2e8-2ef ipl 43: ns16550a, working fifo
    gem0 at pci1 dev 12 function 1: Sun Microsystems ERI Ethernet (rev. 0x01)
    gem0: interrupting at ivec 3006
    ukphy0 at gem0 phy 1: Generic IEEE 802.3u media interface
    ukphy0: OUI 0x0008bb, model 0x0002, rev. 1
    ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
    gem0: Ethernet address 00:03:ba:06:1f:e0, 2KB RX fifo, 2KB TX fifo
    ohci0 at pci1 dev 12 function 3: Sun Microsystems USB controller (rev. 0x01)
    ohci0: interrupting at ivec 24
    ohci0: OHCI version 1.0, legacy support
    usb0 at ohci0: USB revision 1.0
    aceride0 at pci1 dev 13 function 0
    aceride0: Acer Labs M5229 UDMA IDE Controller (rev. 0xc3)
    aceride0: bus-master DMA support present
    aceride0: primary channel configured to native-PCI mode
    aceride0: using ivec 180c for native-PCI interrupt
    atabus0 at aceride0 channel 0
    aceride0: secondary channel configured to native-PCI mode
    atabus1 at aceride0 channel 1
    gem1 at pci1 dev 5 function 1: Sun Microsystems ERI Ethernet (rev. 0x01)
    gem1: interrupting at ivec 301c
    ukphy1 at gem1 phy 1: Generic IEEE 802.3u media interface
    ukphy1: OUI 0x0008bb, model 0x0002, rev. 1
    ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
    gem1: Ethernet address 00:03:ba:06:1f:e0, 2KB RX fifo, 2KB TX fifo
    ohci1 at pci1 dev 5 function 3: Sun Microsystems USB controller (rev. 0x01)
    ohci1: interrupting at ivec 26
    ohci1: OHCI version 1.0, legacy support
    usb1 at ohci1: USB revision 1.0
    ppb1 at pci0 dev 1 function 0: Sun Microsystems Simba PCI bridge (rev. 0x13)
    pci2 at ppb1 bus 2
    pci2: i/o space, memory space enabled
    esiop0 at pci2 dev 8 function 0: Symbios Logic 53c896 (ultra2-wide scsi)
    esiop0: using on-board RAM
    esiop0: interrupting at ivec 1820
    scsibus0 at esiop0: 16 targets, 8 luns per target
    esiop1 at pci2 dev 8 function 1: Symbios Logic 53c896 (ultra2-wide scsi)
    esiop1: using on-board RAM
    esiop1: interrupting at ivec 1820
    scsibus1 at esiop1: 16 targets, 8 luns per target
    pcons at mainbus0 not configured
    timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0
    timecounter: Timecounter "tick-counter" frequency 500000000 Hz quality 100
    No counter-timer -- using %tick at 500MHz as system clock.
    scsibus0: waiting 2 seconds for devices to settle...
    scsibus1: waiting 2 seconds for devices to settle...
    uhub0 at usb0: Sun Microsystem OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
    uhub0: 4 ports with 4 removable, self powered
    uhub1 at usb1: Sun Microsystem OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
    uhub1: 4 ports with 4 removable, self powered
    sd0 at scsibus0 target 0 lun 0: disk fixed
    sd0: 17274 MB, 7508 cyl, 19 head, 248 sec, 512 bytes/sect x 35378533 sectors
    sd0: sync (25.00ns offset 31), 16-bit (80.000MB/s) transfers, tagged queueing
    Kernelized RAIDframe activated
    root on sd0a dumps on sd0b
    root file system type: ffs




    VN:F [1.9.22_1171]
    Rating: 10.0/10 (1 vote cast)
    VN:F [1.9.22_1171]
    Rating: 0 (from 0 votes)
    Related Posts with Thumbnails

    © odwiedź stronę http://maciejewski.org po więcej fajnych postów!

    Add your widget here