Bug 6806

Summary: Upgrade from 1.20.2 to 1.21.1 mdev problem
Product: Busybox Reporter: anthonysepa
Component: OtherAssignee: unassigned
Status: NEW ---    
Severity: normal CC: busybox-cvs, gregory.0xf0, vda.linux
Priority: P5    
Version: 1.21.x   
Target Milestone: ---   
Hardware: Other   
OS: Linux   
Host: Target:
Build:
Attachments: Changing the order of which the /sys tree is scanned in "mdev -s"

Description anthonysepa 2014-01-15 00:49:24 UTC
The flash devices on my embedded system are not flashable after update from 1.20.2 to 1.21.1.

flash_eraseall: can't open '/dev/mtd3': No such device or address

All programs try to write to the mtd? devices are affected. If I downgrade back to 1.20.2 it works again. Same everything.
Comment 1 Simon Edlund 2014-02-04 07:57:12 UTC
The problem seems to be the symlink /sys/block/mtdblockX/device
which points to /sys/class/mtd/mtdX, which exists on some kernels (i.e. 2.6.31)

When mdev -s traverses the /sys directory looking for "dev" files, it starts with the block devices under /sys/block, and will find the "dev" file through the symlink, and create a block device node.
In the next stage it will scan the /sys/class looking for char devices, and will find mtdX/dev again, but this time the mknod will fail because there is already a device node with that name.

I fixed this by having mdev -s scan the /sys/class before /sys/block, whether this is the best way, someone else with a deeper knowledge of the /sys directory hierarchy will have to judge. Anyway, I'll attach my patch to this bug.
Comment 2 Simon Edlund 2014-02-04 07:58:23 UTC
Created attachment 5216 [details]
Changing the order of which the /sys tree is scanned in "mdev -s"
Comment 3 anthonysepa 2014-02-04 17:33:48 UTC
Thanks for the patch. It works great. I used in on busybox 1.21.1 that is the default for buildroot 2013.11.
Comment 4 anthonysepa 2014-02-05 14:12:34 UTC
I'm having another problem that I don't know if it's related or not but the mdev -s is not setting the permissions for /dev/input/event* properly. In my mdev.conf I have the line:
event.*         root:root 666 =input/ @chmod 

but the permissions are:
total 0
drwxr-xr-x    2 root     root             0 Feb  2 21:08 .
drwxr-xr-x    4 root     root             0 Feb  2 21:08 ..
crw-rw----    1 root     root       13,  64 Feb  2 21:08 event0
crw-rw----    1 root     root       13,  65 Feb  2 21:08 event1
crw-rw----    1 root     root       13,  66 Feb  2 21:08 event2
crw-rw----    1 root     root       13,  67 Feb  2 21:08 event3

even if I change the line to:
event.*         root:games @chmod 666 $MDEV

run:
mdev -s

It's still:
total 0
drwxr-xr-x    2 root     root             0 Feb  2 21:08 .
drwxr-xr-x    4 root     root             0 Feb  2 21:08 ..
crw-rw----    1 root     root       13,  64 Feb  2 21:08 event0
crw-rw----    1 root     root       13,  65 Feb  2 21:08 event1
crw-rw----    1 root     root       13,  66 Feb  2 21:08 event2
crw-rw----    1 root     root       13,  67 Feb  2 21:08 event3
no change to group or permissions.

I am using a chmod in my startup script but mdev -s will revert it back to the wrong permissions if it ever gets run.
Comment 5 anthonysepa 2014-02-05 14:25:52 UTC
Just noticed it doesn't set permissions or user:group for any of my devices in subdirectories for example /dev/input or /dev/snd.
Comment 6 gregory.0xf0 2014-09-24 02:18:55 UTC
(In reply to comment #1)
> The problem seems to be the symlink /sys/block/mtdblockX/device
> which points to /sys/class/mtd/mtdX, which exists on some kernels (i.e. 2.6.31)
> 
> When mdev -s traverses the /sys directory looking for "dev" files, it starts
> with the block devices under /sys/block, and will find the "dev" file through
> the symlink, and create a block device node.
> In the next stage it will scan the /sys/class looking for char devices, and
> will find mtdX/dev again, but this time the mknod will fail because there is
> already a device node with that name.
> 
> I fixed this by having mdev -s scan the /sys/class before /sys/block, whether
> this is the best way, someone else with a deeper knowledge of the /sys
> directory hierarchy will have to judge. Anyway, I'll attach my patch to this
> bug.

I believe this patch is a good approach, has this been submitted to the mailing list?  I don't see it in the archives.
Comment 7 gregory.0xf0 2014-09-24 02:22:23 UTC
Also, it appears that this is only a problem when both CONFIG_SYSFS_DEPRECATED and CONFIG_SYSFS_DEPRECATED_V2 are set.