Posts made by Tom Elliott

Now that I understand the full scope of the problem, I more clearly was able to take and fix this issue. Login should’ve worked for any page but it was loading page specific js code even when no user was logged in. I have since corrected this in working branch.

If this works, I’ll push a pull request against partclone so future versions shouldn’t hit this problem.

@Sebastian-Roth thanks for taking the time to look this over and hopefully this is the solution. If I had to guess, this was just a simple oversite on Thomas Tsai’s part.

@SlimJim Thanks for the patience and understanding on this.

Init’s have been updated with the patch, as well as I fixed a compiling issue with partclone-0.2.89 in case anybody else was at all trying to build their own inits. (Sorry I fixed it manually once, and had forgotten that I had to do that. Found appropriate fix though and it is now a part of the source scripts for building the inits.)

Please give a try for them.

Init’s can be downloaded as:

wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xz

Hopefully it fixes the issue you were seeing.

@herb There really isn’t a “feature list” or schedule persay.

This being a 100% free (as in free food) software product, we developers work on FOG on our free time. Because of this, most features requested are added as feasible/suitable. There isn’t a specific list we’re striving to incorporate as FOG thrives from the community input/feedback. The schedule, due to this being 100% free, is kind of as we see things progressing. There may be years that go by without an update, or it might be days depending on needs.

I know this isn’t an answer most people like to hear, but it’s the truth, and I personally think it’s ultimately better this way. (As long as active development is ongoing.) – (I don’t plan on cutting from the development anytime soon.)

@crbarahona Is the OS configured as a Legacy (MBR) style image or is it configured as a UEFI style image? It, at least seems, to me to be Legacy style windows image as you are using the SANBOOT/GRUB_FIRST_HDD to work on both 1604 and 1703, but it almost sounds like 1703 is forcing some form of UEFI stack to the disk. (Maybe 1703 is changing the disk to a “dynamic” disk changing how the disk is partitioned without losing the data.) – (Doubt it as changing to GRUB works okay – then again GRUB is a proper bootloader and might not be hitting the constraints the bios is handing out as iPXE could be).

I really don’t want to think this is an iPXE issue considering the iPXE code did not change one bit. If it were an iPXE specific issue, the problem should be present on the same system regardless of what OS you deploy/use on it. The only variable that’s changed here is the OS on the client machine so it must be something that OS is doing.

The next question is more direct, I think.

If you deploy the 1604 image to a machine, boot into Windows, then deploy the 1703 image to the machine is this issue immediate? (When the machine reboots after the post deploy does it boot into windows or is it immediately broken?)

If it boots into windows 1703 and then fails on any subsequent reboots I would think there’s something Windows is doing regarding firmware which could be causing the problem. (It could even be something like the firmware to the NIC changing how iPXE is passing to SANBOOT, meaning iPXE might be able to do something to check and fix this.)

If it doesn’t boot immediately following deployment, then I believe the issue is how the disk is “laid” out.

I know there’s a lot of information here, just trying to get a full picture.

@jim-graczyk But I already made the change for the snapin start times to be more accurate. It does not set all snapins to the same time, it set’s each snapin it’s working on to whatever time it starts now. Are you saying this is not working? See here:
https://github.com/FOGProject/fogproject/commit/e6a4cd1996d6c93885b91681e31ac22732e9082f

I don’t think setting the time for the cancellation is necessary at all for the reasons I listed earlier. I understand what you’re saying about cancelled snapins, but I still think it’s better to know how long before each snapin task was cancelled.

@jim-graczyk I’m not feeling the change over for that. Playing with the cancellation ultimately isn’t hard, but it could be useful to help describe to managers why you cancelled the task. “Well it was running for 5 weeks 2 days 8 hours 45 minutes and 16 seconds without running. This is why I cancelled it.” Or (I cancelled it because it was unintended to be pushed to that machine.)

This is a personal preference. I think having the time it actually completed makes the most sense. Besides, to get it to properly display 0, I have to do a check on all the current “start times” and set each task. That may not seem like much, but means additional queries to get the information. (Not too much, but can impact performance too).

Create a backup of your current /tftpboot say as /tftpboot_persSigned.

Upgrade.

Once upgrade complete do:

mv /tftpboot /tftpboot_orig
mv /tftpboot{_persSigned,}

@sbenson Can you create a backup of your /tftpboot folder.

I’d also ask that you update to the latest rc please. I added, after rc4 I think, the links will change for the protocol being requested. rc4 still caused defaults to jump to http for internal links.

The command to do such a thing would be:

snmysqlhost=10.10.10.10 snmysqluser='root' snmysqluser='passwordforcentralsql' ./installfog.sh -y

What I might recommend, is there a particular reason the FOG server requires mariadb? If you’re just trying to centrally manage the db you can specify an alternate snmysqlhost, snmysqluser, and snmysqlpass directly through the installer.

Sorry about that, please repull and reinstall. This should be addressed.

Updated, please repull dev-branch and install, this should be corrected for now.

Found and fix coming shortly. I’ll ask you to update once done. Thanks for letting me know. Sorry I missed the variable trying to set.

@olivetree Have you tested it first. I don’t want to just solve it based on what your network admin’s say.

@george1421 This wouldn’t be a bug. The very same mechanism that handles images (which you’ve already pointed out) handles the drivers (particularly when you consider the drivers is also an image too). So while there is a problem, it’s highly unlikely this is a problem being caused by fog, at least not directly.

https://news.fogproject.org/fog-1-5-0-rc-7/

Fixed in working branch.

Fixed in working branch.

Fixed in working.