Posts made by Tom Elliott

The start time was not being set “dynamically” (totally).

I think the intent was to lessen the amount of calls, just without much thought. Sorry I’m dumb like that sometimes.

I’ve updated this so hopefully future snapin task starts will represent the accurate time.

Ultimately, though, i don’t know what the times might actually represent so you might have a 1 second timeout followed by a 32 second gap that adminset occurs, followed by 2 seconds for the post image cleanup etc…

Hopefully this helps describe what you’re seeing.

This is now fixed just update working branch and revel in the success hopefully.

What’s the contents of that system’s image d1.fixed_size_partitions.

What’s the contents of:

cat /images/<imagename>/d1.fixed_size_partitions
cat /images/<imagename>/d1.partitions
cat /images/<imagename>/d1.minimum.partitions

This, too me, sounds liek the image was captured before our tests for “fixed” partitions became a little more proper and it resized something that was expected to be fixed size. What partition was it giving this issue on?

@sbenson
Can you please read this:

http://ipxe.org/err/2d0c61

You’ll likely need to build the file with the CA file itself, typically located in ca.cert.der (/var/www/fog/management/other/ca.cert.der)

What do you mean “login” not working? Do you mean simply “update” buttons not working?

if that’s the case, working branch already has this issue fixed. This issue is only, to my knowledge, present on Group page, which was fixed a few days ago.

@gotesson I’m only recommending searching for any bugs you might run into with the RC-6. If you’re unsure go ahead and post, and I’ll likely let you know if it’s known about/fixed or not anyway.

@gotesson Can you install the latest RC then? I know there was an issue, and it has since been addressed, I just don’t remember when. Pretty sure RC-6 has these fixes. I’ll get more useful information too. Mind you, there are a few bugs I’m already aware of and have fixed which are in the “working” branch. I don’t expect you to go to working, but search the forums for the problem before just posting that you found a problem as it’s likely I’ve already been informed and have a “fix” already in place.

Just switch branches from your git folder with:

git checkout dev-branch
git pull
cd bin
./installfog.sh -y

@gotesson So you’re getting the same message or not?

Found the issue and it is corrected for in the working branch.

It stemmed from the move to use the api backend. The pending display element was still using the old display methodology.

@sbenson What I’m seeing off the bat:

tftp://10.64.76.44/default.ipxe… ok

VS default.ipxe forwarding to:
https://10.63.76.44/fog/service/ipxe/boot.php

(10.64.76.44 vs. 10.63.76.44)

@sbenson said in Problem with HTTPS upgrade:

https://10.63.76.44/fog/service/ipxe/boot.php

And if you goto the link as is directly in the browser?

@sbenson Then it’s something in ipxe code that changed this, which is well outside my own scope.

@sebastian-roth The problem is I only know of a 100% sure fire way to build the ipxe binaries and the requirements aren’t readily available on the “base” installation. That said, i’ll admit I haven’t really looked into building any specialties as I’m busy on a about a million other things as well.

While not perfect maybe this could help?
https://wiki.fogproject.org/wiki/index.php?title=Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server

It’s literally in the lcoation stated.

/tftpboot/ipxe.efi

If it’s not there, then my guess is the installer didn’t complete or somebody deleted the file.

From Terminal you can copy this file to your desktop with (if you installed the Linux OS with a GUI):

sudo cp /tftpboot/ipxe.efi ~<username>/Desktop

Just replace <username> with the username you created and are logged in with.

You’re still on the development team, so please feel free, though I’d suggest pushing into the working branch now.

The tree structure is now:

master = stable
dev-branch = RC releases. (typically).
working = latest and greatest.

@msaglioc99 Not trying to sound mean/rude/crude or anything, but “Same Subnet, Different VLAN” makes 0 sense.

A VLAN, but definition, is a separate network. maybe the “SUBNET” Mask is the same between vlans, but they are definitely not on the same network (subnet).

Update, we’re up to 1.4.4. I think, however, the plugin issue was addressed in the RC’s (maybe? I forget now).

Then something is not right. If the ISO cannot fit inside the RAM space, and you’ve got 8GB of RAM, the Disk is not only 3.3Gb.

So I think I got it now.

Please update the working branch, and perform a hard refresh on your browser so to see the elements and updates. I basically rewrote all the javascript code to be a little nicer. Of course I make mistakes and a lot of them, but hopefully the new approach is faster, smoother, simpler.