Posts made by theodor.scherer

@tom-elliott yes, you are right it loads the _32 version. I tried to load many of the kernels i could from kernel updates, with no luck. The kernels and image seems to load fine, and the menu is ok. But after when it realy tries to work, running the commands for registration, or deploying (partimage), it crashes because lack of memory.

@tom-elliott So, I tried many values. If I set a lower then 100M value then even if the menu will load and memtest will work the rest of the menu options will run into kernel panic. The PC’s are Celeron 533/128MB.
In VM I tested with 220 MB RAM, 100 for the ramdisk, it works and that seems to be a minimum. So minimum requirement for a PC will be 256 MB :(. That is pretty much I think for the task of capture and deploy a PC. The registration anyway must be done by hand, so I did not test the quick registration requirement. May I change something and renounce at ramdisk? and work somehow as memtest mode? without ramdisk? Or use a network disk for loading what is possible?
Or there is an older version that is running by default with small memory?
thanks.

@theodor-scherer I found this topic about PC’s with 128MB Ram. ( https://sourceforge.net/p/freeghost/support-requests/10/ )I didn’t think that RAM will be such a problem, it seems to be. So in the end somebody said that it is a version that rolls a bit over 60MB and that seems to be perfect. Which version of fog may be?

I tried now on one real machine. After boot in the menu and chose quick registration I got this:

The PC is a celeron 533MHz.
Which is the recommended boot method for such a PC? Must I return at an old pxelinux?
It is better to open another topic maybe or staying here is good as are related?
Thanks

@tom-elliott
eth0 has link in a network we have not rights to mess with. And no reason for that as we have an interface just for us.
eth1 has link in the fog network. We can boot from it, and we can do anything we want.

“How hard would it be to establish routes allowing nic0 to see the fog server? I guess what I’m asking is the problem at the boot menu or the actual wrong nic is associated to the host?”
There is no way to mess with the lan connected to eth0. Of course the problem is that the registered MAC is the eth0’s MAC, and we boot from eth1, so that is the problem. The servers only register a MAC we don’t boot and spoke to. And we don’t want to do it.

The vlans are not mac related but think at 2 networks where you have rights only in one, the other is a different thing, it just need to coexist. You can not modify, switch cables, etc. Do not insist anymore it is for anything else, other network, other dhcp, other all. And other switch and infrastructure. Fog has it’s infrastructure and it is connected to eth1 how I said. I will add in the end it’s MAC by hand. But for an app to insist to register and work only with a nic, just for existing and not to talk to a nic that has the connection to it, that is a bug, no matter how many years that app is working
I was working with FOG many years ago in XP time. It was and it is a great piece of work, but that is a thing I discover and it works bad, in this conditions, it can be replicated, and it may be a normal thing for one from now on, to have multiple interfaces that must not have a link with fog server. The app must not limit somebody to boot with the first, second or any other interface in order to work well … Otherwise is buggy … If I can add manually the correct MAC, and if it will work that way after, will be an workaround that not exclude the bug.

@tom-elliott said in MAC Adreses:
“> When it sends the information to the server it’s sending all macs that it finds.”
Sorry, I see only one MAC registered the one that has no connection with FOG. Are you sure that I must see them all, after quick registration?

“If eth0 is the nic that’s not communicating it doesn’t matter. It’s just sending information it’s finding. You could work this by disconnecting the nic that doesn’t communicate to fog, or switch the ports around so eth0 is the nic communicating to fog.”
I cannot do that on all machines, they are embedded in some boxes, locked, etc. Neither to switch the ports … The Nics are different, and it must be that way. The nic for fog anyway is 1G and the other is 10/100. What I can do is manually add the MAC in fog server.

“Either way, this isn’t something we can fix with a simple arp as we need to know which nic is communicating to the fog server, not the fog servers MAC address.”
I was referring to an arp from the server to the IP address of the host in the course of registration … As the host is sending data for registration - for sure the IP address is in the data, and the server is doing an arp on that. It maybe simple methods also. Only from host you can bet that the eth reported by ifconfig with a greater TX or RX is the one which was booted that will be very, very simple

“This likely will not be addressed for 1.5.0 as we really are trying to get a machenism that doesn’t rely on the MAC address. While we could make this work, it would not be a simple thing, and would only be used for a very short amount of time.”
I have seen that 1.5.0 is out, this is good news. And I understand that you cannot do something so quick … For me the MAC was and is yet a great way to identify something in network, I am curious about what are you trying to do …
Regards, I will go for boot one of them now.

@tom-elliott Hello, Tom. Sorry for yesterday, I was all day in a hurry and very pressed. I will take it again because I see it is hard to understand.
“You have stated that machines are registering.” - Yes, If I do the quick registration I can see on server in the list of hosts, that I have 1 host with a single MAC. But the MAC is from the eth0 which is not attached to the fog network. Eth0 has other purposes, another switch, Vlan, etc. (that maybe responds to your questions about what nic is booting fog). So I have the host registered on server.
But If I reboot (the host) after registration, in order to capture or something, on the host’s screen I have the message that “The host is not registered”. While it is on the server, but it doesn’t recognize itself, I think because the MAC registered which is eth0 MAC.
That’s the bug. I hope you understand now …

Maybe I can add manually the eth1 MAC’s also, but this is a thing which must work on auto not to workaround with it.
In the end I do not Understand this: “I’ve also asked what nic is booting to fog? If it’s the nic that’s not communicating back to fog,this would explain why the host is showing unregistered.”
If the first nic is connected elsewhere, it cannot boot from it, so, of course it is booting from the second nic connected to Fog … Or maybe I don’t get the sense of the phrase …
Today I will try directly on one machine, I will skip the simulation on VM.
Thanks

@tom-elliott no, I think you did not understand correctly I think:
So I perform registration. The first NIC’s MAC only is registered on server and i can see that the MAC is from the NIC that has not communication with FOG. It is on another VLAN and so… For that when I want to capture, at the next host boot the host is saying that it is not registered. Is that more clear now? It registers on server with a MAC which has nothing to do with our task and with the server

@sebastian-roth and this behaviour is much like a bug, to register on an eth card at random. If you want to register olny one card, for sure is one that can communicate with the server(any other way your host will complain about not being registered at the next pxe boot - that is buggy). So in the register process we can call for example an arp -a with the IP addresses from the host, to know the MAC we are talking with … Is one method, and for sure not the only one. I am sure that we can know also from the host on which eth it is talking to the server…

I think it may be much more simple… In order to do registration, the host is sending to server the data … So the IP or the MAC from where the registration data comes identify the machine for the server. It is normal … generally that’s the address we want to have … sure the rest of existing eth cards, wireless or other thing maybe they are interesting in particular cases, but the in the most cases we register machines with the interface we want to have it registered … I think so, is it not?

I am running the last 1.4.4. It register only one (the first). So after registration when I reboot I see on WebIf only one mac, and the host says it is not registered. No way to capture. If I disconnected the first NIC, and re-performed the registration, it happens with the correct MAC, so all is good. But normally it must work from the start registering the MAC that is used to boot with. Don’t you think so? for now I am not using the fog client, is out of the scope. In the end all I need is only capture and deploy some old WinNT 3.5 systems. My test setup now is for the server an Ubuntu server 16.04 VM with fog 1.4.4 and I use, for testing capture and deploying, another VM with an Ubuntu image. Of course with 2 NICs one in the first VLAN and the second in the Fog’s Vlan. But in the end the real machines are some celerons 533 with Win NT 3.5. May I expect some boot problems on those machines? How can I simulate best those in VM? I use Proxmox as Hypervisor.

Thanks

Hello, I am back to FOG after a long period of not using
Now, I have a network of some old PC’s each with 2 NIC’s. The first one is reserved for things like internet and other inside comms, and that network iface will be inaccessible for me, but the second card is accessible for things like FOG. So when I try to register the host, at reboot will say that host is not registered because only the first card’s MAC was registered with the host. I think the normal will be to register the MAC with the server works, and not the first MAC of any order … What do you say, it is hard to implement that? Or maybe to register all the MAC’s indifferent of the state of connection or the order of connection?
Regards and Thanks