From: Stefan H. <sh...@lu...> - 2004-10-26 11:39:33
|
Hi UMLatics, this is a strange problem. All my UMLs works nice, but this one won't run with a uml kernel > 2.6.7-1um. And there is no difference between this uml and the others, except that this one uses many large fss. rootfs was 4GB, but for now I've shrunk to 1.9GB - no matter. cut from my startup-log: Checking for the skas3 patch in the host...found Checking for /proc/mm...found Linux version 2.6.9-uml-B1-basic-mono (ro...@sa...z) (gcc version 3.3.4 (Debian 1:3.3.4-13)) #8 Tue Oct 26 00:13:44 CEST 2004 Built 1 zonelists Kernel command line: umid=uml10 uml_dir=/tmp/uml/pid root=/dev/ubd/0 mem=128M ubd0=/fs/data/uml/uml10/uml10_root.cow_fs,/fs/data/uml/uml10/uml10_root.fs ubd1=/fs/data/uml/uml10/uml10_public.cow_fs,/fs/data/uml/uml10/uml10_public.fs ubd2=/fs/data/uml/uml10/uml10_audio.cow_fs,/fs/data/uml/uml10/uml10_audio.fs ubd3=/fs/data/uml/uml10/uml10_video.cow_fs,/fs/data/uml/uml10/uml10_video.fs ubd4=/fs/data/uml/uml10/uml10_home.cow_fs,/fs/data/uml/uml10/uml10_home.fs ubd7=/tmp/uml/swap/uml10_swap.fs eth0=tuntap,tap8 con=pts con0=fd:0,fd:1 con1=tty:/dev/vc/5 PID hash table entries: 1024 (order: 10, 16384 bytes) Kernel panic - not syncing: Segfault with no mm can anybody help me? thanks & greetings, stefan |
From: Stefan H. <sh...@lu...> - 2004-10-26 12:26:29
|
[ From: Stefan Hofmann <sh...@lu...> Date: 26.10.2004 13:39 MsgID: <901...@lu...> ] > Hi UMLatics, > this is a strange problem. > All my UMLs works nice, but this one won't run with a uml kernel > > 2.6.7-1um. > And there is no difference between this uml and the others, except that > this one uses many large fss. rootfs was 4GB, but for now I've shrunk to > 1.9GB - no matter. > cut from my startup-log: > Checking for the skas3 patch in the host...found > Checking for /proc/mm...found > Linux version 2.6.9-uml-B1-basic-mono (ro...@sa...z) (gcc version 3.3.4 (Debian 1:3.3.4-13)) #8 Tue Oct 26 00:13:44 CEST 2004 > Built 1 zonelists > Kernel command line: umid=uml10 uml_dir=/tmp/uml/pid root=/dev/ubd/0 mem=128M ubd0=/fs/data/uml/uml10/uml10_root.cow_fs,/fs/data/uml/uml10/uml10_root.fs > ubd1=/fs/data/uml/uml10/uml10_public.cow_fs,/fs/data/uml/uml10/uml10_public.fs ubd2=/fs/data/uml/uml10/uml10_audio.cow_fs,/fs/data/uml/uml10/uml10_audio.fs > ubd3=/fs/data/uml/uml10/uml10_video.cow_fs,/fs/data/uml/uml10/uml10_video.fs ubd4=/fs/data/uml/uml10/uml10_home.cow_fs,/fs/data/uml/uml10/uml10_home.fs ubd7=/tmp/uml/swap/uml10_swap.fs > eth0=tuntap,tap8 con=pts con0=fd:0,fd:1 con1=tty:/dev/vc/5 > PID hash table entries: 1024 (order: 10, 16384 bytes) > Kernel panic - not syncing: Segfault with no mm > can anybody help me? It was a simple command line problem. Maybe the cl string is too large. But, *why* does it work with kernel < 2.6.8??? Has the command line parsing code changed from 2.6.7? Thanks, stefan |
From: BlaisorBlade <bla...@ya...> - 2004-10-26 14:02:01
|
On Tuesday 26 October 2004 14:21, Stefan Hofmann wrote: > [ From: Stefan Hofmann <sh...@lu...> > Date: 26.10.2004 13:39 > MsgID: <901...@lu...> > ] > > > Hi UMLatics, > > > > this is a strange problem. > > cut from my startup-log: > > Checking for the skas3 patch in the host...found > > Checking for /proc/mm...found > > Linux version 2.6.9-uml-B1-basic-mono (ro...@sa...z) (gcc version 3.3.4 > > (Debian 1:3.3.4-13)) #8 Tue Oct 26 00:13:44 CEST 2004 Built 1 zonelists > > Kernel command line: umid=uml10 uml_dir=/tmp/uml/pid root=/dev/ubd/0 > > mem=128M > > ubd0=/fs/data/uml/uml10/uml10_root.cow_fs,/fs/data/uml/uml10/uml10_root.f > >s > > ubd1=/fs/data/uml/uml10/uml10_public.cow_fs,/fs/data/uml/uml10/uml10_publ > >ic.fs > > ubd2=/fs/data/uml/uml10/uml10_audio.cow_fs,/fs/data/uml/uml10/uml10_audio > >.fs > > ubd3=/fs/data/uml/uml10/uml10_video.cow_fs,/fs/data/uml/uml10/uml10_video > >.fs > > ubd4=/fs/data/uml/uml10/uml10_home.cow_fs,/fs/data/uml/uml10/uml10_home.f > >s ubd7=/tmp/uml/swap/uml10_swap.fs eth0=tuntap,tap8 con=pts con0=fd:0,fd:1 > > con1=tty:/dev/vc/5 > > PID hash table entries: 1024 (order: 10, 16384 bytes) > > Kernel panic - not syncing: Segfault with no mm > > > > can anybody help me? > > It was a simple command line problem. Maybe the cl string is too large. > But, *why* does it work with kernel < 2.6.8??? > > Has the command line parsing code changed from 2.6.7? Not that I know. But sorry, how do you manage to use COW files? It's quite hard, since the code does not even compile currently, to my knowledge. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Stefan H. <sh...@lu...> - 2004-10-26 14:42:14
|
[ From: BlaisorBlade <bla...@ya...> Date: 26.10.2004 16:02 MsgID: <200...@ya...> ] Hi BlaisorBlade, >> It was a simple command line problem. Maybe the cl string is too large. >> But, *why* does it work with kernel < 2.6.8??? >> >> Has the command line parsing code changed from 2.6.7? > Not that I know. But sorry, how do you manage to use COW files? It's quite > hard, since the code does not even compile currently, to my knowledge. NoNo, it does compile without any problems. 2.6.9 does, and 2.6.8.1 and 2.6.7 also. COW isn't the problem, but SMP <=> TT collides. A strange thing! because the shell cl buffer is always the same. Or is there a limit? Greetings, stefan hofmann |
From: BlaisorBlade <bla...@ya...> - 2004-10-26 15:17:18
|
On Tuesday 26 October 2004 16:38, Stefan Hofmann wrote: > [ From: BlaisorBlade <bla...@ya...> > Date: 26.10.2004 16:02 > MsgID: <200...@ya...> > ] > Hi BlaisorBlade, > > >> It was a simple command line problem. Maybe the cl string is too large. > >> But, *why* does it work with kernel < 2.6.8??? > >> > >> Has the command line parsing code changed from 2.6.7? > > > > Not that I know. But sorry, how do you manage to use COW files? It's > > quite hard, since the code does not even compile currently, to my > > knowledge. > > NoNo, it does compile without any problems. 2.6.9 does, and 2.6.8.1 and > 2.6.7 also. COW isn't the problem, but SMP <=> TT collides. Are you sure? I just tested COW support, and: - it appear to work if you pre-create the COW file, but it does not create it on its own. - the changes done to the root_fs, when using the COW file, are completely lost. There is at least another report of this, about the 2.6.0 era... > A strange thing! because the shell cl buffer is always the same. > Or is > there a limit? There is a big limit (about 32k) in general for Linux processes, and a smaller limit (I think it can be 1k or less) which is also choosen, at least in part, in mainline. I don't know all the mainline changes which could have caused this. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Stefan H. <sh...@lu...> - 2004-10-26 16:26:19
|
[ From: BlaisorBlade <bla...@ya...> Date: 26.10.2004 17:16 MsgID: <200...@ya...> ] Hi BlaisorBlade, >> NoNo, it does compile without any problems. 2.6.9 does, and 2.6.8.1 and >> 2.6.7 also. COW isn't the problem, but SMP <=> TT collides. > Are you sure? I just tested COW support, and: > - it appear to work if you pre-create the COW file, but it does not create it > on its own. > - the changes done to the root_fs, when using the COW file, are completely > lost. There is at least another report of this, about the 2.6.0 era... here are you wrong. COW files works very well. The kernel process build non-existing cow files, and changing a root_fs (and deleting its cow) works well, too - absolutely stable since 2.6.4. It even works in runtime. You can umount a fs+cowfs, merge it, make changes on fs and remount it without problems and the right cow file will be build on-the-fly. Very nice that. >> A strange thing! because the shell cl buffer is always the same. >> Or is there a limit? > There is a big limit (about 32k) in general for Linux processes, and a smaller > limit (I think it can be 1k or less) which is also choosen, at least in part, > in mainline. I don't know all the mainline changes which could have caused > this. the smaller limit could be interesting. 1k or less is tiny; I think one should increase such a limit. greetings, stefan |
From: Lars Kellogg-S. <la...@od...> - 2004-10-26 17:41:13
|
> - the changes done to the root_fs, when using the COW file, are completely > lost. There is at least another report of this, about the 2.6.0 era... I'm using COW filesystems with 2.6.8.1, and I haven't encountered any problems. The COW files are created correctly, and changes are persistent. -- Lars |
From: Jeff D. <jd...@ad...> - 2004-10-26 15:59:31
|
bla...@ya... said: > But sorry, how do you manage to use COW files? It's quite hard, since > the code does not even compile currently, to my knowledge. What are you talking about? COW files have always worked and have never been broken. Actually, I suspect you're confused by my attempt at creating a standalone COW driver which I later tossed out of the pool. Jeff |
From: BlaisorBlade <bla...@ya...> - 2004-10-26 16:36:14
|
On Tuesday 26 October 2004 19:09, Jeff Dike wrote: > bla...@ya... said: > > But sorry, how do you manage to use COW files? It's quite hard, since > > the code does not even compile currently, to my knowledge. > What are you talking about? COW files have always worked and have never > been broken. That's fine, but the support is quite buggy: 1) Any change which is done is lost (reported and confirmed). I remember digging into this some time ago, and maybe it came out that only little changes get lost. I tried changing the root password on the root_fs_tomsbrt and the change got lost after exiting from the VM and restarting it. 2) Creating a COW directly from the command line does not work. There is an error in the failure path, of the kind "errno / -return value": diff -puN arch/um/drivers/ubd_kern.c~uml-start-fixing-ubd arch/um/drivers/ubd_kern.c --- linux-2.6.9-current/arch/um/drivers/ubd_kern.c~uml-start-fixing-ubd 2004-10-17 18:03:54.158938784 +0200 +++ linux-2.6.9-current-paolo/arch/um/drivers/ubd_kern.c 2004-10-17 18:17:49.071012856 +0200 @@ -1394,7 +1394,7 @@ int open_ubd_file(char *file, struct ope if((fd == -ENOENT) && (create_cow_out != NULL)) *create_cow_out = 1; if(!openflags->w || - ((errno != EROFS) && (errno != EACCES))) return(-errno); + ((fd != -EROFS) && (fd != -EACCES))) return(fd); openflags->w = 0; fd = os_open_file(file, *openflags, mode); if(fd < 0) (Note that the patch is probably against ubd_user.c, actually. In my tree, I've almost completely moved it in ubd_kern.c). 3) Even with that applied, I got complaints from absolutize(). > Actually, I suspect you're confused by my attempt at creating a standalone > COW driver which I later tossed out of the pool. This is true, too: I got quite confused, even because the code is also in 2.4 and I thought it was needed. In fact, I was not at all able to understand what the hell was happening in the code. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: BlaisorBlade <bla...@ya...> - 2004-10-26 17:34:22
|
On Tuesday 26 October 2004 18:36, BlaisorBlade wrote: > On Tuesday 26 October 2004 19:09, Jeff Dike wrote: > > bla...@ya... said: > > > But sorry, how do you manage to use COW files? It's quite hard, since > > > the code does not even compile currently, to my knowledge. > > > > What are you talking about? COW files have always worked and have never > > been broken. > > That's fine, but the support is quite buggy: > > 1) Any change which is done is lost (reported and confirmed). I remember > digging into this some time ago, and maybe it came out that only little > changes get lost. I tried changing the root password on the root_fs_tomsbrt > and the change got lost after exiting from the VM and restarting it. I can confirm this issue with 2.6 kernels. To show this, however, you need to edit a file which already exists in the backing file, as /etc/passwd. I've tested this with root_fs_tomsbrt. > 2) Creating a COW directly from the command line does not work. There is an > error in the failure path, of the kind "errno / -return value": With the current kernels I'm testing (2.6.9 rc ones), this does not happen. The fix below does still make sense, however. > diff -puN arch/um/drivers/ubd_kern.c~uml-start-fixing-ubd > arch/um/drivers/ubd_kern.c > --- linux-2.6.9-current/arch/um/drivers/ubd_kern.c~uml-start-fixing-ubd > 2004-10-17 18:03:54.158938784 +0200 > +++ linux-2.6.9-current-paolo/arch/um/drivers/ubd_kern.c 2004-10-17 > 18:17:49.071012856 +0200 > @@ -1394,7 +1394,7 @@ int open_ubd_file(char *file, struct ope > if((fd == -ENOENT) && (create_cow_out != NULL)) > *create_cow_out = 1; > if(!openflags->w || > - ((errno != EROFS) && (errno != EACCES))) > return(-errno); + ((fd != -EROFS) && (fd != -EACCES))) > return(fd); openflags->w = 0; > fd = os_open_file(file, *openflags, mode); > if(fd < 0) > > (Note that the patch is probably against ubd_user.c, actually. In my tree, > I've almost completely moved it in ubd_kern.c). > > 3) Even with that applied, I got complaints from absolutize(). -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: Blaisorblade <bla...@ya...> - 2004-11-02 22:28:08
|
On Tuesday 26 October 2004 19:34, BlaisorBlade wrote: > On Tuesday 26 October 2004 18:36, BlaisorBlade wrote: > > On Tuesday 26 October 2004 19:09, Jeff Dike wrote: > > > bla...@ya... said: > > > > But sorry, how do you manage to use COW files? It's quite hard, > > > > since the code does not even compile currently, to my knowledge. > > > > > > What are you talking about? COW files have always worked and have > > > never been broken. > > > > That's fine, but the support is quite buggy: I'd like to undo this sentence... > > 1) Any change which is done is lost (reported and confirmed). I remember > > digging into this some time ago, and maybe it came out that only little > > changes get lost. I tried changing the root password on the > > root_fs_tomsbrt and the change got lost after exiting from the VM and > > restarting it. > > I can confirm this issue with 2.6 kernels. To show this, however, you need > to edit a file which already exists in the backing file, as /etc/passwd. > I've tested this with root_fs_tomsbrt. Well, this is false. It happens, in fact, even without COW files, and because /etc/passwd is rewritten during shutdown by that FS's scripts! So I am foolish :-000 . Please tell this all over the world! > > 2) Creating a COW directly from the command line does not work. > > There is > > an error in the failure path, of the kind "errno / -return value": > With the current kernels I'm testing (2.6.9 rc ones), this does not happen. > The fix below does still make sense, however. > > diff -puN arch/um/drivers/ubd_kern.c~uml-start-fixing-ubd > > arch/um/drivers/ubd_kern.c > > --- linux-2.6.9-current/arch/um/drivers/ubd_kern.c~uml-start-fixing-ubd > > 2004-10-17 18:03:54.158938784 +0200 > > +++ linux-2.6.9-current-paolo/arch/um/drivers/ubd_kern.c > > 2004-10-17 18:17:49.071012856 +0200 > > @@ -1394,7 +1394,7 @@ int open_ubd_file(char *file, struct ope > > if((fd == -ENOENT) && (create_cow_out != NULL)) > > *create_cow_out = 1; > > if(!openflags->w || > > - ((errno != EROFS) && (errno != EACCES))) > > return(-errno); + ((fd != -EROFS) && (fd != -EACCES))) > > return(fd); openflags->w = 0; > > fd = os_open_file(file, *openflags, mode); > > if(fd < 0) > > > > (Note that the patch is probably against ubd_user.c, actually. In my > > tree, I've almost completely moved it in ubd_kern.c). Ok - this is another problem, less foolish. Actually, moving the code from ubd_user.c to ubd_kern.c *should* work. However, it does not when referring to "errno". The kernel files are compiled with -Derrno=kernel_errno; while ubd_user should use the os_* functions return value, it can use errno without failure. I'll fix that. > > 3) Even with that applied, I got complaints from absolutize(). This is a problem from the shell: it does not expand the "~" in the backing file name, when using COW files. I'm fixing that by using ":" as separator for this case (which is understood by the shell; this requires fixing UML to understand this delimiter, which is a trivial fix). However, there is a real problem (which is less important, however): when the COW file is empty, UML does not fill it in. Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |