|
Size: 2143
Comment:
|
Size: 2310
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| Life is massively simpler if you just compile your own kernel and put everything in statically. The beautiful thing about this is, if you compile the kernel statically, your bootloader is not broken, the root fs mounts (or you can pass boot args to use a network root fs!) and the root fs has /bin/bash, then you can always recover from any damage. If you rely on kernel modules, magical initial ramdisks, etc, the situation becomes much more fragile. | Life is massively simpler if you just compile your own kernel and put everything in statically. The beautiful thing about this is, if you compile the kernel statically, your bootloader is not broken, the root fs mounts and the root fs has /bin/bash, /dev/console, and /dev/null, then you can always recover from any damage. Note that if the kernel has boot-from-nfs or boot-from-afs compiled in, then all you need is a working bootloader and a kernel! If you rely on kernel modules, magical initial ramdisks, etc, the situation becomes much, much more fragile -- exponentially so if you need kernel modules (such as the md driver) to mount the root filesystem. |
| Line 7: | Line 7: |
| The above paragraph is not 100% true any longer. It used to be the case back in the good old days of devfs. However, devfs was retired for entirely nontechnical reasons (completely political/manpower-based issues) and now we have udev. So, you need to make sure that /dev/null and /dev/console exist. Unfortunately, udev "overmounts" its own tempfs over the root filesystem's /dev, so once the system is up there's really no easy way to make sure that these files are in place "beneath" udev's overmount. This is a pain, but now that the world has decided on udev, there is no longer any alternative (I am personally of the opinion that a kernel hack to make these two devices "seem to" exist even if they aren't there would be a great idea). | The above paragraph is not 100% true any longer. It used to be the case back in the good old days of devfs. However, devfs was retired for entirely nontechnical reasons (completely political/manpower-based issues) and now we have udev. Unfortunately, udev "overmounts" its own tempfs over the root filesystem's /dev, so once the system is up there's really no easy way to make sure that /dev/console and /dev/null files are in place "beneath" udev's overmount. This is a pain, but now that the world has decided on udev, there is no longer any alternative (I am personally of the opinion that a kernel hack to make these two devices "seem to" exist even if they aren't there would be a great idea). |
1. Adam Megacz's Opinion
Look, I've been burned a billion times by the insanity of kernel modules and "initial ramdisks" (or whatever they're called nowadays). I am of the opinion that the main purpose of kernel modules is to make life easier for kernel developers, so they can try new code without rebooting. I still remain unconvinced that kernel modules are a good idea for normal users.
Life is massively simpler if you just compile your own kernel and put everything in statically. The beautiful thing about this is, if you compile the kernel statically, your bootloader is not broken, the root fs mounts and the root fs has /bin/bash, /dev/console, and /dev/null, then you can always recover from any damage. Note that if the kernel has boot-from-nfs or boot-from-afs compiled in, then all you need is a working bootloader and a kernel! If you rely on kernel modules, magical initial ramdisks, etc, the situation becomes much, much more fragile -- exponentially so if you need kernel modules (such as the md driver) to mount the root filesystem.
The above paragraph is not 100% true any longer. It used to be the case back in the good old days of devfs. However, devfs was retired for entirely nontechnical reasons (completely political/manpower-based issues) and now we have udev. Unfortunately, udev "overmounts" its own tempfs over the root filesystem's /dev, so once the system is up there's really no easy way to make sure that /dev/console and /dev/null files are in place "beneath" udev's overmount. This is a pain, but now that the world has decided on udev, there is no longer any alternative (I am personally of the opinion that a kernel hack to make these two devices "seem to" exist even if they aren't there would be a great idea).
1.1. How to Do It
Grab the source tarball for the kernel. Do a make menuconfig, disable kernel modules, DO NOTHING ELSE, save, and exit. This will change all the "M" options to "*" -- it will change the default kernel config to use the same options, but to simply compile them statically rather than as modules. Unfortunately then you will need to go back in and re-enable module support because (for licensing reasons) the openafs code cannot be statically compiled into the kernel. But everything else can be.