Arra gondoltam, hogy nekilátok és összerakok egy RHCSA-RHCSE anyagot. Azonban nem tudom, hogy van-e olyan ember, akit itt érdekelhet a dolog, mert fölöslegesen nem tölteném vele az időt.

Ami biztos nem lesz benne:

- Hogyan néz ki a vizsga
- Milyen feladatok voltak
- pm-ben válasz a kérdésekre (topicban többen is tudnak válaszolni)

Ha valakit érdekel, akkor a fórumba jelezze.

HD7750

+ keveset fogyaszt
+ kicsi, akar teljesen passzivva is teheto
- Ma meg eleg, de mi lesz fel ev mulva?
- ar/teljesitmeny nem tul fenyes, 28k

HD7770

+ fogyasztasa jo, nem melegszik
+ cca 25%-al erosebb, mint a 7750
- 10-15%-al elmarad az 5850-hez kepest
- A teljesitmenyehez kepest draga, legolcsobb helyen is 38k

HD5850

+olcso 33k
+ erosebb, mint a masik ketto
- fogyasztas
- Nem vacsi uj garival, mint a masik ketto

Ti melyiket valasztanatok?

DOS alatt az IP stacket maguk a programok tartalmazzák. Persze a hardvert már akkor sem direktben hajtották meg. A drivereknek valamilyen egységes felületet kellett biztosítaniuk. A legismertebb talán az ODI, amit a legjobban elterjedt Netware használt. A 3COM 589-hez sikerült is letölteni, igaz Dell-nek álcázta magát:

[link]

A net.cfg-be négy sor kell csak:

Link Support
buffers 8 1600
Link Driver 3C574
Frame Ethernet_II

A driver mellé kell egy Netware kliens, pontosabban abból az lsl.com. Ugyan a Netware DOS kliens nem támogatott, de azért még elérhető:

[link]

A Packet driver már kevésbé támogatott, de szerencsére van megoldás. Az ODIPKT segítségével máris megvan a packet driver. Az arachne böngésző szerencsére tartalmazza, ezért nem kellett keresgélni. Az arachne innen tölthető le:

[link]

A darabokat már csak össze kell legózni. Az összeset ( lsl, 3c589 a net.cfg-vel és a odpkt ) bemásoltam a c:\net könyvtárba. Az autoexec-ben a megfelelő sorrendben betöltöm a TSR-ket:

Teli van a hócipőm az AMD driverekkel. Egyszerűen ami ment két driverrel korábban, most fagy, minha Sziberiában írták volna. A 11.12 -es, más néven a 8.92-es fglrx-et raktam fel egy RHEL WS 6.1-re. Érdekes módon nem kellett vele küzdeni, szó nélkül elkészítette az rpm csomagot. A dkms is rögtön ment, ahogy az aktuális kernelhez felkerült a header csomag. Az már csak hab a tortán, hogy nem mem leakel és az X screensavert is tolerálja.

Persze előre teáztam a sikerre...

Ha a dokkban altatom a gépet és a felélesztés nem ott történik, akkor eldobja magát az X. Ez visszafelé is igaz, tehát csak a laptop kijelzőjével altatva (suspend to memory) képtelen feltápászkodni. Az X Window a libglx.so betöltése után a következővel szórakoztat az Xorg logban:

Segmentation fault at address 0x9ab000

Fatal server error:
Caught signal 11 (Segmentation fault). Server aborting

Ez mind semmi, mert nagyon szép karaktereket villogtat altatás és ébresztés közben is a kijelzőn. Kipróbáltam pár dolgot, de csak a dual screen letiltása segít, tehát ha nem venném ki a dokkolóból a gépet, akkor nem lenne gond. De akkor mire való a laptop?

1. ubuntu szerver letöltése
2. minimal telepítés

Az ezt követő parancsokat egy root shell-ben futtattam. Persze lehet saját könyvtárbatelepíteni, akár jail-be, de most maradtam az egyszerű megoldásnál:

sudo bash

Frissítés, xorg, fglrx

apt-get update
apt-get dist-upgrade
apt-get install xorg dbus alsa-base
apt-get install fglrx
aticonfig --initial

XBMC fordítás előkészítése

apt-get install python-software-properties
add-apt-repository ppa:team-xbmc/unstable

