RFT: croagh framework #176
Comments
|
Nice, that's good news! Constantly rebasing my master branch is not the most fun thing ever (I accidentally broke it today...), and your architecture looks simpler and more scalable than my brute-force copy-paste ,-) For the project name, maybe U for universal, and, well, the "T" is there to make it sound yummy ,-) I'll have a look at the code, and let you know if I see potential issues with Arch integration. |
|
Thanks. Am testing croagh now, and it's working just like crouton. Installed cli-extra -r raring, used it, deleted it, entered existing chroots, used, exited. All is the same. Anything specific to test? |
|
question - would it be possible to reconsider the naming conventions of targets and releases? I understand that you can only have one DE per release, and the DE name is the default target name, and you can always check the real chroot name outside the chroot in /usr/local/chroots for enter-chroot, delete-crhoot, etc., but if we can now have more than one chroot with the same DE, the startupscript name should possibly reflect the chroot or target that it will bring up. Currently it can change on you, and require you to remember what target name you used during install or -n parameter passed, and not be able to look up easily. For example, startxfce4 may have started your xfce target for a long time, then you create another chroot higher in the alphabet, and now your startxfce4 needs you to remember parameters to load, otherwise the first in the alphabet comes up. Perhaps it is as simple as keeping a list of targets installed somewhere, but preferably a unique startup script name for each target. Also, after an install, the 'enter-chroot' should possibly say 'enter-chroot-[chroot filename] otherwise one would always enter an arbitrary chroot. While in a chroot, uname -a doesn't say much, just arm v7, kernel 3.4, etc. Is there a way or command within the chroot to know which chroot target, and release you are in? |
|
Pretty much just need to test that the install completes with various targets and options; the rest should be just as (non-)functional as before. We can address naming conventions in another bug if you'd like to file one. |
|
OK, installing more targets, now e17 / raring. This error message, I've seen in crouton, so I don't think it's new, but just fyi: ... |
|
Yeah, that's nothing to worry about. The debootstrap second stage temporarily clobbers a lot of the bindmounts inside of the chroot. |
|
opened a new crosh / shell window and installed sudo sh -e ~/Downloads/croagh -t e17 -r raring Install went OK, entered username / pw. tried to start with sudo starte17 It's possible I had a window that had enter-chroot into the alarm chroot, but I'm sure that xfce (alarm) wasn't running. After the usual unmount-chroots didn't work, I power cycled, and alarm still won't unmount: nor will the sigkill loop abort with ctrl-c.: chronos@localhost / $ sudo starte17 Initializing built-in extension Generic Event Extension /usr/bin/xinit: connection to X server lost waiting for X server to shut down ratpoison:manage.c:236: error: XGetWMName failed Unmounting /usr/local/chroots/alarm... Initializing built-in extension Generic Event Extension /usr/bin/xinit: connection to X server lost waiting for X server to shut down ratpoison:manage.c:236: error: XGetWMName failed Unmounting /usr/local/chroots/alarm... Unmounts one or more chroots, optionally killing any processes still running By default, it will run in interactive mode where it will ask to kill any Options: Initializing built-in extension Generic Event Extension /usr/bin/xinit: connection to X server lost waiting for X server to shut down ratpoison:manage.c:236: error: XGetWMName failed Unmounting /usr/local/chroots/alarm... |
|
from crosh/shell sudo su top, I was able to kill the sh with -9, then as root, apparently the "p" which I thought displayed hanging processes unmounted alarm finally, but starte17 showed alarm still mounted. Will have to delete-chroot alarm and power cycle... localhost bin # ls |
|
After a lot of failed unmounts, I was finally able to delete-chroot alarm, power cycle, then try starte17 again, but now it is having trouble unmounting precise (xfce) which definitely wasn't running or entered since last power cycle. The dnsmasq, and whoopsie messages indicate that it may be trying to start xfce (precise) as those messages do come up when xfce (precise starts), even though this e17 target was using -r raring and chroot name is raring. Will try to delete raring next. crosh> shell [dix] Could not init font path element /usr/share/fonts/X11/misc, removing from list! waiting for X server to shut down X Error of failed request: BadWindow (invalid Window parameter) Unmounting /usr/local/chroots/precise... |
|
with alarm and raring (e17) deleted, the old precise xfce starts up, and exits well. Will try kde or another chroot with croagh later, but I think even though precise (xfce) is behaving well, there may be something "sticky" in my setup... Unmounting /usr/local/chroots/precise... |
|
Cool. Anyone else get the chance to test this new installer? |
|
after kde / raring finished, entered user / pw, sudo startkde, I got an all white screen, with black square block in upper left. system was frozen. power-cycled, something thinks precise is still mounted. Successfully entered xfce precise, exited, appears to unmount, startkde gave white screen with black rectangle. mouse is active, but can't hot-key back to chromeos. crosh> shell [dix] Could not init font path element /usr/share/fonts/X11/misc, removing from list! waiting for X server to shut down |
|
I'm pretty sure you already know that if you don't specify -n, you're going to be entering the first chroot alphabetically, regardless of what is installed in it. Nothing strange is happening here. |
|
argh, croargh, forgot. startkde -n raring does bring up kde / raring, still exits with sigkill loop that has to be terminated from another shell. Also, noted that double light tap to click wasn't working in kde/raring, had to hard press the touchpad. When a user deletes a chroot (e.g. delete-chroot raring) associated with a DE target (e.g. e17), the starte17 wrapper stays around. It's confusing when that chroot is gone... I'm not sure the tap to click, and sigkill loop are croagh related, but I can delete the kde / raring and re-install with crouton if needed. let me know. Thanks for reminding me about the -n |
|
Well, quick tests show that Ubuntu still works. Debian does not work, because the mirror is Ubuntu's by default. In
Also, I'm not sure if the files listing release names is really a good idea ( Maybe we could have a "pre-install" script, distribution-specific, that we could source before doing the bulk of the work, and that would set those variables: |
|
Good catch on the variables. I figured debian wouldn't work as is (it never in crouton); in fact currently there's no code in "core" to set up the software sources for debian. I feel that specifying the distro separately is redundant; I don't mind updating the release list once every 6 months or so since it makes things way simpler for the user. This also works nicely with the default-name-is-the-release, and provides backwards compatibility with existing chroots. For Arch and Gentoo, a "release" is more like a derivative, so releases named "arch", "alarm", "gentoo", etc would make perfect sense in this context. Help also needs to be extended to somehow list the supported releases. I'll likely do something akin to pre-install, but it needs to be somewhat better-defined. I'll keep thinking about it. |
|
Okay. I've added a "defaults" file to the distro, which needs to set ARCH and MIRROR at a minimum (if not specified). Also debian kinda works now maybe... |
|
... I'm installing a new croagh-quantal chroot now with targets: chrome-beta cli-extra gtk-extra kde unity xfce btw - is version (0-20130601151326~croagh:6560aba4) per the above link (https://docs.google.com/uc?export=download&id=0B1QUtoJwc9L3SmxyQmcxRUdNbFk) the latest or should we be checking another link for updates? |
|
That link will always be the latest until croagh gets merged in, after which it will be a dead link. |
|
Thanx, I'll assume the 'crouton-desktops' link will be treated the same way... |
|
Yep. No developments there, unfortunately. |
|
installed croagh with sh -e ~/Downloads/croagh -t kde, lxde, touch -r took 1-2 hours, but completed. not sure how to test touch on the samsung On Sat, Jun 1, 2013 at 8:44 PM, David Schneider [email protected]:
|
|
...follow-up.... |
|
Yep, it's really just the installer that has been reworked; once running it should be the exact same. |
|
Dennis, I realize you're on the x86 platform, but does the kde DE have tap to click working OK? Does anyone else on the ARM platform have tap to click not working on kde (but working with xfce) ? |
|
@tedm - I just now checked all three of my DE's ( kdm, unity, xfce4) on croach -r quantal and the touchpad seemed to work well including tap-to-click. Granted, I'm not proficient with the touchpad since I use an external mouse (Logitech M325) normally but I managed to kludge along pretty well. |
|
Thanks Dennis, since your x86 version of quantal with croagh and kde is Exiting the kde / quantal chroot also gives some error messages and a usual |
|
@drinkcat any other integration issues you can foresee? |
|
For now, 2 things:
Those are fairly minor issues, I guess I'll see the real ones (if any...) when I start porting my modifications. |
|
Starting porting my code, hit one more:
|
|
And also note the commits I pushed to you in #192 (2 so far). |
|
A last one for tonight (not really about the framework itself, though):
|
|
Thanks for the fixes and notes.
|
Ok.
Yes, I see the idea, my point is that I find it odd to have a generic facility that: 1. Will not apply for some distributions (no
Yes, I was just wondering if it would be possible to "bootstrap" it by adding the repository manually (and then let Chrome manage it). That would make the code neater, but I have no idea if that's practical.
Unless the user does something crazy like upgrading the release...
Oh yeah. Eyes got crossed and I though the daemon was started before the
One more issue:
|
It is indeed a bit odd, although it is nice to shift the implementation elsewhere so that targets are easier to create. Sounds like Arch/Gentoo will simply implement it as an error message. But really, it's no different from having a custom function defined for a distro--this way at least it has a predefined syntax. Maybe change the wording in the comments to say that install_pkg can be implemented as an error message if the distro doesn't support downloadable packages?
I don't really see how that would be any neater, especially since you may end up with two instances of the Chrome repo in your sources once the package is installed, and that install method is really not aligned with the way Chrome is packaged.
That's what
is that...XML? Yikes. Hopefully you can come up with some elegant way of parsing it.
I was indeed really hesitant to add that when I did. I'd be okay removing the dependency once we have a method for opening new tabs on the host side, in which case that can be the default URL handler. Until then, I'd rather not leave the people who blindly install DEs without a built-in web browser (how else would they search for "how to switch back to Chromium OS"?), and Chromium makes the most sense for default browser in the repo since it's available on all architectures and, well, you ARE on a Chromebook (or box). If I recall correctly, with dependencies it's smaller than Firefox (and Chrome, since unlike Chrome, Chromium builds against shared libraries). Another option would be Midori, but again, Chromebook. |
Yes, I thought that it would be more appropriate as a custom function for the distro. But, it's up to you ,-) If you update some of the comments, could you try to update the description of
If we write to
I was thinking about something quick and dirty. Maybe I need to rethink now ,-)
I see your point. I guess I need to figure out the URL handler thing then ,-) It can easily be integrated in the clipboard app, but that's not the solution we want, if we can avoid it... I tried searching for a DBUS interface, found other interesting stuff (volume, screen locking: I'll push those to you soon), but nothing about URL handling or clipboard... |
I think I'll leave it as-is for now. Once a few more distros are added we can see how useful it is to define it consistently and relegate it to a distro extension if it doesn't find any other usage.
Yeah, it's like --minimal, except it only prevents the installation of specific packages, allowing the other recommended packages to be auto-installed. For example, Firefox is recommended for Unity or something. We don't want to not include the other recommended packages, but we don't want Firefox installed by default either. So the second set of packages is a list of things to avoid installing automatically. In the case of apt-get, this is implemented by checking if the package is installed, and if it is not, adds a - to the end of it in the install command to mark that it should be uninstalled (which effectively means not automatically-installed). This...needs a better explanation in the comments.
Good point. How about this: each distro provide a release script that just prints out the installed release when run, and that gets installed as the chroot's /usr/local/bin/croutonrelease. That way the upgrader can run it to sanity-check, and croutonversion can run it to print out more information about the chroot.
There's nothing quick-and-dirty about XML, unfortunately. My vote is to brute-force try both :) |
Ok, thanks for the clarification.
Yes. It simply doesn't install anything that is "suggested" (it does suggest other packages from time to time, but only prints them out). Only strict dependencies are pulled in. (same with Gentoo BTW) So basically I will ignore the second set in Arch.
I guess the script will need to run in the chroot. Does it mean that the test is moved in |
It can be run with an explicit call to
It's also useful for croutonversion (which is run inside the chroot), which makes bug reporting easier.
I'd like to get to the point where you don't need to specify -r for upgrades. If we install croutonrelease into the chroot, we just need to run that to grab the release. If we add a script in the distro directory, we can iterate through each one until we hit one that successfully returns a release. I think you're right, though, chrooting to check the release seems kinda strange. The "iterate through" technique seems simple enough for upgrades/sanity checking, and we can start writing the release to /etc/crouton/release (and not reading it back) for the sake of croutonversion (understanding that it may be out-of-date if the user manually upgraded). So then the solution is:
|
Sounds perfect to me. |
|
I tried an encrypted install with xfce and it seemed to work well. It seems like drinkcat's xkb modifications haven't been merged into croagh yet? (As an aside, I added a comment to the pull request for the xkb overlay modifications but failed to note that it was closed, should I open a new bug?) I also took a quick look over at drinkcat's fork with arch support. I didn't see any specific work done yet for gentoo, but I'd be happy to brainstorm/help/test with that since I would probably consider that. I have run funtoo as an ordinary install on my Pixel and have got a make.conf and some config files that may come in handy. |
|
xkb is in there; install the keyboard target. Go ahead and open a new bug for brainstorming Gentoo support if you'd like; or better yet, fork the croagh branch and start scripting :) |
|
Okay, release detection implemented, bunch of drinkcat's awesome fixes merged, and some functions have been factored out into a library. More testing please! |
|
updated precise xfce with croagh ( sudh sh -e ~/Downloads/croagh -t xfce -u ) and seems to be OK. The text at the end of script is inconsistent, it says 'sudo startxfce4') and just 'enter-chroot', the latter will need a sudo if run as crosh / shell user $ and would be good if it said ...enter-chroot -n precise or ...startxfce4 -n precise as if I actually typed what it said, and had a chroot with name < 'p' that would start or enter instead. |
|
since update with croagh, have been getting this message upon exit of chroot: Unmounting /usr/local/chroots/precise... not sure if it is from croagh, or just from the update? |
|
Actually, that's an issue in crouton as well. I fixed one of the two sources of that but missed the other. Thanks for pointing that out. |
|
Please stress the croagh installer as much as you can this week (play with all of the installer parameters). Baring any explosions, I hope to merge it into master at the end of the week. |
|
xfce / quantal appears to install, run, and exit properly with croagh. |
|
I've got my encrypted xfce on raring updated with the latest chroagh. I'm guessing it's probably something very trivial that I'm overlooking, but something strange seems to be going on with xkb. I had previously made changes to Re bug #199 (why I'm messing with xkb and not using janky tools that edit keyboard layouts on the fly) |
|
You probably have to delete the xkb cache to apply changes: |
|
David, emptying the xkb cache didn't do the trick. I just tried it again to verify. Edit: Here's the patch I'm testing Edit 2: Bizarre, it seems to be working now, although when I assign |
|
I answered by own question, it's because of a patch to the kernel on the ChromeOS side for magic sysrq handling: https://gerrit.chromium.org/gerrit/#/c/29275/ @dnschneid There isn't a way around this, is there? I don't seem to have write access to sysrq seems to be set in Edit: Ugh, I'm totally brain dead today. It's solved through the overlay mapping of the number keys to function keys. |
|
Sure, it would be handy to have in the wiki. Go ahead and add it :) |
|
Welp, it's merged! Let the issues come rolling in. |
I've created a branch called "croagh" that adds a framework and abstractions that should make it reasonably straightforward to add new distributions with minimal to no duplicated code.
But first, we have to make sure the new installer framework doesn't screw up anything, so please test croagh with everything you can. If it installs and upgrades chroots without any errors, it should be fine (since nothing after that has fundamentally changed).
Once that's confirmed OK and merged, we can look into bringing @drinkcat's Arch bootstrap code and compatibility into master. I'll have to start thinking of a new explanation for the project's name...
The text was updated successfully, but these errors were encountered: