dd if=/dev/zero of=loop bs=1M count=16

This could be much smaller, I seem to remember 720k floppy disks (not sure what is the actual minimum).

sudo mkfs.vfat loop

The label can be added there with -n label.

the last array:string:"rw" are the mount options

Does the trick still work if we mount it as ro? Just to make sure the user does not put stuff in the dummy partition.

Could we auto-mount ext2/3/4 USB drives with an udev rule? (I'm pretty sure we can actually, the tricky part would be to get the eject button to work properly: currently it only removes the bind mount)

Is it possible to umount -d /dev/loop# once the bindmount is in place? Or does crosdisk get confused/kernel doesn't let you?

@drinkcat Without running into issues smallest was 1024 Kb. With a quick google I couldn't find a real defined minimum for the size. So I for now took just a shortcut and tried some sizes. I will see if I get some more info on that.

Yes we can use "ro" no problem, that will work.

I adjusted the topic post with the changes.

@dnschneid Yes that is possible, but crosdisk won't like that. It will still show as mounted in the Files app. However if something is mounted on top of the fat32 bindmount you can't unmount it in the Files app or on the command line.

The idea with my comment was to unmount the fake loopback partition leaving the bindmount in place, so that when Files does eventually unmount it, it will get rid of the bind-mount and remove the directory.

@dnschneid Ok this needs some attention, I don't think it will be that easy, however I didn't really looked into it yet.
@drinkcat I tried adding a udev rule, but it doesn't get processed when looking for a partition with ext2/3/4 when a drive is added.
The simple rule I used:

SUBSYSTEM=="block", KERNEL=="sd??", ENV{ID_FS_TYPE}=="ext?", RUN+="/usr/local/bin/mountextfs"

I left out ACTION to see if the rule works. On removal of the drive it works, but when a drive is added not. It seems like crosdisks is blocking further execution of rules when coming across an ext2/3/4 partition. I didn't look at the source code yet to confirm this.

If I make it to watch when a drive got added it is processed.
An idea to make this work would be to add a rule and watch when a drive is added, execute a script. In the script we can use dbus-send to get the relevant info.
Get all auto mountable drives

chronos@localhost / $ sudo dbus-send --print-reply --system --dest=org.chromium.CrosDisks /org/chromium/CrosDisks org.chromium.CrosDisks.EnumerateDevices
method return sender=:1.16 -> dest=:1.76 reply_serial=2
   array [
      string "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/host39/target39:0:0/39:0:0:0/block/sdc"
      string "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/host39/target39:0:0/39:0:0:0/block/sdc/sdc1"
      string "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/host39/target39:0:0/39:0:0:0/block/sdc/sdc2"
      string "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host38/target38:0:0/38:0:0:0/block/sdb"
      string "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host38/target38:0:0/38:0:0:0/block/sdb/sdb1"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda10"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda11"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda12"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda2"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda3"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda4"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda5"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda6"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda7"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda8"
      string "/sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda9"
      string "/sys/devices/virtual/block/loop0"
      string "/sys/devices/virtual/block/loop1"
      string "/sys/devices/virtual/block/loop2"
      string "/sys/devices/virtual/block/loop3"
      string "/sys/devices/virtual/block/loop4"
      string "/sys/devices/virtual/block/loop5"
      string "/sys/devices/virtual/block/loop6"
      string "/sys/devices/virtual/block/loop7"
      string "/sys/devices/virtual/block/loop9"
   ]

Get the drive info from a specific drive:

chronos@localhost / $ sudo dbus-send --print-reply --system --dest=org.chromium.CrosDisks /org/chromium/CrosDisks org.chromium.CrosDisks.GetDeviceProperties string:"/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/host39/target39:0:0/39:0:0:0/block/sdc/sdc1"
method return sender=:1.16 -> dest=:1.77 reply_serial=2
   array [
      dict entry(
         string "DeviceFile"
         variant             string "/dev/sdc1"
      )
      dict entry(
         string "DeviceIsDrive"
         variant             boolean false
      )
      dict entry(
         string "DeviceIsMediaAvailable"
         variant             boolean true
      )
      dict entry(
         string "DeviceIsMounted"
         variant             boolean false
      )
      dict entry(
         string "DeviceIsOnBootDevice"
         variant             boolean false
      )
      dict entry(
         string "DeviceIsOnRemovableDevice"
         variant             boolean true
      )
      dict entry(
         string "DeviceIsReadOnly"
         variant             boolean false
      )
      dict entry(
         string "DeviceIsVirtual"
         variant             boolean false
      )
      dict entry(
         string "DeviceMediaType"
         variant             uint32 1
      )
      dict entry(
         string "DeviceMountPaths"
         variant             array [
            ]
      )
      dict entry(
         string "DevicePresentationHide"
         variant             boolean false
      )
      dict entry(
         string "DeviceSize"
         variant             uint64 14954790912
      )
      dict entry(
         string "DriveIsRotational"
         variant             boolean false
      )
      dict entry(
         string "DriveModel"
         variant             string "SD_MMC_MS_PRO"
      )
      dict entry(
         string "IdLabel"
         variant             string "SD_16Gb_ext4"
      )
      dict entry(
         string "IdUuid"
         variant             string "95EEC279DD3C5C38ABE8234C7CDF8F5F3B12B445"
      )
      dict entry(
         string "NativePath"
         variant             string "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-7/1-7:1.0/host39/target39:0:0/39:0:0:0/block/sdc/sdc1"
      )
      dict entry(
         string "ProductId"
         variant             string "0177"
      )
      dict entry(
         string "ProductName"
         variant             string ""
      )
      dict entry(
         string "VendorId"
         variant             string "0bda"
      )
      dict entry(
         string "VendorName"
         variant             string "Realtek Semiconductor Corp."
      )
   ]

If someone has another idea or howto get a udev rule to work for a partition that gets executed...

Removing the ID_FS_TYPE check from the udev rule does the trick Thanks drinkcat ;)
Although it is strange, because the env. variable ID_FS_TYPE I can use in the script with no problems and has the right value.
I have now the following working udev rule.

