Crouton: Cyclical filesystem mount when running chroot from removable USB device

Created on 18 Feb 2015 · 4Comments · Source: dnschneid/crouton

System:

HP Chromebook 11 (ARM)

Preconditions:

Create crouton with:

sudo sh crouton -p /media/removable/MyDrive/ -r trusty -t xfce

where MyDrive is a removable USB device.

Reproduction steps:

sudo sh -e /media/removable/MyDrive/startxfce4
...
leave the chroot (log off)
attempt to eject drive in "Files" app - unsuccessful
attempt to unmount the drive via shell

Expected result:

Drive unmounts

Actual result:

From Files app, ChromeOS shows dialog stating that you need to wait for a drive operation to finish
From shell, umount says the device is busy, indicating this path:

/run/crouton/media/removable/MyDrive/chroots/trusty/var/host/media/removable/MyDrive/chroots/trusty/var/host/media/removable/MyDrive

is still in use. As a result, the drive cannot safely be removed from the system, and removing it unsafely causes filesystem damage that makes the chroot inoperable. Note the beautiful filesystem cycle.

Workaround

Mount the drive in a non-default location that is not mounted automatically in the chroot.

Just thought I'd report this, its an interesting issue with USB drives, but can be avoided pretty easily.

bug

Source

kiorpesc

Most helpful comment

Weird, I'm not sure why the mountpoints are reflecting back to /media...that's the whole point of the /run/crouton shadow directory. Thanks for raising this.

dnschneid on 18 Feb 2015

👍2

All 4 comments

Weird, I'm not sure why the mountpoints are reflecting back to /media...that's the whole point of the /run/crouton shadow directory. Thanks for raising this.

dnschneid on 18 Feb 2015

👍2

I think /media is the default mount for /dev/[removable devices] and like power management and networking, the host OS can tell if something is plugged in or removed, but since the chroot can as well, or even shut down, the host thinks it may not be in a safe state to eject.

Can unmounting the chroot force an eject of /media devices? Also, how will usb and sdcards work with multiple chrome users logged in at the same time, with first desktop user also having a chroot? Who is owner, and what are perms?

tedm on 18 Feb 2015

I am having the same problem with latest crouton on Acer C720:

crouton: version 1-20151013174138~master:488c9e21

The temporary solution (as suggested) is to rename the directory /media/removable/[card]/chroots
to something else, for example:
/media/removable/kingusb3/chroots_new

and then launch the chroot with:

sudo sh /media/removable/kingusb3/bin/enter-chroot -c /media/removable/kingusb3/chroots_new -n trusty

However this has the drawback that when I try to update the chroot with the command:

sudo sh ~/Downloads/crouton -u -n trusty -p /media/removable/kingusb3/chroots-new/

the script crouton looks always for a "standard" chroots directory:

/media/removable/kingusb3/chroots-new/chroots

and exits with an error:

/media/removable/kingusb3/chroots-new/chroots/trusty does not exist; cannot update.

I think it would be very useful to fix this cyclical mounting problem

pippo0312 on 19 Oct 2015

I encountered this issue with the latest version of Crouton with storage path "/media/removable/PNY64". The workaround prescribed by kiorpesc was effective, and the shell transcript below shows the steps I took.

chronos@localhost /usr/local/bin $ sudo sh ./crouton -V
Downloading latest crouton installer...
######################################################################## 100.0%
crouton: version 1-20170315143304~master:95589555

chronos@localhost /usr/local/bin $ sudo mkdir -pv /var/run/mount/PNY64
mkdir: created directory ‘/var/run/mount/PNY64’

chronos@localhost /usr/local/bin $ sudo mount -v /dev/sdc2 /var/run/mount/PNY64
mount: /dev/sdc2 mounted on /run/mount/PNY64.

chronos@localhost /usr/local/bin $ cd /var/run/mount/PNY64/bin/

chronos@localhost /var/run/mount/PNY64/bin $ sudo ./startxfce