udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Kay Sievers]

Just a heads-up, because some tools like to "look into" /dev/.udev/.
With udev 167 there will be no /dev/.udev/ directory anymore.

The maintainers of the commonly used early-boot tools agreed to use a
/dev/.run/<package>/ dir instead, which will be provided by initramfs
and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
will be available at /var/run/. The /dev/.run/ directory is at that
point just an "early-boot alias" for /var/run/, and all early-boot
tools will have their data in /var/run/, just like any other service.
In the end, there should be no custom .-dirs left in /dev, besides
this "alias".

The command 'udevadm info --convert-db' is also gone. The udev daemon
converts any old database if needed on startup:
  [    3.708616] systemd-fsck[344]: Root directory is writable, skipping check.
  [    3.796452] udev[359]: converting old udev database
  [    3.856218] udev[359]: starting version 167

The udev source change is here:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h_59fa0900a5c127ce1a25d8ba3176f166662f96

If you support LVM, please make sure to conflict udev if neccessary
with older initramfs implementations, so that no new udev gets into an
old initramfs image, udev puts the data in /dev/.run/ which isn't its
own mountpoint, and the real root would overmount the udev directory.

Thanks,
Kay

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Marco d'Itri]

On Mar 15, Kay Sievers <kay.sievers@vrfy.org> wrote:

> The maintainers of the commonly used early-boot tools agreed to use a
> /dev/.run/<package>/ dir instead, which will be provided by initramfs
> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
> will be available at /var/run/. The /dev/.run/ directory is at that
> point just an "early-boot alias" for /var/run/, and all early-boot
> tools will have their data in /var/run/, just like any other service.
This looks complex and requiring coordination among multiple packages.
Where is the documentation of everything which needs to be done by the
surrounding boot scripts?
Will anything break if I still create an empty /dev/.udev/ for the
benefit of everything which checks for it to know if udev is running?

> If you support LVM, please make sure to conflict udev if neccessary
> with older initramfs implementations, so that no new udev gets into an
> old initramfs image, udev puts the data in /dev/.run/ which isn't its
> own mountpoint, and the real root would overmount the udev directory.
I am not sure that I understand this sentence.

-- 
ciao,
Marco

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Kay Sievers]

On Tue, Mar 15, 2011 at 18:38, Marco d'Itri <md@linux.it> wrote:
> On Mar 15, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> The maintainers of the commonly used early-boot tools agreed to use a
>> /dev/.run/<package>/ dir instead, which will be provided by initramfs
>> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
>> will be available at /var/run/. The /dev/.run/ directory is at that
>> point just an "early-boot alias" for /var/run/, and all early-boot
>> tools will have their data in /var/run/, just like any other service.
> This looks complex and requiring coordination among multiple packages.

> Where is the documentation of everything which needs to be done by the
> surrounding boot scripts?

I can't know, or document anything. The init scripts I maintain do not
know anything about /dev/.udev/.

> Will anything break if I still create an empty /dev/.udev/ for the
> benefit of everything which checks for it to know if udev is running?

I wouldn't do that. But it should work, if you don't create the db/
dir there, that would trigger the built-in converter. And please don't
make it a symlink to /dev/.run/, I don't know how that behaves.
Anyway, if you really still need that check, you should probably add a
command to 'udevadm info ...' using the libudev check, instead of
poking directories.

>> If you support LVM, please make sure to conflict udev if neccessary
>> with older initramfs implementations, so that no new udev gets into an
>> old initramfs image, udev puts the data in /dev/.run/ which isn't its
>> own mountpoint, and the real root would overmount the udev directory.
> I am not sure that I understand this sentence.

LVM needs the udev database from initramfs to be preserved.
Non-adapted initramfs images with the new udev might not create the
/dev/.run/ mountpoint, and any new init system will just overmount the
entire /dev/.run/ from initramfs, and the udev database is gone and
LVM will not find the udev database ....

Kay

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Marco d'Itri]

On Mar 16, Kay Sievers <kay.sievers@vrfy.org> wrote:

> >> The maintainers of the commonly used early-boot tools agreed to use a
> >> /dev/.run/<package>/ dir instead, which will be provided by initramfs
> >> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
> >> will be available at /var/run/. The /dev/.run/ directory is at that
> >> point just an "early-boot alias" for /var/run/, and all early-boot
> >> tools will have their data in /var/run/, just like any other service.
> > This looks complex and requiring coordination among multiple packages.
> > Where is the documentation of everything which needs to be done by the
> > surrounding boot scripts?
> I can't know, or document anything. The init scripts I maintain do not
> know anything about /dev/.udev/.
I am talking about this new /dev/.run/ thing. Where is it documented?

-- 
ciao,
Marco

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Kay Sievers]

On Wed, Mar 16, 2011 at 00:09, Marco d'Itri <md@linux.it> wrote:
> On Mar 16, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> >> The maintainers of the commonly used early-boot tools agreed to use a
>> >> /dev/.run/<package>/ dir instead, which will be provided by initramfs
>> >> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
>> >> will be available at /var/run/. The /dev/.run/ directory is at that
>> >> point just an "early-boot alias" for /var/run/, and all early-boot
>> >> tools will have their data in /var/run/, just like any other service.
>> > This looks complex and requiring coordination among multiple packages.
>> > Where is the documentation of everything which needs to be done by the
>> > surrounding boot scripts?
>> I can't know, or document anything. The init scripts I maintain do not
>> know anything about /dev/.udev/.
> I am talking about this new /dev/.run/ thing. Where is it documented?

So far only in code in systemd and dracut and the SUSE mkinitrd. It's
just a plain directory udev uses like /dev/.udev/ was. Udev itself
does not know anything about it. Old initramfs and init will just not
care, and udev just has a new directory with that name to put its
stuff into.

If modern initramfs and init are used, it is a tmpfs mountpoint that
will be the same as /var/run/.

Kay

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Scott James Remnant]

On Tue, Mar 15, 2011 at 4:14 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:

> If modern initramfs and init are used, it is a tmpfs mountpoint that
> will be the same as /var/run/.
>
I'm sick of this definition of "modern" to mean whatever you want ...
has this been even discussed with the authors or maintainers of any
other initramfs implementation than dracut?

Scott

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Kay Sievers]

On Wed, Mar 16, 2011 at 01:09, Scott James Remnant <scott@netsplit.com> wrote:
> On Tue, Mar 15, 2011 at 4:14 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> If modern initramfs and init are used, it is a tmpfs mountpoint that
>> will be the same as /var/run/.
>>
> I'm sick of this definition of "modern" to mean whatever you want ...
> has this been even discussed with the authors or maintainers of any
> other initramfs implementation than dracut?

You will recover from that sickness, I hope. :)

Kay

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Scott James Remnant]

On Tue, Mar 15, 2011 at 5:20 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> On Wed, Mar 16, 2011 at 01:09, Scott James Remnant <scott@netsplit.com> wrote:
>> On Tue, Mar 15, 2011 at 4:14 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>>
>>> If modern initramfs and init are used, it is a tmpfs mountpoint that
>>> will be the same as /var/run/.
>>>
>> I'm sick of this definition of "modern" to mean whatever you want ...
>> has this been even discussed with the authors or maintainers of any
>> other initramfs implementation than dracut?
>
> You will recover from that sickness, I hope. :)
>
That wasn't answering the question.

Have you discussed this with the authors or maintainers of any other
initramfs implementation then dracut?

Also:

Has a kernel patch been proposed for the vast majority of Linux
installations that aren't using either an initramfs or systemd?

Scott

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Scott James Remnant]

On Tue, Mar 15, 2011 at 10:25 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:

> The maintainers of the commonly used early-boot tools agreed to use a
> /dev/.run/<package>/ dir instead, which will be provided by initramfs
> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
> will be available at /var/run/. The /dev/.run/ directory is at that
> point just an "early-boot alias" for /var/run/, and all early-boot
> tools will have their data in /var/run/, just like any other service.
> In the end, there should be no custom .-dirs left in /dev, besides
> this "alias".
>
Kay has clarified in IM that the /dev/.run directory is bind-mounted
to /var/run later in the boot, so it's available at both paths always.
If other distros ignore that, then it's just a change of path for
udev.

Which makes me wonder why this is necessary at all.  Modern distros
have a tmpfs mounted on /var/run at all phases of the boot, mounting
it in the initramfs, binding it to the target filesystem, and ensuring
that it remains mounted even if an intermediate /var is placed in the
way.

So udev could simply use /var/run/udev all the time anyway

Scott

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Kay Sievers]

On Wed, Mar 16, 2011 at 01:34, Scott James Remnant <scott@netsplit.com> wrote:
> On Tue, Mar 15, 2011 at 10:25 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:

> Which makes me wonder why this is necessary at all.  Modern distros
> have a tmpfs mounted on /var/run at all phases of the boot, mounting
> it in the initramfs, binding it to the target filesystem, and ensuring
> that it remains mounted even if an intermediate /var is placed in the
> way.
>
> So udev could simply use /var/run/udev all the time anyway

Not really, it wouldn't work well on older systems without /var/run on
tmpfs, or separate /var.

The only sane alternative anyway is to introduce /run, not to fiddle
around an make assumptions what we have around on on-disk filesystems
on bootup.

Kay

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Greg KH]

On Tue, Mar 15, 2011 at 05:23:27PM -0700, Scott James Remnant wrote:
> On Tue, Mar 15, 2011 at 5:20 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> > On Wed, Mar 16, 2011 at 01:09, Scott James Remnant <scott@netsplit.com> wrote:
> >> On Tue, Mar 15, 2011 at 4:14 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
> >>
> >>> If modern initramfs and init are used, it is a tmpfs mountpoint that
> >>> will be the same as /var/run/.
> >>>
> >> I'm sick of this definition of "modern" to mean whatever you want ...
> >> has this been even discussed with the authors or maintainers of any
> >> other initramfs implementation than dracut?
> >
> > You will recover from that sickness, I hope. :)
> >
> That wasn't answering the question.
> 
> Have you discussed this with the authors or maintainers of any other
> initramfs implementation then dracut?

What other ones are actively developed these days?

> Has a kernel patch been proposed for the vast majority of Linux
> installations that aren't using either an initramfs or systemd?

Why would the kernel care about this?

confused,

greg k-h

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Scott James Remnant]

On Tue, Mar 15, 2011 at 6:11 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Mar 15, 2011 at 05:23:27PM -0700, Scott James Remnant wrote:
>> On Tue, Mar 15, 2011 at 5:20 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> > On Wed, Mar 16, 2011 at 01:09, Scott James Remnant <scott@netsplit.com> wrote:
>> >> On Tue, Mar 15, 2011 at 4:14 PM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>> >>
>> >>> If modern initramfs and init are used, it is a tmpfs mountpoint that
>> >>> will be the same as /var/run/.
>> >>>
>> >> I'm sick of this definition of "modern" to mean whatever you want ...
>> >> has this been even discussed with the authors or maintainers of any
>> >> other initramfs implementation than dracut?
>> >
>> > You will recover from that sickness, I hope. :)
>> >
>> That wasn't answering the question.
>>
>> Have you discussed this with the authors or maintainers of any other
>> initramfs implementation then dracut?
>
> What other ones are actively developed these days?
>
initramfs-tools is very actively developed

Scott

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Andrey Borzenkov]

