[Buildroot] devtmpfs and initramfs

[Buildroot] devtmpfs and initramfs

[Arnout Vandecappelle]

 Hoi all,

 I'm using an initramfs as the root filesystem image, and devtmpfs for the 
devices.  However, it turns out that devtmpfs doesn't get mounted 
automatically if the root filesystem is an initramfs (at least in 2.6.35).

 I ended up adding the following to my inittab:

null::sysinit:/bin/mount -t devtmpfs devtmpfs /dev


 Does anyone know a more elegant solution?

 Regards,
 Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

[Buildroot] devtmpfs and initramfs

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

 Arnout>  Hoi all,

 Arnout>  I'm using an initramfs as the root filesystem image, and
 Arnout> devtmpfs for the devices.  However, it turns out that devtmpfs
 Arnout> doesn't get mounted automatically if the root filesystem is an
 Arnout> initramfs (at least in 2.6.35).

Indeed, init/mainc::kernel_init() doesn't call prepare_namespace()
(which calls devtmpfs_mount()) if an initramfs with an /init is found.

 Arnout>  I ended up adding the following to my inittab:

 Arnout> null::sysinit:/bin/mount -t devtmpfs devtmpfs /dev

 Arnout>  Does anyone know a more elegant solution?

Not really - Besides adding a devtmps_mount() call in kernel_init(), but
that's kind of icky as well.

-- 
Bye, Peter Korsgaard

[Buildroot] devtmpfs and initramfs

[Arnout Vandecappelle]

On Tuesday 19 July 2011 12:33:13, Peter Korsgaard wrote:
> >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
>  Arnout>  I ended up adding the following to my inittab:
> 
>  Arnout> null::sysinit:/bin/mount -t devtmpfs devtmpfs /dev
> 
>  Arnout>  Does anyone know a more elegant solution?
> 
> Not really - Besides adding a devtmps_mount() call in kernel_init(), but
> that's kind of icky as well.

 We could of course use the same trick as for GENERIC_SERIAL...

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

[Buildroot] devtmpfs and initramfs

[Diego Iastrubni]

On Tue, Jul 19, 2011 at 2:23 PM, Arnout Vandecappelle <arnout@mind.be>wrote:

>
> On Tuesday 19 July 2011 12:33:13, Peter Korsgaard wrote:
> > >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> >  Arnout>  I ended up adding the following to my inittab:
> >
> >  Arnout> null::sysinit:/bin/mount -t devtmpfs devtmpfs /dev
> >
> >  Arnout>  Does anyone know a more elegant solution?
> >
> > Not really - Besides adding a devtmps_mount() call in kernel_init(), but
> > that's kind of icky as well.
>
>  We could of course use the same trick as for GENERIC_SERIAL...
>
>  Regards,
>  Arnout
>
>
.. or... we can revert ca520507fc15a8213334a76339a3e6d567e91ea0 ... as I
have seen 2-3 people have been reporting similar problems is the last few
months.

see:
http://lists.busybox.net/pipermail/buildroot/2011-May/043266.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110720/62208c11/attachment.html>

[Buildroot] devtmpfs and initramfs

[Peter Korsgaard]

>>>>> "Diego" == Diego Iastrubni <diegoiast@gmail.com> writes:

Hi,

 Diego> .. or... we can revert?ca520507fc15a8213334a76339a3e6d567e91ea0
 Diego> ... as I have seen 2-3 people have been reporting similar
 Diego> problems is the last few months.

That wouldn't really change anything for people using devtmpfs or mdev,
and as devtmpfs gets used more and more (E.G. systemd requires it) and
brings a number of advantages, I think it's a sensible thing to require.

-- 
Bye, Peter Korsgaard

[Buildroot] devtmpfs and initramfs

[Arnout Vandecappelle]

