We use the same kernel, so the analysis is wrong.

A review of the kernel source shows that the command hdx=remap is only processed by the IDE code if the IDE code is compiled in.

A 'lsmod' command on a SuSe 10.0 system shows that ide and idecore as loaded modules whereas a 'lsmod' on a system booted to the install CD does not show these modules.

A check of the kernel module directories shows both ide.ko and idecore.ko.

If the boot kernel was the same as kernel-default, there would not be an ide.ko and idecore.ko in the modules directory because they would be compiled in.

The display of the ide partition discovery during kernel boot also is different.  

When booting with the install CD (or floppies) and hda=remap command, the partitions are properly discovered and registered as partitions.  However, on first reboot with kernel-default, only the fake main EZDrive partition is discovered and found despite the hda=remap command.

Attempts to modprobe or insmod the ide and idecore modules with a parameter of hda=remap result in an error that the module doesn't know what to do with the command.

Based on all of this, the kernel-default package shipped with 10.0 is NOT the same as the boot kernel used by the CD or Floppies.  It probably was planned to be the same but someone changed the IDE parameter to Module rather than Yes.

To pass options to the IDE driver, if compiled as a module, you need to
use a little unusual syntax (for historical reasons). In your case the correct
commandline is:

        insmod ide.o options="hda=remap"

I have tried that command and it fails for two reasons.  One, ide.ko does not support any options command as a module.  Commands to the IDE subsystem only work if passed as a kernel command line and if IDE is compiled into the kernel as part of the main monolith kernel.  Two, ide.ko should not even exist because it should be compiled in as part of the kernel, not as a module.

I just checked another SuSe 10 system that is up to date with patches and ide-core.ko is still there as a module.  So even the latest update of the kernel contains the same flaw.  IDE support compiled as a M rather than a Y so it is not compiled into the prime kernel.

Additonal:

On that same SuSe system, I just did these commands:

cp /proc/config.gz ~
unzip config.gz
emacs config

and found this:

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=m
CONFIG_BLK_DEV_IDE=m

#
# Please see .....
#
# CONFIG_BLK_DEV_IDE_SATA is not set
# CONFIG_BLK_DEV_HD_IDE is not set


