user-mode-linux-user

Re: [uml-user] UML for ARM processors?

[richard -r. w. <ric...@gm...>]

On Mon, Oct 3, 2011 at 9:32 AM, Troy Piggins <tro...@pi...> wrote:
> Hi there.  I'm running an ARM-based Dreamplug with Debian Squeeze on
> it.  Contemplating trying UML virtual machines on it, but not sure
> if that's possible.  Any ideas or pointers?

No. Currently UML runs on only on x86_{32,64}.
AFAIK Al Viro is working on a PPC port.

-- 
Thanks,
//richard

[uml-user] UML for ARM processors?

[Troy P. <tro...@pi...>]

Hi there.  I'm running an ARM-based Dreamplug with Debian Squeeze on
it.  Contemplating trying UML virtual machines on it, but not sure
if that's possible.  Any ideas or pointers?

-- 
Troy Piggins

Re: [uml-user] udev hangs on boot when using a cow file

[richard -r. w. <ric...@gm...>]

On Wed, Sep 28, 2011 at 10:04 PM, Dan Bassett <dba...@or...> wrote:
>
>
> On 09/28/2011 02:53 PM, richard -rw- weinberger wrote:
>>
>> On Tue, Sep 27, 2011 at 7:09 PM, Dan Bassett<dba...@or...>  wrote:
>>
>>>
>>> I did some more digging after finding some more debugging flags for
>>> start_udev and I have more information today.  After serializing udev's
>>> startup process, it looks like the boot process always hangs in the same
>>> spot.  During the processing of the persistent storage rules that ship
>>> with
>>> udev, the following rule is encountered:
>>>
>>> KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
>>>
>>> This results in /sbin/blkid being run for ubd0/a as such:
>>>
>>> util_run_program: '/sbin/blkid -o udev -p /dev/.tmp-block-98:0' started
>>>
>>
>> The attached patch should fix the issue.
>> Please confirm. :-)
>>
>
> Richard-
> Yes, I can confirm that the patch works.  Thanks for fixing this!

Perfect. :)

-- 
Thanks,
//richard

Re: [uml-user] udev hangs on boot when using a cow file

[Dan B. <dba...@or...>]

On 09/28/2011 02:53 PM, richard -rw- weinberger wrote:
> On Tue, Sep 27, 2011 at 7:09 PM, Dan Bassett<dba...@or...>  wrote:
>    
>> I did some more digging after finding some more debugging flags for
>> start_udev and I have more information today.  After serializing udev's
>> startup process, it looks like the boot process always hangs in the same
>> spot.  During the processing of the persistent storage rules that ship with
>> udev, the following rule is encountered:
>>
>> KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
>>
>> This results in /sbin/blkid being run for ubd0/a as such:
>>
>> util_run_program: '/sbin/blkid -o udev -p /dev/.tmp-block-98:0' started
>>      
> The attached patch should fix the issue.
> Please confirm. :-)
>    
Richard-
Yes, I can confirm that the patch works.  Thanks for fixing this!

Dan

Re: [uml-user] udev hangs on boot when using a cow file

[richard -r. w. <ric...@gm...>]

On Tue, Sep 27, 2011 at 7:09 PM, Dan Bassett <dba...@or...> wrote:
> I did some more digging after finding some more debugging flags for
> start_udev and I have more information today.  After serializing udev's
> startup process, it looks like the boot process always hangs in the same
> spot.  During the processing of the persistent storage rules that ship with
> udev, the following rule is encountered:
>
> KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
>
> This results in /sbin/blkid being run for ubd0/a as such:
>
> util_run_program: '/sbin/blkid -o udev -p /dev/.tmp-block-98:0' started

The attached patch should fix the issue.
Please confirm. :-)

-- 
Thanks,
//richard

Re: [uml-user] udev hangs on boot when using a cow file

[richard -r. w. <ric...@gm...>]

On Tue, Sep 27, 2011 at 7:09 PM, Dan Bassett <dba...@or...> wrote:
> I did some more digging after finding some more debugging flags for
> start_udev and I have more information today.  After serializing udev's
> startup process, it looks like the boot process always hangs in the same
> spot.  During the processing of the persistent storage rules that ship with
> udev, the following rule is encountered:
>
> KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
>
> This results in /sbin/blkid being run for ubd0/a as such:
>
> util_run_program: '/sbin/blkid -o udev -p /dev/.tmp-block-98:0' started

The attached patch should fix the issue.
Please confirm. :-)

-- 
Thanks,
//richard

Re: [uml-user] udev hangs on boot when using a cow file

[richard -r. w. <ric...@gm...>]

On Tue, Sep 27, 2011 at 7:09 PM, Dan Bassett <dba...@or...> wrote:
> I did some more digging after finding some more debugging flags for
> start_udev and I have more information today.  After serializing udev's
> startup process, it looks like the boot process always hangs in the same
> spot.  During the processing of the persistent storage rules that ship with
> udev, the following rule is encountered:
>
> KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"
>
> This results in /sbin/blkid being run for ubd0/a as such:
>
> util_run_program: '/sbin/blkid -o udev -p /dev/.tmp-block-98:0' started
>

Can you please test the attached patch?
I should trigger the BUG_ON().

There is definitely something fishy...

-- 
Thanks,
//richard

Re: [uml-user] udev hangs on boot when using a cow file

[Dan B. <dba...@or...>]

