RAID array doesn't auto-start

1. offizieller Beitrag

    Can anyone here possibly help me sort out why my iSCSI LUN refuses to auto-start after a reboot. Everytime I reboot I have to "mdmadm --assemble /dev/md0, "vgscan", "vgchange -ay and /etc/init.d/iscsitarget restart" to get everything working again. I have mdadm providing /dev/md0 to lvm which provides a LV to ietd which serves the LUN.



    Does anyone have any idea where I might start looking for an issue?



    edit: seems like it could be related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568838

    • Offizieller Beitrag

    Don't see anything wrong there, I was looking maybe some disk of the array with partitions but they look Ok.
    Other than that you will have to look at some smart values of each disk. What's the brand/model of the disks?
    Each time you reboot does cat /proc/mdstat indicate that a disk is out or other sort of distress?
    Also look at dmesg errors for mdadm at startup.

    Zitat

    Each time you reboot does cat /proc/mdstat indicate that a disk is out or other sort of distress?


    mdstat just shows that the array's not been started yet. otherwise there's no hardware cause that i can see being an issue. all the smart states for the drives are in good order as well. there are no glaring errors in dmesg either. it just seems that the steps that I perform manually after boot-up are not being executed during boot as I expect them to.


    pastebin of dmesg.....
    http://pastebin.com/9hjKDHJ8

    • Offizieller Beitrag

    Can you tell me if your rootfs is mounted read only, with the mount command?


    Other than that you can try the backport kernel 3.16 that can be installed with omv-extras. Be aware that iscsi doesn't work with backport kernel. You need to grab the source from iscsitarget and build the modules against the new kernel to make it work.


    Let me know if you're still interested and I'll give you the instructions

    nope, it's mounted RW...



    Zitat

    Other than that you can try the backport kernel 3.16 that can be installed with omv-extras. Be aware that iscsi doesn't work with backport kernel.


    This setup WAS working. I'm not sure what changed. I only recently installed the 1.13 release in the past week or so. Are you certain that the BPO update is necessary? If so, albeit with trepidation, I suppose we can proceed with the BPO/modules install if you provide the steps.

    that order looks correct. the link to iscsitarget seems to missing though??



    The last things I installed were actually v19 mpt2sas LSI drivers for the SAS cards via SSH and, libcups2 via the OMV GUI update.

    Zitat

    The driver module what's the name? Mpt2sas?


    Yes, I've crossflashed 3x Dell H310's with LSI IT mode F/W.



    The problem started after the last reboot. This following the install of the LSI module and libcups2.

    • Offizieller Beitrag

    Looking again at dmesg what i found strange is no LVM scan after md0 starts. According to dmesg md0 is present and available. But you also mentioned that you have to re-assemble the array per reboot.


    The default kernel 3.2 comes with mpt2sas version 10, backport kernel 3.16 comes with mpt2sas version 16. Youre are using version 19.


    You can try and install the backport kernel and boot that one, see if it makes a change. This kernel boot will not load the version 19 driver.

    Zitat


    You can try and install the backport kernel and boot that one, see if it makes a change. This kernel boot will not load the version 19 driver.


    I'd like to reserve that course of action as a last resort. The whole reason why I installed the v19 module with the stock kernel was to correct this problem...
    http://pastebin.com/tssnuE2d


    If we exhaust all possibilities with the stock kernel then I'll gladly take the procedure from you on how to install the backport kernel and compile the ietd modules for it. Again though, I'd like to reserve that as a last resort if possible.



    Zitat

    So can you check if LVM starts or indicates an error at /var/log/boot


    Here's the boot log...



    It looks like it tries to start right after udev does its' thing, but doesn't find any VG's. It looks to me like there's a race condition caused by udev taking longer to generate all the links in /dev/* than LVM is willing to wait for? Am I reading that right? This was my line of thinking when I suggested the link to the debian bug report above, since I built this OMV installation on Wheezy.


    I have since taken a shot in the dark and tried applying the patch in that bug report, even though it's not for the same version of lvm2 in OMV without any change. I have since reverted that change/patch. After that, I started this thread here.

    Well that seems like only part of the problem. That may help the LVM part..... but not the md part because remember, part of what I manually do after boot up is to assemble the md device first. So maybe I should "sleep 20" somewhere in the init script of mdadm-raid as well as "lvm2" ???

    i think we're making progress :D



    here's a video of boot-up after the "sleep 20" was added. i don't think that the "sleep 20" is actually sleeping for 20 seconds though....
    https://www.dropbox.com/s/ta98et8nrrn8ge4/san.avi?dl=0

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden