[PATCH 1/3] initramfs-image: Make intiramfs images cpio.gz

[PATCH 1/3] initramfs-image: Make intiramfs images cpio.gz

[Kelvie Wong]

The kernel doesn't recognize anything else, anyways.
---
 recipes/images/initramfs-image.bb |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/recipes/images/initramfs-image.bb b/recipes/images/initramfs-image.bb
index e518984..ba9d8fe 100644
--- a/recipes/images/initramfs-image.bb
+++ b/recipes/images/initramfs-image.bb
@@ -3,6 +3,7 @@
 # recursive) and NFS.
 
 IMAGE_INSTALL = "busybox-static initramfs-module-block initramfs-module-loop initramfs-module-nfs"
+IMAGE_FSTYPES = "cpio.gz"
 IMAGE_LINGUAS = ""
 
 # Remove any kernel-image that the kernel-module-* packages may have pulled in.
-- 
1.7.0.4

[PATCH 2/3] initramfs-module-udev: New module

[Kelvie Wong]

This launches (and kills) udev during the initramfs procedure to populate
the /dev tree as udev would.

With this, we can boot off block devices by label or uuid, by using the
/dev/disk/by-{uuid,label,path}/sdX syntax.
---
 recipes/initrdscripts/files/15-initudev.sh         |    5 +++++
 recipes/initrdscripts/files/90-killudev.sh         |    4 ++++
 recipes/initrdscripts/initramfs-module-udev_1.0.bb |   13 +++++++++++++
 3 files changed, 22 insertions(+), 0 deletions(-)
 create mode 100644 recipes/initrdscripts/files/15-initudev.sh
 create mode 100644 recipes/initrdscripts/files/90-killudev.sh
 create mode 100644 recipes/initrdscripts/initramfs-module-udev_1.0.bb

diff --git a/recipes/initrdscripts/files/15-initudev.sh b/recipes/initrdscripts/files/15-initudev.sh
new file mode 100644
index 0000000..5505a83
--- /dev/null
+++ b/recipes/initrdscripts/files/15-initudev.sh
@@ -0,0 +1,5 @@
+#!/bin/sh
+# Starts udev to populate /dev
+
+# 'start' isn't actually needed, but keeps it consistent
+/etc/init.d/udev start
diff --git a/recipes/initrdscripts/files/90-killudev.sh b/recipes/initrdscripts/files/90-killudev.sh
new file mode 100644
index 0000000..464eb30
--- /dev/null
+++ b/recipes/initrdscripts/files/90-killudev.sh
@@ -0,0 +1,4 @@
+#!/bin/sh
+# Kills udevd before booting into the real root.
+
+kill `pidof udevd`
diff --git a/recipes/initrdscripts/initramfs-module-udev_1.0.bb b/recipes/initrdscripts/initramfs-module-udev_1.0.bb
new file mode 100644
index 0000000..0ae9a33
--- /dev/null
+++ b/recipes/initrdscripts/initramfs-module-udev_1.0.bb
@@ -0,0 +1,13 @@
+SRC_URI = "file://15-initudev.sh file://90-killudev.sh"
+RDEPENDS = "initramfs-uniboot udev"
+DESCRIPTION = "initramfs module for populating /dev with udev"
+
+do_install() {
+    install -d ${D}/initrd.d
+    install -m 0755 ${WORKDIR}/15-initudev.sh ${D}/initrd.d/
+    install -m 0755 ${WORKDIR}/90-killudev.sh ${D}/initrd.d/
+}
+
+PACKAGE_ARCH = "all"
+FILES_${PN} += " /initrd.d/* "
+
-- 
1.7.0.4

[PATCH 3/3] initramfs-udev-image: new image target.

[Kelvie Wong]

