Closed drinkcat closed 9 years ago
Is this still an issue?
Well, my Samsung ARM is locked in a drawer halfway around the world....
I think this might have been on kernel 3.4, so maybe it is fixed with kernel 3.8. I'll open a crbug if necessary.
This might be a Chrome issue, as I have a Satechi USB 3 Ethernet (wired) adapter, which is also a 3 pot USB 2/3 hub. With no chroot running, just Stable Chrome on the Samsung 2012 ARM, resuming in the USB 3 port by lifting up the lid, may require me to pull out and re-insert the adapter. But in the USB 2 port, it appears to resume OK. Again, this is WITHOUT a chroot running, so either a Chromium OS issue, or an incompatibility with this specific USB 3 device.
Hi,
I am having maybe a related issue with a SanDisk USB 3.0 formatted with ext4. It keeps remounting randomly during normal continuous operation in Chrome OS.
I am for example unable to do any backups on my chroot as it keeps randomly umounting/remountig during the process. On the other hand, a backup on a Lexar USB 2.0 (I think FAT32) seems to work flawlesly no remounts.
I guess it seems to be a Chrome OS problem.
So, I got that new fancy USB 3.0 stick to use with my Samsung Chromebook ARM, but I’m facing an issue with persistence on the USB 3.0 port. USB 2.0 port works as expected.
croutonversion:
Plug in USB 2.0 port,
dmesg
output:Then enter-chroot:
Now suspend the machine (close lid), wake it up, chroot still works, and nothing remarkable in dmesg:
All good.
Now, connecting the device on the USB 3.0 port:
enter-chroot, then close the lid. On the way back, the chroot is unusable:
And this in dmesg:
The USB stick gets mapped to a new device (
sdb
), mounted a new location (/media/removable/USB Drive 1
), and lots of mount points are left behind by crouton.Related to #288 (and http://crbug.com/208380), but not quite the same thing... ext4 without journal does not fix the problem: the issue is at a lower level it seems.
Another device that is only USB 2.0 capable works on both ports (I've notice some strangeness that looks more like #288, but the chroot was always kept alive).
power/persist
in the relevant sysfs directory is set to 1, as expected.If somebody has any suggestions...