Re: DEVTMPFS, DEVTMPFS_MOUNT, custom no initrd kernel, udev 175-7.2 and 204-4
On Thu, 26 Sep 2013 07:25:33 -0400 (EDT), Regid Ichira wrote:
>
> In view of http://bugs.debian.org/722580 and
> http://bugs.debian.org/722604:
>
> A machine with:
> - a custom, non initrd, linux image
> - udev 175-7.2
> - no DEVTMPFS in the kernel configuration
> is able to boot.
>
> 1. Will the machine boot with
> CONFIG_DEVTMPFS=y
> # CONFIG_DEVTMPFS_MOUNT is not set
> ? Again, custom, non initrd, linux image. udev 175-7.2.
> 2. What about
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> ? custom, non initrd, linux image. udev 175-7.2.
> 3. Will it boot when /etc/init.d/udev from udev 175-7.2 is edtited
> by hand? If so, what modifications, by hand, are required to
> /etc/init.d/udev? Are there more files to edit? Again, custom,
> non initrd, linux image.
> 4. When udev 204-4 is installed, what should be the settings of
> CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT for a custom, non
> initrd, linux image?
>
> Isn't there an upgrade path problem for people with a custom, non
> initrd, linux image that have DEVTMPFS unset? I mean, newer udev
> can't be installed without CONFIG_DEVTMPFS=y. So one has to boot
> into a CONFIG_DEVTMPFS=y kernel before upgrading udev. But will a
> custom, non initrd, linux image with CONFIG_DEVTMPFS=y boot with udev
> 175-7.2?
I don't know the answer to any of your specific questions, but I will
say in general that, in my humble opinion, I would avoid creating kernels
with no initial RAM file system. Back in the day when the only purpose
for an initial RAM file system was to load kernel modules that were needed
before the permanent root file system could be mounted, an alternative to
doing this was to build the needed support directly into the kernel, thus
eliminating the need to load these kernel modules and thus eliminating the
need for an initial RAM file system.
But modern Linux systems need the
initial RAM file system for other things now besides loading kernel modules,
such as launching early user space processes such as udev. Some work by
udev may need to be done before the permanent root file system can be
mounted, such as creating symbolic links in the /dev/disk directory and
its subdirectories. In general, it is not safe to use root file system
specifications such as /dev/sda1 anymore, since the device name mapping
can change from boot to boot. Specifying the root file system by means
of a UUID or LABEL gets around this problem, but that requires that udev
and friends have already done their disk identification work by then. And
without an initial RAM file system, udev cannot be launched until after
the permanent root file system has been mounted. It's a "catch 22"
situation. My advice, for what it's worth, is to stop swimming upstream
and use an initial RAM file system.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: