Thoughts on mounting the rootfs from a udev rule

Thoughts on mounting the rootfs from a udev rule

[Victor Lowther]

It seems that there are two major use cases that make mounting the root
file system directly from a udev rule an inadvisable design decision:

The first is when your root filesystem does not reside on a block
device, as in the nfsroot case.  In this case, there is no backing
device for the filesystem for udev to detect, so we would still need a
non-udev method of mounting the root filesystem in order to handle any
case where there is no backing device for the root filesystem.

The second is when we are asked to resume from hibernate.  In this case,
we must not attempt to mount the root filesystem (or any other
filesystem, for that matter) until we have either attempted to resume
(and failed) or we have determined that resuming is impossible.  Udev
does not make any guarantees about the order in which devices are
discovered, which leads to all sorts of interesting potential failure
modes when you have either or both of resume handling and rootfs
handling in a udev rule.

Thoughts?

-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Harald Hoyer]

Victor Lowther wrote:
> It seems that there are two major use cases that make mounting the root
> file system directly from a udev rule an inadvisable design decision:
> 
> The first is when your root filesystem does not reside on a block
> device, as in the nfsroot case.  In this case, there is no backing
> device for the filesystem for udev to detect, so we would still need a
> non-udev method of mounting the root filesystem in order to handle any
> case where there is no backing device for the root filesystem.
> 
> The second is when we are asked to resume from hibernate.  In this case,
> we must not attempt to mount the root filesystem (or any other
> filesystem, for that matter) until we have either attempted to resume
> (and failed) or we have determined that resuming is impossible.  Udev
> does not make any guarantees about the order in which devices are
> discovered, which leads to all sorts of interesting potential failure
> modes when you have either or both of resume handling and rootfs
> handling in a udev rule.
> 
> Thoughts?
> 

You are right.

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Hannes Reinecke]

Victor Lowther wrote:
> It seems that there are two major use cases that make mounting the root
> file system directly from a udev rule an inadvisable design decision:
> 
> The first is when your root filesystem does not reside on a block
> device, as in the nfsroot case.  In this case, there is no backing
> device for the filesystem for udev to detect, so we would still need a
> non-udev method of mounting the root filesystem in order to handle any
> case where there is no backing device for the root filesystem.
> 
Hmm. There is no strict _need_ for a backing device for udev to work
properly, we just need an event here.
So for the nfsroot case it would be totally sufficient to have an event
like 'network is up'. This could then trigger a nfsmount

> The second is when we are asked to resume from hibernate.  In this case,
> we must not attempt to mount the root filesystem (or any other
> filesystem, for that matter) until we have either attempted to resume
> (and failed) or we have determined that resuming is impossible.  Udev
> does not make any guarantees about the order in which devices are
> discovered, which leads to all sorts of interesting potential failure
> modes when you have either or both of resume handling and rootfs
> handling in a udev rule.
> 
Ah, that's ok. In these cases you'll have a 'resume=' argument in
the kernel commandline, so you just need to write a rule using an
event serializer/capture like 'collect':
- Use three arguments to collect, root device, resume device, and
  another one signifying 'resume_done'.
- Add another rule which triggers resume on the resume device, sets
  'resume_done' if resume returns, and triggers the collect rule again.
- Then collect will return 1 and start the mount process.

No problem there. However, you're still facing the problem that you'd
might want to run 'fsck' on the root device. And you might want to
know when 'mount' has actually finished, as only then you can execute
'init'. Sadly the 'mount' events are gone from the kernel, otherwise
it would've been quite handy here.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Victor Lowther]

On Fri, 2009-03-20 at 09:31 +0100, Hannes Reinecke wrote:
> Victor Lowther wrote:
> > It seems that there are two major use cases that make mounting the root
> > file system directly from a udev rule an inadvisable design decision:
> > 
> > The first is when your root filesystem does not reside on a block
> > device, as in the nfsroot case.  In this case, there is no backing
> > device for the filesystem for udev to detect, so we would still need a
> > non-udev method of mounting the root filesystem in order to handle any
> > case where there is no backing device for the root filesystem.
> > 
> Hmm. There is no strict _need_ for a backing device for udev to work
> properly, we just need an event here.
> So for the nfsroot case it would be totally sufficient to have an event
> like 'network is up'. This could then trigger a nfsmount

