Rollback iPXE files
-
Maybe I should rephrase my question.
I’m not looking for FOG 1.0.0, I’m looking for the iPXE files. At least that is one thing I’m considering in tracking down the source of the problem.
The problem being what I’ve seen other discuss, involving machines not rebooting properly after a multicast.
Unicast in all its flavours works beautifully. Multicast used to work, but along the way has become an issue. The actual mechanic leading to the multicast, and the data transfer to clients works wonderfully, it’s at the first reboot after PartImage releases the system that everything goes pear shaped.
And as I type this I wonder, is it PartImage’s fault in dealing with a multicast? hmm
Anyways the initial problem screen stops at:
[CODE]
/default.ipxe… ok
[URL]http://x.x.x.x/fog/service/ipxe/boot.php[/URL]… ok
booting from SAN device 0x80[/CODE]Subsequent reboots result in the same wordage.
Attempting any other FOG based action on that afflicted system results in:
[CODE]-
Mounting File System … Done
-
Checking Mounted File System … Done
-
Starting Image Push
-
Looking for Hard Disks …
An error has been detected!
Failed to initialize disk
Computer will reboot in 1 minute
[/CODE]
FOG won’t touch this machine now. The drive must be wiped (typically with DBAN) or diskpart or whatever, because FOG can’t even run its own disk wipe. That last error persists.
Changing the exit type makes no difference under the iPXE settings.
I’ll admit I haven’t been able to fully test the multicast feature in a while, but it did work at one point. I don’t recall the version (bzImage or iPXE) but it did. And that was my first thought. That iPXE and its file were the culprit so I wanted to be able to replace with older versions.
FOG has the built in feature for installing the kernel of your choice. I’m assuming that is for bzImage only and not iPXE. Or am I wrong? I have noticed that the iPXE version does change often, even if the bzImage does not.
I rambled …
To solve this problem I’m considering:
- iPXE
- bzImage
- PartImage <— leaning towards this guy.
- Use of the Hidden menu option with special key to enter
… as possible causes.
I reiterate, unicast works flawlessly. This is only a multicast issue.
Disconnecting the network cable or interrupting the PXE DHCP call, results in either a disk read error or no further activity.
According to GParted… All that exists on the HDD is a 54.91MiB Used, 1.95 GiB Unused and 147.05 GiB Unallocated. A neat trick. The original Windows 7 image had a single 70 GiB partition (no System Reserved partition at the head) with about 55GB of data.
When I have more information I will move this into the Bug or Problems forum.
-
-
iPXE is NOT your problem.
i also doubt that partImage is your problem, PartImage isn’t used unless you’re using images from versions fog prior to version 1.0.0
what version of fog are you running? -
Just to back up Junkhacker here are the instructions to upgrade from 0.32 to 1.20:
[LIST]
[][url]http://fogproject.org/wiki/index.php/Upgrade_to_1.x.x[/url]
[]There you will notice [url]http://fogproject.org/wiki/index.php/Upgrade_to_1.x.x#Old_Images[/url]. Describing that partClone is the new method. partImage is no longer used since 0.33b. Due to this change your images will need to be set to “legacy”
[/LIST]
However, you state that unicast works and multicast does not. May I suggest to check the troubleshooting wiki:
[LIST]
[*][url]http://fogproject.org/wiki/index.php/Multicasting[/url]
[/LIST] -
Multicasting does transfer the image. Data transmission and HDD writing does occur.
At first restart, before even attempting to boot from the HDD, I’ve booted to GParted and that’s where I see the imaginary partition table, instead of what should be there.
The images tested are indeed set to PartImage. I will test with a PartClone image shortly.
This server is running SVN2876 with iPXE 1.0.0+ (d38b) . It has never been 0.32 or 1.2.0, it was originally installed as SVN 2331 I believe, and updated maybe four times to land now at SVN2876.
Looking at the trunk.tar … I see that the ipxe files come with. ( fog_trunk\packages\tftp\ ).
You are forcing auto-download of the latest bzImage files when a new server is installed, but you do offer the means to download any bzImage kernel the user later desires from the FOG menus. Would you consider building in the ability to allow to change the iPXE files post-install as well? They too have versions.
-
[quote=“sudburr, post: 41196, member: 4706”]Would you consider building in the ability to allow to change the iPXE files post-install as well? They too have versions.[/quote]
no. they have versions, but if the latest version doesn’t work for you, an older version almost certainly won’t.
-
Alrighty then. My first test with Multicasting a PartClone image succeeded. Any PartImage image continues to fail and fubar the HDD.
Testing continues …
-
Um hate to be the “Negative Nancy” but in [url]http://fogproject.org/wiki/index.php/Upgrade_to_1.x.x#Old_Images[/url] you will see:
[LIST]
[*][B]Best practices:[/B] You should download these to your hardware and re-upload BEFORE deploying on to multiple machines. If [B]Image Type[/B] is set to [B]partImage[/B] on next upload it will automatically change [B]Image Type[/B] to [B]partClone[/B]. NO need to go back and change that setting. Once all your images are re-uploaded you can then go and disable [B]FOG_FORMAT_FLAG_IN_GUI[/B] in [B]Fog Settings[/B]
[/LIST]
[I][U][FONT=sans-serif][COLOR=#000000][B]There is a reason that is stated.[/B][/COLOR][/FONT][/U][/I] -
These images were uploaded under Partimage and are PartImage images as created via an older FOG version (probably 0.32). They unicast as PartImage. The FLAG has been set since it was first available in 1.0.0 or whatever.
The PartClone image was created 5 months ago, with whatever version of PartClone was in FOG at that time.
By quoting from that article, if you are categorically saying the PartImage images cannot be multicast with the current FOG, then could you please update that article to say that in no-uncertain terms?
-
While I’ve tried my best, and believe me when I say I really have, to maintain backwards compatibility, I have never been able to test all possible scenarios. That said is it more probable you’re running into a sector problem than an issue with partimage and multicast. Just saying.
-
In about a month’s time or so this whole conversation will be moot for me as I’ll be replacing the images with updated recipes captured via PartClone.
If there is a bug and a solution I’m trying to find it not for my sake. I’ve already instructed our techs to use QuickImage and unicast in the meantime.
If the PartImage-captured PartImage-deployed image has a sector problem when multicast, then would it not also be corrupt when it is unicast?
Aggressively zero’ing the drives prior to PartImage Multicast results in the same.
Interestingly, interrupting a PartImage-multicast session will corrupt the drive similarly to the point where FOG will refuse to work with that drive until it is re-zero’d.