on my 9.1 machine (has to be 9.1 due to an overlay and also the touchpad doesn't work rite under any later version) here's how the kernel config reads:

#
# ATA/ATAPI/MFM/RLL support
#
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

#
# Please see .....
#
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_BLK_DEV_HD_IDE=y

so, 10.0 changed these settings and as a result, removed support for hdx=remap

Whoever is in charge of compiling new kernel rpms needs to change these settings back for either the next security update of 10.0 or for 10.1

NO. IDE does accept options when compiled as a module. I'm sorry to have
made a mistake in my previous comment, the name of the module should of
course have been "ide-core", not just "ide".

kernel/drivers/ide # modinfo ide-core.ko

filename:       ide-core.ko
license:        GPL
vermagic:       2.6.13-15.7-default 586 REGPARM gcc-4.0
supported:      yes
depends:        
srcversion:     45059E4EAFC713A2364EDA8
parm:           options:charp

"options:charp" means that it accepts a single parameter named "options" that
is a string. 

Note that options passed on the kernel command line are not passed down to the
modules, you'll likely need to modify the initramfs to pass that option to
IDE.

Also note that IDE has been modular since 9.3 at least, so this change is nothing new.

And finally, I don't think we officially support EZDrive interaction, so
you'll simply have to invest some of your effort to get this working.

I'm closing this as invalid, since 10.0 is no different in IDE parameter handling to previous version, and because the parameter handling is still
functional, only needs to be specified elsewhere (initramfs, instead of
the kernel command line).

This is NOT RESOLVED

If you have to close it, close it as DON'T CARE / WON'T FIX

If this was changed since 9.3, it was not noticed since 9.2 and 9.3 did not work for other reasons.

And ide-core.ko does NOT accept hdx=remap as a parameter using the Options keyword.  Go read the source of the kernel.  ide-core does not accept any module parameters.  It does not contain the code necessary to parce module parameters.

The excuse that "this is how we do it now" is also NOT ACCEPTABLE.

I will try to be civilized in the rest of my reply. However, there are only two ways to fix this.  Either fix the kernel used by SuSe or rewrite the overall Linux Kernel.  And getting a change into the Kernel, unless you are someone who knows someone who knows someone, is impossible.

So that means that unless SuSe wants to continue its increasing disregard for people who have less than the latest and greatest hardware (btw, where did support for creating floppies under something less than a working final install go?  EH? or under a non SuSe system?  EH?)  this, like the decision to ignore the history of SuSe and go off on tangents (such as dumping official support for  KDE) will result in the exact DEATH of SuSe as predicted in the offsite minutes recently posted on the mailing list.

This is an EASY fix on the part of SuSe and you just blow it off.

If the distrobution kernel won't be fixed, then make sure that the boot kernel used by the CD, DVD, and floppy all have IDE=M on them also.  That way people won't get 1 CD into the upgrade / installation and find that they have a broken and unbootable system due to one kernel supporting overlays and the other kernel not supporting them.

I'll ignore the rant, and comment on the technical stuff:

1. IDE needs to be modular for quite a number of reasons, one of them being able
to use different modules for driving the IDE controller than the classic IDE
driver (SATA and RAID drivers come to mind). This will not be changed, and if
anything, modularization will increase in other areas in the future.

2. We can't really fix the 10.0 installation CD and DVD, can we? They're already
out and pressed. The only updates that we can do are to the installed system.
You might open another bug for this issue (asking for the installation CD/DVD
to also have modular IDE), and that likely can be fixed for 10.1.

3. I've checked the source. ide.c, function module_init(), splits and
parses the "options" string, passing the chunks to ide_setup(), exactly the
same way it'd happen at bootup, if ide.c was built-in. There of course might
be a bug preventing this to work correctly - I have only read the source,
not tested it yet.

4. I've checked that the 'mkinitrd' script adds proper statements to initramfs 'linuxrc' script, which in turn parse the kernel command line and pass the options
to ide-core in proper format. ide-core also recognizes options passed to it.

5. I've also tested it. I can't reproduce your problem. I didn't do a whole installation yet, just a runtime check, though.

There is still a possibility that there is some bug somewhere preventing the code to work correctly for you, but all the functionality to preserve the kernel options used at installation time and pass them all the way down to the IDE module is there.

Please supply more information about the exact behavior on your system - 'dmesg' output at minimum, boot messages when passing 'hda=remap' on the kernel command line if possible (the initramfs part isn't archived anywhere, so you can eg. photograph it from the screen).

I'm also degrading the severity of the bug.

I looked arround at my systems and found one that is mixed.  IDE with Overlay and scsi.  So I'm loading up a minimal 9.1 system on the scsi right now, I'll get the output and settings from that and then I'll upgrade to 10.0.  Since I'm loading Linux on the scsi, I won't get into a no-boot when the IDE isn't properly detected and I can test things like adding Option ide 'hda=remap' to the modprobe.local file and rebuild the initrd.

Since this is an older machine, even a minimal load takes a little time but I should have some outputs and data by Friday (stateside time).

Thanks for doing the experimental install.

The module parameters for initramfs in 10.0 are taken from /proc/cmdline, modprobe.local isn't used. And they're taken at runtime, no pre-generation
of initramfs is necessary, except for having the ide-core module there at all.

You can try adding some undefined IDE parameter, too, for example "hda=testme",
which the IDE module will complain about being unknown: this way you'll see that
it indeed was passed to the module.

So far, here's what I have found.

If you have an overlay, you must boot with the overlay in memory and use the boot floppies to install.  This is different than 9.1 and 9.2 so perhaps something about the way that overlays are implemented in the kernel changed.  I installed both 9.1 and 9.2 by booting directly to the cdrom, passed hda=remap, and things worked just fine.

If you are upgrading, you can improve the possibility of sucess by also adding this line to /etc/modprobe.conf.local.  There isn't a module called ide but perhaps yast or grub parse the file and change how they behave?  I had about 50% sucess upgrading (boot with floppy) before ading that line and got up to about 99% sucess after that.  The remaining 1% may just be older hardware not waking up fast enough for the kernel or something.

options ide hda=remap

all the testing so far was on a system that had the IDE as a windows drive supported by the overlay and SuSe on scsi.  I'll dig out my second laptop (which is ide only with overlay and dual boot and won't boot from a cd it's so old) and risk it's install next.

And on first reboot, I'm back to where I started.  Partitions not recognized.  My guess is that on the mixed system, the IDE isn't being set up until after the main  drive is mounted and control is turned over to it from the initrd so it works but on an IDE only system, something is missing from the initrd to make it work right.

I'll resume experiamenting under Rescue mode once the manditory family holiday events are over.

I'm going on vacation tomorrow, so I'll try to reproduce this after New Year, when 
I return.

test report:

Here's what I've done/found so far using these steps:

1) boot to Rescue mode with hda=remap
2) create a directory and mount / and /boot
3) chroot to the directory where / is mounted
4) vi /etc/modprobe.conf.local and change the setting I want to test
5) mkinitrd to get the default module list
6) mkinitrd again, this time with the -m param to add ide_core and ide_disk to the list (oh and leave off thermal and fan since my laptops don't use them)
7) exit chroot
8) unmount the two partitions
9) shutdown -r and see what happens

