Description of problem: On a workstation with a hardware RAID 10 as boot device (RAID 5/6 SAS 6G) the required driver (megaraid_sas) is not automatically loaded. You can select it manually so that the installation continues and you will finally have a bootable system. But whenever you make later changes to the kernel and/or bootloader via mcc you have to call dracut manually to include the driver again in initrd. Otherwise your system does not boot any more. Another kernel module which is not automatically loaded and included in initrd is "st" although mcc can detect tape drives. But since you won't boot from a tape drive at least this one is not critical. It simply shows that there are some discrepancies between detecting hardware and including proper kernel modules via mcc. Version-Release number of selected component (if applicable): How reproducible: It happens always after changing/updating/upgrading the kernel without calling dracut before rebooting. Steps to Reproduce: 1. Install Mageia 2 on a RAID 10 boot device. 2. Change kernel from "desktop" to "server" or upgrade to the latest kernel. 3. Reboot - if you have a rescue disk at hands...
What's the output of "rpm -q dracut" ? When you say "the required driver (megaraid_sas) is not automatically loaded", is this at install time when detecting hard drives or after booting the installed system, when adding a new kernel?
Keywords: (none) => NEEDINFOCC: (none) => mageia, thierry.vignaudSource RPM: (none) => dracut
(In reply to comment #1) > What's the output of "rpm -q dracut" ? # rpm -q dracut dracut-017-16.1.mga2 # > When you say "the required driver (megaraid_sas) is not automatically loaded", > is this at install time when detecting hard drives or after booting the > installed system, when adding a new kernel? First it happens at install time. After successful installation Mageia will boot. Most likely it will continue to boot as long as you do not make any kernel changes. But when I installed "kernel-server" after the installation and tried to reboot the system hung. I had to add megaraid_sas manually before I could successfully boot again. The same happened when Mageia provided the upgrade kernel (3.3.6 -> 3.3.8). I re-installed Mageia 2 several times until I found out about dracut. My final way to a nicely running system was: 1. Install Mageia 2 from DVD with manual selection of megaraid_sas. 2. Install updates after first reboot -> newer kernel! 3. Call dracut to include megaraid_sas (and st for tapes). 4. Reboot. 5. Switch from kernel-desktop to kernel-server. 6. Call dracut to include megaraid_sas (and st for tapes). 7. Reboot. 8. Enable nonfree repositories and install nvidia drivers. 9. Reboot. 10. Have fun with Mageia! Step 1 and 2 never worked together (no updates during first installation). Installing nvidia drivers was only possible after the installation of the final kernel.
Can you attach the file resulting from running the following command: lspcidrake -v>pci.txt
I suspect it's either the modules.order issue in kmod (bug #5833) and/or the issue where ldetect fails to detect more than 100 devices (bug #8320)
(In reply to comment #3) > Can you attach the file resulting from running the following command: > lspcidrake -v>pci.txt I attached the file. Interestingly, mptsas for the LSI controller on the mainboard is listed (SAS1068E) but megaraid_sas for the LSI controller on one PCIe card not.
Created attachment 3236 [details] lspcidrake -v > pci.txt
Yeah, we were limited to 100 PCI devices. This has been fixed for next Mageia (Mageia3 beta1) The fix has been backported in ldetect as a release candidate in the 'Core Updates Testing' medium (which is not enabled by default)
@Thierry : Can you confirm this bug is already solved ? Roelof
CC: (none) => r.wobben
(In reply to comment #8) > @Thierry : Can you confirm this bug is already solved ? > > Roelof I will be back at work on January 14th and I will try to install the backported ldetect on my system then. At least I could verify whether this version works with my system.
Fine, we wait till you report back after the 14th. Thanks for the reply. Roelof
(In reply to comment #8) > @Thierry : Can you confirm this bug is already solved ? > > Roelof Yes. But for now it's an update candidate, not yet a released update. See bug #8373.
(In reply to comment #10) > Fine, we wait till you report back after the 14th. > Thanks for the reply. > > > Roelof I have just installed ldetect version 0.12.1.1-5.mga2 from 'Core Updates Testing' including dependencies (rpmdrake). But the behaviour did not change. Somehow the limit of 100 devices is kept: # lspcidrake |perl -pi -e 'undef $_ if /^hub|^usb/../eof/'|wc -l 100 #
what's the output of: rpm -q ldetect lib{,64}ldetect0.12
(In reply to comment #13) > what's the output of: > rpm -q ldetect lib{,64}ldetect0.12 # rpm -q ldetect lib{,64}ldetect0.12 ldetect-0.12.1.1-5.mga2 Das Paket libldetect0.12 ist nicht installiert lib64ldetect0.12-0.12.1-5.mga2 # Package libldetect0.12 is not installed. Is it required on a x86_64 system?
Blocks: (none) => 8373
Blocks: 8373 => (none)Depends on: (none) => 8373
It's not (but as I didn't know what arch you were running, I provided a "universal" command). You need to update ldetect library, ldetect by itself only contains lspcidrake who use the library...
(In reply to comment #15) > It's not (but as I didn't know what arch you were running, I provided a > "universal" command). > You need to update ldetect library, ldetect by itself only contains lspcidrake > who use the library... I have just upgraded from kernel 3.3.8-server to 3.4.24-server. Before rebooting I had to manually adjust /boot/config and /boot/Sytem.map to the new kernel. But after verifying that the required SAS modules (megaraid_sas) were automatically included in initrd I could reboot the system without problems. So, it seems that this version of ldetect solves some of my kernel upgrade problems. At least I did not have to call dracut manually. The module st for tape drives is still not included in initrd. But the device /dev/nst0 exists and can be used. Maybe one of the SAS-drivers loads it later because in my case it is a SAS-tape drive.
I believe /boot/config and /boot/System.map symlinks are updated on boot. They should reflect the *running* kernels, not the "preferred" kernel. So you shouldn't have had to adjust those files. Do we even need /boot/config these days anyway? Can't we use /proc/config.gz for anything we would need /boot/config for? Or is it just too ingrained in various things (e.g. dkms and such like across several pkgs)?
Changing component: IIUC this is not an installer bug but rather a ldetect issue.
Source RPM: dracut => ldetect
Component: Installer => RPM Packages
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD