| 1 |
Branko Badrljica wrote: |
| 2 |
> Jason wrote: |
| 3 |
>> initrd is exactly how you do it. In the case of booting off of USB, |
| 4 |
>> there are too many variables (drive detection order, different |
| 5 |
>> hardware, etc) to handle on the kernel command line. An initrd gives |
| 6 |
>> you the flexibility to solve these problems. |
| 7 |
>> |
| 8 |
>>> You could use initrd/initramfs, but seems like a lot of complications |
| 9 |
>>> for little gain... |
| 10 |
>> |
| 11 |
>> I wouldn't call a portable, writable, boot from anywhere Linux OS on a |
| 12 |
>> thumbdrive a trivial gain. ;-) |
| 13 |
> |
| 14 |
> But y<ou have the headache of interface at the old and new root across |
| 15 |
> the pivot root. What happens if you execute something that was |
| 16 |
> dynamically linked from intramfs and it decides to load and link another |
| 17 |
> module with dlopen() from new root ? If you have that module and it |
| 18 |
> belongs to the same version, then probably everything is fine. Otherwise |
| 19 |
> it might not be. |
| 20 |
|
| 21 |
1.) a good initrd will use only statically linked executables. |
| 22 |
2.) you shouldn't start any servers or background processes from initrd. |
| 23 |
3.) initrd's are tied to kernels. Every distro's initrd generator is |
| 24 |
re-run upon upgrading the kernel. The modules versions won't be out of |
| 25 |
sync then. Gentoo has genkernel for this purpose. |
| 26 |
|
| 27 |
> Also, opened files and extra nodes in /dev during intiramfs phase tend |
| 28 |
> to cause a headache or two... |
| 29 |
|
| 30 |
If your initrd follows the 3 suggestions, above, there won't be any |
| 31 |
processes running to hold a file or device open. Unless you had |
| 32 |
something else in mind? |
| 33 |
|
| 34 |
Jason. |
| 35 |
-- |
| 36 |
gentoo-amd64@l.g.o mailing list |
Archives