Mivel az oneiric nincs még a listán, ezért érdemes átírni natty-ra a targetet:

/etc/apt/sources.list.d/team-xbmc-unstable-oneiric.list

apt-get build-dep xbmc
apt-get install libva-dev

XBMC fordítása

git clone git://github.com/xbmc/xbmc.git
cd xbmc
./bootstrap
./configure

Ha a lGL-re panaszkodik, akkor a libGL.so nem jó helyre van linkelve:

sudo rm /usr/lib/libGL.so; sudo ln -s /usr/lib/fglrx/libGL.so /usr/lib/libGL.so;./configure

make -j 2
make install

Automatikus indulás

Mielőtt végső állomáshelyére vezényelném az Asrock 350M1 alapú HTPC szerkezet pár Windowsüos tesz:

OS Win7 Home Prof x64
Mem: 2G DDR3 1333, amibol 512MB-ot eszik meg az IGP

SuperPI 1.5 1M:

1333MHz

00m 48.860s

1066MHz

50.42s

Winrar 4.0 benchmark

1333MHz

Multithreading off: 269kB/s
Multithreading on: 498kB/s

1066MHz

Multithreading off: 248kB/s
Multithreading on: 472kB/s

1333MHz Cinebench 11.529

32 bit
GPU: 8.13 fps (Ref Match 99.3%)
CPU 1 thread: 0.29 pts
CPU 2 threads:0.47 pts

x64
GPU: 8.22 fps (Ref Match 99.3%)
CPU 1 thread: 0.28
CPU 2 threads: 0.49pts

x64 1066MHz:

GPU: 7.52 fps (Ref Match 99.3%)
CPU 1 thread: 0.27
CPU 2 threads: 0.45pts

Szeretem tudni, hogy milyen meleg uralkodik a gépben, az OS Ubuntu 11.04 Beta, avagy Natty. A merevlemezt a smart daemon figyeli, ami szerint 32 Celsius fokos a lemez, ami nem csoda egy 23 cm-es ventilátor mellett. Az alaplapot elvileg az lm-sensors csomaggal lehet figyelni, csak éppen nem talál hozzá drivert. Szerencsére tippet ad, hogy hol érdemes utána nézni:

Driver `to-be-written':
* ISA bus, address 0x290
Chip `Nuvoton W83677HG-I (NCT6771F/NCT6772F/NCT6775F) Super IO Sensors' (confidence: 9)

Note: there is no driver for Nuvoton W83677HG-I (NCT6771F/NCT6772F/NCT6775F) Super IO Sensors yet.
Check http://www.lm-sensors.org/wiki/Devices for updates.

Rákerestem a chipre sikerült megtalálni a modul forrását. Wget-tel gyorsan lehúztam ([link]) mind az 5 állományt.

root@xxx:~/W83677HG-I# ls
lm75.h Makefile w83627ehf.c w83627ehf.c.18 w83627ehf.c.rh54

A fordításhoz és telepítéshez csak a make-et hívtam meg kétszer.

make; make install

Végül betöltöttem a modult és boot állóvá tettem:

modprobe w83627ehf
echo "w83627ehf" >>/etc/modules

Gondoltam, hogy az E350-es APU-t kipróbálom Nattyval. Elég szépnek tűnik, de amúgy igazi szőke. Igaz, hogy Beta 1, de egy debian testing verzió sziklaszilárd hozzá képest. A telepítés rögtön megviccelt. Ugya a kis ITX-es deszka EFI alapú, ezért gondolt egyet és az EFI-s GRUB-ot telpítette. De az Arock nem így gondolta, hanem sima AHCI módban próbál bootolni. Vicces páros, mert a DVD-t előtte EFI módban szerette.

Gyors javításhoz live DVD boot után:

# sudo bash
# mount /dev/sda2 /mnt
# mount /dev/sda1 /mnt/boot
# mount tmpfs -t devtmpfs /mnt/dev
# mount tmpfs -t sysfs /mnt/sys
# mount tmpfs -t proc /mnt/proc
# chroot /mnt
# apt-get install grub-pc
# exit
# shutdown -r now

