root fs from ext3 to ext2
mares25
hab RH 7.2 standardinstallation und bräuchte hilfe beim rückstieg von ext3
auf ext2 (für jene die mir das ausreden wollen - siehe "warum der wechsel"
ganz unten)
bisher bin ich folgendermassen vorgegangen:
bestehende partition unmounten - dann mit "tune2fs -O ^has_journal" das
journaling abgedreht - fsck.ext2 /dev/sdxx - in /etc/fstab von ext3 auf ext2
geändert. verlief alles ohne probleme bis auf das rootfs. um das zu
konvertieren bin ich dann mit der install-cd im rescue modus hochgefahren
und das system hat mein rootfs nach /mnt/sysimage gemountet mit der meldung
ich könnte ja wenn ich dann mal fertig bin mit chroot auf mein rootfs
wechseln. hab dann ein umount auf /mnt/sysimage versucht jedoch kein erfolg
da "device busy". kann das überhaupt sein obwohl es ja gar nicht in
verwendung war? zu dem zeitpunkt war ja nur eine konsole offen und in der
befand ich mich in / .
naja, lange rede kurzer sinn. wer kann mir helfen auch mein rootfs wieder
auf ext2 umzustellen. bin für jede anregung dakbar.
cu
reinhard
warum der wechsel: es gibt da einen bug in verbindung mit DB2 UDB 7xx dem
multiprozessor standard kernel von RH7.2 und ext3 filesystem. das ganze kann
dann zb. so schlimm werden das nur noch ein reboot die maschine wieder in
den griff kriegt (zu finden in den RH erratas). das einfachste wär natürlich
gewesen ein kernelupdate zu machen (ist leider nicht möglich da ein anderes
programm nur mit den libraries funzt welche beim 7.2er standard sind).
Alexander Bartolich
> [...] wer kann mir helfen auch mein rootfs wieder auf ext2 umzustellen.
> bin für jede anregung dakbar.
Wo ist das Problem? Bei einem sauber ungemounteten ext3 ist das Journal
leer und es kann bedenkenlos als ext2 gemountet werden. In /etc/fstab
einfach ext3 durch ext2 ersetzen und neu starten, fertig.
reinhard
hast du das schon mal in der prxis mit dem rootfs gemacht oder versuchst
hier nur eine theorie wiederzugeben.
aber danke für die rasche antwort.
lg
reihard
Alexander Bartolich
> [...] hast du das schon mal in der prxis mit dem rootfs gemacht oder
> versuchst hier nur eine theorie wiederzugeben.
Schön. Du bist also paranoid genug für diese NG.
Ich mache das regelmäßig auf einem Multiboot-System wo der älteste
Teilnehmer eine SuSE 6.0 (aber mit 2.2.0-Kernel) ist. Solange man
immer saubere Shutdowns baut, ist das kein Problem.
reinhard
ok. dann mal sehen was du zu folgendem sagst.flogende ausgangssitutaion:
- RH 7.2 mit kernel 2.4.7-10
- alle partitionen mit ext3 aufgesetzt.
/dev/sda1 /boot
/dev/sda2 /tmp
/dev/sda3 /var
/dev/sda5 /usr
/dev/sda6 /home
/dev/sda7 /
/dev/sda8 swap
nach einem clean shutdown mit 1-ten RH cd hochgefahren im rescuemodus ohne
das bestehende system zu mounten. dann folgendes:
tune2fs -O ^has_journal /dev/sda1
fsck.ext2 /dev/sda1
tune2fs -O ^has_journal /dev/sda2
fsck.ext2 /dev/sda2
tune2fs -O ^has_journal /dev/sda3
fsck.ext2 /dev/sda3
tune2fs -O ^has_journal /dev/sda5
fsck.ext2 /dev/sda5
tune2fs -O ^has_journal /dev/sda6
fsck.ext2 /dev/sda6
tune2fs -O ^has_journal /dev/sda7
fsck.ext2 /dev/sda7
dann alle nach /mnt/sysimage gemountet (entsprechend)
zb. mount -t ext2 /dev/sda7 /mnt/sysimage
wieder hat alles geklappt. ich kann meine files sehen und darauf zugreifen.
während dessen hab ich dann unter /mnt/sysimage/etc/ die fstab bei allen
von ext3 nach ext2 geändert. beim nächsten neustart bekomme ich dann einen
fehler vom jounaldaemon der sich darüber mokiert das es auf sda7 kein
journal gibt? erst nachdem ich neuerlich mit dem rescue mode hochgefahren
bin, wieder ein tune2fs -j /dev/sda7 um ein journal anzulegen gemacht hab
und dann wiederum in der fstab nur für /dev/sda7 von ext2 auf ext3 geändert
hatte, hat der bootvorgang wieder geklappt.
also, wie sieht nun deine lösungsmöglichkeit dafür aus das rootfs wieder auf
ext2 zu bekommen wobei es mir ja eigentlich darum geht das journaling zu
deaktivieren da ja das eigentlich die ganzen probleme hervorruft.
lg
reinhard
Alexander Bartolich
> [...] bekomme ich dann einen fehler vom jounaldaemon der sich
> darüber mokiert das es auf sda7 kein journal gibt?
Ok, muss zugegeben das ich mit deinem konkreten Fall noch nicht
gearbeitet habe. Ich betreibe zwar Partitionen abwechselnd als
ext2 und ext3, aber immer von komplett verschiedenen Systemen aus.
Zu Übungszwecken habe ich also eine Konvertierung von / auf einem
Red Hat 7.3 probiert:
perl -p -i.bak -e 's/ext3/ext2/' /etc/fstab
init 1
(diverse kill und killall)
umount -a
mount /dev/hdc1 -o remount,ro
tune2fs -O ^has_journal /dev/hdc1
shutdown -r 0
Und stolpere dann in kudzu hinein, weil keine Maus angehängt war.
Wurscht. Nicht mehr wurscht war dann die Meldung 'Updating /etc/fstab',
und einer anschließenden Ausbesserung von ext2 nach ext3.
In updfstab(8) steht zwar absolut nichts davon, und mir ist auch nicht
klar, wo denn die Information, dass es sich eigentlich um ein ext3-FS
handelt stehen, aber so ist Voodoo eben nun mal.
Ich habe dann mit ntsysv kudzu deaktiviert, und siehe da die Wiederholung
der Aktion hinterlässt bleibende Wirkung. Very strange indeed.
Matthias Kahlert
>
> Wurscht. Nicht mehr wurscht war dann die Meldung 'Updating /etc/fstab',
> und einer anschließenden Ausbesserung von ext2 nach ext3.
>
> In updfstab(8) steht zwar absolut nichts davon, und mir ist auch nicht
> klar, wo denn die Information, dass es sich eigentlich um ein ext3-FS
> handelt stehen, aber so ist Voodoo eben nun mal.
Woher weiss denn der kernel, was für ein Dateisystem / ist? Aus
/etc/fstab kann er ja wohl nicht lesen, solange / nicht gemountet ist.
Meines wissens gibts da irgendeine Heuristik, mit der ein ext3-enabled
kernel entscheidet, ob / ein ext3 ist.
Ich würde mal einen kernel ohne (einkompilierten) ext3-support
probieren.
--
Matthias
reinhard
> reinhard schrieb:
>> [...] bekomme ich dann einen fehler vom jounaldaemon der sich
>> darüber mokiert das es auf sda7 kein journal gibt?
>
> Ok, muss zugegeben das ich mit deinem konkreten Fall noch nicht
> gearbeitet habe. Ich betreibe zwar Partitionen abwechselnd als
> ext2 und ext3, aber immer von komplett verschiedenen Systemen aus.
> Zu Übungszwecken habe ich also eine Konvertierung von / auf einem
> Red Hat 7.3 probiert:
>
> perl -p -i.bak -e 's/ext3/ext2/' /etc/fstab
> init 1
> (diverse kill und killall)
> umount -a
> mount /dev/hdc1 -o remount,ro
> tune2fs -O ^has_journal /dev/hdc1
> shutdown -r 0
>
> Und stolpere dann in kudzu hinein, weil keine Maus angehängt war.
> Wurscht. Nicht mehr wurscht war dann die Meldung 'Updating /etc/fstab',
> und einer anschließenden Ausbesserung von ext2 nach ext3.
>
> In updfstab(8) steht zwar absolut nichts davon, und mir ist auch nicht
> klar, wo denn die Information, dass es sich eigentlich um ein ext3-FS
> handelt stehen, aber so ist Voodoo eben nun mal.
noch mehr strange is das es anscheinend auch nur bei großen disks bzw.
großen raids ( >100 GB) ein problem is, bei kleinen (habs gestern in einer
vmware kurz ausprobiert - ging ohne probs mit 4 GB virtueller disk).
> Ich habe dann mit ntsysv kudzu deaktiviert, und siehe da die Wiederholung
> der Aktion hinterlässt bleibende Wirkung. Very strange indeed.
very strange - bin voll deiner meinung. ich würde ja gerne RH 7.3 vewenden
jedoch wie schon erwähnt sind's die libaries (ála glibc usw.) welche bei
7.3 zu neu sind. leider, den mit 7.3 hätt ich keine probleme mehr mit ext3
bzw. mit dem journaling.
lg
reinhard
Andreas Krennmair
> Alexander Bartolich wrote:
> >
> > Wurscht. Nicht mehr wurscht war dann die Meldung 'Updating /etc/fstab',
> > und einer anschließenden Ausbesserung von ext2 nach ext3.
> >
> > In updfstab(8) steht zwar absolut nichts davon, und mir ist auch nicht
> > klar, wo denn die Information, dass es sich eigentlich um ein ext3-FS
> > handelt stehen, aber so ist Voodoo eben nun mal.
>
> Woher weiss denn der kernel, was für ein Dateisystem / ist? Aus
> /etc/fstab kann er ja wohl nicht lesen, solange / nicht gemountet ist.
> Meines wissens gibts da irgendeine Heuristik, mit der ein ext3-enabled
> kernel entscheidet, ob / ein ext3 ist.
Die einzige "Heuristik", die ich gefunden habe, ist folgende:
fs/super.c: mount_root():
--- SNIP ---
for (p = fs_names; *p; p += strlen(p)+1) {
struct file_system_type * fs_type = get_fs_type(p);
if (!fs_type)
continue;
atomic_inc(&bdev->bd_count);
retval = blkdev_get(bdev, mode, 0, BDEV_FS);
if (retval)
goto Eio;
sb = read_super(ROOT_DEV, bdev, fs_type,
root_mountflags, root_mount_data);
put_filesystem(fs_type);
if (sb) {
blkdev_put(bdev, BDEV_FS);
goto mount_it;
}
}
panic("VFS: Unable to mount root fs on %s", kdevname(ROOT_DEV));
mount_it:
--- SNIP ---
ext3 wird einfach nur vor ext2 in der Liste stehen...
--- SNIP ---
nodev rootfs
nodev bdev
nodev proc
nodev sockfs
nodev tmpfs
nodev shm
nodev pipefs
ext3
ext2
cramfs
vfat
iso9660
nodev nfs
nodev autofs
reiserfs
nodev devpts
minix
--- SNIP ---
Ja, genau. QED.
mfg, ak
--
As Internet technology advances, new things become suddenly possible. Take
content management. Just five years ago, it was almost impossible to waste a
million dollars building a Web site.
-- David Walker, http://www.shorewalker.com/pages/cms_woes-1.html
reinhard
ich habs glaub ich schon mal erwähnt ich kann keine gravierenden änderungen
am system vornehmen. kompilieren schon garnicht. für andere vorschläge bin
ich ganz ohr.
greets
reinhard
Alexander Bartolich
> Die einzige "Heuristik", die ich gefunden habe, ist folgende:
>
> fs/super.c: mount_root():
Mhh. Bei linux-2.4.20-xfs steckt der Code in init/do_mounts.c
und nennt sich "mount_block_root(char *name, int flags)".
Die entscheidende Stelle ist IMHO aber wo anders.
$ expand -t 2 ./init/do_mounts.c | nl -bap
305 static void __init get_fs_names(char *page)
306 {
307 char *s = page;
308
309 if (root_fs_names) {
310 strcpy(page, root_fs_names);
311 while (*s++) {
312 if (s[-1] == ',')
313 s[-1] = '\0';
314 }
315 } else {
316 int len = get_filesystem_list(page);
317 char *p, *next;
318
319 page[len] = '\0';
320 for (p = page-1; p; p = next) {
321 next = strchr(++p, '\n');
322 if (*p++ != '\t')
323 continue;
324 while ((*s++ = *p++) != '\n')
325 ;
326 s[-1] = '\0';
327 }
328 }
329 *s = '\0';
330 }
"int get_filesystem_list(char * buf)" ist fs/super.c bearbeitet
dort eine dynamische Liste "struct file_system_type *file_systems;".
Irgendwie logisch, wo doch heutzutage alle Dateisysteme als Module
vorliegen.
Interessanter finde ich da schon den ersten Zweig des if,
den mit "root_fs_names". Da gibt es dann noch das da:
295 static char * __initdata root_fs_names;
296 static int __init fs_names_setup(char *str)
297 {
298 root_fs_names = str;
299 return 1;
300 }
und das da
302 __setup("rootflags=", root_data_setup);
303 __setup("rootfstype=", fs_names_setup);
Und tatsächlich, der taucht in Documentation/kernel-parameters.txt auf:
# root= [KNL] root filesystem.
# rootflags= [KNL] set root filesystem mount option string
# rootfstype= [KNL] set root filesystem type
Tja. Müsste man mal probieren.
Alexander Griesser
> very strange - bin voll deiner meinung. ich würde ja gerne RH 7.3 vewenden
> jedoch wie schon erwähnt sind's die libaries (ála glibc usw.) welche bei
> 7.3 zu neu sind. leider, den mit 7.3 hätt ich keine probleme mehr mit ext3
> bzw. mit dem journaling.
Ein neuer Kernel bedeutet ja nicht, dass die glic und andere
Userspace-Libraries auch upgedatet werden. Insofern sehe ich da also
kein Problem.
ciao,
--
| .-. | CCNA Alexander Griesser <tu...@tuxx-home.at> | .''`. |
| /v\ \ http://www.tuxx-home.at -=- Linux 2.4.18-xfs / : :' : |
| /( )\ | echo "pgpkey" |mail tu...@tuxx-home.at | `. `' |
| ^^ ^^ `-------------------------------------------------' `- |
mares25
news:slrnb6n3fd...@tuxx-home.at...
> * reinhard <luky...@gmx.net>:
> > very strange - bin voll deiner meinung. ich würde ja gerne RH 7.3
vewenden
> > jedoch wie schon erwähnt sind's die libaries (ála glibc usw.) welche
bei
> > 7.3 zu neu sind. leider, den mit 7.3 hätt ich keine probleme mehr mit
ext3
> > bzw. mit dem journaling.
>
> Ein neuer Kernel bedeutet ja nicht, dass die glic und andere
> Userspace-Libraries auch upgedatet werden. Insofern sehe ich da also
> kein Problem.
>
> ciao,
> --
erst in einer höheren kernel version gefixt ist welche, und jetzt kommt der
spassige teil, auch ein update der glibc bedeutet.
sollte es aber einen multiprozessorkernel geben bei welchem der bug mit dem
ext3 bzw. mit dem journaling gefixt ist ohne das man vom standard RH7.2
sonst nix updaten muss - nur her damit.
aber ansonsten bin ich für alle anregungen offen - wobei, mitlerweile wurde
der server komplett neu mit ext2 aufgesetzt.
thx
reinhard