Auto-mounting of USB stick failed

[grdoba]

[was: Installation of chroot to USB stick failed]

I tried to install xfce chroot on the external USB stick (not SD card) using sudo su cd /home/chronos/user/Downloads/ sh -e crouton -t xfce -p /media/removable/USB\ Drive/ but the installation failed with the messages: ......... I: Extracting xz-utils... I: Extracting zlib1g... Moving bootstrap files into the chroot... Preparing chroot environment... x11 target does not work on ARM. Substituting in xephyr. Installing brightness into the chroot... Installing host-dbus into the chroot... Installing croutonpowerd into the chroot... Installing croutonwheel into the chroot... Installing croutonwm into the chroot... Installing xinit into the chroot... x11 target does not work on ARM. Substituting in xephyr. x11 target does not work on ARM. Substituting in xephyr. Installing startxfce4 into the host... Installing enter-chroot into the host... Installing delete-chroot into the host... Installing mount-chroot into the host... Installing unmount-chroot into the host... /tmp/crouton.BML/host-bin/enter-chroot: 167: readlink: Argument list too long /tmp/crouton.BML/host-bin/enter-chroot: 167: mountpoint: Argument list too long /tmp/crouton.BML/host-bin/enter-chroot: 167: mkdir: Argument list too long Unmounting /media/removable/USB Drive//chroots/precise... localhost Downloads #

I noticed that similar messages appeared in issue #21 in somewhat different context.

The installation to the local disk was fine. Playing with this installation I noticed that the click on the touchpad does not work when I just start xfce with sudo startxfce4. I need to cycle between Chrome OS and xfce using Ctrl-Alt-Shft--> in order to get it working.

Also, I realized that I am not able to mount usb drives when in xfce. Is it the feature of this chroot or just my problem? It would be nice to have usb drives available...

At some point (when the issue with external installation will be fixed) I'd like to move the chroot from the local drive to a usb drive (or SD card). What would be a reasonable way to do that?

[dnschneid]

If you run sh -e crouton -V, what version do you get? If it's not crouton: version 0-20130225111212, download it again and try again; I might have fixed that earlier today (it was borking on the trailing slash in the -p argument).

There's no reason the trackpad click shouldn't work; that's odd. Does that happen every time you start xfce for the first time?

When mounting a USB drive, I imagine you get a "permission denied" message? I've been looking at that off and on, but haven't figured out what's missing yet. You can safely mount things manually using mount, though, which isn't much of a solution (although they will automatically unmount if you close the chroot, which is convenient).

Moving a chroot is as simple as moving a folder. If that's your only chroot, then something along the lines of sudo mv /usr/local/bin /usr/local/chroots /media/removable/USB\ Drive/ will move everything to the USB drive (don't interrupt it), and then you can start the chroot via sudo sh -e /media/removable/USB\ Drive/bin/startxfce4. Make sure your USB drive is formatted with ext, or you'll be exploring new ground (fun...but dangerous).

[dnschneid]

As for the mounting a USB drive: try creating a file called /etc/polkit-1/localauthority/50-local.d/10-mount-crosh.pkla with the following contents:

[Allow mounting when started from crosh]
Identity=*
Action=org.freedesktop.udisks2.filesystem-mount
ResultAny=auth_admin
ResultInactive=yes
ResultActive=yes

And then try mounting again, and see what happens.

[grdoba]

My version of crouton complains on -V as illegal option. Thanks for the hint how to move the installation. I will give a try to a new version later today.

The physical click on the touchpad actually works. The tapping and tapping with two fingers do not work when I do a fresh start from crosh. Without two-finger tapping I do not know how to get a right-click. After I logout from xfce and start the session again from the same shell the touchpad gestures are working. When switching forth and back between Chrome OS and xfce sometimes the tapping stop working.

The manual mount of the usb drive works normally. My stick is mounted by Chrome OS as /dev/sda1 on /media/removable/USB Drive type ext4 (rw,nosuid,nodev,noexec,relatime,data=ordered) In xfce, I have created usb directory in my home and mounting sudo mount /dev/sda1 usb works fine. I have created the file as you suggested and tried to remount the usb drive but it did not help with automounting. Here are the kernel messages:

