mkreiserfs, reisersfsck einheitlich verlinken

[dbt]

Würde es was ausmachen, wenn man generell die fstools verlinkt und hier einheitilche namen hätte? Ich bin nur grade über reiserfsprogs gestolpert. Also z.B.: statt mkreiserfs->mkfs.reiserfs

Code: Alles auswählen

Index: ide-apps.mk
===================================================================
RCS file: /cvs/tuxbox/cdk/make/ide-apps.mk,v
retrieving revision 1.15
diff -u -r1.15 ide-apps.mk
--- a/ide-apps.mk	7 Jul 2009 09:54:17 -0000	1.15
+++ b/ide-apps.mk	16 Jul 2009 13:40:09 -0000
@@ -389,6 +389,8 @@
 			--prefix= && \
 		$(MAKE) && \
 		@INSTALL_reiserfsprogs@
+		@ln -sf mkreiserfs $(targetprefix)/sbin/mkfs.reiserfs
+		@ln -sf reiserfsck $(targetprefix)/sbin/fsck.reiserfs
 	@CLEANUP_reiserfsprogs@
 	touch $@
 
@@ -398,10 +400,12 @@
 
 $(flashprefix)/root/sbin/mkreiserfs: bootstrap libtool reiserfsprogs | $(flashprefix)/root
 	$(INSTALL) $(targetprefix)/sbin/mkreiserfs $(flashprefix)/root/sbin
+	@ln -sf mkreiserfs $(flashprefix)/root/sbin/mkfs.reiserfs
 	@FLASHROOTDIR_MODIFIED@
 
 $(flashprefix)/root/sbin/reiserfsck: bootstrap libtool reiserfsprogs | $(flashprefix)/root
 	$(INSTALL) $(targetprefix)/sbin/reiserfsck $(flashprefix)/root/sbin
+	@ln -sf reiserfsck $(flashprefix)/root/sbin/fsck.reiserfs
 	@FLASHROOTDIR_MODIFIED@
 
 endif

[rhabarber1848]

Prinzipiell spricht nichts dagegen, allerdings denke ich,
dass ich Reiserfs-Support zu voreilig eingebaut habe.
Irgendwann gab es einen build-Fehler, ich glaube mit
Kernel 2.6. Auch habe ich Postings gesehen, die
aussagten, dass Reiserfs auf PPC nicht stabil ist.

[rhabarber1848]

Also z.B.: statt mkreiserfs->mkfs.reiserfs

committed: http://article.gmane.org/gmane.comp.vid ... ox.scm/824

[dbt]

Schnell wie die Feuerwehr...wieder was weniger. Was den Rest angeht, wird sich zeigen.

[dbt]

Was mir noch aufgefallen ist, es sind auch tools für ext4 enthalten, aber keine Module dazu, oder läuft das anders?

[dbt]

Prinzipiell spricht nichts dagegen, allerdings denke ich,
dass ich Reiserfs-Support zu voreilig eingebaut habe.
Irgendwann gab es einen build-Fehler, ich glaube mit
Kernel 2.6. Auch habe ich Postings gesehen, die
aussagten, dass Reiserfs auf PPC nicht stabil ist.

Also ich habs jetzt mit K2.4 getestet und es scheint zumindest kein Problem zu sein, reiserfs Partitionen anzulegen. Mounten dauert gefühlt etwas länger. Schreiben/Lesen hat auch problemlos funktioniert. Hast Du mal wegen ext4 geschaut?

[rhabarber1848]

Hast Du mal wegen ext4 geschaut?

Noch nicht, aber jetzt:
http://de.wikipedia.org/wiki/Ext4

In Kernel 2.4 scheint es ext4 gar nicht zu geben, der
Haupteinsatzbereich der Dbox2 fällt somit flach.

Ext4 ist seit Kernel 2.6.19 experimenteller Bestandteil.
Dreambox nutzt 2.6.9, IPBox 2.6.17 - für beide Boxen
ist ext4 ebenfalls nicht verfügbar.

Ext4 ist seit Kernel 2.6.28 stabil, auf der Dbox2 wird
maximal 2.6.26.8 unterstützt, da in 2.6.27 arch/ppc
mit arch/powerpc zusammengelegt wurde.

Ich sehe somit keinen Sinn, ext4 für das Tuxbox CVS
nutzbar zu machen. Wenn durch das e2fsprogs-Update
ext4-Tools nun im Image landen, wäre das IMHO ein zu
behebender Fehler.

[dbt]

Ich sehe somit keinen Sinn, ext4 für das Tuxbox CVS
nutzbar zu machen. Wenn durch das e2fsprogs-Update
ext4-Tools nun im Image landen, wäre das IMHO ein zu
behebender Fehler.

Ok, also machst du das wieder raus?

[rhabarber1848]

es sind auch tools für ext4 enthalten

Nur im Yadd, aber nicht in Flash-Images, richtig?

Die ext4-Versionen sind in Wirklichkeit dieselben Dateien wie für ext2/3:

Code: Alles auswählen

# md5sum sbin/*ext*
3175fe65c1d997794a6313b71961089a  sbin/fsck.ext2
3175fe65c1d997794a6313b71961089a  sbin/fsck.ext3
3175fe65c1d997794a6313b71961089a  sbin/fsck.ext4
3175fe65c1d997794a6313b71961089a  sbin/fsck.ext4dev
9d28da5f3d1935feaa359f3afa350856  sbin/mkfs.ext2
9d28da5f3d1935feaa359f3afa350856  sbin/mkfs.ext3
9d28da5f3d1935feaa359f3afa350856  sbin/mkfs.ext4
9d28da5f3d1935feaa359f3afa350856  sbin/mkfs.ext4dev

In Flash-Images werden die ext4-Versionen gar nicht reinkopiert,
im Yadd landen sie durch "make install", stören dort IMHO aber
nicht weiter.

[dbt]

Ok, dann wär's egal.

[dbt]

Würde allgemein etwas dagegen sprechen auch für xfs_repair einen link einzuführen: fsck.xfs. und überhaupt alle fs-tools konform zu verlinken. Bei den meisten ist es ja schon so, aber falls was dazu kommt, wäre das immer passend.

Edit: erledigt. auch fürs IDE-Menü wurde das soeben angepasst, also ein cdk_update sollte dann schon sein, damit das zusammen passt!