On 09/26/2011 05:16 PM, Dan Bassett wrote:
> On 09/26/2011 04:04 PM, richard -rw- weinberger wrote:
>    
>> Dan,
>>
>> On Mon, Sep 26, 2011 at 6:27 PM, Dan Bassett<dba...@or...>   wrote:
>>
>>      
>>> I'm having issues when using cow files with CentOS6 system images.  It
>>> is specific to CentOS6.  When I tried with a debian image built with
>>> debootstrap, the system booted just fine.  I am experiencing this issue
>>> both with a custom built UML kernel as well as the kernel I obtained
>>> from the debian repository (2.6.32-1um-4+34squeeze1)
>>>
>>>        
>> Is the issue related to CentOS 6 or udev?
>> IOW does the same udev version work on e.g. Debian?
>>
>>      
> Actually It looks like udev isn't even installed on the Debian box, it
> must have a static /dev.  I think I may have assumed that this image
> built with debootstrap was more like a regular debian install than it
> actually is.  That doesn't really answer the question of why not
> specifying the backing storage file on the kernel command line would
> cause udev to hang, though.
>    
>>
>>      
>>> The issue I am experiencing is that during the boot process, udev hangs
>>> forever and the boot process does not complete.  It only occurs when I
>>> use a cow file by specifying just the cow file on the command line like
>>> "ubd0=cow_fs" rather than "ubd0=cow_fs,root_fs".  When I specify both
>>> the cow file and the backing file, the problem doesn't happen.  I am
>>> able to specify ubd0 either way with a debian image and the system boots
>>> as expected.  I have tried editing the appropriate rc script in the
>>> CentOS6 image to take udev out of the boot process, and the system
>>> boots, but has problems related to udev not running.
>>>
>>>        
>> Can you find out _where_ udev hangs?
>> Is it a endless loop? A blocking system call?
>>
>>
>>      
> I did some digging just now and found that in CentOS6, udev is
> initialized using a script at /sbin/start_udev.  I began putting echo
> statements here and there trying to narrow down where things were
> actually getting stuck and I found that it always happens at a "udevadm"
> command, and usually it's at a "udevadm settle".  I honestly don't know
> enough about udev and/or the uml cow format to make an educated (or even
> uneducated) guess as to why those particular commands hang.  If you have
> suggestions about other methods I could use to glean more debugging
> information, I would be happy to investigate further.
>
> I could just potentially throw up my hands, say "forget it" and go with
> a static /dev since I don't need a udev controlled /dev for this
> particular application, but it would be nice to debug this for future
> UML users all over the world :-)
>    
I did some more digging after finding some more debugging flags for 
start_udev and I have more information today.  After serializing udev's 
startup process, it looks like the boot process always hangs in the same 
spot.  During the processing of the persistent storage rules that ship 
with udev, the following rule is encountered:

KERNEL!="sr*", IMPORT{program}="/sbin/blkid -o udev -p $tempnode"

This results in /sbin/blkid being run for ubd0/a as such:

util_run_program: '/sbin/blkid -o udev -p /dev/.tmp-block-98:0' started

This is where it hangs.  From the blkid man page:

"The  blkid  program  is the command-line interface to working with 
libblkid(3) library.  It can determine the type of content (e.g.  
filesystem, swap)  a  block  device  holds,  and  also  attributes  
(tokens, NAME=value pairs)  from  the  content  metadata  (e.g.  LABEL  
or  UUID fields)."

So it sounds like udev is trying to use blkid to read metadata from 
ubd0/a and is failing.  Again, I don't know what goes on with the 
internals of the cow filesystem, so I don't know how specifying the 
backing store versus not specifying it would make a difference here.  
It's my understanding that the cow file contains the information for the 
backing store in a header of some sort and the kernel just takes care of 
opening the backing file and presenting the two to the system as ubd0/a.

Dan

Re: [uml-user] udev hangs on boot when using a cow file

[Dan B. <dba...@or...>]

On 09/26/2011 04:04 PM, richard -rw- weinberger wrote:
> Dan,
>
> On Mon, Sep 26, 2011 at 6:27 PM, Dan Bassett<dba...@or...>  wrote:
>    
>> I'm having issues when using cow files with CentOS6 system images.  It
>> is specific to CentOS6.  When I tried with a debian image built with
>> debootstrap, the system booted just fine.  I am experiencing this issue
>> both with a custom built UML kernel as well as the kernel I obtained
>> from the debian repository (2.6.32-1um-4+34squeeze1)
>>      
> Is the issue related to CentOS 6 or udev?
> IOW does the same udev version work on e.g. Debian?
>    
Actually It looks like udev isn't even installed on the Debian box, it 
must have a static /dev.  I think I may have assumed that this image 
built with debootstrap was more like a regular debian install than it 
actually is.  That doesn't really answer the question of why not 
specifying the backing storage file on the kernel command line would 
cause udev to hang, though.
>    
>> The issue I am experiencing is that during the boot process, udev hangs
>> forever and the boot process does not complete.  It only occurs when I
>> use a cow file by specifying just the cow file on the command line like
>> "ubd0=cow_fs" rather than "ubd0=cow_fs,root_fs".  When I specify both
>> the cow file and the backing file, the problem doesn't happen.  I am
>> able to specify ubd0 either way with a debian image and the system boots
>> as expected.  I have tried editing the appropriate rc script in the
>> CentOS6 image to take udev out of the boot process, and the system
>> boots, but has problems related to udev not running.
>>      
> Can you find out _where_ udev hangs?
> Is it a endless loop? A blocking system call?
>
>    
I did some digging just now and found that in CentOS6, udev is 
initialized using a script at /sbin/start_udev.  I began putting echo 
statements here and there trying to narrow down where things were 
actually getting stuck and I found that it always happens at a "udevadm" 
command, and usually it's at a "udevadm settle".  I honestly don't know 
enough about udev and/or the uml cow format to make an educated (or even 
uneducated) guess as to why those particular commands hang.  If you have 
suggestions about other methods I could use to glean more debugging 
information, I would be happy to investigate further.

I could just potentially throw up my hands, say "forget it" and go with 
a static /dev since I don't need a udev controlled /dev for this 
particular application, but it would be nice to debug this for future 
UML users all over the world :-)

Re: [uml-user] udev hangs on boot when using a cow file

