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 : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1287490021.3392877.1380236855592.javamail.r...@md01.wow.synacor.com
