(GELOEST) fsck bringt mich wg. Fehler in die Busybox (brtfs)

[safran]

Hallo Debianusers,

nach einem Upgrade meines Debians von Jessie auf Sid (ja keine Sorge, das ist nicht mein Produktivsystem - ich mache das um meine Software unter dieser Umgebung zu testen)

komm ich in der Bootroutine nicht mehr weiter als folgender Punkt.

Kurz nachdem der Kernel gebootet wird, beschwert sich fsck, dass es nicht möglich sei, meine Rootpartition zu checken.
nach Eingabe vom Rootpasswort bin ich in der Busybox, mit einem Read-Only gemounteten brtfs-filesystem als Rootpartition.

Ich kann hier auf alles zugreifen, und sie auch als writable remounten, allerdings weiss ich nicht wie der fsck mit brtfs ab hier funktioniert.

Befehle wie

Code: Alles auswählen

fsck /dev/sda3

(sda3 ist die Rootpartition)
oder

Code: Alles auswählen

brtfs check /dev/sda3

(soähnlie Syntax)
sagt mir immer, dass ich nicht den Check machen kann, da das FS bereits gemountet ist.

Code: Alles auswählen

umount /

bzw. /dev/sda3 bzw

Code: Alles auswählen

umount -a

hat nicht geholfen

1. Frage:
wie kann ich aus der Busybox den Check machen,

wichtig zu erwähnen ist noch die Fehlermeldung während des Bootprozesses:
fsck sagt

Code: Alles auswählen

unknown option -a
fsck died exit status 129

2. Frage:
Wer mir sagen kann, wo ich eine Datei ändere, und dieses anscheinend veraltete Atrribut -a herausnehme hilft mir bestimmt auch weiter, vermutlich kann dann der Check ganz regulär erfolgen.

ps:
mit dem Grubattribut

Code: Alles auswählen

fastboot

konnte ich auch nicht den Check umgehen
Vielen herzlichen Dank...

[Cae]

Kann's sein, dass du da ein Ubuntu ("Feisty Fawn", 7.04) hast, was du auf Debian Sid upgraden willst? Das wird ziemlich sicher in die Hose gehen, wie du gerade siehst.

Der Fehler kommt vermutlich aus der initrd, die ist ein gzip-gepacktes cpio-Archiv. Damit kann man sie aufmachen, bearbeiten und wieder zusammenpacken.

Gruss Cae

[safran]

hi,
danke für den Hinweis,
ich meinte jessie, habs oben korrigiert (so lebensmuede bin ich nicht)

[smutbert]

Tatsächlich läßt sich btrfs mit btrfsck (bzw. fsck.btrfs oder fsck) nur überprüfen (und reparieren), wenn es nicht gemountet ist, es darf meines Wissens nicht einmal readonly gemountet sein.

zu diesem Zwecke bietet sich zB ein von CD oder ISO Image gestartetes grml an…

[safran]

hi,

schreib Euch gerade schon von SID mit KDE aus experimental, läuft super!

ich hab in die Trickkiste gegriffen,
nach dem remount als writable

Code: Alles auswählen

cp /bin/true /sbin/fsck.btrfs

ein neustart und alles läuft super. (bootet jetzt sogar noch schneller )
sorry dass ich Eure Zeit beansprucht habe, hätte da auch früher draufkommen können.
Danke auch smutbert für den Hinweis.

[smutbert]

Dieser Trick sollte eigentlich nicht mehr notwendig sein und noch was: wenn beim Booten fastboot angegeben wird oder in der fstab in der letzten Spalte 0 steht, sollte das Dateisystem gar nicht überprüft werden.

Das Ganze und auch das mit dem fsck -a steht in /etc/init.d/checkfs.sh, das auch einige Konfigurationsoptionen aus /etc/default/rcS einliest.

[safran]

genau, da in der /etc/init.d/checkfs.sh hab ich das mit dem -a Attribut gefunden.

Code: Alles auswählen

		if [ -f /forcefsck ] || grep -s -w -i "forcefsck" /proc/cmdline
		then
			force="-f"
		else
			force=""
		fi
		if [ "$FSCKFIX" = yes ]
		then
			fix="-y"
		else
			fix="-a"
		fi
		spinner="-C"
		case "$TERM" in
		  dumb|network|unknown|"")
			spinner=""
			;;
		esac
		[ "$(uname -m)" = s390x ] && spinner=""  # This should go away
		FSCKTYPES_OPT=""
		[ "$FSCKTYPES" ] && FSCKTYPES_OPT="-t $FSCKTYPES"
		handle_failed_fsck() {
			log_failure_msg "File system check failed. 
A log is being saved in ${FSCK_LOGFILE} if that location is writable. 
Please repair the file system manually."
			log_warning_msg "A maintenance shell will now be started. 
CONTROL-D will terminate this shell and resume system boot."
			# Start a single user shell on the console]

die Datei ist noch vom August 2012, wurde also im Rahmen vom Dist-Upgrade nicht aktualisiert.
Diese Datei gehörte zum Paket initscripts, ist mittlerweile allerdings garnicht mehr drin...

Werden also von der init alle Dateien im Ordner init.d ausgeführt? Das würde erklären warum es zu diesem Vorfall kommt. Falls ich richtig liege könnte man den DEVs ja kurz bescheid geben, beim Upgrade diese Datei zu löschen

[pferdefreund]

Versteh ich das richtig, dass damit gar kein fsck mehr erfolgt ? Ob das sinnig ist ?