I’m from the old school if it ain’t broke don’t touch it with that being said I cannot believe how long I have been using this close to 8 years now and I love it. Had 1 hard drive fail in that time but otherwise going strong.
@robza As I said in the other thread your issue is a very different one although the error message is pretty much the same.
Your partition layout is not one of these easy straight forward ones that we got pretty good at but a more advanced one. We fail(ed) to detect that sda2 needs to be fixed size in your case. Tom has added some new code to the inits to hopefully get some better detection. So can you please upgrade to the very latest version and do a fresh upload (maybe just create a new image definition so you don’t mess with your working one) and then try deploying again. The d1.fixed_size_partitions file should be correct this time. Please let us know if it is working for you with the latest FOG version or not.
@Wayne-Workman That’s it. Thanks heaps for finding this! I thought I’d searched for \003 but obviously I didn’t - not properly at least.
You recommended to use undionly.kkpxe as the “quick fix”.
That’s not the whole truth I’m afraid! As it does not load a binary from the TFTP you need to use other methods like USB booting (rom-o-matic.eu, settings in the wiki but output format iso/usb). Or you could burn iPXE into the NIC ROM (haven’t done this myself yet so I cannot give any instructions). Why I did recommend undionly.kkpxe is because there is a known issue with a particular realtek NIC. As the OP didn’t let us know any machine or NIC details I am not sure if this is the same one. But I guess this is a very rare issue. So possibly it’e exactly the same NIC.
@SteveB689 probably something along the lines of fixparts /dev/sda and then :w and :q but I could be remembering wrong. If your intention is to create documentation, just say run fixparts /dev/sda and follow on-screen instructions.
No probs… that’s what I typed ,…
this can be marked as SOLVED
🙂
@LJedi First thing is to update to the latest, on all nodes - master first. Second is to review permissions, interfaces, IP addresses, storage groups, just going through it all.
Can you post the replication log? Also telling us which Image you updated recently. The output of ls -lahRt /images from the main server might reveal something.
Also, ensure all your fields for the storage node are filled out, such as web root, images path, ftp path, etc.
Actually switching the master option from one node to another will, in way, lock FOG imaging on a vlan or another.
Not so, the master node is simply the one used with uploads, and the one that does any multicasting. Switching it allows uploads from the other vlan, as you were trying to do.
I think you need a storage node per vlan as @Quazz suggested. It’d simplify this. Trunk isn’t the “answer”, but you’d like it and it’s more simple, more robust, higher performing, supports more hardware, etc.
@Wayne-Workman i tried a vm and all worked well, while talking to @Tom-Elliott it seems i have time/date problem with one of the new computers to be imaged, i can finally check this tomorrow morning and get back.
About my initial post about the services, i used the interactive registration and i think i did something wrong while proceeding, with a quick reg all services will be enabled like defaulted.