In simple cases, maybe.  In the sort of cases Seewer has to deal with,
it gets a great deal more complicated.

Driving network configuration from udev is easy and usually the right
thing to do, but doesn't really help when you don't know beforehand
which interface will actually be able to talk to the nfs server.

> > The second is when we are asked to resume from hibernate.  In this case,
> > we must not attempt to mount the root filesystem (or any other
> > filesystem, for that matter) until we have either attempted to resume
> > (and failed) or we have determined that resuming is impossible.  Udev
> > does not make any guarantees about the order in which devices are
> > discovered, which leads to all sorts of interesting potential failure
> > modes when you have either or both of resume handling and rootfs
> > handling in a udev rule.
> > 
> Ah, that's ok. In these cases you'll have a 'resume=' argument in
> the kernel commandline, so you just need to write a rule using an
> event serializer/capture like 'collect':
> - Use three arguments to collect, root device, resume device, and
>   another one signifying 'resume_done'.
> - Add another rule which triggers resume on the resume device, sets
>   'resume_done' if resume returns, and triggers the collect rule again.
> - Then collect will return 1 and start the mount process.

How does that handle the case where we asked to resume but the resume
device is not found?

Will it be easier to maintain than just waiting for all the devices to
be found and configured before trying to resume or mount anything?

> No problem there. However, you're still facing the problem that you'd
> might want to run 'fsck' on the root device. And you might want to
> know when 'mount' has actually finished, as only then you can execute
> 'init'. Sadly the 'mount' events are gone from the kernel, otherwise
> it would've been quite handy here.

Indeed.

> Cheers,
> 
> Hannes
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Seewer Philippe]

Victor Lowther wrote:
> It seems that there are two major use cases that make mounting the root
> file system directly from a udev rule an inadvisable design decision:
> 
> The first is when your root filesystem does not reside on a block
> device, as in the nfsroot case.  In this case, there is no backing
> device for the filesystem for udev to detect, so we would still need a
> non-udev method of mounting the root filesystem in order to handle any
> case where there is no backing device for the root filesystem.
> 
> The second is when we are asked to resume from hibernate.  In this case,
> we must not attempt to mount the root filesystem (or any other
> filesystem, for that matter) until we have either attempted to resume
> (and failed) or we have determined that resuming is impossible.  Udev
> does not make any guarantees about the order in which devices are
> discovered, which leads to all sorts of interesting potential failure
> modes when you have either or both of resume handling and rootfs
> handling in a udev rule.
> 
> Thoughts?

 From experience with other software projects, having an event driven
system which asks 'something happened, what should I do' is preferrable
to having to write all the glue code yourself. And one of dracut's goals
is to get rid of as much shell code as possible no?

Question is: Are the described cases exlusive? I mean if udev does
something does it make thawing impossible? Of so, can we prevent it? Or
maybe just postpone starting udev or restart udev at a later point.

Regards,
Philippe



--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Seewer Philippe]

Hannes Reinecke wrote:
> Victor Lowther wrote:
>> It seems that there are two major use cases that make mounting the root
>> file system directly from a udev rule an inadvisable design decision:
>>
>> The first is when your root filesystem does not reside on a block
>> device, as in the nfsroot case.  In this case, there is no backing
>> device for the filesystem for udev to detect, so we would still need a
>> non-udev method of mounting the root filesystem in order to handle any
>> case where there is no backing device for the root filesystem.
>>
> Hmm. There is no strict _need_ for a backing device for udev to work
> properly, we just need an event here.
> So for the nfsroot case it would be totally sufficient to have an event
> like 'network is up'. This could then trigger a nfsmount

Hmmm... I haven't thought about that. Is it possible to send events to 
udev from Userspace?

Cheers,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Seewer Philippe]

