Intel RAID
-
@eddy According to Tom’s last posts, the support should be there… no way to really know but to try. Either way, you’ll need to move to the latest FOG Trunk version to find out. Here’s how you do that:
-
It wouldn’t be optimal, but have you tried the dd method?
-
The issue is still there
Test on trunk version: 4702 with Optiplex 9020 Raid 0. -
@mutant What is the issue that is still there?
-
I don’t know if this will help anybody.
https://github.com/FOGProject/fogproject/pull/53
But I’m not going to try auto mounting raid myself.
Follow the instructions (essentially set the host’s kernelArgs to contain mdraid=true)
-
putting Host Kernel Arguments “mdraid=true” still result in the same issue that when deploy image it will break the raid and only image one disk. -
Did you download the new init and kernel files before testing?
-
Kernel was updated last week when upgrade using git to trunk version 4702.
The git source “S99fog” file does have the $mdraid change. -
Again,
I need more information.
What is happening, what isn’t working? Does the system recognize the volumes at all?
-
@mutant said:
9020
I have Dell Optiplex 9020s at work. The factory firmware settings come with the hdd operating in “RAID ON” mode instead of AHCI. I’ve been able to successfully image this system with FOG Trunk. Have you played with these HDD operation mode settings? Does the 9020 have two physical hard drives, or just one? What is not working? Can the system network boot? Can you upload an image? Can you download an image? Can you provide a photograph of the issue you’re seeing?
-
Upgrade the official published kernel from 4.2.0(Sept 17 2015) to 4.2.1 TomElliott (Sept 22 2015) and test again
Optiplex 9020 with two 500GB physical hard drive.
The system can network boot.
Both of Raid0 and Raid1 test with deploy successfully to boot OS but only deploy to one disk.Raid1 (Mirror) 465.8GB
Deploy a sysprep windows7 image result in degraded raid as it only deploy to one disk.
Raid0 (Stripe) 931.5GB
Deploy a sysprep windows7 image result in failed raid as it only deploy to one disk.
Raid0 Image
Raid1 Image
-
@mutant Not sure but I think that FOG only see the disk not the volume.
-
What does it look like on the original system?? If this is a real RAID controller you shouldn’t see the two disks in Windows! A real RAID is not configured in Windows/Linux but has it’s own (BIOS-like) configuration. You’d have to configure the RAID on the target system before cloning. This cannot be done by FOG!
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Uncle-Frank Very true.
When you’re using hardware RAID, the OS is oblivious to it. Even FOG would be oblivious to a good hardware RAID setup.
Since it’s clearly not hardware RAID, or a good hardware RAID - use “Multiple Partition Image - All Disks”
-
Re-reading your post and trying to find out a bit more about the RAID in Optiplex 9020 I noticed that I was totally wrong, sorry! This is not a real RAID but a fakeraid (as you already said in your first post
). It is Intel ICH8R (82801HR) southbridge which they call a ‘firmware RAID’. After setting it up properly on the target machine (http://www.dell.com/support/article/us/en/19/SLN153494/EN) you still need to address this in linux as well.Do you have ‘Host Primary Disk’ configured for those hosts? FOG is not intelligent enough yet to find out about (fake)RAID setup and use the correct device just by itself! You might be fine not setting ‘Host Primary Disk’ for the host you are getting the image from as /dev/sda should be equal to /dev/sdb (FOG uses /dev/sda as default). But you need to set this to /dev/md0 to make FOG properly deploy to your RAID.
By the way: “Multiple Partition Image - All Disks” probably won’t help you as the RAID array won’t be in sync if it is not properly deployed through the correct device file AFAIK.
-
Set the “Host Primary Disk” to /dev/md0 and test again and still no go.
Went into debug mode to check the raid status
mdadm -D /dev/md0
shows the status of md0 is “inactive”cat /proc/mdstat
shows only md126 is “active” and md127 is inactiveThe problem seems that FOG does not assemble /dev/md0 properly
Re-run the task after setting the “Host Primary Disk” to /dev/md126
still not go , it shows “Problem opening /dev/md126p1 for reading! Error is 2. The specified file does not exist!”The problem seems that FOG try to read from /dev/md126p1 instead of /dev/md126
-
Well, seams like it all depends. I cannot give you an easy solution like “just do it this way and you’ll be ok” as I don’t have a similar machine here to test.
What do you see when running the following command in debug mode: gdisk -l
Maybe those links are helpful: http://serverfault.com/questions/226053/intel-matrix-storage-raid-and-linux-mdadm and https://forums.gentoo.org/viewtopic-t-888520-start-0.html
Also check out the device files you have in /dev/md/ and let us know.
Edit: fakeraid is even more complicted than I had in mind: https://raid.wiki.kernel.org/index.php/RAID_superblock_formats
See if you can find out how your RAID was setup in the first place. Then we might be able to find a solution to image this thing too. -
Just posting some of my own success with RAID and fog.
I have a genuine hardware RAID setup at the house, I just got done installing CentOS 7 on it.
It’s setup with two sata hard drives in RAID 1 configuration.
I was having a very hard time trying to access the logical RAID 1 volume, and the below kernel options weren’t working, and I wasn’t having luck with finding what the system was refering to it as either.
However - I think I might have come across a better solution.
fdisk -lclearly shows two disks with exact size, model, and partitions.I simply created a new a new image using
multiple partition image - single disk (not resizeable)and obviously I assigned that to the host, and for “host primary disk” I just entered
/dev/sdaand it worked like a charm.I’m a little curious about how my RAID 1 controller card would react if FOG tried to resize /dev/sda alone…
Perhaps the RAID card will make those changes to sdb ? maybe the RAID 1 volume will degrade! lol
I have no idea… but…
this is a really good way to get an image off of a RAID 1 system and then put it onto a NON-RAID system.
I’ll experiment with this and the resizable images.
-
When setting the “Host Primary Disk” to /dev/md126 because there is no /dev/md0.
The following error message show up when restore a resizable windows 7 sysprep image.
Problem opening /dev/md126p for reading! Error is 2.
The specified file does not exist!
Problem opening /dev/md126p for reading! Error is 2.
The specified file does not exist!- Processing Partition: /dev/md126p1 (p1)
- Partition File Missing: /images/W7/d1pp1.im*
Problem opening /dev/md126p for reading! Error is 2.
The specified file does not exist!
Problem opening /dev/md126p for reading! Error is 2.
The specified file does not exist!
Problem opening /dev/md126p for reading! Error is 2.
The specified file does not exist!
It looks some kind of fog bugs when processing fakeraid Raid0 partition.
It has problem to properly read the raid0 partition and it tries to read d1pp1.im* file instead of d1p1.im* file.
-
I am sorry but I feel pretty lost with this as I don’t have such a machine here to test!
The only thing I can offer is to go through this again from the start step by step. Just an offer. It’s up to you if you want to.
Let’s start with the client you are getting the image from. Configure a complete new image for that client in FOG and make it
Multiple partition image - single disk (not resizeable). The run a debug session for that client, boot it up and wait till you get to the command shell. Then run the following commands and post the full output here in the forums or upload the text files. Replace x.x.x.x with the IP address of your FOG server.mkdir -p /mnt mount -t nfs -o rw,nolock x.x.x.x:/images/dev /mnt mdadm --examine /dev/sd? > /mnt/mdadm_examine.txt cat /proc/mdstat > /mnt/mdstat.txt mdadm --assemble --scan --verbose > /mnt/mdadm_assemble.txt ls -al /dev/md* > /mnt/md_devices.txt umount /mntI just typed and copied those commands without testing. There might be typos.
