Crouton: Suspend/resume breaks chroot when running off external SDC card

[stsquad]

On my Chromebook Pixel it looks like a suspend/resume cycle leaves the chroot in an odd state.

04:14 alex@localhost/x86_64 [~] >echo "before suspend"
before suspend
04:14 alex@localhost/x86_64 [~] >echo "after suspend"
after suspend
-su: history: /home/alex/.bash_history: cannot create: Input/output error
11:15 alex@localhost/x86_64 [~] >

Looking at the dmesg it looks like there are ext4 errors on the SDC card which forces a re-mount breaking the chroot (or possibly the SDC is just unmounted as part of the suspend cycle).

ss Generic STORAGE DEVICE 0207 PQ: 0 ANSI: 0
[15015.434666] sd 12:0:0:0: [sdf] 125827072 512-byte logical blocks: (64.4 GB/59.9 GiB)
[15015.435935] sd 12:0:0:0: [sdf] Write Protect is off
[15015.435946] sd 12:0:0:0: [sdf] Mode Sense: 0b 00 00 08
[15015.437146] sd 12:0:0:0: [sdf] No Caching mode page present
[15015.437156] sd 12:0:0:0: [sdf] Assuming drive cache: write through
[15015.441164] sd 12:0:0:0: [sdf] No Caching mode page present
[15015.441174] sd 12:0:0:0: [sdf] Assuming drive cache: write through
[15015.448779] sdf: sdf1
[15015.452132] sd 12:0:0:0: [sdf] No Caching mode page present
[15015.452142] sd 12:0:0:0: [sdf] Assuming drive cache: write through
[15015.452151] sd 12:0:0:0: [sdf] Attached SCSI removable disk
[15016.731447] EXT4-fs (sdf1): recovery complete
[15016.736860] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts:
[15024.898066] wlan0: no IPv6 routers present
[15029.857907] EXT4-fs error (device sde1): ext4_find_entry:935: inode #3020490: comm bash: reading directory lblock 0
[15029.857941] EXT4-fs error (device sde1): ext4_read_inode_bitmap:171: comm bash: Cannot read inode bitmap - block_group = 368, inode_bitma
p = 12058640
[15029.857954] EXT4-fs error (device sde1) in ext4_new_inode:895: IO failure
[15029.857993] EXT4-fs error (device sde1): ext4_find_entry:935: inode #2884078: comm bash: reading directory lblock 0
[15029.858071] EXT4-fs error (device sde1): ext4_find_entry:935: inode #2883586: comm bash: reading directory lblock 0
[15029.858090] EXT4-fs error (device sde1): ext4_find_entry:935: inode #2883586: comm bash: reading directory lblock 0
[15035.044833] Aborting journal on device sde1-8.
[15035.044845] Buffer I/O error on device sde1, logical block 7372800
[15035.044851] lost page write due to I/O error on sde1
[15035.044857] JBD2: Error -5 detected when updating journal superblock for sde1-8.
[15092.013341] EXT4-fs error (device sde1): ext4_find_entry:935: inode #3020490: comm bash: reading directory lblock 0
[15092.013363] EXT4-fs error (device sde1): ext4_find_entry:935: inode #2884078: comm bash: reading directory lblock 0
[15092.013395] EXT4-fs error (device sde1): ext4_find_entry:935: inode #2883587: comm bash: reading directory lblock 0
[15092.013410] EXT4-fs error (device sde1): ext4_find_entry:935: inode #2884078: comm bash: reading directory lblock 0
[15092.014147] EXT4-fs error (device sde1): ext4_journal_start_sb:328: Detected aborted journal
[15092.014160] EXT4-fs (sde1): Remounting filesystem read-only
[15094.359077] EXT4-fs error (device sde1): ext4_find_entry:935: inode #3020490: comm bash: reading directory lblock 0

[stsquad]

Looking at enter-chroot I see it does attempt to prevent powerd from persisting usb mounts. I wonder if it's the same sort of thing?

[dnschneid]

Yeah, enter-chroot tries to prevent powerd from _disabling_ usb mount persistence, but it only seems to work part of the time for me.

Is it failing if you let the system idle suspend, or when you close the lid, or both?

[stsquad]

Both as far as I can tell - certainly the file-browser keeps popping up after both. Looking at the sed statement I don't think anything is being patched now, possibly the powerd script has been updated?

[stsquad]

@dnschneid yeah I reckon this upstream commit broke the crouton hack:

http://git.chromium.org/gitweb/?p=chromiumos/platform/power_manager.git;a=commitdiff;h=0007a546853a529064772b1b96bd9164dece8c46

[dnschneid]

Cool, then that should be fixable by adding the line to the script in a reasonable location.

[stsquad]

Even simpler I think we can just get away with enabling USB persist as we enter the chroot and skip the copy/mount powerd stuff as it's not going to attempt to turn it off anyway. I'll have a play.

[dnschneid]

Good call. We just need to make sure that patch has landed in the stable channel for all platforms before removing the copy/mount hack stuff.

[dnschneid]

Yep, looks like that patch has landed in stable.

[dnschneid]

This fix may have stopped working.

[stsquad]

I've noticed file-manger popping up (a sign the remount has been detected). I've yet to notice a crouton session getting killed.

[mark0978]

On my Acer C710, its happening all the time right now. The only way my chroot lives across sleep/resume is on the internal storage. This effectively renders the SD Card useless.

[phoenix00a]

So, I've got to forget about using my SD Card and install crouton internally? Yikes. I've only got 16GB on my HP Pavilion 14 Chromebook..

[mark0978]

Yea, it sucks Same on the Acert C710

[dnschneid]

Yeah, major suck. I've looked through kconfig commit logs to see if anything other than the default persistence setting was changed, but I didn't find much, assuming this isn't buggy. I'll need to ask one of the kernel guys what's stopping USB persist from working.

Of course, I've done this checking without actually confirming that the crouton code is still doing what it's supposed to be doing. If anyone wants to check it before me, make sure the echo 1 line in enter-chroot is getting called, and the echo 0 line in unmount-chroot isn't being called at an incorrect time.

[dnschneid]

Try the latest crouton; I restructured the mount system to fix another issue, and I think it might have resolved this as well.

[dnschneid]

Hmm, it looks like it's persisting, but there are journal errors upon resume so it gets remounted RO...unless that's just my SD card.

[dnschneid]

Okay, something's wrong with superblock access which is causing the device to be error-mounted RO when replaying the journal. I'll investigate what is causing this in Chromium OS. In the meantime, you have two options:

1. Set the partition to ignore errors and mount anyway. This is such a terrible idea that I'm not even going to post the command here.
2. Disable journaling. This significantly increases the risk of data loss when things go poorly, so it's still a pretty bad idea. sudo umount /dev/sdb1 && sudo tune2fs -O ^has_journal /dev/sdb1 and then unplug and re-plug the SD card. You can re-enable journaling at a future date.

[dnschneid]

Relevant bug. Star it if you're affected.

[tocker]

Is it possible to manually remount the sdcard as RW?
I tried a few variations of mount but none worked.

[mark0978]

Yes you can remount it. But the suspend/remount destroys any hope of
recovery from sleep.
On Jan 28, 2014 8:59 AM, "tocker" [email protected] wrote:

Is it possible to manually remount the sdcard as RW?
I tried a few variations of mount but none worked.

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