A siker nem maradt el. Érdekes, de elérhetőek repositoryból a vaapi libek. Remélem legjobbakat. Most még kap egy dist-upgradet, aztán jöhet az fglrx is. Mindenesetre rögtön lekapcsoltam a képernyővédőt és az összes standby funkciót, mert az AMD nem képes normális meghatót írni, ami rendesen működik. Ha már fglrx, ahogy nézem ebben az is a bétás 11.4.

XBMC live iso letöltése:

http://mirrors.xbmc.org/releases/live/xbmc-10.1-live.iso

USB-re alakítás:

Az USB kulcsot miután bedugtam a dmesg paranccsal ellenőriztem és /dev/sdc-kent érzékelte a gépem. Fdisk segítségével egy linuxos partíciót hoztam létre és megformáztam ext2-re:

fdisk /dev/sdc
n -> new
p -> primari
1 -> elso particio
enter, amíg kérdez, majd w a kiíráshoz.

Kihúz -> visszadug után formázás:

mkfs.ext2 /dev/sdc1

A bootolhato USB előállítása volt hátra. Ehhez kell az unetbootin és a p7zip. Sajna a régi RHEL alá nincs más megoldás, mint a fordítás vagy a futtatható bináris letöltése. Legálabbis RPM-et nem találtam.

unetbootin

p7zip

Innen egyszerű a mutatvány:

Ha nincs grafikus felület a gépen, amin virtualizálni szeretnénk, akkor két lehetőség van az adminisztrálásra:

VBoxManage

ssh-val belép az admin a gépre és szorgalmasan gépel. Lerakatnyi paramétere van, amivel gyakorlatilag bármit be lehet állítani. Egy gyors példa.

Gép létrehozása és regisztrálása:

VBoxManage createvm -name "box_buntu_01" -register

Szükségünk van egy merevlemezre. A lemez méretet MB-ban kell megadni és regisztrálni kell. A létrehozást követően hozzá is adtam egy IDE controllert es csatoltam, primary master merevlemezt (hda).

VBoxManage createhd -filename "box_buntu_01.vdi" -size 10000 -register
VBoxManage storagectl box_buntu_01 --name "PATA" --add sata
vboxmanage storageattach box_buntu_01 --storagectl "PATA" --port 0 --device 0 --type hdd --medium box_buntu_01.vdi

Nem árt, ha van memória és hálózati eszköz. Ha bridged, akkor a hálózati forgalmát a szerver egyik fizikai interface-n (eth0) fogja bonyolítani. Így tudunk saját IP-t adni és külső gépről el tudjuk érni. Alternatíva, hogy NAT-ot használunk, de én jobb szeretem ezt a megoldást, mert kevésbé macerás.

A VMware magára hagyta a server-t. Szerencsére a google és a közösség segített. Problémák:

Az új debian alatt nem akart lefordulni a kernel modul:

Egy patch-re van szükség. A howto elég részletes. A lényege:

- patch.tgz-t le kell tölteni és kicsomagolni.
- A kernelnek megfelelő gcc-t állítottam be: ln -s gcc-4.3 /usr/bin/gcc
- A benne található scriptnek meg kell adni a könyvtárat, ahol a vmware telepítő található:
./vmware-server-2.0.x-kernel-2.6.3x-install.sh /install/vmware/server

Firefox alatt nem akart betölteni a webgui

Több dolgot is kipróbáltam. A végén kettő együttes alkalmazása hozta el a web UI-t.

- /usr/local/lib/vmware/lib/libc.so.6 könyvtárba létrehoztam egy linket, ami a /lib/libc.so.6-ra mutat.
ln -s /lib/libc.so.6 /usr/local/lib/vmware/lib/libc.so.6/libc.so.6
- A firefox-ban engedélyeztem az ssl2-őt, majd újraindítottam azt.

Az eredmény egy működő vmware server. A virtualbox GUI-ja a következő kihívás.

Értem, hogy a bulvár sajtó csak az olvasottságra hajt. Értem, hogy ezt csak úgy tudja elérni, ha hatásosan tálal dolgokat. De azt már nem tudom elhinni, hogy miért van szükség a fölösleges pánik keltésre.

Két cikk:

Greenpeace

