Linux (Slackware 7.1) and "scandisk"

[DJ]

Hallo Allen.

Weet iemand hoe ik kan zien of een Disk (die gemount is) bad sectors heeft?

Mijn Linux (Slackware 7.1) routerje maakte laatst een minder leuk geluid dat van de HardDisk af kwam. Het leek of hij een HeadCrash had (zo'n KLONK geluid), spinde down, en spinde weer up . . . Linux zelf had nergens last van (ik heb inmiddels een Uptime van ruim 260dagen ), maar ik wil wel eens weten of er misschien een badsector bij gekomen is (er stonden er nog geen op).

Ik hoor het wel.

DJ

[Verwijderd]

e2fsck -c /dev/..

[deadinspace]

Op maandag 03 september 2001 00:26 schreef edwinv het volgende:
e2fsck -c /dev/..

Alsie gemount is?

[Verwijderd]

Op maandag 03 september 2001 00:39 schreef deadinspace het volgende:

[..]

Alsie gemount is?

Zolang het maar RO is.

[Verwijderd]

Op maandag 03 september 2001 00:40 schreef nelske het volgende:

[..]

Zolang het maar RO is.

Precies, nooit progs zoals fsck, tune2fs, enz. runnen op een RW-gemounte partitie.

[Verwijderd]

Waarom mag dat niet op een RW gemounte partitie

[Verwijderd]

fsck doet volgens mij een check van het filesystem.
Bad sectors kun je nakijken met badblocks /dev/blah

[DJ]

Op maandag 03 september 2001 01:31 schreef edwinv het volgende:

[..]

Precies, nooit progs zoals fsck, tune2fs, enz. runnen op een RW-gemounte partitie.

Da's dus precies mijn probleem . . .

Deze schijf is gemount als / (root dus . . .)

En mijn routertje heeft al een Uptime van dik 260 dagen, en dat wil ik wel zo houden.

Dus vandaar de vraag of je kunt zien op een RW gemounte schijf of je Bad Sectors hebt.

DJ

[Verwijderd]

Op maandag 03 september 2001 10:22 schreef rezzie het volgende:
Waarom mag dat niet op een RW gemounte partitie

Kan ernstige schade toebrengen aan je filesysteem.
Het kan wel hoor, maar het is niet aan te raden.

Op maandag 03 september 2001 17:31 schreef DJ het volgende:

[..]

Da's dus precies mijn probleem . . .

Deze schijf is gemount als / (root dus . . .)

En mijn routertje heeft al een Uptime van dik 260 dagen, en dat wil ik wel zo houden.

Dus vandaar de vraag of je kunt zien op een RW gemounte schijf of je Bad Sectors hebt.

DJ

man mount

code:

mount -o remount,ro /

Verder is je redenatie nogal vreemd als je het mij vraagt.
Af en toe een nieuwe kernel erop gooien i.v.m. exploits is niet verkeerd (ik weet zo niet welke kernel slackware 7.1 heeft, maar toch)! Ik moet altijd smakelijk lachen om mensen die blij zijn met een uptime van meer dan een jaar of iets dergelijks. Geeft alleen maar aan, dat ze beveiliging niet echt serieus nemen. Tja dat een linux machine lang up kan blijven weet iedereen wel!

[Verwijderd]

Slackware 7.1 heeft standaard kernel 2.2.16 aan boord.

[Verwijderd]

Tja ofwel daar is sowieso en exploit voor.
Ik had eigenlijk niet eens hoeven weten welke kernel het was, aangezien alle kernels < 2.2.19 hiervan last hebben.

"Hiervan" is in deze een sysctl call geheugen probleem.
Het is mogelijk om met programma's die geen privileges hebben toch geheugen uit te lezen dat geprivileerd is, aangezien de call met negatieve waardes aangeroepen kan worden.

[DJ]

Als ik het dus goed begrijp, dan is er, op fsck etc. na, geen andere manier om te zien of een schijf bad sectors heeft . . .

Als dat zo is, dan laat ik de machine gewooon draaien tot hij klapt . . . is toch een oude bak, en een andere schijf heb ik nog wel liggen . . .

DJ

[Servowire]

mount -o remount,ro /

Zegt iemand toch al!
dat remount je readonly, dan kun je fsck denk ik wel veilig doen.

Daarna weer terugmounten als /

Of lul ik nou uit mijn nek?

[active2]

Of lul ik nou uit mijn nek?

nee

[Verwijderd]

Op dinsdag 04 september 2001 08:53 schreef Servowire het volgende:
Of lul ik nou uit mijn nek?

Dubbelcheck: Nee
Maar ja, als het niet gecontroleerd behoeft te worden

[DJ]

Op dinsdag 04 september 2001 14:39 schreef nelske het volgende:

[..]

Dubbelcheck: Nee
Maar ja, als het niet gecontroleerd behoeft te worden

Sorry voor de onwetendheid mijnerzijds . . . maar ik snap hem nu . . .

Ik krijg alleen als ik dat commando intik hetvolgende:

code:

root@luxje:/# mount -o remount,ro /
mount: / is busy
root@luxje:/#

moet ik nu eerst alle processen "killen" ?

Ik zal een uitdraai van mijn "top" schgerm erbij zetten:

code:

  7:55pm  up 265 days, 19:35,  1 user,  load average: 0.02, 0.42, 0.75
37 processes: 36 sleeping, 1 running, 0 zombie, 0 stopped
CPU states:  0.0% user,  0.1% system,  0.0% nice,  0.0% idle
Mem:    62900K av,   47004K used,   15896K free,    6712K shrd,   30816K buff
Swap:  157240K av,    2148K used,  155092K free           4124K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME COMMAND
28116 root  16   0  1104 1104   912 R    0  3.8  1.7   0:00 top
    1 root   0   0    72   64    44 S    0  0.0  0.1   0:05 init
    2 root   0   0     0    0     0 SW  0  0.0  0.0   0:01 kflushd
    3 root   0   0     0    0     0 SW  0  0.0  0.0   0:03 kupdate
    4 root   0   0     0    0     0 SW  0  0.0  0.0   0:00 kpiod
    5 root   0   0     0    0     0 SW  0  0.0  0.0   0:02 kswapd
   66 bin     0   0   252  228   172 S   0  0.0  0.3   0:00 rpc.portmap
   70 root   0   0   256  204   156 S    0  0.0  0.3   0:53 syslogd
   73 root   0   0   468    0     0 SW  0  0.0  0.0   0:08 klogd
   75 root   0   0   256  212   176 S    0  0.0  0.3   0:00 inetd
   77 root   0   0   100    0     0 SW  0  0.0  0.0   0:00 lpd
   80 root   0   0   180   72    48 S    0  0.0  0.1   0:00 rpc.mountd
   82 root   0   0   188   72    44 S    0  0.0  0.1   0:00 rpc.nfsd
   84 root   0   0   304  276   212 S    0  0.0  0.4   0:00 crond
   94 root   0   0    76   20    12 S    0  0.0  0.0   0:00 gpm
  107 root   0   0    64    0     0 SW  0  0.0  0.0   0:00 agetty
  108 root   0   0    64    0     0 SW  0  0.0  0.0   0:00 agetty
  109 root   0   0    64    0     0 SW  0  0.0  0.0   0:00 agetty
  110 root   0   0    64    0     0 SW  0  0.0  0.0   0:00 agetty
  111 root   0   0    64    0     0 SW  0  0.0  0.0   0:00 agetty
  153 root   0   0    64    0     0 SW  0  0.0  0.0   0:00 agetty
  171 nobody     0   0   180   48    24 S    0  0.0  0.0   0:00 in.identd
  172 nobody     0   0   180   48    24 S    0  0.0  0.0   0:00 in.identd
  173 nobody     0   0   180   48    24 S    0  0.0  0.0   0:00 in.identd
  174 nobody     0   0   180   48    24 S    0  0.0  0.0   0:00 in.identd
  175 nobody     0   0   180   48    24 S    0  0.0  0.0   0:00 in.identd
  176 nobody     0   0   180   48    24 S    0  0.0  0.0   0:00 in.identd
  177 nobody     0   0   180   48    24 S    0  0.0  0.0   0:00 in.identd
15365 root   0   0   440  388   276 S    0  0.0  0.6   1:04 dhclient
 1707 root   0   0   412  356   252 S    0  0.0  0.5   0:17 dhcpd
 3806 root   0   0   108  108    80 S    0  0.0  0.1   0:32 dhcpcd
28082 root   0   0   628  628   508 S    0  0.0  0.9   0:00 in.telnetd
28083 deij   0   0  1040 1040   804 S    0  0.0  1.6   0:00 bash
28093 root  10   0  1048 1048   800 S    0  0.0  1.6   0:00 bash
28108 root   0   0   988  988   820 S    0  0.0  1.5   0:00 squid
28110 squid 6   0  5644 5644  1120 S     0  0.0  8.9   0:00 squid
28111 squid 0   0   308  308   252 S     0  0.0  0.4   0:00 unlinkd

Ik hoor/lees het wel.

DJ

[Mark]

Op maandag 03 september 2001 18:33 schreef nelske het volgende:
Tja ofwel daar is sowieso en exploit voor.
Ik had eigenlijk niet eens hoeven weten welke kernel het was, aangezien alle kernels < 2.2.19 hiervan last hebben.

"Hiervan" is in deze een sysctl call geheugen probleem.
Het is mogelijk om met programma's die geen privileges hebben toch geheugen uit te lezen dat geprivileerd is, aangezien de call met negatieve waardes aangeroepen kan worden.

Euuh...vermeld er ook even bij dat dit alleen een local exploit is. Mensen welke geen "onveilige" local users hebben hoeven hun kernel niet perse te updaten (al is het trouwens natuurlijk nooit slecht om het wel te doen )

[deadinspace]

Op donderdag 06 september 2001 00:33 schreef RedRoon het volgende:
Euuh...vermeld er ook even bij dat dit alleen een local exploit is. Mensen welke geen "onveilige" local users hebben hoeven hun kernel niet perse te updaten (al is het trouwens natuurlijk nooit slecht om het wel te doen )

Klopt, maar als er nou morgen een exploit in apache wordt ontdekt, waardoor een cracker als user nobody een shell kan krijgen op die bak, dan kan hij via die kernel exploit root worden.

[Verwijderd]

Whoops. Er moet sowieso de optie -n bij zodat er niet naar /etc/mtab geschreven wordt, want dat gaat uiteraard niet lukken.
Dus "mount -n -o remount,ro /"

Op donderdag 06 september 2001 00:33 schreef RedRoon het volgende:

[..]

Euuh...vermeld er ook even bij dat dit alleen een local exploit is. Mensen welke geen "onveilige" local users hebben hoeven hun kernel niet perse te updaten (al is het trouwens natuurlijk nooit slecht om het wel te doen )

Yupz, is bij deze gedaan
Maar goed een local exploit kan heel handig van pas komen als een cracker binnen weet te komen maar nog geen root-privileges heeft, zoals deadinspace ook al zei.