ACTION=="add", SUBSYSTEM=="block", KERNEL=="sd??", RUN+="/usr/local/bin/mountextfs %k"

The file system type check must be done in the script file. When pressing the eject button in the Files app the ext4 partition gets unmounted. Only to clean up we need to unmount the loop device with umount -d /dev/loopx -d is needed to free the loop device, if not used you will have problems on the next use of the same loop device. Second is removing the directory in /media/removable.
Just looking for a way on how to trigger it after the eject button in the Files app is pressed. On dbus-monitor there were no events to be seen.

Created some scripts to test mounting/unmounting ext2/3/4 usb drive and sd cards.

divx118@1d1fb12

mount-extfs will setup the udev rule with the following command

sudo mount-extfs setup

unmount-loop will take care of the loop unmounts.
It will check /proc/mounts if there is a leftover loop device mounted, unmounts it and deletes the directory in /media/removable if it is empty.
I still didn't find another way then watching /proc/mounts to trigger unmounting the loop device.

With these scripts I did some testing when suspending and waking up. When I unmount the drive before suspending it gets nicely mounted again on wakeup. If I let it suspend without unmounting first it will be still mounted when waking up. It behaves well so far.

Just need to format a usb drive with some multiple mixed filesystem partitions on it. Only the SD-card I tested with had a mixed partition with vfat and ext4 mounting worked well as expected.

Something else to think about. What permissions should we use to mount the drives. I guess by default noexec . BTW we could add some mount options string when we call the script to allow people to create there own udev rule for example when they want the drive mounted as exec.

Edit: Pushed the scripts to my git repo changed the formatting so it is better readable also added default mount options.

A little update, mounting a usb stick with 4 partitions and a SD card with 2 works now with the script.
Using some trickery with a sleep timer to prevent assigning the same loop device to multiple partitions.
I need to invest some time to make this better. Depending on a timer is not what I want. git repo

How about a lockfile?