[richard -r. w. <ric...@gm...>]

Dan,

On Mon, Sep 26, 2011 at 6:27 PM, Dan Bassett <dba...@or...> wrote:
> I'm having issues when using cow files with CentOS6 system images.  It
> is specific to CentOS6.  When I tried with a debian image built with
> debootstrap, the system booted just fine.  I am experiencing this issue
> both with a custom built UML kernel as well as the kernel I obtained
> from the debian repository (2.6.32-1um-4+34squeeze1)

Is the issue related to CentOS 6 or udev?
IOW does the same udev version work on e.g. Debian?

> The issue I am experiencing is that during the boot process, udev hangs
> forever and the boot process does not complete.  It only occurs when I
> use a cow file by specifying just the cow file on the command line like
> "ubd0=cow_fs" rather than "ubd0=cow_fs,root_fs".  When I specify both
> the cow file and the backing file, the problem doesn't happen.  I am
> able to specify ubd0 either way with a debian image and the system boots
> as expected.  I have tried editing the appropriate rc script in the
> CentOS6 image to take udev out of the boot process, and the system
> boots, but has problems related to udev not running.

Can you find out _where_ udev hangs?
Is it a endless loop? A blocking system call?

-- 
Thanks,
//richard

[uml-user] udev hangs on boot when using a cow file

[Dan B. <dba...@or...>]

I'm having issues when using cow files with CentOS6 system images.  It 
is specific to CentOS6.  When I tried with a debian image built with 
debootstrap, the system booted just fine.  I am experiencing this issue 
both with a custom built UML kernel as well as the kernel I obtained 
from the debian repository (2.6.32-1um-4+34squeeze1)

The issue I am experiencing is that during the boot process, udev hangs 
forever and the boot process does not complete.  It only occurs when I 
use a cow file by specifying just the cow file on the command line like 
"ubd0=cow_fs" rather than "ubd0=cow_fs,root_fs".  When I specify both 
the cow file and the backing file, the problem doesn't happen.  I am 
able to specify ubd0 either way with a debian image and the system boots 
as expected.  I have tried editing the appropriate rc script in the 
CentOS6 image to take udev out of the boot process, and the system 
boots, but has problems related to udev not running.

I have also tried specifying the "udevtimeout" parameter on the kernel 
command line to see if I could force it to time out quickly and carry on 
with booting, but that made no difference.  This leads me to believe 
that udev isn't just spinning it's wheels waiting for something, but 
it's actually hung or crashed.

I'm kind of at a loss here.  I don't know what interaction between the 
cow fs and udev would cause udev to hang, or if it's something that's 
only tangentially related to using the cow fs that's causing the 
problem.  It may even be a bug in udev.  I'm assuming that the kernel 
presents the block device ubd0/a to the system the same way, regardless 
if the device is specified to the kernel as "cow_file,backing_file" or 
just "cow_file", so I don't know why that would cause an issue.  
However, the manner that I use to specify ubd0 on the command line is 
literally the only thing that is different between a system that boots 
successfully, and one that hangs at starting udev.

The environment in which I run the UML kernel doesn't seem to make a 
difference; I have run the kernel on both my Debian Squeeze box and one 
of our CentOS6 servers (which is where these machines will be running in 
production).

Dan

Re: [uml-user] routing table error in 2.6.39 ..

[David M. <da...@da...>]

From: ratheesh kannoth <rat...@gm...>
Date: Thu, 22 Sep 2011 21:25:47 +0530

> in 2.6.38 routing  table is  correct. But in 2.6.39 default gw appears
> on top of the routing table. same problem persist in 3.0.0 also.

You cannot depend upon the order in which routing table entries
are listed by the kernel.

The table internally is correct, and lookups will match using the
proper longest-matching-prefix algorithm.

[uml-user] routing table error in 2.6.39 ..

[ratheesh k. <rat...@gm...>]

I built UML  (user mode linux ) for 2.6.38 and 2.6.39 kernels.

in 2.6.38 routing  table is  correct. But in 2.6.39 default gw appears
on top of the routing table. same problem persist in 3.0.0 also.

is it a known problem or fixed in higher versions ?

-Ratheesh

Re: [uml-user] [PATCH 19/55] um: irq: Remove IRQF_DISABLED

[Richard W. <ri...@no...>]

Am 22.09.2011 10:58, schrieb Yong Zhang:
> Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
> We run all interrupt handlers with interrupts disabled
> and we even check and yell when an interrupt handler
> returns with interrupts enabled (see commit [b738a50a:
> genirq: Warn when handler enables interrupts]).
> 
> So now this flag is a NOOP and can be removed.
> 
> Signed-off-by: Yong Zhang <yon...@gm...>

Acked-by: Richard Weinberger <ri...@no...>

[uml-user] [PATCH 19/55] um: irq: Remove IRQF_DISABLED

[Yong Z. <yon...@gm...>]

Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn when handler enables interrupts]).

So now this flag is a NOOP and can be removed.

Signed-off-by: Yong Zhang <yon...@gm...>
---
 arch/um/drivers/line.c          |    8 ++++----
 arch/um/drivers/mconsole_kern.c |    2 +-
 arch/um/drivers/net_kern.c      |    2 +-
 arch/um/drivers/port_kern.c     |    4 ++--
 arch/um/drivers/random.c        |    2 +-
 arch/um/drivers/ubd_kern.c      |    2 +-
 arch/um/drivers/xterm_kern.c    |    2 +-
 arch/um/kernel/sigio.c          |    2 +-
 arch/um/kernel/time.c           |    2 +-
 9 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c
index 364c8a1..d38f475 100644
--- a/arch/um/drivers/line.c
+++ b/arch/um/drivers/line.c
@@ -347,8 +347,8 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
 	int err;
 
 	/*
-	 * Interrupts are disabled here because we registered the interrupt with
-	 * IRQF_DISABLED (see line_setup_irq).
+	 * Interrupts are disabled here because genirq keep irqs disabled when
+	 * calling the action handler.
 	 */
 
 	spin_lock(&line->lock);
@@ -371,7 +371,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
 int line_setup_irq(int fd, int input, int output, struct line *line, void *data)
 {
 	const struct line_driver *driver = line->driver;
-	int err = 0, flags = IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM;
+	int err = 0, flags = IRQF_SHARED | IRQF_SAMPLE_RANDOM;
 
 	if (input)
 		err = um_request_irq(driver->read_irq, fd, IRQ_READ,
@@ -807,7 +807,7 @@ void register_winch_irq(int fd, int tty_fd, int pid, struct tty_struct *tty,
 				   .stack	= stack });
 
 	if (um_request_irq(WINCH_IRQ, fd, IRQ_READ, winch_interrupt,
-			   IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+			   IRQF_SHARED | IRQF_SAMPLE_RANDOM,
 			   "winch", winch) < 0) {
 		printk(KERN_ERR "register_winch_irq - failed to register "
 		       "IRQ\n");
diff --git a/arch/um/drivers/mconsole_kern.c b/arch/um/drivers/mconsole_kern.c
index c70e047..e672bd6 100644
--- a/arch/um/drivers/mconsole_kern.c
+++ b/arch/um/drivers/mconsole_kern.c
@@ -773,7 +773,7 @@ static int __init mconsole_init(void)
 	register_reboot_notifier(&reboot_notifier);
 
 	err = um_request_irq(MCONSOLE_IRQ, sock, IRQ_READ, mconsole_interrupt,
-			     IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+			     IRQF_SHARED | IRQF_SAMPLE_RANDOM,
 			     "mconsole", (void *)sock);
 	if (err) {
 		printk(KERN_ERR "Failed to get IRQ for management console\n");
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index a492e59..46ffd65 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -161,7 +161,7 @@ static int uml_net_open(struct net_device *dev)
 	}
 
 	err = um_request_irq(dev->irq, lp->fd, IRQ_READ, uml_net_interrupt,
-			     IRQF_DISABLED | IRQF_SHARED, dev->name, dev);
+			     IRQF_SHARED, dev->name, dev);
 	if (err != 0) {
 		printk(KERN_ERR "uml_net_open: failed to get irq(%d)\n", err);
 		err = -ENETUNREACH;
diff --git a/arch/um/drivers/port_kern.c b/arch/um/drivers/port_kern.c
index a11573b..e31680e 100644
--- a/arch/um/drivers/port_kern.c
+++ b/arch/um/drivers/port_kern.c
@@ -100,7 +100,7 @@ static int port_accept(struct port_list *port)
 		  .port 	= port });
 
 	if (um_request_irq(TELNETD_IRQ, socket[0], IRQ_READ, pipe_interrupt,
-			  IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+			  IRQF_SHARED | IRQF_SAMPLE_RANDOM,
 			  "telnetd", conn)) {
 		printk(KERN_ERR "port_accept : failed to get IRQ for "
 		       "telnetd\n");
@@ -184,7 +184,7 @@ void *port_data(int port_num)
 	}
 
 	if (um_request_irq(ACCEPT_IRQ, fd, IRQ_READ, port_interrupt,
-			  IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+			  IRQF_SHARED | IRQF_SAMPLE_RANDOM,
 			  "port", port)) {
 		printk(KERN_ERR "Failed to get IRQ for port %d\n", port_num);
 		goto out_close;
diff --git a/arch/um/drivers/random.c b/arch/um/drivers/random.c
index 981085a..b25296e 100644
--- a/arch/um/drivers/random.c
+++ b/arch/um/drivers/random.c
@@ -131,7 +131,7 @@ static int __init rng_init (void)
 	random_fd = err;
 
 	err = um_request_irq(RANDOM_IRQ, random_fd, IRQ_READ, random_interrupt,
-			     IRQF_DISABLED | IRQF_SAMPLE_RANDOM, "random",
+			     IRQF_SAMPLE_RANDOM, "random",
 			     NULL);
 	if (err)
 		goto err_out_cleanup_hw;
diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index 620f5b7..c9dae89 100644
--- a/arch/um/drivers/ubd_kern.c
+++ b/arch/um/drivers/ubd_kern.c
@@ -1088,7 +1088,7 @@ static int __init ubd_driver_init(void){
 		return 0;
 	}
 	err = um_request_irq(UBD_IRQ, thread_fd, IRQ_READ, ubd_intr,
-			     IRQF_DISABLED, "ubd", ubd_devs);
+			     0, "ubd", ubd_devs);
 	if(err != 0)
 		printk(KERN_ERR "um_request_irq failed - errno = %d\n", -err);
 	return 0;
