|continued from:||Hotwiring a Chromebook to run Minecraft [link]|
|continued to:||chromebook sudo startkde fails [link]|
> shell $ sudo startkde … Loading extension GLX (EE) Fatal server error: (EE) xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory) (EE) …
Epic fail. kde booted fine yesterday, why is startkde failing now? Google “xf86OpenConsole: Cannot open /dev/tty0 (No such file or directory)“, find this is a known recent problem. Go go https://github.com/dnschneid/crouton and read there. Let’s remind me what chroots I have set up
$ ls /usr/local/chroots/ saucy
So, following directions
$ sudo sh ~/Downloads/crouton -u -n saucy
This takes less than 5 minutes. Ends with
WARNING: The following packages cannot be authenticated! libspeex1 linux-libc-dev libc6-dev libspeex-dev libspeexdsp-dev E: There are problems and -y was used without --force-yes Failed to complete chroot setup. Unmounting /mnt/stateful_partition/crouton/chroots/saucy…
$ sudo startkde Entering /mnt/stateful_partition/crouton/chroots/saucy... 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
Fails with the original “Cannot open /dev/tty0” error. Read some more at https://github.com/dnschneid/crouton/issues/1717. The saucy release is unsupported and at end of its life. Try a newer one, like the one recommended in the reading:
$ sudo sh ~/Downloads/crouton -r list $ sudo sh ~/Downloads/crouton -r trusty
This last command prints out a long message -- see the Appendix below -- but doesn’t do anything. Read some more. Do this to delete my existing obsolete chroot
$ sudo delete-chroot saucy
$ sudo sh ~/Downloads/crouton -r trusty
But I get the same long message. Read some more. Instead, I am going to replace saucy with trusty and reinstall kde
$ sudo sh ~/Downloads/crouton -r trusty -t kde
This does something -- it installs kde again! This takes about 30 minutes. Enter a Unix username and password. Here is the end of the installation
Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully Here's some tips: Audio from the chroot will now be forwarded to CRAS (Chromium OS audio server), through an ALSA plugin. Future Chromium OS upgrades may break compatibility with the installed version of CRAS. Should this happen, simply update your chroot. You can flip through your running chroot desktops and Chromium OS by hitting Ctrl+Alt+Shift+Back and Ctrl+Alt+Shift+Forward. You can start KDE via the startkde host command: sudo startkde Unmounting /mnt/stateful_partition/crouton/chroots/trusty... Done! You can enter the chroot using enter-chroot.
Now, test to see if it works
$ sudo startkde
It boots. Looks like I will have to reinstall minecraft and java. I do this, following the directions I typed up previously.
A second hotwired-for-minecraft chromebook was misbooted and we lost developer mode. This means that out installation of ubuntu, kde, java, and minecraft were all deleted. Ouch! I have to reinstall everything from the beginning. I will do this following my previously typed instructions [link]. Doing this again, there are a couple differences
- The "Preparing systems for Developer Mode." screen now does not show a progress bar. I just wait have to wait; the wait is approximately 5 to 7 minutes.
- Instead of sudo sh -e ~/Downloads/crouton -r saucy -t kde use sudo sh -e ~/Downloads/crouton -r trusty -t kde. This is important; the saucy version of Ubuntu Linux is out of date and "at the end of its life" while the trusty version of Ubuntu Linux is current and maintained.
The “long message”
chronos@localhost / $ sudo sh ~/Downloads/crouton -r trusty crouton [options] -t targets crouton [options] -f backup_tarball crouton [options] -d -f bootstrap_tarball Constructs a chroot for running a more standard userspace alongside Chromium OS. If run with -f, where the tarball is a backup previously made using edit-chroot, the chroot is restored and relevant scripts installed. If run with -d, a bootstrap tarball is created to speed up chroot creation in the future. You can use bootstrap tarballs generated this way by passing them to -f the next time you create a chroot with the same architecture and release. crouton must be run as root unless -d is specified AND fakeroot is installed AND /tmp is mounted exec and dev. It is highly recommended to run this from a crosh shell (Ctrl+Alt+T), not VT2. Options: -a ARCH The architecture to prepare a new chroot or bootstrap for. Default: autodetected for the current chroot or system. -b Restore crouton scripts in PREFIX/bin, as required by the chroots currently installed in PREFIX/chroots. -d Downloads the bootstrap tarball but does not prepare the chroot. -e Encrypt the chroot with ecryptfs using a passphrase. If specified twice, prompt to change the encryption passphrase. -f TARBALL The bootstrap or backup tarball to use, or to download to (-d). When using an existing tarball, -a and -r are ignored. -k KEYFILE File or directory to store the (encrypted) encryption keys in. If unspecified, the keys will be stored in the chroot if doing a first encryption, or auto-detected on existing chroots. -m MIRROR Mirror to use for bootstrapping and package installation. Default depends on the release chosen. Can only be specified during chroot creation and forced updates (-u -u). After installation, the mirror can be modified using the distribution's recommended way. -M MIRROR2 A secondary mirror, often used for security updates. Can only be specified alongside -m. -n NAME Name of the chroot. Default is the release name. Cannot contain any slash (/). -p PREFIX The root directory in which to install the bin and chroot subdirectories and data. Default: /usr/local, with /usr/local/chroots linked to /mnt/stateful_partition/crouton/chroots. -P PROXY Set an HTTP proxy for the chroot; effectively sets http_proxy. Specify an empty string to remove a proxy when updating. -r RELEASE Name of the distribution release. Default: precise, or auto-detected if upgrading a chroot and -n is specified. Specify 'help' or 'list' to print out recognized releases. -t TARGETS Comma-separated list of environment targets to install. Specify 'help' or 'list' to print out potential targets. -T TARGETFILE Path to a custom target definition file that gets applied to the chroot as if it were a target in the crouton bundle. -u If the chroot exists, runs the preparation step again. You can use this to install new targets or update old ones. Passing this parameter twice will force an update even if the specified release does not match the one already installed. -V Prints the version of the installer to stdout. Be aware that dev mode is inherently insecure, even if you have a strong password in your chroot! Anyone can simply switch VTs and gain root access unless you've permanently assigned a Chromium OS root password. Encrypted chroots require you to set a Chromium OS root password, but are still only as secure as the passphrases you assign to them.