PXE Boot freezing at the BG.png?
-
First off, I just have to say that i have set up FOG basically having no super Linux background until recently when i decided to go against my colleagues and tell Ghost to shove it. My other laptops and desktops deploy just fine. However this Dell latitude 7275 2-in1 laptop. It uses the the Realtek 8153 USB-C adapter. I have done my searching and realized that the Realtek 8153 has worked with the undionly.kkpxe and that is what I’m using.
I have turned off my UEFI boot for the time being as I don’t feel like dealing with that side since some of my other machines do not use UEFI. I have tried just about every pxe in my the dang /TFTPboot folder and still nothing. The funny thing is if i restart and run it again sometimes it will go up in percentage and then freeze again and the more i restart the higher it gets until i just wont go anymore.
I am using trunk 7721 w/ kernel 4.5.3
I am sure that I am leaving something out, but i don’t know. I have been at this issue for about 4 days now. Any input appreciated! -
@MrSmith912 said:
Any input appreciated!
Same we ask from you. Please post a picture of the hang/freeze!
-
@MrSmith912 I have seen this before, with same type of network adapter. Is the target host and server on the same broadcast domain? Broadcast domain is a network term, if you don’t immediately know what it is, Google it.
-
Hmmm
Just restating what I read. Realtek nic and transfer hangs when the link starts to load, other systems deploy OK. (building network switches may be cisco catalyst series ??)
The first thing that jumps to mind is to place a unmanaged dumb switch between this target computer and your business network. Lets see how that works.
-
@george1421 you sir are correct, they are catalyst. I will try the dumb switch when i get back to work in the morning.
-
-
@Wayne-Workman yes they are if I remember correctly. All on same vlan as well
-
@MrSmith912 said in PXE Boot freezing at the BG.png?:
@george1421 you sir are correct, they are catalyst. I will try the dumb switch when i get back to work in the morning.
We are seeing this more often now. Not sure why either. But it seems that the newer realtek nics are having a problem with (we are trying to make a solid connection here):
- They are not negotiating the link speed properly
- They are having a compatibility issue with the green ethernet settings 802.3az and the more advanced switches (i.e. catalyst)
- Some other initialization handshaking that goes on between the nic and the catalyst switch.
We found that putting an unmanaged (dumb) switch between the catalyst and realtek nic breaks this bad behavior. Again we don’t have a solid picture why this has started in the last year or so. It could be the nic or the newer FOS linux 4.x kernels taking advantage of these newer negotiation protocols. The FOG developers simply don’t have enough info yet.
-
@george1421 Couldn’t have put it any better! Thanks a lot!
-
I simply wonder if just changing the iPXE boot file would fix this? What file are you trying to boot from now? If it’s BIOS booting I’m guessing you’re currently using undionly.kpxe, if so can you try the undionly.kkpxe?
I’ve seen these hangs occur on different iPXE files, and changing the one to use seems to help keep it from getting stuck.
-
@Tom-Elliott was using the undionly.kkpxe at the time this happened.
-
Ok so the ones on the other side of the dumb switch get to the FOG screen, however now they hang at the loading of the bz.image
all stuck at 0% -
@MrSmith912 try other files. For example try using ipxe.pxe rather than undionly.kkpxe.
-
@MrSmith912 said in PXE Boot freezing at the BG.png?:
Ok so the ones on the other side of the dumb switch get to the FOG screen, however now they hang at the loading of the bz.image
all stuck at 0%OK then it just pushed the issue down to the next heavy traffic load. The I would test the driver that Tom mentioned. The ipxe.pxe contains all of the known linux network drivers for all known cards. The undionly drivers rely on the card’s built in driver components (which have been known to be flaky at times too).
Just be aware this pxe booting / configuration can be a bit of a black art at times to get just the right configuration to make all hardware happy. Using the ipxe.pxe image will not impact most pxe booting, so if it works for these new computes it should work with the older ones too, its just the undionly driver is widely supported.
-
@george1421 @Tom-Elliott I tried the IPXE.pxe file and the boot returns a “DHCP failed… rebooting in 12 sec”
i have been trying to understand how the guy got his to work in this thread as well.
https://forums.fogproject.org/topic/2620/realtek-8153-usb-network-adapter/28Also for shiz and giggles i tried the UEFI boot Even if i have to use it for the time being to get these 25 “2-in-1” done and then go back to the drawing board with one of them and test the bios boot. I used both snponly.efi and snp.efi they both worked. I got to FOG and told it to register the host and it returned the following.
UPDATE*** Changed the bootfile to IPXE.efi and it registered. Going to try to upload an image and I will let you all know what happens.
I have also been reading the thread/how to on the coexistence of uefi and bios booting. I am one of those people who has to deal with a 2008 server soo i will play around with that at a later time for you guys and see what happens. As of right now I would still like to get the BIOS boot files to work with these machines and will continue testing one of the laptops with pxe files, the others however, I am just going to uefi and switch the bootfile back when done
-
@MrSmith912 OK so the ipxe.efi with uefi firmware booted? I would say great but the ipxe.pxe should have the same drivers as the ipxe.efi. But it sounds like the uefi firmware is a bit better supported than bios.
As for the bios and uefi coexistence you are better off to upgrade to 2012 or setup a subnet for just uefi systems so you can create a different dhcp scope for these two boot environment.
crud I just remembered. Since have only a few of these, just use a dhcp reservation that way you can defined which devices need the efi boot file.
-
@george1421 I will take a look at that on monday when i get back to work. HALF DAY fridays woot!
Yeah i honestly think that with the the coming up refreshes i might be able to get away with all uefi booting seeing as how all of the new machines will be uefi enabled. hell it might be for the better. I will still test the BIOS boot on the UEFI devices to see and report back so that other people can see what has been done and if it eventually worked
-
@MrSmith912 Great to hear that you seem to make it work step by step!
@george1421 said:
The ipxe.pxe contains all of the known linux network drivers for all known cards.
AFAIK this is not perfectly true and might confuse people. iPXE and the linux kernel are two different and mostly unrelated pieces of software. They might have bits and pieces of the driver code in common but in general they don’t share any drivers or code. The iPXE team coded a fair amount of native network drivers and those are included in the ipxe.pxe binary. But those have pretty much nothing to do with the linux network drivers. I know this detail is not relevant for most of the users. Just wanted to get that out to hopefully prevent from some confusion.
Web GUI issue? Please check apache error (debian/ubuntu: /var/log/apache2/error.log, centos/fedora/rhel: /var/log/httpd/error_log) and php-fpm log (/var/log/php*-fpm.log)
Please support FOG if you like it: https://wiki.fogproject.org/wiki/index.php/Support_FOG
-
@Sebastian-Roth I stand corrected after a long day of typing.
I really do know the difference between iPXE kernels and linux kernels even though my fingers lie once and a while.