@dnschneid That could maybe be an option, however I am still afraid of timing issues.
I took now a different approach and watch for a disk to be added, then find and mount the partitions in the script. As it is now and as far as I tested it works very good. No timing issues anymore.
What I noticed is that when using spaces in label names or when using different partitions with the same label name (doesn't matter if they are on different disks) the mounting fails. This I solved for now by replacing spaces with an "_" and creating a unique label name by prefixing it with the last 2 characters of the device name. For example /dev/sdb1 with label name "Ext4 64GB" will show up as "b1.Ext4_64GB".
Also I still can't get rid of the message "Whoa, there. Be careful" when ejecting the disk although everything is unmounted.
I see if I can resolve these 2 issues. Also need to add some actions if for example mount or unmount fails.

If someone wants to test or has some feedback on the code:
Usage is simple, copy the 2 scripts in /usr/local/bin then sudo mount-extfs setup to setup the udev rule and you are good to go.
For mounting the disks mount-extfs
Taking care of unmounting loop devices unmount-loop

I am not a shell master (instead JAPH) but tried to figure this out briefly
and then gave up and did something different because the automount system
of ChromeOS seems to change slightly on eveyr release. (I'm on the dev
channel so maybe it's not as much of a problem for those on formal or beta)

What I did instead was completely redo my chroot on the internal SSD, and
then installed the Android stuff and the NetBSD ISO torrents I seed etc,
but then hit another problem. That 16GB runs out of room very quickly
because of the aggro caching strategy used- and then when things start
filling files on that 16GB internal drive start getting deleted. That is
... ridiculous and equivalent to how 2.4 Linux would just start randomly
killing processes when it ran out of VM. I would have thought that Mother-G
engineers would have learned from that horrific past, but apparently not.
What I would have liked to do was disable the joint cross mount of the
Downloads folder from the chroot and instead point it at my large SD card
for bulk storage. I thought I found where to do that and commented out the
code but it refused to "just work". Is there some sort of easy option I'm
missing here or is it more complicated than I think it is, due to
ChromeOS's per-instance shadow stuff?

The specific code I'm talking about is in the enter-chroot script, and I
disabled this portion.- as stated, it didn't work and I'm not sure why:

Bind-mount ~/Downloads if we're logged in as a user

localdownloads='/home/chronos/user/Downloads'
if [ -z "$NOLOGIN" -a -n "$CHROOTHOME" -a -d "$localdownloads" ]; then
bindmount "$localdownloads" "$CHROOTHOME/Downloads" exec
fi

IMO this is something that definitely needs to be addressed, besides
my usage scenario if you have to do something like store CA keys you
want them on removable media, which already got broken by the "we
don't care about external ext2/3/4" thing, and is also needed to avoid
the "my dog hit the spacebar while my Chromebook was booting and it
autowiped itself and my private keys no longer exist" scenario.

Namaste-

-SS

NUNQUAM NON PARATUS ☤ INCITATUS ÆTERNUS ヽ(´◇｀)ノ

V/T: 00.1.408.718.6290

Skype: Scott Solmonson

On Tue, Aug 19, 2014 at 9:17 AM, divx118 notifications@github.com wrote:

@dnschneid https://github.com/dnschneid That could maybe be an option,
however I am still afraid of timing issues.

I took now a different approach and watch for a disk to be added, then
find and mount the partitions in the script. As it is now and as far as I
tested it works very good. No timing issues anymore.

What I noticed is that when using spaces in label names or when using
different partitions with the same label name (doesn't matter if they are
on different disks) the mounting fails. This I solved for now by replacing
spaces with an "_" and creating a unique label name by prefixing it with
the last 2 characters of the device name. For example /dev/sdb1 with label
name "Ext4 64GB" will show up as "b1.Ext4_64GB".

Also I still can't get rid of the message "Whoa, there. Be careful" when
ejecting the disk although everything is unmounted.

I see if I can resolve these 2 issues. Also need to add some actions if
for example mount or unmount fails.

If someone wants to test or has some feedback on the code:
Usage is simple, copy the 2 scripts in /usr/local/bin then sudo
mount-extfs setup to setup the udev rule and you are good to go.
For mounting the disks mount-extfs
https://github.com/divx118/crouton/blob/mountextfs/host-bin/mount-extfs
Taking care of unmounting loop devices unmount-loop
https://github.com/divx118/crouton/blob/mountextfs/host-bin/unmount-loop

—
Reply to this email directly or view it on GitHub
#954 (comment).

I was about to update the scripts to match the unwritten rules for crouton scripts.
I have a question about that.
How should we integrate this into crouton, so we can support installing chroots on external devices?
It is a script that IMO needs to live always in /usr/local/bin on your SSD. You need to run it on every reboot to setup the UDEV rule. So before you can use your external device.
We could also just leave it for now and I could make a pull request just for the two scripts once adjusted. The user will then be able to setup the UDEV rule with for example sudo mount-extfs -s -m "mount options (optional)"
He needs of course crouton installed on his local ssd or mount his external device manually on the command line first.
IMO this should be great for extensive testing without interfering with crouton. After that we can start integrating it into crouton step by step.

Any ideas are welcome.

Sorry to potentially turn things on its head, but here's a thought:

As far as crouton is concerned, it doesn't need to be able to automount ext media. All it needs is the ability to launch a chroot via scripts only on the removable media, with the chroot stored on removable media in a filesystem that is Linux-safe, without touching the device's internal storage. After that, you can set up auto-mounting of ext filesystems for other purposes, but it can be independent from crouton.

Here's what I'm thinking: for external, non-ext media, we create a new type of chroot mount: an expanding image. I think everything can be implemented in mount-chroot/unmount-chroot. Use 2 GB chunks and this technique to create a multi-part loop mount with ext4 on it. Run a monitor script that waits for there to be less than 1 GB free, then allocates and adds a new chunk to the dm table and live-grows the ext mount. Add a parameter to unmount-chroot that runs a compaction on the chroot if there's >3GB free space.

This fixes a few problems:

1. ext doesn't automount anymore.
2. fat32/ntfs cause strange issues when creating a chroot on them.
3. Even with the automount script, running crouton on external media is far harder and more complex than it needs to be.

Your thoughts?

@dnschneid Yes, always wondered why crouton didn't use image files especially with the problems you get on fat32/ntfs.
Well let me think about it for a bit, maybe there are some other options to expand / shrink the image. Although dmsetup seems nice.

One possible option is to use sparse files, and create a large FS (same size as the USB stick), that takes no space on the actual physical device
With ext4 (loop) on ext4 (physical device), if you run fstrim on the loop device, unallocated blocks are freed up on the parent FS.
NTFS also supports sparse files so that may work in theory. FAT32 won't work unfortunately.

Another thought. Has anybody tried to create an encrypted chroot on FAT32? ecryptfs might actually be a good abstraction layer, with no space wasted...

Yeah, it needs to work on all external filesystems. Does ecryptfs encode UNIX permissions in the file? That could indeed be an extremely good solution (even if we make it so that an "unencrypted" chroot uses a null encryption key), assuming the filename encryption doesn't result in names that are too long for fat32.

what about creating a wubi style root.disk on an ntfs formatted usb device and mounting there?

advantages are that it is a single file, supports linux permissions, and even the creation of partitions within the image file, and can be file encrypted, or full device encrypted, supports journaling.

disadvantages are it can't easily be resized, probably won't support any hibernation (a good thing, IMHO), not sure if chromebooks or macs can reformat usb devices to ntfs easily. FAT32/vfat might work, but then 4gb limits for / , /home , etc.

ecryptfs does not work unfortunately, permissions and symlinks rely on the underlying FS...

qcow images are designed for this, but that'd need some fuse driver, so, probably not great...

Oh well, sounds like ecryptfs is out.

@tedm thanks, but the approach I suggested has none of those downsides. And whatever we do, we want to keep it as similar to what happens normally (i.e., no partitions to deal with) to avoid unnecessary complexity interacting with the rest of crouton.

@divx118 I have both a usb external hard drive and SD card with ext4 partitions. The SD card has my chroots. I'm having trouble getting the mount-extfs script to mount either of them. I can't figure out why it's not working. It seems that the dbus-send line isn't mounting. I'm on ChromeOS Beta. If there's anything else I can try, please let me know.

Here's the content of the log file for the external drive (sdb):

    + APPLICATION=mount-extfs
    +++ readlink -f /usr/local/bin/mount-extfs
    ++ dirname /usr/local/bin/mount-extfs
    + BINDIR=/usr/local/bin
    + MOUNT_OPTIONS=rw,dirsync,nosuid,nodev,noexec,relatime
    + USAGE='mount-extfs [options] name [...]
    Mounts one or more ext2/3/4 USB devices or SD-cards on top of a loop device
    which will then show up in the chromeos Files app.
    Options:
    -d DEVICE        Kernel device name for example sdb ,sdc ,sdd etc.
                     Normally passed by the UDEV rule.
    -m MOUNT_OPTIONS Mount options for the partitions. Default: rw,dirsync,nosuid,nodev,noexec,relatime\.
    -s               Setup the UDEV rule.'
    + SETUP=0
    + getopts d:m:s f
    + case "$f" in
    + KERNEL_DEVNAME=sdb
    + getopts d:m:s f
    + '[' 0 -eq 0 ']'
    + mount_extfs
    + mountextfs_tmp=/tmp/mount-extfs/
    + mkdir -p /tmp/mount-extfs/
    + read line
    + blkid /dev/sdb1
    ++ echo /dev/sdb1: 'UUID="e2fe2bb5-d985-4ef1-a398-5b68344298ab"' 'TYPE="ext4"' 'PARTUUID="000dbec4-01"'
    ++ cut -d : -f 1
    + dev_part=/dev/sdb1
    ++ echo /dev/sdb1: 'UUID="e2fe2bb5-d985-4ef1-a398-5b68344298ab"' 'TYPE="ext4"' 'PARTUUID="000dbec4-01"'
    ++ cut -d : -f 2-
    ++ sed 's/\" /\"\;/g'
    + part_prop=' UUID="e2fe2bb5-d985-4ef1-a398-5b68344298ab";TYPE="ext4";PARTUUID="000dbec4-01"'
    + unset LABEL TYPE PARTUUID
    + eval 'UUID="e2fe2bb5-d985-4ef1-a398-5b68344298ab";TYPE="ext4";PARTUUID="000dbec4-01"'
    ++ UUID=e2fe2bb5-d985-4ef1-a398-5b68344298ab
    ++ TYPE=ext4
    ++ PARTUUID=000dbec4-01
    + '[' x '!=' xext4 ']'
    + '[' -z '' ']'
    + LABEL=000dbec4-01
    + rm -f /tmp/mount-extfs/sdb1
    + mkfs.vfat -C /tmp/mount-extfs/sdb1 34 -n 000dbec4-01
mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows
    ++ losetup -f --show /tmp/mount-extfs/sdb1
    + loop_device=/dev/loop15
    + echo /dev/loop15,/dev/sdb1
    + dbus-send --print-reply --system --dest=org.chromium.CrosDisks /org/chromium/CrosDisks org.chromium.CrosDisks.Mount string:/dev/loop15 string: array:string:ro
    + read line
    + j=0
    ++ cat /tmp/mount-extfs/sdb
    + '[' x/dev/loop15,/dev/sdb1 '!=' x -a 0 -lt 6 ']'
    ++ cat /tmp/mount-extfs/sdb
    + for line in '`cat $mountextfs_tmp$KERNEL_DEVNAME`'
    ++ cut -d , -f 1
    ++ echo /dev/loop15,/dev/sdb1
    + loop_device=/dev/loop15
    ++ cut -d , -f 2
    ++ echo /dev/loop15,/dev/sdb1
    + dev_part=/dev/sdb1
    ++ cut -d ' ' -f 2
    ++ sed 's/\\040/ /g'
    ++ grep -v /run/crouton/mnt/stateful_partition
    ++ cat /proc/mounts
    ++ grep /dev/loop15
    + mount_point=
    + mount /dev/sdb1 '' -o rw,dirsync,nosuid,nodev,noexec,relatime
    mount: mount point  does not exist
    + continue
    + j=1
    + sleep 1
    ...repeat the above steps for the loop 5 times...
    ++ cat /tmp/mount-extfs/sdb
    + '[' x/dev/loop15,/dev/sdb1 '!=' x -a 6 -lt 6 ']'
    + '[' -f /tmp/mount-extfs/sdb ']'
    + rm /tmp/mount-extfs/sdb
    ++ ps -aux
    ++ grep -v grep
    ++ grep unmount-loop
    + '[' x = x ']'
    + exit 0
    + /usr/local/bin/unmount-loop

Yes, you are probably right. It seems the file app doesn't wan't to mount the loop device. I had this before sometimes when I created a udev rule that triggers on partitions, but since I switched to scan the partitions in the script it just works.
Which chromebook device do you have?
You can use dbus-monitor --system --monitor 'interface=org.chromium.CrosDisks' to see what happens with the dbus-send.
I also noticed a bug in the code. When mount_point is empty it should retry atleast 5 times, to give the file app some time to mount the loop device. It could be that this is the issue. I am going to fix that. Edit missed your comment so I thought it didn't loop.
I also need to add some code to free up the loop devices when this sort of thing happens. I see you are already using loop device 15. Easiest way to free your loop devices again is a restart of your chromebook.

I have an Acer C710-2833 (PARROT SICKLEBILL A-D 1328) with 10GB of RAM. I
hadn't restarted, so I gave that a try...unsuccessfully. Since my chroots
are on the SD card, that's what I'd like to get mounted. I tried to break
down your script so I could just mount it manually, but it also didn't work
so well. I appreciate your help with this.

Here's what happens when I monitor dbus-send:

chronos@localhost / $ sudo dbus-monitor --system --monitor
'interface=org.chromium.CrosDisks'
signal sender=org.freedesktop.DBus -> dest=:1.41 serial=2
path=/org/freedesktop/DBus; interface=org.freedesktop.DBus;
member=NameAcquired
string ":1.41"
signal sender=:1.17 -> dest=(null destination) serial=41
path=/org/chromium/CrosDisks; interface=org.chromium.CrosDisks;
member=DeviceAdded
string "/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.1/mmc_host/mmc0/mmc0:3b9a"
signal sender=:1.17 -> dest=(null destination) serial=42
path=/org/chromium/CrosDisks; interface=org.chromium.CrosDisks;
member=DiskAdded
string "/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.1/mmc_host/mmc0/mmc0:3b9a/block/mmcblk0"
signal sender=:1.17 -> dest=(null destination) serial=44
path=/org/chromium/CrosDisks; interface=org.chromium.CrosDisks;
member=DiskAdded
string "/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.1/mmc_host/mmc0/mmc0:3b9a/block/mmcblk0/mmcblk0p1"
signal sender=:1.17 -> dest=(null destination) serial=46
path=/org/chromium/CrosDisks; interface=org.chromium.CrosDisks;
member=MountCompleted
uint32 102
string "/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.1/mmc_host/mmc0/mmc0:3b9a/block/mmcblk0/mmcblk0p1"
uint32 1
string "/media/removable/SD Card"

I then get the "Sorry, your external device is not supported at this
time" message.

Thanks,
Mike

On Wed, Sep 10, 2014 at 11:46 AM, Maurice van Kruchten <
notifications@github.com> wrote:

Yes, you are probably right. It seems the file app doesn't wan't to mount
the loop device. I had this before sometimes when I created a udev rule
that triggers on partitions, but since I switched to scan the partitions in
the script it just works.
Which chromebook device do you have?

You can use dbus-monitor --system --monitor
'interface=org.chromium.CrosDisks' to see what happens with the dbus-send.
I also noticed a bug in the code. When mount_point is empty it should
retry atleast 5 times, to give the file app some time to mount the loop
device. It could be that this is the issue. I am going to fix that.
I also need to add some code to free up the loop devices when this sort of
thing happens. I see you are already using loop device 15. Easiest way to
free your loop devices again is a restart of your chromebook.

—
Reply to this email directly or view it on GitHub
#954 (comment).

@mfbenson
To mount manually in the crosh shell you can do the following:
Plug in your usb device.
Find your device something like /dev/sdb1:

$ dmesg |grep /dev/

Create a mount dir:

$ sudo mkdir /media/removable/myusb

Mount the device on the directory just created. Probably /dev/sdb1 in your case:

$ sudo mount /dev/sdb1 /media/removable/myusb

Now your device is mounted, but won't show up in the Files app. However you can use it for starting your chroots. The mount command above will mount with default options, so you also will have exec rights.
If you remove the disk, then be sure to safely unmount it:

sudo umount /media/removable/myusb

I see if I can reproduce your problems with the script.

Thanks for the steps. I was able to get those to work manually, so I'll use
them in the interim.

Thanks,
Mike

On Thu, Sep 11, 2014 at 11:35 AM, Maurice van Kruchten <
notifications@github.com> wrote:

To mount manually in the cross shell you can do the following:
Plug in your usb device.

Find your device something like /dev/sdb1:

$ dmesg |grep /dev/

Create a mount dir:

$ sudo mkdir /media/removable/myusb

Mount the device on the directory just created. Probably /dev/sdb1 in your
case:

$ sudo mount /dev/sdb1 /media/removable/myusb

Now your device is mounted, but won't show up in the Files app. However
you can use it for starting your chroots. The mount command above will
mount with default options, so you also will have exec rights.
If you remove the disk, then be sure to safely unmount it:

sudo umount /media/removable/myusb

I see if I can reproduce your problems with the script.

—
Reply to this email directly or view it on GitHub
#954 (comment).

@dnschneid I played around a bit with dmsetup. Although it works, the following drawbacks make it hard to use.
AFAIK you can't expand the virtual disk on the fly. You will need to unmount it, add the new chunk and use resize2fs to update the size. Also creating a new chunk on a fat partition will take a lot of time. Depends on the write speed of your usb or sd-card, you will need to write the complete 2Gb chunk.
A sparse file on ntfs would be better, but then you will need to detect the fstype of the directory you passed to the crouton script or enter-chroot. Not so easy in the first glance I took at it, it won't be a one liner. Also as mentioned before not working on fat.
I am still thinking about other ways ... I don't think we should add multiple possibilities for setting up a chroot on external media (makes it all to complicated). IMO we should add one method that works without much hassle on all filesystems, or just support one filesystem.

Totally agree. There should be one solution for removable media that works automagically, regardless of filesystem.

I did some test with mount.posixovl on a usb drive with a fat partition. It works but too slow. I almost setup a working chroot, but lost patience when it was running for a few hours. Using the binary from the package fuse-posixovl on trusty works on chromeos.
More info http://manpages.ubuntu.com/manpages/trusty/man1/mount.posixovl.1.html and the project on sourceforge http://sourceforge.net/projects/posixovl/
Compiled version of the source on sourceforge, also works, but will give the following warning fuse: warning: library too old, some operations may not not work (compiled it in a trusty chroot)
I wonder why it is so slow. a simple ls -al of the mount directory already takes a second or so with just a couple of directories and a few files.
Well it was worth a shot and could come in handy for something else now we know it works.

Thanks for trying that out. It also looks like posixovl doesn't help with case insensitivity, so it's a bit limited as insulation from the card filesystem.

FYI, I'm using the dmsetup thing on a FAT32 USB stick: https://gist.github.com/drinkcat/8209d412a25a1a0f79f6 . It does not work awesomely well as the USB stick gets unmounted on suspend (no persist: crouton needs to be smarter about the flag...)

@dnschneid Yes you are right, I overlooked the case insensitive.
@drinkcat Ok good to know. didn't test that yet.

FYI, ext4 is coming back: https://code.google.com/p/chromium/issues/detail?id=315401#c124

This was fun, but not necessary anymore, now that ext4 support is back in Chromium OS.

wow