Crouton: Creating hwaudio group with GID 18... Password: su: Authentication failure

[a1exus]

I'm using ASUS Chromebook Flip with Google Chrome OS 53.0.2773.3.dev and while running following command:

chronos@localhost / $ sudo edit-chroot -all
name: kali-rolling
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/kali-rolling...
crouton: version 1-20160620130246~master:c39102d9
release: kali-rolling
architecture: armhf
xmethod: xorg
targets: xfce
host: version 8481.2.0 (Official Build) dev-channel veyron_minnie 
kernel: Linux localhost 3.14.0 #1 SMP PREEMPT Fri Jun 24 00:01:48 PDT 2016 armv7l GNU/Linux
freon: yes
Unmounting /mnt/stateful_partition/crouton/chroots/kali-rolling...
name: precise
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/precise...
Creating hwaudio group with GID 18...
Password: 
su: Authentication failurePassword: 
su: Authentication failure
chronos@localhost / $ 

I'm being asked for _Password_

Creating hwaudio group with GID 18...
Password: 
su: Authentication failure

Please advise.

[rudedog830]

I am having the same issue. Not sure what hardware the OP is using, but I'm on an Asus Flip running ChromeOS dev v53.

[drinkcat]

Please update your chroot, that should fix it.

[a1exus]

@drinkcat, I'm getting same thing with latest version of crouton:

chronos@localhost ~ $ sh ~/Downloads/crouton -V
Downloading latest crouton installer...
######################################################################## 100.0%
crouton: version 1-20160627183059~master:e3c0a690
chronos@localhost ~ $ sudo edit-chroot -all
Password: 
name: precise
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/precise...
Creating hwaudio group with GID 18...
Password: 
su: Authentication failure
chronos@localhost ~ $ 

[DennisLfromGA]

It seems to be failing on updates too according to this post: Authentication problem on Install

[a1exus]

@DennisLfromGA per Mark Rude, I've even tried trusty, however that did not work for me either, I got same prompt for password. --- This is issue is a _blocker_, at least for me(

chronos@localhost ~ $ sudo startunity
Password: 
Entering /mnt/stateful_partition/crouton/chroots/precise...
A chroot setup script still exists inside the chroot.
The chroot may not be fully set up.
Would you like to finish the setup? [Y/n/d] y
Preparing chroot environment...
Creating hwaudio group with GID 18...
Password: 
su: Authentication failure
The chroot setup script may be broken. Your chroot is not fully configured.
Removing the chroot setup script. You may want to update your chroot again.
UID 1000 not found in precise
Unmounting /mnt/stateful_partition/crouton/chroots/precise...
chronos@localhost ~ $

