udevd "got lost" after moving /dev

udevd "got lost" after moving /dev

[Hai Zaar]

In initramfs I run udevd and populate /dev.
Then I mount new root to $NEWROOT.
Then I do the following:
            cd $NEWROOT
            udevcontrol stop_exec_queue
            mount -n --move /dev ./dev
            mount -n --move / .
            chroot /sbin/init >/dev/console </dev/console

In initramfs I have only storage-related modules. So some of the
events have failed. So in bootscripts, instead of triggering all of
the events again, I just want to:
            udevcontrols start_exec_queue
and then replay failed events. This would complete the coldplugging.

The problem is that after --move'ing and chrooting, udev behaves very
strange. It looks like it do not see the rules or something like that.
For example when I plug USB disk (logs are in the end of the message).
If I restart udevd somewhere in bootscripts, everythings works fine.

Is there something inconsistent in my setup?

udev logs (when I plug USB disk):
--------------------------------
1138709838 udevd[331] : udev_event_run: seq 577 forked, pid [2056],
'add' 'usb', 0 seconds old
1138709838 udevd[331] : udev_done: seq 577, pid [2056] exit with 0, 0
seconds old
1138709838 udevd[331] : udev_event_run: seq 578 forked, pid [2057],
'add' 'usb', 0 seconds old
1138709838 udevd[331] : udev_done: seq 578, pid [2057] exit with 0, 0
seconds old
1138709838 udevd[331] : udev_event_run: seq 579 forked, pid [2058],
'add' 'usb_device', 0 seconds old
1138709838 udevd[331] : udev_done: seq 579, pid [2058] exit with 0, 0
seconds old

udevmonitor output (when I plug USB disk):
-------------------------------------------
UEVENT[1138709934.391279] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-8
ACTION­d
DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-8
SUBSYSTEM=usb
SEQNUMX3
PHYSDEVBUS=usb
PHYSDEVDRIVER=usb

UEVENT[1138709934.391438] add@/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0
ACTION­d
DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-8/1-8:1.0
SUBSYSTEM=usb
SEQNUMX4
PHYSDEVBUS=usb
DEVICE=/proc/bus/usb/001/007
PRODUCT\x1058/701/240
TYPE=0/0/0
INTERFACE=8/6/80
MODALIAS=usb:v1058p0701d0240dc00dsc00dp00ic08isc06ip50

UEVENT[1138709934.391488] add@/class/usb_device/usbdev1.7
ACTION­d
DEVPATH=/class/usb_device/usbdev1.7
SUBSYSTEM=usb_device
SEQNUMX5
PHYSDEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-8
PHYSDEVBUS=usb
PHYSDEVDRIVER=usb
MAJOR\x189
MINOR=6

--
Zaar


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevd "got lost" after moving /dev

[Kay Sievers]

On Tue, Jan 31, 2006 at 02:29:39PM +0200, Hai Zaar wrote:
> In initramfs I run udevd and populate /dev.
> Then I mount new root to $NEWROOT.
> Then I do the following:
>             cd $NEWROOT
>             udevcontrol stop_exec_queue
>             mount -n --move /dev ./dev
>             mount -n --move / .
>             chroot /sbin/init >/dev/console </dev/console
> 
> In initramfs I have only storage-related modules. So some of the
> events have failed. So in bootscripts, instead of triggering all of
> the events again, I just want to:
>             udevcontrols start_exec_queue
> and then replay failed events. This would complete the coldplugging.
> 
> The problem is that after --move'ing and chrooting, udev behaves very
> strange. It looks like it do not see the rules or something like that.
> For example when I plug USB disk (logs are in the end of the message).
> If I restart udevd somewhere in bootscripts, everythings works fine.

Don't run the daemon from initramfs on the real root. You should kill it
before leaving initramfs and start the real one. Ususally you also want
to replay all events in the real root, cause there could be different
rules and different tools available than in initramfs.

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevd "got lost" after moving /dev

[Hai Zaar]

>
> Don't run the daemon from initramfs on the real root.
Is there any technical reason for it?
> You should kill it
> before leaving initramfs and start the real one. Ususally you also want
> to replay all events in the real root, cause there could be different
> rules and different tools available than in initramfs.
My mkinitramfs script brings real udev rules to initramfs image, so I
have exactly the same rules both in initramfs and real root.

>
> Kay
>


--
Zaar


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevd "got lost" after moving /dev

[Scott James Remnant]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

On Tue, 2006-01-31 at 16:47 +0200, Hai Zaar wrote:

> > Don't run the daemon from initramfs on the real root.
> Is there any technical reason for it?
> 
Because it can't see the real filesystem once the pivot_root has taken
place.

> > You should kill it
> > before leaving initramfs and start the real one. Ususally you also want
> > to replay all events in the real root, cause there could be different
> > rules and different tools available than in initramfs.
> My mkinitramfs script brings real udev rules to initramfs image, so I
> have exactly the same rules both in initramfs and real root.
> 
But then you can't update those rules in the real root and have udevd
automatically reload; you'd have to reboot!

Scott
-- 
Scott James Remnant
scott@ubuntu.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: udevd "got lost" after moving /dev

[Hai Zaar]

On 1/31/06, Scott James Remnant <scott@ubuntu.com> wrote:
> On Tue, 2006-01-31 at 16:47 +0200, Hai Zaar wrote:
>
> > > Don't run the daemon from initramfs on the real root.
> > Is there any technical reason for it?
> >
> Because it can't see the real filesystem once the pivot_root has taken
> place.
You are right. After some more thinking I've got it myself. Thanks!

>
> > > You should kill it
> > > before leaving initramfs and start the real one. Ususally you also want
> > > to replay all events in the real root, cause there could be different
> > > rules and different tools available than in initramfs.
> > My mkinitramfs script brings real udev rules to initramfs image, so I
> > have exactly the same rules both in initramfs and real root.
> >
> But then you can't update those rules in the real root and have udevd
> automatically reload; you'd have to reboot!
Well, I still keep /etc/init.d/udev script, so if I update rules, I
can run /etc/init.d/udev restart or something like that. That does not
matter anyway, due to the first reason above.
>
> Scott
> --
> Scott James Remnant
> scott@ubuntu.com
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
>
> iD8DBQBD34JASnQiFMl4yK4RAtMWAJ9/0M7sG+76LMZlyJ/7o5KdmNU9GwCgm/CO
> ET4i4BQ9IEycI0NWbfOvhyM> =gdBc
> -----END PGP SIGNATURE-----
>
>
>


--
Zaar


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevd "got lost" after moving /dev

[Vassilis Virvilis]

Kay Sievers wrote:

> Don't run the daemon from initramfs on the real root. You should kill it
> before leaving initramfs and start the real one. Ususally you also want
> to replay all events in the real root, cause there could be different
> rules and different tools available than in initramfs.
> 
> Kay
> 

Wouldn' do this the trick?

mount -o bind /dev /root/dev;
where /root is mounted the "real" root device
just before releasing control to the "real" init

exec run-init ${rootmnt} ${init} "$@";

     .bill


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevd "got lost" after moving /dev

[Kay Sievers]

On Thu, Feb 02, 2006 at 03:25:24PM +0200, Vassilis Virvilis wrote:
> Kay Sievers wrote:
> 
> >Don't run the daemon from initramfs on the real root. You should kill it
> >before leaving initramfs and start the real one. Ususally you also want
> >to replay all events in the real root, cause there could be different
> >rules and different tools available than in initramfs.

> Wouldn' do this the trick?
> 
> mount -o bind /dev /root/dev;
> where /root is mounted the "real" root device
> just before releasing control to the "real" init
> 
> exec run-init ${rootmnt} ${init} "$@";

What has this to do with different rules on the real root, different
tools not available in initramfs or the udev daemon not receiving events
for changed rule files on the real root?

Kay


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: udevd "got lost" after moving /dev

[Vassilis Virvilis]

Kay Sievers wrote:

> 
> What has this to do with different rules on the real root, different
> tools not available in initramfs or the udev daemon not receiving events
> for changed rule files on the real root?
> 
> Kay
> 

None, I was replying in case his setup was the same (between initramfs and real root)
and he doesn't want to replay the events because the /dev directory simply vanished.


    .bill




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x103432&bid#0486&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel