init.xz issue?

bjmarowitz

@Wayne-Workman Thank you … all settings are as they should be. I followed the Fedora 21 guide in the wiki for the initial setup

@StahnAileron Interesting … Until your reply, I haven’t found anyone else having this issue, so it still seems like something simple being missed. If it is something to do with the TFTP boot files, I’m not willing to start switching those around without a further understanding of what is happening at the point of the reboot.

Is there a wiki page or document or posting somewhere that explains the steps FOG is making behind-the-scenes? IOW, when the screen shows “init.xz <OK>”, what just happened? What is supposed to happen next?

Tom Elliott

@bjmarowitz to me the issue seems very simple, that the init.xz is not fully downloaded, and therefore is not going to work. Maybe try rerunning the installer and wait for a bit.

StahnAileron

@Tom-Elliott @bjmarowitz Well, my actual problem was a bit more complex than that.

First, I was able to get multicast to work properly (via a thread I started an Tom helped me with. Found out old files left behind during upgrades and incomplete/incorrect installations were the problem.) The FOG server I was working on was a for my school. (They partnered with a non-profit organization; we do PC refurbishing for them. In return, they get the opportunity to give students hands-on experience. I’m a work-study for the IT program chairman.)

After all the work to get it functional, I took some time away from the lab to get caught up on school work. On Monday, I speak to the chairman about the lab and he tells me the multicast function is a bit dysfunctional. He couldn’t get multi-cast to work again, not without a system reboot of the server. I wasn’t there to witness this, so I take his work on it. He said they stall on the Partclone screen. He also made some changes to some things. What specifically, I don’t recall, though I’m pretty sure they weren’t directly multicast related…

I go to check the server logs for multicast, but it’s empty. In fact, all the logs were empty. They worked when I was working on the system last week Wed. Anyway, I set up a multicast job just to check. I don’t even think I got as far as I should’ve. REALLY weird.

Well, this IS Trunk, so things happen. Maybe an updated install would help? I pull the new version via SVN and install. No problems. Set up the multicast job. The workstations boot into FOG and then start crashing out. (Kernel Panic at some point later during my troubleshooting…) Something went REALLY wrong.

Now unfortunately, I didn’t document my troubleshooting and testing well enough. Suffice to say we’re now on a 1.2 FOG install until I figure out what is going on (I like Trunk/1.3’s web interface design and feature set more, so yeah…) I haven’t touched it since getting 1.2 up and running initially (I left it doing an image pull test.) I probably won’t be touching FOG again until this Thursday and Friday. (I need to catch up on schoolwork on my class days.)

It’s a convoluted mess on my end. So until I figure out something and have pertinent and sensible info to relay for advice (I can’t have people making sense of my mess when I’m not even quite sure where to start…), I’ll be quiet about the matter… Though now I have some questions (had thoughts while typing all this up):

@Tom-Elliot Are the TFTP boot files in 1.2 compatible with the features of Trunk? Or do I need the TFTP files included with Trunk for it to work?

1.2 works, so I know for sure the boot files for it are non-corrupted. My original Trunk install was actually a 1.2 to Trunk upgrade installation…

I did pull the TFTP boot files many times during my testing spree.

Again, you won’t hear from me again really until Thursday at the earliest. I hope I make progress, even if it does wind up being a dumb moment on my part.

george1421

While this recommendation isn’t fog specific, I think I would take this approach.

You have 1.2.0 working right? If so leave that system in place for a short time. It is working and the school can deploy.

Take a new machine (desktop with a dual core and 4GB of ram). Install Centos 6.7 on that system. Its in the redhat family so you should not have much of a learning curve switching from fedora to centos. Do a minimal centos install. Just be aware that there is no gui with the minimal install so you will have to use putty and/or the console for configuration. Ensure you update the computer to the latest patches using yum. Then download and install the latest svn trunk directly onto the system. Do no upgrade from 1.2.0 go directly to the svn trunk. This will ensure there are no remaining older bits on the system. Then just follow the installation instructions for centos. Document your steps, step by step so you can create an installation manual and have a history of changes. Once you get this second “clean” system built are you are sure it is configured correctly, change the dhcp options to point to this new server. If something goes wrong with the new server then just change the dhcp setting back to the working 1.2.0 build.

Once you have the svn trunk version perfected then resetup the main server. I can tell you that installing fog on Centos works and works well. Centos isn’t leading edge like fedora, but for servers you want stability over a fancy gui or latest hardware support.

Again this is only my opinion and how I would approach the problem.

Wayne Workman

@george1421 said:

Install Centos 6.7

Why are you so big on 6.7? Why not just go with CentOS 7 ?

george1421

@Wayne-Workman

Right now what the OP is saying is a bit conflicting in my mind. So we need to get to a known good place with the SVN trunk. I can say, absolutely that FOG SVN trunk works on Centos 6.7 with 0 alternations or messing around. Follow the documented install instructions (even on the svn trunk) and it will work, period. Understand that I’m not saying that Centos 7 (rhel7) is not a viable candidate. Personally I don’t have quite enough experience with Centos 7 to say absolutely there will be no issue. It appears that the OP is having issues that could or could not be related to the OS, or the way the FOG interacts with the OS. To go to a known good state I recommended Centos 6.7 on alternate hardware. If it works there and not on the main system then we can start to pick the OS apart. If FOG acts exactly the same between the production system and this test system on a known stable OS then we have more justification to point to something in the FOG SVN trunk is amiss.

Also for 6.7 its still a viable option since LTS ends in 2020 with full system updates ending in summer 2017 (it kind of parallels the question of Win7 vs Win10, what do you install today?). The answer will be different if you ask me the same question next July. FWIW: LTS for Centos 7 ends in 2024.

bjmarowitz

@Tom-Elliott Thank you for your input… I waited for quite some time, and the issue persisted.

@StahnAileron @george1421 @Wayne-Workman After not getting further with Fedora 22, I set up the SVN trunk FOG server on the same machine, with Centos 6.7. Outside of correcting a reboot parameter on Centos itself (Optiplex 990 issue), it all works as expected and I am playing with the imaging capture/deploy.

@george1421 Thank you for the Centos suggestion, it has been sometime since I’ve used that but it is coming back to me

I will most likely try Centos 7 at some point, but I have enough playing to do for now

Thank you all for your assistance, and thanks for making FOG available!

george1421

For what its worth. I just spun on a centos 7 fog server. With the exception of a few commands that are different between 6.7 and 7. The current FOG trunk installs and operates on Centos 7 without issue. Understand at this point I haven’t uploaded or downloaded an image yet. But basic functions on Centos 7 are working.

Right now you appear to be in a good place with Centos 6.7 so hang there for a bit and then focus on make your fog configurations perfect for your tasks.

Wayne Workman

@bjmarowitz said:

@Wayne-Workman After not getting further with Fedora 22, …

That’s it, I’m writing a Fedora 22 article.

Sebastian Roth

@bjmarowitz Do you still see the init.xz hang issue or should we mark this solved?

KKTwenty101

@george1421 regards to centos 6.7 I had difficulty installing sql using the trunk install. I needed to install sql separately, sql wouldn’t start without a separate installation (for me), I didn’t bother debugging as it took seconds to spool up a separate yum. I used the minimal 6.7 install ISO on a freshly minted hyper-v host. I did try with 7 at one point but stuck to 6 as the instructions were more verbose.

obviously mariadb was used.

george1421

@KKTwenty101 Interesting, I also do a minimal install for Cento 6 and 7 and fog installs no problem. As long as you remember to disable iptables and selinux. I know that FOG installs mysql during the initial install because the password for mysql root user is blank. If you are doing something outside of the normal FOG install then something is broken either with the system or the FOG installer.

My FOG server is behind a proxy server so I have to create a few envron variables and update wgetrc and subversion with the proxy server settings, but the basic workflow is

Install centos 6.5
yum upgrade -y
yum install subversion wget -y
reboot
disable selinux and iptables
reboot
mkdir /opt/fog_trunk
cd to the fog_trunk and use subversion to copy the current build
cd /opt/fog_trunk/bin
./install.sh

That’s all I’ve done and it works correctly right out of the box, so to speak.

KKTwenty101

@george1421 I wonder if there is something different in 6.7? Originally I used Ubuntu where the documentation was followed to the letter, I only recently rebuilt as Centos in the last week due to SMP and NIC issues in the Ubuntu integration services. It could be that a hyper-v centos installs/activates “something else”. I have done the same as you above except that I install sql (and nano- I really cant use VI) at point 3 (and I disable selinux and iptables before point 2).

Either way, the system does work for me and any errors AFTER base installation are usually down to importing settings from a previous versions (FOG user password differences, large log files, hosts with incorrect usernames/passwords, AD activation differences etc etc).

I have no doubt it will be something I have done as I am primarily a windows sysadmin with enough Linux experience to get me by.

bmaster001

Sorry to reply to a rather old topic, but I’m having the exact same issue…
History:

fog 1.20 on Ubuntu 12.04 (which served us well for a couple of years now)
a “special” computer arrived this week that we need to image: a Thor VM3 (https://www.honeywellaidc.com/en-US/Pages/Product.aspx?category=vehicle-mount-computers&cat=HSM&pid=thorvm3)
Since this uses uefi, it doesn’t work with fog 1.20. So I upgraded to the trunk version, hoping this would fix all my issues
it boots to the fog menu, but when I choose the quick registration task, the machine hangs on “init.xz … ok” (no reboot, it just hangs there).
memtest doesn’t work either: it says “memdisk… ok” followed by “Could not select: Exec format error” and “Could not boot: Exec format error”

I read in this topic that installing fog on a fresh Centos 6.7 helped for @bjmarowitz. I tried that today, but it behaves the exact same way in our situation here

PS: Last attempt was with trunk version 8099 (or is it the SVN revision 5678 that is important? I’m confused )

Any help is very welcome! Thanks!

george1421

@bmaster001 I strongly suggest that you start your own thread since your conditions are probably different.

If this is your first uefi system, what are you sending for dhcp option 67? This uefi system needs the uefi boot iPXE kernel. So you will need ipxe.efi being sent to “this” target computer.

bmaster001

I understand, I created a new topic: https://forums.fogproject.org/topic/7767/another-init-xz-issue
PS: dhcp settings seem to be ok (see the new topic).

init.xz issue?

248

11.7k

17.2k

154.7k