This is an initramfs image target with udev support.  This is useful for
things such as booting from /dev/disk/by-{uuid,label}/*
---
 recipes/images/initramfs-udev-image.bb |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)
 create mode 100644 recipes/images/initramfs-udev-image.bb

diff --git a/recipes/images/initramfs-udev-image.bb b/recipes/images/initramfs-udev-image.bb
new file mode 100644
index 0000000..669cbfc
--- /dev/null
+++ b/recipes/images/initramfs-udev-image.bb
@@ -0,0 +1,7 @@
+# initramfs image with udev support
+#
+# (New!) Now with a more populated /dev!
+
+require initramfs-image.bb
+
+IMAGE_INSTALL += "initramfs-module-udev"
-- 
1.7.0.4

Re: [PATCH 2/3] initramfs-module-udev: New module

[Otavio Salvador]

Hello,

On Sat, Sep 25, 2010 at 2:07 PM, Kelvie Wong <kwong@wurldtech.com> wrote:
> This launches (and kills) udev during the initramfs procedure to populate
> the /dev tree as udev would.

I didn't get /why/ do you kill it after starting.

Personally I think this could be supported by not enabled by default.
This might be an option that could be set by image.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: [PATCH 2/3] initramfs-module-udev: New module

[Kelvie Wong]

On September 25, 2010 03:29:15 pm Otavio Salvador wrote:
> Hello,
> 
> On Sat, Sep 25, 2010 at 2:07 PM, Kelvie Wong <kwong@wurldtech.com> wrote:
> > This launches (and kills) udev during the initramfs procedure to populate
> > the /dev tree as udev would.
> 
> I didn't get /why/ do you kill it after starting.
> 
> Personally I think this could be supported by not enabled by default.
> This might be an option that could be set by image.

This was to let the rest of the boot process start udev, if it wants to.

All I need udev for is to populate /dev (specifically, the nodes in /dev/disk 
to set the root partition by label, e.g. for USB disk partitions); I don't 
want to leave processes running when doing the chroot, either.

-- 
Kelvie Wong
Software Developer

Wurldtech Security Technologies Inc.
Suite 1680 - 401 West Georgia St.
Vancouver, B.C.  V6B 5A1
Canada

Phone:       + 1.604.669.6674
Toll Free:   + 1.877.369.6674
Fax:           + 1.604.669.2902
Website:    http://www.wurldtech.com/

"ARE YOU ACHILLES CERTIFIED?"

This message is intended only for the named recipients. This message
may contain information that is privileged, confidential or exempt
from disclosure under applicable law. Any dissemination or copying
of this message by anyone other than a named recipient is strictly
prohibited. If you are not a named recipient or an employee or agent
responsible for delivering this message to a named recipient, please
notify us immediately by telephone at 604-669-6674, and permanently
destroy this message and any copies you may have. Email may not be
secure unless properly encrypted.

Re: [PATCH 2/3] initramfs-module-udev: New module

[Otavio Salvador]

Hello,

On Mon, Sep 27, 2010 at 11:39 AM, Kelvie Wong <kwong@wurldtech.com> wrote:
> This was to let the rest of the boot process start udev, if it wants to.

Right.

> All I need udev for is to populate /dev (specifically, the nodes in /dev/disk
> to set the root partition by label, e.g. for USB disk partitions); I don't
> want to leave processes running when doing the chroot, either.

For systems that are going to _use_ udev this looks like wasting CPU
time and IO.

I see your point but I believe it might be an optional behaviour.

-- 
Otavio Salvador                  O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854         http://projetos.ossystems.com.br

Re: [PATCH 2/3] initramfs-module-udev: New module

[Kelvie Wong]

On September 27, 2010 07:51:43 am Otavio Salvador wrote:
> Hello,
> 
> On Mon, Sep 27, 2010 at 11:39 AM, Kelvie Wong <kwong@wurldtech.com> wrote:
> > This was to let the rest of the boot process start udev, if it wants to.
> 
> Right.
> 
> > All I need udev for is to populate /dev (specifically, the nodes in
> > /dev/disk to set the root partition by label, e.g. for USB disk
> > partitions); I don't want to leave processes running when doing the
> > chroot, either.
> 
> For systems that are going to _use_ udev this looks like wasting CPU
> time and IO.
> 
> I see your point but I believe it might be an optional behaviour.

I am unfamiliar with how udev works in this case -- if I leave it running, and 
another tmpfs is mounted on the new /dev (outside of the initrd), does it get 
populated unless udev is restarted?

(Sorry for the double send, didn't mean to take it off list)
-- 
Kelvie Wong
Software Developer

Wurldtech Security Technologies Inc.
Suite 1680 - 401 West Georgia St.
Vancouver, B.C.  V6B 5A1
Canada

Phone:       + 1.604.669.6674
Toll Free:   + 1.877.369.6674
Fax:           + 1.604.669.2902
Website:    http://www.wurldtech.com/

"ARE YOU ACHILLES CERTIFIED?"

This message is intended only for the named recipients. This message
may contain information that is privileged, confidential or exempt
from disclosure under applicable law. Any dissemination or copying
of this message by anyone other than a named recipient is strictly
prohibited. If you are not a named recipient or an employee or agent
responsible for delivering this message to a named recipient, please
notify us immediately by telephone at 604-669-6674, and permanently
destroy this message and any copies you may have. Email may not be
secure unless properly encrypted.