[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fsck beim Boot abbrechen, FS trotzdem rw mounten



Hi,

Claudius Hubig wrote:
> Silke Suck <usenet@mindsky.de> wrote:
>>Hallo Claudius,
>>
>>Claudius Hubig <x2017_2007@nurfuerspam.de> schrieb:
>>>
>>> Entschuldige, dass hätte ich vielleicht dazuschreiben sollen:
>>> natürlich ist mir diese Möglichkeit bekannt, allerdings gibt es
>>> während des Bootvorganges bei nicht-schreibbarem / einige "nette",
>>> wenn auch mehr oder weniger harmlose, Fehlermeldungen, die ich gerne
>>> vermeiden würde, eben indem direkt nach dem abgebrochenen fsck das
>>> Dateisystem rw gemountet wird.
>>
>>ich hab das jetzt mal zur Diskussion gestellt, weil es mir komisch
>>vorkam, dass ein vom User abgebrochenes fsck das FS ro mountet. Wir
>>konnten uns nicht so ganz einig werden, ob das normal ist oder nicht,
>>aber pruef doch mal mit tune2fs -l die Einstellung von "Errors
>>behaviour". Falls das nicht auf "continue" steht, sondern auf
>>"remount-ro", koennte das der Grund sein - mit tune2fs -e kannst du das
>>umstellen.
> 
> Nope, da steht "Continue". Hier mal die gesamte Ausgabe von tune2fs:
> 
> zeus:~# tune2fs -l /dev/mapper/md1_crypt
> tune2fs 1.40-WIP (14-Nov-2006)
> Filesystem volume name:   <none>
> Last mounted on:          <not available>
> Filesystem UUID:          842dabcd-17d4-45eb-872c-42b20a3cc7b1
> Filesystem magic number:  0xEF53
> Filesystem revision #:    1 (dynamic)
> Filesystem features:      has_journal resize_inode dir_index filetype
> needs_recovery sparse_super large_file Filesystem flags:
> signed directory hash Default mount options:    (none)
> Filesystem state:         clean
> Errors behavior:          Continue
> Filesystem OS type:       Linux
> Inode count:              1210048
> Block count:              2417503
> Reserved block count:     120875
> Free blocks:              608230
> Free inodes:              1059208
> First block:              0
> Block size:               4096
> Fragment size:            4096
> Reserved GDT blocks:      590
> Blocks per group:         32768
> Fragments per group:      32768
> Inodes per group:         16352
> Inode blocks per group:   511
> Filesystem created:       Tue Apr  3 18:55:48 2007
> Last mount time:          Thu Jul  5 12:53:59 2007
> Last write time:          Thu Jul  5 12:53:59 2007
> Mount count:              1
> Maximum mount count:      30
> Last checked:             Thu Jul  5 12:52:29 2007
> Check interval:           15552000 (6 months)
> Next check after:         Tue Jan  1 11:52:29 2008
> Reserved blocks uid:      0 (user root)
> Reserved blocks gid:      0 (group root)
> First inode:              11
> Inode size:               128
> Journal inode:            8
> Default directory hash:   tea
> Directory Hash Seed:      4835b38c-75ae-499d-bf96-14b2e36a3010
> Journal backup:           inode blocks
> 
> Das sieht soweit auch für mich alles gut aus.
> 
> Eine Idee habe ich aber noch - wenn ich in einem Shellscript Ctrl+C
> nutze, wird nicht etwa nur das gerade laufende Programm, sondern das
> gesamte Skript abgebrochen, wie man hierdran sehen kann:
> 
> #!/bin/bash
> echo "123"
> dd if=/dev/urandom of=/dev/null count=20000 bs=2048
> echo "321"
> 
> Drücke ich während dd "arbeitet" Ctrl+C, wird "321" nicht ausgegeben,
> wird das Skript normal beendet dagegen schon. Da fsck beim Booten ja
> in den Skripten aufgerufen wird, die irgendwie auch so aussehen, als
> seien sie fürs Mounten zuständig, habe ich die Vermutung, dass ich
> dann eben das "richtige" Mounten von / abbreche (es wurde ja vorher
> schon ro gemountet). Stimmt das?

wenn im Skript Traps nicht abgefangen werden, sollte das stimmen.
Schau doch einfach mal in checkroot.sh rein, da kannst Du genau
sehen, was passiert.

Gruss
Reinhold



Reply to: