Makes complete sense.
Already have one open, as someone else is having the issue as well. He seems to have found a likely culprit, where the FS is setup to ext42 instead of ext4… More info here:
https://forums.fogproject.org/topic/7690/kernel-panic-on-quick-register
Sorry, didn’t mean to threadjack, but it appears to be the same problem. Can we merge?
Updated from whatever the last git release was to 7895 . Option 67 is set to undionly.kpxe, as I had been using trunk before. Same issue.
Is there a way to roll back if you’re using git instead of SVN?
Getting the same thing here, same version. Boots up, can image machines already registered in the UI, but if I attempt to quick register or full register, I get the
Kernel panic - not syncing: VFS Unable to mount root fs on unknown-block(1.0) Kernel Offset : disabled
Yep, looping back. I also checked the “installed plugins” bit and it has nothing.
Brand new install, Ubuntu 14.04, trunk version 7981 via git this afternoon.
Added a storage node for the first time, went great. Then went to add the location plugin, so I can direct my clients to the right storage node so they don’t pull across the WAN.
Enabled plugins in Fog settings.
Went to Activate plugins, clicked location. All good.
Went to install plugins, location listed, went into it and clicked the large “Install Plugin” button. It just loops back to that page.
Am I missing a step? I haven’t used plugins before.
@Tom-Elliott So pull from Git again? Sorry, still learning trunk.
Alright, after figuring out my Win10 issue, I’m now having a new one.
I have my clients registered in Fog, put them in a group, associated an image, etc. All works great on Unicast.
However, when I attempt to start a Multicast session by going to the Group > Basic Tasks> MultiCast Session> Create Mulit-Cast task, the browser just returns a 500 error and nothing get started.
I just pulled from Git an hour ago, so I’m on version 7212 according to the happy cloud logo.
Any input? Unicast is working great and tested fine, so now I want to start pushing out labs.
Update:
Just thought to check my apache logs, /var/log/apache2/error.log shows the following for my IP address
[Tue Apr 19 12:48:14.951242 2016] [:error] [pid 25044] [client 10.1.0.199:58062] PHP Fatal error: Call to a member function get() on null in /var/www/fog/lib/fog/fogpage.class.php on line 390, referer: http://10.1.0.24/fog/management/index.php?node=group&sub=deploy&id=3&type=8
@Tom-Elliott alright, cool.
Sorry for my ignorance, but I seem to remember Snapins before needing to be wrapped with SFXMaker and such for all things. Is that still the case, or can I now just upload a script and be done with it?
UPDATE
Never mind, uploaded a bat file and it ran flawlessly. Thanks for the help, now my thin imaging with PDQ to throw apps on afterwards is working fantastically across all sites!
@Tom-Elliott Completely agree, it’s a Win10 issue, not Fog. I’m hoping to use a snapin or the like as a bandaid until I figure out why it’s doing it.
I don’t need it to run before hostname change/domain join, actually need it after. Since I haven’t used snapins since, oh… .28, if I remember right I can just build one that does the gpupdate, assign it to the group, and they should grab them as soon as they check in next, right?
So I’m finalizing my Window 10 clients to roll out this summer, and running into a weird issue.
My image rolls out fine using Fog Trunk, joins the domain, and is all good. However, it appears that it’s not applying a group policy update when joining or something like that, which is causing issues as it’s not grabbing my firewall settings . Without the firewall settings, my PDQ Deploy box can’t send out applications.
If I log in as a user, any user, and run a gpupdate manually or let it do it’s wait, we’re good to go.
Is there a way to like make a Snapin that’ll force a gpupdate after it joins the domain? Or a better solution?
Note, this is only happening with Win10. My Win7 boxes using the same server pull all these settings fine.
That’s also in the works. Again, it’s for the stop gap in between time. The clients are laptops that students roam with, and due to them being on wireless with cached logins, group policy takes longer than I’d like to roll out.
I’ll throw it into PDQ deploy though, that should handle it pretty fast. Thanks for your help and input!
Oh, I agree with all your points, and I fully plan on rolling out the new client with all new images.
My concern is for the imaged machines that are already out in the wild, with the old client installed. Since I’d be removing my 1.2.x install and replacing it with trunk, I wanted to make sure that the old client would still be able to ‘phone home’ as such and perform it’s duties with the newer server.
All of my new images have the new client included. This is more of a stop gap for the ones already out there. Wanted to make sure I don’t leave them in trouble until I get a chance to image them again, which will be over the summer.
@Wayne-Workman said:
As @jbob said, yes it’ll work.
Would I recommend it? Nope.
Can you elaborate on why? My primary usage for the client at the moment is domain join after image and client rename, no snapins or anything. I’d just like to get this new version rolled out before our major summer imaging starts.
I’ve just rolled out a new trunk install of Fog. However, I had used standard 1.2.0 to image out 900+ machines earlier this year. As such, they have the old client.
Will the old client function with the trunk version of Fog? I know I’ll not get some of the new features, but a reimage for each machine is not feasible at this time. I plan to push the new client out, to make sure they all get it, but in the middle time, I don’t want to screw anything up.
TLDR:
Old fog client, new fog server, same IP, will it work until I can update the client on each machine?
@Tom-Elliott Works for me! I just remember when 14.04 came out, 1.2 had some issues installing on it, so I kept with 12.04. I just looked at my server that did work, and it is 14.04. Time to try that out!
@Wayne-Workman Yes, following those exactly for both Wget and Git, since I attempted it twice.
@Uncle-Frank , I’l take a look in the logs when I have time to snapshot my current install and test it again. Should be tomm at the earliest.
It’s odd. Everything seems to go fine, and I did the same exact thing on a fog server in another site that was running on KVM with no issues. It just doesn’t like this one for some reason.
I think I’m going nuts over here. Attempting to install the trunk version on a Ubuntu 12.04 box hosted in ESXI.
I’ve currently got a 1.2.0 up and running, and first tried that as a base. Everything goes fine until I get to the part about updating the MySQL database. When I browse to http://fog-ip/fog/management I simply get a white screen. The faveico is there, so it’s at least loading, but not providing content.
I then made an entirely new VM, Ubuntu 12.04, and pulled the trunk from GIT and it did the same exact thing.
I feel like I’m taking crazy pills. Does it require 14.04 or something now? I just want me some sweet sweet speed increase in our deployments!
Sadly, tried that, no luck. Since it’s a powershell script, it really needs the domain to be working well, which means I cant have it on RunOnce registry unless I could somehow get that key added after the domainjoin task.
Startupscript via local group policy is an option I’ll be trying today. I’d just need to set the last step of the task to delete the script…
I’m honestly wondering how BigMan99211 got it working up there, and was hoping he’d chime in!