Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] udev changes

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Arjan Bouter <abouter AT sourcemage.org>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] udev changes
  • Date: Sun, 29 May 2011 15:04:08 +0200

On Sun, 29 May 2011 21:51:46 +0900
flux <flux AT sourcemage.org> wrote:

> Arjan Bouter (abouter AT sourcemage.org) wrote [11.05.29 21:26]:
> > Now that the CONFIG_DEVTMPFS is mandatory for every single smgl box with
> > udev
> > installed without any backward compatibility we'll need to fix a couple of
> > issues:
> >
> > * "fix" the linux spell to drop support for kernels < 2.6.32 (possibly
> > even
> > more kernels will *have* to be dropped because devtmpfs only lost it's
> > experimental status around January 2010)
> >
> > * selinux support needs to be checked, as the kernel has *no* clue about
> > selinux context and all device files will be created with the default
> > context, possibly breaking existing installs.
> >
> > * we need to document on the website that anyone using a initramfs *must*
> > mount
> > devtmpfs in that initramfs, because the kernel doesn't automount it in
> > this
> > case.
> >
> > * cauldron needs logic to make sure that CONFIG_DEVTMPFS is enabled both
> > in the
> > supplied kernel as in the kernel that's built during install when udev
> > is
> > used because because otherwise the system will probably be unable to
> > boot.
> >
> > It's quite possible that a lot more needs to be fixed, these are just the
> > few
> > issues that came to mind when I had the init.d spell fail because
> > CONFIG_DEVTMPFS is disabled in my kernel.
> >
> > I'm all for useful new features, but is this really something we need to
> > force
> > on every udev user?
> >
> > Arjan Bouter
>
> There are several problems here.
>
> 1) This should not be a requirement (at least not yet) in the first
> place. This needs far more testing before it should be pushed onto
> everyone. Specifically, it minimally needs a clear update path. A udev
> that requires a new kernel feature should *not* go into stable until at
> least this update path is in place to handle the change over. There
> should also be far more testing to ensure that said upgrade path
> actually works for different scenarios.
>
> 2) Cauldron does not need the logic you imply. The ISO kernel is built
> from a maintained kernel config, so the config would only need to be
> updated (pending the change actually goes into stable, but see point (1)
> above). There is no requirement to test custom built kernels for
> specific features, and it would not make sense to. If you build a custom
> kernel, it's your own responsibility to make sure you build it with the
> necessary options. For current udev in the stable grimoire you must have
> tmpfs enabled, and there have never been any checks for the presence of
> tmpfs in a kernel, either in cauldron or any of our other components.
> One particular reason this is the case is because udev itself is
> optional.
>
> 3) We've never marshalled what goes on in an initramfs employed by a
> user, because we don't offer any. Any and all initram filesystems are
> created by the user and thus the user's responsibility. Additionally,
> there is still no requirement that the user mount devtmpfs in the
> initramfs unless the user employs udev in the initramfs. Busybox
> provides its own minimalistic device manager, mdev. One could also use a
> static dev in the initramfs. This is all completely separate and
> orthogonal to what is used in the booted system, as the initramfs and
> the booted system are two distinct run-times.
>
> 4) Not all users install their kernel via the linux spell, so you can't
> assume that putting a fix in the linux spell will guarantee the sanity
> of the system. However, since the kernel options are ultimately the
> user's responsibility, it's not a real problem since it's up to the user
> to guarantee this particular sanity (again, we make no provisions
> presently even for tmpfs support in the kernel, which is already
> required for udev in the stable grimoire).
>
> --
> Justin "flux_control" Boffemmyer
> Cauldron wizard and general mage
> Source Mage GNU/Linux
> http://www.sourcemage.org


I agree that it should not be required/enforced at this point to use devtmpfs,
but it is. The init.d spell fails when devtmpfs isn't in the kernelconfig and
when using udev it currently is assumed devtmpfs is enabled.

I mentioned putting a notice on the website for initramfs users, because until
now our init scripts handled /dev and we're switching to having the kernel
provide the initial populating of /dev

Failing to at least warn the user when devtmpfs is used when installing will
result in the box not booting properly and the init.d spell failing.

Anyone running an unpatched kernel < 2.6.32 won't have the devtmpfs option so
these kernels won't work with the current init.d and udev spells.

David mentioned we need a proper upgrade path and yet the changes are made.

This change needs more work.

Arjan

+=======
Source Mage GNU/Linux developer,
http://www.sourcemage.org
+===




Archive powered by MHonArc 2.6.24.

Top of Page