2064 2012-03-08 09:42:37 +0000 [BSP] mount shows "/dev/sda4 on /media/sda4" but /media/sda4 doesn't exist 2013-06-12 23:43:12 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.2 x86 Multiple RESOLVED FIXED Low minor 1.5 M2 1 dexuan.cui hongxu.jia corneliux.stoicescu dvhart hongxu.jia liezhi.yang mark.hatle meta.mr.watcher meta.watcher Qi.Chen sgw yi.zhao zhenfeng.zhao --- --- --- oldest_to_newest 18904 0 dexuan.cui 2012-03-08 09:42:37 +0000 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". 19157 1 dvhart 2012-03-15 22:18:52 +0000 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. 19158 2 dvhart 2012-03-15 22:19:44 +0000 Waiting for a response from Dexuan, but we may just close this. But first, let me know why this is a problem. 19164 3 dexuan.cui 2012-03-16 01:45:58 +0000 (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. 19223 4 dvhart 2012-03-19 16:16:22 +0000 One potential option here would be to bind mount the boot /media/* mount points into the chroot fs prior to chroot'ing to it. 20897 5 dvhart 2012-04-27 00:33:13 +0000 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. 20900 6 dexuan.cui 2012-04-27 02:09:33 +0000 (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) 29222 7 Qi.Chen 2013-01-28 02:54:59 +0000 merged into poky/master: f8a4a74c8cd69de2b3332526e1110ff745fb824d http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/live-image-move-media 33653 8 hongxu.jia 2013-06-06 05:42:54 +0000 *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. 33873 9 hongxu.jia 2013-06-12 23:43:12 +0000 Merged into master: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=66079795c9eaec1a7ae376b25d91eea14e6498b7