[NullVoxPopuli]

I am experiencing this issue on the HP11.

Other issues I've noticed that I think may be related:

• When the USB drive does remount, I can't re-enter chroot. It says that the chroot is invalid, and tries to kill some processes.
• I cannot get back in to chroot until I have restarted my computer.

my uname -a from chrome OS:
Linux localhost 3.4.0 #1 SMP Tue Feb 18 23:28:43 PST 2014 armv7l ARMv7 Processor rev 4 (v7l) SAMSUNG EXYNOS5 (Flattened Device Tree) GNU/Linux

[dnschneid]

The relevant crbug has a request for someone to reproduce and provide an event log. Any takers?

[scosol]

I will try to reproduce after I can install my own chroot again: https://github.com/dnschneid/crouton/issues/711

[dnschneid]

Thanks for volunteering; #712 should be merged tomorrow. Autotest went down while I was away, and I can't merge without running them through the tests.

[scosol]

Is this still relevant? Reading through the months-long CR comments I can't
tell exactly what the next step is-

Upon Suspend, everything should sync and flush, because even in a
maintained-memory state there's no way of knowing if/when things will come
back on, and the FS needs to be clean and consistent outside of that- the
only caveat to that model is if there's a persistent heavy I/O job that
makes it not actually ever Suspend. Thankfully in Chromeland we don't have
to deal with HW RAID devices that like to lie about their state.
I'm re-croutoning my USB stick right now and can then test, but is there
anything else that would be useful beyond dmesg output?

-SS

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

V/T: 00.1.408.718.6290

Skype: Scott Solmonson

On Thu, Mar 27, 2014 at 2:57 PM, David Schneider
[email protected]:

Thanks for volunteering; #712https://github.com/dnschneid/crouton/pull/712should be merged tomorrow. Autotest went down while I was away, and I can't
merge without running them through the tests.

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

[mark0978]

I think it is still relevant. You expect the machine with a SD card in use to behave the same as the internal drive behaves. I can suspend and resume into my crouton with no issue, unless that crouton is on an external SD card. There is NO good reason for this behavior. My guess is, it was too hard to deal with a suspend resume on an external device and someone took the shortcut of unmount/remount, something they DO NOT DO with the internal drive. So, yes, it is relevant, it impacts my ability to use a device that has 16GB internally and 32GB externally.

[tedm]

Since the chroot can't run independent of the Chromium OS host, I can't understand why a chroot running under the Chromium OS host should have independent power, input, display, i/o settings, if it risked the stability of the host.

xscreensaver, for example, causes all kinds of problems, trying to put the chroot asleep or awake, without knowing the state of the host.

[DennisLfromGA]

Not a total solution by any means but you can uninstall xscreensaver, I've
had to do it myself on a chroot with multiple DE's, each having their own
screensaver.

On Mon, Mar 31, 2014 at 9:21 PM, tedm [email protected] wrote:

Since the chroot can't run independent of the Chromium OS host, I can't
understand why a chroot running under the Chromium OS host should have
independent power, input, display, i/o settings, if it risked the stability
of the host.

xscreensaver, for example, causes all kinds of problems, trying to put the
chroot asleep or awake, without knowing the state of the host.

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

_DennyL@GMail_

[mark0978]

Maybe the problem doesn't belong to Crouton, but I bet the guys doing Crouton know the guys doing ChromeOS a lot better than the ChromeOS users do. Maybe this kind of feedback needs to go upstream. It does impact the ability to use ChromeOS and Crouton.

Without Crouton, I have no need for ChromeOS, I'd just use android. Crouton gives me a workable solution for travel in a form factor I'm willing to risk losing/having destroyed. Not going to take my $2K+ laptop places I would take my $250 Chromebook.

[scosol]

Let's remember that by definition, crouton is userland, which both provides
the benefits and the deficiencies of relying upon the G-approved Kernel.
This is Linux on Desktop finally actually playing a hand, and I'm here to
make sure it finally sticks.

TedM- my suggestions around an rc-local kind of mindscape aren't meant to
disable the competency of the kernel at all; instead it's more meant to
achieve a user-level "known environment" that can become quickly familiar,
regardless of whatever Mother-G forces on the next update. Your "send it
upstream" sentiment is I think precise- engineers build things according to
their own mind-model, which is often in conflict with the actual userbase
and UI/UX, and we the actual users are here to keep things in check- so how
far upstream do you want to go? Everything and anything can be forked on to
a different path with a few keystrokes and a driven mind, but I sincerely
believe that's not the best course forward for now-

-SS

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

V/T: 00.1.408.718.6290

Skype: Scott Solmonson

On Mon, Mar 31, 2014 at 6:46 PM, Mark Jones [email protected]:

Maybe the problem doesn't belong to Crouton, but I bet the guys doing
Crouton know the guys doing ChromeOS a lot better than the ChromeOS users
do. Maybe this kind of feedback needs to go upstream. It does impact the
ability to use ChromeOS and Crouton.

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

[dnschneid]

I suggest looking at my comment in the crbug and see if you see the same thing upon resume.

[dnschneid]

Here's a quick hack to try (as noted in the crbug): copy /usr/bin/powerd_suspend to /usr/local/bin/powerd_suspend. Edit /usr/local/bin/powerd_suspend to add the following on the line immediately after the call to sync: for m in /media/removable/*; do [ -d "$m" ] && mount -o remount,ro "$m"; done. Add the following after the initctl call: for m in /media/removable/*; do [ -d "$m" ] && mount -o remount,rw "$m"; done.
Finally, in crosh, bind mount over the /usr/bin/powerd_suspend: sudo mount --bind /usr/local/bin/powerd_suspend /usr/bin/powerd_suspend.
Do your suspend and resume and see if things don't break.

[mark0978]

I will give it a try this evening.

[tocker]

David,
I gave your hack a try and so far it seems to work!

** Update ** Nope, still failing...

