Permission denied when trying to capture Intel RAID1 image

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

[george1421]

@Sebastian-Roth Deployment was successful.

I did notice there was an error message I have not seen before, but I don’t think its related to intel raid.

db_root: can not open: /etc/target

Everything works OK so I don’t know maybe if its a warning we can ignore.

Also FWIW I’m also running on the latest FOS kernels (4.18.11)

[Quazz]

@george1421 I’ve seen that on the latest kernels on normal installs too, doesn’t seem to hurt anything afaik.

[Zerpie]

My first attempt to capture the image after downloading the new init files I got an error.

Partclone fail, please check /var/log/partclone.log !

Failed to complete capture (savePartition)
   Args Passed: /dev/md126p1 1 /images/00270e3b9d1e all
    Exit code: 1
    Maybe check the fog server to ensure disk space is good to go?

After the host rebooted it started a CHKDSK and I’m waiting for it to finish now.
I may need to restore the original image again just to get a fresh start. I’ve also checked the image storage and there’s plenty of space available. I’ll update once I’ve gotten a few good tests. Thanks!

[Zerpie]

I’m not sure what that error was caused by the first time around, but I was able to successfully capture the image on my second pass. Now I’m deploying the captured image. So far so good. No errors yet. Fingers crossed…