Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a bizarre issue. We have a Dell PowerEdge server with RHEL4 up7 installed and working without much issue.
Problem is that we just upgraded from RH9 with a RocketRaid 1740 sata raid controller installed and need it to work perfectly as it is the core of our imaging/scanning system.
I downloaded the latest opensource driver source from highpoint-tech.com, compiled and "insmod rr174x.ko" the driver. It works great.
HOWEVER, on every reboot it disapears and I have to manually rerun "insmod rr174x.ko"
I've also noticed that when I "modprobe rr174x" it gives me the following message, even after insmod has been run and the RAID shows up just ducky.
added /lib/modules/2.6.9-78.0.1.ELsmp/kernel/drivers/scsi/rr174x.ko: to /lib/modules/2.6.9-78.0.1.ELsmp/modules.dep directly after the other scsi devices were listed.
This gets the device recognized on boot, BUT breaks GRUB on reboot when an entry is put in the /etc/fstab to mount /dev/sda1 to /RAID (as I need it to be)
I'm hoping someone out there can at least give me some clues, as this system is a backbone to our daily work flow. It's very important that we correct this issue because of the way this system integrates with other servers in our network.
I stumbled upon this thread while researching another issue.
First I need to know if the driver automatically installed a entry in /etc/modprobe.conf. My guess is that there is no reference to this module, thus rendering the automatic load obsolete. If there is an entry in /etc/modprobe.conf I would try to rebuild my dependency list using depmod and rebooting. If that still doesn't work, try a remake of your ramdisk.
Please list cat out /etc/modprobe.conf and post it in this thread.
Also, it may not hurt to probe all of your working kernel modules by issuing;
Here is the thing, I see no reference to your module rr174x in /etc/modprobe.conf, this could be an issue. I'm sorry that I didn't take in consideration that your system is in production, generally posts of this nature would reside in the Enterprise Linux section of the forums. I understand the system has to stay up, issuing depmod -a will not bring your system down, so it will not hurt to probe all modules and rebuild a dependency list; I would advise to do this now.
About adding an entry to this module in /etc/modprobe.conf, this is generally quite easy besides one little tricky part. You need to know which slot the SCSI card is that you are working with.
You will need to determine where the card is physically attached on the server, using the conventional computer counting method (0=1, 1=2 etc.) and set your scsi_hostadapter and reference your module. ( A good way to check and see where this is install is by a long-listing on the /proc/scsi/ directory.)
Lets say the card is in the second PCI slot on the server, here is how it would work.
/etc/modprobe.conf
# add the following line for your card Y = the integer representing the
# physical connection of this card.
alias scsi_hostadapter_Y rr174x
This will tell the kernel taht hostadapter_Y will use the module rr174x.
Or we could do this they easy sloppy way and add insmod rr174x to /etc/inittab or /etc/rc.d/rc.local
Last edited by misconfiguration; 09-02-2008 at 02:02 PM.
I have noticed something else while following your link, you are using RHEL 4, the driver only references the RHEL 5 version; did you build this from source or install the pre-compiled package for RHEL 5?
Yes this was built from the opensource edition of the driver.
before I follow your instructions I just want to clarify:
at this moment, because I added the entries into modules.dep the device is being recognized on boot. I know that's a hack, but should I remove those entries before doing this fix? -just looking for clarification because it IS a production box.
the other issue is that the device is not recognized at the time /etc/fstab is ran during boot, even though the device is present at startup. would this work around that or just correct it? Either way ideally I would like to put the entry in the fstab so there are no surprises.
Also i ran depmod -a I will reboot at first opportunity.
If you have manually added anything to modules.dep I would personally remove those entries and let depmod handle the proper linking of modules, the modules.dep file is there to ensure the modules are loaded, unloaded and linked in the proper order. Remove your manual entries and run your depmod -a; this will automatically add any needed entries to modules.dep. After all is done and the modules are installed successfully you shouldn't run into the issue in /etc/fstab anymore, ideally we want the modules to be loaded into the kernel before local filesystems are mounted. I am confident this action will help you, if it doesn't we could always create a new ramdisk image while your module is already loaded.
Let me know the outcome, feel free to email me with any questions//concerns.
looks good. but then it occured to me, way back when I started having this problem running "modprobe rr174x" on the reboots when it wasnt loading gave me:
FATAL: Module rr174x not found.
But insmod rr174x.ko from the appropriate dir worked fine. out of curiosity I ran modprobe again and it still gives me the error. Bare in mind I have not resrtarted as yet, but this to me seems like a clue-in to why its not loading properly. If Insmod did it's job correctly, it should be showing up.
I did add the following to /etc/modprobe.conf
alias scsi_hostadapter_1 rr174x
which should point at the correct driver, provided it can find it... thoughts?
Yes adding the alias in /etc/modprobe.conf should load the proper driver providing that the module will be able to be found. After the depmod was created I would go ahead and reboot, to ensure everything booted fine. Remember modinfo <module> will give you a more detailed explanation of your loaded modules.
What happens if you do a modprobe -a rr174x, and modprobe -l |grep rr174x?
Well, I finally had a chance to reboot the server. unfortunately we are back to square 1.
again during boot it failed on the fstab line to mount /dev/sda1 to /mountpoint citing unrecognized device.
As usual I had to drop to prompt, comment out the line in /etc/fstab and reboot
Then once started go to the dir where I have the .ko mod stored and insmod rr174x.ko (which gives no output, but works.) Out of curiosity I ran modprobe again and received the same FATAL: Module not found error as before.
Then remounted the device and it works fine. However the fact that this has to be done every time there is a reboot is not acceptable. I guess we will have to look into the ramdisk options?
Just to sum things up; currently when the module is loaded and you run modprobe -a and then a modprobe -l |grep rr174x.ko does it still give you the FATAL: error? Also, what directory is the module you're loading located?
Keep in mind that the RAMDISK we will build will pass the module information to the kernel before sysinit is called.
In order to rebuild the RAMDISK, I would advise the following.
1.) Ensure the module rr174x.ko is loaded and working, determine by using lsmod, modprobe and modinfo.
2.) Do the following:
cd /boot
mv initrd-$(uname -r).img initrd-$(uname -r).img.bak # This is for safe keeping
mkinitrd -f initrd-$(uname -r).img $(uname -r)
reboot (when you can schedule the appropriate downtimes)
Please note: until you get this module to properly load into the kernel before /etc/fstab gets called you will continue to have this problem.
Last edited by misconfiguration; 09-03-2008 at 02:25 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.