Permission denied when trying to capture Intel RAID1 image
@george1421 Well this is what I see when I configured the 780 with 2 250GB disk setup in raid 0 move (stripped)
and for lsblk
I can say that I have a global kernel parameter of
mdraid=truealways set. When I watched FOS boot, I saw message about mdadm container assembled and then the container started. I haven’t tried to deploy to this system just yet because I need to edit the host configuration to include /dev/md126, but I’m pretty sure it will image like this. The raid array appears to be in good health.
[Edit] Yes I can affirm that it imaged correctly Windows OOBE is currently running on that system.
Download and put in
/var/www/fog/service/ipxeon 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’m thinking that md127 being set to inactive is also a clue. I just grabbed an old Opltiplex 780 and I’ll spin up a test workstation with the intel raid configured to see if I can duplicate the results here.
@Zerpie Ahh, I see, md126 is
read-onlywhich 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
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.
@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.
@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
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.
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.
@Zerpie It could also be under global settings, but I don’t think it really has anything to do with it failing.
@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.
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 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.
@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.
@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 0to 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.
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.
I’ll try disabling the remove hibernation file setting today and test it.
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 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).
@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 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 This can mean two different things:
- The image is not complete and does indeed miss some or all the files.
- 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=1as “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/md126and post a picture of that here.
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)