Hello,
I'm currently running at 2.6.0-test1-mm2-O8 and I wanted to give devfs a
shot. I recompiled the kernel with the following settings:
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
# CONFIG_DEVFS_DEBUG is not set
As I read through the documentation (btw, devfs=nomount is mentioned in
configure help but not in Documentation/filesystems/devfs/boot-options)
I got the understanding that this shouldn't make any difference to the
system right? After booting with this kernel there were lots of proper
devfs devices in my dmesg (host0/ide0... scsi0/...) however, the system
didn't came up (couldn't mount rootfs). It didn't even work when I
enabled CONFIG_DEVFS_MOUNT.
I'm not sure whether this is a bug in mount/nomount of devfs or if it's
somewhere my fault/setup (root on raid1, various lvm2 devices on raid1/0
devices)
Any help would be greatly appreciated.
--
Regards,
Wiktor Wodecki
argh
On Fri, Jul 25, 2003 at 01:08:31PM +0200, Wiktor Wodecki wrote:
> Hello,
>
> I'm currently running at 2.6.0-test1-mm2-O8 and I wanted to give devfs a
> shot. I recompiled the kernel with the following settings:
> CONFIG_DEVFS_FS=y
> CONFIG_DEVFS_MOUNT=y
please note, that my initial testing was done with CONFIG_DEVFS_MOUNT
*not* set.
> # CONFIG_DEVFS_DEBUG is not set
>
> As I read through the documentation (btw, devfs=nomount is mentioned in
> configure help but not in Documentation/filesystems/devfs/boot-options)
> I got the understanding that this shouldn't make any difference to the
> system right? After booting with this kernel there were lots of proper
> devfs devices in my dmesg (host0/ide0... scsi0/...) however, the system
> didn't came up (couldn't mount rootfs). It didn't even work when I
> enabled CONFIG_DEVFS_MOUNT.
>
> I'm not sure whether this is a bug in mount/nomount of devfs or if it's
> somewhere my fault/setup (root on raid1, various lvm2 devices on raid1/0
> devices)
>
> Any help would be greatly appreciated.
>
> --
> Regards,
>
> Wiktor Wodecki
--
Regards,
Wiktor Wodecki
>Hello,
>I'm currently running at 2.6.0-test1-mm2-O8 and I wanted to give devfs a
>shot. I recompiled the kernel with the following settings:
>CONFIG_DEVFS_FS=y
>CONFIG_DEVFS_MOUNT=y
># CONFIG_DEVFS_DEBUG is not set
>As I read through the documentation (btw, devfs=nomount is mentioned in
>configure help but not in Documentation/filesystems/devfs/boot-options)
>I got the understanding that this shouldn't make any difference to the
>system right? After booting with this kernel there were lots of proper
>devfs devices in my dmesg (host0/ide0... scsi0/...) however, the system
>didn't came up (couldn't mount rootfs). It didn't even work when I
>enabled CONFIG_DEVFS_MOUNT.
>I'm not sure whether this is a bug in mount/nomount of devfs or if it's
>somewhere my fault/setup (root on raid1, various lvm2 devices on raid1/0
>devices)
>Any help would be greatly appreciated.
You need to change your /etc/fstab to reflect the new devfs device names,
ex: "/dev/discs/disc0/part1" instead of "/dev/hda1". You can also use devfsd (or some alternative) to make synlinks to the older devices and retain permissions etc... Also, without devfsd you cannot expect module autoloading as modules can't be automatically loaded when theres no device requesting them (in this case the device simply doesn't exist until module is loaded)
On Sat, Jul 26, 2003 at 12:23:25AM +0530, Balram Adlakha wrote:
> >Hello,
>
> >I'm currently running at 2.6.0-test1-mm2-O8 and I wanted to give devfs a
> >shot. I recompiled the kernel with the following settings:
> >CONFIG_DEVFS_FS=y
> >CONFIG_DEVFS_MOUNT=y
> ># CONFIG_DEVFS_DEBUG is not set
>
> >As I read through the documentation (btw, devfs=nomount is mentioned in
> >configure help but not in Documentation/filesystems/devfs/boot-options)
> >I got the understanding that this shouldn't make any difference to the
> >system right? After booting with this kernel there were lots of proper
> >devfs devices in my dmesg (host0/ide0... scsi0/...) however, the system
> >didn't came up (couldn't mount rootfs). It didn't even work when I
> >enabled CONFIG_DEVFS_MOUNT.
>
> >I'm not sure whether this is a bug in mount/nomount of devfs or if it's
> >somewhere my fault/setup (root on raid1, various lvm2 devices on raid1/0
> >devices)
>
> >Any help would be greatly appreciated.
>
>
> You need to change your /etc/fstab to reflect the new devfs device names,
> ex: "/dev/discs/disc0/part1" instead of "/dev/hda1". You can also use devfsd (or some alternative) to make synlinks to the older devices and retain permissions etc... Also, without devfsd you cannot expect module autoloading as modules can't be automatically loaded when theres no device requesting them (in this case the device simply doesn't exist until module is loaded)
wait a second, this is a dumb thing to do. I do not want to migrate over
to devfs yet. I wanted to give it a shot and look around a bit. What I
haad in mind was mounting it on /dev2 or similar. Enabling this option
and converting my whole system is not a migration path. That's just
plain luck (might be easy for plain ide/scsi disks, but whatabout
metadevices like lvm and raid?). It is written in the documentation that
devfs comes with most backwards compatibility. I expected there to be
things like /dev/md0 and such for compatibility.
OTOH what's CONFIG_DEVFS_MOUNT for then? If devices get named the other
way round I *have* to mount it anyway, haven't I? I think improvements
must happen here in order to make devfs usable.
--
Regards,
Wiktor Wodecki
There is a bug with devfs and raid, see:
http://bugzilla.kernel.org/show_bug.cgi?id=471
It's sitting there since 2.5.45, but no one seems interested and I
don't have the knowledge to fix it by myself (or the time to acquire
that knowledge).
Bye.
On Fri, Jul 25, 2003 at 01:08:31PM +0200, Wiktor Wodecki wrote:
> Hello,
>
> I'm currently running at 2.6.0-test1-mm2-O8 and I wanted to give devfs a
> shot. I recompiled the kernel with the following settings:
> CONFIG_DEVFS_FS=y
> CONFIG_DEVFS_MOUNT=y
> # CONFIG_DEVFS_DEBUG is not set
>
> I'm not sure whether this is a bug in mount/nomount of devfs or if it's
> somewhere my fault/setup (root on raid1, various lvm2 devices on raid1/0
> devices)
>
> Any help would be greatly appreciated.
--
----------------------------------------
Daniele Venzano
Web: http://digilander.iol.it/webvenza/
Daniele Venzano <[email protected]> wrote:
>
> There is a bug with devfs and raid, see:
> http://bugzilla.kernel.org/show_bug.cgi?id=471
>
> It's sitting there since 2.5.45, but no one seems interested and I
> don't have the knowledge to fix it by myself (or the time to acquire
> that knowledge).
Unfortunately, raising a bug in bugzilla doesn't actually mean that anyone
is paying any attention to it. You need to keep shouting at people.
Is the problem simply that the device has moved from /dev/md1 to /dev/md/1?
If so, is this change sufficient?
diff -puN drivers/md/md.c~a drivers/md/md.c
--- 25/drivers/md/md.c~a 2003-07-26 11:24:58.000000000 -0700
+++ 25-akpm/drivers/md/md.c 2003-07-26 11:25:15.000000000 -0700
@@ -3505,7 +3505,7 @@ int __init md_init(void)
for (minor=0; minor < MAX_MD_DEVS; ++minor) {
devfs_mk_bdev(MKDEV(MAJOR_NR, minor),
S_IFBLK|S_IRUSR|S_IWUSR,
- "md/%d", minor);
+ "md%d", minor);
}
register_reboot_notifier(&md_notifier);
@@ -3567,7 +3567,7 @@ static __exit void md_exit(void)
int i;
blk_unregister_region(MKDEV(MAJOR_NR,0), MAX_MD_DEVS);
for (i=0; i < MAX_MD_DEVS; i++)
- devfs_remove("md/%d", i);
+ devfs_remove("md%d", i);
devfs_remove("md");
unregister_blkdev(MAJOR_NR,"md");
_
> Is the problem simply that the device has moved from /dev/md1 to /dev/md/1?
> If so, is this change sufficient?
>
> diff -puN drivers/md/md.c~a drivers/md/md.c
> --- 25/drivers/md/md.c~a 2003-07-26 11:24:58.000000000 -0700
> +++ 25-akpm/drivers/md/md.c 2003-07-26 11:25:15.000000000 -0700
> @@ -3505,7 +3505,7 @@ int __init md_init(void)
> for (minor=0; minor < MAX_MD_DEVS; ++minor) {
> devfs_mk_bdev(MKDEV(MAJOR_NR, minor),
> S_IFBLK|S_IRUSR|S_IWUSR,
> - "md/%d", minor);
> + "md%d", minor);
> }
should not such things be done by devfsd in user space? This patch makes it
even more incompatible with 2.4 ...
On Sun, Jul 27, 2003 at 01:49:19AM +0530, Balram Adlakha wrote:
> On Sat, Jul 26, 2003 at 08:37:50PM +0200, Wiktor Wodecki wrote:
> > On Sat, Jul 26, 2003 at 11:22:14PM +0530, Balram Adlakha wrote:
> > > The old naming scheme is (quite) depricated. Firstly, devfs shows only those devices which are probed (have a driver), secondly the devices are sorted in an easy to understand directory heirarchy to reduce clutter.
> > > Theres a devfs daemon called devfsd which is actually (almost) a part of a working devfs system. Using devfsd, you can autoload modules even while using devfs, and it also creates symlinks to older device name if that is specified in the /etc/devfsd.conf file.
> > > It is your choice if you want to use devfs or not, linux is all about choice. If you don't like the new naming scheme, you can edit a few lines in the devfs source and change the scheme. Or you can have devfs mounted in another place (like /dev2) and create a script which creates symlinks from /dev2 to /dev with your own preferred names, and you can edit /etc/rc.d/rc.sysinit to run the script on bootup.
> > > Or you can continue using the old device inodes...Some people still prefer them.
> >
> > I understand that and I greatly appreciate the new naming scheme.
> > However it would have been nice if I could have bootet just up and look
> > at it without changing my core system files (I regard /etc/fstab as
> > core). Nevermind, I might give it another shot on a testing system.
> >
> You won't need to update /etc/fstab if you use devfsd and its configured to create old device names in /dev...
ah! This should be placed somewhere in a FAQ or so. As I've read through
the docs this isn't mentioned anywhere. This of course solves all my
concerns about devfs. Will try it again soon.
Thanks for enlightment :-)
--
Regards,
Wiktor Wodecki
Andrey Borzenkov <[email protected]> wrote:
>
> > Is the problem simply that the device has moved from /dev/md1 to /dev/md/1?
> > If so, is this change sufficient?
> >
> > diff -puN drivers/md/md.c~a drivers/md/md.c
> > --- 25/drivers/md/md.c~a 2003-07-26 11:24:58.000000000 -0700
> > +++ 25-akpm/drivers/md/md.c 2003-07-26 11:25:15.000000000 -0700
> > @@ -3505,7 +3505,7 @@ int __init md_init(void)
> > for (minor=0; minor < MAX_MD_DEVS; ++minor) {
> > devfs_mk_bdev(MKDEV(MAJOR_NR, minor),
> > S_IFBLK|S_IRUSR|S_IWUSR,
> > - "md/%d", minor);
> > + "md%d", minor);
> > }
>
> should not such things be done by devfsd in user space?
Darned if I know - I do not have operational experience with devfs.
> This patch makes it even more incompatible with 2.4 ...
The patch is broken - 2.4 does /dev/md/2 as well.
So what is the bug? Why are people suddenly having problems with this?
On Sunday 27 July 2003 00:50, Andrew Morton wrote:
> Andrey Borzenkov <[email protected]> wrote:
> > > Is the problem simply that the device has moved from /dev/md1 to
> > > /dev/md/1? If so, is this change sufficient?
> > >
> > > diff -puN drivers/md/md.c~a drivers/md/md.c
> > > --- 25/drivers/md/md.c~a 2003-07-26 11:24:58.000000000 -0700
> > > +++ 25-akpm/drivers/md/md.c 2003-07-26 11:25:15.000000000 -0700
> > > @@ -3505,7 +3505,7 @@ int __init md_init(void)
> > > for (minor=0; minor < MAX_MD_DEVS; ++minor) {
> > > devfs_mk_bdev(MKDEV(MAJOR_NR, minor),
> > > S_IFBLK|S_IRUSR|S_IWUSR,
> > > - "md/%d", minor);
> > > + "md%d", minor);
> > > }
> >
> > should not such things be done by devfsd in user space?
>
> Darned if I know - I do not have operational experience with devfs.
>
> > This patch makes it even more incompatible with 2.4 ...
>
> The patch is broken - 2.4 does /dev/md/2 as well.
>
> So what is the bug? Why are people suddenly having problems with this?
it is hard to tell with the amount of information provided in bug report (even
error message is not given). We have three cases here:
root=123456 (real major/minor number) or root=/dev/md2 (literal string). In
both cases init/do_mount_devfs.c:create_dev() should notice that neither
/dev/123456 nor /dev/md2 exist, search /dev for ROOT_DEV and create link from
/dev/root to real device. If it does not work somethig is broken here, people
who can reproduce it should add printk's to create_dev and find_in_devfs to
see what happens. It may fail for /dev/md2 if block device name in sysfs
differs from "md2" because then it won't find correct ROOT_DEV
root=/dev/md/2 (literal string) should work simply because /dev/root is linked
directly to /dev/md/2
I do not have any raid devices nor possibility to create them so I cannot
test.
-andrey
On Sun, Jul 27, 2003 at 02:30:01AM +0400, Andrey Borzenkov wrote:
> it is hard to tell with the amount of information provided in bug report (even
> error message is not given). We have three cases here:
>
> root=123456 (real major/minor number) or root=/dev/md2 (literal string). In
> both cases init/do_mount_devfs.c:create_dev() should notice that neither
> /dev/123456 nor /dev/md2 exist, search /dev for ROOT_DEV and create link from
> /dev/root to real device. If it does not work somethig is broken here, people
> who can reproduce it should add printk's to create_dev and find_in_devfs to
> see what happens. It may fail for /dev/md2 if block device name in sysfs
> differs from "md2" because then it won't find correct ROOT_DEV
>
> root=/dev/md/2 (literal string) should work simply because /dev/root is linked
> directly to /dev/md/2
>
> I do not have any raid devices nor possibility to create them so I cannot
> test.
Andrew's patch makes it work, the system boots fine with raid and devfs
mounted automatically.
Also using root=/dev/md/2 as boot option works (just tried).
Before the patch I tried with root=/dev/md2, that is what I'm using with
2.4, but didn't work. The error message is:
VFS: cannot open root device "md2" or md2
please append a correct "root=" boot option
Kernel panic: VFS: unable to mount root fs on md2
Let me know if you need more info, but I think the sysfs
explanation is right.
Bye.
--
----------------------------------------
Daniele Venzano
Web: http://digilander.iol.it/webvenza/
On Sad, 2003-07-26 at 19:25, Andrew Morton wrote:
> Is the problem simply that the device has moved from /dev/md1 to /dev/md/1?
> If so, is this change sufficient?
The problem seems to be "user selected devfs"
> diff -puN drivers/md/md.c~a drivers/md/md.c
> --- 25/drivers/md/md.c~a 2003-07-26 11:24:58.000000000 -0700
> +++ 25-akpm/drivers/md/md.c 2003-07-26 11:25:15.000000000 -0700
> @@ -3505,7 +3505,7 @@ int __init md_init(void)
> for (minor=0; minor < MAX_MD_DEVS; ++minor) {
> devfs_mk_bdev(MKDEV(MAJOR_NR, minor),
> S_IFBLK|S_IRUSR|S_IWUSR,
> - "md/%d", minor);
> + "md%d", minor);
But 2.4 is the same as 2.5 ...
devfs_handle = devfs_mk_dir (NULL, "md", NULL);
/* we don't use devfs_register_series because we want to fill
md_hd_str
for (minor=0; minor < MAX_MD_DEVS; ++minor) {
char devname[128];
sprintf (devname, "%u", minor);
>
> The patch is broken - 2.4 does /dev/md/2 as well.
>
> So what is the bug? Why are people suddenly having problems with this?
>
Daniele did some debugging, result is:
=================
Buggy config
------------
GRUB command line: kernel (hd0,1)/testing root=/dev/md2
video=radeonfb:1024x768-32@60
As output there is only (copied by hand):
[...]
raid1: raid set md2 active with 2 out of 2 mirrors
md: ... autorun DONE.
create_dev: name=/dev/root dev=902 dname=md2
VFS: cannot open root device "md2" or md2
please append a correct "root=" boot option
Kernel panic: VFS: unable to mount root fs on md2
<STOP>
==================
the bug is almost for sure in init/do_mount_devfs.c:read_dir; it
allocates static buffer of size at most 2**MAX_ORDER and tries to
read the whole dir at once. md driver creates all minors in md_init
i.e. 256 (2**MINORBITS). MAX_ORDER default is 11 so we have at most
2K which is enough for appr. 200 entries; 256 do not fit :)
Daniel, please, could you change read_dir to just allocate bigger
buffer - 4K should do - and test once more?
I'll see what can be done. Anyone sees reason why normal directory
scan won't work here?
-andrey
"Andrey Borzenkov" <[email protected]> wrote:
>
> the bug is almost for sure in init/do_mount_devfs.c:read_dir; it
> allocates static buffer of size at most 2**MAX_ORDER and tries to
> read the whole dir at once.
Yes, that function is buggy.
diff -puN init/do_mounts_devfs.c~read_dir-fix init/do_mounts_devfs.c
--- 25/init/do_mounts_devfs.c~read_dir-fix 2003-07-28 00:21:40.000000000 -0700
+++ 25-akpm/init/do_mounts_devfs.c 2003-07-28 00:21:40.000000000 -0700
@@ -54,7 +54,7 @@ static void * __init read_dir(char *path
if (fd < 0)
return NULL;
- for (size = 1 << 9; size <= (1 << MAX_ORDER); size <<= 1) {
+ for (size = 1 << 9; size <= (PAGE_SIZE << MAX_ORDER); size <<= 1) {
void *p = kmalloc(size, GFP_KERNEL);
int n;
if (!p)
_
On Mon, Jul 28, 2003 at 12:22:16AM -0700, Andrew Morton wrote:
> "Andrey Borzenkov" <[email protected]> wrote:
> >
> > the bug is almost for sure in init/do_mount_devfs.c:read_dir; it
> > allocates static buffer of size at most 2**MAX_ORDER and tries to
> > read the whole dir at once.
>
> Yes, that function is buggy.
>
> diff -puN init/do_mounts_devfs.c~read_dir-fix init/do_mounts_devfs.c
> --- 25/init/do_mounts_devfs.c~read_dir-fix 2003-07-28 00:21:40.000000000 -0700
> +++ 25-akpm/init/do_mounts_devfs.c 2003-07-28 00:21:40.000000000 -0700
> @@ -54,7 +54,7 @@ static void * __init read_dir(char *path
> if (fd < 0)
> return NULL;
>
> - for (size = 1 << 9; size <= (1 << MAX_ORDER); size <<= 1) {
> + for (size = 1 << 9; size <= (PAGE_SIZE << MAX_ORDER); size <<= 1) {
> void *p = kmalloc(size, GFP_KERNEL);
> int n;
> if (!p)
>
> _
This patch solves the problem, the kernel boots fine and finds the root
device using root=/dev/md2 as boot option.
The output during boot is:
[...]
raid1: raid set md2 active with 2 out of 2 mirrors
md: ... autorun DONE.
create_dev: name=/dev/root dev=902 dname=md2
create_dev: found real device /dev/md/2
[...]
Thanks everyone, bye.
--
----------------------------------------
Daniele Venzano
Web: http://digilander.iol.it/webvenza/