Small boot drive and an iSCSI primary volume

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












1














I have a main storage / iSCSI server where I want to keep all my data.



On the other side I have workstations and VMs where I want no data at all. However due to performance requirements I want to keep some local storage at workstations and VMs to serve as /boot and cache for the primary iSCSI volume.



I have not yet decided whether to use bcache or LVMs dm-cache so if there's any difference between them regarding this question, please mention them in your answer.



The question:



How can I install linux (ubuntu) such that my local storage would only serve as GRUB, /boot & iSCSI initiator mounting one specific volume on the target (no PXE involved). Cache too, of course. Ideally this would be installed to each workstation using command line from a live CD or something. For VMs I'd just copy the disk itself and then change the iSCSI volume to mount.










share|improve this question




























    1














    I have a main storage / iSCSI server where I want to keep all my data.



    On the other side I have workstations and VMs where I want no data at all. However due to performance requirements I want to keep some local storage at workstations and VMs to serve as /boot and cache for the primary iSCSI volume.



    I have not yet decided whether to use bcache or LVMs dm-cache so if there's any difference between them regarding this question, please mention them in your answer.



    The question:



    How can I install linux (ubuntu) such that my local storage would only serve as GRUB, /boot & iSCSI initiator mounting one specific volume on the target (no PXE involved). Cache too, of course. Ideally this would be installed to each workstation using command line from a live CD or something. For VMs I'd just copy the disk itself and then change the iSCSI volume to mount.










    share|improve this question


























      1












      1








      1







      I have a main storage / iSCSI server where I want to keep all my data.



      On the other side I have workstations and VMs where I want no data at all. However due to performance requirements I want to keep some local storage at workstations and VMs to serve as /boot and cache for the primary iSCSI volume.



      I have not yet decided whether to use bcache or LVMs dm-cache so if there's any difference between them regarding this question, please mention them in your answer.



      The question:



      How can I install linux (ubuntu) such that my local storage would only serve as GRUB, /boot & iSCSI initiator mounting one specific volume on the target (no PXE involved). Cache too, of course. Ideally this would be installed to each workstation using command line from a live CD or something. For VMs I'd just copy the disk itself and then change the iSCSI volume to mount.










      share|improve this question















      I have a main storage / iSCSI server where I want to keep all my data.



      On the other side I have workstations and VMs where I want no data at all. However due to performance requirements I want to keep some local storage at workstations and VMs to serve as /boot and cache for the primary iSCSI volume.



      I have not yet decided whether to use bcache or LVMs dm-cache so if there's any difference between them regarding this question, please mention them in your answer.



      The question:



      How can I install linux (ubuntu) such that my local storage would only serve as GRUB, /boot & iSCSI initiator mounting one specific volume on the target (no PXE involved). Cache too, of course. Ideally this would be installed to each workstation using command line from a live CD or something. For VMs I'd just copy the disk itself and then change the iSCSI volume to mount.







      boot cache iscsi






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Dec 15 at 22:02









      Rui F Ribeiro

      38.9k1479129




      38.9k1479129










      asked Jan 25 '17 at 7:46









      velis

      1421214




      1421214




















          1 Answer
          1






          active

          oldest

          votes


















          0














          Well, this turned out to be something of a learning experience :)



          Step 1



          To make this work, I took Ubuntu network installer server image. It's just 55MB.



          Step 2



          The installation is text based, but no less functional as the desktop counterpart. It does have a minor difference of allowing you to specify iSCSI connection parameters directly within the installation, but you do have to choose manual partitioning. I'm not sure it's that helpful though as entering initiator info into the installer resulted in same LUN being mounted twice which is a bit unfortunate as that messes up (at least) LVM I'm installing next. So I just entered initiator ID from within the installer and then switched to console #2 (ctrl + alt + F2) and connected to the target manually from there. Returning back to the installer and manual disk partitioning I now had /dev/sda (my local storage) & /dev/sdb (the iSCSI volume).



          Please note that a desktop installer (for ubuntu gnome edition) did not preinstall open-iscsi into the deploy and I ultimately gave up on it and just went with the server installer.



          Step 3



          Proceeding with manual partitioning, the next step is to establish base conditions for the SSD cache. In this case I decided to use LVM's dm-cache implementation, so for now I simply created a volume group in the iSCSI LUN and created a logical volume within it. This will be the root. Please note that having an existing logical volume on the iSCSI LUN does not display it in the installer's partition manager, so you might need to delete it first and create a new one before you're able to proceed.



          Step 4



          Finishing up the manual disk partitioning, I now created the partitions:



          • sda1: /boot

          • sda2: swap

          • sdb:vg/lv: / (root)

          And installed the OS into them. You get a choice of your favourite desktop flavour during installation, so there's no mission out on anything. You can even choose to only install necesities first and later restart tasksel as suggested in the link just above.



          Step 5



          This left me with a non-functional deployment for two reasons:



          1. The iSCSI initiator ID burned into deployment's initramfs was not the one used to connect to the target.

          2. The password information for CHAP authentication was also left out in the initramfs image

          As a result, my newly installed Ubuntu dropped to initramfs prompt as it couldn't mount the iSCSI image containing root FS.



          I'm not sure how I could fix this during the install phase, so I just fixed it with the following steps:



          1. I verified what client ID my new deploy was using and created an appropriate ACL in my server's targetcli. At the same time I disabled CHAP authentication. This would have been better accomplished by simply invoking iscsistart from within initramfs prompt with the correct parameters, but at the time I simply didn't know that. Choose your favourite poison here.

          2. After my client booted, I fixed the /etc/iscsi/initiatorname.iscsi with the correct initiator ID and /etc/iscsi/iscsi.initramfs with full target & authentication details. The parameter names for the latter file are ISCSI_INITIATOR, ISCSI_TARGET_NAME, ISCSI_TARGET_IP, ISCSI_TARGET_PORT, ISCSI_TARGET_GROUP, ISCSI_USERNAME, ISCSI_PASSWORD, ISCSI_IN_USERNAME, ISCSI_IN_PASSWORD. I got them here. Following the updates, I issued update-initramfs -u to update the boot configuration accordingly.

          After this step I have a correctly setup system which boots and operates as I wanted from the start. There remain two steps that I haven't completed yet.



          Step 6



          The deployment has a "bug" where during shutdown, the network stack and iSCSI volume get shut down before the root filesystem gets unmounted. This results in shutdown hanging mid-way. When I find a fix for this, I'll update this step accordingly and proceed to the final step.



          Step 7



          After fixing the shutdown issue, I want to setup SSD caching as explained here & here.



          I'm currently looking into LVM caching for two reasons:



          1. I have set up bcache on my main server and while it's very powerful and configurable and reliable, I'm experiencing certain minor (but nonetheless annoying) issues with it.

          2. LVM's caching leaves logical volumes' paths intact: you can enable / disable / remove cache at will with no changes in how you use the underlying volumes. bcache on the other hand creates a new mapping which needs to remain active even if you disable the cache itself. Well, technically, since I had to setup LVM just to be able to enable cache later on, I guess it's not really fair of me to say that bcache has another layer and LVM doesn't, is it?





          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',
            autoActivateHeartbeat: false,
            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%2f339975%2fsmall-boot-drive-and-an-iscsi-primary-volume%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









            0














            Well, this turned out to be something of a learning experience :)



            Step 1



            To make this work, I took Ubuntu network installer server image. It's just 55MB.



            Step 2



            The installation is text based, but no less functional as the desktop counterpart. It does have a minor difference of allowing you to specify iSCSI connection parameters directly within the installation, but you do have to choose manual partitioning. I'm not sure it's that helpful though as entering initiator info into the installer resulted in same LUN being mounted twice which is a bit unfortunate as that messes up (at least) LVM I'm installing next. So I just entered initiator ID from within the installer and then switched to console #2 (ctrl + alt + F2) and connected to the target manually from there. Returning back to the installer and manual disk partitioning I now had /dev/sda (my local storage) & /dev/sdb (the iSCSI volume).



            Please note that a desktop installer (for ubuntu gnome edition) did not preinstall open-iscsi into the deploy and I ultimately gave up on it and just went with the server installer.



            Step 3



            Proceeding with manual partitioning, the next step is to establish base conditions for the SSD cache. In this case I decided to use LVM's dm-cache implementation, so for now I simply created a volume group in the iSCSI LUN and created a logical volume within it. This will be the root. Please note that having an existing logical volume on the iSCSI LUN does not display it in the installer's partition manager, so you might need to delete it first and create a new one before you're able to proceed.



            Step 4



            Finishing up the manual disk partitioning, I now created the partitions:



            • sda1: /boot

            • sda2: swap

            • sdb:vg/lv: / (root)

            And installed the OS into them. You get a choice of your favourite desktop flavour during installation, so there's no mission out on anything. You can even choose to only install necesities first and later restart tasksel as suggested in the link just above.



            Step 5



            This left me with a non-functional deployment for two reasons:



            1. The iSCSI initiator ID burned into deployment's initramfs was not the one used to connect to the target.

            2. The password information for CHAP authentication was also left out in the initramfs image

            As a result, my newly installed Ubuntu dropped to initramfs prompt as it couldn't mount the iSCSI image containing root FS.



            I'm not sure how I could fix this during the install phase, so I just fixed it with the following steps:



            1. I verified what client ID my new deploy was using and created an appropriate ACL in my server's targetcli. At the same time I disabled CHAP authentication. This would have been better accomplished by simply invoking iscsistart from within initramfs prompt with the correct parameters, but at the time I simply didn't know that. Choose your favourite poison here.

            2. After my client booted, I fixed the /etc/iscsi/initiatorname.iscsi with the correct initiator ID and /etc/iscsi/iscsi.initramfs with full target & authentication details. The parameter names for the latter file are ISCSI_INITIATOR, ISCSI_TARGET_NAME, ISCSI_TARGET_IP, ISCSI_TARGET_PORT, ISCSI_TARGET_GROUP, ISCSI_USERNAME, ISCSI_PASSWORD, ISCSI_IN_USERNAME, ISCSI_IN_PASSWORD. I got them here. Following the updates, I issued update-initramfs -u to update the boot configuration accordingly.

            After this step I have a correctly setup system which boots and operates as I wanted from the start. There remain two steps that I haven't completed yet.



            Step 6



            The deployment has a "bug" where during shutdown, the network stack and iSCSI volume get shut down before the root filesystem gets unmounted. This results in shutdown hanging mid-way. When I find a fix for this, I'll update this step accordingly and proceed to the final step.



            Step 7



            After fixing the shutdown issue, I want to setup SSD caching as explained here & here.



            I'm currently looking into LVM caching for two reasons:



            1. I have set up bcache on my main server and while it's very powerful and configurable and reliable, I'm experiencing certain minor (but nonetheless annoying) issues with it.

            2. LVM's caching leaves logical volumes' paths intact: you can enable / disable / remove cache at will with no changes in how you use the underlying volumes. bcache on the other hand creates a new mapping which needs to remain active even if you disable the cache itself. Well, technically, since I had to setup LVM just to be able to enable cache later on, I guess it's not really fair of me to say that bcache has another layer and LVM doesn't, is it?





            share|improve this answer



























              0














              Well, this turned out to be something of a learning experience :)



              Step 1



              To make this work, I took Ubuntu network installer server image. It's just 55MB.



              Step 2



              The installation is text based, but no less functional as the desktop counterpart. It does have a minor difference of allowing you to specify iSCSI connection parameters directly within the installation, but you do have to choose manual partitioning. I'm not sure it's that helpful though as entering initiator info into the installer resulted in same LUN being mounted twice which is a bit unfortunate as that messes up (at least) LVM I'm installing next. So I just entered initiator ID from within the installer and then switched to console #2 (ctrl + alt + F2) and connected to the target manually from there. Returning back to the installer and manual disk partitioning I now had /dev/sda (my local storage) & /dev/sdb (the iSCSI volume).



              Please note that a desktop installer (for ubuntu gnome edition) did not preinstall open-iscsi into the deploy and I ultimately gave up on it and just went with the server installer.



              Step 3



              Proceeding with manual partitioning, the next step is to establish base conditions for the SSD cache. In this case I decided to use LVM's dm-cache implementation, so for now I simply created a volume group in the iSCSI LUN and created a logical volume within it. This will be the root. Please note that having an existing logical volume on the iSCSI LUN does not display it in the installer's partition manager, so you might need to delete it first and create a new one before you're able to proceed.



              Step 4



              Finishing up the manual disk partitioning, I now created the partitions:



              • sda1: /boot

              • sda2: swap

              • sdb:vg/lv: / (root)

              And installed the OS into them. You get a choice of your favourite desktop flavour during installation, so there's no mission out on anything. You can even choose to only install necesities first and later restart tasksel as suggested in the link just above.



              Step 5



              This left me with a non-functional deployment for two reasons:



              1. The iSCSI initiator ID burned into deployment's initramfs was not the one used to connect to the target.

              2. The password information for CHAP authentication was also left out in the initramfs image

              As a result, my newly installed Ubuntu dropped to initramfs prompt as it couldn't mount the iSCSI image containing root FS.



              I'm not sure how I could fix this during the install phase, so I just fixed it with the following steps:



              1. I verified what client ID my new deploy was using and created an appropriate ACL in my server's targetcli. At the same time I disabled CHAP authentication. This would have been better accomplished by simply invoking iscsistart from within initramfs prompt with the correct parameters, but at the time I simply didn't know that. Choose your favourite poison here.

              2. After my client booted, I fixed the /etc/iscsi/initiatorname.iscsi with the correct initiator ID and /etc/iscsi/iscsi.initramfs with full target & authentication details. The parameter names for the latter file are ISCSI_INITIATOR, ISCSI_TARGET_NAME, ISCSI_TARGET_IP, ISCSI_TARGET_PORT, ISCSI_TARGET_GROUP, ISCSI_USERNAME, ISCSI_PASSWORD, ISCSI_IN_USERNAME, ISCSI_IN_PASSWORD. I got them here. Following the updates, I issued update-initramfs -u to update the boot configuration accordingly.

              After this step I have a correctly setup system which boots and operates as I wanted from the start. There remain two steps that I haven't completed yet.



              Step 6



              The deployment has a "bug" where during shutdown, the network stack and iSCSI volume get shut down before the root filesystem gets unmounted. This results in shutdown hanging mid-way. When I find a fix for this, I'll update this step accordingly and proceed to the final step.



              Step 7



              After fixing the shutdown issue, I want to setup SSD caching as explained here & here.



              I'm currently looking into LVM caching for two reasons:



              1. I have set up bcache on my main server and while it's very powerful and configurable and reliable, I'm experiencing certain minor (but nonetheless annoying) issues with it.

              2. LVM's caching leaves logical volumes' paths intact: you can enable / disable / remove cache at will with no changes in how you use the underlying volumes. bcache on the other hand creates a new mapping which needs to remain active even if you disable the cache itself. Well, technically, since I had to setup LVM just to be able to enable cache later on, I guess it's not really fair of me to say that bcache has another layer and LVM doesn't, is it?





              share|improve this answer

























                0












                0








                0






                Well, this turned out to be something of a learning experience :)



                Step 1



                To make this work, I took Ubuntu network installer server image. It's just 55MB.



                Step 2



                The installation is text based, but no less functional as the desktop counterpart. It does have a minor difference of allowing you to specify iSCSI connection parameters directly within the installation, but you do have to choose manual partitioning. I'm not sure it's that helpful though as entering initiator info into the installer resulted in same LUN being mounted twice which is a bit unfortunate as that messes up (at least) LVM I'm installing next. So I just entered initiator ID from within the installer and then switched to console #2 (ctrl + alt + F2) and connected to the target manually from there. Returning back to the installer and manual disk partitioning I now had /dev/sda (my local storage) & /dev/sdb (the iSCSI volume).



                Please note that a desktop installer (for ubuntu gnome edition) did not preinstall open-iscsi into the deploy and I ultimately gave up on it and just went with the server installer.



                Step 3



                Proceeding with manual partitioning, the next step is to establish base conditions for the SSD cache. In this case I decided to use LVM's dm-cache implementation, so for now I simply created a volume group in the iSCSI LUN and created a logical volume within it. This will be the root. Please note that having an existing logical volume on the iSCSI LUN does not display it in the installer's partition manager, so you might need to delete it first and create a new one before you're able to proceed.



                Step 4



                Finishing up the manual disk partitioning, I now created the partitions:



                • sda1: /boot

                • sda2: swap

                • sdb:vg/lv: / (root)

                And installed the OS into them. You get a choice of your favourite desktop flavour during installation, so there's no mission out on anything. You can even choose to only install necesities first and later restart tasksel as suggested in the link just above.



                Step 5



                This left me with a non-functional deployment for two reasons:



                1. The iSCSI initiator ID burned into deployment's initramfs was not the one used to connect to the target.

                2. The password information for CHAP authentication was also left out in the initramfs image

                As a result, my newly installed Ubuntu dropped to initramfs prompt as it couldn't mount the iSCSI image containing root FS.



                I'm not sure how I could fix this during the install phase, so I just fixed it with the following steps:



                1. I verified what client ID my new deploy was using and created an appropriate ACL in my server's targetcli. At the same time I disabled CHAP authentication. This would have been better accomplished by simply invoking iscsistart from within initramfs prompt with the correct parameters, but at the time I simply didn't know that. Choose your favourite poison here.

                2. After my client booted, I fixed the /etc/iscsi/initiatorname.iscsi with the correct initiator ID and /etc/iscsi/iscsi.initramfs with full target & authentication details. The parameter names for the latter file are ISCSI_INITIATOR, ISCSI_TARGET_NAME, ISCSI_TARGET_IP, ISCSI_TARGET_PORT, ISCSI_TARGET_GROUP, ISCSI_USERNAME, ISCSI_PASSWORD, ISCSI_IN_USERNAME, ISCSI_IN_PASSWORD. I got them here. Following the updates, I issued update-initramfs -u to update the boot configuration accordingly.

                After this step I have a correctly setup system which boots and operates as I wanted from the start. There remain two steps that I haven't completed yet.



                Step 6



                The deployment has a "bug" where during shutdown, the network stack and iSCSI volume get shut down before the root filesystem gets unmounted. This results in shutdown hanging mid-way. When I find a fix for this, I'll update this step accordingly and proceed to the final step.



                Step 7



                After fixing the shutdown issue, I want to setup SSD caching as explained here & here.



                I'm currently looking into LVM caching for two reasons:



                1. I have set up bcache on my main server and while it's very powerful and configurable and reliable, I'm experiencing certain minor (but nonetheless annoying) issues with it.

                2. LVM's caching leaves logical volumes' paths intact: you can enable / disable / remove cache at will with no changes in how you use the underlying volumes. bcache on the other hand creates a new mapping which needs to remain active even if you disable the cache itself. Well, technically, since I had to setup LVM just to be able to enable cache later on, I guess it's not really fair of me to say that bcache has another layer and LVM doesn't, is it?





                share|improve this answer














                Well, this turned out to be something of a learning experience :)



                Step 1



                To make this work, I took Ubuntu network installer server image. It's just 55MB.



                Step 2



                The installation is text based, but no less functional as the desktop counterpart. It does have a minor difference of allowing you to specify iSCSI connection parameters directly within the installation, but you do have to choose manual partitioning. I'm not sure it's that helpful though as entering initiator info into the installer resulted in same LUN being mounted twice which is a bit unfortunate as that messes up (at least) LVM I'm installing next. So I just entered initiator ID from within the installer and then switched to console #2 (ctrl + alt + F2) and connected to the target manually from there. Returning back to the installer and manual disk partitioning I now had /dev/sda (my local storage) & /dev/sdb (the iSCSI volume).



                Please note that a desktop installer (for ubuntu gnome edition) did not preinstall open-iscsi into the deploy and I ultimately gave up on it and just went with the server installer.



                Step 3



                Proceeding with manual partitioning, the next step is to establish base conditions for the SSD cache. In this case I decided to use LVM's dm-cache implementation, so for now I simply created a volume group in the iSCSI LUN and created a logical volume within it. This will be the root. Please note that having an existing logical volume on the iSCSI LUN does not display it in the installer's partition manager, so you might need to delete it first and create a new one before you're able to proceed.



                Step 4



                Finishing up the manual disk partitioning, I now created the partitions:



                • sda1: /boot

                • sda2: swap

                • sdb:vg/lv: / (root)

                And installed the OS into them. You get a choice of your favourite desktop flavour during installation, so there's no mission out on anything. You can even choose to only install necesities first and later restart tasksel as suggested in the link just above.



                Step 5



                This left me with a non-functional deployment for two reasons:



                1. The iSCSI initiator ID burned into deployment's initramfs was not the one used to connect to the target.

                2. The password information for CHAP authentication was also left out in the initramfs image

                As a result, my newly installed Ubuntu dropped to initramfs prompt as it couldn't mount the iSCSI image containing root FS.



                I'm not sure how I could fix this during the install phase, so I just fixed it with the following steps:



                1. I verified what client ID my new deploy was using and created an appropriate ACL in my server's targetcli. At the same time I disabled CHAP authentication. This would have been better accomplished by simply invoking iscsistart from within initramfs prompt with the correct parameters, but at the time I simply didn't know that. Choose your favourite poison here.

                2. After my client booted, I fixed the /etc/iscsi/initiatorname.iscsi with the correct initiator ID and /etc/iscsi/iscsi.initramfs with full target & authentication details. The parameter names for the latter file are ISCSI_INITIATOR, ISCSI_TARGET_NAME, ISCSI_TARGET_IP, ISCSI_TARGET_PORT, ISCSI_TARGET_GROUP, ISCSI_USERNAME, ISCSI_PASSWORD, ISCSI_IN_USERNAME, ISCSI_IN_PASSWORD. I got them here. Following the updates, I issued update-initramfs -u to update the boot configuration accordingly.

                After this step I have a correctly setup system which boots and operates as I wanted from the start. There remain two steps that I haven't completed yet.



                Step 6



                The deployment has a "bug" where during shutdown, the network stack and iSCSI volume get shut down before the root filesystem gets unmounted. This results in shutdown hanging mid-way. When I find a fix for this, I'll update this step accordingly and proceed to the final step.



                Step 7



                After fixing the shutdown issue, I want to setup SSD caching as explained here & here.



                I'm currently looking into LVM caching for two reasons:



                1. I have set up bcache on my main server and while it's very powerful and configurable and reliable, I'm experiencing certain minor (but nonetheless annoying) issues with it.

                2. LVM's caching leaves logical volumes' paths intact: you can enable / disable / remove cache at will with no changes in how you use the underlying volumes. bcache on the other hand creates a new mapping which needs to remain active even if you disable the cache itself. Well, technically, since I had to setup LVM just to be able to enable cache later on, I guess it's not really fair of me to say that bcache has another layer and LVM doesn't, is it?






                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Apr 13 '17 at 12:37









                Community

                1




                1










                answered Feb 1 '17 at 14:07









                velis

                1421214




                1421214



























                    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%2f339975%2fsmall-boot-drive-and-an-iscsi-primary-volume%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

                    How to check contact read email or not when send email to Individual?

                    Bahrain

                    Postfix configuration issue with fips on centos 7; mailgun relay