Stuck Changing perc 6 to perc H200 raid Controller on installed system

Again i am confused. This driver is it still this one?:
https://elrepo.org/linux/dud/el8/x86_64/dd-megaraid_sas-07.719.03.00-1.el8_6.elrepo.iso

I tried to combine this driver with an 8.6 almalinux minimal stick in the procedure. (2 sticks. A minimal almalinux 8.6 stick B. driver above)
Didn’t work The list of ‘potential drivers’ came up. it booted straight to rescue mode. It did found my linux system. No network. Weird When i did this listing:

/lib/modules/*/extra/

I did see a line with mptsas something.
Also I did a mount to the usb stick where the RPM file for the driver was listed.
I tried to do "dnf install ./(mount)/…file… But it started listing unavailable repo…
because there is no network.
pinging 1.1.1.1 gives ‘no network’

desperated I copied back the backupped `initramfs bak kernel file and after that I tried again: "dracut -f /boot/initramfs-…

I tried to reboot the system. This time it give kernel error.
I will try to whole thing again, but now a 9.1. minimal stick. I didn’t understand about the driver version. I will use this one:
https://elrepo.org/linux/dud/el9/x86_64/dd-mptsas-3.04.20-2.el9_1.elrepo.iso

Am I correct you say this could repair my 8.6 system following the procedure?

My example system requires “mptsas”. Therefore, in my example was “mptsas”.

If your system requires “mpt3sas”, then that is what you should use and look for, not “mptsas” or “megaraid”.

If you do have Alma 8.6, then ideally you try to repair it with 8.6’s installer and drivers. If you can see disk and have network with 9.1’s installer, then you can try to do the rescue with it.

Thanks, just in time. I just wanted to start the 9.1 set.
I will keep on trying with the 8.6 set then.

We are in business… Used the mptsas as linked. I see the driver disk device selection now!
I will update you.

update:
Like you mentioned. I can’t select sda (number 2 in this menu)
It prompts every time again. "# to select , r -refresh, c continue
everytime it repeats again. Tried refresh many times but i will go on

update 2:

conclusion of this evening;

I manage to pick up this driver:
https://elrepo.org/linux/dud/el8/x86_64/dd-mptsas-3.04.20-7.el8_6.elrepo.iso
by exactly doing what is in the video.

After it runs in rescue. 1. find linux installation.
Sorry can’t find it. You don’t have any linux partition.
Press enter to go shell:

ping 1.1.1.1
Network is unreachable.

So i can’t chroot to /mnt/sysroot.
It doesn’t see a linux partition, so i guess the driver is not working.

update 3:
after another couple of attempts I saw this error after booting rescue environment started:
“modprobe module floppy not found” ,but the menu to choose the usb device (dev/sda)
still came up.

After loading it can’t find the linux system and no network available. Is
https://elrepo.org/linux/dud/el8/x86_64/dd-mptsas-3.04.20-7.el8_6.elrepo.iso
correct for:
https://pci-ids.ucw.cz/read/PC/1000/0072
and a minmimal rescue almalinux version 8.6 ?

As @jlehtone noted, you need mpt3sas, not mptsas.

https://elrepo.org/linux/dud/el8/x86_64/dd-mpt3sas-39.100.00.00-1.el8_6.elrepo.iso (for EL 8.6)

Thanks.

I just finished to try the procedure according to jlehtone’s instructions with driver
https://elrepo.org/linux/dud/el8/x86_64/dd-mpt3sas-39.100.00.00-1.el8_6.elrepo.iso (for EL 8.6)

(mpt3sas)

The menu comes up. it list devices 1 to 8. Mine is 1 /dev/sda.

I chose in order: 1 -1 -c-c (There is no other way to get out of the menu but to give another c.) 1. select /dev/sda 1. select /dev/sda 1. toggle /dev/sda. c. continue
(then it lists the complete list again) c. continue (I already toggled the right device.)

-rescue environment boots.

  • search linux system works.
    -chroot to the system.

-no network error by pinging 1.1.1.1

I mounted the driver usb to /mnt/test in the system.

Tried: sudo dnf localinstall /dev/sda/…src…/ dir. sample_file.rpm

it gives repository errors on a https location. Possible there is no network.

Tried: sudo rpm -i /dev/sda/…src…/ dir. sample_file.rpm
gives a user error, it uses root instead.

Tried:
/lib/modules/*/extra/

