helo!
CentOS 5
# mount /dev/md4 /var/spool/squid/ -o rw,uid=23,gid=23
mount: wrong fs type, bad option, bad superblock on /dev/md4,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
# mount /dev/md4 /var/spool/squid/
#
In article [EMAIL PROTECTED],
Papp Tamas [EMAIL PROTECTED] writes:
Ez mitol lehet? A particion ext3 van.
file -s /dev/m4 mit mond?
kissg
_
linux lista - linux@mlf.linux.rulez.org
On Thu, Oct 18, 2007 at 08:45:54AM +, Kiss Gabor wrote:
In article [EMAIL PROTECTED],
Papp Tamas [EMAIL PROTECTED] writes:
Ez mitol lehet? A particion ext3 van.
file -s /dev/m4 mit mond?
# file -s /dev/md4
/dev/md4: Linux rev 1.0 ext3 filesystem data (needs journal recovery)
Papp Tamas [EMAIL PROTECTED] wrote:
Ez mitol lehet? A particion ext3 van.
bad option, az ext3-nak nincs uid= meg gid= -je.
raas
--
Those who say it cannot be done should not interrupt the person doing it.
-- Chinese proverb
Papp Tamas wrote:
helo!
CentOS 5
# mount /dev/md4 /var/spool/squid/ -o rw,uid=23,gid=23
mount: wrong fs type, bad option, bad superblock on /dev/md4,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
# mount
Gabor HALASZ [EMAIL PROTECTED] wrote:
Az etxt2/3 nem tamogatja az uid/gid opciokat (a man szerint legalabbis),
a mount meg nem tud hibat kezelni.
Mert nem o kezeli, hanem a kernel. A mount odairta, hogy a dmesg vegen
van a tenyleges hibauzenet, es tenyleg ott is van ilyenkor.
raas
--
Those
On Thu, Oct 18, 2007 at 09:22:53AM +, Andras HORVATH wrote:
Gabor HALASZ [EMAIL PROTECTED] wrote:
Az etxt2/3 nem tamogatja az uid/gid opciokat (a man szerint legalabbis),
a mount meg nem tud hibat kezelni.
Mert nem o kezeli, hanem a kernel. A mount odairta, hogy a dmesg vegen
van
Andras HORVATH wrote:
Gabor HALASZ [EMAIL PROTECTED] wrote:
Az etxt2/3 nem tamogatja az uid/gid opciokat (a man szerint legalabbis),
a mount meg nem tud hibat kezelni.
Mert nem o kezeli, hanem a kernel. A mount odairta, hogy a dmesg vegen
van a tenyleges hibauzenet, es tenyleg ott is van
Papp Tamas wrote:
squid:
Oct 18 10:45:59 sziget2 squid: cache_dir /var/spool/squid: (13) Permission
denied
netfinity-1:~# mount | grep squid
/dev/rd/c0d1p1 on /var/spool/squid type reiserfs (rw)
netfinity-1:~# ls -la /var/spool/ | grep squid
drwxr-xr-- 19 proxy proxy 504 Oct 18 06:25
On Thu, Oct 18, 2007 at 11:36:02AM +0200, Papp Tamas wrote:
squid:
Oct 18 10:45:59 sziget2 squid: cache_dir /var/spool/squid: (13) Permission
denied
Kezzel inditva az initscriptet minden sima (ezert probalkoztam a
megfelelo mount opcioval, hatha meghatja).
chown es chmod.
--
On Thu, Oct 18, 2007 at 12:00:16PM +0200, Kosa Attila wrote:
On Thu, Oct 18, 2007 at 11:36:02AM +0200, Papp Tamas wrote:
squid:
Oct 18 10:45:59 sziget2 squid: cache_dir /var/spool/squid: (13) Permission
denied
Kezzel inditva az initscriptet minden sima (ezert probalkoztam a
Kedves Linux Lista!
Mivel még nem érkezett meg az új UPS, a mai 1 órás áramszünet után szétesett
az egyik gépen a raid1.
Mentségére legyen írva a rendszernek, hogy küldött róla mailt, így azonnal
újraépíttettem a tömböket.
Hogy tudom elérni, hogy ilyenkor magától építse újra, ne kelljen kézzel
On Thu, Oct 18, 2007 at 12:55:40PM +0200, Papp Tamas wrote:
On Thu, Oct 18, 2007 at 12:00:16PM +0200, Kosa Attila wrote:
On Thu, Oct 18, 2007 at 11:36:02AM +0200, Papp Tamas wrote:
squid:
Oct 18 10:45:59 sziget2 squid: cache_dir /var/spool/squid: (13)
Permission denied
On Thu, Oct 18, 2007 at 01:07:55PM +0200, Kosa Attila wrote:
A unixos fajlrendszerek eseten a fajlrendszer tarolja a
jogosultsagokat, nem a mount-nak kell megmondani.
Igen, de explicit meg akartam mondani neki. De nem lenyeg, pontosabban
nincs is ertelme emiatt.
Passz. Probald -x-szel
Sziasztok !
Ki segitseg kellene, mert ilyent meg nem lattam. (Ez nem azt jelenti,
hogy nincs, csak meg fiatal vagyok :))
Egy Compaq server gepem van, 3 db halokartyaval szepen ment. Eth0 (PciX
realtek, 1(alaplapi marvell yukon), 2 (PCI realtek).
A pci-s realtek vez elhunyt, en pedig kicsereltem
Papp Tamas wrote:
A problema, hogy nem indulnak el egyes daemonok a bootfolyamat soran:
squid, clamav, pedig szerepelnek meg a /etc/rc.local-ban is. Az
apache elinudl, de csak a /etc/rc.local-bol (konnyen lehet, hogy itt
vmi mas benazas van a hatterben).
Miért is az rc.local-ból indulnak
On Thu, Oct 18, 2007 at 02:06:04PM +0200, Gábor Lénárt wrote:
On Thu, Oct 18, 2007 at 01:53:47PM +0200, Itsystem - -Értékház wrote:
[...]
A pci-s realtek vez elhunyt, en pedig kicsereltem egy masik (nem
gigabites) realtek-re.
A boot utan meglepve tapasztaltam, hogy az eth0 es az eth2
On Thu, Oct 18, 2007 at 02:07:58PM +0200, BERES Laszlo wrote:
Miért is az rc.local-ból indulnak ezek? Van saját initscriptjük,
megfelelő runlevelen.
Nem onnan indulnak, csak kinomban oda is beraktam azzal a
felszolalassal, hogy az az utolso, mielott vegez a boot folyamat, de
nem segitett.
Scenario: aram el, shutdow elkezdodik, kozben az aram
visszajon, a gepek
meg szepen leallnak es ottmaradnak kikapcsolt allapotban.
Igen, ez fontos probléma.
Gepek bios-aban be KELL allitani hogy 'last state'
legyen aram-kieses utan. A default sokszor 'OFF state'.
Amennyiben a linux elkuldi
Gepek bios-aban be KELL allitani hogy 'last state'
legyen aram-kieses utan. A default sokszor 'OFF state'.
Helyesbítek: ON state... (24h szerverek... ha nem kell, ki kell húzni,
biztos-ami-biztos)
Amennyiben a linux elkuldi a win-eknek (pl. samba-n
keresztul: rpcclient) hogy shutdown, akkor
2007, Oct 18 - Pirity Tamas Gabor wrote :
Ha jól hiszem, Lajber Zoltan írta az alábbiakat:
Biztos, hogy nem C-vel kell kezdeni. Eros a gyanum, hogy a Pascal nem
rossz kezdes. jobb, mint a php, vagy a visbas.
Hogyúgyvan.
Hello,
igy a vege fele csak annyit, h szerintem is jo a python
21 matches
Mail list logo