Victor Lowther wrote:
[snip]
>> Hmm. There is no strict _need_ for a backing device for udev to work
>> properly, we just need an event here.
>> So for the nfsroot case it would be totally sufficient to have an event
>> like 'network is up'. This could then trigger a nfsmount
> 
> In simple cases, maybe.  In the sort of cases Seewer has to deal with,
> it gets a great deal more complicated.

Yes and no. The current implementation is sort of event-based. "Network 
is up, please test" means theres something in the fifo and we can go and 
try. The same could be done via udev, if we could tell it do so 
something. Only problem I see would be synchronizing asynchronous events.

> 
> Driving network configuration from udev is easy and usually the right
> thing to do, but doesn't really help when you don't know beforehand
> which interface will actually be able to talk to the nfs server.

Or even worse, if you receive mount-data through dhcp options. But even 
that could be handled somehow if we had to.

>>> The second is when we are asked to resume from hibernate.  In this case,
>>> we must not attempt to mount the root filesystem (or any other
>>> filesystem, for that matter) until we have either attempted to resume
>>> (and failed) or we have determined that resuming is impossible.  Udev
>>> does not make any guarantees about the order in which devices are
>>> discovered, which leads to all sorts of interesting potential failure
>>> modes when you have either or both of resume handling and rootfs
>>> handling in a udev rule.
>>>
>> Ah, that's ok. In these cases you'll have a 'resume=' argument in
>> the kernel commandline, so you just need to write a rule using an
>> event serializer/capture like 'collect':
>> - Use three arguments to collect, root device, resume device, and
>>   another one signifying 'resume_done'.
>> - Add another rule which triggers resume on the resume device, sets
>>   'resume_done' if resume returns, and triggers the collect rule again.
>> - Then collect will return 1 and start the mount process.
> 
> How does that handle the case where we asked to resume but the resume
> device is not found?

Question: If we know which device to resume from, why not have a 
pre-udev rule specifying _if_ that device shows up try to thaw?

> Will it be easier to maintain than just waiting for all the devices to
> be found and configured before trying to resume or mount anything?

I guess that depends on personal taste (and documentation)

>> No problem there. However, you're still facing the problem that you'd
>> might want to run 'fsck' on the root device. And you might want to
>> know when 'mount' has actually finished, as only then you can execute
>> 'init'. Sadly the 'mount' events are gone from the kernel, otherwise
>> it would've been quite handy here.

Again, is it possible to send events to udev from Userspace?

Regards,
Philippe
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Victor Lowther]

On Fri, 2009-03-20 at 10:15 +0100, Seewer Philippe wrote:
> Victor Lowther wrote:
> > It seems that there are two major use cases that make mounting the root
> > file system directly from a udev rule an inadvisable design decision:
> > 
> > The first is when your root filesystem does not reside on a block
> > device, as in the nfsroot case.  In this case, there is no backing
> > device for the filesystem for udev to detect, so we would still need a
> > non-udev method of mounting the root filesystem in order to handle any
> > case where there is no backing device for the root filesystem.
> > 
> > The second is when we are asked to resume from hibernate.  In this case,
> > we must not attempt to mount the root filesystem (or any other
> > filesystem, for that matter) until we have either attempted to resume
> > (and failed) or we have determined that resuming is impossible.  Udev
> > does not make any guarantees about the order in which devices are
> > discovered, which leads to all sorts of interesting potential failure
> > modes when you have either or both of resume handling and rootfs
> > handling in a udev rule.
> > 
> > Thoughts?
> 
>  From experience with other software projects, having an event driven
> system which asks 'something happened, what should I do' is preferrable
> to having to write all the glue code yourself. And one of dracut's goals
> is to get rid of as much shell code as possible no?

It is a tradeoff -- I have little doubt that we could force nearly
everything to happen as a direct result of a udev rule firing, but would
that result be more or less maintainable and understandable than a
hybrid solution?

> Question is: Are the described cases exlusive? I mean if udev does
> something does it make thawing impossible? Of so, can we prevent it? Or
> maybe just postpone starting udev or restart udev at a later point.

If you mount an ext3 filesystem it replays the journal whether or not
you mount it read-only.  If you do that when you were hibernated then
the filesystem will be dirty.  If at any point after journal replay has
started udev discovers the resume device an initiates a resume you have
just silently corrupted your root filesystem.  If you are lucky you
might be able to recover from it.

> Regards,
> Philippe
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe initramfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Victor Lowther]

On Fri, 2009-03-20 at 10:24 +0100, Seewer Philippe wrote:
> Victor Lowther wrote:
> [snip]
> >> Hmm. There is no strict _need_ for a backing device for udev to work
> >> properly, we just need an event here.
> >> So for the nfsroot case it would be totally sufficient to have an event
> >> like 'network is up'. This could then trigger a nfsmount
> > 
> > In simple cases, maybe.  In the sort of cases Seewer has to deal with,
> > it gets a great deal more complicated.
> 
> Yes and no. The current implementation is sort of event-based. "Network 
> is up, please test" means theres something in the fifo and we can go and 
> try. The same could be done via udev, if we could tell it do so 
> something. Only problem I see would be synchronizing asynchronous events.

As far as I know, you cannot inject an event into udev from userspace.
It responds to messages from the kernel and that is it.

> > Driving network configuration from udev is easy and usually the right
> > thing to do, but doesn't really help when you don't know beforehand
> > which interface will actually be able to talk to the nfs server.
> 
> Or even worse, if you receive mount-data through dhcp options. But even 
> that could be handled somehow if we had to.

Actually, that part should not be that hard -- just separate the "saving
info from dhclient" and "configuring the interface" phases.

> >>> The second is when we are asked to resume from hibernate.  In this case,
> >>> we must not attempt to mount the root filesystem (or any other
> >>> filesystem, for that matter) until we have either attempted to resume
> >>> (and failed) or we have determined that resuming is impossible.  Udev
> >>> does not make any guarantees about the order in which devices are
> >>> discovered, which leads to all sorts of interesting potential failure
> >>> modes when you have either or both of resume handling and rootfs
> >>> handling in a udev rule.
> >>>
> >> Ah, that's ok. In these cases you'll have a 'resume=' argument in
> >> the kernel commandline, so you just need to write a rule using an
> >> event serializer/capture like 'collect':
> >> - Use three arguments to collect, root device, resume device, and
> >>   another one signifying 'resume_done'.
> >> - Add another rule which triggers resume on the resume device, sets
> >>   'resume_done' if resume returns, and triggers the collect rule again.
> >> - Then collect will return 1 and start the mount process.
> > 
> > How does that handle the case where we asked to resume but the resume
> > device is not found?
> 
> Question: If we know which device to resume from, why not have a 
> pre-udev rule specifying _if_ that device shows up try to thaw?

If it shows up after we have already started mounting the root
filesystem we are hosed.

If it never shows up at all, things get interesting depending on exactly
how we want to handle that case.

> > Will it be easier to maintain than just waiting for all the devices to
> > be found and configured before trying to resume or mount anything?
> 
> I guess that depends on personal taste (and documentation)
> 
> >> No problem there. However, you're still facing the problem that you'd
> >> might want to run 'fsck' on the root device. And you might want to
> >> know when 'mount' has actually finished, as only then you can execute
> >> 'init'. Sadly the 'mount' events are gone from the kernel, otherwise
> >> it would've been quite handy here.
> 
> Again, is it possible to send events to udev from Userspace?
> 
> Regards,
> Philippe
-- 
Victor Lowther
RHCE# 805008539634727
LPIC-2# LPI000140019

--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Karel Zak]

On Fri, Mar 20, 2009 at 10:24:03AM +0100, Seewer Philippe wrote:
> Again, is it possible to send events to udev from Userspace?

 uevent files in /sys ?

 echo "change" > /sys/devices/pci0000:00/0000:00:19.0/net/eth0/uevent
 
    Karel

-- 
 Karel Zak  <kzak-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Seewer Philippe]