Az első cikkben megszólaltatott Greenpeace szakértő biokémiát és környezetvédelmet végzett. Hallgatott ugyan nukleáris technikát, de ez nem igazán több, mint amennyi villanytant egy mérnök-manager tanul. Jelenleg környezetvédelmi kommunikációt tanít, amihez jól ért, mint a cikkből is kitűnik.

[link] - [link] - [link]

A véleményetekre lennék kíváncsi. Elgondolkoztam, hogy mikor mondhatom hogy egy gép virtualizált és mikor, hogy emulált. Ha az elméleti definícióját nézzük, akkor minimális az eltérés:

- Az emuláció lényege, hogy egy teljesen eltérő környezetben teszi lehetővé a programok futását. Az emulátor tehát egy olyan (szoftver-hardver) eszköz, ami megvalósítja ezt a kompatibilitást.
- Virtualizáció során egy látszólagos környezetet hozunk létre, ami érinthet egy vagy több hardver vagy szoftver elemet.

Válasz 1:

Ez alapján minden emuláció, mert egy virtualPC vagy ESXi is több hardvert emulál. Pl. a vidókártyát, vagy a floppy meghajtót. Talán a legjobb választóvonal az lehetne, hogy a CPU-t emuláljuk-e. De itt bejön az, hogy a VT ide vagy oda, a ring 0-ba tartozó (guest operációs rendszer kernel egy része) kódot mindenféle trükkökkel tudják csak futtatni. Régebbi gépeken VT hiányában (S775-ön a kisebb CPU-ból az Intel kispórolta) szintén leginkább emulációhoz hasonló kód átalakító-trap beszúró átalakítás szükséges.

Válasz 2:

Egy határozott különbséget lehet húzni a kettő közé. Ha a CPU-t regiszterestül, ALU-val és FPU-val együtt emuláljuk és a bináris kód ezen fut, akkor emuláció. (Példa: dolphin-emu, bochs) Ha a bináris kód nagy része (90% fölött) natívan a fizikai gép CPU-ján fut átalakítás nélkül, akkor virtualizáció. (pl. virtualbox)

Van egy kis gond a vaapi-val RHEL 5.5 alatt. Feltelepítettem ami elvileg szükséges a libva-hoz

# yum -y install libdrm libdrm-devel
# wget http://www.splitted-desktop.com/~gbeauchesne/libva/libva-latest.tar.gz
# tar zxf libva-latest.tar.gz
# cd libva-0.31.1/
# ./configure

De nem ment. Megpróbáltam autoconfig és automake segítségével, de sajnos nem fordul le:

undefined reference to `drmOpenOnce'

Azt az egyet tudtam kisütni, hogy talán a libdrm túl régi. De ha azt is le akarom fordítani, akkor le kell cserélnem az utomaket, amihez viszont... Azt hiszem ebbe a lavinába nem akarok beszállni. mindenesetre ha valakinek van használható ötlete, azt szívesen hallgatom. Esetleg RHEL 6-al kellene próbálkozni...

Elnezest az ekezetek hianyaert, de meg csak most kezdtem el belakni a gepem.

A RHEL 5.5 nem eppen desktop rendszernek keszult, persze minden megoldhato, mint minden linuxon. Elso korben belottem a wifit, ugyanis hianyzott a firmware a dmesg szerint:

kernel: iwlagn: iwlwifi-5000-1.ucode firmware file req failed: -2

Masodik korben belottem a GPRS-t bluetoothon keresztul. Ez kicsit heggesztes lett, elegge csunya, de majd felrakok valami GUI-t kesobb:

# cat /etc/bluetooth/hcid.conf
#
# HCI daemon configuration file.
# HCId options
options {
autoinit yes;
security auto;
pairing multi;
dbus_pin_helper;
}

# Default settings for HCI devices
device {
name "jomadar-%d";
class 0x120104;
iscan enable; pscan enable;
lm accept;
lp rswitch,hold,sniff,park;
}

A telefonban engedelyezni kell, hogy mas eszkozok is lathassak, majd az rfcomm-hoz lekerdezhetjuk a telefon cimet a hcitool inq utasitassal. Ezt kell megadni a device sorban. A csatornat az sdptool search DUN segitsegevel tudhatjuk meg.

# cat /etc/bluetooth/rfcomm.conf
#
# RFCOMM configuration file.
#