Created attachment 4480 [details]
TTY1 without modprobe dm-raid

Created attachment 4481 [details]
ls /dev/mapper without modprobe dm-raid

Created attachment 4482 [details]
TTY3 without modprobe dm-raid

Created attachment 4483 [details]
TTY4 without modprobe dm-raid

OK, so basically the old initrd presumably loaded a whole bunch of stuff related to kernel modules and just left them loaded. I guess we need to replace that somehow or make sure stage2 can do it's own modprobbing as needed. I don't think stage2 includes any kernel modules so the bind mount of /usr will completely mask the ones available in the initrd even if stage2 does try to run modprobe.

I wonder if instead of bind-mounting /tmp/stage2/usr to /usr we could use overlayfs/unionfs or similar so the stage2 stuff takes precedence, but we can still have the underlying stuff when nothing overrides it.... Thomas, Thierry, WDYT?

Or perhaps I've missed something that caused stage1 to install modules that is no longer working after my rework. Any thoughts on where dm-raid was loaded previously would be useful before I go digging into the code...

stage2 is kernel agnostic (aka it doesn't contains any kernel modules and thus doesn't have to be rebuild on new kernel)
stage1 contains the stage2 loader as well as the kernel modules.

Stage1 loaded the modules:
- needed for input (USB, HID, ...)
- needed to found the stage2 depending on the chosen method
  (network, disk, ...)

Stage2 see the stage1 tree and thus when it needs to load a module, it access the /lib/modules left by the stage1.

Having said that, I don't think:
- stage1 ever supported loading stage2 from raid array and
  thus never loaded any raid modules
- you broke stage2 ability to load modules, else this would
  have been reported quite a lot earlier and you would have seen it.

A quick test shows that stage2 is still able to load modules

Stage2 always has taken care of loading raid modules when needed.

So before going forward, I would have requested the reporter to:
- plug a USB key
- run the "bug" command
- attach the report.bug.xz he founds on his USB key to this bug report
(instead of attaching photos)

But as for "dm-raid" I would wonder:
- whether it was autoloaded by dmraid
- whether is it a new kernel module (which is not)
- whether another kernel module loaded it as a dep
  (which doesn't look it's the case)
- whether it was not needed previously for dmrakdnot)

Keywords: (none) => NEEDINFO

Created attachment 4484 [details]
we could just load dm-raid when initializing dmraid

Obviously I forgot to remove the original line before posting that patch :-)

Also it would be interesting for someone to test regular soft raid.
If it's failing too due to missing dm-raid module, we would need to load it into devices.pm in init_device_mapper() instead, when loading 'dm-mod'

Thomas: any though about this?

Summary: Stage2 don't ask for the raid driver need modeprobe dm-raid in stage1 => Stage2 don't ask for the raid driver (need "modprobe dm-raid")
Source RPM: (none) => drakx-installer-stage2

Dear all,

@Thierry

I can't give you the report.bug.xz because the "bug" command line don't work at home.

I have the message:
Error: Can't have a partition oustide the disk!
Error: Can't have a partition oustide the disk!
Error: /dev/sdb: unrecognised disk label
ask_from_list: empty list
interactive::ask_from_listf_raw() called from /usr/lib/libDrakX/interactive.pm:282
interactive::ask_from_listf() called from /usr/lib/libDrakX/install/commands.pm:404
install::commands::bug() called from /usr/bin/bug:16
(eval)() called from /usr/bin/bug:14


This message with 3 different usb key. It's for that I use the photos.

Stéphane.

(In reply to Thierry Vignaud from comment #7)
> stage2 is kernel agnostic (aka it doesn't contains any kernel modules and
> thus doesn't have to be rebuild on new kernel)
> stage1 contains the stage2 loader as well as the kernel modules.
> 
> Stage1 loaded the modules:
> - needed for input (USB, HID, ...)
> - needed to found the stage2 depending on the chosen method
>   (network, disk, ...)
> 
> Stage2 see the stage1 tree and thus when it needs to load a module, it
> access the /lib/modules left by the stage1.

Probably something to chat to you about later but I'm a little confused as to how it did this in the past... previously as far as I could tell /bin, /sbin, /lib, /lib64 and /usr would all be rm -rf'ed and then symlinked form stage2... I do things a little bit differently now, but the principle is the same. I'm just not sure how stage2 could load modules when they've been nuked already. I guess I must be missing something in my understanding of how the old system works.

Also not sure how bind mounting /usr to /tmp/stage2/usr allows access to the old /usr/lib/modules/kernel* folder tree to load more modules.

> A quick test shows that stage2 is still able to load modules
> 
> Stage2 always has taken care of loading raid modules when needed.


I guess this is the part I don't yet understand! I'll poke about a bit and take this discussion off-bug while I get my brain in order :)

(In reply to Colin Guthrie from comment #11)
> I guess this is the part I don't yet understand! I'll poke about a bit and
> take this discussion off-bug while I get my brain in order :)

OK, so I've done some playing and stage2 CANNOT load modules. There is a /usr/lib/modules and a /usr/lib/firmware sylink in stage2 that point to /modules and /firmware as needed.

This is now somewhat broken as these top-level folders do not exist and thus modprobe fails.

I can tweak stage1/init again to be able to cope with this.

*** Bug 11601 has been marked as a duplicate of this bug. ***

CC: (none) => tablackwell

OK, so this problem should be fixed in the new drakx-installer-binaries (-images needs rebuilt too after)

*** Bug 11605 has been marked as a duplicate of this bug. ***

CC: (none) => eeeemail

M4B1 round 4 x86_64
Install still crashes due to failed target partition mount; unable to mount either ext3 or ext4 target partition from the classic DVD graphical installer.
Curiously mount does succeed manually now from the F2 # prompt. 
 'mount /dev/sda4 /mnt -o acl,noatime' gives a readable mount containing lost+found and media directories.
Installation is frozen at this point as no target

Dear,


I testing today, it's solve for me.

With my configuration with dmraid.

I send from cauldron.

Thanks.

Stephane.

Closing

Status: NEW => RESOLVED
Resolution: (none) => FIXED