Unable to mount encrypted chroot in ChromeOS 9647.0.0

[jamebus]

It appears that a change in the latest dev channel update is breaking ecryptfs chroots. This is ChromeOS 9647.0.0 running on samus. I'm working through the changes and wanted to get this report out there in case anyone else is seeing this issue. There's been some filesystem changes in this release.

chronos@localhost ~ $ sudo enter-chroot -n jessie-development
Password:
Enter encryption passphrase for jessie-development:
mount: mount(2) failed: /run/crouton/mnt/stateful_partition/crouton/chroots/jessie-development: No such file or directory
Failed to mount jessie-development.
chronos@localhost ~ $ dmesg | tail -n 10
[ 6000.487521] SELinux: initialized (dev proc, type proc), uses genfs_contexts
[ 6001.066621] SELinux: initialized (dev proc, type proc), uses genfs_contexts
[ 6071.935105] SELinux: initialized (dev proc, type proc), uses genfs_contexts
[ 6072.239855] SELinux: initialized (dev proc, type proc), uses genfs_contexts
[ 6096.005517] Could not find key with description: [REDACTED]
[ 6096.005524] process_request_key_err: No key
[ 6096.005528] Could not find valid key in user session keyring for sig specified in mount option: [REDACTED]
[ 6096.005535] One or more global auth toks could not properly register; rc = [-2]
[ 6096.005541] Error parsing options; rc = [-2]
[ 6117.011786] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19

[casandra9]

Hi,
ChromeOS Update 5.9.211.31 (59.0.3071.91) from Jun 5, 2017 breaks the crouton install.

My experience:

• crouton fresh install on ChromeOS 4.9.... May 11, 2017 - works, update host system to the new version 5.9.211.31 (59.0.3071.91) Jun 5, 2017 breaks the install (mount: mount(2) failed: No such file or directory), had to powerwash (recovery mode) and start from scratch, the powerwash destroyed the update too so i could get back to non-developer mode

• I then installed the ChromeOS update and tried crouton again - with the update installed crouton installation fails with: mount: mount(2) failed: No such file or directory

• I tried again with powerwash (recovery mode) and at one time I enabled Debug Mode and changed the chronos password (sudo chromeos-setdevpasswd via the console) AND that finally broke everything, I bricked my ChromeOS Notebook into Developer Mode, trying to switch back results in a Chrome OS is broken message at boot and I have to escape+F3+Power back into Developer Mode which seams to work, normal operation but no way out of Developer Mode

• the ChromeOS update mentioned above stays now active even after a powerwash (or recovery attempt) and all crouton installation attempts fail with the mount failure, last time tried yesterday Jun 14, 2017

Looks like the ChromeOS update from Jun 5th, 2017 changes something in the FS and the crouton installer needs an update too. Be careful, when you update ChromeOS it'll break you Ubuntu and there's no way back, from my user point of view...

Hardware:
Lenovo N22: Intel N3050, 2GB RAM

I am happy to submit logs. Please be specific in your request I am not a developer.

Please help...

[guypursey]

Experiencing same/similar problem with Crouton since an update. The build date is apparently on Tuesday 6th June -- although it's only in the last day or two that I had the problem, but only since I restarted my Chromebook. There's a good chance I hadn't restarted/updated it before that since the update came out.

I've attempted my usual command of sudo startkde and also sudo enter-chroot. With either command, I'm asked for my password as usual and my encryption key as usual and at that point get the following:

mount: mount(2) failed: No such file or directory

No idea how I can now get to my Ubuntu OS (I have trusty) and thereby to all my usual tools.

Update: I have an ASUS C300. Version of Chrome OS listed in Settings > About is 59.0.3071.91 (Official Build) (64-bit).

[casandra9]

Exact same behavior here, as soon as I restarted with the update enabled it's no longer accessible (or install-able).