_(If you need logs, etc. let me know and I'll post it here.)_

Thanks!

[yisheng-on-linux]

How's the progress on this?
I just posted a long list of my experiences at
https://code.google.com/p/chromium/issues/detail?id=208380
outlining what happens when, so I won't repeat here unless asked. I think it's a powerd issue as you can see.
If you can manage the power drain (I can go a day like this so not too bad but does get warm in a bag) do this before starting crouton:
sudo stop powerd
As you will see, the usb drive keeps the drain up even when closed, so you aren't really losing much more than now, but will save all those pesky fs errors...

forgot to mention another side benefit - this disables the power button too, so (at least for me) I don't have to worry about picking it up while open and laying my thumb on the power button and shutting it down while I blink.... for the hundreth time...

[faddah]

@dnschneid -

i have seen the same thing, as recently as today, 11-Oct.2014. i have ubuntu linux running off an sd card (using your -p option/switch in crouton) which i had named "linux." this morning on a reboot, it's now called SD\ Card - and i never renamed it.

i also posted this in the related issue #445.

best,

-- faddah wolf
portland, oregon, u.s.a.
github.com/faddah

[Jackhford]

I don't know if this is relevant to the topic, but I had to do a reinstall. I'm trying to finish the virtualbox setup, but I can't create rc.local in /etc, because I get the filesystem is read-only error. I hope someone has an easy solution.
Thanks

[hsharrison]

I think the only workaround is to reboot ChromeOS, then run sudo stop powerd in crosh to prevent sleep. It's the only thing that's worked for me.

It's too bad, I just "upgraded" to a newer Chromebook from one where you could swap out the SSD for something bigger. I thought I would be fine with the SD card. I was wrong.

[ee7klt]

/usr/bin/powerd_suspend doesn't exist for me. do i just create one and add the hack to it?

[dylanPowers]

Is there a way to stop the system from sleeping without killing the ability to change brightness?

[dnschneid]

If the lid is left open, you can use croutonpowerd -i to inhibit going to sleep. To avoid the lid close, you have to disable the lid action which I believe requires sending a protobuf via dbus to powerd. It may be possible to pregenerate the protobuf data and then send the blob, but I haven't looked into it.

[grobbie]

I was able to get suspend / resume working without having the sd card go readonly on resume.

I moved the chroot user home directory onto the sd card using rsync in order to save space and moved the chroot back onto the ssd.

sudo rsync -aXS --exclude='/*/.gvfs' /home/. /media/removable/<sdcard>/chroot/home/.

I edited the chroot's /etc/passwd and set my home directory to the path on the sd card. I removed the home directory in the chroot and migrated the chroot back to the ssd drive in the chromebook.

NB. I had a problem running IntelliJ from the sd card, since ChromeOS mounts it with noexec. Remounting got rid of it.

sudo mount -o remount,exec /dev/sdb1 /var/host/media/removable/<sdcard>

I then followed the instruction dnschneid gave already:

Add the following after the initctl call: for m in /media/removable/*; do [ -d "$m" ] && mount -o remount,rw "$m"; done.
Finally, in crosh, bind mount over the /usr/bin/powerd_suspend: sudo mount --bind /usr/local/bin/powerd_suspend /usr/bin/powerd_suspend.
Do your suspend and resume and see if things don't break.

Seems to suspend/resume predictably. Certainly not perfect, but since the ChromeOS kernel now prevents usb-persist "in order to save 500ms", no other choice.

[erinzm]

Could I recompile my ChromeOS kernel with usb-persist enabled?

[ee7klt]

hi grobbie, can you please elaborate on "I edited the chroot's /etc/passwd and set my home directory to the path on the sd card. I removed the home directory in the chroot and migrated the chroot back to the ssd drive in the chromebook.". In particular, can you provide sample cod for each stop of the way?
thanks.

[yisheng-on-linux]

I've been running with powerd off so I've been away from this a while, but I went back and tried a few things and the latest update(s) seem to have changed things!

• With the chroot (everything really...) on usb, and keeping powerd running, it seems to sleep fine, no remounting ro, everything happy.
• The 4-finger salute doesn't respond while the screensaver is active in crouton (a good thing if by design to prevent going to chrome and killing it to get in)
• Once I switch back with the 4-finger salute to chrome, the same finger gymnastics won't work in any way to get back to the chroot. HOWEVER, I can ctrl-alt-f2 to get a login, then ctrl-alt-f3 to get to the x session (the chroot session). So, I can make it work, but something's really changed.

I will keep testing, but I did add the following in my own startup script before doing enter-chroot. Testing on another machine without that seems to say it isn't necessary though... I have done none of the ...bin/powerd_suspend changes or moved any files to the internal drive either.

I hope I'm not missing something here.....

added before doing enter-chroot, but may remove it soon:
_for usbp in /sys/bus/usb/devices/*/power/persist
do
if [ -e "$usbp" ]
then
echo 1 > "$usbp"
fi
done_

[erinzm]

@dnschneid How is usb-persist being disabled affecting the MMC/SD card reader?
The SD card reader, to my knowledge, isn't USB-based.

[dnschneid]

@ArchimedesPi depends on the platform. It's USB-based on most Intel platforms. ARM platforms it's usually implemented by an integrated SDIO controller.

[erinzm]

OK, so what's the best way to get around this bug for _SD cards_.
I tried some other solutions, but they all seem to work only on USB sticks.

Any ideas @dnschneid?

On Mon, Jan 12, 2015 at 11:33 AM, David Schneider [email protected]
wrote:

@ArchimedesPi https://github.com/ArchimedesPi depends on the platform.
It's USB-based on most Intel platforms. ARM platforms it's usually
implemented by an integrated SDIO controller.

—
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/288#issuecomment-69609618.

[jjg]

What's the current work-around for this? I read through these comments and the posts on the Chromium bug tracker but it's not clear to me what can be done about it at this point.

When this happens to me (for example, when I close the lid) I get the "Whoa!" warning when I open the lid back up, but worse I can't see the SD Card again until I reboot. My old Chromebook (HP 11, ARM, the one with the recalled power supply) did this but when I opened the lid the flash storage (a USB drive) would come back and could kill off my Crouton terminals and restart them, but on the new machine (Lenovo Thinkpad 11e Yoga Chromebook, Intel) I can't get any removable storage that was plugged in during suspend to come back (SD Card or USB).

For now I'm running Crouton off internal storage and looking into ways I can increase that storage, but ideally I'd be able to go back to running Crouton off removable flash. I can't help but feel like there should be a way to treat an SD Card the same way the internal flash storage is treated during suspend but perhaps it's just a hard reality of how the removable media bus is setup.

Is disabling suspend the only solution at this time?

[jjg]

Looks like there's another bug report that might help resolve this:

https://code.google.com/p/chromium/issues/detail?id=434372

[mer23]

Toshiba Chromebook 2
Sony SDXC 64gb
Before getting my hands on crouton the SD card unmounted on sleep and mounted back when I woke it up.
First time I installed trusty on the internal ssd: the card wasn't being mounted back upon awakening but instead chromeOS threw two warnings: the 'Whoa be careful' one, and another that said the external device couldn't be recognized.

Powerwashed the chromebook, no chroots for a few days, the SD card did mount automatically after it came back from sleep mode.

Downloaded crouton again, but this time I installed the chroot on the SD card using the -p parameter. Now apart from not being able to enter the chroot (which I think has nothing to do with the bug being discussed here) again the SD card is not being mounted after a sleep. Not only it's not being mounted, it doesn't even throw the warnings anymore, the SD card just disappears from the file manager. If I remove the SD card from the slot and put it back nothing happens and when I do sudo mount /dev/mmcblk1p1 to try mounting it manually I get mount: can't find /dev/mmcblk1p1 in /etc/fstab
Since I can't modify my fstab because it's a read only file system, the only thing left to do to regain access to my SD card is reboot the chromebook. Again, in this case I didn't start my chroot not even once, only installing it seems to have caused these issue.

[cefn]

I'm struggling with this issue on an SD card (Toshiba Chromebook 2) when the remount doesn't take after suspend resume. Is this the right bug to track the problem on SD cards, or is the USB case distinctive? Should I file a new bug? What useful data can be gathered for diagnostics on this class of problem?

[nguyenquoc]

I have a solution that works on my HP chromebook. Hopefully others who have the same problem can apply the same or similar solution. I have crouton installed on my sdcard in order conserve the 16 GB internal drive. After applying this solution, I can start up ubuntu, close my lid, open my lid, and ubuntu still works with a writable filesystem.

dnschneid's comment on Apr 2, 2014 helped me arrive at this solution. Basically, I mount the sdcard after resuming. The relevant command is:

mount /dev/sdb1 /media/removable/chrome-32

To automate the process, copy /usr/bin/powerd_suspend to /usr/local/bin/powerd_suspend, edit /usr/local/bin/powerd_suspend with the following:

After [ initctl ], add [ mount /dev/sdb1 /media/removable/chrome-32 ]

Finally bind powerd_suspend: sudo mount --bind /usr/local/bin/powerd_suspend /usr/bin/powerd_suspend

[dnschneid]

@cefn this issue. Intel platforms usually have USB SD card readers.

[dnschneid]

@nguyenquoc unmount works? You're running your chroot from the sdcard? Are you sure that command doesn't silently fail?

[nguyenquoc]

@dnschneid You may be right that unmount silently fails. I removed the unmount from powerd_suspend and the system still works, so it looks like I just needed the mount. I updated my instructions. Yes, I'm running chroot from the sdcard. If I remove the mount, then I get a read only filesystem, so the mount is doing something good.

[mark0978]

That's not working in my book. Apps running at the time the lid closes
aren't going to function when the lid is reopened. MySQL, postgres etc..
don't take to kindly to having the rug yanked out from under them.

On Wed, Mar 25, 2015 at 9:48 PM, nguyenquoc [email protected]
wrote:

@dnschneid https://github.com/dnschneid You may be right that unmount
silently fails. I removed the unmount from powerd_suspend and the system
still works, so it looks like I just needed the mount. I updated my
instructions. Yes, I'm running chroot from the sdcard. If I remove the
mount, then I get a read only filesystem, so the mount is doing something
good.

—
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/288#issuecomment-86309664.

[erinzm]

If you could get it to umount, wouldn't that signal MySQL or Postgres or some other thing like that to stop writing to disk and close file descriptors?

[mark0978]

Unmount can't happen while they have it open without forcing it and no they
get no signal in that case, your stuff just potentially gets corrupted.

It needs to leave the filesystems mounted and hibernate, then when it
resumes, check that the same SD card is in the device and silently restore
the mount (which should require 0 effort since it should still be mounted)
before waking any of the apps.

On Thu, Mar 26, 2015 at 11:27 AM, Liam M [email protected] wrote:

If you could get it to umount, wouldn't that signal MySQL or Postgres or
some other thing like that to stop writing to disk and close file
descriptors?

—
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/288#issuecomment-86603785.

[andisopany]

I'm having this same problem.

I noticed that the sd card is mounted as the rootfs for the chroot AND ALSO as a media mounted external. I'm wondering if this is why things are complicated.

[andisopany]

I found a few discussions about problems with ubuntu corrupting sd cards after a sleep/resume cycle. Although quite old, the following discussion addresses a kernel config setting which, by default, causes sd cards to be remounted automatically during a sleep/resume cycle.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504391

I'm thinking the problem might be in the chrooted kernel remounting the sd card after sleep, and not in chrome os.

[divx118]

@andisopany There is no "chrooted kernel". When using a chroot it uses the same kernel as the host system. So in this case it uses the chromeos kernel. Like you also read in the issue, is that enabling CONFIG_MMC_UNSAFE_RESUME is not very safe and can cause data corruption. This flag is indeed not set in the chromeos config for the kernel. Only for armel which uses internal mmc.

chromeos/config/armel/common.config:CONFIG_MMC_UNSAFE_RESUME=y
chromeos/config/i386/common.config:# CONFIG_MMC_UNSAFE_RESUME is not set
chromeos/config/x86_64/common.config:# CONFIG_MMC_UNSAFE_RESUME is not set

[andisopany]

Are you saying that the settings of the userspace kernel have no effect on
the mounting behavior of the sd card during the sleep/resume cycle? Why
does the userspace kernel mount the sd card in a different location than
chrome os?

My point is that the crouton script attempts to mitigate by setting chrome
os to persist it's mount for the sd but no consideration is given to the
userspace kernel.

On Wednesday, April 1, 2015, Maurice van Kruchten [email protected]
wrote:

@andisopany https://github.com/andisopany There is no "chrooted
kernel". When using a chroot it uses the same kernel as the host system. So
in this case it uses the chromeos kernel. Like you also read in the issue,
is that enabling CONFIG_MMC_UNSAFE_RESUME is not very safe and can cause
data corruption. This flag is indeed not set in the chromeos config for the
kernel. Only for armel which uses internal mmc.

chromeos/config/armel/common.config:CONFIG_MMC_UNSAFE_RESUME=y
chromeos/config/i386/common.config:# CONFIG_MMC_UNSAFE_RESUME is not set
chromeos/config/x86_64/common.config:# CONFIG_MMC_UNSAFE_RESUME is not set

—
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/288#issuecomment-88525302.

[andisopany]

Ok I guess I really don't know what a chroot is, but it seems like the second set of settings you get when you add a chroot will have the same effects as the original one. If there is a sleep procedure in the chroot won't it be run when the tablet sleeps?

[MAkerboom]

you can disable 'standby on lid' and/or 'idle suspend' by writing to these files without needing to change the readonly filesystem:

/var/lib/power_manager/disable_idle_suspend
/var/lib/power_manager/use_lid

I created a wrapper script to start my crouton:

#!/bin/sh -e

ROOTUID="0"

if [ "$(id -u)" -ne "$ROOTUID" ] ; then
  echo "This script must be executed with root privileges."
  exit 1
else
  echo 1 >/var/lib/power_manager/disable_idle_suspend
  echo 0 >/var/lib/power_manager/use_lid
  ( (status powerd | fgrep -q "start/running" ) && restart powerd ) || \
  start powerd
  echo "Disabled idle/lid suspend"

  startunity $@

  rm -f /var/lib/power_manager/disable_idle_suspend
  rm -f /var/lib/power_manager/use_lid
  ( (status powerd | fgrep -q "start/running" ) && restart powerd ) || \
  start powerd
  echo "Enabled idle/lid suspend"
fi

hope this helps

[dylanPowers]

@MAkerboom I've needed this! Thanks. I presume you use it by running sudo enter-chroot -b yourscript rather than sudo enter-chroot -b xinit? All I'd need to do is replace startunity $@ with xinit?

Update: Nope that definitely won't work. A little help?

Replace startunity $@ with enter-chroot xinit in my case. I'm curious, I usually run crouton with the -b option so it runs in the background and I don't have to worry about accidentally closing a terminal. Is there a way to do what this script does while also running crouton in the background like I normally do?

[MAkerboom]

@dylanPowers I named the script startx and just start a crosh shell and run it with sudo startx. Once back in chrome os just close the crosh window, the script keeps on running...

[MAkerboom]

I created a little wiki page for this: https://github.com/dnschneid/crouton/wiki/Power-manager-overrides

[dylanPowers]

@MAkerboom Oh it does keep running. Cool. I did not know it worked that way. Thanks!

[xmbwd]

Sorry to be dense here, but I am wondering if there is a complete solution that allows for closing the lid on a chroot from an SD Card. @MAkerboom's script and wiki page seem to only stop the close lid from suspending.

But am I correct that then the Chromebook just continues running -- just with the lid closed? If not, great -- but please let us know.

And if the script does just prevent suspend, but the CB keeps running with the lid shut, is there another solution in the works?

[tkchris93]

First off, thank you for everything you are doing for this project. I think you double or triple the value of a chromebook. I'm still a bit of a beginner in this, but whilst waiting for a more permanent solution, I was wondering if there is a better way to get it working again. As of now, the only thing I have found that works is restarting the computer entirely to have the system recognize the card again. Is there a better way to do this? If I can get that working, I this issue would be much more manageable for me.

[dylanPowers]

@tkchris93 With my configuration all that's generally required is to kill all the processes that were trying to use the card (most of them usually crash on their own), and simply remount everything. If you're unsure what exactly you need to remount, you can run unmount-chroot with possibly the -k flag from a ChromeOS shell. That will essentially do a full shutdown of the chroot and allow you to start it up fresh again when you enter-chroot again. There's definitely no need to shutdown the Chromebook.

[tkchris93]

Maybe I have a different problem, then. Because last night, I unmounted my chroot, my Toshiba Chromebook 2 went to sleep, now this morning when I tried to use enter-chroot, it said that there weren't any chroots found. I navigated to the SD card in the chromeOS shell, and it thinks the SD card is empty. Once I restarted the laptop, then it recognized what was on the SD card again and everything was fine.

[dylanPowers]

Ah I see. You're set up a bit different than me. I have my chroots live on the Chromebook's internal storage and have certain bloated directories symlinked or mounted to my SD card. It limits the damage done by this bug so that when my SD card does become unmounted my chroot still works somewhat.

[ecollins]

There's a somewhat elaborate method of preventing a Chromebook from going to sleep here. Just thought I'd chime in that I've solved this problem with the 3rd-party extension Stay Awake, which has an option to forgo sleep and just turn the screen off when the lid closes.

[MAkerboom]

@ecollins the FAQ says different:
Frequently-asked questions:

• Will this extension prevent a Chromebook from suspending when its lid is closed?
  No, but if an external display is connected, recent versions of Chrome OS will remain awake when the lid is closed.

[cefn]

Do the last comments in https://code.google.com/p/chromium/issues/detail?id=208380#c96 hold a measure of hope for a fix coming through on the beta channel?

I'm finding it hard to identify from that thread whether there is really an improvement or not for filesystems mounted on SD cards, and how to take advantage of it.

Perhaps based on https://code.google.com/p/chromium/issues/detail?id=505216 it sounds like the same problem remains (File Descriptors invalidated) so it's probably just a misreport.

My Chromebook space issues are critical, to the extent I've removed everything I can and I'm still maxing out my 16 Gb.

[ecollins]

@MAkerboom Quite right, my mistake. Not sure why it appeared to work for a bit, but it stopped.
Your solution is awesome, though. All my hats off.

[Oliver84]

I've tried a solution posted on https://goo.gl/sIwg48. He suggested installing crouton directly on the usb without using symbolic links and then running enter-chroot from within that directory.

"1. Use an ext4 USB and install crouton chroots in it.
(By crouton -r trusty -t core -p /media/removable/USB Drive/crouton)

1. sudo sh ./enter-chroot in /media/removable/USB Drive/crouton/bin
2. ls in trusty and it works well.
3. suspend the laptop.
4. ls again after resumed.
5. still works."

I've tested this with a 10 min and 45 min suspend time and it has resumed perfectly fine. I will try longer suspends and see if anything breaks. Hope this helps

[ecollins]

This is how I run Debian from my sd card; suspend still results on
read-only lock.
On Sep 24, 2015 7:58 AM, "Oliver Acevedo" [email protected] wrote:

I've tried a solution posted on https://goo.gl/sIwg48. He suggested
installing crouton directly on the usb without using symbolic links and
then running enter-chroot from within that directory.

"1. Use an ext4 USB and install crouton chroots in it.
(By crouton -r trusty -t core -p /media/removable/USB Drive/crouton)

1. sudo sh ./enter-chroot in /media/removable/USB Drive/crouton/bin
2. ls in trusty and it works well.
3. suspend the laptop.
4. ls again after resumed.
5. still works."

I've tested this with a 10 min and 45 min suspend time and it has resumed
perfectly fine. I will try longer suspends and see if anything breaks. Hope
this helps

—
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/288#issuecomment-142954346.

[Oliver84]

Actually, after suspending it for over an hour it broke...

[cefn]

Any possible resolution of this on the horizon? Anything I can do to progress it?

Can we set up some kind of bounty or is it just dead in the water (e.g. the ChromeOS patches have prevented any technical solution aside from building your own ChromeOS) ?

[Oliver84]

So if this is caused by the chromebook suspending, why doesn't it break when you manually suspend it by running powerd_dbus_suspend?

[ecollins]

@MAkerboom 's solution has worked, but with the unappealing side-effect that I had to close out linux to make the computer sleep. But now I can't suspend at all, even after a full reboot. Any ideas?

With only 16Gb local and the constant threat of deletion, Crouton only makes sense on an SD card for me, but there should really be a warning about this issue on the label.

[tkchris93]

Sorry if this has already been answered and I missed it, but does the same thing happen with USB drives?

[Oliver84]

Yes, that's my problem.

[rprr]

I posted earlier and created a new issue #2234. But I closed it as it is the same as this issue. I'm using an ASUS C201 Rockchip chromebook running trusty with xfce,xiwi from an external 64 GB Sandisk Ultra Card.

[me-lina]

After using @MAkerboom s script for a long time, I think it's causing an issue I also have since a long time. Because it seemed to happen randomly, I didn't see any connection with the script.
The problem is, that my Toshiba Chromebook 2 crashes when putting it to sleep (closing the lid) and opening it again after I started Crouton with the script and terminated it again. Most of the time the "crash" results in a black display and a Chrome-Error which says, that some error occured and I can restore my tabs. But some other times, the whole Chromebook starts new. After this, (I think) the error doesn't happen again until I started&terminated Crouton again.

Did anyone of you notice any issue similar to that?

[nigelhealy]

ChromeOS power management will disable SD card in many situations.

Disable ChromeOS power management of you want SD to always work.

The best way overall is to install your chroot on internal storage, and
have adhoc data needs on SD, this allows the Chromebook to work as
intended. The next best is if you must put important always needed data on
SD is disable power management.

I run my chroot in a script which disables power management and restores is
as chroot exits. The chroot doesn't always halt, so I also have power
management restore script.
On Jan 13, 2016 4:17 AM, "me-lina" [email protected] wrote:

After using @MAkerboom https://github.com/MAkerboom s script for a long
time, I think it's causing an issue I also have since a long time. Because
it seemed to happen randomly, I didn't see any connection with the script.
The problem is, that my Toshiba Chromebook 2 crashes when putting it to
sleep (closing the lid) and opening it again after I started Crouton with
the script and terminated it again. Most of the time the "crash" results in
a black display and a Chrome-Error which says, that some error occured and
I can restore my tabs. But some other times, the whole Chromebook starts
new. After this, (I think) the error doesn't happen again until I
started&terminated Crouton again.

Did anyone of you notice any issue similar to that?

—
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/288#issuecomment-171274674.

[ecollins]

I was having similar issues with that script for a while, yes. Not sure
why, but I think @MAkerboom's script is probably the issue.

[tkchris93]

I haven't tried MAkerboom's script yet. I've just started running "sudo stop powerd". This forces the chromebook to stay awake (even when the lid is closed), which avoids the problem. Though it's very simple, I have seen two semi-annoying side effects. 1) you lose functionality of the brightness buttons. 2) naturally, the battery won't last as long since it never goes to sleep.

