Infinite booting loop
-
thanks for that. and yup I got what you meant. I thought it might be a disparity from 32 bit to 64. Are your 390s 32 bit by chance?
My server is 32 bit and the 990s are 64 bit. Though, trying the chainboot fix only caused my computer to not restart, just reloop the fog screen itself over and over. So, I’m not sure what’s going on. Have you tried a 64 bit client yet?
-
[quote=“bardicverse, post: 4351, member: 1314”]thanks for that. and yup I got what you meant. I thought it might be a disparity from 32 bit to 64. Are your 390s 32 bit by chance?
My server is 32 bit and the 990s are 64 bit. Though, trying the chainboot fix only caused my computer to not restart, just reloop the fog screen itself over and over. So, I’m not sure what’s going on. Have you tried a 64 bit client yet?[/quote]
I have only tried 64bit on both the server and the client. I cannot see any reason why the client OS would matter. I think it has more to do with the new Dells having some BIOS closer to UEFI.
I havent had a chance to try fixing it again, as I just disabled the network boot and just use F12 when I need to image on them. My other projects have taken priority.
-
makes sense. Ah well, I’ll be poking and prodding on it over the summer once I got these other labs reimaged. Will post back if I come up with a solution.
-
Just to further prove my 64bit server theory, I had to fix a F10 32bit server to get a Dell Latitude 5520 laptop to stop looping and it worked great.
-
For those of you experiencing menu looping, please post your /tftpboot/pxelinux.cfg/default file, and perhaps the steps you took in setting up the chainloading. Anything that helps us pin down what’s causing this issue is important.
One thing to consider: the chainloading will return you to the menu if the device you’re booting to does not have a boot partition (though it usually displays an error message for a few seconds before reloading the menu). I’m not sure how it would handle being pointed at a hardware address that does not exist; it is possible that your systems are setup in such a way that your drive is listed as hd1 instead of hd0, which [I]might [/I]be contributing to your problem.
I don’t know why there would be an issue between 32bit and 64bit, though I won’t go so far as to say it’s impossible. I’ve been chainloading from both 32bit and 64bit to both 32bit and 64 bit, and I’ve never encountered an issue.
-
actually, that would probably be the case. Dell hard drives come partitioned with a recovery partition, or disk 0, and the next partition is the main body partition, which would probably be disk 1. I’ll have to test that theory out later. currently uploading 2 new images to the server.
I think in future practice, I’m going to wipe the dell recovery partition outright, so I can use the resizable image option. But since we’re already underway with the summer workload, it’ll have to wait.
-
[quote=“bardicverse, post: 4361, member: 1314”]actually, that would probably be the case. Dell hard drives come partitioned with a recovery partition, or disk 0, and the next partition is the main body partition, which would probably be disk 1. I’ll have to test that theory out later. currently uploading 2 new images to the server.
I think in future practice, I’m going to wipe the dell recovery partition outright, so I can use the resizable image option. But since we’re already underway with the summer workload, it’ll have to wait.[/quote]
I think I can answer that and say no deleting the recovery/OEM junk partition will not work, as the first thing I do when setting up a new pc from any OEM is put in a Windows disk and remove all that.
I think BryceZ probably means that to the BIOS it is being listed as hd1 vs hd0, as in its possibly connected to SATA port 1 vs port 0. I think it has to be on the server side, as many other people have gotten it to work.
Are you using 4.04 of the syslinux? I tried 4.05 and that didnt work at all.
-
not sure what version of syslinux. To be honest, I can always just use the one time boot menu when i need to reimage, etc. Right now I’m just trying to roll out these images asap.
-
I have just set up FOG at my place of work. It has been working fine for all of our computers so far (apart from those running in hardware raid)
We use mainly Dell, and so far it works fine on both Precision T1500 and T3500, STUDIO laptops and a few different Optiplex.However on out XPS laptops, I get the same cycle spoken about in this post.
It reaches the Gui boot menu, counts down from 3 seconds, and then quits its.
But instead of booting the hdd, it reboots and tries all over again.From this post I tried to make this change to /tftpboot/pxelinux.cfg/default
LABEL fog.local
[B]kernel chain.c32 [/B]
[B]append hd0 [/B]
MENU DEFAULT
MENU LABEL Boot from hard disk
TEXT HELP
Boot from the local hard drive.
If you are unsure, select this option.
ENDTEXTHowever that put all of my machines in a cycle inside the Gui instead, continually counting down from 3.
I also tried hd1 and other abbreviations (hd0,0 and so), to no avail.
Also, if I escape out of the Gui, and try to do a hd0 or hd1, it says it cant be found in the kernel.
Could it have another name?
I am running Windows 7 Ultimate on all the machines.
For now I have changed it back to default, so it can be used on the other machines while I figure this out.
Sincerely
Jon -
Did you add/replace the files listed in the [URL=‘http://www.fogproject.org/wiki/index.php?title=FIX:_Chainloading_alternate_SYSLINUX_to_force_boot_from_first_hard_drive’]chainloading[/URL] article on the wiki?
-
[quote=“BryceZ, post: 5243, member: 2”]Did you add/replace the files listed in the [URL=‘http://www.fogproject.org/wiki/index.php?title=FIX:_Chainloading_alternate_SYSLINUX_to_force_boot_from_first_hard_drive’]chainloading[/URL] article on the wiki?[/quote]
I did not, and that was my downfall ^^After switching out the files, it was an immediate success!
Thanks for the help.
-Jon