I will submit the exact Chrome OS build once I am home in the mo i do not have access to the Chrome Book (it's my sons school book :() I think it's the 59 major version upgrade causing the issue.

Lenovo N22 (Touch)
V8 5.9.211.31 (59.0.3071.91) from Jun 5, 2017

[DennisLfromGA]

This issue may be the same or related to the work being done on this PR:

• Link user keychain to session keychain Link user keychain to session keychain #3246 --> Create new session, then link user keychain to session keychain Create new session, then link user keychain to session keychain #3278

Hope this helps,
-DennisL

[jbertman]

+1 same issue here, encrypted kali-rolling, broke the moment I updated ("critical" update, seemed to drop the Play Store on the main channel or something similar)

chronos@localhost ~/Downloads $ sudo enter-chroot
Password: 
Enter encryption passphrase for kali-rolling: 
mount: mount(2) failed: /run/crouton/mnt/stateful_partition/crouton/chroots/kali-rolling: No such file or directory
Failed to mount kali-rolling.
chronos@localhost ~/Downloads $ sudo sh crouton -u -n kali-rolling
/usr/local/chroots/kali-rolling already exists; updating it...
Enter encryption passphrase for kali-rolling: 
mount: mount(2) failed: /run/crouton/mnt/stateful_partition/crouton/chroots/kali-rolling: No such file or directory
Failed to mount kali-rolling.
chronos@localhost ~/Downloads $ dmesg | tail -n10
[  763.514624] Could not find key with description: [SNIP]
[  763.514633] process_request_key_err: No key
[  763.514638] Could not find valid key in user session keyring for sig specified in mount option: [SNIP]
[  763.514647] One or more global auth toks could not properly register; rc = [-2]
[  763.514654] Error parsing options; rc = [-2]
[  774.241169] Could not find key with description: [SNIP]
[  774.241193] process_request_key_err: No key
[  774.241197] Could not find valid key in user session keyring for sig specified in mount option: [SNIP]
[  774.241206] One or more global auth toks could not properly register; rc = [-2]
[  774.241213] Error parsing options; rc = [-2]

ASUS Chromebook Flip C302CA-DHM4
9592.15.0 (Official Build) beta-channel cave
Version 60.0.3112.26 (Official Build) beta (64-bit)

[casandra9]

I confirm the issue comes with the update (59) and it affects the user / password handling.
I was able to install new crouton client xfce/Ubuntu/Xenial after update w/o encryption enabled (-e parameter).

This runs w/o issue. Encryption doesn't work (for me) it throws the mount error.

[moclei]

Same here,
One Acer Chromebook 15, Ubuntu Trusty, just updated to Version 60.0.3100.0 (Official Build) dev (64-bit), getting "mount: mount(2) failed: No such file or directory
Failed to mount trusty." when I run sudo startunity

One Acer Chromebook 14 for Work, just updated to version 59.0.3071.91 (official build) (64-bit), getting "mount: mount(2) failed: No such file or directory
Failed to mount xenial." when I run sudo startxfce4

Both just started this when I updated the chromebook to the latest version yesterday.

I've backed up and restored both, which worked but did not change anything. Can't mount the chroots to get in and test anything. Renamed them to no effect. I'm stumbling around in the dark here so would love some help.

[casandra9]

chroots work w/o encryption only with the current crouton build.

[mithrenithil]

I've been testing PR #3278 "Create new session, then link user keychain to session keychain" and the 2 line patch works great. Many thanks to smerrill, drinkcat and dnschneid for coming up with the solution so quickly!

[moclei]

Those two lines worked for me, and I learned something new. Thanks.

[rj919]

Same problem. Couple of questions.

1. By "two lines", do you guys mean:

keyctl new_session >/dev/null
keyctl link @u @s

added to host-bin/mount-chroot?

2. If this patch works, how would I go about adding those two lines to my local installation of crouton. Assuming, my shell entrance places me at the root /, specifically what file in what folder do I need to edit?

3. If this patch is being rolled into crouton, how do I update crouton itself? And, if I do update crouton, will it wipe my mounts in the process? And, if it would wipe my mounts, is there any way to backup the mount prior to updating once it suffers from this mount: mount(2) lock out?

Thanks ahead of time.

[moclei]

@rj919 Yes those two lines

When I added those two lines, it fixed the problem as if it had never happened. I did download the latest version of crouton although I don't know if that was necessary. I didn't update, delete or change my chroot, I didn't lose any data. I just got it back as if the issue had never occurred.

What I did

1. I went to the shell,
2. I typed sudo su
3. I typed those two lines as you have them, one by one
4. I entered my chroot as I normally do with sudo startxfce4. It worked!
5. In between that I typed some lines I didn't need to and I reset my chromebook for good measure, but I don't think any of that made a difference, just the four steps above

[grafer74]

YES! Thank you very much moclei.
It worked for me, even if I had to repeat that 3 times, probably because it is necessary to restart the Chromebook after that. I also updated my crouton. Now everything works as usual.

[rj919]

@moclei Thanks for the quick response!
I am now able to enter my chroot whenever I run from the shell:

$ sudo su
$ keyctl new_session >/dev/null
$ keyctl link @u @s
$ sudo startunity

However, it appears I need to perform this sequence from the root user each time I restart the chromebook. Do you know if there is a way to persist the config?

[moclei]

@rj919 Sorry bud, I don't know, just learning about this myself.

I'm installing a new chroot as we speak, without encryption, and I've got all my stuff ready to transfer over to that one. This will not be a problem with an un-encrypted chroot from what I've read above.

I assume they will 'perma' fix this going forward, if they haven't already. I don't know if their fix will apply to newly installed, encrypted chroots only or if it will fix existing encrypted chroots. Perhaps someone more experienced than I will reply here and explain that.

It's not super convenient to make a new chroot, re-install everything, transfer files etc. But I'm still loving having linux on my chromebook.

[guypursey]

@rj919 So far, I think I've permanently fixed my problem. Or, rather, the fix is already in crouton and I've managed to successfully apply it. And I have an encrypted chroot.

Here, roughly, from memory, are the steps I followed, in case this helps:

1. I went to shell.

2. I entered the command sudo su. (This took me from a chronos@localhost prompt to localhost.)

3. I entered the two session and keychain lines one by one. To be clear the two lines are:

    keyctl new_session >/dev/null
    keyctl link @u @s
   

4. At this point I was able to run sudo startkde (or sudo enter-chroot) and get into my Chroot as if nothing had ever happened. However, here I decided to run crouton. But I had to find it -- becuase I was running as superuser I couldn't just run sh ~/Downloads/crouton -u -n trusty (trusty is my chroot name), as it couldn't find root just like that. (Perhaps this is down to my ignorance of shell scripting.)

   But I was able to run

   sh ./home/user/309b525f2f22a653ca33cb374da08beb4cc61a8f/Downloads/crouton -u n- trusty
   

   to achive the same effect. I'm certain the longer folder in the middle of that pathname will differ for you. I used ls home/user to see which folders I had then ran ls on each until I found my Downloads folder with crouton, which I downloaded earlier, inside it. Apologies if this is stating the obvious, but just in case it helps.

5. Once this was done, I exited the su and tried entering my chroot from the usual shell.

Like @grafer74, at some point I restarted my Chromebook and rebooted -- it didn't work straight away but the second time I tried it, it updated crouton successfully -- something stuck and now the fix is persisting. Apologies that these final details are a little fuzzy but if you try following them and vary when you shut down or exit the superuser shell, hopefully it will work for you. Perhaps someone with a better understanding of the workings of it can explain the details of how the fix is applied.

[dnschneid]

Actually, I released a new version of crouton with the patch last night, so you should just be able to update your chroot and things will work.