It doesn’t list the mpt3sas driver.

  • Disable all repos with “–disablerepo=*”
  • If you mount to /mnt/test, then path to package file starts with that
  • “localinstall” is deprecated alias for “install”
  • The name of package starts probably with “kmod-mpt3sas*”
sudo dnf --disablerepo=* install /mnt/test/.../kmod-mpt3sas*.rpm

(I can’t recall what the ... part of the path is.)

it was just ‘…’ to skip the complete path. I understand you and will try now this “-- disablerepo=*” paramater and update you. A big Thanks for your patience.

in business at the moment…!

installing: kmod-mpt3sas

complete!

ls -alh /lib/modules/*/extra/

-kmod-kvdo
-megaraid_sas …AND!..
-mpt3sas

I will go for the
https://support.hpe.com/hpesc/public/docDisplay?docId=sf000081208en_us&docLocale=en_US

procedure now and will update you.
I assumed it is best to copy the backupped original from
( # cp /boot/initramfs-4.18.0....................img /boot/4.18..............bak.$(date +%m-%d-%H%M%S).img)
back to the original file, is that correct? (last dracut -f try didn’t succeed. To avoid any unseen variables .)

update3:

Hope is rising. i finished the dracut -f procedure.

Then I did:

lsinitrd /boot/initramfs-4.18.0-372.26.1.el8_6.x86_64.img | grep sas

It lists:
/extra/mpt3sas
and
/extra/mpt3sas/mpt3sas.ko !!

No network by pinging 1.1.1.1 however…yet.
Ok, I think I am about to try and restart the installed system here.

The dracut writes a new initramfs*.img file. If something exists with that name, then it is overwritten. The previous file is not used in any way. Therefore, that copy is not necessary.

Jukka…:grinning:

Eureka!
You have become my personal hero. After today.
That T310 perc H200 installed almalinux system which I considered
to be a wreck 3 weeks ago… It runs!

Also thank you all others and Toracat for sharing the video after I gave up…

This was the most complex support help I ever got remote and with success.
Wow!

After a reboot the system started doing a selinux re definition of all files that were now on the new H200 SAS virtual partition. At that stage, I was getting really hopeful, since it meant it already had past the critical point.
another restart and the system was back in business! It was like a dream to see the login screen and be able to login from GUI.
Do i sound like a computer nerd now? Probably I do, but I am so happy I kept my work which took me serious time.

It is now only a matter of using gparted, modify partitions and editing the /etc/fstab file configure the new space on the partition, small desktop settings and the system already proposed an incoming update!
Network works again. Still I don’t understand why not during usb rescue session almalinux 8.6. But heck, does it matter now!?

Last question, jukka,
If you would have been me, and you would have exchanged a sas controller card on a almalinux installed system, what would you had done to prevent all this mess i got myself into? (Yes not change the card I guess…but besides that?)

Great respect. :grinning: :grinning: :grinning: :grinning: :grinning:

1 Like

Congratulations!

I suppose you are now running Alma 8.6. When you update the system to 8.7, make sure you also update the kmod-mpt3sas package. This happens automatically if you have installed elrepo-release because the elrepo repository is enabled by default.

Usually, elrepo’s kmods survive kernel updates, meaning there is no need to update kmod upon every kernel update, thanks to the kABI-tracking feature. However in a major/minor release update (for example going from 8.6 to 8.7), kABI breakage can occur. In those cases, elrepo publishes updated kmod packages. Just be vigilant when there is a kernel update.

In the old days I would have been scared to replace the controller. Not because of drivers, but because uncertainty of compatibility – would both controllers support the array metadata that is on the drives? (If the new controller does not, it can’t assemble the array.) That side of things has improved.

In principle one could look up the device ID but most trivial method is by lspci and then the controller has to be plugged into some machine. Not necessarily any drives connected though; just to see the ID and whether there is driver support. Then install the driver to system before replacing controller.

The initramfs is a filesystem in a file. The bootloader loads the kernel and initramfs. Kernel uses files (drivers) to find devices and activate them so that it can mount the / filesystem.

The installer’s initramfs has all drivers (that are included in the distro). It is fat. That way the installer can run on all (supported) hardware.
The initramfs of an installed kernel has only the necessary drivers in it. “Lean and mean”. It is possible to tell the dracut to include “unnecessary drivers”, when you run it explicitly. That way you can inject the controller’s driver before you have one on the system.

Would I have done that preparation? Probably not. An “oh hell, lets just try” followed by solving the inevitable mess, while not wise, looks the likely path.