Forums

Resolved
0 votes
Hi. Lt me start by saying, I am completely out of patience. I have lost more, in terms of both hardware and data, in the last two days than most people own, total. My office is in shambles, a result of a BS sequence of events combined with my own failures of anger management. If anybody is looking for some broken monitors, splintered wood, non-rectangular PC cases, or shards of broken circuit board, I'm your guy. There was even a small fire, so if charred sheetrock is your thing, give me a call.

Now, to where I am now.

Before my primary server decided, out of the blue, that it wasn't going to boot (all indications suggested HDD failure but ALL of its HDDs pass every smart test and when I boot with centos live, all of my data is there), I was already in the process of setting up a new server. That new server was a pain as well, what with the motherboard manual contradicting itself, and about $150 worth of hardware that it allegedly supported but doesn't... but, after much torture, I got it built, and booting, and followed my previous setup instructions to get it configured mostly the way I need it.

Well, my new drive controller came in the mail, and I put it in, and now I can't boot. Going back to the other controllers is stupid, as this is the one I intend to use, and it should work. I suspect that reinstalling clearos from scratch with this controller in place should get it booting again, but my instructions/notes are on the OTHER server (the old one, that died) and I can't very easily access that until THIS one is working.

So I need someone with more linux-fu to tell me what to type to get this thing to find the drives on the new controller. I'm sure enough googling, swearing, poking, prodding, and praying could get me there, but I DO NOT have that kind of patience. If I don't have this thing up by the end of tomorrow it's going in the driveway, through the window of course, likely with the keyboard, mouse, and monitor (a 40" TV) still connected.

The new controller is a Dell SAS 6. The drives are all SATA, and the HBA BIOS lists them. I get the kernel selection menu, and it even tries to start gnome -- but sits at a blank screen for a while, then gives me several pages of