Karel Zak wrote:
> On Fri, Mar 20, 2009 at 10:24:03AM +0100, Seewer Philippe wrote:
>> Again, is it possible to send events to udev from Userspace?
> 
>  uevent files in /sys ?
> 
>  echo "change" > /sys/devices/pci0000:00/0000:00:19.0/net/eth0/uevent


good point! but... whatever I write in there, 'udevadm monitor' shows this:

UEVENT[1237554273.439387] add      /devices/pci0000:00/0000:00:19.0/net/eth0 (net)
UDEV  [1237554273.446993] add      /devices/pci0000:00/0000:00:19.0/net/eth0 (net)


>  
>     Karel
> 
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Kay Sievers]

On Fri, Mar 20, 2009 at 14:07, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org> wrote:
> Karel Zak wrote:
>>
>> On Fri, Mar 20, 2009 at 10:24:03AM +0100, Seewer Philippe wrote:
>>>
>>> Again, is it possible to send events to udev from Userspace?
>>
>>  uevent files in /sys ?
>>
>>  echo "change" > /sys/devices/pci0000:00/0000:00:19.0/net/eth0/uevent
>
>
> good point! but... whatever I write in there, 'udevadm monitor' shows this:
>
> UEVENT[1237554273.439387] add      /devices/pci0000:00/0000:00:19.0/net/eth0
> (net)
> UDEV  [1237554273.446993] add      /devices/pci0000:00/0000:00:19.0/net/eth0
> (net)

You got an ancient kernel? That was added very long ago to use match
valid event actions.

Kay
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Seewer Philippe]

Kay Sievers wrote:
> On Fri, Mar 20, 2009 at 14:07, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org> wrote:
>> Karel Zak wrote:
>>> On Fri, Mar 20, 2009 at 10:24:03AM +0100, Seewer Philippe wrote:
>>>> Again, is it possible to send events to udev from Userspace?
>>>  uevent files in /sys ?
>>>
>>>  echo "change" > /sys/devices/pci0000:00/0000:00:19.0/net/eth0/uevent
>>
>> good point! but... whatever I write in there, 'udevadm monitor' shows this:
>>
>> UEVENT[1237554273.439387] add      /devices/pci0000:00/0000:00:19.0/net/eth0
>> (net)
>> UDEV  [1237554273.446993] add      /devices/pci0000:00/0000:00:19.0/net/eth0
>> (net)
> 
> You got an ancient kernel? That was added very long ago to use match
> valid event actions.

Same behaviour on:
-Ubuntu 8.10 stock 2.6.27-11-generic
-Debian 5.0 stock 2.6.26-1-686


--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Kay Sievers]

On Fri, Mar 20, 2009 at 14:22, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org> wrote:
> Kay Sievers wrote:
>> On Fri, Mar 20, 2009 at 14:07, Seewer Philippe <philippe.seewer@bfh.ch>
>> wrote:
>>>
>>> Karel Zak wrote:
>>>>
>>>> On Fri, Mar 20, 2009 at 10:24:03AM +0100, Seewer Philippe wrote:
>>>>>
>>>>> Again, is it possible to send events to udev from Userspace?
>>>>
>>>>  uevent files in /sys ?
>>>>
>>>>  echo "change" > /sys/devices/pci0000:00/0000:00:19.0/net/eth0/uevent
>>>
>>> good point! but... whatever I write in there, 'udevadm monitor' shows
>>> this:
>>>
>>> UEVENT[1237554273.439387] add
>>>  /devices/pci0000:00/0000:00:19.0/net/eth0
>>> (net)
>>> UDEV  [1237554273.446993] add
>>>  /devices/pci0000:00/0000:00:19.0/net/eth0
>>> (net)
>>
>> You got an ancient kernel? That was added very long ago to use match
>> valid event actions.
>
> Same behaviour on:
> -Ubuntu 8.10 stock 2.6.27-11-generic
> -Debian 5.0 stock 2.6.26-1-686

Oh, that's fine. You got a warning in dmesg, I guess, saying that you
did not write a proper string to the file? It's falling back to 'add'
then. Make sure you are not writing invalid action strings to it.

Kay
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Seewer Philippe]