test #1
options ide_core hda=remap
options ide_disk hda=remap

result: both modules report bad option hda

test #2
options ide_core remap

result: ide_core reports bad option remap

test #3
no options at all

result: ide_core, ide_disk, and piix all load correctly, in sequence.  Partition search reports: hda: hda1[EZD] rather than hda1, hda5, hda6, hda7, and hda8 that are reported when booting with a non modular kernel and hda=remap.


My Guess:

my guess is that something, either /proc, or something else, isn't being set up right by initrd and as a result, the initrd modprobe of the modules doesn't pick up the right options from the main kernel.  But, once initrd is done, the environment is correct (as illustrated by my tests on the mixed system).

Based on your results, 

options ide_core options="hda=remap"

should work.

However the complex procedure you describe above shouldn't be
needed, provided you passed "hda=remap" on the kernel command line
on the first installation boot.

I'm also rather surprised that ide_core/piix aren't added to the needed module list automatically. We may be missing some pci IDs for your mainboard. Can I
see your 'lspci' output?

I'll try that options line and also try to get the lspci output when I get home (I work graveyard shift).  The piix module was being automatically included by mkinitrd but it wasn't listing the ide_core or ide_disk modules so I was specifying them to force their inclusion in the initrd.  They might have been auto-included but they weren't listed in the output of mkinitrd so I was taking out insurance by telling the system to include them.

If they weren't being included automatically, I'm guessing that it is because they are not modules under rescue or install.  Once I do get the right option specified and am booting with a modular kernel I suspect that subsequent mkinitrd commands will auto-include ide_core and ide_disk since they will be listed in lsmod.

I did check /etc/grub/menu.1st and it does include hda=remap in the kernel command line.  Which is why I was so surprised when it didn't work under 10.0 like it did under 9.1 and 9.2.

upgrade sucess!

follow above rescue steps and add your suggested line to modprobe.conf.local and rebuild initrd and reboot

now to see if just adding that line to modprobe.conf.local before upgrade works or if I need to rebuild initrd to include ide_core and ide_disk. Time to risk my prime laptop (original cause of this whole thing).

I don't have a clue how to do all this on a clean install except by following all of the above rescue steps.

confirmed that upgrading with that line works.  and ide_core and ide_disk are auto-included in the initrd despite not being listed on the mkinitrd display.

for a fresh install, I suspect this will work:

wait for first reboot to fail to the shell
modprobe ide_core options="hda=remap"
modprobe ide_disk
modprobe hdcontroller (in my case piix)
exit

allow boot to finish, add required line to modprobe.conf.local, execute mkinitrd


For long term fix, Yast install will need to detect if the command line contains any of the ide_core commands and add/update the necessary line to modprobe.conf.local before mkinitrd.  yast bootloader also needs to detect if that line is used or removed, make the appropriate change to the local file, and execute mkinitrd

after some thoughts, my fix for first time clean installs won't work since those three modules will already be modprobed in and the initrd doesn't include rmmod.

I'll have to do a clean install of 10 on my secondary laptop and see if I have to do the Rescue steps to get it up and running.

I got the clean install done.  Same results until I booted to rescue and fixed the modprobe.conf.local file and rebuilt the initrd.  If I can figure out how to attach files, I have the orginal initrd and the one after the rebuild.

Created attachment 62292 [details]
original initrd

Created attachment 62296 [details]
initrd after rescue and file mod

So, I guess the next question is "what additional tests would you like me to try?"  Or is this something that can't be fixed in a simple way and if so, do you want me to write up a HOWTO that can be provided to the less than 1% of folks who use SuSe and might run in to this issue?

Is this still a problem with 10.2?

No reaction since more than 5 months, therefore closing as CANTFIX (aka WONTFIX).

If you can provide the needed information, feel free to reopen the bug.