“LVM failed to initialize library context” - SLES 12.3 after reboot lost some of its PVs











up vote
0
down vote

favorite
1












After a reboot, a SLES 12.3 box doesn't recognizes a few disks (that are actually behind HW raid).



What could the issue be?



If I "head /dev/sdb | strings | head" the problematic disks, I can see data on them, ok.



But "pvscan" doesn't recognizes it.



SERVER:~ # pvck /dev/sdb
Device /dev/sdb not found (or ignored by filtering).
SERVER:~ #
SERVER:~ # grep ' filter' /etc/lvm/lvm.conf
filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", "r|/dev/fd.*|", "r|/dev/cdrom|", "a|/dev/sd.*[1-9]|", "a|/dev/vda[1-9]|", "a|/dev/mapper/.*|", "a|/dev/dm-*|" , "r|.*|" ]
SERVER:~ #


Strangely, the OS recognizes sda, which holds the OS itself.



But it doesn't recognizes the sdb/sdc/etc (holding the data) as PV.



UPDATE on 2018 Dec 11: all the disks: sda (raid1), sdb(raid5), sdc(raid5), sdd(raid1) are on HW RAID. "zypper up" says nothing to update.










share|improve this question
























  • There is a know bug after upgrades, especially when using multipath.
    – Rui F Ribeiro
    2 days ago










  • hmm, no multipath is used here, only HW RAID1 (which is sda) and HW RAID5, which is RAID5. But many thanks for any hint.
    – KollarA
    yesterday












  • Any link/workaround to that bug? Many thanks.
    – KollarA
    yesterday










  • Yes, but probably does not apply. suse.com/support/kb/doc/?id=7022520
    – Rui F Ribeiro
    yesterday










  • sda is from HW RAID too and that works, but checking, Thanks!
    – KollarA
    yesterday

















up vote
0
down vote

favorite
1












After a reboot, a SLES 12.3 box doesn't recognizes a few disks (that are actually behind HW raid).



What could the issue be?



If I "head /dev/sdb | strings | head" the problematic disks, I can see data on them, ok.



But "pvscan" doesn't recognizes it.



SERVER:~ # pvck /dev/sdb
Device /dev/sdb not found (or ignored by filtering).
SERVER:~ #
SERVER:~ # grep ' filter' /etc/lvm/lvm.conf
filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", "r|/dev/fd.*|", "r|/dev/cdrom|", "a|/dev/sd.*[1-9]|", "a|/dev/vda[1-9]|", "a|/dev/mapper/.*|", "a|/dev/dm-*|" , "r|.*|" ]
SERVER:~ #


Strangely, the OS recognizes sda, which holds the OS itself.



But it doesn't recognizes the sdb/sdc/etc (holding the data) as PV.



UPDATE on 2018 Dec 11: all the disks: sda (raid1), sdb(raid5), sdc(raid5), sdd(raid1) are on HW RAID. "zypper up" says nothing to update.










share|improve this question
























  • There is a know bug after upgrades, especially when using multipath.
    – Rui F Ribeiro
    2 days ago










  • hmm, no multipath is used here, only HW RAID1 (which is sda) and HW RAID5, which is RAID5. But many thanks for any hint.
    – KollarA
    yesterday












  • Any link/workaround to that bug? Many thanks.
    – KollarA
    yesterday










  • Yes, but probably does not apply. suse.com/support/kb/doc/?id=7022520
    – Rui F Ribeiro
    yesterday










  • sda is from HW RAID too and that works, but checking, Thanks!
    – KollarA
    yesterday















up vote
0
down vote

favorite
1









up vote
0
down vote

favorite
1






1





After a reboot, a SLES 12.3 box doesn't recognizes a few disks (that are actually behind HW raid).



What could the issue be?



If I "head /dev/sdb | strings | head" the problematic disks, I can see data on them, ok.



But "pvscan" doesn't recognizes it.



SERVER:~ # pvck /dev/sdb
Device /dev/sdb not found (or ignored by filtering).
SERVER:~ #
SERVER:~ # grep ' filter' /etc/lvm/lvm.conf
filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", "r|/dev/fd.*|", "r|/dev/cdrom|", "a|/dev/sd.*[1-9]|", "a|/dev/vda[1-9]|", "a|/dev/mapper/.*|", "a|/dev/dm-*|" , "r|.*|" ]
SERVER:~ #


Strangely, the OS recognizes sda, which holds the OS itself.



But it doesn't recognizes the sdb/sdc/etc (holding the data) as PV.



UPDATE on 2018 Dec 11: all the disks: sda (raid1), sdb(raid5), sdc(raid5), sdd(raid1) are on HW RAID. "zypper up" says nothing to update.










share|improve this question















After a reboot, a SLES 12.3 box doesn't recognizes a few disks (that are actually behind HW raid).



What could the issue be?



If I "head /dev/sdb | strings | head" the problematic disks, I can see data on them, ok.



But "pvscan" doesn't recognizes it.



SERVER:~ # pvck /dev/sdb
Device /dev/sdb not found (or ignored by filtering).
SERVER:~ #
SERVER:~ # grep ' filter' /etc/lvm/lvm.conf
filter = [ "r|/dev/.*/by-path/.*|", "r|/dev/.*/by-id/.*|", "r|/dev/fd.*|", "r|/dev/cdrom|", "a|/dev/sd.*[1-9]|", "a|/dev/vda[1-9]|", "a|/dev/mapper/.*|", "a|/dev/dm-*|" , "r|.*|" ]
SERVER:~ #