To turn powerd back on, run "sudo start powerd".

[me-lina]

I modified the script a little bit, until now it seems to work without that issue I had before. (But now there's the problem with the brightness buttons as mentioned by @tkchris93 )

#!/bin/bash  

ROOTUID="0"

case $(id -u) in

  $ROOTUID)
        stop powerd  
        echo "Disabled idle/lid suspend"

        startxfce4 -c /media/removable/SD/chroots $@                   

        start powerd
        echo "Enabled idle/lid suspend" 
        ;; 

         *)
        echo "This script must be executed with root privileges."
        ;;
esac

edit: didn't work, the issue occured again, but I think now, that it's maybe my crouton installation itself. my newest skript (another one), doesn't cause the issue.

[3rdwiki]

I posted a bounty for this : http://ow.ly/Xt2rw

I shall come back to this when funds allow.

[me-lina]

So, I couldn't resolve the problem when running Crouton from a SD card but when running it from an USB 3.0 Stick on a Toshiba Chromebook 2. Now I can suspend while running Crouton and it seems to do a real suspend (checked battery level in percent before and after putting it to sleep for several hours). I tested it with a SanDisk Cruzer Extreme stick but I ordered a smaller stick now.

Version 48.0.2564.116 (64-bit)
Plattform 7647.84.0 (Official Build) stable-channel swanky
Firmware Google_Swanky.5216.238.5

