Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Authentication failure on enter-chroot after upgrade to Chrome 53 #2787

Closed
fulv opened this issue Sep 22, 2016 · 21 comments
Closed

Authentication failure on enter-chroot after upgrade to Chrome 53 #2787

fulv opened this issue Sep 22, 2016 · 21 comments

Comments

@fulv
Copy link

fulv commented Sep 22, 2016

chronos@localhost / $ sudo edit-chroot -all
Password: 
name: precise
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/precise...
crouton: version 1-20160902144033~master:9f8e9a22
release: precise
architecture: armhf
targets: cli-extra
host: version 8530.90.0 (Official Build) stable-channel veyron_minnie 
kernel: Linux localhost 3.14.0 #1 SMP PREEMPT Tue Sep 20 00:23:39 PDT 2016 armv7l armv7l armv7l GNU/Linux
freon: yes
Not unmounting /mnt/stateful_partition/crouton/chroots/precise as another instance is using it.

Please describe your issue:

This morning I had two chroots which were working just fine, one on internal storage, and one on SD Card. I had Chrome 52. As shown above, I'm on the stable channel, and the chroot is not encrypted (either of them).

This morning I upgraded to Chrome 53. Now I am unable to enter-chroot (for either the internal or the SD Card one), because it asks me for a password twice: once before and once after the Entering /mnt/... message. The first password prompt seems to be for the chronos user, but I don't know what the second prompt is for, because it won't accept anything I can think of, including the chronos user password, empty, test0000, or anything else. Before this morning's upgrade, I had never seen this prompt.

If known, describe the steps to reproduce the issue:

chronos@localhost / $ sudo enter-chroot
Password:                  #<----- it accepts my chronos user password
Entering /mnt/stateful_partition/crouton/chroots/precise...
Password:                 #<------nothing works here
su: Authentication failure
WARNING: starting chroot system dbus daemon failed with code 1
Password: 
su: Authentication failure
Unmounting /mnt/stateful_partition/crouton/chroots/precise...
chronos@localhost / $ sudo enter-chroot -c /media/removable/SD\ Card/
Password: 
Entering /media/removable/SD Card/precise...
Password: 
su: Authentication failure
WARNING: starting chroot system dbus daemon failed with code 1
Password: 
su: Authentication failure
Unmounting /media/removable/SD Card/precise...
@DennisLfromGA
Copy link
Collaborator

@fulv,

Did you per chance set a chronos password using chromeos-setdevpasswd?
Did you per chance enable 'Debugging Features' after a powerwash?
Are you prompted for a password when entering a shell session from crosh?

If you haven't encrypted your chroot(s), you shouldn't be prompted for a password when entering a shell from crosh nor when running 'sudo' commands.

-DennisL

@fulv
Copy link
Author

fulv commented Sep 23, 2016

@DennisLfromGA
Yes, I did set the chronos password using chromeos-setdevpasswd, because I was very confused as to what is going on. As far as I understand it, chromeos-setdevpasswd sets the password for the chronos user.

No, I definitely did not enable Debugging Features.

No, I am not prompted for a password when entering a shell session from crosh. But I am prompted when I run sudo commands, and the password I previously set with chromeos-setdevpasswd gets accepted when I do so.

@DennisLfromGA
Copy link
Collaborator

@fulv,

It's interesting that it would start giving you trouble after a Chrome OS update.

If I were you, I would remove the password you set and see if your chroots will then work.
The chromeos-setdevpasswd script creates /mnt/stateful_partition/etc/devmode.passwd
You could possibly do something like this, at least temporarily:

sudo mv /mnt/stateful_partition/etc/devmode.passwd /mnt/stateful_partition/etc/devmode.passwd.bak

Then logoff/on or reboot and see if you can launch your chroots per normal.

Hope this helps,
-DennisL

@fulv
Copy link
Author

fulv commented Sep 23, 2016

@DennisLfromGA Thanks for your tip. At least now both root and chronos users do not require passwords. However, I still get the password prompt after Entering /mnt/stateful_partition/crouton/chroots/precise..., that I can't seem to get past.

@DennisLfromGA
Copy link
Collaborator

@fulv,

Okay, then enter your chroot as 'root' and change the user password.

sudo enter-chroot -u root
passwd [username] (enter password twice)
exit

Then see if you can get into the chroot without a password prompt.

-DennisL

@fulv
Copy link
Author

