Topics created by sudburr

Things I want to do later:

Give users the option to use buildroot themselves (it takes a long time) Make an init updater script so the init can be updated without just downloading everything and running the installer

Heh! You’re going to love this.

Twelve servers later, I check my source document.

I copy and paste my commands into the CLI … I had accidentally highlighted the CR+LF after the last command. So it’s piped into the CLI to appear, invisibly mind you, after the prompt. But it doesn’t actually enter itself at that prompt. So that when I enter “y” then <enter>, it has actually received CR+LF Y <enter> and fails out.

Doh!

Based on what I’m seeing and it appearing to show up randomly, I’m going to solve this issue. I think its more likely related to sourceforge and not getting the whole file properly.

The problem with the service start error seems to be that $linuxReleaseName in .install.sh evaluates to “Debian GNU/Linux”, not “Debian” as the scripts expect. After setting $linuxReleaseName manually in .install.sh, everything worked fine for me.

I’m solving this post simply because the title leads it to NEVER actually be solvable.

This will help. Thank you. I was just hoping someone knew definitively. This is a closed development system I’m experimenting with and I’m considering different ways of doing differing things. This is one of them.

The difference, for now, is ipxe is hosted directly in the SVN folders. This means an svn up -r <rev#> will roll you back. Of course I don’t constantly update ipxe files. I try to keep up with the speed of development on ipxe, but many times I’m much faster.

No. It’s only written when you install.

I try to summarize what I’ve found in this new thread here.

You could also try removing them out of the Advanced menu and create individual menu items for each of these, now that you are on a higher revision.

[quote=“George Stewart, post: 47485, member: 29650”]Thank you for the responses.

I am using the location plugin, but I have only one location. I’ve named this “main”. I have a dedicated 10 gig connection between my sites ( fiber ). One site can see the fog menu, register a device but fails (just reboots) once the image starts to pull down. My other site can’t boot to the fog system at all. I’ve ruled out the patch cables or switches being a problem as they are the same at all of my locations (gigabit switches). Should I setup additional locations at these other two sites and push the location\replicate the images down to these other sites? Just don’t want to go that route if my dedicated fog server here at the main location can handle this for me already.[/quote]

You only have one PHYSICAL location, but do you have V-Lans, or seperate broadcast domains configured? Is your location sub-netted?

The location plugin only needs to be used if you have logically separated networks segments.

If everything in your organization is all in one nice-simple network and on the same broadcast domain, you can just configure storage nodes if you like, or just have 1 FOG server, and nothing more.

Thank you!

Not a good day to be building a new server… ack

Update and a reboot. Two bits.

Fixed with SVN2890, thank you.

In about a month’s time or so this whole conversation will be moot for me as I’ll be replacing the images with updated recipes captured via PartClone.

If there is a bug and a solution I’m trying to find it not for my sake. I’ve already instructed our techs to use QuickImage and unicast in the meantime.

If the PartImage-captured PartImage-deployed image has a sector problem when multicast, then would it not also be corrupt when it is unicast?

Aggressively zero’ing the drives prior to PartImage Multicast results in the same.

Interestingly, interrupting a PartImage-multicast session will corrupt the drive similarly to the point where FOG will refuse to work with that drive until it is re-zero’d.

@george1421 Wouldn’t Know How To check if it’s in the repo, but I can give it a shot almost home.

Added some commands, cleaned up others; tweaked remarks; functionally identical.

Tweeked some more.

Updated to a single line copy/pasted post-install configuration and SVN2651.