Strangely, the OS recognizes sda, which holds the OS itself.



But it doesn't recognizes the sdb/sdc/etc (holding the data) as PV.



UPDATE on 2018 Dec 11: all the disks: sda (raid1), sdb(raid5), sdc(raid5), sdd(raid1) are on HW RAID. "zypper up" says nothing to update.







sles






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited yesterday

























asked 2 days ago









KollarA

436




436












  • There is a know bug after upgrades, especially when using multipath.
    – Rui F Ribeiro
    2 days ago










  • hmm, no multipath is used here, only HW RAID1 (which is sda) and HW RAID5, which is RAID5. But many thanks for any hint.
    – KollarA
    yesterday












  • Any link/workaround to that bug? Many thanks.
    – KollarA
    yesterday










  • Yes, but probably does not apply. suse.com/support/kb/doc/?id=7022520
    – Rui F Ribeiro
    yesterday










  • sda is from HW RAID too and that works, but checking, Thanks!
    – KollarA
    yesterday




















  • There is a know bug after upgrades, especially when using multipath.
    – Rui F Ribeiro
    2 days ago










  • hmm, no multipath is used here, only HW RAID1 (which is sda) and HW RAID5, which is RAID5. But many thanks for any hint.
    – KollarA
    yesterday












  • Any link/workaround to that bug? Many thanks.
    – KollarA
    yesterday










  • Yes, but probably does not apply. suse.com/support/kb/doc/?id=7022520
    – Rui F Ribeiro
    yesterday










  • sda is from HW RAID too and that works, but checking, Thanks!
    – KollarA
    yesterday


















There is a know bug after upgrades, especially when using multipath.
– Rui F Ribeiro
2 days ago




There is a know bug after upgrades, especially when using multipath.
– Rui F Ribeiro
2 days ago












hmm, no multipath is used here, only HW RAID1 (which is sda) and HW RAID5, which is RAID5. But many thanks for any hint.
– KollarA
yesterday






hmm, no multipath is used here, only HW RAID1 (which is sda) and HW RAID5, which is RAID5. But many thanks for any hint.
– KollarA
yesterday














Any link/workaround to that bug? Many thanks.
– KollarA
yesterday




Any link/workaround to that bug? Many thanks.
– KollarA
yesterday












Yes, but probably does not apply. suse.com/support/kb/doc/?id=7022520
– Rui F Ribeiro
yesterday




Yes, but probably does not apply. suse.com/support/kb/doc/?id=7022520
– Rui F Ribeiro
yesterday












sda is from HW RAID too and that works, but checking, Thanks!
– KollarA
yesterday






sda is from HW RAID too and that works, but checking, Thanks!
– KollarA
yesterday












1 Answer
1






active

oldest

votes

















up vote
0
down vote













finally, we found out:



It looks like something deleted the non-sda partitions :)



So the data was there on the ex.: sdb, sdc, sdd, but we had to re-run the partition creating oneliner:



parted -s /dev/sdb mklabel gpt mkpart primary xfs 0% 100% set 1 lvm on


and presto, pvscan found them! yay.






share|improve this answer





















    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487198%2flvm-failed-to-initialize-library-context-sles-12-3-after-reboot-lost-some-of%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    0
    down vote













    finally, we found out:



    It looks like something deleted the non-sda partitions :)



    So the data was there on the ex.: sdb, sdc, sdd, but we had to re-run the partition creating oneliner:



    parted -s /dev/sdb mklabel gpt mkpart primary xfs 0% 100% set 1 lvm on


    and presto, pvscan found them! yay.






    share|improve this answer

























      up vote
      0
      down vote













      finally, we found out:



      It looks like something deleted the non-sda partitions :)



      So the data was there on the ex.: sdb, sdc, sdd, but we had to re-run the partition creating oneliner:



      parted -s /dev/sdb mklabel gpt mkpart primary xfs 0% 100% set 1 lvm on


      and presto, pvscan found them! yay.






      share|improve this answer























        up vote
        0
        down vote










        up vote
        0
        down vote









        finally, we found out:



        It looks like something deleted the non-sda partitions :)



        So the data was there on the ex.: sdb, sdc, sdd, but we had to re-run the partition creating oneliner:



        parted -s /dev/sdb mklabel gpt mkpart primary xfs 0% 100% set 1 lvm on


        and presto, pvscan found them! yay.






        share|improve this answer












        finally, we found out:



        It looks like something deleted the non-sda partitions :)



        So the data was there on the ex.: sdb, sdc, sdd, but we had to re-run the partition creating oneliner:



        parted -s /dev/sdb mklabel gpt mkpart primary xfs 0% 100% set 1 lvm on


        and presto, pvscan found them! yay.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered yesterday









        KollarA

        436




        436






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f487198%2flvm-failed-to-initialize-library-context-sles-12-3-after-reboot-lost-some-of%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Accessing regular linux commands in Huawei's Dopra Linux

            Can't connect RFCOMM socket: Host is down

            Kernel panic - not syncing: Fatal Exception in Interrupt