Update from technical side: I'm now setting up the test environment for ARC kiosk (with help from poromov@ peletskyi@.)


mitsuji@, do we have any migration UI flow defined for Kiosk?

More on technical side,
Kiosk login is handled by cryptohomed::AsyncMountPublic
https://cs.corp.google.com/chromeos_public/src/platform2/cryptohome/cryptohome.xml?type=cs&q=AsyncMountPublic+package:%5Echromeos_public$&l=165
that may need to be enhanced with forcing dircrypto parameter.

Actual migration function for regular users, MigrateToDircrypto
https://cs.corp.google.com/chromeos_public/src/platform2/cryptohome/cryptohome.xml?type=cs&q=MigrateToDircrypto+package:%5Echromeos_public$&l=537
takes authorization key as the parameter, while for public mount it is not needed. We need to adjust the difference here, too.

I spoke with abodenha@ about this yesterday. 

All updates to these machines are done without any UI and controlled by the admin. So here are the scenarios:

1. If a device does not have ARC++ running, then don't upgrade. 
2. If a device is running ARC++, then do the migration as soon as the device receives the update. No UI necessary. 

We will need to message to the admin the following: 
1. A heads-up that the next upgrade will include the migration process; 
2. What it means and how long it will take; 
3. As always give them the option to proceed using existing admin tools

By giving the admins a heads up and allowing them to make a choice using existing admin tools should ensure the desired behavior. 

On a side note I will try and get how many devices are used as kiosk devices, by device type and if they are actively using ARC++.

Ack.

Some questions (to mitsuji@ san mainly)

* "If a device is running ARC++, then do the migration as soon as the device receives the update. No UI necessary."
 To align with the regular user flow, this will be:
  1) When the device starts auto-login to the Kiosk session, migration starts.
  2) When the migration ends, the machine automatically restarts.
  3) The next auto-login to the Kiosk session after reboot will just log-in to ext4.
 Are we fine with this steps? (Especially the reboot at step 2?)

