Red Hat, Fedora, CentOS

hello

van egy centos 6.4 egy ESXi 5.0.0 és a grub menu után mintha timeoutolna vagy nem tudom mivan. súlyos 10 percekig csak fekete konzol képernyő és utána indul a boot. vajon mi a fene lehet? merre kezdjek el keresgélni?

A grub.conf


# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/mapper/vg_system-LogVol02
# initrd /initrd-[generic-]version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
#hiddenmenu
title CentOS (2.6.32-358.18.1.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-358.18.1.el6.x86_64 ro root=/dev/mapper/vg_system-lv_root rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=uk LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=vg_system/lv_swap rd_LVM_LV=vg_system/lv_root rd_NO_DM
initrd /initramfs-2.6.32-358.18.1.el6.x86_64.img
title CentOS (2.6.32-358.11.1.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-358.11.1.el6.x86_64 ro root=/dev/mapper/vg_system-lv_root rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=uk LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=vg_system/lv_swap rd_LVM_LV=vg_system/lv_root rd_NO_DM
initrd /initramfs-2.6.32-358.11.1.el6.x86_64.img
title CentOS (2.6.32-358.el6.x86_64)
root (hd0,0)
kernel /vmlinuz-2.6.32-358.el6.x86_64 ro root=/dev/mapper/vg_system-lv_root rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=uk LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=vg_system/lv_swap rd_LVM_LV=vg_system/lv_root rd_NO_DM
initrd /initramfs-2.6.32-358.el6.x86_64.img


Tisztelt nagyérdemű!
Az alábbi dologba keveredtem bele:
Volt/van egy(pár) OEL5.9-es (tikaga?) oracle redhat szerver, amik multipath-on kapják némely diszkjüket.
Eddig minden jól működött, Oracle RAC ASM-es diszkjeit kapta. És aki implementálta a rc.local-ből adta ki a jogokat a multipath-olt eszközökön a megefelelő (nem root) usernek.
Aztán egyszer csak puff nem működött...Azaz a device létrejött a /dev/mapper/ alatt de a jogok nem kerültek beállításra rajta.

Amit láttam, hogy boot után a multipath-olt diskek csaj jelenős 4-5 perc késéssel jelennek meg, amikorra a rc.local már lefutott.
A probléma multipath nem kellően dokumentált uid group parmétereivel orvoslódott, szerencsére az Oracle cluster stack ezt túléli.
Amit viszont megtaláltam, hogy a multipath betöltéskor pillanatra felvillan a unable to load libaio.so üzenet.
Azt is sikerült kiderítenem, hogy ezek a /usr/lib(64)-ben "laknak" de nálam a /usr külön filesys így a boot folyamat ezen részében nincs fenn.
Nos ezek szerint ez design hiba? vagy mi?

Persze a libaio-s libek átmásolva a /lib(64)-be a boot megvárja a mpath-olt diszkeket ...

Ilyet láttatok?
Mit lehet tenni?

Üdv. TamsA

Sziasztok

Fedora 19 (64bit) alatt nem sikerül életre kelteni az internetet. A hálókártya egy alaplapi történet, rtl8101e, a realtek oldaláról leszedett driver forgatása után látszólag gond nélkül működik. A hálózaton DHCP kioszt mindent, de ha kézzel állítom be akkor is úgy tűnik megvan a kapcsolat. ping-elni a routert tudom. DNS-nél hasalhatna el, de a "ping google.com" is gond nélkül működik. Viszont ha pl.: "curl -Iv google.com"-al, vagy sima "yum update"-el próbálkozom, már timeout-al megáll. Böngészők is, természetesen. Proxy nincs.
Próbáltam "netstat -F"-et, és adtam volna hozzá getaway-t, "route add default gw 192.168.1.1", de minden maradt a régiben. "tail -f /var/log/messages"-ben semmi árulkodó, em1 link up hasonlóak. Gyanakodtam a tűzfalra, "systemctl stop firewalld.service" nem hozott eredményt. SELinux kikapcsolva.Tömör összefoglaló:

[root@localhost r8101-1.024.00]# ifconfig
em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.93  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::ef0b:ff:fe00:e000  prefixlen 64  scopeid 0x20<link>
        ether ed:0b:00:00:e0:00  txqueuelen 1000  (Ethernet)
        RX packets 634  bytes 64576 (63.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 148  bytes 14186 (13.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 45  base 0xe000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@localhost r8101-1.024.00]# ping index.hu
PING index.hu (217.20.130.97) 56(84) bytes of data.
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=1 ttl=60 time=17.7 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=2 ttl=60 time=11.5 ms
64 bytes from sportgeza.hu (217.20.130.97): icmp_seq=3 ttl=60 time=11.1 ms
^C
--- index.hu ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 11.198/13.504/17.791/3.034 ms
[root@localhost r8101-1.024.00]# yum update
Betöltött bővítmények: langpacks, refresh-packagekit
Hiba: Cannot retrieve metalink for repository: fedora/19/x86_64. Please verify its path and try again

Nem nagyon ismerem a fedora-t (még), abban kérnék segítséget, hogy mit kellene nézzek, mi okozhatja ezt. Lehet, hogy a kézzel forgatott driver a gond, szúrjak az alaplapba valami más hálókártyát? (windowsra újraindítva gond nélkül megy minden)

szerk: A megoldás sírvaröhögős: meg kell változtatni a mac address-t valamire, ami nem a gyári. Az ask.fedora-n is feltett kérdésre (köszönet zoltanh kollégának a közreműködésért) írta valaki, hogy bug van a kártya firmwarejében, és eredeti mac-el ezt csinálja. A címet megváltoztatva, majd újracsatlakozva minden működött, lefutott a yum update, és a böngészőben is megjelentek az oldalak.

A "megoldva" utáni "remélem" arra vonatkozik, hogy valaki írta a hozzászólásokban, hogy neki is volt hasonló, de stabilitási gondjai is voltak, "remélem" ott is "csak" a hibás fw okozta. Ha ez történne, akkor is marad a megoldva, mert beleteszek egy másik kártyát, ezt letiltom és jónapot...

Köszönöm mindenkinek a segítségét.

Olykor belefutok abba a problémába, hogy távolról frissítem valakinek a gépét, ő meg erről mit sem tudva kikapcsolja azt. Ez nagyon nem jó, különösen kernel, glibc, selinux-policy frissítése közben.

Az tehát a kérdésem, ki hogyan venné elejét az efféle cselekedetnek. Neten nézegettem ötleteket. Az egyik az volt, hogy csináljak aliast a shutdown, reboot parancsokra, s így futtathatok saját scriptet. Jó is volna, ha egy gépet történelmi okokból nem lehetne sokféleképpen leállítani, újraindítani, hibernálni. Például:

shutdown -h now
poweroff
halt
systemctl halt
systemctl poweroff

Nem sorolom fel ezeket reboot-ra, hibernálásra. És persze ideértendő a kikapcsológomb megnyomása is.

Az oprendszer Fedora 19, a későbbiekben újabb. Természetesen systemd-vel.

Az igazán nekem tetsző megoldás az volna, ha futhatna saját script, ezzel figyelmeztetve a felhasználót, hogy most nem kéne azt tennie, amire készül, azaz leállítani a gépet. Működnie kellene általánosan, például, ha Xfce-ből valaki a logout menüben mondja, hogy shutdown. Már eleve nem tudom, ilyenkor az Xfce mit hív a gép leállításához.

Megoldás:

A /root/.bashrc file-ba az alábbi sort írtam:

alias yum='systemd-inhibit --what=sleep:shutdown:idle:handle-power-key --who=locsemege --why="Frissítem a gépet!" yum'


Nem kicsit vagyok gondban. Egy ismerősöm gépét karbantartottam távolról, kikapcsolta. Épp a selinux-policy frissítése volt soron, így bekapcsolás után nem értem el távolról a gépet. Ismerős nem ért a géphez, Skype-on mondtam, mit tegyen. Az lett belőle, hogy letörölte az rpm parancsot.

Hogyan tegyem vissza, amikor ez éppen az a parancs, amivel feltelepíthetném? Selinuxot kikapcsoltam, most éppen elérem a gépet, de nem tudok telepíteni. A yum ezt mondja:

yum install rpm
error: Unable to open /usr/lib/rpm/rpmrc for reading: No such file or directory.
error: no dbpath has been set
error: cannot open Packages database in /%{_dbpath}
CRITICAL:yum.main:


Error: rpmdb open failed

Megoldás:
Az rpm csomagot kibontottam a saját gépemen, a file-okat átmásoltam ssh-n, majd chown root:root az érintett file-okra. Ezt követően

yum install rpm

így a pre- és post install scriptek is normálisan futottak.

Sziasztok!

A segítségeteket szeretném kérni. Van egy CentOS 6.4 x86_64-et futtató szerverünk, ami 4 IP címmel rendelkezik. Tárhelyek, Teamspeaket és egyéb apróbb szolgáltatásokat futtat. A mai napig tökéletesen működött, de reggel elkezdett szórakozni azzal, hogy kb. 25-30 percenként az egyik IP cím elérhetetlenné válik, ( Mindig ugyanaz. ) de a másik háromról ugyanúgy elérhető a gép. Ha service network restarttal újraindítom, akkor megint megy kb 20-30 percig. Egész nap restartolgatom már, keresgéltem mindenfelé de a logok sem mondanak semmi érdekeset.

Ti mire tippeltek, merre keressem a hibát?

Köszönöm mielőbbi válaszotokat!

- Mennyi alkalmas a Fedora 19 AMD-s notebookokra [ Hp probook 4535s-LG855EA | http://goo.gl/VesXbO ] ?
- Mennyi jó az energiakezelése ?
- Mennyire Synaptics touchpad barát alapjáraton hegesztés nélkül (Palmdetect, koppintásos kikapcsolás, több ujjas gesztusok, íráskor kikapcsolás, stb)?
- Mennyi szoktak működni a média gomb kombinációk (FN gombok. Hang, világítás, aksi kijelzés, lezárás, hibernálás stb)
- HDMI kimenetet mennyire jól kezeli [ Manjaro-n akadtak a felbontással és a színekkel gondjaim, főleg akkor amikor a TV fullHD felbontásban ment a notebook pedig HD-ben ] ?
- Egy belakott rendszert mennyi biztonságos frissíteni a következő verzióra? Szoktak összeomlások lenni, vagy megoldott az upgrade?
- Kezdő / fél-kezdő felhasználóknak mennyire javallott ?

Nézem a last parancs kimenetét, s nem értem. Például itt van ez a sor:

reboot   system boot  3.10.4-300.fc19. Wed Jul 31 00:07 - 21:10 (11+21:02)

Természetesen nincs 11 napja és 21 órája bekapcsolva a gép. Nem szoktam hibernálni, tehát ezért sem jogos, hogy ezt mondja. Ez is érdekes:

valaki   pts/0        :0.0             Sun Aug 11 21:10   still logged in   
reboot   system boot  3.10.5-201.fc19. Sun Aug 11 21:01 - 21:10  (00:09)    
valaki   pts/1        :0.0             Sun Aug 11 21:03 - crash  (00:-2)    
valaki   pts/0        :0.0             Sun Aug 11 14:53 - 14:53  (00:00)    
valaki   pts/0        :0.0             Sun Aug 11 14:48 - 14:52  (00:03)    

Miért van hamarabb a pts/1-re bejelentkezés a logban, mint a gép indulása? Egyáltalán ki írja a wtmp-t, s miért érzem, hogy zöldség a tartalma? A systemd-ben nem jó valami?

Működik valakinek a sandbox Fedora 19 alatt? Most upgrade-eltem 18-ról és meg sem szólal. Hibaüzenet nincs. Az alábbi parancsok nem működnek, egyszerűen nem jelenik meg a GUI (a Xephyr-el).

sandbox -X xterm
sandbox -t sandbox_net_t -X -- firefox

X nélküli sandbox működik, pl:

sandbox date

Udv!

Adott egy szerver, amin valami eszi a memoriat. Most kaptam hozza hozzaferest, de van nemi adat az elmult egy honapbol. 256G ram van benne, ebbol 1 honapja ilyet lehetett latni:

Tue May 14 10:08:01 IST 2013
             total       used       free     shared    buffers     cached
Mem:        258440      13877     244562          0        217       7932
-/+ buffers/cache:       5727     252712
Swap:         2047          0       2047

, most viszont ez van:

Mon Jul  8 15:08:01 IST 2013
             total       used       free     shared    buffers     cached
Mem:        258440      18412     240027          0        324      10778
-/+ buffers/cache:       7310     251129
Swap:         2047          0       2047

. Na jo, ez mar majdnem 2 honap. A megkapott logfilek alapjan nagyjabol folyamatosan tunt el ez a masfel giga memoria (5727 -> 7310), es nem sokat latok, hogy mi lehet ennek az oka. Ime a mem logok. Van hozza egy altalam generalt grafikon is, amin latszik nemi novekedes a puppetmasterd- nel, de a ez csak 100- 200MB, es nem masfel GB (landscape = obq).

Ezen adatokbol nem igazan lehet kitalalni (szvsz), hogy mitol fogy a memoria, de erdekelne, hogy mivel probalkoznatok ennek kideritese erdekeben. Egy szerverrol van szo, tulajdonkeppen csak puppetmasterkent szolgal, illetve ez a landscape nevu valami fut rajta. A gepnek kozvetlen Internetkapcsolata sincs, es amennyire latom, Red Hat- rol van szo, ill.:

Linux dhcp-172-19-29-160 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 16:15:13 CDT 2013 x86_64 x86_64 x86_64 GNU/Linux

.

Koszi a valaszokat!