SEO

Hi,

in addition to my mainboard IDE controller I use a Promise Ultra100 IDE
controller for additional hard drives.

When I booted SuSE 9.2 then my boot device became /dev/hde2 instead
of /dev/hda2. So I used on the kernel command line ide=reverse and all went
fine, i.e. my boot device became /dev/hda2.

Since SuSE 9.3 with kernel 2.6.11 this seems to be broken. When I do use or
when I do not use this parameter (ide=reverse) my boot device always
becomes /dev/hde2.

Is this option no longer supported? Is there a replacement to switch the two
IDE controllers when asssigning devices to controllers?

Thanks for your help.

Regards, Manfred

Hello

I've just the very same problem
Maybe even worde, because with the bott-parameter insmod=ide-generi
I was able to install SuSE-9.3 - but now I can not boot it, becaus
neither insmod=ide-generic nor ide=reverse seems to work
Fourtunately I have a back-up of the old SuSE-9.2 installation on th
secon disk and this still boots, even with the new grub on 1st disk
Hence, I am sure that its not grub since device-map and ide=revers
still works with old kernel
It must be something with kernel-2.6.11.4 !

Have you made any progress
Any help is welcome
Marku

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

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

In such cases the initrd of SuSE-9.3 interchanges the ide-channel
(e.g
the 1st disk at 1st ide-channel becomes /dev/hde instead of /dev/hd
an
the 2nd disk at the Promise-contr. becomes /dev/hda instead o
/dev/hde)
Also the boot parameter 'ide=reverse' that some people use t
overcom
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 moun
th
root partition (update note possible) :-
c) the initial-boot (1st boot after installation/update) hangs wit
'waiting for root device' or 'kernel panic' :-(
d) For a system which has disk(s) connected to the on-boar
ide-channel
only, the installation/update works fine. However, if later on th
system is extended by additional disks at the Promise-controller
SuSE-9.3 will not boot any more, since it will look on the ne
disk
for the system's old root partition :-

The confusion starts with the configuration of the kernel shippe
wit
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 detect
the correct kernel module to load (e.g. 'via82cxxx' an
'pdc202xx_old')
But the problem is, that the loading sequence of the modules i
importan
and it seems that the installation script is loading them in simpl
alphabetical order: I.e. loading "pdc202xx_old via82cxxx" instead o
"via82cxxx pdc202xx_old". Therefore the initial ram-disk sees th
Promise channels first and the on-board ide-channel only afterwards
(probably this will also be the case with SYS chip-sets, but not wit
INTEL ones, because lexically 'sys' comes after 'pdc', too.

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

Possible solution

1) For the installation/update use the boot promp
'insmod=ide-generic
This slightly slows down the installation, but ensures that th
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 fo
installation (not for standard boot). But you can simply boo
agai
from the installation CD/DVD. Again, choose <installation
wit
'insmod=ide-generic', but then choose <boot installed system
o
the next menu (new-installation/update/boot-system/repair)
With this trick the installation script will find the correc
root partition (e.g. /dev/hda7). After confirmation the syste
will boot normally (perhaps with somewhat slower I/O)
4) In order to avoid item (3) on each following boot you have t
correct initrd's module load-sequence in /etc/sysconfig/kernel
e.g. INITRD_MODULES="pdc202xx_old via82cxxx scsi_mod sd_mo
reiserfs
into INITRD_MODULES="via82cxxx pdc202xx_old scsi_mod sd_mo
reiserfs
After this create a new initrd with 'mkinitrd' and with the nex
everything will be o.k. (even a future kernel-update should b
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 o
a 'dreary' weekend

Regards
Marku