I changed some of the power saving settings for usb1 and usb2, but I'm not sure anymore which and whether is important for the solution.

My settings are (for both):

while [ $i -lt $(ls -l|wc -l) ]; do echo -e $PWD/$(ls | head -n $i | tail -n 1) '\t\t Value: '$(cat *| head -n $i | tail -n 1) && let i=$i+1; done
/sys/bus/usb/devices/usb1/power/active_duration Value: 26337460
/sys/bus/usb/devices/usb1/power/autosuspend Value: 2
/sys/bus/usb/devices/usb1/power/autosuspend_delay_ms Value: 2000
/sys/bus/usb/devices/usb1/power/connected_duration Value: 63712046
/sys/bus/usb/devices/usb1/power/control Value: auto
/sys/bus/usb/devices/usb1/power/dark_resume_active Value: disabled
/sys/bus/usb/devices/usb1/power/dark_resume_source Value: disabled
/sys/bus/usb/devices/usb1/power/level Value: auto
/sys/bus/usb/devices/usb1/power/runtime_active_time Value: 12369728
/sys/bus/usb/devices/usb1/power/runtime_status Value: active
/sys/bus/usb/devices/usb1/power/runtime_suspended_time Value: 37352530
/sys/bus/usb/devices/usb1/power/wakeup Value: disabled
/sys/bus/usb/devices/usb1/power/wakeup_abort_count Value:
/sys/bus/usb/devices/usb1/power/wakeup_active Value:
/sys/bus/usb/devices/usb1/power/wakeup_active_count Value:
/sys/bus/usb/devices/usb1/power/wakeup_count Value:
/sys/bus/usb/devices/usb1/power/wakeup_expire_count Value:
/sys/bus/usb/devices/usb1/power/wakeup_last_time_ms Value:
/sys/bus/usb/devices/usb1/power/wakeup_max_time_ms Value:
/sys/bus/usb/devices/usb1/power/wakeup_total_time_ms Value:

