Best posts made by cspence

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.