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.
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 :)
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
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.
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.
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.
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 :)
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.
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:
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).
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:
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 :)
Po odesparowaniu okazało się, że jeden upgrade to 16 płytek!
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 :)
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:
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
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.
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:
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