On Wednesday 20 July 2011 09:44:31, Diego Iastrubni wrote:
> On Tue, Jul 19, 2011 at 2:23 PM, Arnout Vandecappelle <arnout@mind.be>wrote:
> > On Tuesday 19 July 2011 12:33:13, Peter Korsgaard wrote:
> > > >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> > >  Arnout>  I ended up adding the following to my inittab:
> > >  
> > >  Arnout> null::sysinit:/bin/mount -t devtmpfs devtmpfs /dev
> > >  
> > >  Arnout>  Does anyone know a more elegant solution?
> > > 
> > > Not really - Besides adding a devtmps_mount() call in kernel_init(),
> > > but that's kind of icky as well.
> >  
> >  We could of course use the same trick as for GENERIC_SERIAL...
> >  
> >  Regards,
> >  Arnout
> 
> .. or... we can revert ca520507fc15a8213334a76339a3e6d567e91ea0 ... as I
> have seen 2-3 people have been reporting similar problems is the last few
> months.
> 
> see:
> http://lists.busybox.net/pipermail/buildroot/2011-May/043266.html

 Call me stupid, but I don't see how that would help: the whole point is that 
I'm not using udev but devtmpfs...

 BTW, it looks like there never was any reply to your original post: /sys is 
mounted by the 'mount -a' in inittab, which looks at /etc/fstab and finds a 
/sys line there.

 Regards,
 Arnout
-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

[Buildroot] devtmpfs and initramfs

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 Arnout> Does anyone know a more elegant solution?
 >> 
 >> Not really - Besides adding a devtmps_mount() call in kernel_init(), but
 >> that's kind of icky as well.

 Arnout>  We could of course use the same trick as for GENERIC_SERIAL...

We could, or adjust initramfs.mk to add a small shellscript as /init
rather than just a symlink:

#!/bin/sh
# devtmpfs does not get automounted for initramfs'es
/bin/mount -t devtmpfs devtmpfs /dev
exec /sbin/init $*

Unless BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled.

-- 
Bye, Peter Korsgaard

[Buildroot] devtmpfs and initramfs

[Diego Iastrubni]

>
> We could, or adjust initramfs.mk to add a small shellscript as /init
> rather than just a symlink:
>
> #!/bin/sh
> # devtmpfs does not get automounted for initramfs'es
> /bin/mount -t devtmpfs devtmpfs /dev
> exec /sbin/init $*
>
> Unless BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled.
>
>
Sorry, but this solution smells just like my socks. I think wk can find a
better one :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20110720/692cdd8d/attachment.html>

[Buildroot] devtmpfs and initramfs

[Arnout Vandecappelle]

On Wednesday 20 July 2011 10:48:28, Diego Iastrubni wrote:
> > We could, or adjust initramfs.mk to add a small shellscript as /init
> > rather than just a symlink:
> > 
> > #!/bin/sh
> > # devtmpfs does not get automounted for initramfs'es
> > /bin/mount -t devtmpfs devtmpfs /dev
> > exec /sbin/init $*
> > 
> > Unless BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled.
> 
> Sorry, but this solution smells just like my socks. I think wk can find a
> better one :)

 Yeah, I also would prefer not to proliferate the number of ways that the init 
process is influenced...

 That said, the inittab solution isn't that good either.  I guess there is a 
reason why all distros have an S01mountall...

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

[Buildroot] devtmpfs and initramfs

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 >> > #!/bin/sh
 >> > # devtmpfs does not get automounted for initramfs'es
 >> > /bin/mount -t devtmpfs devtmpfs /dev
 >> > exec /sbin/init $*
 >> > 
 >> > Unless BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled.
 >> 
 >> Sorry, but this solution smells just like my socks. I think wk can find a
 >> better one :)

 Arnout>  Yeah, I also would prefer not to proliferate the number of
 Arnout> ways that the init process is influenced...

I don't see what there is to dislike. With this, the non-standard
behaviour of initramfs'es is nicely self contained within the initramfs
support code, and nothing else needs to know about it. There's nothing
to tweak, and it just works out of the box (tm), no matter what init
implementation or custom inittab is used.

