FC3 SMP builds do NOT contain ext3 drivers in the build!!!!

[Aleksandar Milivojevic]

C. Linus Hicks wrote:
> 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 at pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7