Bug 2064

I believe this is because the mount data comes from proc setup during early boot before the change root, which then uses a different root filesystem.

We mount with sync because it is removable media and not using sync is dangerous. If you care about performance, you shouldn't be booting from a USB drive anyway. I suggest running an install from the live image, rather than using the live image as the final boot image.

As this is not a functional failure, but rather an ambiguous status report from mount, I'm dropping in priority.

Waiting for a response from Dexuan, but we may just close this. But first, let me know why this is a problem.

(In reply to comment #1)
> I believe this is because the mount data comes from proc setup during early
> boot before the change root, which then uses a different root filesystem.

"mount" shows: /dev/sda4 on /media/sda4 type vfat
but /media/sda4 doesn't exist at all. I think this would confuse a user?
If this mounting is intended and can't be fixed easily, can we at least create the directory /media/sda4? 

> 
> We mount with sync because it is removable media and not using sync is
> dangerous.
I agree.

>  If you care about performance, you shouldn't be booting from a USB
> drive anyway.
I mostly agree.

However, I can give some data: I have a USB drive that can be read at 15 MB/s and be written at 5MB/s.
However, with the sync option, looks the speed is far slower than 1MB/s.
This can cause pretty slow IO response sometimes when I write a few files -- the   shell can hang for 1~2 minutes until the IO finishes...

If I mkdir /media/sda4 and mount -o remount,async, the IO speed will become normal.

I'm not sure if this is an issue.
If this is intended, I can understand and close the bug. :-)

> I suggest running an install from the live image, rather than
> using the live image as the final boot image.
I agree.

> 
> As this is not a functional failure, but rather an ambiguous status report from
> mount, I'm dropping in priority.

One potential option here would be to bind mount the boot /media/* mount points into the chroot fs prior to chroot'ing to it.

This has additional side effects as well. I worked with a customer today who mounted the boot device (mmcblk0 in this case) to /mnt. It was already mounted on /media/mmcblk0, but that wasn't visible. They then mounted the rootfs.img to make a change (since union fs appears to prevent persistent storage). They unmounted the rootfs.img loop mount. Then tried to unmount /mnt/ It failed with a "device or resource busy" error. I suspect something is getting crossed up with mmcblk0 being mounted twice.

(In reply to comment #5)
> This has additional side effects as well. I worked with a customer today who
> mounted the boot device (mmcblk0 in this case) to /mnt. It was already mounted
> on /media/mmcblk0, but that wasn't visible. They then mounted the rootfs.img to
> make a change (since union fs appears to prevent persistent storage). They
> unmounted the rootfs.img loop mount. Then tried to unmount /mnt/ It failed with
> a "device or resource busy" error. I suspect something is getting crossed up
> with mmcblk0 being mounted twice.

Hi Darren,
I got the same  "device or resource busy" error recently -- previously(I meant maybe 2 months ago) I didn't get this error when I tried  "mount -o remount,async" as I described in Comment 3.

I think there must be something changed recently.
(Sorry, at present I have no time to look into that)

merged into poky/master: f8a4a74c8cd69de2b3332526e1110ff745fb824d

http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/live-image-move-media

*env
Build Configuration:
BB_VERSION        = "1.19.0"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-12.10"
TARGET_SYS        = "i586-poky-linux"
MACHINE           = "emenlow-noemgd"
DISTRO            = "poky"
DISTRO_VERSION    = "1.4+snapshot-20130605"
TUNE_FEATURES     = "m32 core2"
TARGET_FPU        = ""
meta              
meta-yocto        
meta-yocto-bsp    = "hongxu-0530-udev:5cb59cc6910d8f3165528c4a71e29e4de897d242"
meta-intel        
meta-emenlow      = "master:2ba2e0ea55bab687134b452a5db81d189b820f59"

*problem
Test them on Emenlow. Machine has internal SSD with sda1/sda2/sda3 partition on it.
After the BSP board is booted with Yocto linux from USB drive, "cat /proc/mounts" shows:
...
/dev/sda3 /media/sda3 ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/sda1 /media/sda1 ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
/dev/sda2 /media/sda2 ext3 rw,relatime,errors=continue,user_xattr,acl,barrier=1,data=ordered 0 0
...

but actually the directory /media/sda1 doesn't exist at all, "df" shows:
...
df: /media/sda3: No such file or directory
df: /media/sda1: No such file or directory
df: /media/sda2: No such file or directory
...

*analysis
This is because the mount data comes from proc setup during early boot before the change root, which then uses a different root filesystem, the media is not in the new root filesystem.

*solution
Plan 1, During early boot before switch_root, unmount any medias which mounted by udev's automounter could fix this issue, after switch_root to make the new root filesystem and start init process, the newer udev will detect and automount them again.

Plan 2, During early boot before switch_root, use `mount --move' to move the medias to the new root filesystem could also fix this issue. 

I have tested both, and Plan 2 is better, cause it only needs automounter once, and Plan 1 could not umount the real root media in which the target is busy.

Merged into master:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=66079795c9eaec1a7ae376b25d91eea14e6498b7