T
tib
Guest
.
Zuletzt bearbeitet von einem Moderator:
Daniel Seuffert
Well-Known Member
http://www.spiration.co.uk/post/1278
Falls du nicht weißt, wie man Textdateien bearbeitet, hier ein Beispiel aus unserer heiligen Schrift:
http://www.freebsd.org/doc/de_DE.ISO8859-1/articles/new-users/x329.html
Falls du nicht weißt, wie man Textdateien bearbeitet, hier ein Beispiel aus unserer heiligen Schrift:
http://www.freebsd.org/doc/de_DE.ISO8859-1/articles/new-users/x329.html
T
tib
Guest
.
Zuletzt bearbeitet von einem Moderator:
Daniel Seuffert
Well-Known Member
Ähm, da steht indirekt eigentlich genau das drin, was du suchst. Du willst sichergehen, daß die ext2-Partition clean ist, also nicht direkt in die fstab, damit sie beim Booten gemountet wird, sondern script aufrufen. Also wo ist jetzt dein Problem?
This quote no parse:
"Aber ich kann nicht glauben, dass ich bin der einer Lösung für die Problematik sucht."
This quote no parse:
"Aber ich kann nicht glauben, dass ich bin der einer Lösung für die Problematik sucht."
T
tib
Guest
.
Zuletzt bearbeitet von einem Moderator:
ouTi
BSD sucker
Ignoranz hilft leider nicht.
fsck für extfs ist nicht im Base, sondern gibt es in den Ports. Die installieren nach /usr/local und daher ist zum Zeitpunkt des Systemboot kein fsck für ext2 verfügbar. Wo ist hier also das Problem? Imho stand das genauso in Daniels genannter Resource.
fsck für extfs ist nicht im Base, sondern gibt es in den Ports. Die installieren nach /usr/local und daher ist zum Zeitpunkt des Systemboot kein fsck für ext2 verfügbar. Wo ist hier also das Problem? Imho stand das genauso in Daniels genannter Resource.
T
tib
Guest
.
Zuletzt bearbeitet von einem Moderator:
R
rosa
Guest
Ahh ja:
a: Wo ist die ext2fs aus dem Topic hin.
b: In der Zeit wo Du hier rumheulst hättest Du dir 100 Lösungen geschrieben (würde ich weniger schreiben, würde dies ja schon einer Beleidigung nachkommmen).
Elessar
Huldigt dem _/\_
Wo ist jetzt eigentlich das unlösbare Problem den ext2fs_check nach /sbin zu installieren und die Startskripte entsprechend zu hacken?
Alternativ eine neue Bootarchitektur für FreeBSD implementieren, bei denen Tools vor dem mounten der Partition auf der sie liegen benutzt werden können. Have fun.
Alternativ eine neue Bootarchitektur für FreeBSD implementieren, bei denen Tools vor dem mounten der Partition auf der sie liegen benutzt werden können. Have fun.
T
tib
Guest
.
Zuletzt bearbeitet von einem Moderator:
Daniel Seuffert
Well-Known Member
Das der FreeBSD-kernel eine message spuckt, daß der Kernel tainted ist wie bei Linux ist logisch, weil er soll ja BSD-only bleiben aus guten Gründen. Ob das einen wirklich stört sei dahingestellt und kann nur von jedem Einzelnen beantwortet werden, der das tut.
Prinzipiell gehört non-BSD-license code nach /contrib, wenn man den Code aus welchen Gründen auch immer im Kernel haben wollte. Man könnte natürlich fsck_ext2fs auch vom Port zur base hin befördern, aber das lässt die base halt weiter wachsen, da finden sich heute schon über 100 Bibliotheken und 775 utilities jeglicher Art und man ist da bei FreeBSD sehr zögerlich da etwas aufzunehmen, um das Ganze nicht über Gebühr zu verfetten (was ich natürlich richtig finde, aber das habt ihr jetzt sowieso geahnt). Das man das Kernelmodul für ext2 an sich nicht in die Ports auslagert ist für mich klar: Man braucht es zu oft im Zusammenspiel zwischen FreeBSD und Linux und das hätte eine ganze Reihe von Nachteilen rein technischer Natur. Filesysteme im userland sind zwar in FreeBSD möglich und seit Jahren vorhanden, aber das will man eigentlich nicht. Zudem ist das nicht notwendig, da der code und BSD-license steht, wie übrigens hier auch schon angemerkt wurde:
http://www.bsdforen.de/showthread.php?t=13761
Man könnte natürlich auch einen BSD-license rewrite machen von fsck_ext2fs für FreeBSD, aber das muß halt erst mal einer tun. Interesant ist folgendes:
http://netbsd.gw.com/cgi-bin/man-cgi?fsck_ext2fs+8+NetBSD-current
So wie ich das auf den ersten Blick sehe, ohne genaue Detailkenntnis von NetBSD, hat sich da jemand die Mühe gemacht so etwas zu implementieren, man könnte es also nach FreeBSD mit mehr oder weniger Aufwand portieren. Das ist zwar auch wieder mehr code, aber da wäre man imho wesentlich geneigter das bei FreeBSD aufzunehmen (ja, Politik ist halt immer mit im Spiel, egal wie man darüber denken mag).
Die Tatsache, daß man sehr wenig über fsck_ext2fs und FreeBSD in Google findet, deutet darauf hin, daß die Vermutung von tib, er sei einer der wenigen, die diese Problemstellung haben, richtig ist.
Da ich gerade dabei bin: Das, was elessar oben angesprochen hat ist auch hier ausführlich besprochen worden:
http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/092365.html ff
Das Ganze alles ohne Wertung meinerseits, nur als weiterführende Information, falls das mal einer hier suchen sollte/gebrauchen kann.
Prinzipiell gehört non-BSD-license code nach /contrib, wenn man den Code aus welchen Gründen auch immer im Kernel haben wollte. Man könnte natürlich fsck_ext2fs auch vom Port zur base hin befördern, aber das lässt die base halt weiter wachsen, da finden sich heute schon über 100 Bibliotheken und 775 utilities jeglicher Art und man ist da bei FreeBSD sehr zögerlich da etwas aufzunehmen, um das Ganze nicht über Gebühr zu verfetten (was ich natürlich richtig finde, aber das habt ihr jetzt sowieso geahnt). Das man das Kernelmodul für ext2 an sich nicht in die Ports auslagert ist für mich klar: Man braucht es zu oft im Zusammenspiel zwischen FreeBSD und Linux und das hätte eine ganze Reihe von Nachteilen rein technischer Natur. Filesysteme im userland sind zwar in FreeBSD möglich und seit Jahren vorhanden, aber das will man eigentlich nicht. Zudem ist das nicht notwendig, da der code und BSD-license steht, wie übrigens hier auch schon angemerkt wurde:
http://www.bsdforen.de/showthread.php?t=13761
Man könnte natürlich auch einen BSD-license rewrite machen von fsck_ext2fs für FreeBSD, aber das muß halt erst mal einer tun. Interesant ist folgendes:
http://netbsd.gw.com/cgi-bin/man-cgi?fsck_ext2fs+8+NetBSD-current
So wie ich das auf den ersten Blick sehe, ohne genaue Detailkenntnis von NetBSD, hat sich da jemand die Mühe gemacht so etwas zu implementieren, man könnte es also nach FreeBSD mit mehr oder weniger Aufwand portieren. Das ist zwar auch wieder mehr code, aber da wäre man imho wesentlich geneigter das bei FreeBSD aufzunehmen (ja, Politik ist halt immer mit im Spiel, egal wie man darüber denken mag).
Die Tatsache, daß man sehr wenig über fsck_ext2fs und FreeBSD in Google findet, deutet darauf hin, daß die Vermutung von tib, er sei einer der wenigen, die diese Problemstellung haben, richtig ist.
Da ich gerade dabei bin: Das, was elessar oben angesprochen hat ist auch hier ausführlich besprochen worden:
http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/092365.html ff
Das Ganze alles ohne Wertung meinerseits, nur als weiterführende Information, falls das mal einer hier suchen sollte/gebrauchen kann.
Daniel Seuffert
Well-Known Member
Im Nachgang dazu interessant ist folgende Aussage von Julio M. Merino Vidal <jmmv AT NetBSD.org>, entnommen aus http://www.netbsd.org/contrib/projects.html
"At last, fsck_ext2fs should be improved because, after a crash, it detects (and attempts to correct!) far more errors than its Linux counterpart. It can end up destroying some data that ought to be correct in the first place because it thinks is incorrect."
Auch bei OpenBSD scheint man sich mancher Schwächen von fsck_ext2fs bewusst zu sein, siehe z.B. http://archives.neohapsis.com/archives/openbsd/2005-04/1545.html
Ich weiß nun nicht mangels ausreichend Zeit, ob das Zeug zuerst von NetBSD nach OpenBSD wanderte oder umgekehrt, aber man kann zumindest auf einen kurzen Blick konstatieren, das der ganze code auf allen Seiten (NetBSD, OpenBSD, Linux) seine Schwachstellen hat. Warum das Problem vorgeblich bei Linux am größten sein soll verwundert mich doch sehr bei der enormen Verbreitung von ext2 in Linux, aber da habe ich jetzt keine Lust näher nachzuforschen, man muß sich imho nicht alles reinziehen.
"At last, fsck_ext2fs should be improved because, after a crash, it detects (and attempts to correct!) far more errors than its Linux counterpart. It can end up destroying some data that ought to be correct in the first place because it thinks is incorrect."
Auch bei OpenBSD scheint man sich mancher Schwächen von fsck_ext2fs bewusst zu sein, siehe z.B. http://archives.neohapsis.com/archives/openbsd/2005-04/1545.html
Ich weiß nun nicht mangels ausreichend Zeit, ob das Zeug zuerst von NetBSD nach OpenBSD wanderte oder umgekehrt, aber man kann zumindest auf einen kurzen Blick konstatieren, das der ganze code auf allen Seiten (NetBSD, OpenBSD, Linux) seine Schwachstellen hat. Warum das Problem vorgeblich bei Linux am größten sein soll verwundert mich doch sehr bei der enormen Verbreitung von ext2 in Linux, aber da habe ich jetzt keine Lust näher nachzuforschen, man muß sich imho nicht alles reinziehen.