• Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login
  • Recent
  • Unsolved
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Register
  • Login

Issues with capturing an image with a raid0 array.

Scheduled Pinned Locked Moved Unsolved
Linux Problems
2
4
272
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • 4
    45lightrain
    last edited by Aug 24, 2024, 6:33 AM

    I am trying to capture an Ubuntu server 22.04 image with a raid0 array set up so that I can roll back to this base image without having to recreate the array.

    The OS is on a SATA SSD while the raid array is made from x2 NVMe drives in a dual slot nvme card.
    nvme0n1 and nvme1n1
    Unfortunately Fog appears to be having issues with my NVMes
    Is there a fix for this?

    another issue I have is when I deploy an image it gets imaged to the NVMe and not the SATA SSD, is there a solution for this as well?
    I have been bypassing this by removing the NVMe card but it would be nice not to have this issue anymore.

    51ec6e28-9598-4ccc-8109-0885b0009380-image.png

    G 1 Reply Last reply Aug 24, 2024, 4:11 PM Reply Quote 0
    • G
      george1421 Moderator @45lightrain
      last edited by Aug 24, 2024, 4:11 PM

      @45lightrain how did you create the raid 0 array? From within linux or using the intel rst controller?

      FWIW: I have not been able to make the vroc arrays work with FOG, but if you have ubuntu loaded on a vroc array then it has to work and we need to talk.

      If you created the array with intel rst or using a software raid created by ubuntu then you have some luck. The first thing I would do is go into the fog global settings and look for kernel parameters field. Then add mdraid-true into that field. That tells the fos linux kernel to look for a raid array.

      Next I would schedule a capture or deploy image, but before you hit the schedule task button, tick the debug checkbox.

      PXE boot the target computer, after a few screens of text you need to clear with the enter key you will be dropped to the fos linux command prompt. Key in lsblk to see if FOS Linux assembled your array for you. It will probably be listed as /dev/md0, or /dev/md126 or 127. If its there THAT is the device name you need to key into the host record for this target computer in the hard drive field. This way FOG will not try to use one of the nvme drive, but the raid device.

      If the device is not automatically detected you may need to assemble the array, but lets first start with making sure you have the kernel parameter set and that fos linux sees the array.

      Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

      4 1 Reply Last reply Aug 24, 2024, 11:48 PM Reply Quote 0
      • 4
        45lightrain @george1421
        last edited by 45lightrain Aug 24, 2024, 5:48 PM Aug 24, 2024, 11:48 PM

        @george1421
        This did the trick!
        Thank you!
        My raid array was made with software raid on Ubuntu.

        FOS recognized and assembled the raid array!
        with that I updated the hard drive field.
        I am now able to capture and deploy the OS with no issues!

        Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?
        While testing the solution you provided I captured and deployed the OS a handful of times but unfortunately the data on the raid array remains intact and doesn’t revert back to the state it was when the OS was initially captured.

        Is there a solution for this or does FOG not have the ability to capture and deploy raid array data on a separate drive that isn’t the OS?
        Using your solution I created a new image and set the host drive to the raid array from FOS to see if I could capture just the raid array data but it won’t be captured due to it not having linux/resizable partitions

        @george1421
        This did the trick!
        Thank you!
        My raid array was made with software raid on Ubuntu.

        FOS recognized and assembled the raid array!
        with that I updated the hard drive field.
        I am now able to capture and deploy the OS with no issues!

        Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?
        While testing the solution you provided I captured and deployed the OS a handful of times but unfortunately the data on the raid array remains intact and doesn’t revert back to the state it was when the OS was initially captured.

        Is there a solution for this or does FOG not have the ability to capture and deploy raid array data on a separate drive that isn’t the OS?
        Using your solution I created a new image and set the host drive to the raid array from FOS to see if I could capture just the raid array data but it won’t be captured due to it not having linux/resizable partitions

        bad893a8-f4cd-44f7-b665-8e02a4c9b634-image.png

        G 1 Reply Last reply Aug 25, 2024, 9:37 PM Reply Quote 0
        • G
          george1421 Moderator @45lightrain
          last edited by Aug 25, 2024, 9:37 PM

          @45lightrain said in Issues with capturing an image with a raid0 array.:

          Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?

          FOG captures disks in block mode. It doesn’t care about partitions (mostly). Also make sure that md0 is the true device for these drives. When you are in the FOS linux shell you can / should create a mount point and then mount /dev/mdX partition to see if you can read the content. I have seen where sometimes md0 is created but the real raid array is /dev/md126.

          Also FOG calls a script before imaging starts. Sometimes its needed to assemble the array in this postinit script. Or do other things to prep the system for imaging. So the postinit script (found in the /images directory on the fog server) is a the place to put that code.

          Also when you start in debug mode (when debugging the imaging process) you can actually start the imaging process from the command line by keying in fog. The imaging will stop at each debugPause; command in the imaging code as a breakpoint. If you notice something wrong, you can hit ctrl-C to exit back to the command prompt. To restart the imaging process again just rekey in fog.

          While it doesn’t exactly apply here I wrote an article 8 years ago about imaging using the intel rst adapter that may contain a nugget of help: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid

          Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!

          1 Reply Last reply Reply Quote 0
          • T Tom Elliott referenced this topic on Aug 28, 2024, 4:12 PM
          • G george1421 referenced this topic on Aug 28, 2024, 9:14 PM
          • 1 / 1
          1 / 1
          • First post
            4/4
            Last post

          164

          Online

          12.0k

          Users

          17.3k

          Topics

          155.2k

          Posts
          Copyright © 2012-2024 FOG Project