kulagin@localhost:~$ dmesg|tail [ 7668.719784] sd 3:0:0:0: [sda] Assuming drive cache: write through [ 7668.725363] sd 3:0:0:0: [sda] No Caching mode page present [ 7668.725376] sd 3:0:0:0: [sda] Assuming drive cache: write through [ 7668.727270] sda: sda1 [ 7668.730754] sd 3:0:0:0: [sda] No Caching mode page present [ 7668.730766] sd 3:0:0:0: [sda] Assuming drive cache: write through [ 7668.730777] sd 3:0:0:0: [sda] Attached SCSI removable disk [ 7670.692297] EXT4-fs (sda1): recovery complete [ 7670.693017] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: [ 7766.465050] [drm:exynos_drm_kds_callback] ERROR previous work detected kulagin@localhost:~$

I also tried to restart the xfce session but again the automounting does not work. By the way, mount with no arguments does not give me anything.

[dnschneid]

Sweet, that means you should definitely upgrade your chroot with the latest version of crouton. I also just pushed a fix for an issue you were about to run into when running from a USB drive.

Tapping not working at first is even stranger. That probably deserves a separate bug.

mount with no arguments won't give you anything because the chroot has a different /etc/mtab that doesn't really reflect reality. Check the permissions of the /media/$USER directory in the chroot; if you can't ls the contents without root permissions, remove the directory (first make sure nothing is mounted inside that), and see if that helps auto-mount (along with the 10-mount-crosh.pkla fix).

[grdoba]

Thanks for a new version of crouton, it worked just fine with the USB installation of a chroot.

Tapping not working at first is still persistent.

As for a USB drive auto-mount, I could not get 10-mount-crosh.pkla method to work. The USB drive icon appears on the desktop, but if I try to open it in the file manager the latter will try to do it forever without particular error messages. My /media directory is empty in the chroot. However, I am quite fine with manual mounting of a usb drive, it works just fine.

A question about something different. Is there a (simple) way to pass the content of the clipboard between Chrome OS and a chroot? Say if I want to pass some piece of memory (text or simple graphics) in the clipboard from Chrome OS to a chroot or back, what should I do. So far I could not get that work.

[dnschneid]

Are you just double-clicking it on the desktop, or are you going to Thunar (the file manager) and selecting it from the list on the left?

As for clipboard, there's currently no method to sync (Chromium OS doesn't even use the standard X11 clipboard), but there's probably a way to interface with it via dbus or something (the hidden benefit of Chromium using separate processes for everything is that whatever it uses to communicate between tabs, we can use as well...in theory). I'll look into it sometime soon.

[grdoba]

I try to open the drive in Thunar from the list on the left. Thanks for explanations.

[dnschneid]

Could you try to collect some data for me on the auto-mounting issues?

1. When you plug in and then attempt to auto-mount the USB disk, does anything interesting print out in the terminal that you originally launched xfce from (probably crosh)?
2. Inside xfce, run sudo killall polkitd, and then sudo /usr/lib/policykit-1/polkitd. While that's open in the terminal, plug in and attempt to auto-mount the USB disk; does it print anything?

Thanks; hopefully we can track this down quickly.

[grdoba]

1. Hrere are the messages in crosh when I start xfce, plugin a USB stick and try to open it with thunar:

