The error messages you posted earlier:
ext3: unknown symbol journal_get_write_access
[ snip bunch of journal_* symbols ]
ext3: unknown symbol journal_restart insmod: error inserting '/lib/ext2.ko": -1 unknown symbol in module
I guess that was typo, probably /lib/ext3.ko (ext2 is built into the kernel, not an module).
would suggest to me that the issue has more to do with modules than the filesystem. I read the above as "When I was attempting to load the ext2 module, I couldn't resolve the symbols that should be resolved in the ext3 module."
I've got similar problems (on one machine I was playing with).
2.6.9-1.667 kernel boots normally. 2.6.9-1.681_FC3 gives me bunch of unknown symbol journal_* messages. This was with "normal" (single-processor) kernel.
Upon investigating init scripts from both initrd images, they are identical (same set of device drivers loaded). One works, the other one doesn't.
Using nm, I can see that those symbols are referenced by ext3.ko, and I can also see they are defined in jbd.ko which is loaded just before ext3.ko. This is very strange.
Now, fun part.
I've copied lsmod (and two needed libs) into initrd image. I've inserted:
sleep 10 lsmod
after the "insmod jbd.ko" and "insmod ext3.ko" lines. Just to check out what is going on (maybe jbd.ko was failing to load). What happened was that with these two sleep lines, the system booted normally (note here, I also had two more sleeps because of another problem, one after loading the SCSI driver for my card, and another after udevstart, neither 2.6.9.-1.667 nor 2.6.9-1.681_FC3 would boot if they are missing, so actually there were total of 4 places in init script where I was waiting for things to catch up).
Looking at the rest of this thread, it seems that OP decided to convert his ext3 file systems to ext2, instead of persuing this issue to the end.
Seems that there is serious race condition issue while executing init script. Those "sleep 10" lines hold things back until previous steps are finished with initializing, thus preventing race condition from occuring. Why this happens with one revision of 2.6.9 kernel, and not with the other, is mistery to me.
The fact that everything works for majority of people means that race condition surfaces only on specific hardware configurations. But it is there, waiting to stab you in the back one day.
P.S.
Those two additional "sleep 10" (after loading SCSI drivers and udevstart) were there because sym53c8xx takes about 5 seconds to detect and report disks connected to the SCSI controler I have in box. By that time, init script is long executed and system concluded that there are no disks attached to the system.
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
