@ldiorio ok good, then its not something that FOG is doing to the image. Can you try one more test, do a warm restart. At the refind pause press ctrl-alt-del and see if it reboots correctly after imaging…
Wait, I think I lost where we were. This isn’t after imaging but just booting through the iPXE menu. So every time you boot through iPXE refind triggers a disk recovery? Do I understand that correctly? This has nothing to do with imaging at all.
@pberberian said in What is the status of aarch64 support for FOG?:
I will need to generate a new buildroot config
Generate a new base build root config and then probably manually merge the FOG settings in. (or generate a arm base config file and then merge the differences between arm and ia64 with a text editor. I’m not sure which would be easier). Its been a while since I messed with buildroot, and surely Tom would know what exactly needs to be done.
@ldiorio The question in my mind is it the fact that you have CSM disabled causing the auto repair or something refind is doing?
To test this you could change the refind timeout (in /var/www/html/fog/service/ipxe/refind.conf) to something like 20 seconds. While waiting in the refind time out, power off the computer. Then power it back on. See if its refind for sure causing the issue or because CSM (legacy roms) are disabled.
@joe-schmitt should we then kill the other files so some block head moderator doesn’t link to them in the future?
@pberberian I’ve talked with one of the other mods on this exact issue a few weeks ago. Someone else asked for arm boot images. If you are capable of cross compiling iPXE then you should be able to do the remaining bits. You need to cross compile bzImage as well as the inits (as you mentioned).
The Developers build bzImage from the linux kernel source files found here: https://www.kernel.org/ You can get the kernel config template file from here: https://github.com/FOGProject/fogproject/tree/master/kernel You will need to update the settings required for your ARM processor.
The inits are generated by buildroot https://buildroot.org/ You can get the buildroot configuration and overlays from here: https://github.com/FOGProject/fogproject/tree/master/src/buildroot Of course you will need to adjust the settings to be appropriate for your ARM processor. While buildroot can build both bzImage and the init.xz files, the developers have chosen to build them separately. Personally I feel both could be built by buildroot, but to each his own.
Now once you get the ARM bzImageARM and init_ARM.xz you can copy to the fog server in /var/www/html/fog/service/ipxe directory. From there you can change the bzimage and init.xz on a host by host, or by host group, or globally depending on your needs.
Now finally if you get all of this to work, please contribute your results back to the FOG project.
@bobbyfrank OK are you using the FOS usb boot device or something you created?
If you are using the FOS usb boot, pick option 6 to get a debug console on the target computer. That should drop you to a linux command prompt on the target computer. From there see if you can ping the FOG server by IP address and dns name. Make sure both work correctly. I can tell you that typically FOG doesn’t use the dns names, but instead uses the IP address for everything. that way FOS doesn’t have to deal with misconfigured dhcp dns settings.
@coxm Now that you have a working solution, I’ll tell you a bit easier way to go about this.
If you know ahead of time you will keep the OS on a thin image and have the /images on a separate disk then before you install fog create the /images directory and mount your image storage disk over /images and finally install FOG. There will be nothing to change post installation. If you see you need to add the disk after fog is install there are a few more steps involved but that’s basically it.
@coxm While I would not have added the big disk like you did, you still should be able to make it work.
If you look in the exports file you should see two file share lines. You updated the one for /images but you missed the one for /images/dev.
FOG captures to /images/dev then moves the file to /images which is read only. This is done to protect the captured image from accidental deletion. You can see the ro vs rw access in the line below, its the first parameter.
/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)
Tell me a bit more about the target system you are trying to capture from. Is this a virtual machine or physical hardware? Also is this target system in uefi or bios mode? I’d like to see if I can duplicate your setup in my lab.
@mpsadmin I have my fog-pi server with me that has FOG 1.4.4 on it. I’m looking at the code and it appears to rely on the file byte count being the same to indicate if the file needs to be replicated or not. I’m not a programmer so this object oriented php is a bit greek to me. But so far it looks like byte count is the trigger. Now this is the byte count as reported by FTP session. Also the log writes to /opt/fog/log look fairly descriptive to what exactly the replicator is doing.
@mpsadmin OK then we might need an opinion from one of the @developers to give us an idea why the NAS is not reporting what the FOG replicator expects.
If I remember right there is 2 or 3 replicator logs. One is the main replicator log, one is for the storage node, and there may be a log file for each image being replicated. I don’t have access to my production FOG server at the moment to confirm. But I thought the logs were pretty descriptive to why it was replicating.
@turcotter Here is 3 different ways you could do this with powershell and a fog snapin. Reply #2 is interesting since it embeds the csv file right into the powershell script.
We can only offer ideas based on how the snapin system works since we have not / do not assign static IP addresses this way to hosts. I’m not saying its wrong, only we don’t have the experience doing this.
Thinking more about this (my fist answer still is true).
I wonder what would happen if…
lsblkThe short answer is you can only “burn” an image created by fog with fog.
@coxm whelp, if you look at the exports file it should look something like this:
/images *(ro,sync,no_wdelay,no_subtree_check,insecure_locks,no_root_squash,insecure,fsid=0)
/images/dev *(rw,async,no_wdelay,no_subtree_check,no_root_squash,insecure,fsid=1)
Knowing that a standard fog server places its images in /images and you placed the images files in /media/ubuntuadmin/Data/Images what might you think you need to update? Also watch the capitalization in the path.
@coxm ok so I have fat fingers. That is the right file. You should see the same shares in there as when you first ran the showmount command.
@coxm well that is where your access denied message is coming from.
As a test, update /etc/exportfs to the real locations. And then run the export -a command. And finally run the showmount command again to ensure the proper directories are shared.
@coxm Well the screen shot tells me that you have something abnormal with this storage node.
The target computer is trying to mount /media/ubuntuadmin/Data/Images . Is this some type of external storage device on the remote server?
On the remote storage node please run this command: showmount -e 127.0.0.1 and post the output here.
@turcotter So if you were to take my script and change it this way.
net use w: \\Server\Share /user:domain\user password
Set csv=w:\pcsetup\ipchanger\ComputerList.csv
if not exist %csv% echo "Unable to access csv file" >c:\windows\temp\ipset_error.txt
for /f “skip=1 delims=, tokens=1-7” %%a in (%csv%) do (
and then at the end remove the mapping to the w: drive
net use w: /delete
Warning: I did not test or debug this but just wrote off the top of my head. But the idea is that if the script can’t reach the csv file it will create a flag file ip_set_error in c:\windows\temp directory.
@turcotter The issue in the link is that SYSTEM does have local admin rights, but it can’t reach outside of the box to pickup the csv file. If you connect to the remote share as a domain user then you can access the central csv file.
The other method is to deliver the csv file with the batch file.