chronos@localhost / $ sudo startxfce4 /usr/bin/startxfce4: S= tarting X server [dix] Could not init font path element /usr/share/fonts= /X11/misc, removing from list! [dix] Could not init font path element /u= sr/share/fonts/X11/cyrillic, removing from list! [dix] Could not init fo= nt path element /usr/share/fonts/X11/100dpi/:unscaled, removing from list!<= br>[dix] Could not init font path element /usr/share/fonts/X11/75dpi/:unsca= led, removing from list! [dix] Could not init font path element /usr/sha= re/fonts/X11/Type1, removing from list! [dix] Could not init font path e= lement /usr/share/fonts/X11/100dpi, removing from list! [dix] Could not = init font path element /usr/share/fonts/X11/75dpi, removing from list! [= dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/di= rs/TrueType, removing from list! /usr/bin/xinit: XFree86VT property une= xpectedly has 0 items instead of 1 /etc/xdg/xfce4/xinitrc: 1: /etc/xdg/x= fce4/xinitrc: ssh-agent: not found xfdesktop[15697]: starting up xfce= 4-settings-helper: Another instance is already running. Leaving... (polk= it-gnome-authentication-agent-1:15711): GLib-CRITICAL *: g_variant_newstr= ing: assertion `string !=3D NULL' failed (polkit-gnome-authentication-ag= ent-1:15711): polkit-gnome-1-WARNING *: Failed to register client: GDBus.E= rror:org.freedesktop.DBus.Error.ServiceUn known: The name org.gnome.Sess= ionManager was not provided by any .service files thunar-volman: Unsuppo= rted USB device type. thunar-volman: Unsupported USB device type. thu= nar-volman: Unknown block device type. thunar-volman: Not Authorized.(Thunar:15691): Gdk-CRITICAL _: IA__gdk_window_get_window_type: assertion= `GDK_IS_WINDOW (window)' failed (Thunar:15691): Gdk-CRITICAL _: IAgd= k_window_get_window_type: assertion `GDK_IS_WINDOW (window)' failed (Thu= nar:15691): Gdk-CRITICAL **: IAgdk_window_get_window_type: assertion`GDK= _IS_WINDOW (window)' failed

[grdoba]

2. kulagin@localhost:~$ sudo killall polkitd [sudo] password for kulagin: kulagin@localhost:~$ sudo /usr/lib/policykit-1/polkitd Entering main event loop Connected to the system bus Registering null backend at priority -10 Using authority class PolkitBackendLocalAuthority Acquired the name org.freedesktop.PolicyKit1

\ (polkitd:25027): WARNING **: skipping unknown tag <_description> at line 15

\ (polkitd:25027): WARNING **: skipping unknown tag <_message> at line 16

[dnschneid]

That all looks normal. I'll look into this more. Thanks!

[dnschneid]

Wait a sec, that's not actually normal (thunar-volman: Not Authorized.), and polkitd should be spitting something out as well. I'll see if it's an ARM thing.

[dnschneid]

Ah, it turns out that since ARM uses the Xephyr approach, the USB stick gets mounted by Chromium OS the moment you attach it, and udisks misinterprets the fact that it's already been mounted. I think this can be fixed by doing a shared-bind-mount of the /media directory, but it'll require a few steps of changes.

[leomilano]

Same error here, David, Acer C7 running your latest, as of this morning. Fantastic work, man, thank you!!! (note that this is not an ARM lappie)

[dnschneid]

Okay! I've prepared a solution that I believe makes external drive mounting and sharing between Chromium OS and the chroot sane, but it could use more testing before I merge it into master.

If the problem is bothering you, grab this release of crouton and update your chroot (-u). Let me know what works and what doesn't work.

The main behavior is as follows:

1. Anything mounted when you start the chroot is accessible in both the chroot and Chromium OS.
2. Anything you mount while Chromium OS is focused (or any time at all, in the case of ARM/Xephyr) will mount in Chromium OS and be accessible in the chroot. You will NOT be able to unmount/eject the device from within the chroot (at least, not with the GUI); you will get a "Not authorized" error. This is intentional. You can eject the device from Chromium OS, or manually unmount it with the umount command.
3. Anything you mount while the chroot is focused (except on ARM/Xephyr) will be visible to only that chroot. Chromium OS will not see it. This is also due to the way udisks and Chromium OS's mounter interact.
4. Unmounting (exiting) the chroot will unmount any devices that fall under (3), and leave mounted any devices that fall under (1) and (2).
5. If your chroot (or any other running chroot) is located on a removable disk, you should NOT be able to access their contents by browsing the disk in any chroot, even as root. If you can, this is bad and you should tell me so I can fix it.

Good luck! If it seems like all is good, I'll merge it into master in the coming days.

[leomilano]

Dude! This works like a charm on my Acer C7! Fantastic work! I can automagically mount a USB now. I'll try item 5 (and others) when I have a minute, cheers!

On Wed, Mar 6, 2013 at 6:16 PM, David Schneider notifications@github.comwrote:

Okay! I've prepared a solution that I believe makes external drive mounting and sharing between Chromium OS and the chroot sane, but it could use more testing before I merge it into master.

If the problem is bothering you, grab this release of croutonhttps://docs.google.com/uc?export=download&id=0B1QUtoJwc9L3QXBwcncySURSYVUand update your chroot ( -u). Let me know what works and what doesn't work.

The main behavior is as follows:

1. Anything mounted when you start the chroot is accessible in both the chroot and Chromium OS.
2. Anything you mount while Chromium OS is focused (or any time at all, in the case of ARM/Xephyr) will mount in Chromium OS and be accessible in the chroot. You will NOT be able to unmount/eject the device from within the chroot (at least, not with the GUI); you will get a "Not authorized" error. This is intentional. You can eject the device from Chromium OS, or manually unmount it with the umount command.
3. Anything you mount while the chroot is focused (except on ARM/Xephyr) will be visible to only that chroot. Chromium OS will see it. This is also due to the way udisks and Chromium OS's mounter interact.
4. Unmounting (exiting) the chroot will unmount any devices that fall under (3), and leave mounted any devices that fall under (1) and (2).
5. If your chroot (or any other running chroot) is located on a removable disk, you should NOT be able to access their contents by browsing the disk in any chroot, even as root. If you can, this is bad and you should tell me so I can fix it.

Good luck! If it seems like all is good, I'll merge it into master in the coming days.

— Reply to this email directly or view it on GitHubhttps://github.com/dnschneid/crouton/issues/27#issuecomment-14539181 .

[dnschneid]

Updated to support udisks (precise) as well as udisks2 (quantal).

[gorzell]

Works for me on a Pixel with quantal.

[grdoba]

This also works for me on Samsung ARM chromebook.

[dnschneid]

Merged into master. Let the bug reports start rolling in!

[davidmaxwaterman]

I've been having trouble using a USB stick that is formatted as EXT4 (npm needs symlinks) in ChromeOS. A ChromeOS doc says EXT4 is 'supported' (whatever that means), but it says otherwise when I plug it in. I don't much care about it working form ChromeOS since I only really want to use it inside Crouton, but I guess the latter needs the former. Is my issue the same as this one? It'd be great to get EXT4 working from a USB stick.

[divx118]

@davidmaxwaterman You are probably on dev channel, ext2/3/4 support is dropped in chromeos File app. See https://github.com/dnschneid/crouton/issues/954 . You could try the two script I made: mount-extfs and unmount-loop copy both to /usr/local/bin and run sudo mount-extfs -s to setup a UDEV rule. After that plugin your USB stick or SD card. Note that you will need to setup the udev rule again everytime you do a reboot or after a power off.

[davidmaxwaterman]

Ah, thanks a lot :) Shame they keep messing with their developers :(...but anyway, I get an error when I try to run that :

failed to execute '/usr/local/bin/mount-extfs' '/usr/local/bin/mount-extfs -d sdb -m rw,dirsync,nosuid,nodev,noexec,relatime': No such file or directory

The scripts are there though, and chmod +x :

-rwxrwxr-x 1 davidmaxwaterman davidmaxwaterman     4892 Aug 26 20:44 mount-extfs
-rwxrwxr-x 1 davidmaxwaterman davidmaxwaterman     1390 Aug 26 20:44 unmount-loop

What did I miss?

[divx118]

You do have the scripts on chromeos in /usr/local/bin? So not in the chroot /usr/local/bin. Sorry I wasn't clear about that.

[davidmaxwaterman]

doh :) Yes, that did it. Awesome! Thanks :)

[divx118]

Forgot to mention, you will get a notification "Whoa, there. Be careful" if you have notifications enabled for the Files app, although the device is unmounted and you remove the disk. Maybe the new commit will fix this in the future, but I haven't had a change to dig through the code yet.

BTW if you notice any other issues with the scripts I appreciate if you mention them on #954

[davidmaxwaterman]

Hi, I wonder if you have a reference for the dropping of extfs support? How can I complain or suggest they rethink? My feeling is this is yet another case of them ignoring the needs of developers, and I'd like to be able to add my +1 to the voice against such moves. Is there a 'bug' or 'issue' on this? Where are such things documented?

[divx118]

The only reference I got is https://code.google.com/p/chromium/issues/detail?id=315401 , however I don't think it will help to complain. They dropped it mainly for security reasons which I can understand, not that I am happy about it. At least we still have support for mounting it on the command line and with some tricking also in the File app by using loop devices.

[davidmaxwaterman]

Well, thanks for that. Yes, I think that's it. I do think it is a case of they being over-zealous since the security issue quotes was hypothetical, or so it seemed to me. I can understand, but if they don't agree to reinstate it (unlikely) there are other solutions. They can at least not make it so fiddly to get working inside crouton. Anyway, I left my thoughts and we'll have to see how it goes.