Kay Sievers wrote:
> On Fri, Mar 20, 2009 at 14:22, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org> wrote:
>> Kay Sievers wrote:
>>> On Fri, Mar 20, 2009 at 14:07, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org>
>>> wrote:
>>>> Karel Zak wrote:
>>>>> On Fri, Mar 20, 2009 at 10:24:03AM +0100, Seewer Philippe wrote:
>>>>>> Again, is it possible to send events to udev from Userspace?
>>>>>  uevent files in /sys ?
>>>>>
>>>>>  echo "change" > /sys/devices/pci0000:00/0000:00:19.0/net/eth0/uevent
>>>> good point! but... whatever I write in there, 'udevadm monitor' shows
>>>> this:
>>>>
>>>> UEVENT[1237554273.439387] add
>>>>  /devices/pci0000:00/0000:00:19.0/net/eth0
>>>> (net)
>>>> UDEV  [1237554273.446993] add
>>>>  /devices/pci0000:00/0000:00:19.0/net/eth0
>>>> (net)
>>> You got an ancient kernel? That was added very long ago to use match
>>> valid event actions.
>> Same behaviour on:
>> -Ubuntu 8.10 stock 2.6.27-11-generic
>> -Debian 5.0 stock 2.6.26-1-686
> 
> Oh, that's fine. You got a warning in dmesg, I guess, saying that you
> did not write a proper string to the file? It's falling back to 'add'
> then. Make sure you are not writing invalid action strings to it.

That is correct. How do I find out which action strings are correct?

> 
> Kay
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Kay Sievers]

On Fri, Mar 20, 2009 at 14:47, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org> wrote:
> Kay Sievers wrote:

>>>> You got an ancient kernel? That was added very long ago to use match
>>>> valid event actions.
>>>
>>> Same behaviour on:
>>> -Ubuntu 8.10 stock 2.6.27-11-generic
>>> -Debian 5.0 stock 2.6.26-1-686
>>
>> Oh, that's fine. You got a warning in dmesg, I guess, saying that you
>> did not write a proper string to the file? It's falling back to 'add'
>> then. Make sure you are not writing invalid action strings to it.
>
> That is correct. How do I find out which action strings are correct?

They are defined in the kernel:
  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=lib/kobject_uevent.c;hb=HEAD#l35

There is only 'add' and 'change' interesting. Only for testing,
'remove' might be useful too.

Kay
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Seewer Philippe]

Kay Sievers wrote:
> On Fri, Mar 20, 2009 at 14:47, Seewer Philippe <philippe.seewer-omB+W0Dpw2o@public.gmane.org> wrote:
>> Kay Sievers wrote:
> 
>>>>> You got an ancient kernel? That was added very long ago to use match
>>>>> valid event actions.
>>>> Same behaviour on:
>>>> -Ubuntu 8.10 stock 2.6.27-11-generic
>>>> -Debian 5.0 stock 2.6.26-1-686
>>> Oh, that's fine. You got a warning in dmesg, I guess, saying that you
>>> did not write a proper string to the file? It's falling back to 'add'
>>> then. Make sure you are not writing invalid action strings to it.
>> That is correct. How do I find out which action strings are correct?
> 
> They are defined in the kernel:
>   http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=lib/kobject_uevent.c;hb=HEAD#l35
> 
> There is only 'add' and 'change' interesting. Only for testing,
> 'remove' might be useful too.

Great! Will look into it if we can get rid of the network fifo.

thanks!

> 
> Kay
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Thoughts on mounting the rootfs from a udev rule

[Adam Spragg]

Victor Lowther wrote:
> If you mount an ext3 filesystem it replays the journal whether or not
> you mount it read-only.

According to the documentation patch at:

http://patchwork.kernel.org/patch/940/

you can mount ext3 as ro,noload which will not replay the journal.

Although those emails are dated Jan 2009, I'm not sure how old that actual
feature is, or what kernels it might be in.

Adam

-- 
The fundamental cause of the trouble is that in the modern world the
stupid are cocksure while the intelligent are full of doubt.
    -- Bertrand Russell
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html