"ide=reverse" not working on Suse 9.3?

Hi,

I'm having a problem with suse 9.3 detecting my hdds correctly, so I though about using the command ide=reverse. That way hde, hdf, hdg would become hda, hdb and hdc.
Any thoughts about that? Am I doing something wrong or ide=reverse is no longer working?

Thanks

Hello, try at the installation command line enter "insmod=ide-generic" without the quotes and see if that works.

What type of system do you have, how many drives, etc. Need a little more info on your system specs to help you.

Probably the key is a bug in the SuSE-9.3 installation script:

For boards with VIA chip-set and Promise-controller the installation
or update to SuSE-9.3 may lead to severe boot problems, if there are
hard-disks connected to the on-board ide-channels (/dev/hda,b,c,d) as
well as to the Promise-controller (/dev/hde,f,g,h).

In such cases the initrd of SuSE-9.3 interchanges the ide-channels (e.g.
the 1st disk at 1st ide-channel becomes /dev/hde instead of /dev/hda and
the 2nd disk at the Promise-contr. becomes /dev/hda instead of /dev/hde).
Also the boot parameter 'ide=reverse' that some people use to overcome
such renumber-problems does not work with the shipped initrd.
Possible complications are:

a) an installation may introduce wrong device names :-/
B) an update from an older SuSE-installation can not find or mount the
root partition (update note possible) :-(
c) the initial-boot (1st boot after installation/update) hangs with
'waiting for root device' or 'kernel panic' :-((
d) For a system which has disk(s) connected to the on-board ide-channels
only, the installation/update works fine. However, if later on the
system is extended by additional disks at the Promise-controller,
SuSE-9.3 will not boot any more, since it will look on the new disks
for the system's old root partition :-(

The confusion starts with the configuration of the kernel shipped with
CD/DVD: vmlinuz-2.6.11.4-20a-default (hopefully 'a' is not 'alpha'?).
The primary ide driver (kernel CONFIGS_IDE/IDE_GENERIC/BLK_DEV_IDE)
are now loadable modules, i.e. are not part of the kernel any more.

In principle this is a good idea and the installation script detects
the correct kernel module to load (e.g. 'via82cxxx' and 'pdc202xx_old').
But the problem is, that the loading sequence of the modules is important
and it seems that the installation script is loading them in simple
alphabetical order: I.e. loading "pdc202xx_old via82cxxx" instead of
"via82cxxx pdc202xx_old". Therefore the initial ram-disk sees the
Promise channels first and the on-board ide-channel only afterwards !
(probably this will also be the case with SYS chip-sets, but not with
INTEL ones, because lexically 'sys' comes after 'pdc', too.)

Even worse is, that you can not correct this swapped channels at the boot
prompt, because the kernel parameters like 'ide=reverse' come too late
(since the swapping happens in the initrd already, which loads the kernel)

Possible solution:

1) For the installation/update use the boot prompt 'insmod=ide-generic'
This slightly slows down the installation, but ensures that the
basic installation will find the disks in proper sequence.
2) If the following initial-boot does not find the root partition:
Don't panic !
3) Unfortunately the parameter 'insmod=ide-generic' only works for
installation (not for standard boot). But you can simply boot again
from the installation CD/DVD. Again, choose <installation> with
'insmod=ide-generic', but then choose <boot installed system> on
the next menu (new-installation/update/boot-system/repair).
With this trick the installation script will find the correct
root partition (e.g. /dev/hda7). After confirmation the system
will boot normally (perhaps with somewhat slower I/O).
4) In order to avoid item (3) on each following boot you have to
correct initrd's module load-sequence in /etc/sysconfig/kernel:
e.g. INITRD_MODULES="pdc202xx_old via82cxxx scsi_mod sd_mod reiserfs"
into INITRD_MODULES="via82cxxx pdc202xx_old scsi_mod sd_mod reiserfs"
After this create a new initrd with 'mkinitrd' and with the next
everything will be o.k. (even a future kernel-update should be fine,
since this will not change the INITRD_MODULES sequence any more.

Maybe there is an easier way, but for me this was the happy end of
a 'dreary' weekend.

Regards,
Markus

My friends Asus A8V Deluxe, based on VIA K8T800, for A64 S939, the installation and all the updates went fine, with 9.2 before and 9.3 now.

Hi Markus:
I just want to thank you for posting this solution. I was in the same boat with a Soyo SY-KT400 DRAGON Ultra with two standard onboard IDE ports controlled by a VIA chipset and two additional Highpoint based IDE ports, and hard and optical drives plugged in everywhere. I wouldn't have figured out your solution and diagnosis in a million years. Your solution worked perfectly for me, and I think your diagnosis is absolutely correct.
Searching for and finding solutions like yours reinforces my opinion that the Open Source Community is where it is at. Thanks!!

Bill W