Bug 59966

We've seen some random instances of the ext3 module not loading...  but the
double checks are a) you are using a beta 1 boot disk b) do you see a warning on
tty3 about the ext3 module not being found?

I'm definitely using a beta1 boot disk.  I'll check the error messages later
this afternoon to see if the module's loading or not

I've seen this error in pre-beta1 trees, however, the hampton beta1 always had
ext3 on my text boxen ... in each of the missing cases the failure to see this
during partitioning corresponded to a failure to load the ext3 modules (and
corresponding error message on VC3) ...

I won't mark this bug as a duplicate of mine (which is closed, BTW) as you may
be seeing something different from me ... :)

What bug # is yours?

59337 :)

I'm a moron.  My search was omitting closed bugs ;-)

I'm not sure if it's the same bug or not.  Was it determined why yours was not
loading ext3?

Here's what I'm seeing:

* modules to insert raid0 raid1 xor raid5 msdos jbd ext3 reiserfs jfs xfs lvm-mod
* module(s) jfs xfs not found
* inserted /tmp/raid0.o
* inserted /tmp/raid1.o
* inserted /tmp/xor.o
* failed to insert /tmp/raid5.o
* failed to insert /tmp/msdos.o
* failed to insert /tmp/jbd.o
* failed to insert /tmp/ext3.o
* inserted /tmp/reiserfs.o
* inserted /tmp/lvm-mod.o
* load module set done

So, ext3 fails to load b/c jbd fails to load.  If I extract ext3 and jbd from
the modules.cgz and attempt to insmod them, insmod jbd fails with a segmentation
fault and insmod ext3 fails with unresolved symbols (as it should) and then
segmentation faults for good measure anyway ;-)

Unfortunately, there's no strace or anything like that in busybox, so I'm not
sure what else to do to debug this ;-)

If you're doing an NFS install, you can put an strace binary on an NFS export
and grab it from there to run strace.

Actually, the segfault was caused by pilot error.  I was forgetting that insmod
requires absolute paths to modules to load....  Apparently the insmod in the
installer segfaults on any error.

At any rate, once I was using insmod correctly, both jbd and ext3 loaded and
worked fine for mounting ext3 filesystems (I have a 7.2 install with some ext3
partitions on that machine), but disk druid still refuses to allow partitions to
be formatted as ext3 (presumably b/c it's caching the filesystems it knows about).

So, now I don't know why anaconda initially failed to load the modules, since
they load manually just fine, and I can't format ext3

Couple of questions...

1) Does "rmmod" return about 7 lines, or about 30? No arguments, just rmmod.
   (don't ask!)
2) Just to be clear "insmod ext3.o" seg faults, but if you uncompresss the
   modules and "insmod /tmp/ext.o" it works fine, right?

You know, telling someone not to ask is the surest way to get them to ask ;-)

rmmod returns about 30 lines of options.  It reports that it's insmod version 2.4.13

As for your other question:

* insmod ext3.o reports missing symbols (as it should) and segfaults 
* insmod jbd.o ; insmod ext3.o works
* zcat modules.cgz | cpio followed by insmod /path/to/jbd.o ; insmod
/path/to/ext3.o works

I've reproduced everything that kaboom is seeing.  Beta hardware ID
62 but without the CD-ROM drive; no mouse connected (and mouse disabled in
BIOS).  TUI install (booted from beta1 bootnet disk using "LILO: expert", "Yes"
to driver disk, selected Etherlink III, and did net. install using HTTP).  The
ext3 module failed to load in VT2 (but ext3.o was the *only* one that didn't
load); insmod ext3.o works from VT3.  rmmod returns about 30 lines.  More
details on request; can retest as needed.

Are we seeing any of this with the Beta 2 disks?

I haven't seen it, but I've only gotten to do one install....

deferred to next installer release

Since we used the same loader for Hampton as we were using all along, I think
this was fixed since it didn't crop up later in the Hampton cycle