So I installed Crouton on the USB stick with the -p option (from a backup in my case):

sudo sh ~/Downloads/crouton -f XFCE.tar.gz -p /media/removable/SanDisk/XFCE

And started it with:

cd /media/removable/SanDisk/XFCE/bin && sudo bash startxfce4

[MarcSabatella]

I guess this is still unresolved? I'm running Toshiba Chromebook 2 - the original Bay Trail version - with a local chroot but with the SD card used for additional storage only, and until recently, the only issue was needing to remount the card on card to turn the "exec" flag on. But since switching to a new SD card formatted as ext4, now when the Chromebook wakes, the card is not mounted at all. I often get a dialog on wake telling me I need to give permission, which I do, but the card still doesn't mount. Manually mounting doesn't work either - "sudo mount /dev/mmcblk1p1 /var/host/media/removable/SD" yields "mount point does not exist", which is true. If I create the folder manually, then the mount fails with "File exists" ("SD" is the name of my card; it normally automounts).

Is there soemthing about ext4 that exacerbates this problem? I really want ext4 for the symbolic links.

[MarcSabatella]

Still having this issue. It seems if I try variations these steps, including switching back and forth to ChromeOS and also popping the card out then back in, I can sometimes get the card to mount. But this can't be good for the filesystem, and definitely isn't good for my productivity. Is there really no solution for this problem? Do SD cards work perfectly for everyone else, or does everyone else just accept that they can't be used conveniently?

[ecollins]

Marc Sabatella -

Are we sure this is the same problem discussed above? It sounds like the SD
card isn't mounting when the laptop powers on to begin with, which I would
read as pointing to a problem other than ChromeOS' tendency to unmount on
suspend.

The solution I'm using is MAkerboom's, which prevents the laptop from
suspending whenever crouton is running. As long as you're okay with leaning
_heavily_ on the Toshiba's admirable battery life, it lets one run crouton
from an SD card without having it constantly unmounted.
(I just turn the screen and any processes off, leaving the laptop up and
running when I carry it around. At least it works better than taking it out
and putting it back in.)

(Sidenote: MAkerboom's script re-enables power management when crouton
turns off, which in theory will maintain the un- and re-mounting behavior
when crouton isn't running. Something about the script _may_ have caused my
laptop to stop suspending entirely, even when crouton's off, but I don't
want to point fingers as I've had toddler-induced hardware issues.)

On Fri, Apr 22, 2016 at 7:20 AM, Marc Sabatella [email protected]
wrote:

Still having this issue. It seems if I try variations these steps,
including switching back and forth to ChromeOS and also popping the card
out then back in, I can sometimes get the card to mount. But this can't be
good for the filesystem, and definitely isn't good for my productivity. Is
there really no solution for this problem? Do SD cards work perfectly for
everyone else, or does everyone else just accept that they can't be used
conveniently?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/288#issuecomment-213446291

[MarcSabatella]

Sorry if I was not clear. My card definitely mounts normally (automatically) when the system first boots. It fails only after a sleep/wake cycle.

It is true the specifics of my case differ from those in the original post - I am not trying to run the chroot itself from the SD card. My situation is thus more like https://github.com/dnschneid/crouton/issues/288#issuecomment-84585763. I assume it's the same basic issue, though - ChromeOS unmounts the card on sleep and somehow it is not being remounted correctly on wake. The specifics of what goes wrong on wake changed for me last week (previously, it remounted but lost exec status, now it fails to remount at all because of either "mount point not found" or "file exists". I'm not running the chroot from the SD card, so all I lose is my extra data drive. But again, my assumption is that the basic problem is the same - the card is not being mounted correctly on wake.

Not going to sleep is not an option for me. All day battery life is one reason i'm using a Chromebook in the first place.

[MarcSabatella]

Hmm, after a few more sleeps where it remounted automatically, or where the manual attempt succeeded, it failed again this afternoon. This time in my flailing about trying to fix it, I tried something I hadn't tried before: an explicit "-t ext4". This worked! Well, it worked this time anyhow.

Still wishing I could figure out a way to not have to face this every time the system wakes up.

[tedm]

I've never seen a standard linux distro on a pc or embedded run off SD cards for more than a couple of years, and that was with specific cards. I'm not sure what the kernel is doing that causes the SD card failures over time. I have seen vmware ESX _BOOT_ from sd cards in dedicated rack servers, and remain running for years, but I've resigned to not run linux or chroots off of SD cards because of the high rate of failures over time.

[nigelhealy]

You need to mount noatime nodiratime as otherwise every read becomes a
write. If you mount read-only if can't cause a write by reading.

Personally I install chroot on internal storage and then inside the chroot
mount the SD for specific folders holding any big apps.

My Chromebook has 16GB internal it is ample to put a full distro on
internal then mount SD for the rest.
On Apr 27, 2016 12:16 PM, "tedm" [email protected] wrote:

I've never seen a standard linux distro on a pc or embedded run off SD
cards for more than a couple of years, and that was with specific cards.
I'm not sure what the kernel is doing that causes the SD card failures over
time. I have seen vmware ESX _BOOT_ from sd cards in dedicated rack
servers, and remain running for years, but I've resigned to not run linux
or chroots off of SD cards because of the high rate of failures over time.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/dnschneid/crouton/issues/288#issuecomment-215197979

[beow]

Don't know if this have been mentioned but I run crouton from internal SSD (Toshiba CB 2) and use SD card for file storage. When suspending the SD cards un-mounts, but switching back to Chrome OS (Shift-Ctrl-Alt-back) Chrome OS re-mounts the card and I can switch back to crouton again with mounted SD card.

[lzantal]

@beow how do you designate your file system for the SD card? If I could have the large linux apps running from the SD card then I could totally use my internal 16GB drive. I also have the toshiba cb2

[jmaris]

This issue still persists and in my opinion is seriously important.

I've noticed that in the enter-chroot script, crouton does

for usbp in /sys/bus/usb/devices/*/power/persist; do
        if [ -e "$usbp" ]; then
            echo 1 > "$usbp"

however I believe that the SD card reader is a mmc device on the Toshiba Chromebook 2. (/sys/bus/mmc/devices/*) however i've had little luck actually getting it to persist.

[Colelyman]

I am also encountering this issue running crouton from a USB 3.0 drive on Dell Chromebook 13:
Version 55.0.2883.42 beta (64-bit)
Platform 8872.44.0 (Official Build) beta-channel lulu
ARC Version 3448313
Firmware Google_Lulu.6301.136.57

ChromeOS seems to crash completely when the lid is closed and crouton is still running.
Note: this issue started last week, before then I was able to suspend/resume with the chroot running just fine.

[jmaris]

Apologies for the double post but my previous post lacked information :
I attempted to create a file named "persist" in the /sys/bus/mmc/devices/*/power/ directories, however it refused to create the file, i also tried to chmod the directory and such but it was to no avail. I'm wondering if there isn't another way of stopping it from going to sleep. I don't want to disable suspend as i need all day battery life ..

[cvmiller]

I see the same problem with chroot on USB3 drive, crouton crashing upon wake up

sudo edit-chroot -al
name: trusty
encrypted: no
Entering /mnt/stateful_partition/crouton/chroots/trusty...
crouton: version 1-20161116131524~master:9db73043
release: trusty
architecture: armhf
xmethod: xiwi
targets: xfce,extension,audio,xiwi,core,x11,keyboard
host: version 8743.85.0 (Official Build) stable-channel daisy 
kernel: Linux localhost 3.8.11 #1 SMP Tue Nov 15 18:18:37 PST 2016 armv7l armv7l armv7l GNU/Linux
freon: yes
Not unmounting /mnt/stateful_partition/crouton/chroots/trusty as another instance is using it.

I see this error in the crash shell:

** (xfdesktop:25045): CRITICAL **: xfce_backdrop_loader_closed_cb: assertion 'XFCE_IS_BACKDROP(backdrop)' failed

(xfdesktop:25045): libxfce4util-CRITICAL **: Unable to rename /home/cvmiller/.config/xfce4/desktop/icons.screen0-1247x723.rc.new.25045.tmp to /home/cvmiller/.config/xfce4/desktop/icons.screen0-1247x723.rc.new: Read-only file system

(xfdesktop:25045): libxfce4util-CRITICAL **: Unable to open file /home/cvmiller/.config/xfce4/desktop/icons.screen0-1247x723.rc.new.25045.tmp for writing: Read-only file system
/usr/local/bin/croutonpowerd: 304: /usr/local/bin/croutonpowerd: host-dbus: not found
/usr/local/bin/croutonclip: 1: /usr/local/bin/croutonclip: croutoncycle: not found
Bus error (core dumped)
/media/removable/USB_Linux/chroots/trusty not found.
chronos@localhost /usr/local $ 

It appears that the USB drive is not mounted when the apps in the chroot want to access it (immediately after wake up), and things get very unhappy.

[courville]

Just want to highlight that the issue is still present with an SDCard on chromebook Acer R11, Toshiba 2 and prevents to really use crouton on low storage space devices with chromeOS (stable/beta).
I can switch to usb key and do the echo 1 > /sys/bus/usb/devices/2-1/power/persist trick manually but mount point from chromeOS world disapears still and I have side effects with xiwi that looses sync via extension.

[tedm]

trust me, you don't want to use an sd card for this, it might work for awhile, but it will very likely fail much sooner than if you ran it on internal non removable storage.

[DennisLfromGA]

There's crbug.com/434372 that's related to this issue, Commenter#41 mentions it affecting 'crouton'.

[choikwa]

I'm seeing same problem as @MarcSabatella where upon suspend and resume, my SD card would be mounted with noexec. My trivial workaround is just running sudo mount -o remount,exec /media/removable/<SD>, but I would like if SD could be mounted as exec in the first place (or at least sticky this command somehow upon resume). Is this problem to be fixed in Chromium upstream and if so, beyond this GH issue?

[darren3]

How do you install the above scripts?

[ChrisHodgesUK]

I'm getting this too on a C201 (xenial and chrome 60). I'm running off a SD card as I don't have much internal storage. It's new in one of the recent chrome updates, but I'm not sure which one as chrome broke my previous chroot (also on the SD card) and I've been trying alternative approaches like dual-booting. Sometimes it remounts my SD card -- but at /media/removable SD Card 1 instead of the usual /media/removable SD Card

[ChrisHodgesUK]

@tedm by what mechanism would flash memory fail faster if the chip is in a card rather than soldered to the motherboard?

I'd rather burn up write cycles on something cheap and replaceable than on the main storage.

[tedm]

@ChrisHodgesUK I don't really know for sure. I suspect it might be that many of the SD and USB flash cards I've seen fail when running 24x7 for weeks and months were of lower quality than internal memory cells, or perhaps the fact that it's going through more interfaces (usb, pci, etc.) causes /proc, /sys reads and writes more?

[jmaris]

do we have any news on this upstream ?

[andersan]

been using crouton for over a year on an external drive - have always had this issue

[xzhao025]

I am using thinkpad13 and have installed crouton on sd card. I was struggling with the suspend/resume crouton not working issue. but it seems got fixed after I manually mount my /dev/mmcblk1 under a mounting point under my home folder, say ~/crouton, instead of /media/removable/xxx. I am not 100% sure but it seems chrome os is only messing up with those device mounted under removable. Hope this might help someone.

[armyofpunk]

I am using thinkpad13 and have installed crouton on sd card. I was struggling with the suspend/resume crouton not working issue. but it seems got fixed after I manually mount my /dev/mmcblk1 under a mounting point under my home folder, say ~/crouton, instead of /media/removable/xxx. I am not 100% sure but it seems chrome os is only messing up with those device mounted under removable. Hope this might help someone.

sorry xzhao025 could you explain more how to mount differently? do you mean on install you installed it in a different place? thanks.

[xzhao025]

hope this alias that I use to start crouton will make more sense out of my comment
alias cli='sudo umount /dev/mmcblk1 ; sudo mount /dev/mmcblk1 ~/crouton ; sudo sh ~/crouton/bin/startcli'

[DennisLfromGA]

Hopefully, these new features coming to Chrome OS will help to alleviate some or all of these problems.

• New Power Saving Options Coming To Chromebooks

-DennisL

[addrummond]

xzhao025's solution works for me. Unmount the SD card from /media/removable and mount it somewhere in your home dir. Suspend/resume then appears to work as expected.

[davidbrewster]

Just wanted to also add that xzhao025's solution worked for me too on Toshiba Chromebook 2. For me the relevent commands were just slightly different:
sudo mount /dev/mmcblk1p1 ~/crouton; sudo sh ~/crouton/bin/enter-chroot
Although obviously you can use startxfce4 or whatever instead of enter-chroot.
So, thanks very much xzhao025! The problem with hanging/loss of mount after suspend had been a real pain in the neck.

[G3zz]

@davidbrewster did you have to move or copy your chroot using edit-chroot -m?
I can mount /dev/mmcblk1p1 at ~/crouton but when I try and execute enter-chroot I am getting No chroots found in /mnt/stateful_partition/crouton/chroots.

[davidbrewster]

@G3zz I'm not with my chromebook at the moment, but IIRC I may have just been running ~/crouton/bin/enter-chroot directly (if that's the right path) - [edit: In fact thats exactly what I did if I look at the second part of the command I posted earlier]

