So far, everything looks good. I wanted to make sure you were using the IP address of the fog server and the right boot file name.
I understand about Orange (silly name change in my opinion), we used them about 10 years ago for WAN management.
Using the fog dhcp server is not mandatory and should be a second choice unless you don’t have a functioning dhcp environment.
The error message is for sure saying that it can’t reach either the fog server or the download file.
Do you mean you are putting both linux and windows on the same hard drive?
If not then you can check the system type and then make your partition selection from that. If you do have floating partitions, I think you better work on a different plan because this will be trouble to manage.
Just for reference you can use the variable $osid to identify the OS that will be deployed to the target computer.
@arnaudrigole said:
I’m sorry for my poor English, i’m french.
Well you are french, that explains a lot <just kidding> Your english is excellent.
Welcome to the fog project.
Can you tell me exactly what you set dhcp options 66 and 67 to?
Secondly, is there any reason you do not just make those options (66 and 67) consistent for all systems and not do mac specific settings?
Can you tell me the error you see on the client computer. I might expect to see an error like “PXE-Exxx” where xxx is some number or letter combination.
@Tom-Elliott (just trying to create a procedure around this)
So just for clarity here, you are recommending the OP to:
A also assume
4) Update the kernels and inits for the newest ones supported under FOG 1.2.0 stable
While it would take a little time to setup. I still think seeing if the trunk version of FOG solves your problem. This would not be a second FOG server just a test system to ensure that the new inits work on the surface pro 4.
The idea is if we have one set of inits that fail and another that works, then there is a path to see where things fall down. If the new inits work, but there is a technical issue with the older inits where they can’t be fixed then the answer will be to wait until fog 1.3.0 is release before you image these systems.
I guess a question for the OP is, are you running the latest kernel and inits for the 1.2.0 build?
I guess I have to be captain obvious here (well may be not so much).
What would you loose if you spun up a new instance of the FOG server using the current trunk image?
Would it be just the registrations, the images, what would be the real impact of starting over?
The reason why I asked is: Will it take more time to upgrade from 0.30 to 1.20 and work out all of the kinks or just recreate the new environment?
Unless I’m off here, you can not deploy images created with 0.30 with the trunk build of fog 1.2.0. The image format has changed. Your best bet would be to deploy an image with fog 0.30 and then right away recapture it with the trunk build of 1.2.0. That way you get the image in the correct format. If its the registrations there may be a way to export the hosts and then re-import them into fog. But again will it take less time to just reenter them into the latest release of FOG.
@Psycholiquid Great, when you have a working system, if you wouldn’t mind document what was done so we can create a wiki page.
You are pioneering a new process that will help others too. You are just the first to get there with the need and the skills to solve it.
@Psycholiquid I’m out of the office today, so I can’t give feedback on the one and only usb ethernet adapter I have. I will do that tomorrow.
But my google-fu found this post which talks about the XPS 13 and usb booting. No definitive answer here either other that to use an older usb ethernet adapter. http://support.plugable.com/plugable/topics/can_i_use_a_usb_network_adapter_for_boot_time_pxe_scenarios
This post does confirm some of my suspicions about why this isn’t working.
[edit] found reference to StarTech USB21000S2 working still trying to confirm [edit]
[edit2] I’m finding more references to the above startech usb working at least in bios mode. The other thing I found interesting is that usb2 ports (black) work more successfully than usb3 ports (blue). [edit2]
[edit3] I did find this article that gives pretty good background inforamtion. http://www.johnwillis.com/2014/03/pxe-booting-using-usb-to-ethernet-dongle.html I do have a usb 2 adapter in my office, when I’m back tomorrow I will confirm for sure if it works with uefi mode on a dell laptop [edit3]
really the only difference between the ipxe kernel from the tutorial and the official one from the fog server is where it gets the next server setting. If you look at the other uefi boot tutorial (easy way). In that one I just take the fog uefi boot kernel, move it to a flash drive and boot it. In that setup you have to key in the ip address of the fog server since it is not being provided by dhcp. There was a request to not have to key in the ip address of the fog server every time, that is what spurred me on to create the harder way.
I’m suspecting that since that nic is not showing up in the bios that it is not uefi compatible and uefi bootable.
It would be interesting to know if you inserted that usb ethernet adapter into a desktop computer that is in uefi mode and see if it shows up. Right now (in my mind) its not clear if the issue is the ipxe kernel, network adapter, or the xps 12 that is at fault. So if it was me I’d start changing one item at a time until you get to a working model.
I would first eliminate the xps 12. Take the usb ethernet adapter and the usb flash drive with the ipxe kernel from the tutorial, or even the one from fog and try to get the ipxe kernel to boot in uefi mode on another computer (like a desktop). This will test out uefi booting from that usb ethernet adapter. If that works then we can start focusing on the xps 12.
@Tom-Elliott OK great. I just wanted to give the usb booted device just enough to get into the official FOG ipxe.efi kernel. That way if you guys developed new or additional tests this external boot would not have to stay in lock step with your updates.
BUT, with that said, if there is an easier/better/preferred way to do this, just let me know and I’ll update this document.
@Psycholiquid said:
What I am trying to do is boot from USB pxe because the laptop has no NIC or UEFI is not cooperating like it should.and Wireless wont boot from network. So basically trying to make a live USB drive so I can boot to FOG on machine where there is no nic or the docking station wont show up.
While this is the intended purpose of the usb boot, dealing with wireless nics is a bit of a pain since the number of models is staggering. I don’t think I included the wireless management code in my how to script. The preference would be to use a usb ethernet nic.
The issue I see is some how you need to tell the client what SSID to connect to and any security keys required to connect. Unless you create a fully open wireless network just for imaging.
@Tom-Elliott said:
I guess what I’m trying to say, if you’re using the usb, you’re already IN ipxe in some way, why would you want to redirect to another ipxe file. Why not make the config the same AS the default.ipxe file, or just load the file itself.
The intent (right or wrong) was to not alter the FOG workflow. My intentions were to get the client booted well enough to then load the official ipxe.efi kernel with all of its goodness. There are many more network checks being done with its boot script than is being done with the USB boot. Was this the right idea, I guess time says… maybe?
Ok I won’t stretch this topic out since the trunk upgrade is underway. But I find it intriguing that it went the other direction and set the task to UTC time instead of double dipping on the CST offset the other direction.
Please understand that upgrading to the latest trunk may not solve the problem, but we can then engage the devs since this is a current issue with the latest build.
@anthonyglamis Interesting off by 5 hours. While I think upgrading to the latest trunk is a good idea, out of curiosity if you use the linux OS as a standard, which way is FOG off? With out putting too much thought into it CST is (UTC – 5) hours. So if fog is using the system time thinking it is UTC and it subtracts 5 hours from the system time which is already 5 hours from utc I could see how things could get mucked up.
If / when you upgrade be sure to remove the tz setting in the php.ini file, because that value is not set by default.
@anthonyglamis Thank you it helps me visualize how you system is setup.
I’m not saying that the php.ini setting will fix the problem. But, I remember this was a solution for some FOSS software I used in the past. The 1.3.0 may have been a fix to address this issue.
On the MAC issue. This is good the registered mac on the device IS the mac address when PXE booted and is nic0. Once you get the tz setting updated it will be interesting to know when you schedule a task does it get entered for the right time. We may have to dig into the database, but I might like a little feedback from the @Developers before we go that far. There may be more value with you upgrading to the latest trunk version (pre 1.3.0) if you can tolerate a little instability as we try to get all of the bugs identified and ironed out.
@anthonyglamis I believe this is the right location /etc/php5/apache2/php.ini (sorry I live in the rhel camp so I have to guess a bit for the debian folks)
The answer is you need the double quotes because this is a string literal. Also I don’t think you confirmed the output of the cat command. Can you do this? (yes, I’m a type “A” person [including double quotes])
Timezone: Nuts, I’ve been running the trunk build for so long I forgot about not everything being in 1.2.0.
just for clarity can you run this command from the linux console. This should be accurate for the ubuntu systems.
cat /etc/timezone
While your system time is correct, I want to make sure the system timezone is correct. I would expect the results to be something like “America/Chicago”.
In the /etc/php.ini there is a timezone property. Please set that to the proper timezone that is listed in the OS. Once you do that restart the apache service so that php will pick up the proper timezone.
On the mac / task issue. Can you confirm which mac address is the ethernet and wireless? You may have to update the registration in FOG to ensure that the mac address used is for the pxe boot adapter.
@anthonyglamis Ok, continuing with the time issue. Since linux knows the proper time, then it is probably a php or FOG offset that is coming into play. Can you inspect the value of FOG_TZ_INFO at Settings->Fog Settings->General make sure that has the right timezone is set. If that setting is correct then I want to try adjusting the php.ini setting. But lets start with easy first.