Permission denied when trying to capture Intel RAID1 image

[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.

[george1421]

@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.

[george1421]

@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=true always 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.

[Zerpie]

@Sebastian-Roth Here’s what I got. This was the same debug session. Not sure if I need to start a new session first.

[george1421]

@Zerpie I can see that my test is a bit off point since I “though” you were configuring for a stripped array (raid-0), but looking at your picture below you are using a mirrored array (raid-1). So my screen shots are not really valid other than proving that FOS can support intel raid arrays.

What does the output of this command look like?
mdstat --detail /dev/md126

Hint reboot first since you disassembled the /dev/md126 device with the stop command.

[Zerpie]

@george1421 It doesn’t recognize the command mdstat.

[Sebastian Roth]

@Zerpie Try mdadm --detail /dev/md126

See chat bubble in the right upper corner…

[Zerpie]

@Sebastian-Roth

[george1421]

With the raid array configured for raid-1 (Mirror) I am getting the same results as the OP. I can’t seem to switch it from raid-only to read write to start the resync process. I’m still working on the issue as time permits today. But there IS something up here, I feel its hardware/array related. It should work because all of the bits are aligned right as soon as I can get it out of read-only mode.