I'm trying to install on a laptop in TUI (since GUI hangs the display). When I
get to the disk druid step to format partitions, the only options available are:
ext3 should definitely be there as well, but it's not.
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?
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
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.
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
I've reproduced everything that email@example.com 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