I think if you update the kernel inits, it should be supported. My guess is you’re running kernel inits from when you installed 1.2.0. @Tom-Elliott and I have updated the drive detection code to accept more interesting interfaces like mmc cards.

Just in case you’re interested: https://github.com/cspenceiv/fog-imager

I have been building a simplified set of imaging scripts. They’ll be fairly similar to what is in use now, but hopefully much easier to read and understand. I’m attempting to get away from a lot of things we currently do.

As of right now, I only have the upload script functional (on an experimental basis). That upload script does not support xfs and jfs (and others that aren’t supported officially by FOG yet). Additionally, it only does multi-disk, multi-partition creates for everything on a system.

Resizability is something I’ll look at later once the basics are taken care of here.

Right now, my test platform is a Arch live disk I built specifically for this testing (that way I’m not testing the buildroot image at the same time). Of course, this is also why I don’t have xfs and jfs support right now (big whoop for this testing).

…and of course, I’m just using samba shares.

@Junkhacker said:

is there a reason you chose to use a mysql query instead of using the built in mechanism of an http request to

<fog-ip>/fog/service/hostname.php?mac=f8:bc:12:6e:67:78&newService=0 

using the http request, you wouldn’t need to utilize database credentials

Maybe he likes to live dangerously.

@Wayne-Workman said:

FYI, kernel / init downloading via the web UI uses FTP…

And sometimes… just sometimes… when you install FOG and it’s “downloading kernels and inits…” the inits part doesn’t work…

Hmm… This calls for more verbose messages during install…

It could be that the file downloads, but opening the init to pack it with custom scripts fails. Maybe we need to look into doing a checksum if that’s the case.

I noticed this issue yesterday on my 1.2.0 test server. After digging through several unresolved bug reports for Ubuntu and Debian, I found that tftpd-hpa no longer likes being bound to 0.0.0.0:69. It now prefers :69 without the IP. Apparently, it can’t resolve 0.0.0.0 (which is ridiculous).

The quick fix is to edit the /etc/default/tftpd-hpa file. Change the value of TFTP_ADDRESS to equal “:69” instead of “0.0.0.0:69”.

This was resolved in SVN 3539/Commit eadae1b.

Try that out and see if it fixes your problem.

Things I want to do later:

• Give users the option to use buildroot themselves (it takes a long time)
• Make an init updater script so the init can be updated without just downloading everything and running the installer

Noting this forum post on the git repo issues. I’ll take a closer look at how networking is handled. It would be good for us to handle multiple NICs more gracefully.

Thanks for reporting.

Try the latest version (SVN 3540). The bug is fixed.

Thanks for reporting!

@fractal13 said:

Capturing all data up to the first partition was intentional. For GRUB2 bootloaders, the space between the MBR and the first partition is used to store extra data.
I suppose we could put an upper limit on the size though…

I just added an upper limit of 2MiB. @Tom-Elliott will get back to you on what SVN that fix will be introduced by. If you’re impatient, try out the dev-branch of the git repo.

@fractal13 said:

Capturing all data up to the first partition was intentional. For GRUB2 bootloaders, the space between the MBR and the first partition is used to store extra data.
I suppose we could put an upper limit on the size though…

I just added an upper limit of 2MiB. @Tom-Elliott will get back to you on what SVN that fix will be introduced by. If you’re impatient, try out the dev-branch of the git repo.

@g.chanaud said:

Can you just guide me to where the partitions creation take place in the case of a resizable image download task ?

https://github.com/FOGProject/fogproject/tree/dev-branch/src/buildroot/package/fog/scripts

The bin directory contains the scripts that fire off the jobs (you’ll want upload and download). The usr directory has the script functions that do all the magic.

@Junkhacker said:

is there a reason you chose to use a mysql query instead of using the built in mechanism of an http request to

<fog-ip>/fog/service/hostname.php?mac=f8:bc:12:6e:67:78&newService=0 

using the http request, you wouldn’t need to utilize database credentials

Maybe he likes to live dangerously.

Unfortunately, at this time, 1.2.0 uses a specific kernel. I talked to @Tom-Elliot about it and he said that 1.2.0 probably won’t work properly with a newer init.

Your option at this point is to try out the bleeding edge and see if the latest SVN version serves your needs for now.

I think if you update the kernel inits, it should be supported. My guess is you’re running kernel inits from when you installed 1.2.0. @Tom-Elliott and I have updated the drive detection code to accept more interesting interfaces like mmc cards.

@ch3i said:

@the_duke Hi, I’ve made a script to do that : https://forums.fogproject.org/topic/4510/scripts-customization-of-ubuntu-fog-service-for-ubuntu

You would.

Thanks for sharing!

3554 appears to have this fixed thanks to Tom.

The change that fixed the excessive DHCP timeouts was 3541. This may not be the most stable commit, but anything after that point will have it fixed.

@Wayne-Workman said:

@cspence Very nice work. Have you seen any performance hits during your testing?

At this point, it’s all about building a working prototype with VMs. But my other testing didn’t show any slow down using samba. Then again, I’m just using plain SATA drives.

Just in case you’re interested: https://github.com/cspenceiv/fog-imager

I have been building a simplified set of imaging scripts. They’ll be fairly similar to what is in use now, but hopefully much easier to read and understand. I’m attempting to get away from a lot of things we currently do.

As of right now, I only have the upload script functional (on an experimental basis). That upload script does not support xfs and jfs (and others that aren’t supported officially by FOG yet). Additionally, it only does multi-disk, multi-partition creates for everything on a system.

Resizability is something I’ll look at later once the basics are taken care of here.

Right now, my test platform is a Arch live disk I built specifically for this testing (that way I’m not testing the buildroot image at the same time). Of course, this is also why I don’t have xfs and jfs support right now (big whoop for this testing).

…and of course, I’m just using samba shares.