initrd creation

[admin1979]

Yes with the 2 workarounds , installation can be completed. But post installation I found that , many of the hardware is showing as unknown devices in the o/p of lspci.
Please find the attach for the relevant logs.

Our aim is not exactly to complete the installation but to find out the solution to the problems faced inorder to complete the installation.

So I guess , now I am trying to find out the exact drivers (*.ko ) which will detect the harddisk and cdrom. Once found , will include them in initrd and recreate the initrd and then try the installation.
Wonder from where I would find the exact drivers.
How about using the drivers already present in SP2. What is required to be done if I am to include these drivers in SP1 ?
Recompilation ??


Please suggest.


Thanx,
Admin

[admin1979]

Apology, Missed the attachment.

[Matti_Kurkela]

> But post installation I found that , many of the hardware is showing as unknown devices in the o/p of lspci.

If lspci cannot identify a PCI/PCI-X/PCIe device, that only means the device IDs of that device are not included in pci.ids file (which is normally at /usr/share/mic/pci.ids). You can fix that by downloading the latest pci.ids file from http://pciids.sourceforge.net and replacing the distribution's standard pci.ids file with it.

The device IDs of the hardware that each driver can run are included in the driver modules.

In this case, it looks like the ahci + libata drivers are the key: In SLES 10 SP2 they contain the necessary updates to recognize the SATA interfaces. That allows the standard sr_mod + cdrom drivers to use the interfaces to access the CD-ROM drive, and the standard sd_mod driver to access the HDDs.

> How about using the drivers already present in SP2. What is required to be done if I am to include these drivers in SP1 ?
Recompilation ??

Recompilation at the very least. If you try it, you may find that the drivers of the SLES 10 SP2 will depend on some internal improvements of the kernel: you may have to copy those features too, and integrate them into the SLES 10 SP1 kernel. This is normally called "backporting". It is one of the reasons why major Linux distributors like Novell and RedHat employ some full-time Linux kernel developers.

The kernel modules are often tied to the exact kernel version they're compiled for: if the compile-time option CONFIG_MODVERSIONS is enabled (when compiling both the kernel and the modules), this restriction is somewhat relaxed, but it still won't allow you to use a module from a newer kernel version that needs a routine that doesn't exist or has a different in-kernel interface in your older kernel. So it's possible that you'll have to recompile the entire kernel to backport the driver.

Personally I haven't ever tried to do what you're planning. Yes, it is within the realm of possible. It might even be easy; or it might require you to become a skilled kernel debugger to accomplish it.

But I would strongly suggest re-applying your customisations to SLES 10 SP2, or even to SLES 11 instead of hanging onto SLES 10 SP1. Making and troubleshooting user-space modifications is easier than with kernel-space modifications.

The hardware manufacturers will keep producing newer hardware models, and there is no guarantee at all that a newer hardware can run a version of OS that is already old when the hardware model is introduced. As time goes on, eventually you won't be able to replace your current hardware when it fails with new off-the-shelf models, but instead you'll have to find replacements through services like eBay. Sooner or later you must move on anyway: it might be better to follow the development of your distribution of choice, rather than to be forced to re-implement everything after multiple major releases.

Also remember that if you use a customized kernel (e.g. with driver modules you've backported yourself) and have a kernel-related problem with it, you should expect Novell support to say something like "Please try to reproduce the problem with a standard SLES kernel, then we'll see about it." Anything above and beyond that will be at Novell's discretion.

MK

[admin1979]

Hi there,

One question for you please,

This is the diff output for 2 different initrds ( 1 of SP1 and 1 of custom-made)

There is only difference in the entry of aic7xxx.

If possible can you elaborate how it will affect the installation?

# diff module.config module.config_orig
105,107c105,107

< megaraid,LSI Logic MegaRAID,,scsi_mod aic7xxx,,1
< megaraid_mbox,LSI Logic MegaRAID Mailbox,,megaraid_mm scsi_mod aic7xxx,,1
< megaraid_sas,LSI Logic MegaRAID SAS,,scsi_mod aic7xxx,,1

---
> megaraid,LSI Logic MegaRAID,,scsi_mod,,1
> megaraid_mbox,LSI Logic MegaRAID Mailbox,,megaraid_mm scsi_mod,,1
> megaraid_sas,LSI Logic MegaRAID SAS,,scsi_mod,,1


Thanx,
Admin