Fórumok
Sziasztok!
Van egy szerverem egy VPS szolgáltatónál. Reboot után, csak ro-val indul a file rendszer.
Remountoltam, majd fsck de nem segít.
mount -o remount,rw /dev/xvda1 /
fsck /dev/xvda1
Minden egyes indításnál ro-ra ugrik.
Eddig csak "valódi" gépekkel volt dolgom, lehet hogy itt másképp kellene ezt csinálni?/Nem gondolnám/
Tudtok segíteni, hogy milyen lépésekkel tudnám újra írhatóvá tenni?
Köszönöm!
Hozzászólások
Az fstabban mi van? A dmesg -ből nem derül ki mi a baja a kernelnek/mount-nak az fs-el?
fstab:
/dev/xvda1 / ext3 defaults,errors=remount-ro 0 1
/dev/xvda2 swap swap defaults 0 0
proc /proc proc defaults 0 0
dmesg-et már vagy háromszor átnéztem, de most megteszem újra. SWAP-ot felcsatolja, azt látom benne.
ubuntu 12.04 + ext4 ?
mert akkor fstabba, egy barrier=0 tegyél be.
vannak/voltak ilyen gondok
Fedora 17, Thinkpad x61s
debian 6, ext3
lehet hibás az fs, és futtatni kéne egy fsck-t
ehhez viszont meg kéne rescue disc, kérdezd meg a szolgáltatótól mik a lehetőségek.
Fedora 17, Thinkpad x61s
Ezt szeretném elkerülni...
Eddig ebben a VPS-ben Kb 2 napi munkám van benne, ha nagyon megerőltetem magam 1. Ha nagyon kell rebuild.
Nem is ez aggaszt, hanem az hogy miért történt ez. Semmi extra nem történt. Ha ez már egy teljesen összeállított rendszernél fordul elő akkor mérges leszek.
Ha szerencséd van tudnak egy LVM snapshotot (vagy bármilyet) csinálni (amit lementenek külsőleg is persze) és gond nélkül lehet fsck-zni. Másrészt a barrier=0 -t próbáld ki, ha ext4-ed van.
Azt tényleg nem értem, hogy elsőre miért nem a szolgáltatónak szólsz, hogy ezt észleled és van-e tippjük. Ha valami visszatérő akkor nyilván van szolúció, ha meg sikerült elsőnek ráfutnod valamire, akkor meg azért kéne nekik szólni.
ne szórakozzunk fsck futtatásához miért kellene rescuedisk?
shutdown -rF now
avagy
touch /forcefsck így persze minden indításnál megcsinálja..
Az fsck egy dolog, de nembiztos, hogy javito modban fut - marpedig neki az kellene, az, hogy az fsck feltarja, hogy gond van, az meg nagyon keves.
--
http://askubuntu.com/a/151742
:)
lényeg:
/etc/default/rcS, FSCKFIX=yes. This means "automatically repair filesystems with inconsistencies during boot" and causes fsck to run with the -y flag. It was set to no in both of my Ubuntu systems.
Ezt próbáltam, de semmi eredmény.
logok?
dmesg:
http://pastebin.com/3ebBsmYi
egy fsck nem a világ, megaztán ha télleg sérült a fájlrendszer muszáj, minnél előbb, az hogy meg miert történt ki tudja, erről max a szolgáltató tud felvilágosítani. Azon kívül csak tippek vannak.
Fedora 17, Thinkpad x61s
Pedig ez a megoldasa a dolognak, es eles rendszernel is ez lesz.
Esetleg megprobalhatod azt, hogy read-only allapotaban futtatsz egy "fsck -C -fy /dev/xvda1" parancsot, asszem az ilyenkor enged fixalni is - rw modban mar nem.
--
fsck -C -fy /dev/xvda1
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/xvda1: 30167/13762560 files (0.8% non-contiguous), 872083/27525120 blocks
Viszont nincs változás..
Ugy nezem, akkor a fajlrendszernek nincs baja, azt jelezne ez a parancs, akkor is, ha keptelen javitani.
Nem lehet esetleg veletlen az, hogy bugos a rendszered? Altalaban az szokott ilyet okozni, ha a kernel paranssoraban van egy 'ro' amit a rendszer nem tud elkezelni. Nyomj mar ide nekem egy /proc/cmdline tartalmat plz...
--
+fstab tartalma is jöhet, mert ha kvótával kapcsolatos bejegyzések vannak, akkor néha attól is csinál ilyet.
voltmar
--
Igaz, köszi. Olvastam is, csak ..este van. Elnézést :)
Ott is próbálj egy barrier=0 -t.
Próbáltam...
Kb mindent leírtak már amit lehetett. Ha semmi eredmény, szerintem jelezd a szolgáltatónak. Ha semmi rosszat nem csináltál, akkor ez nem normális állapot -> javítania kell.
Egyáltalán nem biztos, hogy a szolgáltatói oldalon van a gubanc. Elképzelhető, hogy valami remek Debian-os update vagy csomag rakoncátlankodik.
Én is erre gyanakszom.. Az utolsó kommentem tartalmazza a frissített csomagokat...
Írtam a szolgáltatónak. Ők is lefuttatták az fsck-t nulla hibával.
Azt javasolták, gondoljam át mit csináltam mielőtt behalt minden.
Hát ezt:
-- iptables script --> /etc/init.d/
-- update-rc.d iptablesscr defaults
-- apt-get update
-- apt-get upgrade //frissítések miatt.
Gyanítom, hogy a frissítések szedték szét.
Megkeresem mik voltak azok pontosan.
Hát ezek:
Upgrade: bind9-host:amd64 (9.7.3.dfsg-1~squeeze9, 9.7.3.dfsg-1~squeeze10), dnsutils:amd64 (9.7.3.dfsg-1~squeeze9, 9.7.3.dfsg-1~squeeze10), libdns69:amd64 (9.7.3.dfsg-1~squeeze9, 9.7.3.dfsg-1~squeeze10), libisccc60:amd64 (9.7.3.dfsg-1~squeeze9, 9.7.3.dfsg-1~squeeze10), liblwres60:amd64 (9.7.3.dfsg-1~squeeze9, 9.7.3.dfsg-1~squeeze10), libbind9-60:amd64 (9.7.3.dfsg-1~squeeze9, 9.7.3.dfsg-1~squeeze10), libisccfg62:amd64 (9.7.3.dfsg-1~squeeze9, 9.7.3.dfsg-1~squeeze10), libisc62:amd64 (9.7.3.dfsg-1~squeeze9, 9.7.3.dfsg-1~squeeze10)
End-Date: 2013-04-02 11:13:10
Furcsa lenne ha egy bind upgrade elrontaná az fs-t :>
Ma raktam fel én is ezeket pár szerverre, de egyelőre semmi gond, remélem nem is lesz.
Fedora 17, Thinkpad x61s
Én is ezért dobtam fel mérlegelés nélkül.
Hmm lehet, hogy user error lesz a dologból..
Kaptam consolt a szerverhez, és most látom a bootlogokat.
KB semmi érdekes, viszont egy sor megütötte a szemem:
startpar: service(s) returned failure: block_ports mountall-bootclean.sh x11-common mountnfs-bootclean.sh bootmisc.sh ... failed!
Az első service ami elindul az általam kreált iptables script aminek már nem kellene ott lennie.
Nos miután megcsináltam a scriptet, beraktam initbe, nyomtam egy restartot.
Nem indult. Gondoltam az iptables kitiltott.
Erre leállítottam vps admin-al a szervert majd file kezelővel töröltem az /etc/init.d-ből.
Viszont ő ezek szerint még mindig próbálkozna az elindítással.
Ez leblokkolhat egy egész FS-t??
Nem lehet az, hogy lementodtek az iptables szabalyok, es minden bootkor betoltodnek, es te akarsz NFS-t mountolni, es az iptables miatt nem sikerul?
OFF:
"Erre leállítottam vps admin-al a szervert majd file kezelővel töröltem az /etc/init.d-ből."
Úgy érted, hogy az offline vps fájlrendszerét felcsatolva tudtál rajta matatni?
Milyen felülettel lehet ezt megtenni?
A parallels tud ilyesmit.
Viszont ha tényleg parallels, akkor sokszor fordult már elö ilyen (illetve hasonló read-only fs hiba) más szolgáltatónál is. Szóval nem biztos, hogy user error...
szerk:
egyébként melyik szolgáltatóról van szó?
Paralellsnél szerintem nem xvdX lesz.
ez engem is erdekelne...
XEN alapú virtualizáció, és hipervm enterprise 2.0 az admin.
Nos,csak user error lett. Vázolom, hátha más is belefut.
Miután megkaptam az elérést a szerverhez, mindegyik program installálása elszállt azzal a hibával, hogy a /etc/init.d/killnash init infója nincs kitöltve. Ezt megtettem egy alap értékkel. Viszont az update-rc.d-t nem futtattam le. (Minek, hiszen így is megoldódott a probléma.)
Majd miután tegnap mégis lefuttattam a saját script miatt, beépítette a killnash-t is ami ezek szerint rossz init infóval rendelkezett. Ezen infót kiszedve simán elindult a szerver.
Szóval user error :/
Köszönöm mindenkinek a hasznos tanácsokat, sokat segítettek!