diff --git a/arch/um/drivers/xterm_kern.c b/arch/um/drivers/xterm_kern.c
index b646bcc..8bd130f 100644
--- a/arch/um/drivers/xterm_kern.c
+++ b/arch/um/drivers/xterm_kern.c
@@ -50,7 +50,7 @@ int xterm_fd(int socket, int *pid_out)
 	init_completion(&data->ready);
 
 	err = um_request_irq(XTERM_IRQ, socket, IRQ_READ, xterm_interrupt,
-			     IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+			     IRQF_SHARED | IRQF_SAMPLE_RANDOM,
 			     "xterm", data);
 	if (err) {
 		printk(KERN_ERR "xterm_fd : failed to get IRQ for xterm, "
diff --git a/arch/um/kernel/sigio.c b/arch/um/kernel/sigio.c
index 2b272b6..2a16392 100644
--- a/arch/um/kernel/sigio.c
+++ b/arch/um/kernel/sigio.c
@@ -25,7 +25,7 @@ int write_sigio_irq(int fd)
 	int err;
 
 	err = um_request_irq(SIGIO_WRITE_IRQ, fd, IRQ_READ, sigio_interrupt,
-			     IRQF_DISABLED|IRQF_SAMPLE_RANDOM, "write sigio",
+			     IRQF_SAMPLE_RANDOM, "write sigio",
 			     NULL);
 	if (err) {
 		printk(KERN_ERR "write_sigio_irq : um_request_irq failed, "
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index a08d9fa..9149b5f 100644
--- a/arch/um/kernel/time.c
+++ b/arch/um/kernel/time.c
@@ -84,7 +84,7 @@ static void __init setup_itimer(void)
 {
 	int err;
 
-	err = request_irq(TIMER_IRQ, um_timer, IRQF_DISABLED, "timer", NULL);
+	err = request_irq(TIMER_IRQ, um_timer, 0, "timer", NULL);
 	if (err != 0)
 		printk(KERN_ERR "register_timer : request_irq failed - "
 		       "errno = %d\n", -err);
-- 
1.7.4.1

Re: [uml-user] Adding bytes to physical memory to account for exec-shield gap Aborted

[richard -r. w. <ric...@gm...>]

On Wed, Sep 21, 2011 at 11:33 AM, ratheesh kannoth
<rat...@gm...> wrote:
> Hi,
>
> i downloaded linux 2.6.31 version and compiled for  ARCH=um
> SUBARCH=i386 ( 32bit uml)
>
> my linux machine (64bit ubunt lucid )  gcc  version is  (Ubuntu
> 4.4.3-4ubuntu5) 4.4.3

Can you please try a newer kernel?
.31 is very old.

-- 
Thanks,
//richard

[uml-user] Adding bytes to physical memory to account for exec-shield gap Aborted

[ratheesh k. <rat...@gm...>]

Hi,

i downloaded linux 2.6.31 version and compiled for  ARCH=um
SUBARCH=i386 ( 32bit uml)

my linux machine (64bit ubunt lucid )  gcc  version is  (Ubuntu
4.4.3-4ubuntu5) 4.4.3


root@dasaradham-laptop:/home/fox/workout/torvalds-linux-a271b16#
./linux ubda=/media/Mars/ubuntu/ubuntu-ext3-2gb-root.fs  mem=128M
Locating the bottom of the address space ... 0x0
Locating the top of the address space ... 0xffffd000
Core dump limits :
       soft - 0
       hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking for tmpfs mount on /dev/shm...OK
Checking PROT_EXEC mmap in /dev/shm/...OK
Checking for the skas3 patch in the host:
 - /proc/mm...not found: No such file or directory
 - PTRACE_FAULTINFO...not found
 - PTRACE_LDT...not found
UML running in SKAS0 mode
Adding 5664768 bytes to physical memory to account for exec-shield gap
Aborted


i did a gdb  to get a back trace



root@dasaradham-laptop:/home/fox/workout/torvalds-linux-a271b16# gdb
./linux core
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/fox/workout/torvalds-linux-a271b16/linux...bdone.
[New Thread 2174]

warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib32/libutil.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib32/libutil.so.1
Reading symbols from /lib32/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib32/libc.so.6
Reading symbols from /lib/ld-linux.so.2...
warning: the debug information found in "/lib/ld-2.11.1.so" does not
match "/lib/ld-linux.so.2" (CRC mismatch).

(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `./linux
ubda=/media/Mars/ubuntu/ubuntu-ext3-2gb-root.fs mem=128M'.
Program terminated with signal 6, Aborted.
#0  0xf7760430 in __kernel_vsyscall ()
(gdb) bt
#0  0xf7760430 in __kernel_vsyscall ()
#1  0xf760a921 in raise () from /lib32/libc.so.6
#2  0xf760dd52 in abort () from /lib32/libc.so.6
#3  0x0806ff2d in os_dump_core () at arch/um/os-Linux/util.c:119
#4  0x0805efe9 in panic_exit (self=0x8280288, unused1=0, unused2=0x8295780)
   at arch/um/kernel/um_arch.c:233
#5  0x080983dc in notifier_call_chain (nl=<value optimized out>,
   val=<value optimized out>, v=0x87e, nr_to_call=-1, nr_calls=0x0)
   at kernel/notifier.c:93
#6  0x08098453 in __atomic_notifier_call_chain (nh=0x8295740, val=0,
   v=0x8295780) at kernel/notifier.c:182
#7  atomic_notifier_call_chain (nh=0x8295740, val=0, v=0x8295780)
   at kernel/notifier.c:191
#8  0x08211d07 in panic (fmt=0x8242b3f "Kernel mode signal %d")
   at kernel/panic.c:91
#9  0x0805e7b7 in relay_signal (sig=4, regs=0x827e4f0)
   at arch/um/kernel/trap.c:228
#10 0x0806ebd4 in sig_handler_common (sig=4, sc=0x827e5a4)
   at arch/um/os-Linux/signal.c:49
#11 0x0806edaa in sig_handler (sig=0, sc=0x827e5a4)
   at arch/um/os-Linux/signal.c:226
#12 0x0806efec in handle_signal (sig=2174, sc=0x827e5a4)
   at arch/um/os-Linux/signal.c:158
---Type <return> to continue, or q <return> to quit---
#13 0x08071298 in hard_handler (sig=4) at arch/um/os-Linux/sys-i386/signal.c:12
#14 <signal handler called>
#15 run_posix_cpu_timers (tsk=0x827f600) at kernel/posix-cpu-timers.c:1389
#16 0x0808964d in update_process_times (user_tick=0) at kernel/timer.c:1163
#17 0x0809e741 in tick_periodic (cpu=<value optimized out>)
   at kernel/time/tick-common.c:72
#18 0x0809e7b1 in tick_handle_periodic (dev=0x82801a0)
   at kernel/time/tick-common.c:84
#19 0x0805d9c3 in um_timer (irq=0, dev=0x0) at arch/um/kernel/time.c:63
#20 0x080a979d in handle_IRQ_event (irq=0, action=0x10c4ab60)
   at kernel/irq/handle.c:376
#21 0x080a989e in __do_IRQ (irq=0) at kernel/irq/handle.c:518
#22 0x0805b675 in do_IRQ (irq=0, regs=0x827e9b8) at arch/um/kernel/irq.c:335
#23 0x0805da86 in timer_handler (sig=26, regs=0x827e9b8)
   at arch/um/kernel/time.c:21
#24 0x0806ece6 in real_alarm_handler (sc=<value optimized out>)
   at arch/um/os-Linux/signal.c:94
#25 0x0806ed62 in alarm_handler (sig=26, sc=0x827ea64)
   at arch/um/os-Linux/signal.c:226
#26 0x0806efec in handle_signal (sig=5, sc=0x827ea64)
   at arch/um/os-Linux/signal.c:158
#27 0x08071298 in hard_handler (sig=26)
   at arch/um/os-Linux/sys-i386/signal.c:12
---Type <return> to continue, or q <return> to quit---
#28 <signal handler called>
#29 calibrate_delay () at init/calibrate.c:146
#30 0x080495f4 in start_kernel () at init/main.c:685
#31 0x0804aac8 in start_kernel_proc (unused=0x0)
   at arch/um/kernel/skas/process.c:46
#32 0x0806d84e in run_kernel_thread (fn=0x804aa9a <start_kernel_proc>,
   arg=0x0, jmp_ptr=0x827f878) at arch/um/os-Linux/process.c:267
#33 0x0805c60e in new_thread_handler () at arch/um/kernel/process.c:151
#34 0x00000000 in ?? ()
(gdb)

[uml-user] [PATCH 19/57] um: irq: Remove IRQF_DISABLED

[Yong Z. <yon...@gm...>]

Since commit [c58543c8: genirq: Run irq handlers with interrupts disabled],
We run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler
returns with interrupts enabled (see commit [b738a50a:
genirq: Warn when handler enables interrupts]).

So now this flag is a NOOP and can be removed.

Signed-off-by: Yong Zhang <yon...@gm...>
---
 arch/um/drivers/line.c          |    8 ++++----
 arch/um/drivers/mconsole_kern.c |    2 +-
 arch/um/drivers/net_kern.c      |    2 +-
 arch/um/drivers/port_kern.c     |    4 ++--
 arch/um/drivers/random.c        |    2 +-
 arch/um/drivers/ubd_kern.c      |    2 +-
 arch/um/drivers/xterm_kern.c    |    2 +-
 arch/um/kernel/sigio.c          |    2 +-
 arch/um/kernel/time.c           |    2 +-
 9 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/um/drivers/line.c b/arch/um/drivers/line.c
index 364c8a1..d38f475 100644
--- a/arch/um/drivers/line.c
+++ b/arch/um/drivers/line.c
@@ -347,8 +347,8 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
 	int err;
 
 	/*
-	 * Interrupts are disabled here because we registered the interrupt with
-	 * IRQF_DISABLED (see line_setup_irq).
+	 * Interrupts are disabled here because genirq keep irqs disabled when
+	 * calling the action handler.
 	 */
 
 	spin_lock(&line->lock);
@@ -371,7 +371,7 @@ static irqreturn_t line_write_interrupt(int irq, void *data)
 int line_setup_irq(int fd, int input, int output, struct line *line, void *data)
 {
 	const struct line_driver *driver = line->driver;
-	int err = 0, flags = IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM;
+	int err = 0, flags = IRQF_SHARED | IRQF_SAMPLE_RANDOM;
 
 	if (input)
 		err = um_request_irq(driver->read_irq, fd, IRQ_READ,
@@ -807,7 +807,7 @@ void register_winch_irq(int fd, int tty_fd, int pid, struct tty_struct *tty,
 				   .stack	= stack });
 
 	if (um_request_irq(WINCH_IRQ, fd, IRQ_READ, winch_interrupt,
-			   IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+			   IRQF_SHARED | IRQF_SAMPLE_RANDOM,
 			   "winch", winch) < 0) {
 		printk(KERN_ERR "register_winch_irq - failed to register "
 		       "IRQ\n");
diff --git a/arch/um/drivers/mconsole_kern.c b/arch/um/drivers/mconsole_kern.c
index c70e047..e672bd6 100644
--- a/arch/um/drivers/mconsole_kern.c
+++ b/arch/um/drivers/mconsole_kern.c
@@ -773,7 +773,7 @@ static int __init mconsole_init(void)
 	register_reboot_notifier(&reboot_notifier);
 
 	err = um_request_irq(MCONSOLE_IRQ, sock, IRQ_READ, mconsole_interrupt,
-			     IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+			     IRQF_SHARED | IRQF_SAMPLE_RANDOM,
 			     "mconsole", (void *)sock);
 	if (err) {
 		printk(KERN_ERR "Failed to get IRQ for management console\n");
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index a492e59..46ffd65 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -161,7 +161,7 @@ static int uml_net_open(struct net_device *dev)
 	}
 
 	err = um_request_irq(dev->irq, lp->fd, IRQ_READ, uml_net_interrupt,
-			     IRQF_DISABLED | IRQF_SHARED, dev->name, dev);
+			     IRQF_SHARED, dev->name, dev);
 	if (err != 0) {
 		printk(KERN_ERR "uml_net_open: failed to get irq(%d)\n", err);
 		err = -ENETUNREACH;
diff --git a/arch/um/drivers/port_kern.c b/arch/um/drivers/port_kern.c
index a11573b..e31680e 100644
--- a/arch/um/drivers/port_kern.c
+++ b/arch/um/drivers/port_kern.c
@@ -100,7 +100,7 @@ static int port_accept(struct port_list *port)
 		  .port 	= port });
 
 	if (um_request_irq(TELNETD_IRQ, socket[0], IRQ_READ, pipe_interrupt,
-			  IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+			  IRQF_SHARED | IRQF_SAMPLE_RANDOM,
 			  "telnetd", conn)) {
 		printk(KERN_ERR "port_accept : failed to get IRQ for "
 		       "telnetd\n");
@@ -184,7 +184,7 @@ void *port_data(int port_num)
 	}
 
 	if (um_request_irq(ACCEPT_IRQ, fd, IRQ_READ, port_interrupt,
-			  IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+			  IRQF_SHARED | IRQF_SAMPLE_RANDOM,
 			  "port", port)) {
 		printk(KERN_ERR "Failed to get IRQ for port %d\n", port_num);
 		goto out_close;
diff --git a/arch/um/drivers/random.c b/arch/um/drivers/random.c
index 981085a..b25296e 100644
--- a/arch/um/drivers/random.c
+++ b/arch/um/drivers/random.c
@@ -131,7 +131,7 @@ static int __init rng_init (void)
 	random_fd = err;
 
 	err = um_request_irq(RANDOM_IRQ, random_fd, IRQ_READ, random_interrupt,
-			     IRQF_DISABLED | IRQF_SAMPLE_RANDOM, "random",
+			     IRQF_SAMPLE_RANDOM, "random",
 			     NULL);
 	if (err)
 		goto err_out_cleanup_hw;
diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index 620f5b7..c9dae89 100644
--- a/arch/um/drivers/ubd_kern.c
+++ b/arch/um/drivers/ubd_kern.c
@@ -1088,7 +1088,7 @@ static int __init ubd_driver_init(void){
 		return 0;
 	}
 	err = um_request_irq(UBD_IRQ, thread_fd, IRQ_READ, ubd_intr,
-			     IRQF_DISABLED, "ubd", ubd_devs);
+			     0, "ubd", ubd_devs);
 	if(err != 0)
 		printk(KERN_ERR "um_request_irq failed - errno = %d\n", -err);
 	return 0;
diff --git a/arch/um/drivers/xterm_kern.c b/arch/um/drivers/xterm_kern.c
index b646bcc..8bd130f 100644
--- a/arch/um/drivers/xterm_kern.c
+++ b/arch/um/drivers/xterm_kern.c
@@ -50,7 +50,7 @@ int xterm_fd(int socket, int *pid_out)
 	init_completion(&data->ready);
 
 	err = um_request_irq(XTERM_IRQ, socket, IRQ_READ, xterm_interrupt,
-			     IRQF_DISABLED | IRQF_SHARED | IRQF_SAMPLE_RANDOM,
+			     IRQF_SHARED | IRQF_SAMPLE_RANDOM,
 			     "xterm", data);
 	if (err) {
 		printk(KERN_ERR "xterm_fd : failed to get IRQ for xterm, "
diff --git a/arch/um/kernel/sigio.c b/arch/um/kernel/sigio.c
index 2b272b6..2a16392 100644
--- a/arch/um/kernel/sigio.c
+++ b/arch/um/kernel/sigio.c
@@ -25,7 +25,7 @@ int write_sigio_irq(int fd)
 	int err;
 
 	err = um_request_irq(SIGIO_WRITE_IRQ, fd, IRQ_READ, sigio_interrupt,
-			     IRQF_DISABLED|IRQF_SAMPLE_RANDOM, "write sigio",
+			     IRQF_SAMPLE_RANDOM, "write sigio",
 			     NULL);
 	if (err) {
 		printk(KERN_ERR "write_sigio_irq : um_request_irq failed, "
diff --git a/arch/um/kernel/time.c b/arch/um/kernel/time.c
index a08d9fa..9149b5f 100644
--- a/arch/um/kernel/time.c
+++ b/arch/um/kernel/time.c
@@ -84,7 +84,7 @@ static void __init setup_itimer(void)
 {
 	int err;
 
-	err = request_irq(TIMER_IRQ, um_timer, IRQF_DISABLED, "timer", NULL);
+	err = request_irq(TIMER_IRQ, um_timer, 0, "timer", NULL);
 	if (err != 0)
 		printk(KERN_ERR "register_timer : request_irq failed - "
 		       "errno = %d\n", -err);
-- 
1.7.4.1

Re: [uml-user] getcap/setcap in UML?

[Chris F. <cd...@fo...>]

On Tue, Sep 20, 2011 at 12:40:44AM +0200, richard -rw- weinberger wrote:
> > capget(0x20080522, 0, NULL) ? ? ? ? ? ? = 0
> > getxattr("/usr/libexec/pt_chown", "security.capability", 0xbf9444ac, 20) = -1 EOPNOTSUPP (Operation not supported)
> > write(2, "Failed to get capabilities of fi"..., 85Failed to get capabilities of file `/usr/libexec/pt_chown' (Operation not supported)
> > ) = 85
> >
> 
> Looks like your file system does not support extended attributes...
> Is  CONFIG_EXT4_FS_XATTR set? (In case you are using ext4).

Thanks.  It was off, and I was searching for a "CAPABILITY" option to enable.

Sorry for the noise.

- Chris

Re: [uml-user] getcap/setcap in UML?

[richard -r. w. <ric...@gm...>]

On Tue, Sep 20, 2011 at 12:27 AM, Chris Frey <cd...@fo...> wrote:
> On Tue, Sep 20, 2011 at 12:28:53AM +0200, richard -rw- weinberger wrote:
>> Can you run strace on it?
>> Let's see what the system call returns...
>
> I get this:
>
> capget(0x20080522, 0, NULL)             = 0
> getxattr("/usr/libexec/pt_chown", "security.capability", 0xbf9444ac, 20) = -1 EOPNOTSUPP (Operation not supported)
> write(2, "Failed to get capabilities of fi"..., 85Failed to get capabilities of file `/usr/libexec/pt_chown' (Operation not supported)
> ) = 85
>

Looks like your file system does not support extended attributes...
Is  CONFIG_EXT4_FS_XATTR set? (In case you are using ext4).

-- 
Thanks,
//richard

Re: [uml-user] getcap/setcap in UML?

[Chris F. <cd...@fo...>]

On Tue, Sep 20, 2011 at 12:28:53AM +0200, richard -rw- weinberger wrote:
> Can you run strace on it?
> Let's see what the system call returns...

I get this:

capget(0x20080522, 0, NULL)             = 0
getxattr("/usr/libexec/pt_chown", "security.capability", 0xbf9444ac, 20) = -1 EOPNOTSUPP (Operation not supported)
write(2, "Failed to get capabilities of fi"..., 85Failed to get capabilities of file `/usr/libexec/pt_chown' (Operation not supported)
) = 85


Full output below.

- Chris






[root@fedora15 ~]# strace getcap /usr/libexec/pt_chown 
execve("/usr/sbin/getcap", ["getcap", "/usr/libexec/pt_chown"], [/* 19 vars */]) = 0
brk(0)                                  = 0x804a000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001f000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=71835, ...}) = 0
mmap2(NULL, 71835, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40020000
close(3)                                = 0
open("/lib/libcap.so.2", O_RDONLY)      = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\r\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=15148, ...}) = 0
mmap2(NULL, 17908, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40032000
mmap2(0x40036000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0x40036000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\225\1\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=1854840, ...}) = 0
mmap2(NULL, 1620552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x40037000
mprotect(0x401bc000, 4096, PROT_NONE)   = 0
mmap2(0x401bd000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x185) = 0x401bd000
mmap2(0x401c0000, 10824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x401c0000
close(3)                                = 0
open("/lib/libattr.so.1", O_RDONLY)     = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\r\0\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=16816, ...}) = 0
mmap2(NULL, 19572, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x401c3000
mmap2(0x401c7000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0x401c7000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401c8000
set_thread_area({entry_number:-1 -> 6, base_addr:0x401c88d0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0x401bd000, 8192, PROT_READ)   = 0
mprotect(0x4001d000, 4096, PROT_READ)   = 0
munmap(0x40020000, 71835)               = 0
lstat64("/usr/libexec/pt_chown", {st_mode=S_IFREG|0755, st_size=23633, ...}) = 0
brk(0)                                  = 0x804a000
brk(0x806b000)                          = 0x806b000
brk(0)                                  = 0x806b000
capget(0x20080522, 0, NULL)             = 0
getxattr("/usr/libexec/pt_chown", "security.capability", 0xbf9444ac, 20) = -1 EOPNOTSUPP (Operation not supported)
write(2, "Failed to get capabilities of fi"..., 85Failed to get capabilities of file `/usr/libexec/pt_chown' (Operation not supported)
) = 85
exit_group(0)                           = ?

Re: [uml-user] getcap/setcap in UML?

[richard -r. w. <ric...@gm...>]

On Mon, Sep 19, 2011 at 11:44 PM, Chris Frey <cd...@fo...> wrote:
>
> When I run it manually, I get:
>
> [root@fedora15 ~]# getcap /usr/libexec/pt_chown
> Failed to get capabilities of file `/usr/libexec/pt_chown' (Operation not supported)
>

Can you run strace on it?
Let's see what the system call returns...

-- 
Thanks,
//richard

[uml-user] getcap/setcap in UML?

[Chris F. <cd...@fo...>]

Hi,

I'm running Fedora 15 in a UML VM, and during update, it tries to set
file capabilities on one file, and this appears to not be available.

When I run it manually, I get:

[root@fedora15 ~]# getcap /usr/libexec/pt_chown 
Failed to get capabilities of file `/usr/libexec/pt_chown' (Operation not supported)

Is this true?  Are file capabilities not available in UML?
I'm using a 2.6.35.5 based kernel.

Thanks,
- Chris

Re: [uml-user] modules are appended with "gdea2244-dirty" so unable to insmod custom modules

[Lakshmipathi.G <lak...@gm...>]

I would suggest adding all the necessary tools to your UML and
compiling the module from source within the UML instance itself
exclusively (make clean or remove any object files present).

Thanks for the suggestion. I found a solution,  Instead of compiling in it
host & copyinh it into uml (guest) or building it from within UML
instance- I added the module to kernel source itself ! Edited few kernel
Makefile +Kconfig +.config files  and build uml as usual, to my surprise
kernel builds my module too :D Now I can use the module ,since its comes
from uml kernel itself :D

Thanks Antoine and Jay for your help.


-- 
----
Cheers,
Lakshmipathi.G
FOSS Programmer.
www.giis.co.in

Re: [uml-user] modules are appended with "gdea2244-dirty" so unable to insmod custom modules

[Jay S. <jay...@gm...>]

> I'm working with assumption following should work .
> I compiled a module (myfs.ko) under host kernel 2.6.32.26-175.fc12. Now built uml from that kernel source (2.6.32.26).
> Logging into uml , I did hostfs mount and copied it into uml. now doing insmod gives following error message
> - (Or I need to compile the module within uml itself not from host and cp it ?) .
> UML# insmod myfs.ko
> myfs: version magic '2.6.32.26-175.fc12.x86_64 SMP mod_unload ' should be '2.6.32.26 mod_unload '
> insmod: error inserting 'myfs.ko': -1 Invalid module format

I would suggest adding all the necessary tools to your UML and
compiling the module from source within the UML instance itself
exclusively (make clean or remove any object files present). At least
this way, you will only attempt to use and link against libraries that
exist within UML (i.e., you will get compile time errors suggesting
libraries are missing which is much more verbose and helpful than what
you are getting now). However, I'm not a kernel expert but this has
worked for me in the past.

Jay