On Wed, Mar 16, 2011 at 3:34 AM, Scott James Remnant <scott@netsplit.com> wrote:
> On Tue, Mar 15, 2011 at 10:25 AM, Kay Sievers <kay.sievers@vrfy.org> wrote:
>
>> The maintainers of the commonly used early-boot tools agreed to use a
>> /dev/.run/<package>/ dir instead, which will be provided by initramfs
>> and systemd. After the basic bootup, the /dev/.run/ tmpfs mountpoint
>> will be available at /var/run/. The /dev/.run/ directory is at that
>> point just an "early-boot alias" for /var/run/, and all early-boot
>> tools will have their data in /var/run/, just like any other service.
>> In the end, there should be no custom .-dirs left in /dev, besides
>> this "alias".
>>
> Kay has clarified in IM that the /dev/.run directory is bind-mounted
> to /var/run later in the boot, so it's available at both paths always.
> If other distros ignore that, then it's just a change of path for
> udev.
>
> Which makes me wonder why this is necessary at all.  Modern distros
> have a tmpfs mounted on /var/run at all phases of the boot,

there are several packages in Mandriva that install subdirectories in
/var/run and simply expect them to be present at any time. My first
try at tmpfs-mount /var/run under systemd was disaster. While I can
fix all those packages to install tmpfiles.d under systemd, I do not
see what can be sensibly done without (except extracting tmpfiles.d
from systemd into separate package).

So the question is - is all of this still going to work without this bind mount?

> mounting
> it in the initramfs, binding it to the target filesystem, and ensuring
> that it remains mounted even if an intermediate /var is placed in the
> way.
>
> So udev could simply use /var/run/udev all the time anyway
>

please, do not! For the reasons above ...

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Lennart Poettering]

On Thu, 17.03.11 13:24, Andrey Borzenkov (arvidjaar@gmail.com) wrote:

> > Kay has clarified in IM that the /dev/.run directory is bind-mounted
> > to /var/run later in the boot, so it's available at both paths always.
> > If other distros ignore that, then it's just a change of path for
> > udev.
> >
> > Which makes me wonder why this is necessary at all.  Modern distros
> > have a tmpfs mounted on /var/run at all phases of the boot,
> 
> there are several packages in Mandriva that install subdirectories in
> /var/run and simply expect them to be present at any time. My first
> try at tmpfs-mount /var/run under systemd was disaster. While I can
> fix all those packages to install tmpfiles.d under systemd, I do not
> see what can be sensibly done without (except extracting tmpfiles.d
> from systemd into separate package).
> 
> So the question is - is all of this still going to work without this
> bind mount?

For now I don't think too many things will break if /var/run is not a
tmpfs, and if /var/run is not bind mounted to /dev/.run. But sooner or
later this will probably break...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Scott James Remnant]

On Thu, Mar 17, 2011 at 7:39 AM, Lennart Poettering
<lennart@poettering.net> wrote:

> For now I don't think too many things will break if /var/run is not a
> tmpfs, and if /var/run is not bind mounted to /dev/.run. But sooner or
> later this will probably break...
>
For non-distribution Linux installs, having that extra mount is an
extra syscall on boot that could be done without.

Do you think it'd be a problem if software could have the option to
use /var/run directly without going through the /dev/.run alias?

(I guess this would be as simple as a configure option for thems that wants it)

Scott

Re: udev runtime data will move from /dev/.udev/ to /dev/.run/udev/

[Kay Sievers]

On Fri, Mar 18, 2011 at 23:12, Scott James Remnant <scott@netsplit.com> wrote:
> On Thu, Mar 17, 2011 at 7:39 AM, Lennart Poettering
> <lennart@poettering.net> wrote:
>
>> For now I don't think too many things will break if /var/run is not a
>> tmpfs, and if /var/run is not bind mounted to /dev/.run. But sooner or
>> later this will probably break...
>>
> For non-distribution Linux installs, having that extra mount is an
> extra syscall on boot that could be done without.
>
> Do you think it'd be a problem if software could have the option to
> use /var/run directly without going through the /dev/.run alias?
>
> (I guess this would be as simple as a configure option for thems that wants it)

Seems, after the last round of discussion we got for a simple /run
tmpfs now, and all these issues and fiddling with directories on an
on-disk /var will go away.

Kay