fulv commented Sep 23, 2016

With sudo enter-chroot -u root it still prompts me for a password, so I'm still stuck there.

@DennisLfromGA
Copy link
Collaborator

@fulv,

At least now both root and chronos users do not require passwords.

So you can get to a bash shell as chronos without a password and you can use sudo in the shell without a password, correct?

However, I still get the password prompt after Entering /mnt/stateful_partition/crouton/chroots/precise..., that I can't seem to get past.

Even if you enter the chroot as 'root'?

It shouldn't ask for a password as 'root' and you should then be able to set the user's password.

But if that's the case then it's really weird that your un-encrypted chroots are prompting for a password.
It's too bad you don't have another Chromebook to test your chroot on the SD Card, that might narrow it down a little.

If you have enough space on your Chromebook, you can install a new chroot and see if you get the same behavior, you shouldn't.

-DennisL

@fulv
Copy link
Author

fulv commented Sep 23, 2016

@DennisLfromGA:

So you can get to a bash shell as chronos without a password and you can use sudo in the shell without a password, correct?

Correct.

Even if you enter the chroot as 'root'?

Correct. Same with -u root, -u chronos or -u fulvio, which is a user that exists inside the chroot.

It's too bad you don't have another Chromebook to test your chroot on the SD Card, that might narrow it down a little.

Are chroots portable between different architectures? My wife has a two years old ASUS C200, and she has been asking me to get her a Linux environment installed, anyway.

If you have enough space on your Chromebook, you can install a new chroot and see if you get the same behavior, you shouldn't.

I do have enough space. First, I tried restoring a pre-upgrade backup (with sudo edit-chroot -r ...). The restore worked fine, but then on trying to enter-chroot I get the same password prompt again.

Then, I tried this:

sudo sh crouton -f mybootstrap.tar.bz2 -t cli-extra -n cli

It started doing its thing, lots of unpacking, installing and configuring messages, and finally:

I: Configuring resolvconf...
I: Configuring initramfs-tools...
I: Base system installed successfully.
Pruning /mnt/stateful_partition/crouton/chroots/cli mounts...
Creating hwaudio group with GID 18...
Password: 
su: Authentication failure
Unmounting /mnt/stateful_partition/crouton/chroots/cli...

So then I tried it again:

chronos@localhost ~/Downloads $ sudo enter-chroot cli
Entering /mnt/stateful_partition/crouton/chroots/cli...
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 cli

(that last line is in red)

Another thing I noticed is that ~/Downloads/crouton has no x permission bits set. I'm not sure if that's something that changed after the upgrade or whether it was always like that. I basically never did anything to crouton since the first time I downloaded.

@DennisLfromGA
Copy link
Collaborator

@fulv,

I'm stumped. Maybe someone else will notice this thread and offer some help or suggestions.

In lieu of that, a powerwash might clean things up but you'll lose your chroot(s) unless you have them backed up. If you can't use them, it may not matter.

The ~/Downloads folder isn't executable so that's why you have to use the sh ... prefix.

-DennisL

@fulv
Copy link
Author

fulv commented Sep 24, 2016

All right, so just to add one more data point, I tried this on my wife's chromebook, and got no password prompt, but this error:

chronos@localhost / $ sudo enter-chroot -c /media/removable/SD\ Card/
Entering /media/removable/SD Card/precise...
chroot: failed to run command 'su': Exec format error
WARNING: starting chroot system dbus daemon failed with code 126
chroot: failed to run command 'su': Exec format error
Unmounting /media/removable/SD Card/precise...

I do not get this error on my own machine, only the password prompt.

The chroot I installed in /mnt/stateful_partition/crouton/chroots works fine on this machine:

chronos@localhost / $ sudo edit-chroot -all
name: precise
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/precise...
crouton: version 1-20160902144033~master:9f8e9a22
release: precise
architecture: amd64
targets: cli-extra
host: version 8530.81.0 (Official Build) stable-channel squawks 
kernel: Linux localhost 3.10.18 #1 SMP Wed Sep 7 16:53:01 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux
freon: yes
Unmounting /mnt/stateful_partition/crouton/chroots/precise...

@fulv
Copy link
Author

fulv commented Sep 24, 2016

Some googling seems to suggest that the chroot: failed to run command 'su': Exec format error stems from a 64-bit vs 32-bit incompatibility. So the chroots appear not to portable cross-platform.

