Bug 2064 - [BSP] mount shows "/dev/sda4 on /media/sda4" but /media/sda4 doesn't exist
Summary: [BSP] mount shows "/dev/sda4 on /media/sda4" but /media/sda4 doesn't exist
Status: RESOLVED FIXED
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 1.2
Hardware: x86 Multiple
: Low minor
Target Milestone: 1.5 M2
Assignee: Hongxu Jia
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2012-03-08 09:42 UTC by Dexuan Cui
Modified: 2013-06-12 23:43 UTC (History)
11 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dexuan Cui 2012-03-08 09:42:37 UTC
This issue happens to BSP only.
After a BSP board is booted with Yocto linux from USB drive, "mount" shows:

/dev/sda4 on /media/sda4 type vfat (rw,sync,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

but actually the directory /media/sda4 doesn't exist at all.

BTW, if the USB disk is created with dd directly, the above "sda4" will be "sda" only, and the directory /media/sda doesn't exist at all.

Ps, the disk is mounted by 'sync' option -- this is really rather slow. I think we should mount it as "async".
Comment 1 Darren Hart 2012-03-15 22:18:52 UTC
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.
Comment 2 Darren Hart 2012-03-15 22:19:44 UTC
Waiting for a response from Dexuan, but we may just close this. But first, let me know why this is a problem.
Comment 3 Dexuan Cui 2012-03-16 01:45:58 UTC
(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.
Comment 4 Darren Hart 2012-03-19 16:16:22 UTC
One potential option here would be to bind mount the boot /media/* mount points into the chroot fs prior to chroot'ing to it.
Comment 5 Darren Hart 2012-04-27 00:33:13 UTC
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.
Comment 6 Dexuan Cui 2012-04-27 02:09:33 UTC
(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)
Comment 7 Chen Qi 2013-01-28 02:54:59 UTC
merged into poky/master: f8a4a74c8cd69de2b3332526e1110ff745fb824d

http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/live-image-move-media
Comment 8 Hongxu Jia 2013-06-06 05:42:54 UTC
*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.