Latest FOG 0.33b
-
Just so all are informed. I was able to get an EFI Windows 8 system to upload an image, which was to be expected. All that worked perfectly. I was also able to deploy the Windows 8, and later boot it back up, from EFI (after disabling Secure boot). Sounds like success right? Well, I was very excited and all initially. However, I have yet to replicate the results. I can only do the deploy once, but nothing after that. It appears (just in case anyone else wanted to give a go as my mind is currently fried.) that the 1st partition (300MB ntfs) overwrites the GPT data structures and damages it. It can’t find the 2nd, 3rd, or 4th partitions (on a base install MPS image).
I think I can fix it but will have to wait until tomorrow. I suspect that Windows 8 is using a Hybrid-Protective MBR style GPT system that I need to actually, on upload, create an MBR backup as well as a GPT Backup. On deploy, write the GPT Backup, then the MBR. It’s just a theory, so no guarantees yet. Just wanted to give a status update.
-
[quote=“wolfemi, post: 23540, member: 5740”]I was doing some more testing on snapins this AM and noticed a few things.
I am still having an issue with group deploy of all snapins. It states Snapins Are already deployed to this host. If I deploy the snapin another way successfully then try it again it creates the task.[/quote]
I think this is sort of expected. The checks on the snapin/task generation basically check if a job is already created with the particular task (or job) and will not “re-deploy” until those previous snapins complete. Why you’re able to generate successfully, and then create the task is a little odd. Do you mean they deploy and complete, or you just create the task, then go to group and create?
[quote=“wolfemi, post: 23540, member: 5740”]
I tried to do a quick deploy of snapins to a group and it didn’t create the snapin task. The single snapin didn’t have an option to select which one.[/quote]
I can quick deploy the snapins to a group, but I don’t remember if I added the “checking” needed to send the snapins through this method. It’s not high priority as I finally got a Windows 8 system to play with. This is a relatively easy thing to “fix”/implement, just didn’t get to it yet.
[quote=“wolfemi, post: 23540, member: 5740”]
A quick deploy of all snapins for a host worked fine, but the quick deploy of single snapin did all snapins.
[/quote] See one above. I never implemented it, yet, on the task management page as I basically recreated the deploy scripts.
[quote=“wolfemi, post: 23540, member: 5740”]
I tried group single deploy and it had the drop down which successfully worked.[/quote] Expected!
[quote=“wolfemi, post: 23540, member: 5740”]
I cancelled single deploy and all deploy active task for both host and group deploy which also removed the snapin task. It wasn’t working before. Also was able to cancel a single snapin from a deploy all snapins with out issue.[/quote]
Expected.Thank you!
-
[quote=“wolfemi, post: 23540, member: 5740”]I was doing some more testing on snapins this AM and noticed a few things.
I am still having an issue with group deploy of all snapins. It states Snapins Are already deployed to this host. If I deploy the snapin another way successfully then try it again it creates the task.[/quote]
I think this is sort of expected. The checks on the snapin/task generation basically check if a job is already created with the particular task (or job) and will not “re-deploy” until those previous snapins complete. Why you’re able to generate successfully, and then create the task is a little odd. Do you mean they deploy and complete, or you just create the task, then go to group and create?
[quote=“wolfemi, post: 23540, member: 5740”]
I tried to do a quick deploy of snapins to a group and it didn’t create the snapin task. The single snapin didn’t have an option to select which one.[/quote]
I can quick deploy the snapins to a group, but I don’t remember if I added the “checking” needed to send the snapins through this method. It’s not high priority as I finally got a Windows 8 system to play with. This is a relatively easy thing to “fix”/implement, just didn’t get to it yet.
[quote=“wolfemi, post: 23540, member: 5740”]
A quick deploy of all snapins for a host worked fine, but the quick deploy of single snapin did all snapins.
[/quote] See one above. I never implemented it, yet, on the task management page as I basically recreated the deploy scripts.
[quote=“wolfemi, post: 23540, member: 5740”]
I tried group single deploy and it had the drop down which successfully worked.[/quote] Expected!
[quote=“wolfemi, post: 23540, member: 5740”]
I cancelled single deploy and all deploy active task for both host and group deploy which also removed the snapin task. It wasn’t working before. Also was able to cancel a single snapin from a deploy all snapins with out issue.[/quote]
Expected.Thank you!
-
[quote=“wolfemi, post: 23540, member: 5740”]I was doing some more testing on snapins this AM and noticed a few things.
I am still having an issue with group deploy of all snapins. It states Snapins Are already deployed to this host. If I deploy the snapin another way successfully then try it again it creates the task.[/quote]
I think this is sort of expected. The checks on the snapin/task generation basically check if a job is already created with the particular task (or job) and will not “re-deploy” until those previous snapins complete. Why you’re able to generate successfully, and then create the task is a little odd. Do you mean they deploy and complete, or you just create the task, then go to group and create?
[quote=“wolfemi, post: 23540, member: 5740”]
I tried to do a quick deploy of snapins to a group and it didn’t create the snapin task. The single snapin didn’t have an option to select which one.[/quote]
I can quick deploy the snapins to a group, but I don’t remember if I added the “checking” needed to send the snapins through this method. It’s not high priority as I finally got a Windows 8 system to play with. This is a relatively easy thing to “fix”/implement, just didn’t get to it yet.
[quote=“wolfemi, post: 23540, member: 5740”]
A quick deploy of all snapins for a host worked fine, but the quick deploy of single snapin did all snapins.
[/quote] See one above. I never implemented it, yet, on the task management page as I basically recreated the deploy scripts.
[quote=“wolfemi, post: 23540, member: 5740”]
I tried group single deploy and it had the drop down which successfully worked.[/quote] Expected!
[quote=“wolfemi, post: 23540, member: 5740”]
I cancelled single deploy and all deploy active task for both host and group deploy which also removed the snapin task. It wasn’t working before. Also was able to cancel a single snapin from a deploy all snapins with out issue.[/quote]
Expected.Thank you!
-
r1258 and 1259 released.
1258 adds fixparts to init.gz for testing with Windows 8 issues I saw earlier today. Add’s advanced options back to PXE Configuration part. Please bare in mind that you will have to use ipxe formatted code. (e.g. double quotes and \n at the end of the line.)
1259 just reinforces that the new init.gz gets distributed.
-
r1260 released.
Actually saves the advanced data.
-
r1261 released.
Removes obsolete imgargs command. Adds reporting of whether the host is registered or not as a gap in the menu.
-
r1262 released.
Fixes Windows 8 and below imaging issues. Yes this includes UEFI/GPT disks. You will need to disable secure boot on the drives but all seems to work. You may even (which I might fix myself) randomize the GUID of the disk to get booting to work as well. Hopefully this helps, and it’s very exciting.
-
[quote=“Tom Elliott, post: 23612, member: 7271”]r1262 released.
Fixes Windows 8 and below imaging issues. Yes this includes UEFI/GPT disks. You will need to disable secure boot on the drives but all seems to work. You may even (which I might fix myself) randomize the GUID of the disk to get booting to work as well. Hopefully this helps, and it’s very exciting.[/quote]
Nice job Tom!
Now I just wait to hear those dreaded words “Get Windows 8 installed on all the staff and student machines!”
-
Lol, still refining a little bit, you know trying to get the procedure (for mps/mpa types) at least right now.
-
What has changed since version 1256, that would stop “Full Host Registration…” from running? It worked fine 2 days ago, now it’s just bypassing and trying to boot to the hard drive…
-
Did you make edits to the boot.php file? If so, check that the line has a \n at the end.
-
No. I haven’t made any changes.
-
@BigMan99211 post a copy (remove your IP addresses if you care to) of the results you get from this url
(your-fog-server-address)/fog/service/ipxe/boot.php?mac=00:00:00:00:00:00 -
[CODE]#!ipxe
colour --rgb 0xFF6600 2
cpair --foreground 7 --background 2 2
console --picture http://10.20.0.225/fog/service/ipxe/bg.png
:MENU
menu
item fog.local Boot from hard disk
item fog.memtest Run Memtest86+
item fog.reg Quick Registration and Inventory
item fog.reginput Perform Full Host Registration and Inventory
item fog.sysinfo Client System Information
item fog.debug Debug Mode
choose --default fog.local --timeout 3000 target && goto ${target}
:fog.local
sanboot --no-describe --drive 0x80 || exit ||
goto MENU
:fog.memtest
kernel fog/memtest/memtest bootfile=http://10.20.0.225/fog/service/ipxe/boot.php?mac=${net0/mac} fastboot
boot ||
:fog.reg
kernel fog/kernel/bzImage bootfile=http://10.20.0.225/fog/service/ipxe/boot.php fastboot
imgfetch fog/images/init.gz
imgargs fog/kernel/bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns= keymap= web=10.20.0.225/fog/ loglevel=4 consoleblank=0 mode=autoreg
boot ||
goto MENU
:fog.reginput
kernel fog/kernel/bzImage bootfile=http://10.20.0.225/fog/service/ipxe/boot.php fastboot
imgfetch fog/images/init.gz
imgargs fog/kernel/bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns= keymap= web=10.20.0.225/fog/ loglevel=4 consoleblank=0 mode=manreg
boot ||
goto MENU
:fog.sysinfo
kernel fog/kernel/bzImage bootfile=http://10.20.0.225/fog/service/ipxe/boot.php fastboot
imgfetch fog/images/init.gz
imgargs fog/kernel/bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns= keymap= web=10.20.0.225/fog/ loglevel=4 consoleblank=0 mode=sysinfo
boot ||
goot MENU
:fog.debug
kernel fog/kernel/bzImage bootfile=http://10.20.0.225/fog/service/ipxe/boot.php fastboot
imgfetch fog/images/init.gz
imgargs fog/kernel/bzImage root=/dev/ram0 rw ramdisk_size=127000 ip=dhcp dns= keymap= web=10.20.0.225/fog/ loglevel=4 consoleblank=0 mode=onlydebug
boot ||
goto MENU
autoboot[/CODE] -
[quote=“BigMan99211, post: 23619, member: 21932”]What has changed since version 1256, that would stop “Full Host Registration…” from running? It worked fine 2 days ago, now it’s just bypassing and trying to boot to the hard drive…[/quote]
I have the same issue, except that any time I choose anything from the iPXE menu, it boots to HDD regardless. I thought it was just me, so I was going to try a fresh install. I didn’t customize any of the configs, etc other than adding the MYSQL passwords to the 2 required files
-
Change your FOG Configuration files
FOG Configuration (?) Icon
FOG Settings
Change the areas that have fog/memtest/memtest, fog/images/init.gz, fog/kernel/bzImage to say only memtest, init.gz, bzImage respectively. -
This post is deleted! -
[quote=“ArchFan, post: 23627, member: 19266”] … the 2 required files[/quote]
2?
-
I don’t know any more
I’ve since changed it to one required file.
/var/www/{fog,html/fog}/commons/config.php
The other config.php just tells the FOG<SERVICENAME> files to point to the main config.php file.