@fulv
Copy link
Author

fulv commented Sep 24, 2016

...Aaaaand even after a powerwash I still have the same problem.
Now I'm really at a loss.

@DennisLfromGA
Copy link
Collaborator

The 64-bit / 32-bit platform errors are understandable.

I was hoping the powerwash might straighten out some permissions but I guess that narrows the problem down to your chroot(s).

That new info. may help though.
Is it possible to do a crouton update on the internal or external chroot to see if the permissions or whatever get fixed? It might be worth a shot.

@fulv
Copy link
Author

fulv commented Sep 26, 2016

@DennisLfromGA After the powerwash I was not trying to revive the old chroot on the SD Card. I was simply making sure that crouton works at all by starting from scratch with a brand new chroot, and I am still getting exactly the same issue.

Now I found issue #2655, which seems to suggest that the problem lies in the combo precise + chrome 53 on ASUS Flip (Minnie), because the latter includes the Android Play store. In fact, my working chroot was precise on chrome 52, and it broke when I went to 53. Also, the ASUS C200 (squawks) does not have the Android Play Store on Chrome 53 (and probably never will), and that's why precise is working there.

I now tried trusty with chrome 53 on minnie, and it works.

So now I wonder if there is any way to upgrade an existing precise chroot to trusty, if I'm not able to start it. I guess I'll have to downgrade to Chrome 52 first. I'll try this: http://www.chromestory.com/2014/11/chromebooks-get-options-downgrade-operating-system/

@DennisLfromGA
Copy link
Collaborator

@fulv,

After the powerwash I was not trying to revive the old chroot on the SD Card. I was simply making sure that crouton works at all by starting from scratch with a brand new chroot, and I am still getting exactly the same issue.

Okay, didn't know that you started from scratch.

Now I found issue #2655, which seems to suggest that the problem lies in the combo precise + chrome 53 on ASUS Flip (Minnie), because the latter includes the Android Play store.

Yes, there was a problem with devices when Android on Chrome rolled out, starting a chroot would kill all the Android apps. There was another somewhat related issue #2758 that prevented a crouton installation or update from completing and even prevented you from entering the chroot. I thought though that this PR #2749 fixed that, maybe not.

So now I wonder if there is any way to upgrade an existing precise chroot to trusty, if I'm not able to start it.

Given your situation, I don't think so. :(

I now tried trusty with chrome 53 on minnie, and it works.

I use 'trusty' for most of my chroots, it's stable and just about everything works on all platforms.
I have tried 'xenial' for a couple of experimantal things like MATE and LXQt but it still has problems with unity-2d, gnome-session-fallback, etc.

-DennisL

@fulv
Copy link
Author

fulv commented Sep 27, 2016

Here are my final updates:

  1. Downgraded to 52
  2. There is an issue that makes accounts unworkable in 52 if they have already been used in 53
  3. But fortunately, I could do everything in the Guest account
  4. I went into my existing precise chroots, ran sudo do-release-upgrade to upgrade them to trusty
  5. Upgraded back to 53

And now I'm back in business.

As far as I'm concerned, this issue can be closed. However, I do think that in light of the fact that more and more chromebooks are going to come online with Android in the near future, crouton should no longer install precise by default. I'm going to open another issue to that effect.

@DennisLfromGA
Copy link
Collaborator

@fulv,

Thanx for all your steps and solutions in resolving these issues.

And thanx to my fellow TCs Gerald & Dymphe in Chromebook Central for helping out.
I missed your topic or I would have helped since I'm all too familiar with the M53 --> M52 syncing issues. :(

-DennisL

@DennisLfromGA
Copy link
Collaborator

Here's another explanation: #2655 (comment)
It seems to be that CrOS M53 + precise + ARC++ will not work.

@lourot
Copy link
Contributor

lourot commented May 26, 2017

After a Chrome-OS upgrade a couple of days ago, I got the same issue: sudo enter-chroot would prompt me for a mysterious password.

So I did sudo sh ~/Downloads/crouton -u -n chrootname, which failed because of the same prompt. Afterwards, I tried entering the chroot again and got

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

And then everything was magically repaired.

@StupidExperimenter
Copy link

This only happens (At least to me)
When you install packages from other systems:
Like installing Sid packages on a Buster chroot.
This is the likely error for this.

@StupidExperimenter
Copy link

So your best choice is replacing your install.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants