What CrOS build are they running? Did the issue start recently?

I am not the original reporter, but we are having a similar issue with Chromebits in Kiosk mode that start up and go into Chrome Sign Builder but then display "no policy received" in Chrome Sign Builder until we manually restart them.  The "cold boot" goes into stuck on No Policy Received, but if we go into google admin and manually reboot them, they successfully get the presentation.  Ours are brand new chromebits (May 2017) 
Google Chrome Version 58.0.3029.112
Platform Version   9334.69.0 (Official Build) stable-channel veyron_mickey
  Firmware Version   Google_Veyron_Mickey.6588.197.0
 Boot Mode   Verified
 Enrollment Date   May 10, 2017 
  

Hi Kirtika, any update on this?

The Chrome Sign Builder Version is 1.0.4
https://chrome.google.com/webstore/detail/chrome-sign-builder/odjaaghiehpobimgdjjfofmablbaleem
Deployed in Kiosk mode (auto launch kiosk app) from admin.google.com.  

I'll happily ship one of the chromebits to a developer who is willing to work on this configured to reproduce the issue.  email me lmewshaw at@ gmai1

Krishna, can you repro it in our QA environment?

One theory is that it may be due to a "slow wifi" login process.  I say theory because we can't see into this at all. The guess is that the kiosk app comes up before the wifi is connected. The Chrome Sign Builder app then can't get a network path out and goes into the "no policy" loop.  I don't know if you can prove that or even reproduce it in your QA environment.  Ideally, you could change the Chrome Sign Builder app that is stuck in "no policy" to retry its connection every 60 seconds.  Once the policy loads, the policy says to reload content every 600 seconds, but the "out of the box" app doesn't seem to retry at all.

Interesting. So, it may not be an issue with OS at all? Do you think it is just an app (Chrome Sign Builder) issue?

I'm having a similar issue. Chromebits not receiving policy after they restart. Customer have tested on v57, 58 and 59. Here are the logs that we retrieved https://drive.google.com/open?id=0B51czt8vCRpUbzFpMXpVRzBsZWs

Please let me know of any updates

Assigning it back to Kirtika

Hi Kirtika, any update on this?

Hi all,

Is there any new information on this issue?

Thanks!

I looked at a few of the logs both from the original report as well as from c#10. In all cases wifi seems to have come up fine and IP address has properly been assigned to the interface.

I don't know how/when the policy gets downloaded to the devices once the network is up.

Raj, can you help route to someone who knows more about the policy download piece since the wifi network seems to come up fine?

Drew, can you help triage?

Maksim, how do we handle extension policy for kiosk apps? I thought we preloaded and cached these, so we wouldn't need any wifi coverage when the kiosk session is actually launched.

Raj, what was the original reporter's use case - was it kiosk mode? what app were they running, and were they really seeing that the device couldn't connect to wifi, or were they seeing something else?

This bug morphed into a different issue. The original issue was that the Chromebits weren't able to connect to WiFi hotspot once it loses connectivity (no retry to connect to hotspot in kiosk mode)

The current issues is that, once Chromebits are restarted, it is unable to download the policy. I suspect the lack of cmos battery (and not able to know the datetime when restarted) may be the root cause.

OK, so which issue do you want to track with this bug? Is the "can't connect to wifi" thing still happening? According to comment #16 it sounds like the devices were indeed able to connect to wifi - do we have a repro for the original report?

As for the second report (CSB not having access to policy) - it shouldn't matter that there's no wifi as we shouldn't need access to the network to launch a kiosk with extension policy. Have we been able to repro this bug in-house?

I will follow-up with the original reporter re: "can't connect to wifi"

Re: the policy (not just PFE) refresh issue, i think the question is if the Chromebits were able to fetch the policy at every restart. We will try to repro.

sduraisamy, were you able to repro the issue or should this be archived?

Closing this for now, do reopen i you you see this issue.

*Closing this for now, do reopen if you you see this issue.