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 : :' : `. `'` `- -- 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/633734621.3380613.1380198178265.javamail.r...@md01.wow.synacor.com