Permission denied when trying to capture Intel RAID1 image

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

[Zerpie]

This post is deleted!

[george1421]

@george1421 OK I have a track on how to make it work. I just need to see how we can get the fix into the official FOS release.

We can patch it, but it needs to be fixed right.

[Zerpie]

@george1421 That’s good to know. Does that mean I’ll have to wait for a future update for this to work with my equipment?

Thanks for all the work you guys have put into this. I really appreciate how much this community is willing to help.

[george1421]

@Zerpie Sebastian was working through why the program was missing from the inits. I think he was planning on patching the inits for now and then going back to the buildroot project with the error why its not including the file when its selected. FOG uses Buildroot to create the customized linux engine that runs on the target computers.
It should be just a day or two before we have a workable solution for you. Its not something you did or didn’t do, its related to mdadm and the missing monitoring application for raid 1 arrays.

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

[george1421]

@Sebastian-Roth Looks like you have it worked out.

The only thing I did was install the updated inits and then pxe boot into a debug console. It worked right out of the box. Well done!

I’m going to start a normal mode deploy to ensure it can push the image out to the disk, but I’m sure it will work as it did with the raid0 setup.