* Is M59 a hard deadline for this? (I might request some merges to the beta branch in that case. ETA is 1 week after  Bug 702526  is done. There's some serial dependency.)

JFYI, not sure how this should affect your plans:

1. Don't forget that ARC++ Kiosk device may not use auto-login, however, that's highly unlikely for real kiosk devices, more for development devices.

2. Also, current ARC++ Kiosk-targeted devices are Fievel and Tiger, and they are not expected to be updated to NYC soon. However, it's always possible to run ARC++ Kiosk on Kevin and etc.

That sounds about right. And to poromov@'s point this only affects kevin for M59 so kiosk devices won't see this update. 

Also spoke with Zel about the timing of kiosk. Let's do this work for M60, no need to rush. 

My current understanding is that we don't need to migrate kiosk devices in M61, but please correct me if I'm wrong.

(changed the title to emphasize its about only ARC Kiosk mode; no plan so far to migerate non-ARC environments.)

Issue 729034 has been merged into this issue.

Re the merged bug:
poromov@, bartfab@, we're targetting for M61 to implement the migration tool for ARC Kisok.
Let us know if you have concerns.

What's not implemented is the migration of the old profiles created on old versions (ecryptfs/M) to the new version (ext4c/N).
For development purpose, local profiles created on NYC-enabled versions should just work.

The problem in the original bug is that if you'll use for example R60-9589.0.0 veyron_minnie-cheets build, than ARC Kiosk just won't start because of check here:
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/arc/arc_util.cc?l=172&rcl=b6b13c9cfe64d52a4168d9d8d1ad9bb8f0b46a2a

I'm concerned that if there are publicly released M60 devices that have ARC migrated to NYC(ext4), ARC Kiosk won't work on these devices due to the same check. Is it right?

publicly released M60 devices that got NYC are those devices that are usually not kiosk devices (although I heard you can configure any device as kiosk), and we are planning to be rolling out NYC on M62 or later for kiosk devices (fievel, tiger) for this reason.

For developers, the workaround is to recreate the profile.

This timeline will not work. Kiosk is not a mode. Kiosk is a feature you can enable on any device. It is very heavily used in edu for high-stakes testing.

We know there are a number of Kevin devices in edu. These are scheduled to go MNC -> NYC in M60. If that happens, all testing kiosk sessions on the devices will stop working, with no way for admins to fix this.

If we are going MNC -> NYC for a given board, we *must* migrate kiosks in the same release.

Temporarily passing the ownership to leads/PMs for the coordination of the schedule.


From engineering perspective, I'm expecting to finish this work within 2 weeks (unless anything unexpected happens.) So, purely from the code level, I hope merging to M60 is still doable.

Adding Igor. If this makes it into M60, we will need to retrofit policy controls for it, within the same release.

The other option could be to temporary allow ARC Kiosk with eCryptfs on NYC.
Not sure whether it will work from engineering perspective and how it will fit CTS/CDD...

But even without migration, ARC Kiosk currently just doesn't work even on M61 NYC builds! http://crbug.com/729034 was initially created for this, but merged here.

Something went wrong during the migration implementation and now completely blocks ARC Kiosk on NYC builds.
For example, I'm using fresh (just resetted) Minnie with veyron_minnie/R61-9620.0.0 build on it. ARC container doesn't start in ARC Kiosk sessions. I think the same happens on M60 as well, for the device that already have NYC there.

"eCryptfs on NYC" is something we want to avoid for two reasons. Ecryptfs doesn't satisfy N-CTS, and I heard that migrating N's filesystem is hard/impossible since it started caring inode numbers (and thus we may lose the last chance to do the migration.)

Re #31: that's weird. I've been using Caroline NYC for ARC Kiosk testing for a while...

What `df -T /home/chronos/user` shows during the failing session?
Could you elaborate more on the "fresh (just resetted)" step? Is it by a flash of recovery image or by something else?

Anyway I'll check it on Minnie tomorrow.

Well, maybe more investigation is needed. Maybe the difference is that Caroline always had NYC, while Minnie is expected to migrate? But not sure how it might affect...

# df -T /home/chronos/user
Filesystem     Type 1K-blocks   Used Available Use% Mounted on
/dev/mmcblk0p1 ext4  10801712 139620  10093672   2% /home/chronos/user

First, I flashed with the following command:
cros flash ssh://minnie xbuddy://remote/veyron_minnie/R61-9620.0.0/test --disable-rootfs-verification

Then I cleared TPM and Powerwashed the device with the following commands:
localhost ~ # crossystem clear_tpm_owner_request=1
localhost ~ # echo "fast keepimg" > /mnt/stateful_partition/factory_install_reset
localhost ~ # reboot

Then enroll to managedchrome.com account and launch some ARC Kiosk session.

Could it be that ARC Kiosk session still tries to mount eCryptfs while the real one is ext4?

Thanks!!

"/dev/mmcblk0p1 ext4" implies that the ext4-crypto is correctly mounted.
Then there's some trouble in Chrome side and failing to detect that it is not ecryptfs.
I'll reopen the original bug and work on this.

Do any labels on this bug need to be changed to ensure that nothing breaks in 60?  We should still be pushing to ensure that kiosks don't break for some reason in 60 on Kevin or any other device.

The best way probably is to block crbug.com/672247 on this bug.

This is a bug to track kiosk mode integration for ext4 migration.

Is there a bug that is tracking M60 kiosk devices keep on functioning? 

I see that https://bugs.chromium.org/p/chromium/issues/detail?id=719278 was filed and marked as fixed, so are we all set?

> so are we all set?
Not quite. Could you answer the Comment 26?

Bug 719278 has nearly nothing to do with what we currently concern (it's mostly for internal dogfooding.)
Bug 729034 is resolved, so now Kiosk is working for fresh accounts.


What is asked now is the timeline of ext4 migration for Kiosk.
Unless we cannot delay Kevin-NYC launch to M61 (which I guess is the case), there seems no choice other than having the migration targetted to M60, though.

Wait, question at #26 doesn't make sense, EDU migration is going to be blocked for M60 and we don't run ARC++ for EDU.

What is the remaining use case ? Enterprise users trying to use kevin in ARC++ kiosk mode and getting blocked from using it unless profile is cleared ?

so it is, M-61

Re #42: Correct. This is the remaining concern. Enterprises that set up an ARC-M kiosk in M59 will have their kiosk disabled when the device upgrades to ARC-N, with no way to fix it other than a complete device wipe or a policy change that removes, then recreates the kiosk session.

Done for M61. More precisely, the migrator is enabled for Chrome 61.0.3144.0 or above
(= Chrome OS R61-9703.0.0 or above) (= the currently pushed Canary image).
Closing for now since it looks to be agreed(?) on labelling as M-61.


If M-60 merge turned out to be needed, the following 5 CLs are the necessary ones

* 4 CLs from  Bug 729905  (CLs for cryptohomed, chrome, protobuf, and DEPS-roll for enhancing a dbus method) and
* 1 CL from  Bug 730966  (CL for actually implementing the migration flow).

either way, I think we anyway need to bake the CLs one dev/canary for a while, though.