I cannot do anything(

[DennisLfromGA]

@a1exus,

Your chroot didn't even make it far enough to create a user id:

UID 1000 not found in precise

In this scenario, it would be best to just delete it and install a new chroot only try the 'trusty' release this time since it works much better.

Hope this helps,
-DennisL

[a1exus]

sudo edit-chroot -d trusty:

chronos@localhost ~ $ ls /mnt/stateful_partition/crouton/chroots/
trusty
chronos@localhost ~ $ sudo edit-chroot -d trusty
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
Delete /mnt/stateful_partition/crouton/chroots/trusty? [a/y/N] y
Finished deleting /mnt/stateful_partition/crouton/chroots/trusty
chronos@localhost ~ $

sudo sh ~/Downloads/crouton -n trusty -t xfce:

chronos@localhost ~ $ sudo sh ~/Downloads/crouton -n trusty -t xfce
...
Pruning /mnt/stateful_partition/crouton/chroots/trusty mounts...
Creating hwaudio group with GID 18...
Password: 
su: Authentication failure
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
chronos@localhost ~ $

sudo enter-chroot:

chronos@localhost ~ $ sudo enter-chroot 
Entering /mnt/stateful_partition/crouton/chroots/trusty...
A chroot setup script still exists inside the chroot.
The chroot may not be fully set up.
Would you like to finish the setup? [Y/n/d] y
Preparing chroot environment...
Creating hwaudio group with GID 18...
Password: 
su: Authentication failure
The chroot setup script may be broken. Your chroot is not fully configured.
Removing the chroot setup script. You may want to update your chroot again.
UID 1000 not found in trusty
Unmounting /mnt/stateful_partition/crouton/chroots/trusty...
chronos@localhost ~ $ 

[DennisLfromGA]

@a1exus - _Whoa, backup..._

In your _earlier_ post, you show a _'precise'_ chroot without a user id setup -

Entering /mnt/stateful_partition/crouton/chroots/precise...
...
UID 1000 not found in precise

That's why I recommended removing it and using the _'trusty'_ release.

---

In the _above_ post, you deleted a chroot _named_ trusty -

sudo edit-chroot -d trusty

Which I didn't know you had installed - that's not what I suggested you remove.
I don't know what _release_ it was since you haven't shown us the output of sudo edit-chroot -all like we ask.

Then you attempted to install a new chroot named _trusty_ with the xfce target -

sudo sh ~/Downloads/crouton -n trusty -t xfce

And you fell into the same predicament, a broken precise chroot.

The reason is, you didn't specify a _release_ using the '-r' option, you used the '-n' option which specifies the name so the _release_ defaulted to precise.

Now you need to delete it again with the first command you used above, namely -

sudo edit-chroot -d trusty

Then, install a new trusty chroot using something like -

sudo edit-chroot -r trusty -t xfce,extension

This chroot will be _named_ trusty since it defaults to the _release_ name if you don't specify a _name_.
I like to add the extension target for copy-paste operations.
I usually also add both 'xorg' & 'xiwi' ( and the 'crouton integration' extension ) for more flexibility.

_Hope this helps,_
-DennisL

[rudedog830]

I fell back to Trusty and everything is working for now. I will continue to monitor this issue for a resolution and if any testing is needed.

[a1exus]

@DennisLfromGA you're absolutely correct, I used wrong option and I was able to get it going with -r trusty! yet default release still broken(

[DennisLfromGA]

@a1exus - _Great!_

Yes, there still seems to be a problem with the 'precise' release and probably 'kali-rolling' that you first reported.

We'll give the developers some time to look at the issue.

-DennisL

[rickyz]

The issue is here:

https://github.com/dnschneid/crouton/blob/5d488fe8ffe603d730bc4f3b889df10a1ff228da/host-bin/enter-chroot#L531

Chrome dev on this device includes Android app support, which enables SELinux enforcing on the system. The linked code makes /sys/fs/selinux read only, which causes some sort of code path in su that falls back to password auth after failing to write to /sys/fs/selinux/access.

Tangentially related, I don't think this sequence of commands does what's intended:

mount --make-rshared /sys
mount --rbind /sys "$CHROOT/sys"
mount --make-rslave "$CHROOT/sys"
mount -o remount,ro "$CHROOT/sys/fs/selinux"

On my device, the ro mount flag does propagate to /sys/fs/selinux outside the chroot, similar to what's described at https://lists.linuxcontainers.org/pipermail/lxc-devel/2015-December/012978.html.

[rickyz]

If the intent is to hide the fact that SELinux is enforcing from the container, I believe you can get away with:

umount "$CHROOT/sys/fs/selinux"

instead of

mount -o remount,ro "$CHROOT/sys/fs/selinux"

This fixes the issue for me.

[filosofic]

sudo sh crouton -r trusty -t xfce,extension,xorg,xiwi
worked for me -- I was in my ¬/Download folder anyway...
and I had deleted any previous installations, restarted and downloaded the latest crouton.
I have been looking for a solution for weeks.
Thanks @DennisLfromGA your solution worked for me on my Minnie Asus Flip Dev 53.
I'm off to explore the distro I've loved since Drake.
Gracias.

[Delta0001]

I can confirm that the precise (default) release does not work. I get the same exact error after entering the password for hwaudio.
-r trusty seems to be working fine though. Thanks everyone!

[GeitHub]

For anyone with an ASUS Flip C100p who's a total novice and just wants to get something up and running this is what worked for me:

Delete whatever you did that didn't work

sudo edit-chroot -all

sudo edit-chroot -d (whatever the name of it is)

type the letter y (for 'yes') when it asks you to confirm the deletion

Then start fresh:

1. Download latest crouton here:
   https://goo.gl/fd3zc
2. Download the extension here:
   https://chrome.google.com/webstore/detail/crouton-integration/gcpneefbbnfalgjniomfjknbcgkbijom
3. sudo sh ~/Downloads/crouton -r trusty -t xfce,extension
4. Wait patiently with fingers crossed
5. Give it a username/password when prompted (you get to make these up, they aren't related to your Google account)
6. Done!
7. To launch the GUI type in: sudo startxfce4
8. To end the chroot simply log out (I can't seem to get the keyboard shortcut to cycle back and forth to work for me)

Thanks for everyone in the thread who helped out!

[Magicode1]

Very frustrating till I found this thread. Thanks for all your help and patience explaining!

[rhettprestwich]

@GeitHub, Thank you so much for your simple instructions. Worked like a charm!

[DennisLfromGA]

I'm wondering if this is still a problem with enter-chroot's new logic in place (shown below)?

    # Remount selinux as ro
    if mountpoint -q "$CHROOT/sys/fs/selinux"; then
        mount -o remount,ro,bind "$CHROOT/sys/fs/selinux"

If anyone on M53 with 'precise' and ARC++ can test this I'd be most appreciative.

Thanx,
-DennisL

[rickyz]

I haven't tested at the moment, but based on my comment explaining the issue above, I don't see how that change would help things.

It looks like https://github.com/dnschneid/crouton/commit/fe9dad6b3d569c1a97411aa7318582dc8c31b27a fixed the issue of breaking SELinux on the rest of the system, but the issue remains that remounting selinuxfs ro in the container makes su unhappy.

I'm not familiar with the original logic behind remounting selinuxfs ro (perhaps @drinkcat would remember: https://github.com/dnschneid/crouton/commit/3454f13e4b1f1e0ae5e0db03d57c7302814fa2ea), but it would probably work better to just unmount selinuxfs in the container as I suggested above.

[DennisLfromGA]

@rickyz,

The latest merge checks to see if selinux is a mountpoint and then _bind_ mounts it.
It's interesting that it seems to break on just some releases.
I don't have a Chromebook with Android apps yet so I can't test it, maybe you or others could.

-DennisL

[rickyz]

I don't have my device on me at the moment, but from the last time I debugged this, the issue is not the type of mount, but the fact that it is read only. I did test my suggested fix of

umount "$CHROOT/sys/fs/selinux"

and it fixes the issue.

[DennisLfromGA]

@rickyz,

I _think_ the problem with not mounting or unmounting selinux is that it kills Android apps when a chroot is launched so that's probably not the best solution.

-DennisL

[rickyz]

Hm, I don't see how unmounting selinuxfs inside of the crouton container would kill Android apps - that shouldn't have any effect on things running inside the Android container. I can't say whether I tested launching a crouton container while Android apps are running since it's been a month or two since I looked into this.

[DennisLfromGA]

@rickyz,

Sorry, I was mistaken. I'm at a disadvantage because I don't have a system with ARC++ yet so I'm just trying to keep up with the issues and not actually able to test or experience them.

I think the original issue was this one: Google Play crashes on Crouton chroot mount #2706

When a chroot was launched and selinux was mounted, Android apps crashed.
So the remedy was to just unmount selinux in the chroot.

This user dug into it a little deeper and decided he didn't need selinux mounted in the chroot.

However, I don't know the reason it was mounted in the chroot to begin with, I'm sure the devs had a reason.
We may have to let them take another look at this and decide what's best.

-DennisL

[ossie77]

New to everything Chrome and Linux based but fascinated by the potential. I bought an Acer R11 three weeks ago and have been trying to get a distro using the tutorials that litter the web but have spent hours and hours of fruitless endeavour trying to make it work. Geithub's instructions have got me on the cusp of success so many thanks. However, I am still not 'in'. The distro unpacks, I get to set a username and UNIX password. I enter sudo startxfce4 but then get asked for a password which I'm not sure about. I tried the Unix password but that didn't work. Any pointers much appreciated.

PS. I have just tried edit-chroot, passwd commands and get asked for my UNIX password but get authentication failure. I assume my UNIX password is for the distro. Do I need to delete the current chroot, set a password for the new chroot at the beginning and then set a new xfce target? Apologies for my confusion and if the solution is glaringly obvious. Just trying to understand.

[kdavh]

I'm still getting this issue:
Creating hwaudio group with GID 18...
then a password prompt, even with the current selinux fix: https://github.com/dnschneid/crouton/issues/2748 (I see these changes inside of my /usr/local/bin/enter-chroot)

This error happens only when trying to install the default ubuntu precise: crouton -t core,cli-extra -n test
If I try with trusty or newer, installation succeeds and I can use it: crouton -t core,cli-extra -n test -r trusty.

Unfortunately, I'm trying to use vagrant with virtualbox on the chroot which only successfully installs on precise.

Any help would be appreciated.

[drinkcat]

So I tried using umount on precise, and, indeed, that fixes the hwaudio group creation, but, then breaks this command:

useradd -u 1000 -G audio,input,video,sudo,plugdev -s /bin/bash -m nicolas

strace output looks like this:

access("/home/nicolas", F_OK)           = -1 ENOENT (No such file or directory)
gettid()                                = 6351
open("/proc/self/task/6351/attr/current", O_RDONLY|O_LARGEFILE) = 9
read(9, "u:r:chromeos:s0\0", 4095)      = 16
close(9)                                = 0
open("/etc/selinux/config", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/etc/selinux/targeted/contexts/files/file_contexts.subs_dist", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/etc/selinux/targeted/contexts/files/file_contexts.subs", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/etc/selinux/targeted/contexts/files/file_contexts", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/sys/fs/selinux/enforce", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)

One possible workaround looks like this:

    mount -t tmpfs none "$CHROOT/sys/fs/selinux"
    echo 0 > "$CHROOT/sys/fs/selinux/enforce"
    mount -o remount,ro "$CHROOT/sys/fs/selinux"

That seems to work with both precise and trusty.

Another way might be to clear the SELinux context for the current process? (useradd seems to check that first, before looking if /sys/fs/selinux/enforce exists)

@rickyz : Any idea?

[kdavh]

@drinkcat Thanks, that other change fixed the installation issue for me.