Raj, can you investigate and prioritize this issue?

> stay stuck on either "initialising application" or "please wait".

Sounds like fs corruption. Kernel log from the device could confirm the problem.

> stuck on "waiting for network configuration"

Network wait should time out, either showing a "configuration" link or an error screen to allow choosing wifi etc.

Logs (/var/log/chrome/*, /var/log/messages) from the device when the problem occurs would help to narrow down what goes wrong.

I don't think kiosk devices provide a kernel log? If they do, we've not seen anything obvious running the log zip through the log analyser. 

And yes, the network wait should time out, but it doesn't. 

When using ethernet, the network will keep waiting. If you unplug the ethernet cable, you get the popups box. Reconnecting the cable, the popups knows ethernet is connected, but the app never restarts automatically (it does on a "clean" device). So something is definitely wrong. 

We've also noticed that upgrading an app from "offline_enabled=true" to "offline_enabled=false" tends to "break" the device. 

Whilst our app itself checks for network connection (to download assets) when in offline mode, everything is OK. When in online mode, despite good connectivity, we get stuck on the network wait. 

We've since had to go back to offline mode and put more checks in our app. 

Can you attach device logs from the affected device? 

Reboot device and skip kiosk mode (go to normal ChromeOS mode) by pressing ctrl + alt + s 

Open browser and go to chrome://net-internals and select "ChromeOS" from left side menu. Click on "Store debug logs". Attach the created log file.

I'll have to wait till we get another device in this state. We managed to get most of them fixed, in that we pushed an app update that enabled offline mode. As soon as I can get my hands on an affected device, I'll try get the logs you requested.

We are having this initializing application/ waiting on network chromebit kiosk issue as well. I stored a log file.

Deleted: debug-logs_20161025-133138.tgz 341 KB

debug-logs_20161025-133138.tgz 341 KB Download

We've recently now encountered similar behaviour on an app that with "offline_enabled" set to true. 

ChromeOS tries to load the app but gets stuck showing the app icon, with the message "please wait". It'll stay like this indefinitely. 

Power washing fixed the issue, but we are unsure how it got like that. Nor have we been able to faithfully reproduce it. 

We are working with apps that obtain their data online (ie: chrome sign builder or our self-made google slides presentation launcher). We haven't found a workaround to get these apps launching. The Chrome sign builder gets stuck at 'please wait' and the slides app gets stuck at 'waiting for network connection'. Neither time out. Our Chromebit is straight out of the box, updated to 53 as well. 

Tried to reproduce the problem locally on a veryon-mickey chromebit, using M-53 Stable 8530.96.2 (test image).  App used:  "TestNav" (id: mdmkkicfmmkgmpkmkdikhlbggogpicma)

The first three power-off reboots re-launched automatically fine.
The fourth time the network was found and the splash screen shown, but then showed a spinning black donut that looked to go on indefinitely (I waited 10 minutes).   [generate_logs output attached].
Six more power-offs all successfully re-launched, though.
I will try some more apps...

Deleted: log-102516-144622.tar.gz 478 KB

log-102516-144622.tar.gz 478 KB Download

Didn't have any problems with AIRSecure Test, but ChromeSign hit a known problem with the Chrome renderer once (Issue 654833); an illegal ARM instruction causes a "Black Screen of Death".  A reboot cleared it up, and ChromeSign had no other anomalies.

Re #10: Might be related to network. Does your network have proxy or something? There are quite some line like the following in the log:

[18343:18523:1025/125802:ERROR:cert_verify_proc_nss.cc(942)] CERT_PKIXVerifyCert for www.google.com failed err=-8172

err=-8172 -> SEC_ERROR_UNTRUSTED_ISSUER

so https to www.google.com is not going through somehow.

This sounds exactly the same as my problem 585657 reported here.

Even if a proxy is configured it is not used to attempt HTTPS access to several google servers during boot and this halts the boot process, with 'waiting for network'

Any updates on this yet?

This sounds like the same issue I am experiencing.  In response to comment 15, there is no proxy in use.

I think I may have fixed this issue in our environment.  Within the Google Admin Console:
Device Management - Chrome - Device Settings - User Data
Set to "Do not erase all local user data"

Not sure why this works as the kiosk app is launched prior to any user sign in.  I assume that when this setting is set to delete, the app must download every time the device starts up, which would explain why the hang times have been unpredictable and vary depending on the wireless network the device is attached to.

If that setting is ON, the kiosk app will not persist data across reboots and the app state will be cleared. Though I do not think the app will be downloaded at every kiosk session start.

Xiyuan, can you please confirm?