You could argue that the shell overhead is a bit of a turn down, but
this is no worse than a S01mountall init script.

-- 
Bye, Peter Korsgaard

[Buildroot] devtmpfs and initramfs

[Arnout Vandecappelle]

On Wednesday 20 July 2011 12:52:08, Peter Korsgaard wrote:
> >>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:
> Hi,
> 
>  >> > #!/bin/sh
>  >> > # devtmpfs does not get automounted for initramfs'es
>  >> > /bin/mount -t devtmpfs devtmpfs /dev
>  >> > exec /sbin/init $*
>  >> > 
>  >> > Unless BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled.
>  >> 
>  >> Sorry, but this solution smells just like my socks. I think wk can find
>  >> a better one :)
> 
>  Arnout>  Yeah, I also would prefer not to proliferate the number of
>  Arnout> ways that the init process is influenced...
> 
> I don't see what there is to dislike. With this, the non-standard
> behaviour of initramfs'es is nicely self contained within the initramfs
> support code, and nothing else needs to know about it. There's nothing
> to tweak, and it just works out of the box (tm), no matter what init
> implementation or custom inittab is used.


 But next thing you know, some other piece of Makefile also wants to do 
something with /init...

 Since it potentially interacts with other parts of the build, I would argue 
that it _should_not_ be self-contained.

 That said, I'm not too enthousiastic about the rc.S solution either, since it 
may also interact badly with alternative init procedures.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

[Buildroot] devtmpfs and initramfs

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 Arnout>  But next thing you know, some other piece of Makefile also
 Arnout> wants to do something with /init...

What would that be? /init is specific to initramfs.

-- 
Bye, Peter Korsgaard

[Buildroot] devtmpfs and initramfs

[Arnout Vandecappelle]

On Wednesday 20 July 2011 10:57:47, Arnout Vandecappelle wrote:
> On Wednesday 20 July 2011 10:48:28, Diego Iastrubni wrote:
> > > We could, or adjust initramfs.mk to add a small shellscript as /init
> > > rather than just a symlink:
> > > 
> > > #!/bin/sh
> > > # devtmpfs does not get automounted for initramfs'es
> > > /bin/mount -t devtmpfs devtmpfs /dev
> > > exec /sbin/init $*
> > > 
> > > Unless BR2_ROOTFS_DEVICE_CREATION_STATIC is enabled.
> > 
> > Sorry, but this solution smells just like my socks. I think wk can find a
> > better one :)
> 
>  Yeah, I also would prefer not to proliferate the number of ways that the
> init process is influenced...
> 
>  That said, the inittab solution isn't that good either.  I guess there is
> a reason why all distros have an S01mountall...


 Okay, I should have shut up and listened to the buildroot master...

 The inittab thing won't work (well) because init needs /dev to have a 
console.

 I'll see if I can produce a patch.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                               arnout at mind be
Senior Embedded Software Architect                 +32-16-286540
Essensium/Mind                                     http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  31BB CF53 8660 6F88 345D  54CC A836 5879 20D7 CF43

[Buildroot] devtmpfs and initramfs

[Peter Korsgaard]

>>>>> "Arnout" == Arnout Vandecappelle <arnout@mind.be> writes:

Hi,

 Arnout>  Okay, I should have shut up and listened to the buildroot master...

;)

 Arnout>  The inittab thing won't work (well) because init needs /dev to
 Arnout> have a console.

I just pushed a commit adding the pre-init shell wrapper I mentioned
earlier. Seems to work fine based on a quick test in qemu.

Alternatively we could try to convince the kernel people that it makes
sense to make CONFIG_DEVTMPFS_MOUNT work with initramfs as well. It's
simple to do so (just stick a devtmpfs_mount("dev") at the bottom of
populate_rootfs), but it could potentially break existing initramfs
scripts as the mount -t devtmpfs devtmpfs /dev command will then fail.

-- 
Bye, Peter Korsgaard