Revision history [back]

I get this in my log (I created a /opt/alien/logs folder to get an aliendalvik log):

02-26 16:31:00.408  1823  1823 D StorageNotification: Startup with UMS connection false (media state mounted)
02-26 16:31:00.430  1823  1906 I StorageNotification: UMS connection changed to false (media state mounted)
02-26 16:31:00.618  1737  1757 W MountService: Duplicate state transition (mounted -> mounted) for /home/nemo/android_storage

What I think is:

The fusermount for /home/nemo/android_storage fails. Users who implemented a custom mount of the "nemo" folder (ex. on a sdcard with btrfs subvolumes) into "/home/nemo" will never get the android stuff in their /home/nemo/android_storage folder (and all links to it). Because this (second) mount on aliendalvik startup fails. For such users /home and /home/nemo are on different devices. So /home/nemo/android_storage points to the mmcblk1 device, and /opt/alien/home/nemo/android_storage points to the mmcblk0p28 device.

this fusermount fails, if it would not fail, we should see some files in the folder, but there are no files:

/dev/fuse on /home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

All Sailors with a standard installation will not be affected. Because the /opt/alien/home/nemo/android_storage mount is done and the android_storage folders are the same. The alien.sh script binds the original /home mountpoint. /home and /home/nemo are on the same device, so they are the same folders. Thats why every thing seem to be done correctly.

only this fusermount is done:

/dev/fuse on /opt/alien/home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

I get this in my log (I created a /opt/alien/logs folder to get an aliendalvik log):

02-26 16:31:00.408  1823  1823 D StorageNotification: Startup with UMS connection false (media state mounted)
02-26 16:31:00.430  1823  1906 I StorageNotification: UMS connection changed to false (media state mounted)
02-26 16:31:00.618  1737  1757 W MountService: Duplicate state transition (mounted -> mounted) for /home/nemo/android_storage

What I think is:

The fusermount for /home/nemo/android_storage fails. Users who implemented a custom mount of the "nemo" folder (ex. on a sdcard with btrfs subvolumes) into "/home/nemo" will never get the android stuff in their /home/nemo/android_storage folder (and all links to it). Because this (second) mount on aliendalvik startup fails. For such users /home and /home/nemo are on different devices. So /home/nemo/android_storage points to the mmcblk1 device, and /opt/alien/home/nemo/android_storage points to the mmcblk0p28 device.

this fusermount fails, if it would not fail, we should see some files in the folder, but there are no files:

/dev/fuse on /home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

All Sailors with a standard installation will not be affected. Because the /opt/alien/home/nemo/android_storage mount is done and the android_storage folders are the same. The alien.sh script binds the original /home mountpoint. /home and /home/nemo are on the same device, so they are the same folders. Thats why every thing seem to be done correctly.

only this fusermount is done:

/dev/fuse on /opt/alien/home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

I get this in my log (I created a /opt/alien/logs folder to get an aliendalvik log):

02-26 16:31:00.408  1823  1823 D StorageNotification: Startup with UMS connection false (media state mounted)
02-26 16:31:00.430  1823  1906 I StorageNotification: UMS connection changed to false (media state mounted)
02-26 16:31:00.618  1737  1757 W MountService: Duplicate state transition (mounted -> mounted) for /home/nemo/android_storage

What I think is:

The fusermount for /home/nemo/android_storage fails. Users who implemented a custom mount of the "nemo" folder (ex. on a sdcard with btrfs subvolumes) into "/home/nemo" will never get the android stuff in their /home/nemo/android_storage folder (and all links to it). Because this (second) mount on aliendalvik startup fails. For such users /home and /home/nemo are on different devices. So /home/nemo/android_storage points to the mmcblk1 device, and /opt/alien/home/nemo/android_storage points to the mmcblk0p28 device.

this fusermount fails, if it would not fail, we should see some files in the folder, but there are no files:

/dev/fuse on /home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

All Sailors with a standard installation will not be affected. Because the /opt/alien/home/nemo/android_storage mount is done and the android_storage folders are the same. The alien.sh script binds the original /home mountpoint. /home and /home/nemo are on the same device, so they are the same folders. Thats why every thing seem to be done correctly.

only this fusermount is done:

/dev/fuse on /opt/alien/home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

I get this in my log (I created a /opt/alien/logs folder to get an aliendalvik log):

02-26 16:31:00.408  1823  1823 D StorageNotification: Startup with UMS connection false (media state mounted)
02-26 16:31:00.430  1823  1906 I StorageNotification: UMS connection changed to false (media state mounted)
02-26 16:31:00.618  1737  1757 W MountService: Duplicate state transition (mounted -> mounted) for /home/nemo/android_storage

What I think is:

The fusermount for /home/nemo/android_storage fails. Users who implemented a custom mount of the "nemo" folder (ex. on a sdcard with btrfs subvolumes) into "/home/nemo" will never get the android stuff in their /home/nemo/android_storage folder (and all links to it). Because this (second) mount on aliendalvik startup fails. For such users /home and /home/nemo are on different devices. So /home/nemo/android_storage points to the mmcblk1 device, and /opt/alien/home/nemo/android_storage points to the mmcblk0p28 device.

this fusermount fails, if it would not fail, we should see some files in the folder, but there are no files:

/dev/fuse on /home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

All Sailors with a standard installation will not be affected. Because the /opt/alien/home/nemo/android_storage mount is done and the android_storage folders are the same. The alien.sh script binds the original /home mountpoint. /home and /home/nemo are on the same device, so they are the same folders. Thats why every thing seem to be done correctly.

only this fusermount is done:

/dev/fuse on /opt/alien/home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

I get this in my log (I created a /opt/alien/logs folder to get an aliendalvik log):

02-26 16:31:00.408  1823  1823 D StorageNotification: Startup with UMS connection false (media state mounted)
02-26 16:31:00.430  1823  1906 I StorageNotification: UMS connection changed to false (media state mounted)
02-26 16:31:00.618  1737  1757 W MountService: Duplicate state transition (mounted -> mounted) for /home/nemo/android_storage

What I think is:

The fusermount for /home/nemo/android_storage fails. Users who implemented a custom mount of the "nemo" folder (ex. on a sdcard with btrfs subvolumes) into "/home/nemo" will never get the android stuff in their /home/nemo/android_storage folder (and all links to it). Because this (second) mount on aliendalvik startup fails. For such users /home and /home/nemo are on different devices. So /home/nemo/android_storage points to the mmcblk1 device, and /opt/alien/home/nemo/android_storage points to the mmcblk0p28 device.

this fusermount fails, if it would not fail, we should see some files in the folder, but there are no files:

/dev/fuse on /home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

All Sailors with a standard installation will not be affected. Because the /opt/alien/home/nemo/android_storage mount is done and the android_storage folders are the same. The alien.sh script binds the original /home mountpoint. /home and /home/nemo are on the same device, so they are the same folders. Thats why every thing seem to be done correctly.

only this fusermount is done:

/dev/fuse on /opt/alien/home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

I get this in my log (I created a /opt/alien/logs folder to get an aliendalvik log):

02-26 16:31:00.408  1823  1823 D StorageNotification: Startup with UMS connection false (media state mounted)
02-26 16:31:00.430  1823  1906 I StorageNotification: UMS connection changed to false (media state mounted)
02-26 16:31:00.618  1737  1757 W MountService: Duplicate state transition (mounted -> mounted) for /home/nemo/android_storage

What I think is:

The fusermount for /home/nemo/android_storage fails. Users who implemented a custom mount of the "nemo" folder (ex. on a sdcard with btrfs subvolumes) into "/home/nemo" will never get the android stuff in their /home/nemo/android_storage folder (and all links dependent symlinks to it). Because this (second) mount on aliendalvik startup fails. For such users /home and /home/nemo are on different devices. So /home/nemo/android_storage points to the mmcblk1 device, and /opt/alien/home/nemo/android_storage points to the mmcblk0p28 device.

this fusermount fails, if it would not fail, we should see some files in the folder, but there are no files:

/dev/fuse on /home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

All Sailors with a standard installation will not be affected. Because the /opt/alien/home/nemo/android_storage mount is done and the android_storage folders are the same. They will not notice, that the fusermount to /home/nemo/android_storage fails. The alien.sh script binds the original /home mountpoint. /home and /home/nemo are on the same device, so they are the same folders. Thats why every thing seem to be done correctly.

only this fusermount is done:

/dev/fuse on /opt/alien/home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

I get this in my log (I created a /opt/alien/logs folder to get an aliendalvik log):

02-26 16:31:00.408  1823  1823 D StorageNotification: Startup with UMS connection false (media state mounted)
02-26 16:31:00.430  1823  1906 I StorageNotification: UMS connection changed to false (media state mounted)
02-26 16:31:00.618  1737  1757 W MountService: Duplicate state transition (mounted -> mounted) for /home/nemo/android_storage

What I think is:

The fusermount for /home/nemo/android_storage fails. Users who implemented a custom mount of the "nemo" folder (ex. on a sdcard with btrfs subvolumes) into "/home/nemo" will never get the android stuff in their /home/nemo/android_storage folder (and all dependent symlinks to it). Because this (second) mount on aliendalvik startup fails. For such users /home and /home/nemo are on different devices. So /home/nemo/android_storage points to the mmcblk1 device, and /opt/alien/home/nemo/android_storage points to the mmcblk0p28 device.

this fusermount fails, if it would not fail, we should see some files in the folder, but there are no files:

/dev/fuse on /home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

All Sailors with a standard installation will not be affected. Because the /opt/alien/home/nemo/android_storage mount is done and the android_storage folders are the same. They will not notice, that the fusermount to /home/nemo/android_storage fails. fails, but it does, and that ist the bug I describe. The alien.sh script binds the original /home mountpoint. /home and /home/nemo are on the same device, so they are the same folders. Thats why every thing seem to be done correctly.

only this fusermount is done:

/dev/fuse on /opt/alien/home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

update: changed the titel. I get this in my log (I created a /opt/alien/logs folder to get an aliendalvik log):

02-26 16:31:00.408  1823  1823 D StorageNotification: Startup with UMS connection false (media state mounted)
02-26 16:31:00.430  1823  1906 I StorageNotification: UMS connection changed to false (media state mounted)
02-26 16:31:00.618  1737  1757 W MountService: Duplicate state transition (mounted -> mounted) for /home/nemo/android_storage

What I think is:

The fusermount for /home/nemo/android_storage fails. Users who implemented a custom mount of the "nemo" folder (ex. on a sdcard with btrfs subvolumes) into "/home/nemo" will never get the android stuff in their /home/nemo/android_storage folder (and all dependent symlinks to it). Because this (second) mount on aliendalvik startup fails. For such users /home and /home/nemo are on different devices. So /home/nemo/android_storage points to the mmcblk1 device, and /opt/alien/home/nemo/android_storage points to the mmcblk0p28 device.

this fusermount fails, if it would not fail, we should see some files in the folder, but there are no files:

/dev/fuse on /home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

All Sailors with a standard installation will not be affected. Because the /opt/alien/home/nemo/android_storage mount is done and the android_storage folders are the same. They will not notice, that the fusermount to /home/nemo/android_storage fails, but it does, and that ist the bug I describe. The alien.sh script binds the original /home mountpoint. /home and /home/nemo are on the same device, so they are the same folders. Thats why every thing seem to be done correctly.

only this fusermount is done:

/dev/fuse on /opt/alien/home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

update: changed the titel. I get this in my log (I created a /opt/alien/logs folder to get an aliendalvik log):

02-26 16:31:00.408  1823  1823 D StorageNotification: Startup with UMS connection false (media state mounted)
02-26 16:31:00.430  1823  1906 I StorageNotification: UMS connection changed to false (media state mounted)
02-26 16:31:00.618  1737  1757 W MountService: Duplicate state transition (mounted -> mounted) for /home/nemo/android_storage

What I think is:

The fusermount for /home/nemo/android_storage fails. Users who implemented a custom mount of the "nemo" folder (ex. on a sdcard with btrfs subvolumes) into "/home/nemo" will never get the android stuff in their /home/nemo/android_storage folder (and all dependent symlinks to it). Because this (second) mount on aliendalvik startup fails. For such users /home and /home/nemo are on different devices. So /home/nemo/android_storage points to the mmcblk1 device, and /opt/alien/home/nemo/android_storage points to the mmcblk0p28 device.

this fusermount fails, if it would not fail, we should see some files in the folder, but there are no files:

/dev/fuse on /home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

All Sailors with a standard installation will not be affected. Because the /opt/alien/home/nemo/android_storage mount is done and the android_storage folders are the same. They will not notice, that the fusermount to /home/nemo/android_storage fails, but it does, and that ist the bug I describe. The alien.sh script binds the original /home mountpoint. /home and /home/nemo are on the same device, so they are the same folders. Thats why every thing seem to be done correctly.

only this fusermount is done:

/dev/fuse on /opt/alien/home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

edit 150227: the fusermont fusermount to /home/nemo/android_storage should be done, before chroot. At the moment it ist done after the chroot.

update: changed the titel. I get this in my log (I created a /opt/alien/logs folder to get an aliendalvik log):

02-26 16:31:00.408  1823  1823 D StorageNotification: Startup with UMS connection false (media state mounted)
02-26 16:31:00.430  1823  1906 I StorageNotification: UMS connection changed to false (media state mounted)
02-26 16:31:00.618  1737  1757 W MountService: Duplicate state transition (mounted -> mounted) for /home/nemo/android_storage

What I think is:

The fusermount for /home/nemo/android_storage fails. Users who implemented a custom mount of the "nemo" folder (ex. on a sdcard with btrfs subvolumes) into "/home/nemo" will never get the android stuff in their /home/nemo/android_storage folder (and all dependent symlinks to it). Because this (second) mount on aliendalvik startup fails. For such users /home and /home/nemo are on different devices. So /home/nemo/android_storage points to the mmcblk1 device, and /opt/alien/home/nemo/android_storage points to the mmcblk0p28 device.

this fusermount fails, if it would not fail, we should see some files in the folder, but there are no files:

/dev/fuse on /home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)

All Sailors with a standard installation will not be affected. Because the /opt/alien/home/nemo/android_storage mount is done and the android_storage folders are the same. They will not notice, that the fusermount to /home/nemo/android_storage fails, but it does, and that ist the bug I describe. The alien.sh script binds the original /home mountpoint. /home and /home/nemo are on the same device, so they are the same folders. Thats why every thing seem to be done correctly.

only this fusermount is done:

/dev/fuse on /opt/alien/home/nemo/android_storage type fuse (rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other)