Latest FOG 1.0.0
-
While I’m stoked about this, it is still, technically, in Release Candidate. But Here is the “New” thread.
I will keep this updated as much as I possibly can just as I did with the Latest 0.33b thread.
Thank you.
Let’s start things off:
r1565 released.
There is quite a jump from this morning. Many changes, fixes, corrections all around. Please test and, as always, let us know of any bugs your issues you stumble upon.
-
r1566 released.
Add’s the ability to search tasks by who created them.
Fixes Snapins so they work even if a task is not “active” for it.
-
Remember to get the latest changes using BTSync
[url]http://www.bittorrent.com/sync[/url]
Main Fog BTSync Read Only Secret
BAU3NUY3XTKVMHHEZO6C7OH55AN2PCGJV
Fog Kernels Read Only Secret
B7AGQ6JVIP4MF5LCRL3XURQBYC53UIS25
Changes are ‘almost instantly’ replicated to everyone running BTSync.
It also allows less stress on Tom’s bandwidth.
-
I wanted to get this link available. As this is now known as FOG 1.0.0, my tarball link has changed. fog_0.33b.tar.bz2 is no more and my website references have been updated, as well as the Upgrading WIKI article.
To download the tarball, if that’s what you want:
[url]https://mastacontrola.com/fog_1.0.0.tar.bz2[/url]To upgrade, go to:
[url]http://fogproject.org/wiki/index.php?title=Upgrade_to_1.0.0[/url]Hopefully this helps.
-
Tom, as promised in the previous thread, I am coming back with feedback about Win8.1.
Disclaimer: yesterday I was in the lab I have at work, while today I virtualized everything; however, the errors were the same.Possible bug: FOGMulticastManager still isn’t starting properly, I had to start it manually.
Win8.1 worked like a charm with “Multiple partition image - single disk”, after I started FOGMulticastManager manually.Now I will try to replace Windows 8.1 with Ubuntu 14.04. Will come back with updates.
Just out of my curiosity, what is “Other (99)” for ? How is it different from Windows 8 or Linux?This is quickly turning into my favourite open source project!
-
Already encountered the first problem…
Any hint please?[url=“/_imported_xf_attachments/0/704_Ubu_dep-2014-05-03-16-28-49.png?:”]Ubu_dep-2014-05-03-16-28-49.png[/url]
-
[quote=“Mr.Myagy, post: 26533, member: 23824”]Already encountered the first problem…
Any hint please?[/quote]
When you installed Ubuntu 14.04, did it install as EFI or MBR? Also, what’s the size of the d1.mbr for this particular image?I ask for size because it’s the “size” of the mbr file that determines if it’s an MBR or GPT type of MBR. From what I can tell, this is a multicast deploy with a linux OSID.
I don’t have an easy method to check if the mbr is GPT or mbr, so I’ve used file sizes to make this determination.
The steps that make an mbr, or gpt backup are:
On upload, it runs gdisk -l /dev/sda and searches for the gpt: present line. If it’s not present, it does a normal dd backup of the mbr, or in the case of linux, it copies all the data from 1 to the 63 sector at 512 bytes each sector. So the “filesize” is: 32256 bytes, but is still of MBR type. This was just a guess, but may be inaccurate for Ubuntu.My guess to the error you’re seeing is because of this. Maybe MBR Ubuntu 14.04 is actually larger so the deploy action is writing the d1.mbr as GPT structured rather than MBR?
-
[quote=“Tom Elliott, post: 26535, member: 7271”]When you installed Ubuntu 14.04, did it install as EFI or MBR? Also, what’s the size of the d1.mbr for this particular image?
I ask for size because it’s the “size” of the mbr file that determines if it’s an MBR or GPT type of MBR. From what I can tell, this is a multicast deploy with a linux OSID.
I don’t have an easy method to check if the mbr is GPT or mbr, so I’ve used file sizes to make this determination.
The steps that make an mbr, or gpt backup are:
On upload, it runs gdisk -l /dev/sda and searches for the gpt: present line. If it’s not present, it does a normal dd backup of the mbr, or in the case of linux, it copies all the data from 1 to the 63 sector at 512 bytes each sector. So the “filesize” is: 32256 bytes, but is still of MBR type. This was just a guess, but may be inaccurate for Ubuntu.My guess to the error you’re seeing is because of this. Maybe MBR Ubuntu 14.04 is actually larger so the deploy action is writing the d1.mbr as GPT structured rather than MBR?[/quote]
Well…
[CODE]# ls -lah
total 1.3G
drwxrwxrwx 2 root root 4.0K May 3 16:14 .
drwxrwxrwx 6 root root 4.0K May 3 16:18 …
-rwxrwxrwx 1 root root 32K May 3 15:58 d1.mbr
-rwxrwxrwx 1 root root 1.3G May 3 16:14 d1p1.img
-rwxrwxrwx 1 root root 125 May 3 16:14 d1p2.img
-rwxrwxrwx 1 root root 59M May 3 16:18 d1p5.img
[/CODE][CODE]# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
[/CODE]Is there any way in which I can get around this?
-
From what I can see, everything should be fine.
The gdisk -l /dev/sda would be from the Client system, which I’m assuming is what the 2nd code block is coming from?
That being said, is that message actually causing a problem or is it just a message being thrown?
-
I think this should answer your question better than I could…In short: nothing happens
[url=“/_imported_xf_attachments/0/708_Ubu_dep-2014-05-03-22-16-21.png?:”]Ubu_dep-2014-05-03-22-16-21.png[/url]
-
r1567 released.
Updated the ipxe files (undionly.kpxe, ipxe.krn, snponly.efi) to the latest from github. Added the ability to assign hosts an image from the Image page as well as “unassign” an image from a host.
-
r1569 released.
Updated the installer files so it will now create a backup of both the web and the tftp directories if they exist called: /tftpboot.prev and /var/www/{webdir}.prev. This way, it should be known to actually copy the new files without issue. Should also fix an issue with the undionly.kpxe from 1567, sorry mistakes happen.
-
Tom, do you think you could get HFS/HFS+ working? I think the info you need is all here - if you need more, just let me know
[url]http://www.fogproject.org/forum/threads/latest-fog-0-33b.6476/page-65#post-24721[/url]
-
[quote=“ArchFan, post: 26555, member: 19266”]Tom, do you think you could get HFS/HFS+ working? I think the info you need is all here - if you need more, just let me know
[url]http://www.fogproject.org/forum/threads/latest-fog-0-33b.6476/page-65#post-24721[/url][/quote]
I’ve already tried testing it all. While I could add all of the needed elements to the download scripts, I haven’t been able to figure out a good method to force MAC’s to actually Network Boot and allow image Uploads through FOG. So for right now it’s on hold. If you know how to get all of that working, please share and I’ll be more than happy to try getting it all working.
-
r1571 released.
Fixes another found issue with undionly.kpxe. I’ve fully tested and it’s back to working. Also fixes an issue with the Node Failures, where if there was a node failure found, it would keep telling you so unless you had other nodes within the same group. So when you had only one Node, the host reported the failure wouldn’t be able to image until the nfsFailures Table was cleared, even though it should really only wait for 5 minutes. This has been corrected for. I don’t know if this worked properly in 0.32, but I now know, for sure, it works in 1.0.0!
-
[quote=“Tom Elliott, post: 26556, member: 7271”]I’ve already tried testing it all. While I could add all of the needed elements to the download scripts, I haven’t been able to figure out a good method to force MAC’s to actually Network Boot and allow image Uploads through FOG. So for right now it’s on hold. If you know how to get all of that working, please share and I’ll be more than happy to try getting it all working.[/quote]
I was able to upload and download NTFS Windows 7 images to/from a Mac before using one of the methods below, but not natively. Unfortunately those are the only ways I’ve figured out as I don’t understand the cause of the issue or possess any coding skills. I don’t understand why booting from an iPXE iso from their website works, yet FOG uses iPXE and they won’t boot from that. Are you still chainloading from PXE to iPXE? That’s the only thing I can figure, but I know you had reasons for doing it the way you did.
- get the iPXE image from their site, burn to CD or copy to flash drive, then boot from the newly created iPXE media. Then FOG is found and booted from without further interaction. The con is that to boot from FOG again, you have to use the CD/Flash drive each time.
2)get a Mac install disc compatible with the machine, boot from it, and re-bless the disk using the command “bless --mount /Volumes/Macintosh\ /HD/ --setBoot --legacy --verbose”. The legacy argument seems to force the machine to use some type of legacy BIOS emulation. Reboot, then the machine will boot from FOG as many times as you’d like - I don’t know whether this will persist once the machine is reimaged or not.
- get the iPXE image from their site, burn to CD or copy to flash drive, then boot from the newly created iPXE media. Then FOG is found and booted from without further interaction. The con is that to boot from FOG again, you have to use the CD/Flash drive each time.
-
Maybe I missed some readme or something, but what changes when I select the Operating system of an image? For instance, how is Win7 different from Win8, Linux or Other?
-
Hi
I had to change the ip to the server fog is installed. I have changed in fog settings the ip in all sections and fog did not work.
So i manual change settings in config.php default.ipxe and in the table [SIZE=14px][FONT=Verdan][COLOR=#000000]nfsGroupMembers and now it is working as it shoud be.[/COLOR][/FONT][/SIZE]
[SIZE=14px][FONT=Verdan][COLOR=#000000][/COLOR][/FONT][/SIZE]Thanks for the nice project and sorry for my bad english
-
[quote=“Mr.Myagy, post: 26562, member: 23824”]Maybe I missed some readme or something, but what changes when I select the Operating system of an image? For instance, how is Win7 different from Win8, Linux or Other?[/quote]
The OS Type is used during the imaging process, but really only needed between Linux and Windows. Other is for some other type of OS. Linux tells the system that it needs to backup and restore the GRUB and MBR. Windows (any) tells the system, in Single Disk Resizable, how to create the partition tables and how to restore the MBR/partition tables.
I realize this is confusion.
Windows 2000/XP Single Disk Resizable Imaging Upload resizes the partition (there’s only one usually) before uploading.
Windows 2000/XP Single Disk Resizable Imaging Download uses the present winxp.mbr file to restore the drive, and expands the drive to it’s full size.
Windows Vista Single Disk Resizable Imaging Upload resizes the ntfs partition before uploading.
Windows Vista Single Disk Resizable Imaging Download uses the present winvista.mbr file to restore the partitions on the hard-drive. Expands the Main partition to the full size.
Windows 7 Single Disk Resizable Imaging Upload resizes the ntfs partitions before uploading.
Windows 7 Single Disk Resizable Imaging Download uses the win7.mbr file to restore the partitions to the hard drive. It assumes the partitions are: 1st 100MB and 2nd Whatever size (70GB I think). Then expands the 2nd partition after imaging completes.
Linux Multipart All or Single upload runs the same as Multipart works on Windows Vista/XP/7/8 except it copies the MBR AND GRUB during the upload process. Same on in reverse for download. -
[quote=“Tom Elliott, post: 26564, member: 7271”]The OS Type is used during the imaging process, but really only needed between Linux and Windows. Other is for some other type of OS. Linux tells the system that it needs to backup and restore the GRUB and MBR. Windows (any) tells the system, in Single Disk Resizable, how to create the partition tables and how to restore the MBR/partition tables.
I realize this is confusion.
Windows 2000/XP Single Disk Resizable Imaging Upload resizes the partition (there’s only one usually) before uploading.
Windows 2000/XP Single Disk Resizable Imaging Download uses the present winxp.mbr file to restore the drive, and expands the drive to it’s full size.
Windows Vista Single Disk Resizable Imaging Upload resizes the ntfs partition before uploading.
Windows Vista Single Disk Resizable Imaging Download uses the present winvista.mbr file to restore the partitions on the hard-drive. Expands the Main partition to the full size.
Windows 7 Single Disk Resizable Imaging Upload resizes the ntfs partitions before uploading.
Windows 7 Single Disk Resizable Imaging Download uses the win7.mbr file to restore the partitions to the hard drive. It assumes the partitions are: 1st 100MB and 2nd Whatever size (70GB I think). Then expands the 2nd partition after imaging completes.
Linux Multipart All or Single upload runs the same as Multipart works on Windows Vista/XP/7/8 except it copies the MBR AND GRUB during the upload process. Same on in reverse for download.[/quote]So if I want to image a dual boot (Windows + Linux) drive, I should use Linux or Other, right?