[#####.######] dracut-initqueue[339]: Warning: dracut-initqueue timeout - starting timeout scripts


and then finally settles on

[#####.######] dracut-initqueue[339]: Warning: /dev/disk/by-id/md-uuid-47095d76:fe1c9045:5e


ya know what I'm done with typing that nonsense out. Here's a picture.

I don't know what this is or where I am or what to do. My assumption is that whatever part of linux enumerates hard drives doesn't know about this lsi adapter, because heaven forbid we build in a failsafe "if I can't find the adapter just use bios" mode.

Please help.
Thursday, July 23 2020, 05:02 AM
Share this post:
Responses (9)
  • Accepted Answer

    Friday, July 24 2020, 10:42 PM - #Permalink
    Resolved
    0 votes
    chroot /mnt/sysimage
    mkinitrd --force --with=mptsas /boot/initramfs-3.10.0-1127.13.1.el7.x86_64.img 3.10.0-1127.13.1.el7.x86_64


    system has now booted.

    thanks for the numerous kicks in the right direction!

    Nick Howitt wrote:

    This is the recovery document, but it doesn't say a lot. It does give you an idea as to where it lands you. mptsas is in /usr/lib/modules/3.10.0-1127.13.1.el7.x86_64/kernel/drivers/message/fusion/mptsas.ko.xz. For initramfs, all I can do is google.
    The reply is currently minimized Show
  • Accepted Answer

    Friday, July 24 2020, 07:25 PM - #Permalink
    Resolved
    0 votes
    This is the recovery document, but it doesn't say a lot. It does give you an idea as to where it lands you. mptsas is in /usr/lib/modules/3.10.0-1127.13.1.el7.x86_64/kernel/drivers/message/fusion/mptsas.ko.xz. For initramfs, all I can do is google.
    Like
    1
    The reply is currently minimized Show
  • Accepted Answer

    Friday, July 24 2020, 06:10 PM - #Permalink
    Resolved
    0 votes
    https://fedoramagazine.org/initramfs-dracut-and-the-dracut-emergency-shell/

    okay. so... dracut lets me add/remove modules to initramfs. initramfs needs to contain mptsas, and doesn't. It's not clear how, from within the dracut "emergency shell," one installs a module that only exists on a volume that does not exist.

    In rescue mode, I could operate dracut the normal way, but I suspect I'd be altering the modules in the rescue boot's initramfs, not the one I need.

    It is mentioned that a new initramfs is generated every time a new kernel is installed, and presumably this includes whatever modules are necessary to boot.

    Is ClearOS going to get pissed off at me if, from within the rescue boot, I yum reinstall kernel ?
    The reply is currently minimized Show
  • Accepted Answer

    Friday, July 24 2020, 05:40 PM - #Permalink
    Resolved
    0 votes
    okay.

    modprobe: FATAL: Module mptsas not found.


    I tried several other things that I thought would load it also, and received various different wordings of "there's no such file" in response.

    I strongly suspect the filesystem I'm in at this "emergency mode" prompt is not my normal /

    (1) it can't be, as my normal / is on drives that "don't exist"
    (2) my normal /, accessed with the rescue boot option, has /usr/lib/modules/3.10.0-1127.13.1.el7.x86_64/kernel/drivers/messages/fusion/mptsas.ko.xz

    As a DOS guy, my next instinct is to copy that file from the rescue thing to a flash drive, and then try to do something with it in emergency mode... but I don't know what that "something" is.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 23 2020, 12:36 PM - #Permalink
    Resolved
    0 votes
    Nick Howitt wrote:

    Did you try with:
    hpsa.hpsa_simple_mode=1 hpsa.hpsa_allow_any=1


    Yes, that is what I tried, both by pressing 'e' at the menu and also by booting the rescue one and adding it to grub. It had no effect either way. Same sequence, same problem.

    Speaking without knowledge, but I have a strong feeling you cannot just move disks created with mdadm to a RAID controller card. I believe one of the dangers of using a RAID controller card (or on-board RAID) is, if the motherboard or RAID controller goes down, you could be forced to source an identical (or compatible) one to recover your disks.


    You are correct. However, I think you may be mistaking the SAS 6 for the PERC 6. The PERC is raid-only, completely lacks any jbod mode, and would certainly cause the problem you're focused on. The SAS 6 does support raid 0 and raid 1 (no other raid modes) but defaults to jbod mode, which I am using. In my application, it is just an 8-port sas hba, and the drives are presented raw to the OS... or at least to the BIOS, since the OS doesn't seem to want to see them right now :)

    Just in case you ever encounter that problem you mentioned (raid controller failure) and have data you need to get back, Active(R) FileRecovery recognizes a lot of different raid volumes and can recover most of them. It's not a 100% thing, but if you find yourself (or someone you know) facing that, give it a shot. Personally I'll stick with software raid, simply as mdadm seems to work identically on every system and the resulting volumes seem to be portable.



    I am at work now, I will try your further instructions when I get home.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 23 2020, 10:49 AM - #Permalink
    Resolved
    0 votes
    Link corrected - https://forums.centos.org/viewtopic.php?f=49&p=201448. Did you try with:
    hpsa.hpsa_simple_mode=1 hpsa.hpsa_allow_any=1
    Speaking without knowledge, but I have a strong feeling you cannot just move disks created with mdadm to a RAID controller card. I believe one of the dangers of using a RAID controller card (or on-board RAID) is, if the motherboard or RAID controller goes down, you could be forced to source an identical (or compatible) one to recover your disks.

    mptsas is a regular kernel module. I don't know what I'm doing here, but try https://unix.stackexchange.com/questions/442943/centos-7-persistent-module-loading-at-boot and https://www.systutorials.com/how-to-make-centos-linux-to-load-a-module-automatically-at-boot-time/
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 23 2020, 10:13 AM - #Permalink
    Resolved
    0 votes
    Hi,


    My major raid array is comprised of 4TB drives and hasn't been moved over yet. It was created on the old server using mdadm, and when I boot that box with CentOS Live on USB and open the "Disks" utility, the array is there, and can be mounted and browsed... so it at least moves from ClearOS to CentOS Live easily enough, I'm hoping for similar luck moving it to the new ClearOS box.

    That said, I visited the centos.org url you provided. It asked me to log in. I presume the corrected link to be https://forums.centos.org/viewtopic.php?f=49&p=201448 but unfortunately, presuming you meant the two hpsa.blah things to add to the boot line, this did not resolve my issue.

    I did note, however, that choosing the 'rescue' option from the grub menu does result in a running system -- a curious fact indeed. I presume this hpsa/cciss talk is about kernel modules so, just for shits and giggles, I threw "lspci -k" at it to see what rescue mode was using...

    01:00.0 SCSI storage controller: Broadcom / LSI SAS1068E PCI-Express Fusion-MPT SAS (rev 08)
    Subsystem: Dell SAS 6/iR Adapter RAID Controller
    Kernel driver in use: mptsas
    Kernel modules: mptsas


    so... if my understanding of what is going on here is correct... can I somehow get the regular boot options to use mptsas?

    Or am I way off base here, and that's not what's wrong?
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 23 2020, 07:46 AM - #Permalink
    Resolved
    0 votes
    If you have moved the disks across from you old server, you may have a problem as the RAID arrays could have been created completely differently. Anyway, you can try. First of all it looks like RedHat dropped support for the controller in EL7, so this will affect ClearOS as well. It should still be possible to get it going thanks to ElRepo if it uses the cciss driver. First of all try this method. This just enables an older driver and it might be enough to get you going. You could then switch to the cciss driver from ElRepo but note that you will need to keep the driver upgraded if any new kernel requires it. ElRepo do have a neat yum plugin which should be able to manage that for you. Otherwise stick with the hpsa driver.

    If that does not work, have a read of this and see the instructions at the end. You will need to modify the instructions to pull from https://elrepo.org/linux/dud/el7/x86_64/ and you will have the same issue keeping the driver updated.
    The reply is currently minimized Show
  • Accepted Answer

    Thursday, July 23 2020, 07:02 AM - #Permalink
    Resolved
    0 votes
    Hi Michael,

    I'm not a linux-guru, but maybe this helps you on the way.
    Your system is booting, but can not find the disk.
    Login, by typing your system password
    Check you /etc/fstab and look which UUID is linked to /boot


    blkid | grep UUID=

    and check which UUID is linked to your bootdisk (/dev/sda1)

    then
    nano -w /etc/fstab

    and check what is mentioned in the 2nd line (after thelines with #)
    with me it is : UUID=5ca75b19-2f33-47be-b0d5-afaff650ca94 /boot xfs defaults 0 0

    Check also :
    https://linuxhint.com/uuid_storage_devices_linux/
    The reply is currently minimized Show
Your Reply