@Sebastian-Roth To help, it was the array causing the issue directly.

The FOG Controller tests if the data it’s receiving is numeric or an array. Because the getSubObjectID’s always returns an array, the is_array portion of the FOGController constructor was taking over. This was passing to the setQuery method.

The setQuery method is only meant to work on associative array’s where the left side are the relevant table/key information and the right side is the values that correspond to those keys. The getSubObjectID doesn’t send the keys to work again, just the array of data.

The fix, for what it’s worth, was to simply add @max(self::getSubObjectIDs('PxeMenuOptions',array('default'=>1))) to the getter on the bootmenu page.

For what it’s worth. I don’t think this is a bug really. The message you’re seeing is coming from an error of another program. I can redirect all the output, but sometimes I think having these bits of information can help more readily than hinder actions.

@Fernando-Gietz Thanks for reporting, should now be fixed in latest.

Yes!!!

tail -n 1 /opt/fog/log/multicast.log
[05-05-16 7:36:18 pm] * No tasks found!
[root@fog6 bczgiflf]# date
jue may 5 19:36:30 CEST 2016

@ITCC So it’s okay to solve this as it wasn’t a bug?

Note, that a quick wipe doesn’t wipe the data off a drive. This means the BOOT bits are still present, even though the partition layout is not available to be used. This is why you’re seeing GRUB, but not able to do anything.

Hi, tested on my network : it’s OK.

I’m marking this solved. Please feel free to open this again if we run into the issue again.

v0.10.3 fixes this issue, please update

Saw the issue, and it was a problem. You may need to re-reset the value, but you should be good to go.

Fixed in latest.

It was working for a little while and then recently stopped again. I have been monitoring this thread: https://forums.fogproject.org/topic/7271/scheduled-cron-tasks-don-t-start/17

@Tom-Elliott I’m on r7410 at home currently, I just deleted this host and tried to network boot and do a full registration. It worked fine lol.

However all it saw was sda when I do have sdb there as well. They are still configured as RAID 0. I’ve learned a little more about this particular RAID card because of one of George’s posts. It’s a hybrid card. It doesn’t actually present one singular drive to the OS, it presents two. But it does have it’s own POST and BIOS menu, and can create volumes and delete them, restore volumes and such… The card is like 6 bucks on ebay - and for what I do with it, it’s a great card. I’ve bought 3 of them lol.

Fixed in latest. Have to know what Pages with objects there are, and I forgot that part. Added and all is working as expected.

@Sebastian-Roth This should be fixed now. Since moving to a less initialization status, I forgot that the last item called is the item that will be referenced. So flipped the logic on the cancellation and all started working for me.

Could you add a textual notice to the process that indicates that only the definitions are deleted and not the actual image files when deleting multiples?

@cyrmoon https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

@Tom-Elliott

Thanks Tom!
(wow, that was fast!)

@Wayne-Workman That seemed to make it happy, thanks.

@Frank How many images do you have? Is FTP_IMAGE_SIZE turned on?

@Quazz Should be fixed. The issue was because the host had no image assigned to it. This should now be fixed, again.