Re: should an end user stick to a kernel with an initrd?
On Thu, 26 Sep 2013 11:57:34 -0400 (EDT), Regid Ichira wrote:
>
> I deliberately changed the subject of this message because I hope
> people will also pay attention to my previous message in the thread.
> At http://lists.debian.org/debian-user/2013/09/msg01150.html, which,
> I hope, this message will be a follow-up to, Stephen Powell wrote
> that, in general, initrd are desirable. He gave a few example where,
> he believes, one can not get without it. I am no expert. I do
> believe that, other then corner cases, most, if not all, the examples
> are wrong. They can be done without an initrd. I think the basic
> reason is that one can have udev rules that will map specific devices
> to specific names.
> Now, considering that an initrd requires a lot more software, I
> think that an initrd should be avoided unless absolutely necessary.
You don't seem to understand. First of all, even if you have written
udev rules to map specific devices to specific names, this mapping
cannot take place until udev starts. udev is not kernel code. It is
not a kernel module, nor can it be built in to the kernel. It is a
user-space process. That means that it must be read from a file system
and executed as a command. And that means that a file system must be
mounted. If you don't use an initial RAM file system, there is no file
system from which to read udev until the permanent root file system is
mounted (usually read-only initially). And if the permanent root file
system is already mounted, it is too late to assign a name to it.
You must know the name before udev gets launched.
Second, this is contrary to the direction and thinking of the kernel
people these days. Traditional device names, such as /dev/sda, /dev/sdb,
(and therefore the partitions on those devices, such as /dev/sda1, /dev/sdb1,
etc.) are not assigned in a predictable manner anymore. This device name
assignment can change from one boot to the next. In order to specify
which partition is to be mounted as the permanent root file system in a manner
which is independent of the now-unpredictable device name assignment, you must
rely on something like the uuid or label of the partition, which is presumed
to be unique. For example, if your boot loader is LILO, something like
root="UUID=3860da3c-b206-44d9-920c-5ed4beac34e9"
can be specified in /etc/lilo.conf. This results in the following being
added to the kernel command line by the LILO boot loader:
root=UUID=3860da3c-b206-44d9-920c-5ed4beac34e9
But in order for the kernel to figure out which partition on which disk
this is, it looks for a symbolic link called
/dev/disk/by-uuid/3860da3c-b206-44d9-920c-5ed4beac34e9
If it finds it, it can determine what partition to mount as the permanent
root file system. But if it can't find it, it can't mount the permanent
root file system. How did that symbolic link get created? udev created it.
udev, launched from the initial RAM file system, has already created this
symbolic link. It might point to /dev/sda1 on this boot. But on the next
boot, it might point to /dev/sdb1. In either case, it will be the
correct partition to mount as the permanent root file system. But if you
don't use an initial RAM file system, udev has not been launched yet, and
therefore, the symbolic link does not exist yet, and therefore, the kernel
can't find the permanent root file system if you refer to it by means of
a uuid. The same principle applies for referring to a partition by means
of a disk label.
Although it is still possible to create a kernel that does not use an
initial RAM file system, the design of modern Linux systems pretty much
assumes that one is used. I predict that as time goes on you will continue
to encounter more and more problems as the result of not using one.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Reply to: