Permission denied when trying to capture Intel RAID1 image

[Zerpie]

I’ve been following the thread over here https://forums.fogproject.org/topic/7851/intel-raid0-image-capture in order to figure out how to image some hardware that I have that uses the “fake” Intel RAID. We specifically use RAID 1 on these machines.

Well I found what I needed and I set the image to Single Disk Resizable and set the Host Kernal Arguments to mdraid=true and the Host Primary Disk to /dev/md126. I kick off the capture task, but then I get the error below.

*Mounting partition (/dev/md126p1)...Failed
*Could not mount /dev/md126p1 (removePageFile)
Args Passed: /dev/md126p1
Reason: ntfs-3g-mount: mount failed: Permission denied

Weird that I’m getting permission denied because if I get rid of the mdraid=true and /dev/md126 and just capture the image like a regular non-RAID machine it captures with no issue. Why would these arguments spit out a permissions error?

[Sebastian Roth]

@Zerpie @george1421 Build is done. Please find new test binaries here 64 bit and 32 bit.

Download and put in /var/www/fog/service/ipxe on your FOG server. Rename to match the original names - do not overwrite but also rename the original init’s I would say just in case.

Please test and let us know. Caputre, deploy… working?

[Zerpie]

I changed the image to Multiple Partition Image - Single Disk (Not Resizable) and it’s currently capturing it. We’ll have to see if the capture task finishes and if I can then deploy the image without breaking RAID. But it’s at least getting past the part where I’d get the Permission denied error previously.

[Zerpie]

After changing the image to Multiple Partition Image - Single Disk (Not Resizable) It captured, but when I tried to deploy it got the following error.

No image file(s) found that would match the partition(s) to be restored (perfomRestore)

[Sebastian Roth]

@Zerpie This can mean two different things:

1. The image is not complete and does indeed miss some or all the files.
2. More likely restoring the partition layout is somehow failing on the RAID disks and FOG is not able to deploy to a disk without partitions (I know the message might be a bit misleading but such a situation can stem from different reasons).

So first you might want to set isdebug=yes ismajordebug=1 as “Host Kernel Args” (FOG web UI -> Hosts -> select the host and scroll a little down till you find the field called “Host Kernel Args”) and then schedule a debug deploy task. You should see more information then. After it fails you are thrown back to a command shell - run gdisk -l /dev/md126 and post a picture of that here.

[Zerpie]

@Sebastian-Roth I was actually getting ready to do just that, Debug deploy. First I’ll try it with the image set to Multiple Partition Image - Single Disk (Not Resizable) and then I’ll try a Debug capture with the image set to Single Disk Resizable since I’m still not sure which it should be set to for RAID. I’ll add the Host Kernel Args as well.

It’s getting towards the end of the workday today so I’ll probably post the results tomorrow.

[Zerpie]

@Sebastian-Roth Ok since I was able to capture the image as Multiple Partition Image - Single Disk (Not Resizable) I went ahead and did a debug deploy of that image first. Again, it failed at Mounting partition (/dev/md126p1). I ran the command gdisk -l /dev/md126 and here’s what it spit out.

Next, I re-imaged the machine with the original image using another imaging program (we’d rather use Fog which is the whole point of doing this). Then I attempted to capture the image with Fog as Single Disk Resizable and I got the Permission denied error again. I then ran gdisk -l /dev/md126 and here’s what I got.

[Sebastian Roth]

@Zerpie I am still trying to get my head around this so please bear with me. So in resizable capture you get the “mount failed: Permission denied”. What FOG is trying to do at this stage is mount the partition and remove the hibernation file as preparation for the partition to be resized before capture. Denied could either mean FOG is not able to properly access the partition on the RAID array. This I think would be a bit strange because it is able to read the partition table and find the first partition. The other thing I can think of is that the partition is somehow “locked”. Could be the partition is bitlocked [ref] or Win 10 fastboot is on or the NTFS filesystem is somehow not clean [ref]

Either way, you can disable removing hibernation file under FOG Configuration -> FOG Settings -> General Settings -> CAPTUREIGNOREPAGEHIBER (uncheck this). Let’s see how far you can get with this.

On debug deploy (non-resizable this time) we see that FOG was not able to put the partition layout on disk and therefore is not able to proceed. I am still not sure why this is happening. Do you capture and deploy to the very same machine or is it going to another one with slightly smaller disks (maybe only a few sectors if they are a different model).

[Zerpie]

I’ll try disabling the remove hibernation file setting today and test it.

@Sebastian-Roth said in Permission denied when trying to capture Intel RAID1 image:

Do you capture and deploy to the very same machine or is it going to another one with slightly smaller disks

It was the very same machine.

[Zerpie]

I disabled the remove hibernation file setting and attempted to capture the image again as Single Disk Resizable and now I got a different error.

[george1421]

@Zerpie To be able to capture with FOG you need to ensure the disk is closed correctly. With Win8+ shutdown is not really “shutdown”

Please use either sysprep to power off the computer before capture or use shutdown -f -s -t 0 to power off the computer and close all open files. If you use the shutdown command properly then you don’t need to worry about the hibernation files. This is not a FOG issue, but a Windows issue you will have with any disk (sector based) imaging solution.

[Zerpie]

@george1421 Thanks for the tip. I tried using shutdown -f -s -t 0 with both CAPTUREIGNOREPAGEHIBER checked in Fog Settings and unchecked and it didn’t seem to make a difference. I got the same errors I did without shutting down with that command.

EDIT: Also, I don’t know if it matters, but this machine is actually running Windows 7, not 8 or later.

[george1421]

@Zerpie Did you schedule a boot time disk check like the message indicated?

As for the win7/win8. Its always good to shutdown with the shutdown command.

[Quazz]

My best guess is that it fails to mount the partition correctly for whatever reason.

Only thing I can see (but shouldn’t cause issues afaik) is that you have mdraid=true in the kernel parameters twice.

[Zerpie]

@Quazz Nope. It’s only in there once. Unless there’s somewhere else it would have been entered as well that I don’t know about.

[Quazz]

@Zerpie It could also be under global settings, but I don’t think it really has anything to do with it failing.

[Zerpie]

@george1421 said in Permission denied when trying to capture Intel RAID1 image:

Did you schedule a boot time disk check like the message indicated?

I just tried that and then attempted another capture task and it still failed with the same Permission denied error as my original post.

[geardog]

@Zerpie
I know it doesn’t directly address your issue; forgive me.

Hardware raid cards are pretty darn cheap (used server pulls etc). Have you ever tried to rebuild one of those fakie raids? I’ve seen really poor results when it actually comes down to rebuilding a mirror, and the performance of general use is garbage.

[Sebastian Roth]

@Zerpie I have a feeling that you need to look into the details of this RAID array to get a better picture of what is going wrong. So after putting the machine into the original state start a debug capture task and when you get to the console run the following commands:

mdadm --examine /dev/sd*
cat /proc/mdstat

[Zerpie]

@Sebastian-Roth I haven’t been able to get back to this issue in the past week or so, but I went ahead and tried this today. I’ve attached pictures of the results.

[Sebastian Roth]

@Zerpie Ahh, I see, md126 is read-only which is probably causing the issue… Please try the following commands in another debug session:

mdadm --stop /dev/md126
mdadm --assemble --scan
cat /proc/mdstat

Yes, yes, imsm raids tend to do that

ref: https://bbs.archlinux.org/viewtopic.php?id=137058

So far I am not exactly sure if there is something we can do about this in the startup scripts. Let’s see if you can fix it manually and take it from there.