[evansharp]

Does anyone have any recovery advice?
I've got a large Lexar SD card that was holding a chroot for my Toshiba CR2, but now it won't mount at all. I can't see the mmcblk1 items in /dev and my other linux laptop can't see it either. Really hoping this $60 card isn't bricked.
Thanks for any thoughts!

[DanPete]

Also wanted to add that @xzhao025's solution also works if the crouton is on a USB drive too. this is the command I ended up using

sudo umount /dev/sda1
sudo mount /dev/sda1 ~/crouton
sudo sh ~/crouton/bin/startunity

I also created a folder at ~/ called crouton, but I am not sure if that was necessary or not. But, it is working very well now, and happy that I can close my Chromebook without the USB unmounting and crouton crashing or hanging.

Thanks @xzhao025!

[xzhao025]

glad my solution could help! Thanks again for crouton project to make chromebook more than a browser!

[cefn]

@DanPete Can your solution be used for mapping specific directories from /dev/sda1 into a specific chroot, or can it only be used to map the common parent of all chroots from /dev/sda1? I would like to have the responsiveness and avoidance of wear by keeping the crouton chroot on my Toshiba Chromebook 2, but with /usr and /home mounted from an ext4 partition on a USB drive to provide for expansion of installed packages and documents beyond the 16G limit.

[zhaofengli]

Is it necessary to unmount the drive from the original ChromeOS mountpoint for this to work? In my limited testing (tried closing the lid once), my own mountpoint isn't affected when the original ChromeOS mount is kept intact.

[Lucaacer]

I have just moved crouton to an ext SD card, which I had ext4 formatted, and I can confirm that creating a crouton folder in home and mounting there the ext SD card seems to work like a charm.

chronos@localhost / $ sudo mkdir ~/crouton
chronos@localhost / $ sudo mount /dev/mmcblk1p1 ~/crouton
chronos@localhost / $ sudo sh ~/crouton/bin/startxfce4

The only caveat is that chrome OS, after suspending, cannot see the SD card any longer, but the xiwi windows is still there and the linux distro works just the same.

Update:

Tested and confirmed as working after my Lenovo thinkpad yoga 3rd gen slept 3 hours straight.

[ipstone]

@Lucaacer

Hi Lucaacer: I am trying to do the same on the external SD card, but I found the SD card is quite slow - is that normal? I followed the instruction to format sd card to ext4 format. The same SD card in FAT format is quite fast with 50MB/sec read speed etc.

[Lucaacer]

Hi, sadly my Chromebook was stolen... so I can't compare the speed! Anyway, the Linux chroot was working well and wasn't sluggish. But it was just my impression and nothing else, sorry.

[Bappy1988]

So, best way I've found to do this (on my c100p) is install in the default SD Card mount location;

sh ~/crouton -t xfce,xiwi,kbd,touch -p /media/removable/SD\ Card

let it go through and install everything (takes AGES)

when it has finished, create a new mount point:

mkdir ~/SDCARD

create a launch script. I went with ~/ubuntu, I did this with vi as that's included in chromeos' shell

#!/bin/sh
sudo umount /dev/mmcblk1*
sudo mount /dev/mmcblk1p1 ~/SDCARD
sudo sh ~/SDCARD/bin/startxfce4 -b

now, when I start up my chromebook, I launch a terminal, type shell, then

sh ~/ubuntu

it asks for my sudo password, then once typed in, it sorts the mountpoint, launches the chroot in the background and I can close the terminal and enjoy coding is vscode on ubuntu 16.04 in a xiwi window, I can close the lid of my chromebook or just leave it to go to sleep mode and not worry about my ubuntu session

[guyman70718]

Is this issue still being worked on? I'm sorry for the major necro but i'm still having this issue.

[CINJ]

Still having a similar version of the same issue: XFCE (no Xiwi) will allow sleep, however, the USB device disappears from ChromeOS as soon as XFCE is logged out and there doesn't seem any way to get the USB device back. Pull out the USB stick and ChromeOS gives a WARNING about removing the USB device! So it's still there somehow! After plugging the USB back in, the chroot is left in an invalid state and after you enter-chroot again it cleans up the chroot and you need to enter it AGAIN and then it enters the chroot as expected.

[JRHLaw]

Still having a similar version of the same issue: XFCE (no Xiwi) will allow sleep, however, the USB device disappears from ChromeOS as soon as XFCE is logged out and there doesn't seem any way to get the USB device back. Pull out the USB stick and ChromeOS gives a WARNING about removing the USB device! So it's still there somehow! After plugging the USB back in, the chroot is left in an invalid state and after you enter-chroot again it cleans up the chroot and you need to enter it AGAIN and then it enters the chroot as expected.

Have also just experienced this when running the chroot off a MicroSD card -- see crosspost at https://www.reddit.com/r/Crouton/comments/9pcfa2/chroot_on_sd_card_still_works_even_when_unmounted.

How odd...

[TriVoxel]

I'm having this issue now as well. I cannot find anything to fix it other than to go into the ChromeOS settings and disable sleep on lid close and suspending after inactivity. Not too good for the battery though. Even worse, if your Chromebook sleeps and you shut down Crouton it cannot access the exit-chroot script and it will inevitably lead to a corrupted installation. I had KDE and after about the tenth time plasmashell could not load anymore and eventually the whole system was unusable.